[Bug c/107339] New: RISC V -mstrict-align

[Bug c/107339] New: RISC V -mstrict-align

[yy172179 at 163 dot com]

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

            Bug ID: 107339
           Summary: RISC V -mstrict-align
           Product: gcc
           Version: 12.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: yy172179 at 163 dot com
  Target Milestone: ---

When I use GCC12 to compile the files  with - march=rv32imac - mabi=ilp32 -
mstrict align - c option，then objdump it.I found that the assembly code will
use “LW” instruction to access  Non aligned address. Causing hardware errors。
Here's an example

#include<stdio.h>

typedef  struct  __attribute__((packed)) misalign
{
    uint8_t rseq[16];
    uint8_t type;
    uint8_t cnt;
} misalign_t;
void  tttt (misalign_t* t){

    printf("%x\n",(*(const uint32_t*)&t->rseq[0]));
    printf("%x\n",(*(const uint32_t*)&t->rseq[1]));
}
int main()
{

    misalign_t  abc;
    misalign_t *test=&abc;
    tttt(test);
        while(1); 
   }

What compilation options or settings can I use to avoid this situation, or is
this a bug？？

[Bug target/107339] RISC V -mstrict-align

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The code is broken.

uint32_t here is aligned to 32bits and you access it via that type.


this is the correct fix:


typedef uint32_t uint32_t_ua __attribute__((aligned(1)));

void  tttt (misalign_t* t){

    printf("%x\n",(*(const uint32_t_ua *)&t->rseq[0]));
    printf("%x\n",(*(const uint32_t_ua *)&t->rseq[1]));
}

[Bug target/107339] RISC V -mstrict-align

[yy172179 at 163 dot com]

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

--- Comment #2 from yy <yy172179 at 163 dot com> ---
(In reply to Andrew Pinski from comment #1)
> The code is broken.
> 
> uint32_t here is aligned to 32bits and you access it via that type.
> 
> 
> this is the correct fix:
> 
> 
> typedef uint32_t uint32_t_ua __attribute__((aligned(1)));
> 
> void  tttt (misalign_t* t){
> 
>     printf("%x\n",(*(const uint32_t_ua *)&t->rseq[0]));
>     printf("%x\n",(*(const uint32_t_ua *)&t->rseq[1]));
> }
(In reply to Andrew Pinski from comment #1)
> The code is broken.
> 
> uint32_t here is aligned to 32bits and you access it via that type.
> 
> 
> this is the correct fix:
> 
> 
> typedef uint32_t uint32_t_ua __attribute__((aligned(1)));
> 
> void  tttt (misalign_t* t){
> 
>     printf("%x\n",(*(const uint32_t_ua *)&t->rseq[0]));
>     printf("%x\n",(*(const uint32_t_ua *)&t->rseq[1]));
> }
Maybe I didn't make the problem clear. To add, I think the non aligned address
"lw" will be converted to "lbu" to access this address indirectly. Change the
above code parameters to the structure, and the situation I think is correct
will occur.

#include<stdio.h>

typedef  struct  __attribute__((packed)) misalign
{
    uint8_t rseq[16];
    uint8_t type;
    uint8_t cnt;
} misalign_t;
void  tttt (misalign_t t){

    printf("%x\n",(*(const uint32_t*)&t.rseq[0]));
    printf("%x\n",(*(const uint32_t*)&t.rseq[1]));
}
int main()
{

    misalign_t  abc;
    misalign_t *test=&abc;
    tttt(abc);
        while(1); 
   }

[Bug target/107339] RISC V -mstrict-align

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Again, the problem is the access via uint32_t which says it is an aligned
access.
This is why you need uint32_t_ua there.

[Bug target/107339] RISC V -mstrict-align

[yy172179 at 163 dot com]

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

--- Comment #4 from yy <yy172179 at 163 dot com> ---
It works to use "uint32_t_ua", but it still works to use "uint32_t" and just
change the function parameter from the structure pointer to the structure. "The
following is the assembly code
    0:   00154703                lbu     a4,1(a0)
 4:   00054783                lbu     a5,0(a0)
 8:   00354583                lbu     a1,3(a0)
 c:   0722                    slli    a4,a4,0x8
 e:   8f5d                    or      a4,a4,a5
10:   00254783                lbu     a5,2(a0)
14:   1141                    addi    sp,sp,-16
16:   c226                    sw      s1,4(sp)
18:   07c2                    slli    a5,a5,0x10
1a:   8fd9                    or      a5,a5,a4
1c:   000004b7                lui     s1,0x0
20:   05e2                    slli    a1,a1,0x18
22:   c422                    sw      s0,8(sp)
24:   8ddd                    or      a1,a1,a5
26:   842a                    mv      s0,a0
28:   00048513                mv      a0,s1
2c:   c606                    sw      ra,12(sp)
2e:   00000097                auipc   ra,0x0
32:   000080e7                jalr    ra # 2e <tttt+0x2e>
36:   00244703                lbu     a4,2(s0)
3a:   00144783                lbu     a5,1(s0)
3e:   00444583                lbu     a1,4(s0)
42:   0722                    slli    a4,a4,0x8
44:   8f5d                    or      a4,a4,a5
46:   00344783                lbu     a5,3(s0)
4a:   05e2                    slli    a1,a1,0x18
4c:   00048513                mv      a0,s1
50:   07c2                    slli    a5,a5,0x10
52:   8fd9                    or      a5,a5,a4
54:   8ddd                    or      a1,a1,a5
56:   00000097                auipc   ra,0x0
5a:   000080e7                jalr    ra # 56 <tttt+0x56>
5e:   00444703                lbu     a4,4(s0)
62:   00344783                lbu     a5,3(s0)
66:   00644583                lbu     a1,6(s0)
6a:   0722                    slli    a4,a4,0x8
6c:   8f5d                    or      a4,a4,a5
6e:   00544783                lbu     a5,5(s0)
72:   4422                    lw      s0,8(sp)
74:   40b2                    lw      ra,12(sp)
76:   07c2                    slli    a5,a5,0x10
78:   00048513                mv      a0,s1
7c:   4492                    lw      s1,4(sp)
7e:   8fd9                    or      a5,a5,a4
80:   05e2                    slli    a1,a1,0x18
82:   8ddd                    or      a1,a1,a5
84:   0141                    addi    sp,sp,16
86:   00000317                auipc   t1,0x0
8a:   00030067                jr      t1 # 86 <tttt+0x86>

[Bug target/107339] RISC V -mstrict-align

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
That is because with the non pointer case gcc can figure out the alignment
without having to assume via pointers.

Note the original code is also undefined by the c standard even the non pointer
case you gave, it just happens to work is not a reason to depend on it.