[Bug c/97969] New: [ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[Bug c/97969] New: [ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[pmiscml at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

            Bug ID: 97969
           Summary: [ARM/Thumb] Certain combo of codegen options leads to
                    compilation infinite loop with growing memory use
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pmiscml at gmail dot com
  Target Milestone: ---

Created attachment 49619
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49619&action=edit
Testcase minimized with CReduce

Attached in the creduce-minimized source code (and original preprocessed
source) which, when compiled with ARM (32-bit) targeting compiler with certain
options, and a code with setjmp(), leads to an apparent infinite loop with
ever-growing memory usage.

Specific command line to reproduce the issue is:

arm-zephyr-eabi-gcc -std=c99 \
-fno-omit-frame-pointer \
-mthumb \
-Os \
-x cpp-output -c js-parser_cpp.c

The combo of 3 of "-fno-omit-frame-pointer -mthumb -Os" is what causes the
issue. Removing any of them gets rid of it.

The issue is not speculative - it happens with JerryScript project
(https://github.com/jerryscript-project/jerryscript/) build against Zephyr RTOS
(https://github.com/zephyrproject-rtos/zephyr/) for a Cortex-M0 target
(original gcc options included -mcpu=cortex-m0plus, but as the issue is
reproducible with just -mthumb, I didn't include it above). The nature of the
issue is pretty DoS'ish/CVE'ish, indeed, it caused our AWS-based CI to run
builds for 12+ hrs (which normally take 10 mins).

The issue happens with GCC 10.2, which is the latest at the time of reporting,
but also with 9.2.0. Specific GCC build comes from the SDK of the mentioned
Zephyr RTOS, which is built using Crosstool-NG, definitely with some patches,
but shouldn't be anything serious which might cause such behavior. It's however
my intention to try other toolchains, I just decided first to record currently
available information in this ticket.




$ /home/pfalcon/opt/zephyr-sdk-0.12.0b1/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc
-v
Using built-in specs.
COLLECT_GCC=/home/pfalcon/opt/zephyr-sdk-0.12.0b1/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc
COLLECT_LTO_WRAPPER=/mnt/hdd/opt/zephyr-sdk-0.12.0b1/arm-zephyr-eabi/bin/../libexec/gcc/arm-zephyr-eabi/10.2.0/lto-wrapper
Target: arm-zephyr-eabi
Configured with:
/workdir/build/build_arm/.build/arm-zephyr-eabi/src/gcc/configure
--build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu
--target=arm-zephyr-eabi --prefix=/workdir/build/output/arm-zephyr-eabi
--with-local-prefix=/workdir/build/output/arm-zephyr-eabi/arm-zephyr-eabi
--with-headers=/workdir/build/output/arm-zephyr-eabi/arm-zephyr-eabi/include
--with-newlib --enable-threads=no --disable-shared
--with-pkgversion='crosstool-NG 1.24.0.192_9551914' --enable-__cxa_atexit
--disable-libgomp --disable-libmudflap --disable-libmpx --disable-libssp
--disable-libquadmath --disable-libquadmath-support
--with-gmp=/workdir/build/build_arm/.build/arm-zephyr-eabi/buildtools
--with-mpfr=/workdir/build/build_arm/.build/arm-zephyr-eabi/buildtools
--with-mpc=/workdir/build/build_arm/.build/arm-zephyr-eabi/buildtools
--with-isl=/workdir/build/build_arm/.build/arm-zephyr-eabi/buildtools
--enable-lto --with-host-libstdcxx='-static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --disable-nls --enable-multiarch
--with-multilib-list=rmprofile --enable-languages=c,c++ --with-gnu-ld
--with-gnu-as --enable-initfini-array
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (crosstool-NG 1.24.0.192_9551914) 



$ /home/pfalcon/opt/zephyr-sdk-0.11.4/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc
-v
Using built-in specs.
COLLECT_GCC=/home/pfalcon/opt/zephyr-sdk-0.11.4/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc
COLLECT_LTO_WRAPPER=/mnt/hdd/opt/zephyr-sdk-0.11.4/arm-zephyr-eabi/bin/../libexec/gcc/arm-zephyr-eabi/9.2.0/lto-wrapper
Target: arm-zephyr-eabi
Configured with:
/home/buildslave/src/github.com/zephyrproject-rtos/sdk-ng/build/build_arm/.build/arm-zephyr-eabi/src/gcc/configure
--build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu
--target=arm-zephyr-eabi
--prefix=/home/buildslave/src/github.com/zephyrproject-rtos/sdk-ng/build/output/arm-zephyr-eabi
--with-local-prefix=/home/buildslave/src/github.com/zephyrproject-rtos/sdk-ng/build/output/arm-zephyr-eabi/arm-zephyr-eabi
--with-headers=/home/buildslave/src/github.com/zephyrproject-rtos/sdk-ng/build/output/arm-zephyr-eabi/arm-zephyr-eabi/include
--with-newlib --enable-threads=no --disable-shared
--with-pkgversion='crosstool-NG 1.24.0.37-3f461da-dirty' --enable-__cxa_atexit
--disable-libgomp --disable-libmudflap --disable-libmpx --disable-libssp
--disable-libquadmath --disable-libquadmath-support
--with-gmp=/home/buildslave/src/github.com/zephyrproject-rtos/sdk-ng/build/build_arm/.build/arm-zephyr-eabi/buildtools
--with-mpfr=/home/buildslave/src/github.com/zephyrproject-rtos/sdk-ng/build/build_arm/.build/arm-zephyr-eabi/buildtools
--with-mpc=/home/buildslave/src/github.com/zephyrproject-rtos/sdk-ng/build/build_arm/.build/arm-zephyr-eabi/buildtools
--with-isl=/home/buildslave/src/github.com/zephyrproject-rtos/sdk-ng/build/build_arm/.build/arm-zephyr-eabi/buildtools
--enable-lto --with-host-libstdcxx='-static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --disable-nls --enable-multiarch
--with-multilib-list=rmprofile --enable-languages=c,c++ --with-gnu-ld
--with-gnu-as --enable-initfini-array
Thread model: single
gcc version 9.2.0 (crosstool-NG 1.24.0.37-3f461da-dirty)

[Bug c/97969] [ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[pmiscml at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

--- Comment #1 from Paul Sokolovsky <pmiscml at gmail dot com> ---
Created attachment 49620
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49620&action=edit
Preprocessed original source which caused the issue (js-parser.c from
JerryScript project)

[Bug c/97969] [ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[pmiscml at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

--- Comment #2 from Paul Sokolovsky <pmiscml at gmail dot com> ---
To confirm, GCC 9.3.1 from "gcc-arm-none-eabi-9-2020-q2-update" (as distributed
by Arm from
https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm)
also has this issue.

[Bug c/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |arm
             Status|UNCONFIRMED                 |NEW
      Known to fail|                            |10.2.1, 11.0, 9.3.1
                 CC|                            |ktkachov at gcc dot gnu.org
      Known to work|                            |8.4.1
   Last reconfirmed|                            |2020-11-24
            Summary|[ARM/Thumb] Certain combo   |[9/10/11
                   |of codegen options leads to |Regression][ARM/Thumb]
                   |compilation infinite loop   |Certain combo of codegen
                   |with growing memory use     |options leads to
                   |                            |compilation infinite loop
                   |                            |with growing memory use
           Keywords|                            |memory-hog
     Ever confirmed|0                           |1

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Confirmed on the 9, 10, 11 branches. On GCC 8 it completes successfully.
Doesn't reproduce on aarch64, looks like it needs all of -mthumb
-fno-omit-frame-pointer -Os.

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |target
           Keywords|                            |compile-time-hog
           Priority|P3                          |P2
   Target Milestone|---                         |9.4

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmakarov at gcc dot gnu.org

--- Comment #4 from ktkachov at gcc dot gnu.org ---
This seems to go into a bad loop somewhere in LRA.

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[pmiscml at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

--- Comment #5 from Paul Sokolovsky <pmiscml at gmail dot com> ---
ktkachov@gcc.gnu.org:

Thanks for looking into this issue! Looking forward for the root cause to be
found. Given the minimized testcase which CReduce came to, my finger-in-the-sky
bet would be that it's a very fine case of data structure corruption, which
doesn't lead to segfault, but rather to infiniloop.

I'm saying that, because I tried to play with the minimized example myself, but
saw that most changes get rid of the issue. The only "simplifying" change I
could make which still leads to infiniloop is replace usage of the "h" enum
with "char" ("int" doesn't work). That makes declaration of the "h" enum
unused, and yet removal of it fixes the loop. That's why I say it looks like
very fine memory corruption, it's hard to imagine how unused enum declaration
can affect regalloc.

But then, I don't have experience with this stuff, and the setup is too
complicated for me to try. So again, thanks for looking into this.

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

--- Comment #6 from ktkachov at gcc dot gnu.org ---
Bisection shows it started with g:8d2d39587d941a40f25ea0144cceb677df115040

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[haoxintu at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

Haoxin Tu <haoxintu at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |haoxintu at gmail dot com

--- Comment #7 from Haoxin Tu <haoxintu at gmail dot com> ---
(In reply to Paul Sokolovsky from comment #0)

Hi, Paul. May I ask how to reduce compile-time-hog/memory-hog test cases using
CReduce?
I know CReduce can be easily used to reduce crash/wrong-code test cases, but I
don't know how to minimize compile-time/memory ones. I will be very appreciated
if you can give me any tips. Thanks.


Best,
Haoxin

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

--- Comment #8 from ktkachov at gcc dot gnu.org ---
(In reply to Haoxin Tu from comment #7)
> (In reply to Paul Sokolovsky from comment #0)
> 
> Hi, Paul. May I ask how to reduce compile-time-hog/memory-hog test cases
> using CReduce?
> I know CReduce can be easily used to reduce crash/wrong-code test cases, but
> I don't know how to minimize compile-time/memory ones. I will be very
> appreciated if you can give me any tips. Thanks.
> 
> 
> Best,
> Haoxin

When I had to do it in the past I've used the 'ulimit' command in linux. That
allows you to kill a process if it exceeds a time limit (ulimit -t) or a memory
limit (ulimit -m). You can use it in the validation script to check for the
pathological behaviour

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[haoxintu at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

--- Comment #9 from Haoxin Tu <haoxintu at gmail dot com> ---
(In reply to ktkachov from comment #8)

> When I had to do it in the past I've used the 'ulimit' command in linux.
> That allows you to kill a process if it exceeds a time limit (ulimit -t) or
> a memory limit (ulimit -m). You can use it in the validation script to check
> for the pathological behaviour

Hi. Got you. Thank you so much!


Best,
Haoxin

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[pmiscml at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

--- Comment #10 from Paul Sokolovsky <pmiscml at gmail dot com> ---
Created attachment 49693
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49693&action=edit
Script for CReduce

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[pmiscml at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

--- Comment #11 from Paul Sokolovsky <pmiscml at gmail dot com> ---
In my case, I used the "timeout" command from GNU coreutils. I've attached the
actual script used for reference (uncleaned dirty stuff, sorry).

One thing to keep in mind (and which took me a couple of extra creduce runs) is
that when it times out, it's the "interesting case" in CReduce terms. And when
compilation succeeds *or* fails (e.g. because CReduce produced broken syntax),
it's "not interesting case". So, you literally need to test for the timeout
exit code vs anything else (be it 0 or 1), like the script shows.

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[haoxintu at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

--- Comment #12 from Haoxin Tu <haoxintu at gmail dot com> ---
(In reply to Paul Sokolovsky from comment #11)

Awesome! I got your main idea here. Thank you very much, Paul!

Best,
Haoxin

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

--- Comment #13 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
Thank you for reducing the test.

I've reproduced the problem and started working on it.  I think the fix will be
ready on this week.

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[wirkus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

--- Comment #14 from Przemyslaw Wirkus <wirkus at gcc dot gnu.org> ---
Hi Vladimir,

I'm assigned to the issue and I'm working on it. I think I got the root cause.
I'm in the process of creating a patch after I complete few tests.

kind regards
Przemyslaw

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

--- Comment #15 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
Created attachment 49955
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49955&action=edit
a patch fixing the PR

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

--- Comment #16 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Przemyslaw Wirkus from comment #14)
> Hi Vladimir,
> 
> I'm assigned to the issue and I'm working on it. I think I got the root
> cause.
> I'm in the process of creating a patch after I complete few tests.
> 
> kind regards
> Przemyslaw

Sorry, it was not clear for me that somebody was working on the patch.  The bug
is actually severe and should be classified as P1.

In any case, here is my patch fixing this.  The patch is in the attachment. 
May be your patch will use a better approach.

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[wirkus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

--- Comment #17 from Przemyslaw Wirkus <wirkus at gcc dot gnu.org> ---
(In reply to Vladimir Makarov from comment #16)
> (In reply to Przemyslaw Wirkus from comment #14)
> > Hi Vladimir,
> > 
> > I'm assigned to the issue and I'm working on it. I think I got the root
> > cause.
> > I'm in the process of creating a patch after I complete few tests.
> > 
> > kind regards
> > Przemyslaw
> 
> Sorry, it was not clear for me that somebody was working on the patch.  The
> bug is actually severe and should be classified as P1.
> 
> In any case, here is my patch fixing this.  The patch is in the attachment. 
> May be your patch will use a better approach.

No worries, we were looking at the problem from Arm's backend pov.
Regardless, please carry on with your patch for this PR as my solution was just
masking the core issue you've addressed.

Thank you for looking at this, cheers!

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

--- Comment #18 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Vladimir Makarov <vmakarov@gcc.gnu.org>:

https://gcc.gnu.org/g:cf2ac1c30af0fa783c8d72e527904dda5d8cc330

commit r11-6615-gcf2ac1c30af0fa783c8d72e527904dda5d8cc330
Author: Vladimir N. Makarov <vmakarov@redhat.com>
Date:   Tue Jan 12 11:26:15 2021 -0500

    [PR97969] LRA: Transform pattern `plus (plus (hard reg, const), pseudo)`
after elimination

    LRA can loop infinitely on targets without `reg + imm` insns.  Register
elimination
    on such targets can increase register pressure resulting in permanent
    stack size increase and changing elimination offset.  To avoid such
situation, a simple
    transformation can be done to avoid register pressure increase after
    generating reload insns containing eliminated hard regs.

    gcc/ChangeLog:

            PR target/97969
            * lra-eliminations.c (eliminate_regs_in_insn): Add transformation
            of pattern 'plus (plus (hard reg, const), pseudo)'.

    gcc/testsuite/ChangeLog:

            PR target/97969
            * gcc.target/arm/pr97969.c: New.

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[pmiscml at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

--- Comment #19 from Paul Sokolovsky <pmiscml at gmail dot com> ---
Vladimir Makarov, Przemyslaw Wirkus: Thanks looking into this issue and fixing
it!

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[wirkus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

--- Comment #20 from Przemyslaw Wirkus <wirkus at gcc dot gnu.org> ---
Just a heads-up:

I would like to suggest backport for this patch to GCC 9 and 10. Quoting
Vladimir:

> The bug is actually severe and should be classified as P1
Currently patch applies cleanly for both gcc-9 and gcc-10 branches. 

I will firstly bootstrap both toolchains (9&10) with this change and run some
tests. After I'm done and all is OK I will properly ask for backport.

Again, Vladimir, thank you for the fix!

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

--- Comment #21 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
Additional fix for PR98722 is necessary for this PR.

4334b524274203125193a08a8485250c41c2daa9

[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

--- Comment #22 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Vladimir Makarov from comment #21)
> Additional fix for PR98722 is necessary for this PR.
> 
> 4334b524274203125193a08a8485250c41c2daa9

Sorry, one more fix for PR98777 is necessary for the PR:

https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=68ba1039c7daf0485b167fe199ed7e8031158091

[Bug target/97969] [9/10/11/12 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

[Bug target/97969] [9/10/11/12 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[przemyslaw.wirkus at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

Przemyslaw Wirkus <przemyslaw.wirkus at arm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |przemyslaw.wirkus at arm dot com

--- Comment #23 from Przemyslaw Wirkus <przemyslaw.wirkus at arm dot com> ---
Just a follow up after GCC 11 release.

I've locally backported to gcc-10 branch (without any change to original
patches) PR97969 and following PR98722 & PR98777 patches.

Commits apply cleanly without changes.
Built and regression tested on:
* arm-none-eabi and
* aarch64-none-linux-gnu cross toolchains.

There were no issues and no regressions (all OK).

I've asked on mailing list for official backport approval.

[Bug target/97969] [9/10/11/12 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> ---
So is this now fixed on trunk and the GCC 11 branch?  Please update the summary
and known-to-work/fail accordingly,

[Bug target/97969] [9/10/11/12 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[wirkus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

--- Comment #25 from Przemyslaw Wirkus <wirkus at gcc dot gnu.org> ---
Yes, it was applied to GCC 11 (then trunk) but we were waiting for GCC 11
release so I can backport at least to GCC 10.

After backport I guess we can close this PR.

PS: Updated "known to work/fail".

Cheers!

[Bug target/97969] [9/10 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.4                         |9.5

--- Comment #26 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.

[Bug target/97969] [9/10 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

--- Comment #27 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Przemyslaw Wirkus
<wirkus@gcc.gnu.org>:

https://gcc.gnu.org/g:eb13f3f81d56910626529af52e03e74770ffca98

commit r10-9880-geb13f3f81d56910626529af52e03e74770ffca98
Author: Vladimir N. Makarov <vmakarov@redhat.com>
Date:   Tue Jan 12 11:26:15 2021 -0500

    [PR97969] LRA: Transform pattern `plus (plus (hard reg, const), pseudo)`
after elimination

    LRA can loop infinitely on targets without `reg + imm` insns.  Register
elimination
    on such targets can increase register pressure resulting in permanent
    stack size increase and changing elimination offset.  To avoid such
situation, a simple
    transformation can be done to avoid register pressure increase after
    generating reload insns containing eliminated hard regs.

    gcc/ChangeLog:

            PR target/97969
            * lra-eliminations.c (eliminate_regs_in_insn): Add transformation
            of pattern 'plus (plus (hard reg, const), pseudo)'.

    gcc/testsuite/ChangeLog:

            PR target/97969
            * gcc.target/arm/pr97969.c: New.

    (cherry picked from commit cf2ac1c30af0fa783c8d72e527904dda5d8cc330)

[Bug target/97969] [9 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |9.5.0
         Resolution|---                         |FIXED
   Target Milestone|9.5                         |10.4
             Status|ASSIGNED                    |RESOLVED

--- Comment #28 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed for GCC 10.4.