--- 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):
--- 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
--
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
--- 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
--- 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,
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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__
--- 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
--- 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)
--- 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.
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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?
--
--- 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
--- 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
--
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
--- 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
--- 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.
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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.
--- 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
40 matches
Mail list logo
