https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
--- Comment #7 from Martin Sebor <msebor at gcc dot gnu.org> --- I asked Peter about that yesterday. The access to *p in your example is still meant to be undefined even under the proposed provenance rules. Here's his response: http://www.open-std.org/jtc1/sc22/wg14/15051 It's not yet entirely clear to me how to derive this answer from the proposed wording but if it can't be it's presumably just a bug that will be fixed. I think the intent of the "happens to immediately follow the first array object in the address space" was to allow implementations to return true for the (&a + i == &b) kind of equalities and the text just came out wrong (as a requirement rather than a permission). The text was added in C99 but I haven't yet been able to find the paper that added it. The implications of the "immediately follows the first array" sentence for equality having to return true would be at odds with the "single provenance" and so the result of the equality is only specified with -fno-provenance (otherwise it's unspecified). Regarding your suggestion for the equality being undefined, since it's well-defined in C and explicitly unspecified in C++, changing it to undefined in C would introduce an incompatibility with C++. That would go against WG14's goal (part of C2X charter) to align more closely with C++. To make it pass in WG14, C++ would most likely have to agree to change first. But I'll bring it up during the meeting. The rationale for the-f[no-]provenance option is discussed in N2119. It sounds like the authors think it disabling the provenance rules might make for more intuitive behavior and help avoid bugs. I'll also bring it at the meeting.
