https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67075
Eric Gallager <egallager at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2017-08-17
CC| |egallager at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #4 from Eric Gallager <egallager at gcc dot gnu.org> ---
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.
