[Bug tree-optimization/115582] New: [regression 15] wrong code when accessing members of incompatible type structure

[Bug tree-optimization/115582] New: [regression 15] wrong code when accessing members of incompatible type structure

[tangyixuan at mail dot dlut.edu.cn]

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

            Bug ID: 115582
           Summary: [regression 15] wrong code when accessing members of
                    incompatible type structure
           Product: gcc
           Version: 15.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tangyixuan at mail dot dlut.edu.cn
  Target Milestone: ---

Hi, I find GCC produces wrong code under optimizations when pointers point to
incompatible type structure but the member types are compatible.

Compiler Explorer: https://godbolt.org/z/jjY599Yfe

$ cat s.c

int printf(const char *, ...);
struct s {int x; } __attribute__((packed));
struct t {int x; };

void swap(struct s* p, struct t* q)
{
  p->x = q->x;
  q->x = p->x;
}
int main()
{    
  struct t a[2];
  a[0].x = 1234;
  a[1].x = 5678;
  swap ((struct s *)((char *)a + 1), a);
  printf("%d",a[0].x);
  return 0;
}

[Bug tree-optimization/115582] [15 regression] wrong code when accessing members of incompatible type structure

[sjames at gcc dot gnu.org]

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

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[regression 15] wrong code  |[15 regression] wrong code
                   |when accessing members of   |when accessing members of
                   |incompatible type structure |incompatible type structure

--- Comment #1 from Sam James <sjames at gcc dot gnu.org> ---
Please give compiler options to reproduce.

[Bug tree-optimization/115582] [15 regression] wrong code when accessing members of incompatible type structure

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-06-21

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The godbolt is at -O3.

But these two structures are not compatible at all.
In c structs are not compatible just because they have the same fields. So they
can't alias.

Why do you think they can alias?

[Bug tree-optimization/115582] [15 regression] wrong code when accessing members of incompatible type structure

[sjames at gcc dot gnu.org]

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

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sjames at gcc dot gnu.org

--- Comment #3 from Sam James <sjames at gcc dot gnu.org> ---
Ah, I was comparing -O0 vs -O{2,3} & -fno-sa given it's aliasing. I didn't
think it was well-defined but wanted you to chip in.

[Bug tree-optimization/115582] [15 regression] wrong code when accessing members of incompatible type structure

[tangyixuan at mail dot dlut.edu.cn]

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

--- Comment #4 from tangyixuan <tangyixuan at mail dot dlut.edu.cn> ---
Thanks for your concerns. The type of "a.x" is converted to char in "(char *)a
+ 1", and it may be confused in clang under -O0 vs -O{2,3}. gcc-15 outputs the
"int" value, but the previous versions like gcc-5.3 produce the "char" value I
guess.

[Bug tree-optimization/115582] [15 regression] wrong code when accessing members of incompatible type structure

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The cast to char* does nothing except getting a pointer. Violation of aliasing
rules in c/c++ is all about what type is doing the access.

In this case the accesses are via the two structs. Note the fields might have
the same type and both can be accessed via int without any undefinedness, they
cannot be accessed via the each other struct types.

[Bug tree-optimization/115582] [15 regression] wrong code when accessing members of incompatible type structure

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #6 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
FWIW there are too many online articles discussing aliasing rule but failing to
get the concept correct.  As Andrew has explained the aliasing rule is all
about the type used for accessing a lvalue, it's not related to pointer
casting, at all.

Checking against pointer casting is just a heruistic way for finding aliasing
bugs and it may have false positives or false negatives.  This renders
-Wstrict-aliasing almost useless.

If a pointer cast to (T *) made the type alias with T, the aliasing rule would
be meaningless because in a different TU (that the compiler cannot see) any
pointer can be casted to anything.  For example, *everything* is casted to
(char *) in Glibc memcpy() thus *everything* would be aliasing.  This would be
obviously irrational.