[Bug c++/31780] [4.2/4.3 regression] ICE with incompatible types for ?: with "complex type" conversion

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

------- Comment #11 from mark at codesourcery dot com  2007-07-08 18:12 -------
Subject: Re:  [4.2/4.3 regression] ICE with incompatible types
 for ?: with "complex type" conversion

pcarlini at suse dot de wrote:
> ------- Comment #10 from pcarlini at suse dot de  2007-07-07 22:57 -------
> (In reply to comment #9)
>> Ah, thanks for finding the old PR.  In looking at the mail threads, I
>> fail to find my magic solution. :-(  Do you have a pointer to it?
> 
> Well, that PR is *closed as fixed*. Maybe at the time I didn't follow all the
> details and your eventual fix was only partial, in some sense? Certainly 21210
> is closed as fixed and we didn't add any constructor, contrary to some ideas
> temporarily envisaged in the discussion linked in Comment #3 therein.

I was confused by your crediting me with magic because it was Roger
Sayle who fixed the bug.  In any case, his fix was a specific hack for
converting zero to a complex type, not for the more general problem,
which has always remained unfixed.

I still think adding a few constructors is the best fix.  The only
situation where we have a problem is a class with constructors taking
both a type like "double" and a GNU __complex__ type.  GNU
__complex__types are very rare in C++ programs; people use std::complex
in C++, and there is no problem in that situation. :-)

So, libstdc++ is the rare case.  Changing the library will give us very
natural semantics in the front end; we just declare GNU __complex__ to
be an arithmetic type, and everything else follows.  Absent direction
from the ISO C++ committee regarding integration of C99 complex into
C++, that seems like the best we can do.


-- 


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