https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91817
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Known to work| |5.3.1
Resolution|--- |FIXED
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
On x86_64-linux with GCC 8 I see
rguenther@murzim:/tmp> /usr/bin/time gcc-8 -S 1.i -m32 -g
0.39user 0.02system 0:00.42elapsed 99%CPU (0avgtext+0avgdata 90428maxresident)k
0inputs+3648outputs (0major+20612minor)pagefaults 0swaps
rguenther@murzim:/tmp> /usr/bin/time gcc-8 -S 1.i -m32 -g -O
1.77user 0.05system 0:01.82elapsed 100%CPU (0avgtext+0avgdata
141920maxresident)k
0inputs+5280outputs (0major+33933minor)pagefaults 0swaps
rguenther@murzim:/tmp> /usr/bin/time gcc-8 -S 1.i -m32 -g -O2
8.01user 0.08system 0:08.10elapsed 99%CPU (0avgtext+0avgdata
330268maxresident)k
0inputs+6272outputs (0major+86763minor)pagefaults 0swaps
rguenther@murzim:/tmp> /usr/bin/time gcc-8 -S 1.i -m32 -g -O3
8.19user 0.11system 0:08.31elapsed 99%CPU (0avgtext+0avgdata
332380maxresident)k
0inputs+6344outputs (0major+94164minor)pagefaults 0swaps
Same for GCC 7.
note GCC 4.6 is very old so it's somewhat pointless to complain about its
compile-time speed. Nevertheless I can reproduce the slowness with that
version so I am assuming this issue has been fixed, in 5.3.1 at least.
