Created attachment 36100 [details] Preprocessed source code to reproduce loop, compressed On a low-memory system, I "need" ggc-min-expand=0 to avoid swapping. However, it appears there are cases where this can lead to an infinite loop of the garbage collector, I presume because more than gcc-min-heapsize memory is actually in use. I did not encounter this in GCC 4.4 or 4.5, but it may have been coincidence, so I am uncertain whether this is a regression or not. I am able to reproduce this consistently with the attached preprocessed source, and either one of these build commands: armv7a-hardfloat-linux-gnueabi-g++ -c -O2 -pipe -mcpu=cortex-a8 -mfpu=vfpv3 -mfloat-abi=hard -mthumb -mthumb-interwork --param ggc-min-expand=0 --param ggc-min-heapsize=32768 -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -fPIC x.cpp /usr/libexec/gcc/armv7a-hardfloat-linux-gnueabi/4.8.4/cc1plus -D_GNU_SOURCE x.cpp -dumpbase x.cpp -da -mcpu=cortex-a8 -mfpu=vfpv3 -mfloat-abi=hard -mthumb -mthumb-interwork -mtls-dialect=gnu -auxbase x -O2 -Wall -Wextra -fvisibility=hidden -fvisibility-inlines-hidden -fPIC --param ggc-min-expand=0 --param ggc-min-heapsize=32768 -fstack-protector -o x.out The latter of these verbosely prints: <*free_lang_data> <visibility> <early_local_cleanups> {GC 32770k -> 32172k} {GC 32770k -> 32480k} ............ (~forever)
Also note: ggc-min-expand=1 seems to successfully workaround this issue (but is non-ideal for low-memory systems).
Sounds more like ggc_collect is now always doing the gc and there are a lot of ggc_collect calls. So what is happening we are close to your 32M limit you set, so any garbage that is produced in a pass will cause the next call to ggc_collect to always collect. This means there a lot of calls to ggc_collect but in the normal case (non 0 case), it does not matter. You might want to try 5.2 as 4.8.x is no longer supported and there have been some memory reductions happened since 4.8.x.
I think nowadays we just have a lot more ggc_collect calls.
redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01605.html Eric Gallager <egallager at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |WAITING Last reconfirmed| |2017-08-14 CC| |egallager at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Eric Gallager <egallager at gcc dot gnu.org> --- (In reply to Andrew Pinski from comment #2) > Sounds more like ggc_collect is now always doing the gc and there are a lot > of ggc_collect calls. > > So what is happening we are close to your 32M limit you set, so any garbage > that is produced in a pass will cause the next call to ggc_collect to always > collect. This means there a lot of calls to ggc_collect but in the normal > case (non 0 case), it does not matter. > > You might want to try 5.2 as 4.8.x is no longer supported and there have > been some memory reductions happened since 4.8.x. Changing to WAITING until reporter tries a supported version.
(In reply to Eric Gallager from comment #4) > redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01605.html > > Eric Gallager <egallager at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|UNCONFIRMED |WAITING > Last reconfirmed| |2017-08-14 > CC| |egallager at gcc dot gnu.org > Ever confirmed|0 |1 > > --- Comment #4 from Eric Gallager <egallager at gcc dot gnu.org> --- > (In reply to Andrew Pinski from comment #2) > > Sounds more like ggc_collect is now always doing the gc and there are a lot > > of ggc_collect calls. > > > > So what is happening we are close to your 32M limit you set, so any garbage > > that is produced in a pass will cause the next call to ggc_collect to always > > collect. This means there a lot of calls to ggc_collect but in the normal > > case (non 0 case), it does not matter. > > > > You might want to try 5.2 as 4.8.x is no longer supported and there have > > been some memory reductions happened since 4.8.x. > > Changing to WAITING until reporter tries a supported version. Reporter still hasn't tried a supported version; closing.