Compiling the attached class file with -O results is: $ gcj -findirect-dispatch -O -c CppTreeParser.class Unable to coalesce ssa_names 7 and 8642 which are marked as MUST COALESCE. _t_7(ab) and _t_8642(ab) frysk/expr/CppTreeParser.java: In class 'frysk.expr.CppTreeParser': frysk/expr/CppTreeParser.java: In method 'frysk.expr.CppTreeParser.expr(antlr.collections.AST)': frysk/expr/CppTreeParser.java:0: internal compiler error: SSA corruption This only happens with -O. It compiles fine with 4.1.1.
Created attachment 12965 [details] Generated .class byte code file This is a generated .class file. It has been generated by gcj -C CppTreeParser.java (which uses ecj). The original .java source file was generated by antlr (and a little sed script) from cpp.g. Original available from the frysk project http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/expr/cpp.g?cvsroot=frysk Other intermediary files available on request of course.
I can reproduce this ICE but it is very hard to see where the problem is with such a long testcase.
Created attachment 12994 [details] Generated .java source file
I have a fairly small C++ testcase for what appears to be the same issue: (sid)3604:tbm@em64t: ~] g++ -c firebird2-nav.cc (sid)3605:tbm@em64t: ~] g++ -c -O firebird2-nav.cc Unable to coalesce ssa_names 27 and 10 which are marked as MUST COALESCE. result_27(ab) and result_10(ab) firebird2-nav.cc: In function 'BOOLEAN NAV_get_record(Rsb*, mfb*, RPB*, RSE_GET_MODE)': firebird2-nav.cc:235: internal compiler error: SSA corruption Please submit a full bug report,
Created attachment 13167 [details] testcase
> I have a fairly small C++ testcase for what appears to be the same issue: I think that issue is actually different as the SSA inliner came in after this bug was filed so I filed this with a reduced testcase as PR 31081.
Looking at the original testcase, the complaint is that _t_8232 and _t_3 are both used in the PHI definition of _t_7. (using mainline from march 5th) ie, _t_7(ab) = PHI <...., _t_8232, ... , _t_3, ...> That definition occurs in BB2509. Because its an abnormal edge, all three must be coalescable. _t_8232 is defined in BB 2315, but _t_3 is live on entry and through this block, meaning they have different values and are live at the same time, so they cannot be coalesced The listing looks OK after ccp2, but in the listing after the FRE pass _t_3 becomes live on entry to this block, and it wasn't before. I can't really read the detailed output from FRE, but it does seem to have replaced a bunch of expressions with _t_3, so that would appear to be the culprit.
-fno-tree-fre makes the test case compile, which is further indication FRE is the problem.
Subject: Re: Unable to coalesce ssa_names <x> and <y> which are marked as MUST COALESCE On 8 Mar 2007 20:12:16 -0000, amacleod at redhat dot com <gcc-bugzilla@gcc.gnu.org> wrote: > > > ------- Comment #7 from amacleod at redhat dot com 2007-03-08 20:12 ------- > Looking at the original testcase, the complaint is that _t_8232 and _t_3 are > both used in the PHI definition of _t_7. (using mainline from march 5th) > > ie, _t_7(ab) = PHI <...., _t_8232, ... , _t_3, ...> > Uh, did you not put the (ab) next to the arguments, or do they really not have SSA_NAME_OCCURS_IN_ABNORMAL_PHI set on them? (They should) > I can't really read the detailed output from FRE, but it does seem to have > replaced a bunch of expressions with _t_3, so that would appear to be the > culprit. It won't value number things with SSA_NAME_OCCURS_IN_ABNORMAL_PHI set, so it should never eliminate anything with them.
They do all have the (ab) next to them, I was just indicating that they all occurred in a PHI together, and hence needed to be coalesced. I should have been more precise. Well, _t_3 definately does have the (ab) flag, and I don't know what all it does do, but it does introduce the situation where we have overlapping abnormal ssa-names which have to be coalesced. I see it does a bunch of replacements which include _t_3(ab), lines such as: Replaced (struct *) #ref#17#7_8338 with _t_3(ab) in #ref#17#7.2741_8343 = (struct *) #ref#17#7_8338; (Just an example, not meant to be the erroneous replacement). So it is clearly doing something with it.
OK, new investigation show that using the smaller testcase firebird2-nav.cc shows the inliner is misbehaving. before inlining (*041t.profile): # BLOCK 2 freq:10000 # PRED: ENTRY [100.0%] (fallthru,exec) D.2709_4 = request_3(D)->req_pool; D.2710_5 = (struct blk *) D.2709_4; D.2711_6 = request_3(D)->req_transaction; D.2712_10 = VIO_get (tdbb_7(D), rpb_8(D), rsb_9(D), D.2711_6, D.2710_5); # SUCC: 4 (ab,eh,exec) 3 [100.0%] (fallthru,exec) # BLOCK 3 freq:10000 # PRED: 2 [100.0%] (fallthru,exec) result_12(ab) = (BOOLEAN) D.2712_10; <...> BTR_key (tdbb_7(D), D.2719_20, D.2718_19, D.2717_18, &value, 0B); goto <bb 5>; # SUCC: 4 (ab,eh,exec) 5 [100.0%] (fallthru,exec) # BLOCK 4 # PRED: 2 (ab,eh,exec) 3 (ab,eh,exec) # result_1(ab) = PHI <result_11(ab)(2), result_12(ab)(3)> <L0>:; <...> # BLOCK 5 freq:10000 # PRED: 3 [100.0%] (fallthru,exec) 4 [100.0%] (fallthru,exec) # result_2 = PHI <result_12(ab)(3), result_1(ab)(4)> return result_2; # SUCC: EXIT [100.0%] and after inlining (*046i.inline) we see: <bb 2>: <bb 7>: D.2882_11 = request_9(D)->req_pool; D.2883_12 = (struct blk *) D.2882_11; D.2884_13 = request_9(D)->req_transaction; D.2885_14 = VIO_get (tdbb_8(D), rpb_3(D), rsb_1(D), D.2884_13, D.2883_12); <bb 3>: result_15(ab) = (BOOLEAN) D.2885_14; <...> BTR_key (tdbb_8(D), D.2892_22, D.2891_21, D.2890_20, &value, 0B); goto <bb 5>; # result_24(ab) = PHI <result_10(ab)(7), result_15(ab)(3)> <L4>:; <...> <bb 5>: # result_23 = PHI <result_15(ab)(3), result_24(ab)(4)> if (result_23 != 0) goto <bb 6>; else goto <bb 7>; <bb 6>: return 1; Basic block 7 is missing a PHI node which should merge result_23 and result_10. The result of this missing PHI should then be used in block 5 instead of result_10. The way it currently sits, result 10 is live through basic block 3, which makes it conflict with result_15, and makes the abnormal edges uncoalescable. Someone familiar with the inliner can probably fix this quickly. I took a quick look but its a different world in there :-)
(In reply to comment #11) > OK, new investigation show that using the smaller testcase firebird2-nav.cc > shows the inliner is misbehaving. That smaller testcase is a different issue as explained in comment #6 and has been filed under PR 31081 already.
Then perhaps we should remove the attachment from this PR if it isn't relevant...
Eventually this is related to PR35164, so please re-check here once that is fixed.
I've got a testcase from gcc trunk dated 20130605 that can generate the same "Unable to coalesce" message. Testcase available on request.
On Thu, 6 Jun 2013, dcb314 at hotmail dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30604 > > David Binderman <dcb314 at hotmail dot com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |dcb314 at hotmail dot com > > --- Comment #15 from David Binderman <dcb314 at hotmail dot com> --- > I've got a testcase from gcc trunk dated 20130605 that > can generate the same "Unable to coalesce" message. > > Testcase available on request. Can you open a new bugreport please? It's very likely a different reason than this one.
(In reply to rguenther@suse.de from comment #16) > Can you open a new bugreport please? It's very likely a different > reason than this one. After a lot of fiddling about, please see #57584 Redhat package guile went to a lot of work to hide the compiler command line ;-|
Is this PR still relevant?
no *** This bug has been marked as a duplicate of bug 35164 ***