On Thu, 3 Sep 2026, Eric Botcazou wrote:
> > To get the data flow yes, but of course the FRE issue is that
> > the SSO attribution is lost and we generate wrong code, so actual
> > SSO attribution is needed for that.
>
> Sure, but we do not support type punning when it toggles the storage order
> and
> this testcase does that (admittedly in a more subtle way than most cases, as
> you need to realize that the bit order is implicitly changed for bitfields).
Hmm, does it? You mean
/* Reversed bit order, so this gives f7 == 1 and f6 == 4. */
*(char *) &g.f3 = 0x24;
? But this is just
memset (&g.f3, 1, 0x23);
as it writes a single byte via a character type there is no storage
order involved?
The
q = (struct S0 *) ((char *) &l + __builtin_offsetof (struct S1, f3));
is just a way to get an offsetted MEM_EXPR I guess, it's also not
punning.
> What needs to be prevented is the optimization of:
>
> g.f3 = { 1, 4 };
>
> into
>
> *(char *) &g.f3 = ...
>
> because the SSO attribution is indeed lost.
I think what happened is that
return q->f7;
gets re-written through
l = g;
and that then picks up the *(char *) &g.f3 store, eliding the SSO
of the q->f7 access.
> > I was mostly questioning SSO on bitfields given bitfield layout might
> > be special. I suppose avoiding padding in S0 might make this more
> > portable (so signed/unsigned char for f7/f6). The testcase fails
> > with that as well before the fix.
>
> SSO on bitfields was the motivating case in Ada though.
I see. I have simplified S0 by using 'char' as type for the bitfields,
avoiding any bit padding.
Do you think this is a non-bug that is fixed? If not I plan to push it.
Thanks,
Richard.
