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?
