This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/40464] [4.5 Regression] FAIL: g++.dg/torture/pr34099.C -O1 (internal compiler error) at -O1 and above



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]