https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 11 Apr 2018, msebor at gcc dot gnu.org wrote: > 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 Even with -fno-provenance? > 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. OK, even GCC might end up computing true if we don't optimize but translate to a cmp instruction and var layout happens to be. Like for -O0 and int *p = &a + i; int *q = &b; if (p == q) ... but at -O1 we'd always compute it as false. > 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 I think for the compiler "unspecified" works as well - we can still unconditionally optimize it to return false, correct? > 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. The issue I see is that implementing -fno-provenance is impossible (well, we might be able to alias it to -O0 and disable all folding). But I don't have time to read up its full specification/rationale right now.
