[Bug c++/28501] ICE with __real__ and implicit type conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28501 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|mark at codesourcery dot|jason at gcc dot gnu.org, |com, mmitchel at gcc dot|paolo.carlini at oracle dot |gnu.org |com Known to fail|| --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-03 15:48:01 UTC --- Hi Jason. A small issue which I fixed a few days ago reminded me this one, pretty old, on which I worked a bit two years ago, then left alone... At the time I figured out the below patchlet, which still avoids the ICE, passes the testsuite, and apparently provides a sensible semantics (eg, if the operator returns 1, i is initialized to 1; if the testcase is tweaked to use __imag__, i is initialized to 0). What do you think? Or shall we just reject the snippet? Index: call.c === --- call.c (revision 173309) +++ call.c (working copy) @@ -2586,6 +2586,12 @@ add_builtin_candidate (struct z_candidate **candid types are TYPE2. */ break; +case REALPART_EXPR: +case IMAGPART_EXPR: + if (ARITHMETIC_TYPE_P (type1)) + break; + return; + default: gcc_unreachable (); }
[Bug c++/28501] ICE with __real__ and implicit type conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28501 --- Comment #8 from Jason Merrill jason at gcc dot gnu.org 2011-05-03 17:32:43 UTC --- That patch looks fine to me.
[Bug c++/28501] ICE with __real__ and implicit type conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28501 --- Comment #9 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-05-03 18:30:41 UTC --- Author: paolo Date: Tue May 3 18:30:37 2011 New Revision: 173337 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173337 Log: /cp 2011-05-03 Paolo Carlini paolo.carl...@oracle.com PR c++/28501 * call.c (add_builtin_candidate): Handle REALPART_EXPR and IMAGPART_EXPR. /testsuite 2011-05-03 Paolo Carlini paolo.carl...@oracle.com PR c++/28501 * g++.dg/ext/complex9.C: New. Added: trunk/gcc/testsuite/g++.dg/ext/complex9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog
[Bug c++/28501] ICE with __real__ and implicit type conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28501 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED CC|paolo.carlini at oracle dot | |com | Resolution||FIXED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.7.0 --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-03 18:33:32 UTC --- Thanks. Committed.
[Bug c++/28501] ICE with __real__ and implicit type conversion
--- Comment #6 from paolo dot carlini at oracle dot com 2009-11-13 02:35 --- Not seriously working on this, unassigning (for now at least) -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu |dot com |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28501
[Bug c++/28501] ICE with __real__ and implicit type conversion
--- Comment #5 from mmitchel at gcc dot gnu dot org 2009-02-08 20:53
---
Paolo --
I didn't realize that something like __real__ 3 was valid GNU C; I thought
that the argument had to have complex type. But, it looks like that is not the
case.
Given that, yes, I think the test case should be accepted, as a GNU extension.
When __real__ (or __imag__) is applied to an expression with class type, we
should see if the expression can be converted to any of the built-in types to
which __real__ can ordinarily be applied. If there is only one such type, then
we should use that conversion; if there is more than one, then we should report
the same kind of error used when we have an ambiguous overload. I don't think
we should be trying to deduce anything from the context in which the __real__
expression is being used.
So, your patch looks like a fine start. I'm not sure what it will do for cases
like:
struct A {
operator int();
operator __complex__ double();
template typename T operator __complex__ T();
};
though. As above, I think those cases should be errors, since there's no way
to know which conversion operator to prefer.
-- Mark
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
CC||mmitchel at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28501
[Bug c++/28501] ICE with __real__ and implicit type conversion
--- Comment #4 from paolo dot carlini at oracle dot com 2009-02-07 11:11 --- Mark, can I have your opinion about this issue? I'm still thinking we could rather easily accept the code... Thanks in advance. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28501
[Bug c++/28501] ICE with __real__ and implicit type conversion
--- Comment #2 from paolo dot carlini at oracle dot com 2009-01-31 02:06 --- I don't think this is invalid, want to look a bit into it: I'm attaching a draft patch which makes sense to me, i.e. if a definition of the operator is provided, i is initialized to the correct value. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28501
[Bug c++/28501] ICE with __real__ and implicit type conversion
--- Comment #3 from paolo dot carlini at oracle dot com 2009-01-31 02:07 --- Created an attachment (id=17219) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17219action=view) draft I'm using as a starting point -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28501
[Bug c++/28501] ICE with __real__ and implicit type conversion
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-03 06:08 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||2.95.3 3.0.4 3.2.2 3.2.3 ||3.3.1 4.0.0 3.4.0 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-09-03 06:08:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28501
