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