On Tue, Nov 24, 2020 at 10:56:46AM +0000, Richard Biener wrote:
> On Tue, 24 Nov 2020, Jakub Jelinek wrote:
> > As mentioned in the PR, we currently ICE on flexible array members in
> > structs and unions during __builtin_clear_padding processing.
> >
> > Jason said in the PR he'd prefer an error in these cases over forcefully
> > handling it as [0] arrays (everything is padding then) or consider the
> > arrays to have as many whole elements as would fit into the tail padding.
> >
> > So, this patch implements that.
> >
> > Ok for trunk if it passes bootstrap/regtest? So far has been tested just
> > on the dg.exp=builtin-clear-padding* dg-torture.exp=builtin-clear-padding*
> > check-gcc check-c++-all testsuite, but the builtin is currently not used
> > in anything else.
>
> So code-gen wise this will still elide the builtin but error, right?
Yes.
> OK then.
>
> Note it still leaves struct { int n; char c[1]; } to be handled
> which I think is the actual way we'll face "flexarray" members.
>
> IMHO we need to treat them as data but maybe we should emit a warning?
This is only about std::atomic used with such type, for the above, one
can safely use on common ABIs only at most 4 elements of the array, more
just wouldn't work anyway. And for the warning I'd think people would be
annoyed by that then they treat it like an array (i.e. the only thing the
standard allows, because they don't do anything wrong and it would be hard
to avoid the warning (only add pragmas somewhere, but where exactly, on all
the method calls of the atomic and constructors?), rather than poor man's
flexible array member.
Jakub
