[Bug c/105588] New: _Alignof (C) and alignof (C++) on dereference of `double *` disagree on 32-bit x86

[Bug c/105588] New: _Alignof (C) and alignof (C++) on dereference of `double *` disagree on 32-bit x86

[hstong at ca dot ibm.com]

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

            Bug ID: 105588
           Summary: _Alignof (C) and alignof (C++) on dereference of
                    `double *` disagree on 32-bit x86
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hstong at ca dot ibm.com
  Target Milestone: ---
            Target: x86_64-pc-linux-gnu

_Alignof(expression) on a dereference of a pointer to double of unknown value
should produce the ABI-required alignment and not the preferred alignment.

The equivalent C++ program behaves as expected.
Online compiler link: https://godbolt.org/z/Tb93a6fcT

### SOURCE (<stdin>):
void f(double *pd) {
  extern char x[_Alignof(double)];
  char (*y)[_Alignof(*pd)] = &x;
}


### COMPILER INVOCATION COMMAND:
gcc -m32 -fsyntax-only -xc -


### ACTUAL OUTPUT:
<stdin>: In function 'f':
<stdin>:3:30: warning: initialization of 'char (*)[8]' from incompatible
pointer type 'char (*)[4]' [-Wincompatible-pointer-types]


### EXPECTED OUTPUT:
(No "incompatible pointer types" warning)


### COMPILER VERSION INFO (`gcc -v`):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/gcc
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220511 (experimental) (GCC)

[Bug c/105588] _Alignof (C) and alignof (C++) on dereference of `double *` disagree on 32-bit x86

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
_Alignof(expression) is still an extension it can return what ever GCC decides
....

[Bug c/105588] _Alignof (C) and alignof (C++) on dereference of `double *` disagree on 32-bit x86

[hstong at ca dot ibm.com]

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

--- Comment #2 from Hubert Tong <hstong at ca dot ibm.com> ---
(In reply to Andrew Pinski from comment #1)
> _Alignof(expression) is still an extension it can return what ever GCC
> decides ....

Sure, although why GCC should have corresponding C and C++ extensions that
behave differently from each other is a bit of a mystery here.

[Bug c/105588] _Alignof (C) and alignof (C++) on dereference of `double *` disagree on 32-bit x86

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
_Alignof(expression) works like __alignof__(expression) which works like
__alignof__(__typeof(expression)), while _Alignof(type_name) is mandated by the
standard to work differently.
The difference is that in the ia32 psABI, double is normally 8 byte aligned,
except when inside of struct/union where the alignment is lowered to 4 byte
alignment.
Changing any of this would be a significant ABI change.

[Bug c/105588] _Alignof (C) and alignof (C++) on dereference of `double *` disagree on 32-bit x86

[hstong at ca dot ibm.com]

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

--- Comment #4 from Hubert Tong <hstong at ca dot ibm.com> ---
(In reply to Jakub Jelinek from comment #3)
> _Alignof(expression) works like __alignof__(expression) which works like
> __alignof__(__typeof(expression)), while _Alignof(type_name) is mandated by
> the standard to work differently.

Except it doesn't work that way. `__alignof__(expression)` is sensitive to what
the expression is in ways other than its type:
https://godbolt.org/z/GjETGnaGn
```
struct A {
  double d;
} a;
void f() {
  extern char x[__alignof__(__typeof(a.d))];
  char (*y)[_Alignof(a.d)] = &x; // warns
}
```

So, if it cares what the expression refers to, then when what is referred to is
unknown, the question becomes what `_Alignof` means: Is it the guaranteed
alignment (of what you were given) or the preferred alignment (for what you
might allocate)?

`_Alignof` already means "guaranteed alignment" in `_Alignof(type)`.

> The difference is that in the ia32 psABI, double is normally 8 byte aligned,
> except when inside of struct/union where the alignment is lowered to 4 byte
> alignment.
> Changing any of this would be a significant ABI change.

There is no request here to change the result of the actual allocation used for
layout or allocation purposes. Just a request to make GNU C's
`_Alignof(expression)` consistent with GNU C++'s `alignof(expression)` (both
being GNU extensions).