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