single precision complex bug in g77 - was Testing g77 with LAPACK 3.0

[Jeffrey A Law]

  In message < 199907080032.RAA26170@rtl.cygnus.com >you write:
  > Using current egcs development sources, it works if I compile with -O, and
  > fails without.
  > 
  > Without optimization, it is a calling convention problem.  We try to pass
  > a single precision complex to the function cabs1.0, which requires loading
  > two SFmode values.  We generate RTL to load them both into the same registe
  > r
  > and this code obviously doesn't work.
  > 
  > (insn 26 24 28 (set (reg:SF 4 a0)
  >         (mem/f:SF (reg:SI 77) 0)) -1 (nil)
  >     (nil))
  > 
  > (insn 28 26 30 (set (reg:SF 4 a0)
  >         (mem/f:SF (plus:SI (reg:SI 77)
  >                 (const_int 4 [0x4])) 0)) -1 (nil)
  >     (nil))
Ouch.

  > This has always been a problem with the complex support.  There was some
  > discussion last year about trying to fix this in the alpha port, but I 
don't
  > know what came of that.
I don't think it was ever resolved.  There's quite a few issues with this
stuff.

  > which emits two loads into the same register when x is a register big
  > enough to hold the entire complex value.  This code can work for registers
  > only if the register is equal to or smaller than one half the size of the
  > complex type.
  >
  > The single register was chosen by the mips FUNCTION_ARG macro.
Right.  Note that FUNCTION_ARG is always going to return a single register
for a complex value since we only call FUNCTION_ARG for the complex value as
a whole, not its subcomponents.

Similarly for FUNCTION_ARG_ADVANCE, FUNCTION_ARG_PARTIAL_NWORDS, etc etc.

This is somewhat contrary to how we treat complex stuff elsewhere -- ie, in
most other places we try to treat the real and imag part independently.  If
we followed that convention for arguments, then we would want to treat 
an SCmode parameter as two independent SFmode parameters.


  > The problem can probably be fixed in either area.  It isn't clear which is
  > best.  We need to make sure that we emit correct ABI compliant code for
  > this case which may constrain the possible solutions.
I think we should be splitting up the complex stuff into independent
parameters (assuming no external constraint which requires us to treat it as
a single parameter).

Consider an SCmode argument on a machine which passes FP args in FP regs and
has 64bit wide FP regs.  Do we pack the two halfs of the SCmode argument into
the upper and lower half of a 64bit FP register?  I hope not, that's a major
pain.

If we agree that we should not be "packing", then the question becomes do we
split up the SCmode parameter before calling the FUNCTION_* macros.

If we do not split it up, then all the targets which define FUNCTION_* macros
will need to be updated since most assume that if you have an argument of N
bits that it is a single argument of N bits, not two independent arguments of
N/2 bits.  ie, we have to teach the FUNCTION_* macros that an SCmode parameter
may actually take up 2 64bit FP regs in the example cited above, even though an
SCmode is only 64bits wide.

I'm leery of trying to get either change into the release branch this late in
the game.  As painful as it may be, I suspect we may be better off using
-femulate-complex for gcc-2.95.



jeff