Ping again on this patch series:
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551927.html
These patches just missed making it into GCC 10 last year -- although
there seemed to be agreement in principle, they needed a bit more work
to resolve test regressions. Now that we are heading into fall again, I
am worried that they may miss GCC 11 as well if they need further
re-working but I don't get feedback until very late in the release
cycle, or any feedback at all. :-( I also have a set of OpenACC
patches for identifying loops in kernels regions that depend on these;
I'll be posting those shortly and I hope to get those into GCC 11 as well.
-Sandra
On 8/13/20 10:34 AM, 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.
-Sandra
Sandra Loosemore (4):
Move loop and switch tree data structures from cp/ to c-family/.
Use C-style loop lowering instead of C++-style.
Work around bootstrap failure in Fortran front end.
Change C front end to emit structured loop and switch tree nodes.
gcc/c-family/c-common.c | 24 ++
gcc/c-family/c-common.def | 24 ++
gcc/c-family/c-common.h | 53 +++-
gcc/c-family/c-dump.c | 38 +++
gcc/c-family/c-gimplify.c | 422
++++++++++++++++++++++++++++++++
gcc/c-family/c-pretty-print.c | 92 ++++++-
gcc/c/c-decl.c | 18 +-
gcc/c/c-lang.h | 3 +-
gcc/c/c-objc-common.h | 2 +
gcc/c/c-parser.c | 125 +++++-----
gcc/c/c-tree.h | 21 +-
gcc/c/c-typeck.c | 227 ++++++-----------
gcc/cp/cp-gimplify.c | 469
+++++++-----------------------------
gcc/cp/cp-objcp-common.c | 13 +-
gcc/cp/cp-tree.def | 23 --
gcc/cp/cp-tree.h | 40 ---
gcc/cp/cxx-pretty-print.c | 78 ------
gcc/cp/dump.c | 31 ---
gcc/doc/generic.texi | 56 +++--
gcc/fortran/interface.c | 4 +
gcc/objc/ChangeLog | 5 +
gcc/objc/objc-act.c | 6 +-
gcc/testsuite/gcc.dg/gomp/block-7.c | 12 +-
23 files changed, 938 insertions(+), 848 deletions(-)
