[Bug middle-end/100604] New: GCC generates invalid LO_SYM for unaligned global

[Bug middle-end/100604] New: GCC generates invalid LO_SYM for unaligned global

[dragan.mladjenovic at syrmia dot com]

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

            Bug ID: 100604
           Summary: GCC generates invalid LO_SYM for unaligned global
           Product: gcc
           Version: 11.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dragan.mladjenovic at syrmia dot com
  Target Milestone: ---

Created attachment 50814
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50814&action=edit
Reproducer example.

This a bit contrived example that requires -O0. Not sure if it applies to
bitfield extracts in other contexts and optimization levels. I noticed it on
STRICT_ALIGMENT targets w/o extzvmisalign.

$cat unaligned.c
int __attribute__((aligned(2))) bar;

int foo (void)
{
        return bar;
}


$riscv64-elf-gcc  unaligned.c  -S  -o -
        .file   "unaligned.c"
        .option nopic
        .attribute arch, "rv64i2p0_m2p0_a2p0_f2p0_d2p0_c2p0"
        .attribute unaligned_access, 0
        .attribute stack_align, 16
        .text
        .globl  bar
        .section        .sbss,"aw",@nobits
        .align  1
        .type   bar, @object
        .size   bar, 4
bar:
        .zero   4
        .text
        .align  1
        .globl  foo
        .type   foo, @function
foo:
        addi    sp,sp,-16
        sd      s0,8(sp)
        addi    s0,sp,16
        lui     a5,%hi(bar)
        lhu     a4,%lo(bar)(a5)
        lhu     a5,%lo(bar+2)(a5)
        slli    a5,a5,16
        or      a5,a5,a4
        slli    a5,a5,32
        srai    a5,a5,32
        sext.w  a5,a5
        mv      a0,a5
        ld      s0,8(sp)
        addi    sp,sp,16
        jr      ra
        .size   foo, .-foo
        .ident  "GCC: (Scratch/experimental build 20210514_1511) 11.1.1
20210503"

$mipsisa64-elf-gcc -O0 unaligned.c -G 0 -mips64r6 -S  -o -
        .file   1 "unaligned.c"
        .section .mdebug.eabi64
        .previous
        .section .gcc_compiled_long64
        .previous
        .nan    2008
        .module fp=64
        .module oddspreg
        .text
        .globl  bar
        .section        .bss,"aw",@nobits
        .align  1
        .type   bar, @object
        .size   bar, 4
bar:
        .space  4
        .text
        .align  2
        .globl  foo
        .set    nomips16
        .set    nomicromips
        .ent    foo
        .type   foo, @function
foo:
        .frame  $fp,8,$31               # vars= 0, regs= 1/0, args= 0, gp= 0
        .mask   0x40000000,0
        .fmask  0x00000000,0
        .set    noreorder
        .set    nomacro
        daddiu  $sp,$sp,-8
        sd      $fp,0($sp)
        move    $fp,$sp
        lui     $2,%hi(bar)
        lhu     $3,%lo(bar)($2)
        dsll    $3,$3,16
        lhu     $2,%lo(bar+2)($2)
        or      $2,$2,$3
        dsll    $2,$2,32
        dsra    $2,$2,32
        sll     $2,$2,0
        move    $sp,$fp
        ld      $fp,0($sp)
        daddiu  $sp,$sp,8
        jrc     $31
        .set    macro
        .set    reorder
        .end    foo
        .size   foo, .-foo
        .ident  "GCC: (Scratch/experimental build 20210514_1405) 11.1.1
20210503"

Notice that %lo(bar)(.*) and %lo(bar+2)(.*) resue same %hi(bar) value.
This can be wrong since bar is 2-byte aligned and might be split between two
different %hi pages.

[Bug middle-end/100604] GCC generates invalid LO_SYM for unaligned global

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|riscv,mips                  |riscv-*-*,mips64r6-*-*
           Keywords|                            |wrong-code

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think this comes from emit-rtl.c:
      /* If MEMREF is a LO_SUM and the offset is within the alignment of the
         object, we can merge it into the LO_SUM.  */
      if (GET_MODE (memref) != BLKmode
          && GET_CODE (addr) == LO_SUM
          && known_in_range_p (offset,
                               0, (GET_MODE_ALIGNMENT (GET_MODE (memref))
                                   / BITS_PER_UNIT)))
        addr = gen_rtx_LO_SUM (address_mode, XEXP (addr, 0),
                               plus_constant (address_mode,
                                              XEXP (addr, 1), offset));

[Bug middle-end/100604] GCC generates invalid LO_SYM for unaligned global

[dragan.mladjenovic at syrmia dot com]

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

--- Comment #2 from dragan.mladjenovic at syrmia dot com ---
It seems so. Something like this helps in this case:

diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index 07e908624a0..a102a9288c5 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -2385,7 +2385,7 @@ adjust_address_1 (rtx memref, machine_mode mode,
poly_int64 offset,
       if (GET_MODE (memref) != BLKmode
          && GET_CODE (addr) == LO_SUM
          && known_in_range_p (offset,
-                              0, (GET_MODE_ALIGNMENT (GET_MODE (memref))
+                              0, (MIN (GET_MODE_ALIGNMENT (GET_MODE (memref)),
attrs.align)
                                   / BITS_PER_UNIT)))
        addr = gen_rtx_LO_SUM (address_mode, XEXP (addr, 0),
                               plus_constant (address_mode,

Don't know which one to trust. The memref has SImode. Caller wants to create
HImode one. The attrs.align matches that of HImode.

[Bug middle-end/100604] GCC generates invalid LO_SYM for unaligned global

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to dragan.mladjenovic from comment #2)
> It seems so. Something like this helps in this case:
> 
> diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
> index 07e908624a0..a102a9288c5 100644
> --- a/gcc/emit-rtl.c
> +++ b/gcc/emit-rtl.c
> @@ -2385,7 +2385,7 @@ adjust_address_1 (rtx memref, machine_mode mode,
> poly_int64 offset,
>        if (GET_MODE (memref) != BLKmode
>           && GET_CODE (addr) == LO_SUM
>           && known_in_range_p (offset,
> -                              0, (GET_MODE_ALIGNMENT (GET_MODE (memref))
> +                              0, (MIN (GET_MODE_ALIGNMENT (GET_MODE
> (memref)), attrs.align)
>                                    / BITS_PER_UNIT)))
>         addr = gen_rtx_LO_SUM (address_mode, XEXP (addr, 0),
>                                plus_constant (address_mode,
> 
> Don't know which one to trust. The memref has SImode. Caller wants to create
> HImode one. The attrs.align matches that of HImode.

on a strict-align target if the MEM has SImode it should be aligned to
the SImode alignment.  Of course generally you should never look at
GET_MODE_ALIGNMENT but use attrs.align unconditionally (aka MEM_ALIGN).

Now the question is where the HImode aligned MEM:SI comes from for
a strict-alignment target.  That said, unconditionally using attrs.align
looks like the correct fix.

[Bug middle-end/100604] GCC generates invalid LO_SYM for unaligned global

[dragan.mladjenovic at syrmia dot com]

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

--- Comment #4 from dragan.mladjenovic at syrmia dot com ---
It seems to be copied from the owning var_decl align in
vararsm.c:assemble_variable. Now when optimizing that happens at a later stage
and rtx gets created lazily from var_decl and has only mode alignment. That's
why on -O or greater middle-end doesn't try to expand unaligned access, which
might be an issue in itself.

[Bug middle-end/100604] GCC generates invalid LO_SYM for unaligned global

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pangbw at gmail dot com

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 106818 has been marked as a duplicate of this bug. ***

[Bug middle-end/100604] GCC generates invalid LO_SYM for unaligned global

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-11-29
     Ever confirmed|0                           |1

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
.

[Bug middle-end/100604] GCC generates invalid LO_SYM for unaligned global

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |patrick at rivosinc dot com

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 114756 has been marked as a duplicate of this bug. ***

[Bug middle-end/100604] GCC generates invalid LO_SYM for unaligned global

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note this linker relaxation code could be more forgiving here and not producing
"wrong-code" but GCC should be fixed still.