Re: Bug with g77 and -mieee on Alpha Linux

[Jeffrey A Law <law at cygnus dot com>]

  In message <19990712072342.28771.qmail@deer>you write:
  > >The difference between these two cases is in the -f[no]emulate-complex we
  > Agreed.  Though, for g77's purposes, the ABI for complex is currently
  > *always* the ABI for struct { float; float; };.
OK.  That's good to know.   If this is indeed the ABI we need to use after
investigating vendor compilers, then we've probably got some work to do in
the backends which pass parameters in registers since I do not believe all 
are prepared to handle complex modes in the various FUNCTION_ARG macros.

Having it as a struct does help with some issues since structs are usually
not passed in FP registers, even when their members are strictly floats,
strictly doubles or strictly long doubles.

Treating it as an aggregate has some performance impacts, so I wouldn't be
totally surprised if some vendor treated it as two independent float args for
parameter passing purposes.  But that's something we'll have to investigate.

  > I'd be interested in
  > knowing about any ABI's for which that was not the case, because they'd
  > be systems on which g77 -fno-emulate-complex might not even *work*,
Yup.  I doubt we've ever done any serious work at looking at how vendor
compilers handle complex and interoperability between g77 and vendor compiled
fortran libraries (or even libf2c/libg2c compiled with the vendor compiler).

On systems like HPs incompatibilities in this area could also be hidden by the
linker for double complex values -- in the event of a caller/callee mismatch
for register types, the linker will insert a trampoline to shuffle arguments
from one register file to the other.  Ick.


  > Whew, well, good luck!  I *still* don't know what to recommend, other
  > than to say that, if we change the default again and don't respin/retest
  > for at least a month, we're risking some pretty serious regressions.
  > Wish I could put a number on that risk, as that might help you.
I doubt we'd need a month to respin/retest.  I bet we could get all the testing
we needed by lapack in a week.  lapack looks to stress the complex stuff a
hell of a lot more than our regression testsuite.

jeff