This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/40464] [4.5 Regression] FAIL: g++.dg/torture/pr34099.C -O1 (internal compiler error) at -O1 and above
- From: "jamborm at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 4 Aug 2009 16:54:24 -0000
- Subject: [Bug tree-optimization/40464] [4.5 Regression] FAIL: g++.dg/torture/pr34099.C -O1 (internal compiler error) at -O1 and above
- References: <bug-40464-276@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #8 from jamborm at gcc dot gnu dot org 2009-08-04 16:54 -------
Right. The number in identifiers I see are different, of course, but
what happens is this. Early SRA replaces structure b.3 with
SR.4_25. In BB2, it is assigned into from parameter b:
SR.4_25 = b._M_value;
This assignment survives until complex lowering which expands it into:
SR.4$real_7 = REALPART_EXPR <b.3._M_value>;
SR.4$imag_1 = IMAGPART_EXPR <b.3._M_value>;
SR.4_25 = COMPLEX_EXPR <SR.4$real_7, SR.4$imag_1>;
Note that the b.3 is back, although it should have died long time
ago and that leads to the varasm ICE.
What is even more weird however, is how tree-complex.c comes upon that
variable. In extract_component() it correctly builds rhs
REALPART_EXPR <b._M_value> but then it feeds it into
force_gimple_operand_gsi() which in turns inserts the bogus statements
into the stream.
So that is where to look now, I suppose. I wonder how come the
behavior is target specific, though. Well, let me see.
--
jamborm at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2009-08-04 16:54:23
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40464