https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67075
Eric Gallager <egallager at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution|--- |INVALID
--- Comment #5 from Eric Gallager <egallager at gcc dot gnu.org> ---
(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.
