------- Comment #4 from yamagen at coral dot t dot u-tokyo dot ac dot jp 2008-01-21 02:57 ------- Thank you very much for your comments.
First I answer to you why I would like to use -ff2c option. The reason is that I would like to use "-framework vecLib". In the URL http://developer.apple.com/hardwaredrivers/ve/errata.html#fortran_conventions , Apple said "The FORTRAN entry points in Mac OS X's vecLib adhere to the call/return conventions of g77." When I tried compile & linking vecLib without "-ff2c" option, the double complex function "zdotu" does not work correctly. Then I tried "-ff2c" option and found this issue. Honestly saying, I don't know well about the calling convention ( nor "C" langueage ), but, I have tried "f2c test2.f" ----test2.f---- function f(a) implicit none complex*16 f real*8 a(*) f=(0d0,0d0) end -------------- Then the resultant C source is /* Double Complex */ VOID f_(doublecomplex * ret_val, doublereal *a) { /* Parameter adjustments */ --a; /* Function Body */ ret_val->r = 0., ret_val->i = 0.; } /* f_ */ So it seems to me that the current functionality of the gfortran is different from that of f2c, isn't it? And, I'm wondering why changing the pseudo-size array "a(:)" to the variable "a" makes "test.f" to be compiled with "-ff2c" option without internal error. # Anyway, I just want to use vecLib without degrading the portability of my fortran fource code. # (I know a work-around, calling zdotu as subroutine with one extra argument receiving the result. # But this work-around degrades the portability. ) # Does anyone know the tips for this issue? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34868
