https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117912
--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #19)
> (In reply to Jakub Jelinek from comment #12)
> > rejects-valid seems inappropriate here, sure, with the error attribute one
> > can error on all kinds of things and so most missed optimizations could be
> > that way rejects-valid as well.
> > I think it is wrong-code, __builtin_object_size (x, 1) is supposed to return
> > the minimum object size, so returning something smaller (like here 0) than
> > the minimum (which isn't really known, because we don't see what allocated
> > it and it is flexible array member) is wrong-code, returning something
> > larger is perhaps missed optimization (but we document that it can always
> > give up and return something more conservative up to all ones).
>
> I'd have expected that "conservative" for minimum works the other way
> around, so zero should be the fallback, not infinity?
For __bos 0/1 modes conservative return is ~(size_t)0 or perhaps something
larger than the actual minimum.
For __bos 2/3 modes conservative return is 0 or perhaps something smaller than
the actual maximum.
If __bos 0 and 2 (or 1 and 3) returns the same value, it means the size is
exact, otherwise it gives a range of valid values (so if we punt on both, [0,
~(size_t)0]).
That said, __bos 1/3 cares about the size of the innermost COMPONENT_REF in the
access path. So perhaps for !(cfun->curr_properties & PROP_objsz) && !derefN
(for deref we actually care about the MEM_REF size and only the address)
remember the innermost COMPONENT_REF and punt if the two FIELD_DECLs have (or
for VL could have) different DECL_SIZE_UNIT or different start or one of them
is flexible array like and the other one is followed by some other field? I
think we don't necessarily need to care about other sizes, say
union U { struct { int a; char b[10]; int c; } d; struct { int e; char f[10];
char g[24]; } h; };
&p->d.b[2]
&p->h.f[2]
can be VN the same, even when d and h have different sizes. Though, for the
outer COMPONENT_REFs perhaps we need to take into account whether it is the
last FIELD_DECL or not (as last FIELD_DECL can be in the end flexible array
like, while when followed by other FIELD_DECLs even if it is flexible array
like it can't).
