[Bug target/113723] New: -freorder-blocks-and-partition emits bogus asm directives on aarch64

[Bug target/113723] New: -freorder-blocks-and-partition emits bogus asm directives on aarch64

[redbeard0531 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113723

            Bug ID: 113723
           Summary: -freorder-blocks-and-partition emits bogus asm
                    directives on aarch64
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

It tries to subtract labels across the function split which the assembler
rejects. At the very least it does this when generating a switch jump table,
but there may be other cases.

https://www.godbolt.org/z/Ynh1zzY4a

Repro with -O3 -freorder-blocks-and-partition:


[[gnu::cold]]void cold();

template<int i> void f();
#define GENERATE_CASE case __COUNTER__: f<__COUNTER__>(); break 

void test(int i) {
    switch(i) {
        case 1: cold(); break;
        GENERATE_CASE;
        GENERATE_CASE;
        GENERATE_CASE;
        GENERATE_CASE;
        GENERATE_CASE;
        GENERATE_CASE;
        GENERATE_CASE;
        GENERATE_CASE;
        GENERATE_CASE;
        GENERATE_CASE;
    }
}

test(int):
        cmp     w0, 18
        bls     .L17
.L1:
        ret
.L17:
        adrp    x1, .L4
        add     x1, x1, :lo12:.L4
        ldrb    w1, [x1,w0,uxtw]
        adr     x0, .Lrtx4
        add     x1, x0, w1, sxtb #2
        br      x1
.Lrtx4:
.L4:
        .byte   (.L14 - .Lrtx4) / 4
        .byte   (.L13 - .Lrtx4) / 4 // <<<< THIS IS THE BAD ONE
        .byte   (.L12 - .Lrtx4) / 4

...

test(int) [clone .cold]:
.L13:
        b       cold()


/tmp/cck05x4u.s: Assembler messages:
/tmp/cck05x4u.s:48: Error: invalid operands (.text.unlikely and .text sections)
for `-'
Compiler returned: 1

I've repro'd on 11,12, and trunk.

[Bug target/113723] -freorder-blocks-and-partition emits bogus asm directives on aarch64

[redbeard0531 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113723

--- Comment #1 from Mathias Stearn <redbeard0531 at gmail dot com> ---
As a workaround sticking [[gnu::optimize("no-reorder-blocks-and-partition")]]
 on each function that triggers this seems to work. But that is obviously not a
scalable solution.

[Bug rtl-optimization/113723] switch (jump) tables don't get along with -freorder-blocks-and-partition on non-x86

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113723

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-02-04
     Ever confirmed|0                           |1
            Summary|-freorder-blocks-and-partit |switch (jump) tables don't
                   |ion emits bogus asm         |get along with
                   |directives on aarch64       |-freorder-blocks-and-partit
                   |                            |ion on non-x86
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
x86 works via using .long:
.long   .L13-.L4

For x86 we get:
(jump_table_data 18 17 19 (addr_diff_vec:SI (label_ref:DI 17)

While on aarch64 we get incorrectly:

(jump_table_data 12 11 13 (addr_diff_vec:QI (label_ref:DI 11)

The shortening pass turns it into QI.

But that is not the only issue.

[Bug rtl-optimization/113723] switch (jump) tables don't get along with -freorder-blocks-and-partition on non-x86

[andi-gcc at firstfloor dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113723

Andi Kleen <andi-gcc at firstfloor dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andi-gcc at firstfloor dot org

--- Comment #3 from Andi Kleen <andi-gcc at firstfloor dot org> ---
Even x86 has similar problems in some cases, see PR50676