https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #20 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- With attachment 51726 and current trunk, the present damage is 22% for the ltrans105 unit, which AFAICT, is the worst offender. This is much better than the original 44%, but still not ideal. After some more poking, it looks more like a ranger issue than a threader issue, so I'll write some notes on how to reproduce for the SPEC challenged (ahem, me). I have the following in my config/myconfig.cfg file to avoid LD_LIBRARY_PATH magic and to save all the build temporary files, since I'm LTO impaired ;-) default: BASEDIR = /home/aldyh/bld/mycompiler/install LDFLAGS = -Wl,-rpath=/usr/lib/gcc/x86_64-redhat-linux/11/ -L/usr/lib/gcc/x86_64-redhat-linux/11/ ... ... default=base: OPTIMIZE = -Ofast -flto=20 -march=native -ftime-report -fno-checking -save-temps -v CXXOPTIMIZE = -fpermissive FOPTIMIZE = -std=legacy $ runcpu --config=myconfig -a build -D --noreportable -I -T base -i test -n 1 521.wrf_r Then I hunt down some make.wrf_r.out file which has the lto1 magic for the ltrans105 unit: /some/dir/lto1 [lots-of-flags] -ftime-report -fno-checking -fltrans ./wrf_r.ltrans105.o -o ./wrf_r.ltrans105.ltrans.s After which, I can re-run lto1 from the directory with all the LTO/.o files (the one with the make.wrf_r.out directory). For the record, I hate the SPEC build system :).
