https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|WAITING |NEW CC| |hjl.tools at gmail dot com --- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to RafaĆ Mszal from comment #4) > Created attachment 43210 [details] > Basic example of main funtion with LTO failure. > > This is simple example of observed LTO issue. RTC1_IRQHandler is removed > despite it is used to change volatile variable. RTC1_IRQHandler is defined > weak in the assembler startup file. I don't see it being defined in the startup file. But I take it should be similar to .weak NMI_Handler .type NMI_Handler, %function NMI_Handler: b . .size NMI_Handler, . - NMI_Handler and the only use is in the startup file as well: .section .isr_vector .align 2 .globl __isr_vector __isr_vector: .long __StackTop /* Top of Stack */ .long Reset_Handler .long NMI_Handler and you'd define it in a C file as non-weak (what it does doesn't matter) void RTC1_IRQHandler(void) { } So a testcase is: t1.c: ----- int i; void Handler() { i = 1; } void *Dispatch; int main(){ ((void (*)(void))Dispatch)(); return i;} t2.s: ----- .file "t2.s" .text .weak Handler .type Handler, @function Handler: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq %rsp, %rbp .cfi_def_cfa_register 6 popq %rbp .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE0: .size Handler, .-Handler .globl Dispatch .data .align 8 .type Dispatch, @object .size Dispatch, 8 Dispatch: .quad Handler .ident "GCC: (SUSE Linux) 7.2.1 20171020 [gcc-7-branch revision 253932]" .section .note.GNU-stack,"",@progbits and then I get > gcc-7 t2.s t1.c -flto /tmp/ccGhH7Cp.o:(.data+0x0): undefined reference to `Handler' collect2: error: ld returned 1 exit status > gcc-7 t1.c t2.s -flto in the working case: 1 t1.o 4 190 16b2980a71930688 PREEMPTED_REG Handler 198 16b2980a71930688 PREVAILING_DEF_IRONLY i 194 16b2980a71930688 PREVAILING_DEF main 202 16b2980a71930688 RESOLVED_EXEC Dispatch in the failing case (GNU ld): 1 t1.o 4 190 801577c96f9ccef3 PREVAILING_DEF_IRONLY Handler 198 801577c96f9ccef3 PREVAILING_DEF_IRONLY i 194 801577c96f9ccef3 PREVAILING_DEF main 202 801577c96f9ccef3 RESOLVED_EXEC Dispatch which works with gold: 1 t1.o 4 190 680bbd652c7cfe04 PREVAILING_DEF Handler 198 680bbd652c7cfe04 PREVAILING_DEF_IRONLY i 194 680bbd652c7cfe04 PREVAILING_DEF main 202 680bbd652c7cfe04 RESOLVED_EXEC Dispatch HJ? This is with binutils 2.29.1, thus confirmed but as a GNU ld issue.