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/67221] [6 Regression] ICE at -Os and above on x86_64-linux-gnu: Segmentation fault (program cc1)


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67221

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ok, so we have

e_17 = e_3 + 1;

and e_3 value-numbers to e_17 (for some reason).  match-and-simplify then
recursively matches ((e_3 + 1) + 1) + 1 ...

Visiting BB 8
SCC consists of: e_3 e_17
Starting iteration 1
Value numbering e_3 stmt = e_3 = PHI <0(5), e_17(8)>
Setting value number of e_3 to c_2 (changed)
Value numbering e_17 stmt = e_17 = e_3 + 1;
Setting value number of e_17 to e_17 (changed)
Starting iteration 2
Value numbering e_3 stmt = e_3 = PHI <0(5), e_17(8)>
Setting value number of e_3 to e_17 (changed)

Oops.  This isn't supposed to happen.  Ok - so the only executable edge
is the backedge here (should have catched that block as unexecutable, sth
to fix as well).  Hmm, we only forbid a VARING -> non-VARYING lattice
transition, not a transition from one value to another.  Fishy.
Of course even with the old PHI value-numbering we should have arrived
at e_3 == e_17 and the very same problem (problem being using the backedge
value as "same val" and the entry edge not executable).

Value numbering e_17 stmt = e_17 = e_3 + 1;


So the workaround I am installing is to mark backedges into unreachable
blocks unexecutable as well.  Still the reason the def of e_17 is not
found unreachable is (again) in sub-optimal visiting order of the
DOM walk :(


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