https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124148
--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Yiwei Zhang from comment #8)
> Sorry, one last question:
>
> Inside the sizeof_pnext helper, there's the sizeof_B_self function to access
> the pNext with the original type B, is it still valid for the compiler to
> DSE the initial pNext assignment?
>
> > ./gcc_dse.c.122t.dse2:76: Deleted dead store: a.pNext = &b;
>
> If so, the only solid workaround would be -fno-strict-aliasing
There is no access that happens with respect to sizeof_B_self. there is a cast
and then a `&val->dummy` BUT the IR that is just considered a pointer
arithmetic and not really an access Yes in C it is considered an access but it
does not matter since there is already violation of the C/C++ aliasing rules
happening that happened right beforehand.
since a violation is the aliasing rules is considered undefined behavior then
anything afterwards does not matter (before the undefined behavior things would
be defined but this is after).
If we change just CHAIN_TYPE_B case part to:
```
case CHAIN_TYPE_B:
{
const B *b = (const B*)pnext;
size += sizeof_simple_pointer(pnext);
size += sizeof_uint32_t(&pnext->sType);
size += sizeof_pnext(b->pNext);
size += sizeof_B_self((const B*)pnext);
}
return size;
```
It works as this is doing an access to pNext field via B.
sType is less of an issue really.
But this is just a small example of the full code and using the correct type
without a base type is just asking for troubles later on.
