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