【问题标题】:Address not passed properly to Fortran function call地址未正确传递给 Fortran 函数调用
【发布时间】:2013-09-19 07:32:04
【问题描述】:

我一直在尝试通过使用 extern "C" 在 C++ 中声明 ARPACK 函数来查找矩阵的特征向量:

extern "C" {void znaupd_(int *IDO, char *BMAT, int *N, char *WHICH,
                 int *NEV, double *TOL, complex<double> *RESID,
             int *NCV, complex<double> *V, int *LDV,
             int *IPARAM, int *IPNTR, complex<double> *WORKD,
             complex<double> *WORKL, int *LWORKL, 
             double *RWORK, int *INFO);}

extern "C" {void zneupd_(bool *RVEC, char *HOWMNY, bool *SELECT, 
             complex<double> *D, complex<double> *Z,
             int *LDZ, complex<double> *WORKEV, 
             complex<double> *SIGMA, char *BMAT, int *N,
             char *WHICH, int *NEV, double *TOL, 
             complex<double> *RESID, int *NCV, 
             complex<double> *V, int *LDV, int *IPARAM,
             int *IPNTR, complex<double> *WORKD, 
             complex<double> *WORKL, int *LWORKL, int *INFO);}

然后,在我的代码主体中,我调用函数:

  do{
    znaupd_(&IDO, &BMAT, &N, WHICH, &NEV, &TOL, RESID, &NCV, V, &LDV, IPARAM,
        IPNTR, WORKD, WORKL, &LWORKL, RWORK, &INFO);
    switch(abs(IDO)){
    case - 1:
      for(i = 0; i < N; i++) X[i] = WORKD[IPNTR[1] + i];
      gmm::mult(SM, X, Y);
      for(i = 0; i < N; i++) WORKD[IPNTR[2] + i] = Y[i];
      break;
    case 1:
      for(i = 0; i < N; i++) X[i] = WORKD[IPNTR[1] + i]; 
      gmm::mult(SM, X, Y);
      for(i = 0; i < N; i++) 
    {WORKD[IPNTR[2] + i] = Y[i];
      WORKD[IPNTR[3] + i] = X[i];}
      break;
    case 2:
      for(i = 0; i < N; i++)
    WORKD[IPNTR[2] + i] = WORKD[IPNTR[1] + i];
      break;
    }
  }while(IDO != 99);
  std::cout << &INFO << std::endl;
  zneupd_(&RVEC, &HOWMNY, SELECT, D, Z, &LDZ, WORKEV, &SIGMA, &BMAT, &N,
      WHICH, &NEV, &TOL, RESID, &NCV, V, &LDV, IPARAM, IPNTR, WORKD,
      WORKL, &LWORKL, &INFO);

然而,在编译和执行之后,程序会出现段错误。使用 GDB 执行回溯显示 &INFO 传递给 zneupd_ 的地址为 0x0,这会导致当 zneupd_ 尝试为该位置分配新值时出现段错误。然而,当我移动到下一帧并使用 print &INFO 时,我被告知 INFO 存储在寄存器 0x​​28a27c 中。出于某种原因,我的程序没有正确地将 INFO 的位置​​传递给 zneupd_。更令人困惑的是znaupd_能够正确接收&INFO,并且能够毫无问题地访问和修改该位置的值。谁能告诉我为什么一个函数可以正确接收参数,而另一个不能?

【问题讨论】:

标签: c++ fortran fortran77 arpack


【解决方案1】:

您可能正在阅读错误的 ARPACK 文档,其中对 ZNEUPD 子例程的描述有误。实际上,在INFO 之前还有一个额外的参数RWORK(总共24 个参数),并且SIGMAWORKEV 之前 - 请参阅official documentation 和一些source code&amp;INFO 在你的情况下是 0 只是一个幸运的巧合。

您的代码中还有另一个问题 - 子例程的 C 原型对于 x86/x64 上的大多数 Fortran 编译器是不正确的。这是因为CHARACTER 参数BMATWHICHHOWMNY 是字符数组(字符串),并且每个实际字符串参数的长度也通过按值作为整数类型的附加隐藏参数。因此ZNAUPD的原型应该是:

extern "C"
void znaupd_(int *IDO,
             char *BMAT,
             int *N,
             char *WHICH,
             int *NEV,
             double *TOL,
             complex<double> *RESID,
             int *NCV,
             complex<double> *V,
             int *LDV,
             int *IPARAM,
             int *IPNTR,
             complex<double> *WORKD,
             complex<double> *WORKL,
             int *LWORKL, 
             double *RWORK,
             int *INFO,
             int _BMAT,    // The length of the actual BMAT argument
             int _WHICH    // The length of the actual WHICH argument
            );

ZNEUPD 也是如此,但它具有三个隐藏的整数参数:

extern "C"
void zneupd_(bool *RVEC,
             char *HOWMNY,
             bool *SELECT, 
             complex<double> *D,
             complex<double> *Z,
             int *LDZ,
             complex<double> *SIGMA,
             complex<double> *WORKEV, 
             char *BMAT,
             int *N,
             char *WHICH,
             int *NEV,
             double *TOL, 
             complex<double> *RESID,
             int *NCV, 
             complex<double> *V,
             int *LDV,
             int *IPARAM,
             int *IPNTR,
             complex<double> *WORKD, 
             complex<double> *WORKL,
             int *LWORKL,
             double *RWORK,
             int *INFO,
             int _HOWMNY,
             int _BMAT,
             int _WHICH
            );

【讨论】:

    猜你喜欢
    • 2022-01-25
    • 2012-10-19
    • 1970-01-01
    • 1970-01-01
    • 2019-11-05
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-02-10
    相关资源
    最近更新 更多