[Bug c++/31780] [4.2/4.3 regression] ICE with incompatible types for ?: with complex type conversion
--- 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=gccview=revrev=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/4.3 regression] ICE with incompatible types for ?: with complex type conversion
--- 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 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
--- 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::complexdouble 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::complexdouble(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
--- 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::complexdouble 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::complexdouble(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
--- 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 [EMAIL PROTECTED] 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
--- 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 [EMAIL PROTECTED] 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 | | complexdouble::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
--- 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
--- 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 [EMAIL PROTECTED] 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
--- 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:
complexfloat {
Complex (int i) : real_(i) {};
Complex (float f): real_f() {};
float real_;
float imag_;
};
would be different than just:
complexfloat {
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
--- 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 [EMAIL PROTECTED] 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::complexdouble.
|
| 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
--- 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
--- 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 [EMAIL PROTECTED] 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
--- 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 complexdouble::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: complexdouble(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
--- 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 [EMAIL PROTECTED] 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
--- 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 [EMAIL PROTECTED] 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
--- 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 [EMAIL PROTECTED] 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 | complexdouble::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
--- 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 | complexdouble::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
--- 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
--- 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 [EMAIL PROTECTED] 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::complexdouble.
-- 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
--- 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 [EMAIL PROTECTED] 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
--- 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::complexdouble.
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
--- 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
--- 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
--- 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::complexdouble constructor taking a __complex__ double exists
primarily so that we can have a simple implementation of std::complexdouble
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
--- 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
--- 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
--- 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
-- 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
--- 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
--- 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
--- 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
--- 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
--- 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|-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
--- 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
--- 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=13867action=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
--- 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::complexdouble 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::complexdouble(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::complexdouble to match all of the arithmetic types directly, e.g., add std::complexdouble::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
--- 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
--- 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
--- 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
