[PATCH V2 0/4] Unify C and C++ handling of loops and switches

[David Malcolm]

On Wed, 2020-09-09 at 17:13 -0400, Jason Merrill wrote:
> On 8/13/20 12:34 PM, Sandra Loosemore wrote:
> > This is a revised version of the patch set originally posted
> > last November:
> > 
> > https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534142.html
> > 
> > In addition to generally updating and rebasing the patches to
> > reflect
> > other changes on mainline in the meantime, for this version I have
> > switched to using the C lowering strategy (directly to goto form)
> > rather than the C++ one (to LOOP_EXPR) because of regressions in
> > the C
> > optimization tests.  Besides the ones previously noted in the
> > original
> > patch submission, there were a bunch of new ones since
> > November.  Some
> > of them were trivial to fix (e.g., flipping branch probabilities to
> > reflect the different sense of the loop exit condition in the
> > C++-style output), but I wasn't making much progress on others and
> > eventually decided to pursue the "plan B" of using the C-style
> > output
> > everywhere, as discussed here:
> > 
> > https://gcc.gnu.org/pipermail/gcc-patches/2019-December/536536.html
> > 
> > The only regression I ran into with this was a bootstrap failure
> > building the Fortran front end from a new -Wmaybe-uninitialized
> > error.
> > This might be a false positive but part 3 of the new series works
> > around it by adding an assertion to give g++ a hint.  Unfortunately
> > I
> > had no luck in trying to reduce this to a standalone test case, but
> > I
> > did observe that the failure went away when I compiled that file
> > with
> > debugging enabled.  :-S  I could file a PR to look into this
> > further if
> > the workaround is good enough for now.
> 
> My impression from Jeff's analysis in January and David's in March 

For reference, these seem to have been:
  https://gcc.gnu.org/pipermail/gcc-patches/2020-January/539207.html
and:
  https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542018.html
respectively.

In the latter I said:

> I think that what's happened is that your patch improves the location
> information for the gimple stmts, and this uncovers a bug in how I 
> wrote the test.

which is presumably what Jason's getting at.

BTW, in terms of analyzer issues, my big rewrite of analyzer state-
tracking landed in master a month ago, on 2020-08-13 as
808f4dfeb3a95f50f15e71148e5c1067f90a126d, and changed the behavior of
gcc.dg/analyzer/explode-2.c, which was one of the ones an earlier
version of Sandra's patch also affected.

Sandra: was the most recent patch you posted tested against a
relatively recent source tree?  (i.e. since that 2020-08-13 patch?). 
That said, I don't want the analyzer to stand in the way of
improvements to the frontends, so let me know if I can help with any
analyzer testsuite regressions.

Thanks
Dave

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