On 9/9/20 3:13 PM, Jason Merrill wrote:
My impression from Jeff's analysis in January and David's in March was that many of the testsuite changes were from the C++ approach actually providing better results, so the reversal here surprises me. Can you talk more about the regressions you're seeing?
I spent most of my time earlier in the summer looking at the 3 regressions I originally saw last fall. Unfortunately I could get no traction at all on the 2 FSA-related ones. :-( For the gcc.dg/tree-ssa/ssa-dce-3.c regression, I tracked it down to some code in the cddce1 pass being sensitive to the ordering of basic blocks in the input code; I filed PR96487 for that.
I was also having a bunch of problems with -Wimplicit-fallthrough failures triggered by the C++ front end loop expansion sometimes flipping the sense of the end test conditional (through the use of fold_build3_loc to build it). It seemed to me that the code that handles COND_EXPRs for those warnings is sensitive to the order of blocks as well, and has asymmetric assumptions that the code for the "if" branch is emitted inline before the "else" branch. I tried some experiments with generalizing it to recognize the branches in either order, but that did not fix the regressions, so maybe the problem was somewhere else entirely, or a combination of two different bugs. :-(
Anyway it seemed to me that the patches would not be accepted if I resubmitted them in a form that still caused regressions, and switching back to the C way of expanding to GOTO form directly instead of via LOOP_EXPR did that.
-Sandra
