https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81342
--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> --- (In reply to Anatol from comment #3) > Hi > > I indeed observe the issue in a kernel project. It is a custom x86 kernel > that is not published yet. > > I tried to narrow down use case and I think I found how to reproduce the > issue easily. It looks like a trigger pattern is: > > 1) compile one file as 32bit code (-m32) > 2) convert it to 64bit elf object using objcopy > 3) link the object above with regular 64bit elf > > If "-flto" is not used then linking works fine otherwise I have the crash > above. > > Here is an attached repo case for your convenience. Well how does it make sense to combine -m32 and -m64 in a single binary? Without -flto having a cross-reference: $ cat code32.c int hello(int a) { return a * a; } $ cat code64.c void main(void) { return hello(1); } One gets: $ gcc -g -ggdb -nostdlib -ffreestanding -std=c11 -fno-stack-protector -mno-red-zone -fno-common -W -Wall -Wextra -O3 code32.o code64.o -o code_bin /usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 00000000004000f0 Thus without LTO it does not work.