[Bug c/116357] New: The item's address of the array is not correct if aligned is used

[Bug c/116357] New: The item's address of the array is not correct if aligned is used

[alwin.zhang at sap dot com]

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

            Bug ID: 116357
           Summary: The item's address of the array is not correct if
                    aligned is used
           Product: gcc
           Version: 10.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: alwin.zhang at sap dot com
  Target Milestone: ---

Created attachment 58922
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58922&action=edit
Test code to reproduce the issue.

The item's address of the array is not correct if aligned is used on the type
of array item. The debug version (without gcc optimization) doesn't have the
issue, but if we enable optimization like -O1/O2, all the items of the array
are using the same address.
Attached file is the test code to reproduce the issue. This issue could be
reproduced from gcc 7.1 to latest 14.2.

From following asm code we can see that the items of the array are using the
same address.

C code is -
------------------
u64 * l1;
u64 * l2;
void align_test(chn_t * p)
{
        l1 = (u64*)(&(p->lock[0]));
        l2 = (u64*)(&(p->lock[99]));
        printf("addr is [0]=%llu, [99]=%llu\n", l1, l2);
}
------------------

asm code is -
------------------
align_test:
        sub     rsp, 8
        mov     rsi, rdi
        mov     QWORD PTR l1[rip], rdi
        mov     QWORD PTR l2[rip], rdi
        mov     rdx, rdi
        mov     edi, OFFSET FLAT:.LC0
        mov     eax, 0
        call    printf
        add     rsp, 8
        ret
------------------

Please download the test code and compile with gcc optimization like -O2 to
check the issue.

Bug 65204 appears to be the same as this issue, but it's resolved. 

Thanks!

[Bug tree-optimization/116357] [12/13/14/15 Regression] The item's address of the array is not correct if aligned is used

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |tree-optimization
      Known to work|                            |6.5.0
      Known to fail|                            |7.1.0
            Summary|The item's address of the   |[12/13/14/15 Regression]
                   |array is not correct if     |The item's address of the
                   |aligned is used             |array is not correct if
                   |                            |aligned is used
   Target Milestone|---                         |12.5
           Keywords|                            |wrong-code

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This was rejected in GCC 5.4-4.7.0 .
But produced wrong code at -O1 and above starting in GCC 7.1.0.

[Bug tree-optimization/116357] [12/13/14/15 Regression] The item's address of the array is not correct if aligned is used

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The linked PRs kinda of point out this is invalid code and should be rejected
...

[Bug tree-optimization/116357] [12/13/14/15 Regression] The item's address of the array is not correct if aligned is used

[alwin.zhang at sap dot com]

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

--- Comment #3 from Alwin Zhang <alwin.zhang at sap dot com> ---
Hi Andrew,
Do you mean that gcc should give an error like old version?
For example,
error: alignment of array elements is greater than element size

[Bug tree-optimization/116357] [12/13/14/15 Regression] The item's address of the array is not correct if aligned is used

[alwin.zhang at sap dot com]

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

--- Comment #4 from Alwin Zhang <alwin.zhang at sap dot com> ---
Hello experts,
What do you think about the fact that it only happens when using -O1/2/3?
It seems like the other issues linked have nothing to do with that fact.

[Bug c/116357] [12/13/14/15 Regression] The item's address of the array is not correct if aligned is used

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|tree-optimization           |c
   Last reconfirmed|                            |2024-09-17
                 CC|                            |jsm28 at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
The optimization issue is because we have an element type that looks like

 <integer_type 0x7ffff69b27e0 spinlock_t volatile unsigned SI
    size <integer_cst 0x7ffff6824198 type <integer_type 0x7ffff68220a8
bitsizetype> constant 32>
    unit-size <integer_cst 0x7ffff68241b0 type <integer_type 0x7ffff6822000
sizetype> constant 4>
    user align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff69b2738 precision:32 min <integer_cst 0x7ffff68241c8 0> max <integer_cst
0x7ffff6824180 4294967295>
    pointer_to_this <pointer_type 0x7ffff69dd540>>

in particular with TYPE_ALIGN > TYPE_SIZE which is a "cannot happen".  Because
ARRAY_REF records the element size in units of element alignment this ends
up as zero ...

In this case value-numbering makes ARRAY_REF OP2 explicit while keeping it
implicit ends up being "fine" (fine as in still densely packing
spinlock_t and thus giving elements wrong alignment).

I wonder whether the bug is that sizeof (spinlock_t) is 4, but of course
that might be difficult to change.  But I suppose this is also how C works;
possibly the C frontend should build a variant type of the element type
if over-alignment should be ignored - putting in the over-aligned type
most definitely breaks the middle-end with regard to how ARRAY_REF is
defined.

This is a C frontend issue, it produces wrong GENERIC.

[Bug c/116357] [12/13/14/15 Regression] The item's address of the array is not correct if aligned is used

[alwin.zhang at sap dot com]

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

--- Comment #6 from Alwin Zhang <alwin.zhang at sap dot com> ---
Thank you Richard for your detailed elaboration.