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.

Reply via email to