https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127925
liu zhenyu <lzy20000419 at outlook dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |lzy20000419 at outlook dot com
--- Comment #5 from liu zhenyu <lzy20000419 at outlook dot com> ---
`fold_ctor_reference` refuses a reverse-storage-order aggregate at the
*outermost* constructor, but when a
reverse-order struct is nested inside a normal-order constant, the outer call
falls back to
`native_encode_initializer`, which has no notion of reverse storage order. That
is the same encoder this PR
is about (via `constant_byte_string`).
```c
struct __attribute__((scalar_storage_order ("big-endian"))) RB { unsigned w; };
struct NB { struct RB in; };
static const struct NB g = { { 0x01020304u } };
__attribute__((noipa)) int f (void) { return ((const unsigned char *) &g)[0]; }
int main (void) { if (f () != 1) __builtin_abort (); return 0; }
```
```
$ gcc -O0 t.c && ./a.out # ok (and .rodata is 01 02 03 04)
$ gcc -O1 t.c && ./a.out # Aborted (f returns 4)
```
Fails at -O1 and above from GCC 6.3 through trunk. An array of reverse-order
structs fails the same way.
The byte is read through `unsigned char`, which is allowed (gcc.dg/sso-7.c /
this PR).
If the fix for PR127925 is put into `native_encode_initializer` itself it
covers this; if it only blocks
`constant_byte_string` it does not. The memcpy-of-SSO-constant shape already
belongs here as a sibling.
Disclaimer: This test case was generated by a fuzzer, and the report was
written with LLM assistance.
