https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at gcc dot gnu.org
--- Comment #2 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Tomasz Kamiński from comment #1)
> This is probably effect on changing !lt(a,b) && !lt(b, a) into !(a<b) &&
> !(b<a) and then a == b. Then following comparision is unspecified according
> to 5.10 [expr.eq] p2.1:
> If at least one of the operands is a pointer, pointer conversions (4.11),
> function pointer conversions (4.13), and qualification conversions (4.5) are
> performed on both operands to bring them to their composite pointer
> type (Clause 5). Comparing pointers is defined as follows:
> — (2.1) If one pointer represents the address of a complete object, and
> another pointer represents the address one past the last element of a
> different complete object, the result of the comparison is unspecified.
>
> However I believe that in light of 20.14.6 [comparisons] p14, above
> transformation is not allowed.
I don't see this as prohibiting the transformation. The standard seems to be
saying that they might or might not compare as equal, which presumably depends
on how variables are laid out in memory. The optimization seems wrong to me.
