https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77951
Bug ID: 77951 Summary: Incorrect placement of label which does not affect execution flow Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- Created attachment 39794 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39794&action=edit label-bug.c The attached test case aborts at run time because the end label is moved up before the call instruction, making it equal to the begin label: .L3: .L4: call f movl $.L4, %eax subl $.L3, %eax ret I suspect this happens because the label is never used as a jump target, but the test shows that there is still a way in which the label placement can matter. This is a purely synthetic test case, extracted from a test I wrote for bug 38295. I did not observe any miscompilation of applications due to this issue. label-bug.c.276r.split4 has: (note/s 4 2 6 2 ("begin") NOTE_INSN_DELETED_LABEL 3) (call_insn 6 4 7 2 (call (mem:QI (symbol_ref:DI ("f") [flags 0x3] <function_decl 0x7fab93016380 f>) [0 f S1 A8]) (const_int 0 [0])) label-bug.c:12 673 {*call} (expr_list:REG_CALL_DECL (symbol_ref:DI ("f") [flags 0x3] <function_decl 0x7fab93016380 f>) (expr_list:REG_EH_REGION (const_int 0 [0]) (nil))) (nil)) (note/s 7 6 9 2 ("end") NOTE_INSN_DELETED_LABEL 4) But label-bug.c.277r.sched2 turns this into: (note/s 4 2 7 2 ("begin") NOTE_INSN_DELETED_LABEL 3) (note/s 7 4 6 2 ("end") NOTE_INSN_DELETED_LABEL 4) (call_insn:TI 6 7 9 2 (call (mem:QI (symbol_ref:DI ("f") [flags 0x3] <function_decl 0x7fab93016380 f>) [0 f S1 A8]) (const_int 0 [0])) label-bug.c:12 673 {*call} (expr_list:REG_CALL_DECL (symbol_ref:DI ("f") [flags 0x3] <function_decl 0x7fab93016380 f>) (expr_list:REG_EH_REGION (const_int 0 [0]) (nil))) (nil)) So it seems an RTL issue. The above RTL dumps are from a fairly old GCC 7 from May, but I see the same issue with gcc version 5.3.1 20160406 (Red Hat 5.3.1-6), in label-bug.c.255r.split4 and label-bug.c.256r.sched2 there.