https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67893
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2015-10-08
Version|6.0 |5.2.1
Target Milestone|--- |5.3
Ever confirmed|0 |1
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Can't yet confirm the regression (need to look for a bigger box...) but I can
confirm it uses >2GB even with plain -O2. Note that -O2 has quite some
quadratic algorithms.
As even plain -O1 goes up to 2GB my usual suspect would be DF.
Note that with -O1 frontend processing peaks at 600MB and after gimplification
and lowering we are at 1GB - so this is a huge CU in the first place. Early
opts plus IPA get us to 2GB already (same at -O2).
What's the second preprocessed source from?
Confirmed as memory-hog though.
Unfortunately as the testcase is so large it's hard to work with it but it
looks
like we gradually leak memory during late optimization/expansion, there are no
"big" functions in the end it seems.
Btw, the gcc 5 branch at r228565 peaks at 2.3GB with -O2, -g adds that other
1.2GB (hello var-tracking and VTA).
