https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67075
Eric Gallager changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67075
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67075
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67075
--- Comment #3 from Richard Biener ---
I think nowadays we just have a lot more ggc_collect calls.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67075
--- Comment #2 from Andrew Pinski ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67075
--- Comment #1 from Luke Dashjr ---
Also note: ggc-min-expand=1 seems to successfully workaround this issue (but is
non-ideal for low-memory systems).
