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

["dragan.mladjenovic at syrmia dot com" <gcc-bugzilla@gcc.gnu.org>]

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.