https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #13 from Martin Liška <marxin at gcc dot gnu.org> --- (In reply to Richard Earnshaw from comment #10) Thank you Richard for help. > I'm not particularly familiar with how LTO is supposed to work. I can > reproduce the crash on ARM as Martin described (but not on AArch64). Interesting. > The > problem seems to be an assert that the number of files to analyse passed on > the command line matches the number of files described in the resolution > file. We have: > > lto1 -quiet -dumpbase aaaa -mcpu=cortex-a72 -mfloat-abi=hard > -mtls-dialect=gnu -mcpu=cortex-a72 -mfloat-abi=hard -mtls-dialect=gnu -marm > -march=armv8-a+crc+simd -auxbase aaaa -version -fno-openmp -fno-openacc > -fno-pie -fltrans-output-list=/tmp/ccoC6W9f.ltrans.out -fwpa > -fresolution=main.res -flinker-output=exec @/tmp/ccHCf4bh > > Where ccHCf4bh contains: > aaaa > main.o > > and main.res contains: > 1 > main.o 1 > 195 4bf9aa6f81679e65 PREVAILING_DEF main > > So if I've understood this correctly, the resolution file says to expect one > file to analyse, but two are passed. It looks like something is > interpreting aaaa as an additional file. Yes, I see the same that the file 'aaaa' is passed as an input file. > > Going back another step, we see > > /home/rearnsha/scratch/gnu/gcc-install/armv8l/gcc-9.1.0/libexec/gcc/armv8l- > unkno > wn-linux-gnueabihf/9.1.0/lto-wrapper -fresolution=main.res > -flinker-output=exec > main.o > /home/rearnsha/scratch/gnu/gcc-install/armv8l/gcc-9.1.0/bin/gcc > @/tmp/cc8Su59l > > where cc8Su59l contains: > -xlto > -c > -fno-openmp > -fno-openacc > -fno-pie > -mcpu=cortex-a72 > -mfloat-abi=hard > -mtls-dialect=gnu > -marm > -march=armv8-a+crc+simd > -v > aaaa Yep, one should not see this file here. > -save-temps > -mcpu=cortex-a72 > -mfloat-abi=hard > -mtls-dialect=gnu > -marm > -march=armv8-a+crc+simd > -fltrans-output-list=/tmp/ccoC6W9f.ltrans.out > -fwpa > -fresolution=main.res > -flinker-output=exec > main.o > > I think the problem is that 'aaaa' mid-way through the list of options. It > looks as though it has had a preceding -MF gobbled but not its argument. I have the same feeling that somewhere the argument of -MF should be eaten. I'm also not able to fully debug that to be honest. > > Does this help any? Partially, it confirms what I can see. But I'm still not able to deduce why that happens only for ARM-targets.
