https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97595
--- Comment #5 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #3)
> I can confirm the warning but I'm not sure the bug is in the middle end
> code. Let me CC Jason for his comments.
>
> The warning triggers for the MEM_REF below:
>
> MEM[(char &)_10 + 224] = _24;
>
> in the following GIMPLE ("type" is char). The destination of the access is
> this_3(D)->D.45669 which is the basic_istream subobject. Its size reported
> by DECL_SIZE_UNIT() in component_ref_size() is 16. The initial offset
> (i.e., _10) is indeterminate but it's taken to be in the range bounded by
> the size of the object, or [0, 16]. Given that, the constant offset 224 is
> determined to be out of bounds.
What you're seeing is that the DECL_SIZE of the base subobject excludes any
virtual bases, because they are laid out in the most derived class, while the
TYPE_SIZE of the base type includes them. CLASSTYPE_SIZE of the base type
should match the DECL_SIZE.
It's definitely OK for a program to refer to a virtual base through any of the
derived classes.
> The change introduced in r11-3827 that triggers the warning is the assumption
> > that unless determined otherwise, an indeterminate offset into an object
> must > be bounded by the object's size.
So this assumption is invalid for base subobjects of types with virtual bases;
such an offset is only bounded by the most-derived object's size.
