https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103839
--- Comment #3 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to Jakub Jelinek from comment #2)
> For __builtin_clear_padding builtin, that behavior is completely
> intentional, for unions the compiler most of the time doesn't know which
> union member is currently active, so it acts conservatively, only clears
> bits that are padding bits in all union members rather than some of them.
> For the internal uses of the __builtin_clear_padding code we'd need some way
> how to tell the code which union member is the currently active one so that
> it could work differently.
OK, poking around in another language, I certainly understand this considering
that C++ allows some more contrived cases.
union U
{
struct { char a; int b; } c;
struct { int d; char e; } f;
};
U u = { .f={1, 2} };
D certainly only considers the first field to be the definitive shape of the
object, so it's not possible to initialize it in a constructor like the above.
I'll just go ahead with DECL_PADDING_P for now, as I can't see any downsides
just yet on doing so.
