https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120980
--- Comment #3 from Krister Walfridsson <kristerw at gcc dot gnu.org> --- (In reply to Richard Biener from comment #2) > We do not want to introduce additional code generation overhead to avoid a > fully out-of-bounds but known not trapping because it's known to fall into > the same page as a previous partly not out-of-bounds access. But I realize > this altered constraint might be difficult to implement in the > analysis tool? It is easy to modify smtgcc's in-range check to treat loads as valid if the loaded bytes are within the same page as bytes of the object identified by the pointer's provenance. But this is far too permissive, and it's easy to construct examples that get miscompiled under that semantic. So we must add additional restrictions on fully out-of-bounds loads. But I have no idea what kind of restrictions would make sense... And there are more problems. For example, how does a fully out-of-bounds load interact with pointer provenance? The out-of-bounds bytes do not correspond to the provenance and may even belong to a different object, so the provenance check will still classify the load as UB, even if we relax the in-range check.
