https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114578
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2025-02-04
Ever confirmed|0 |1
Summary|[13/14/15 Regression] |[13/14 Regression] memory
|memory hog, virtual memory |hog, virtual memory
|exhausted, building a c++ |exhausted, building a c++
|file on arm-linux-gnueabihf |file on arm-linux-gnueabihf
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
I'll note that 32bit host systems are not the focus for (memory) optimizations.
I can confirm a slight memory usage regression on a 64bit host from 12.4 to
13.3, from
27.09user 1.25system 0:28.42elapsed 99%CPU (0avgtext+0avgdata
3644708maxresident)k
3616inputs+468408outputs (14major+781348minor)pagefaults 0swaps
to
27.95user 1.27system 0:29.28elapsed 99%CPU (0avgtext+0avgdata
3808172maxresident)k
1816inputs+468504outputs (8major+829796minor)pagefaults 0swaps
GCC 14.2 using
26.18user 1.24system 0:27.49elapsed 99%CPU (0avgtext+0avgdata
3810184maxresident)k
3784inputs+468504outputs (12major+800842minor)pagefaults 0swaps
and trunk improving to the following - likely due to automagic
#embed-ification.
2.03user 0.09system 0:02.13elapsed 99%CPU (0avgtext+0avgdata
267264maxresident)k
0inputs+62184outputs (0major+34537minor)pagefaults 0swaps
So - fixed on trunk.
