https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84050
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to fail|10.0 |10.2.0, 11.0
--- Comment #7 from Martin Sebor <msebor at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #2)
...
> I'm not a language lawyer, so I don't know what the semantics of undefined
> behavior is. Is returning 0 even the correct thing to do?
Anything goes for undefined behavior so folding the access to zero is strictly
valid. But doing it silently, without issuing a warning designed to detect
this bug, is at a minimum unfriendly (I'd even say it's a bug in the warning).
I believe the problem is in fold_nonarray_ctor_reference(): the function
doesn't make sure the reference is in bounds of the object. It simply returns
zero when it isn't om the assumption reflected in a comment removed in r274837:
/* Memory not explicitly mentioned in constructor is 0. */
The function assumes that when the constructor is smaller than the type of the
declared object the reference is to an element of the object. But that's only
true for valid references, not for those that are out of bounds. So before
returning zero, the function should check that the offset into the object plus
the element size doesn't exceed the size of the object and if it does, return
null.
I suspect a fix wouldn't be considered in stage 4 of GCC 11 but it's something
to look into for GCC 12.
