[Bug fortran/34868] ICE with -ff2c for function returning a complex number

["yamagen at coral dot t dot u-tokyo dot ac dot jp" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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