[Bug c++/31780] New: [4.3 regression] ICE with incompatible types for ?:

[Bug c++/31780] New: [4.3 regression] ICE with incompatible types for ?:

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE on mainline:

===========================================
bool foo();

void bar()
{
  __builtin_expect(foo(), 1) ? 0i : 0;
}
===========================================

bug.cc: In function 'void bar()':
bug.cc:5: error: could not convert '0' to 'int __complex__'
bug.cc:5: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in tree_ssa_useless_type_conversion_1, at
tree-ssa.c:900
Please submit a full bug report, [etc.]


-- 
           Summary: [4.3 regression] ICE with incompatible types for ?:
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Keywords: ice-on-invalid-code, error-recovery, monitored
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c++/31780] [4.3 regression] ICE with incompatible types for ?:

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.3.0


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2007-05-02 01:46 -------
> bug.cc:5: error: could not convert '0' to 'int __complex__'

Actually it should be able to convert that and I think this is the same reason
why we are rejecting PR 30209.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
           Keywords|error-recovery, ice-on-     |ice-on-valid-code
                   |invalid-code                |
            Summary|[4.3 regression] ICE with   |[4.3 regression] ICE with
                   |incompatible types for ?:   |incompatible types for ?:
                   |                            |with "complex type"
                   |                            |conversion


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2007-05-02 01:47 -------
Also I think this was caused by PR 31338.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |30209
OtherBugsDependingO|                            |31338
              nThis|                            |


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

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

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


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

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

[reichelt at gcc dot gnu dot org]

------- Comment #3 from reichelt at gcc dot gnu dot org  2007-07-07 10:47 -------
The ICE is now also present on the 4.2 branch.
Most likely caused by the patch for PR 31338.


-- 

reichelt at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at codesourcery dot com
            Summary|[4.3 regression] ICE with   |[4.2/4.3 regression] ICE
                   |incompatible types for ?:   |with incompatible types for
                   |with "complex type"         |?: with "complex type"
                   |conversion                  |conversion
   Target Milestone|4.3.0                       |4.2.1


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

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

[mmitchel at gcc dot gnu dot org]

------- Comment #4 from mmitchel at gcc dot gnu dot org  2007-07-07 19:26 -------
The ICE is occurring in the gimplifier; it appears not to handle expressions
with type error_mark_node.  Either we should not gimplify anything after an
error occurs, or it must be made more robust.

I'm thinking about whether or not the error itself is valid.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |mmitchel at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-07-07 19:26:39
               date|                            |


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

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

[mmitchel at gcc dot gnu dot org]

------- Comment #5 from mmitchel at gcc dot gnu dot org  2007-07-07 19:35 -------
I do think that the error is bogus.


-- 


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

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

[mmitchel at gcc dot gnu dot org]

------- Comment #6 from mmitchel at gcc dot gnu dot org  2007-07-07 22:12 -------
Created an attachment (id=13867)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13867&action=view)
Patch


-- 


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

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

[mmitchel at gcc dot gnu dot org]

------- Comment #7 from mmitchel at gcc dot gnu dot org  2007-07-07 22:21 -------
I've attached a patch which fixes this bug in an obvious way.

Since complex types are arithmetic types in GNU C++, we should allow standard
conversions to them from integers, just as we do for all other arithmetic
types.

However, this runs into problems with libstdc++.  In particular,
std::complex<double> has a constructor from double and also a constructor from
__complex__ double.  Making the change in this patch makes that conversion
ambiguous because now "std::complex<double>(1)" can go via either the
"__complex__ double" constructor or the plain "double" constructor.

I'm pretty sure that we did indeed discuss this at some point in the past,
although I couldn't find a link and I don't remember what we decided, if
anything.  

The easiest way to fix this is probably to add more constructors to
std::complex<double> to match all of the arithmetic types directly, e.g., add
"std::complex<double>::complex(int, int = 0)".  Then, that will be the best
match. 

I think we need input from the libstdc++ maintainers before trying to do
anything in the front end.  Paolo?


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pcarlini at suse dot de
             Status|ASSIGNED                    |WAITING


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

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

[pcarlini at suse dot de]

------- Comment #8 from pcarlini at suse dot de  2007-07-07 22:44 -------
Hi Mark. First, I can point you to C++/21210. In that occasion (see in
particular Comment #3) we struggled with the issue quite a bit (if I remember
correctly we tried to avoid adding constructors...) then you came up with a
"magic" very simple solution! While I study a bit more the present issue maybe
you can re-focus that old one... (thanks for involving libstdc++ this time too)


-- 


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

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

[mark at codesourcery dot com]

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

pcarlini at suse dot de wrote:
> ------- Comment #8 from pcarlini at suse dot de  2007-07-07 22:44 -------
> Hi Mark. First, I can point you to C++/21210. In that occasion (see in
> particular Comment #3) we struggled with the issue quite a bit (if I remember
> correctly we tried to avoid adding constructors...) then you came up with a
> "magic" very simple solution! While I study a bit more the present issue maybe
> you can re-focus that old one... (thanks for involving libstdc++ this time too)

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?

Thanks,


-- 


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

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

[pcarlini at suse dot de]

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


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|21210                       |


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

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

[mark at codesourcery dot com]

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

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

[pcarlini at suse dot de]

------- Comment #12 from pcarlini at suse dot de  2007-07-08 18:42 -------
(In reply to comment #11)
> I was confused by your crediting me with magic because it was Roger
> Sayle who fixed the bug.

Ah! Curious, he doesn't work on the C++ front-end very often...

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

What can I say... Gaby designed the complex class that way, those special
constructors included. If we cannot avoid adding more constructors, so be it,
but of course please make sure Gaby agrees.


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
   Last reconfirmed|2007-07-07 19:26:39         |2007-07-08 18:42:04
               date|                            |


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

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

[mmitchel at gcc dot gnu dot org]

------- Comment #13 from mmitchel at gcc dot gnu dot org  2007-07-08 18:58 -------
Gaby --

Paolo and I would like your input on this issue, please.

Thanks,

-- Mark


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gdr at integrable-solutions
                   |                            |dot net
             Status|NEW                         |WAITING


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

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

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.2.1                       |4.2.2


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

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

[mmitchel at gcc dot gnu dot org]

------- Comment #14 from mmitchel at gcc dot gnu dot org  2007-10-09 19:20 -------
Change target milestone to 4.2.3, as 4.2.2 has been released.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.2.2                       |4.2.3


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

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

[steven at gcc dot gnu dot org]

------- Comment #15 from steven at gcc dot gnu dot org  2007-12-16 23:26 -------
P1 regression and >2.5 months without activity.

PING!


-- 


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

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

[mmitchel at gcc dot gnu dot org]

------- Comment #16 from mmitchel at gcc dot gnu dot org  2007-12-18 05:36 -------
We need input from a libstdc++ maintainer.  Gaby was invited to comment, but
there's no comment from him in this PR.  Paolo, do you have any further
thoughts?


-- 


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

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

[gdr at gcc dot gnu dot org]

------- Comment #17 from gdr at gcc dot gnu dot org  2007-12-23 21:22 -------
(In reply to comment #13)
> Gaby --
> 
> Paolo and I would like your input on this issue, please.
> 
> Thanks,
> 
> -- Mark
> 

Sorry for replying late -- this issue escaped by attention; Paolo
kindly sent me a private reminder.

The std::complex<double> constructor taking a __complex__ double exists
primarily so that we can have a simple implementation of std::complex<double>
that is both compatible with C99 _Complex and the GNU extension __complex__,
and beneficiary of the existing machinery supporting that datatype.
I believe that is a plus we all agree we should keep.

I'm very nervous about adding more constructors.
I'd rather distinguish the constructor taking __complex__ by adding
a dummy parameter:

   enum _DummyArg { };
   complex(__complex__ double __z, _DummyArg);


-- 


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

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

[mark at codesourcery dot com]

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

gdr at gcc dot gnu dot org wrote:

> I'm very nervous about adding more constructors.
> I'd rather distinguish the constructor taking __complex__ by adding
> a dummy parameter:
> 
>    enum _DummyArg { };
>    complex(__complex__ double __z, _DummyArg);

That will, however, break backwards compatibility for user programs (if
any) relying on the constructor.


-- 


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

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

[pcarlini at suse dot de]

------- Comment #19 from pcarlini at suse dot de  2007-12-26 22:02 -------
Also, I'm afraid the implementation of parts of <complex> (the transcendental
functions) may become much uglier, humpf...


-- 


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

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

[gdr at cs dot tamu dot edu]

------- Comment #20 from gdr at cs dot tamu dot edu  2008-01-05 07:51 -------
Subject: Re:  [4.2/4.3 regression] ICE with incompatible types for ?: with
"complex type" conversion

"mark at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Comment #18 from mark at codesourcery dot com  2007-12-26 21:19
-------
| Subject: Re:  [4.2/4.3 regression] ICE with incompatible types
|  for ?: with "complex type" conversion
| 
| gdr at gcc dot gnu dot org wrote:
| 
| > I'm very nervous about adding more constructors.
| > I'd rather distinguish the constructor taking __complex__ by adding
| > a dummy parameter:
| > 
| >    enum _DummyArg { };
| >    complex(__complex__ double __z, _DummyArg);
| 
| That will, however, break backwards compatibility for user programs (if
| any) relying on the constructor.

That isn't a concern because I never published that constructor as a
contract in the interface of std::complex<double>.

-- Gaby


-- 


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

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

[gdr at cs dot tamu dot edu]

------- Comment #21 from gdr at cs dot tamu dot edu  2008-01-05 07:51 -------
Subject: Re:  [4.2/4.3 regression] ICE with incompatible types for ?: with
"complex type" conversion

"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:

| Also, I'm afraid the implementation of parts of <complex> (the transcendental
| functions) may become much uglier, humpf...

I'm not sure what you mean; please could you clarify?

-- Gaby


-- 


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

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

[mark at codesourcery dot com]

------- Comment #22 from mark at codesourcery dot com  2008-01-05 07:55 -------
Subject: Re:  [4.2/4.3 regression] ICE with incompatible types
 for ?: with "complex type" conversion

gdr at cs dot tamu dot edu wrote:

> | > I'd rather distinguish the constructor taking __complex__ by adding
> | > a dummy parameter:
> | > 
> | >    enum _DummyArg { };
> | >    complex(__complex__ double __z, _DummyArg);
> | 
> | That will, however, break backwards compatibility for user programs (if
> | any) relying on the constructor.
> 
> That isn't a concern because I never published that constructor as a
> contract in the interface of std::complex<double>.

I'm not sure what you mean by that.  It's a public constructor; how do
we know that there aren't users out there using it?  How would they have
known that they weren't supposed to use it?


-- 


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

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

[gdr at cs dot tamu dot edu]

------- Comment #23 from gdr at cs dot tamu dot edu  2008-01-06 15:28 -------
Subject: Re:  [4.2/4.3 regression] ICE with incompatible types for ?: with
"complex type" conversion

"mark at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| Subject: Re:  [4.2/4.3 regression] ICE with incompatible types
|  for ?: with "complex type" conversion
| 
| gdr at cs dot tamu dot edu wrote:
| 
| > | > I'd rather distinguish the constructor taking __complex__ by adding
| > | > a dummy parameter:
| > | > 
| > | >    enum _DummyArg { };
| > | >    complex(__complex__ double __z, _DummyArg);
| > | 
| > | That will, however, break backwards compatibility for user programs (if
| > | any) relying on the constructor.
| > 
| > That isn't a concern because I never published that constructor as a
| > contract in the interface of std::complex<double>.
| 
| I'm not sure what you mean by that.  It's a public constructor;

I mean that it is not a standard constructor, and it is not a
constructor I documented as a GNU extension.  The fact that it is a
public constructor is not, by itself, a documentation that it is a
standard constructor or a constructor that users should use.

-- Gaby


-- 


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

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

[mark at codesourcery dot com]

------- Comment #24 from mark at codesourcery dot com  2008-01-06 21:06 -------
Subject: Re:  [4.2/4.3 regression] ICE with incompatible types
 for ?: with "complex type" conversion

gdr at cs dot tamu dot edu wrote:

> | I'm not sure what you mean by that.  It's a public constructor;
> 
> I mean that it is not a standard constructor, and it is not a
> constructor I documented as a GNU extension.  The fact that it is a
> public constructor is not, by itself, a documentation that it is a
> standard constructor or a constructor that users should use.

But, it's also not documentation that users should *not* use it.  And,
now it's been out there for a long time, so it's quite likely that some
users somewhere *are* using it.  The run-time library has various
extensions to the standard, and the way people use a run-time library is
partly to open its header files and use what they see.  I think we have
to accept that this is indeed an incompatible change and likely to
affect users.

That said, I do think it's reasonable to break backwards compatibility
here if we have no other choice.  Right now, we have this odd wart in
the language with our handling of __complex__ (treating is as a
non-artithmetic type) which causes other problems.  So, it's possible
that we have to choose between making an incompatible change to the
library and leaving the language wart -- and I think we're all agreed
that in that case we'd rather add the dummy parameter you suggest.

But, you've not shown that my suggestion of adding additional
constructors is detectable by users.  If it's not, then that would be a
better solution: it would allow us to avoid the incompatible change to
the library.  Of course, if adding constructors itself breaks
compatibility, then that's a powerful argument against my suggestion.
So far, all you've said is that it makes you nervous.  Does it actually
break something?


-- 


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

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

[gdr at cs dot tamu dot edu]

------- Comment #25 from gdr at cs dot tamu dot edu  2008-01-07 00:38 -------
Subject: Re:  [4.2/4.3 regression] ICE with incompatible types for ?: with
"complex type" conversion

"mark at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| Subject: Re:  [4.2/4.3 regression] ICE with incompatible types
|  for ?: with "complex type" conversion
| 
| gdr at cs dot tamu dot edu wrote:
| 
| > | I'm not sure what you mean by that.  It's a public constructor;
| > 
| > I mean that it is not a standard constructor, and it is not a
| > constructor I documented as a GNU extension.  The fact that it is a
| > public constructor is not, by itself, a documentation that it is a
| > standard constructor or a constructor that users should use.
| 
| But, it's also not documentation that users should *not* use it.  And,
| now it's been out there for a long time, so it's quite likely that some
| users somewhere *are* using it.

I would not bet money that nobody is not using it.  However, that
somebody is using something specifically non-standard and NOT
documented GNU extension.  

This situatiation is radically very different from the one where the
constructor would have been documented as GNU extension -- then we
would be stuck with it, and I would have been pressed hard to suggest
what I'm suggesting.

[...]

| But, you've not shown that my suggestion of adding additional
| constructors is detectable by users.

It is adding more constructors where the standard says none existed.

We have no plan of how those new constructors will interact with
future new additions.  Consequently, I'm very reluctant adding those
constructors -- after all, these new single-parameter constructors are
being suggested because of an ambiguity caused by adding a single-parameter
constructor that did not exist (in the Standard) in the first place.  I 
would not like to continue that road by adding more, just to fix a mess
caused by this constructor and the compiler's handling of __complex__.
This isn't a case where I'm ready to say `the more the merrier' :-)

Adding an additional dummy parameter to the constructor __complex__
significantly reduces (to zero), the risk of conflict with anything
unforseen now.  I believe that is what we should do.

-- Gaby


-- 


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

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

[mark at codesourcery dot com]

------- Comment #26 from mark at codesourcery dot com  2008-01-07 01:16 -------
Subject: Re:  [4.2/4.3 regression] ICE with incompatible types
 for ?: with "complex type" conversion

gdr at cs dot tamu dot edu wrote:

> I would not bet money that nobody is not using it.  However, that
> somebody is using something specifically non-standard and NOT
> documented GNU extension.  
> 
> This situatiation is radically very different from the one where the
> constructor would have been documented as GNU extension 

It isn't different to the user.  This isn't quite the same situation as
fixing an accepts-invalid bug in the front end.  There, a user had no
reason at all to expect the code to be valid, and the only way to make
the compiler conform to the requirement to emit a diagnostic is to
reject the code -- or at least give a warning about it.  And I'd prefer
to warn rather than error where practical.

Imagine that you're a user.  You read about GNU __complex__ types in the
manual.  You write some code with them.  Then, you want to call some C++
functions that expect std::complex.  You look at the libstdc++ source
code, notice a constructor there that does what you want, and use it.
You upgrade to a new version of G++ and your code breaks.  I'm sure you
agree that this doesn't make you happy.

So, let's not try to argue that changing the constructor signature is
painless.  Instead, let's decide whether that's a better or worse
solution than adding more constructors.  As I said previously, if adding
more constructors is going to break something, then I agree that it's bad.

> We have no plan of how those new constructors will interact with
> future new additions.  Consequently, I'm very reluctant adding those
> constructors -- after all, these new single-parameter constructors are
> being suggested because of an ambiguity caused by adding a single-parameter
> constructor that did not exist (in the Standard) in the first place.

I don't understand this argument.  Do you mean a future addition to the
ISO C++ standard or to the GNU C++ library?  We control the latter, so
that doesn't seem like a problem.

Is it conceivable that ISO C++ will ever add a
complex<double>::complex(int) constructor that doesn't set the real part
to the value of the argument (converted to double), and the imaginary
part to zero?  I'm not involved in the standards process at this point,
but that would be amazing to me, both since that would change the
meaning of:

  complex<double>(3)

and since it would not conform to the usual mathematical notions of
projections of integers onto the complex plane.

What is the concern that you have?


-- 


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

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

[gdr at cs dot tamu dot edu]

------- Comment #28 from gdr at cs dot tamu dot edu  2008-01-07 06:57 -------
Subject: Re:  [4.2/4.3 regression] ICE with incompatible types for ?: with
"complex type" conversion

"mark at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| Imagine that you're a user.  You read about GNU __complex__ types in the
| manual.  You write some code with them.  Then, you want to call some C++
| functions that expect std::complex.  You look at the libstdc++ source
| code, notice a constructor there that does what you want, and use it.
| You upgrade to a new version of G++ and your code breaks.  I'm sure you
| agree that this doesn't make you happy.

But, as that hypothetical user, I would not have any ground to be unhappy.
After all, it was code based on unfounded extrapolations.

-- Gaby


-- 


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

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

[gdr at cs dot tamu dot edu]

------- Comment #29 from gdr at cs dot tamu dot edu  2008-01-07 07:09 -------
Subject: Re:  [4.2/4.3 regression] ICE with incompatible types for ?: with
"complex type" conversion

"mark at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| > We have no plan of how those new constructors will interact with
| > future new additions.  Consequently, I'm very reluctant adding those
| > constructors -- after all, these new single-parameter constructors are
| > being suggested because of an ambiguity caused by adding a single-parameter
| > constructor that did not exist (in the Standard) in the first place.
| 
| I don't understand this argument.  Do you mean a future addition to the
| ISO C++ standard or to the GNU C++ library? 

ISO C++.

| Is it conceivable that ISO C++ will ever add a
| complex<double>::complex(int) constructor that doesn't set the real part
| to the value of the argument (converted to double), and the imaginary
| part to zero? 

That isn't the issue.  My concern is whether ISO C++ will ever
change conversion rules, say from integers to floats or doubles.  The
answer is likely. 

-- Gaby


-- 


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

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

[gdr at cs dot tamu dot edu]

------- Comment #27 from gdr at cs dot tamu dot edu  2008-01-07 06:54 -------
Subject: Re:  [4.2/4.3 regression] ICE with incompatible types for ?: with
"complex type" conversion

"mark at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Comment #26 from mark at codesourcery dot com  2008-01-07 01:16
-------
| Subject: Re:  [4.2/4.3 regression] ICE with incompatible types
|  for ?: with "complex type" conversion
| 
| gdr at cs dot tamu dot edu wrote:
| 
| > I would not bet money that nobody is not using it.  However, that
| > somebody is using something specifically non-standard and NOT
| > documented GNU extension.  
| > 
| > This situatiation is radically very different from the one where the
| > constructor would have been documented as GNU extension 
| 
| It isn't different to the user.

Surely it is.  If it a documented GNU extension, then it is a promise we
must keep.  If it a standard constructor, then we don't have the choice.

-- Gaby


-- 


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

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

[mark at codesourcery dot com]

------- Comment #30 from mark at codesourcery dot com  2008-01-07 07:44 -------
Subject: Re:  [4.2/4.3 regression] ICE with incompatible types
 for ?: with "complex type" conversion

gdr at cs dot tamu dot edu wrote:

> | Is it conceivable that ISO C++ will ever add a
> | complex<double>::complex(int) constructor that doesn't set the real part
> | to the value of the argument (converted to double), and the imaginary
> | part to zero? 
> 
> That isn't the issue.  My concern is whether ISO C++ will ever
> change conversion rules, say from integers to floats or doubles.  The
> answer is likely. 

What's the likely change?


-- 


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

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

[mark at codesourcery dot com]

------- Comment #31 from mark at codesourcery dot com  2008-01-07 07:48 -------
Subject: Re:  [4.2/4.3 regression] ICE with incompatible types
 for ?: with "complex type" conversion

gdr at cs dot tamu dot edu wrote:

> But, as that hypothetical user, I would not have any ground to be unhappy.
> After all, it was code based on unfounded extrapolations.

I think this is a mistake.   Our documentation has never been good
enough for people to rely on the absence of documentation as meaningful.
 One of the most frequent complaints I get about GCC is that we break
existing code with every release.  Apparently, we do this much more
often than other other compilers.

You're clearly not going to agree with me.  So be it.

Please ask your fellow libstdc++ maintainers what they think.


-- 


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

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

[gdr at cs dot tamu dot edu]

------- Comment #33 from gdr at cs dot tamu dot edu  2008-01-07 08:10 -------
Subject: Re:  [4.2/4.3 regression] ICE with incompatible types for ?: with
"complex type" conversion

"mark at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| Subject: Re:  [4.2/4.3 regression] ICE with incompatible types
|  for ?: with "complex type" conversion
| 
| gdr at cs dot tamu dot edu wrote:
| 
| > | Is it conceivable that ISO C++ will ever add a
| > | complex<double>::complex(int) constructor that doesn't set the real part
| > | to the value of the argument (converted to double), and the imaginary
| > | part to zero? 
| > 
| > That isn't the issue.  My concern is whether ISO C++ will ever
| > change conversion rules, say from integers to floats or doubles.  The
| > answer is likely. 
| 
| What's the likely change?

Ban implicit narrowing conversions, in the sense that a round trip will not
give the same value back.  The exact rules are in flux (there was a
specification discussed at the last Kona meeting, but it got changed
based on feedback, and may likely change from now to Sophia Antipolis
meeting).  However, the general idea meets consensus.

-- Gaby


-- 


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

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

[gdr at cs dot tamu dot edu]

------- Comment #32 from gdr at cs dot tamu dot edu  2008-01-07 08:00 -------
Subject: Re:  [4.2/4.3 regression] ICE with incompatible types for ?: with
"complex type" conversion

"mark at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Comment #31 from mark at codesourcery dot com  2008-01-07 07:48
-------
| Subject: Re:  [4.2/4.3 regression] ICE with incompatible types
|  for ?: with "complex type" conversion
| 
| gdr at cs dot tamu dot edu wrote:
| 
| > But, as that hypothetical user, I would not have any ground to be unhappy.
| > After all, it was code based on unfounded extrapolations.
| 
| I think this is a mistake.

The real mistake was when I make that constructor unary.  It was a
terrible mistake.  And I apologize for that.

The fix isn't to build more brittle tower on top of it in the name of
hypothetical codes written with unfounded assumptions. 

[...]

|  One of the most frequent complaints I get about GCC is that we break
| existing code with every release.

I get that complain too.  But only for documented features.

-- Gaby


-- 


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

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

[mark at codesourcery dot com]

------- Comment #34 from mark at codesourcery dot com  2008-01-07 16:17 -------
Subject: Re:  [4.2/4.3 regression] ICE with incompatible types
 for ?: with "complex type" conversion

gdr at cs dot tamu dot edu wrote:

> | What's the likely change?
> 
> Ban implicit narrowing conversions, in the sense that a round trip will not
> give the same value back. 

Which direction is narrowing, between "int" and "float"?  (Both have
values unrepresentable in the other, of course.)  Would you please give
an example of how this change, together with the new constructors, would
make some program behave differently than the standard says it should?


-- 


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

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

[gdr at cs dot tamu dot edu]

------- Comment #35 from gdr at cs dot tamu dot edu  2008-01-08 02:52 -------
Subject: Re:  [4.2/4.3 regression] ICE with incompatible types for ?: with
"complex type" conversion

"mark at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Comment #34 from mark at codesourcery dot com  2008-01-07 16:17
-------
| Subject: Re:  [4.2/4.3 regression] ICE with incompatible types
|  for ?: with "complex type" conversion
| 
| gdr at cs dot tamu dot edu wrote:
| 
| > | What's the likely change?
| > 
| > Ban implicit narrowing conversions, in the sense that a round trip will not
| > give the same value back. 
| 
| Which direction is narrowing, between "int" and "float"?

The rule is not just based on 'type'; if the source  value is a
constant, then the implementation determine whether a round trip is
OK.  Otherwise, it uses 'just' the type rule (for safe approximation).

furthermore, based on feedback from Koan meeting, it is also
proposed that narrowing should not cross integer-float barrier. 

|  (Both have
| values unrepresentable in the other, of course.)  Would you please give
| an example of how this change, together with the new constructors, would
| make some program behave differently than the standard says it should?

Please see the details in the proposal put foward by BS, me, and JSA titled
`initializer list' (post Toronto meeting), and the recent `rationale'
paper by BS in the mid-term mailing.  Look for the section or word `narrowing'.

(I'm currently in a location in san francisco where the nhe flakky
network connection does not ease extended mail).

-- Gaby


-- 


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

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

[mark at codesourcery dot com]

------- Comment #36 from mark at codesourcery dot com  2008-01-08 03:39 -------
Subject: Re:  [4.2/4.3 regression] ICE with incompatible types
 for ?: with "complex type" conversion

gdr at cs dot tamu dot edu wrote:

> |  (Both have
> | values unrepresentable in the other, of course.)  Would you please give
> | an example of how this change, together with the new constructors, would
> | make some program behave differently than the standard says it should?
> 
> Please see the details in the proposal put foward by BS, me, and JSA titled
> `initializer list' (post Toronto meeting), and the recent `rationale'
> paper by BS in the mid-term mailing.  Look for the section or word `narrowing'.

I don't know where to find those things, unfortunately.  Do you have a URL?

Would you please provide an example of how:

  complex<float> {
    Complex (int i) : real_(i) {};
    Complex (float f): real_f() {};

    float real_;
    float imag_;
  };

would be different than just:

  complex<float> {
    Complex (float f): real_f() {};

    float real_;
    float imag_;
  };

when passed an "int"?  I'm having a hard time seeing how making the
conversion in the constructor would be different than making it at the
call site, whether or not the argument is a constant.


-- 


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

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

[jason at gcc dot gnu dot org]

------- Comment #37 from jason at gcc dot gnu dot org  2008-01-22 15:37 -------
(In reply to comment #7)
> Since complex types are arithmetic types in GNU C++, we should allow standard
> conversions to them from integers, just as we do for all other arithmetic
> types.
> 
> However, this runs into problems with libstdc++.  In particular,
> std::complex<double> has a constructor from double and also a constructor from
> __complex__ double.  Making the change in this patch makes that conversion
> ambiguous because now "std::complex<double>(1)" can go via either the
> "__complex__ double" constructor or the plain "double" constructor.

It seems clear to me that conversion to complex should be worse than conversion
to another scalar arithmetic type.  I would implement this in hypothetical
standardese by defining "complex conversions" for the conversion from scalar to
complex, and the term "scalar arithmetic conversions" for integer, float and
integer-float conversions, then adding to 13.3.3.2p3 an additional rule that S1
is better than S2 if S1 is a scalar arithmetic conversion and S2 is a complex
conversion.

I think this approach would avoid the need for extra constructors.


-- 


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

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

[mark at codesourcery dot com]

------- Comment #38 from mark at codesourcery dot com  2008-01-22 17:47 -------
Subject: Re:  [4.2/4.3 regression] ICE with incompatible types
 for ?: with "complex type" conversion

jason at gcc dot gnu dot org wrote:

>> However, this runs into problems with libstdc++.  In particular,
>> std::complex<double> has a constructor from double and also a constructor from
>> __complex__ double.  Making the change in this patch makes that conversion
>> ambiguous because now "std::complex<double>(1)" can go via either the
>> "__complex__ double" constructor or the plain "double" constructor.
> 
> It seems clear to me that conversion to complex should be worse than conversion
> to another scalar arithmetic type.  I would implement this in hypothetical
> standardese by defining "complex conversions" for the conversion from scalar to
> complex, and the term "scalar arithmetic conversions" for integer, float and
> integer-float conversions, then adding to 13.3.3.2p3 an additional rule that S1
> is better than S2 if S1 is a scalar arithmetic conversion and S2 is a complex
> conversion.

Yes, that would probably work.  I would prefer to avoid a whole new
class of conversions, and it doesn't seem necessary to me, since I still
don't understand what Gaby is worried about.  But, it does seem like a
technically feasible solution if absolutely necessary.


-- 


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #39 from rguenth at gcc dot gnu dot org  2008-01-25 15:46 -------
Jason, can you coordinate with Mark and help with the remaining P1 C++
regressions?


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu dot org
             Status|WAITING                     |NEW
   Last reconfirmed|2007-07-08 18:42:04         |2008-01-25 15:46:04
               date|                            |


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

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

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|mmitchel at gcc dot gnu dot |jason at gcc dot gnu dot org
                   |org                         |
             Status|NEW                         |ASSIGNED


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

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

[jason at gcc dot gnu dot org]

------- Comment #40 from jason at gcc dot gnu dot org  2008-01-25 19:45 -------
Subject: Bug 31780

Author: jason
Date: Fri Jan 25 19:45:11 2008
New Revision: 131832

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131832
Log:
        PR c++/31780
        * call.c (standard_conversion): Allow conversion from integer/real
        to complex.
        (compare_ics): Such a conversion is worse than a normal arithmetic
        conversion.

Added:
    trunk/gcc/testsuite/g++.dg/ext/complex3.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/call.c


-- 


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

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

[jason at gcc dot gnu dot org]

------- Comment #41 from jason at gcc dot gnu dot org  2008-01-25 19:51 -------
Fixed for 4.3.0, not worth fixing on 4.2 branch.


-- 

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
            Summary|[4.2/4.3 regression] ICE    |[4.2 regression] ICE with
                   |with incompatible types for |incompatible types for ?:
                   |?: with "complex type"      |with "complex type"
                   |conversion                  |conversion
   Target Milestone|4.2.3                       |4.3.0


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