[Bug middle-end/37850] infinite recursive call to __mulsc3 when multiplying not-constant complexs

["joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #8 from joseph at codesourcery dot com  2008-10-18 18:06 -------
Subject: Re:  infinite recursive call to __mulsc3 when
 multiplying not-constant complexs

On Sat, 18 Oct 2008, rguenth at gcc dot gnu dot org wrote:

> The question is whether the standard requires actual complex multiplication
> carried out for y * I, as it seems to allow an imaginary type used for I
> as well.
> 
> A probably better writing of the return statement is
> 
>   CTYPE res;
>   __real res = x;
>   __imag res = y;
>   return res;
> 
> which should be valid, as the NaN cases are checked earlier.

The above is indeed a better representation of the return statement to 
avoid problems with NaNs, infinities and negative zero.

GCC does not implement imaginary types.  Nor do other compilers; no-one on 
the Power ABI working group had a Power architecture compiler supporting 
_Imaginary so we didn't include _Imaginary in the ABI draft (it has ABI 
implications for how you pass and return _Imaginary values, and the answer 
is not generally an obvious "like real values" given that float _Imaginary 
is not promoted to double _Imaginary when passed to variadic functions, so 
you have to deal with the case of float _Imaginary in variable arguments 
when doesn't arise for float).

Given that imaginary types are not used, multiplication by I is 
multiplication by (0.0 + 1.0i).  However, multiplying real y by (0.0 + 
1.0i) is not multiplying (y + 0.0i) by (0.0 + 1.0i); this is bug 24581.  
GCC does not implement the standard requirement that the operands of mixed 
real/complex arithmetic have a common real type found but without 
converting real operands to complex types (so float + double _Complex has 
the float argument converted to double not _Complex double, double + float 
_Complex has the float _Complex argument converted to double _Complex 
without changing the double argument).  The spurious conversions to 
complex types give additional opportunities for problems with NaNs, 
infinities and negative zero to arise.

That standard requirement should be reasonably straightforward to 
implement in the front end for all cases except division of a real value 
by a complex one.  Annex G doesn't suggest any particular requirements for 
real/complex division that would go wrong if the real number is converted 
to complex in that case so it may be appropriate to keep doing so in the 
front end.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37850