There is no requirement that optimization does not change behaviour. The only requirement is that the optimized behavior remains consistent with the standards. The point of the point on floating point equality is that the standards give enough room for variance that you should not use literal equality unless you know exactly what you are doing and have a good reason for doing it.

As an aside, if your concern is that the standards impose too much restrictions, another popular option is the ffast-math option.

We see this come up with strings fairly often in higher level languages where, sometimes, logical equal strings will happen to be equal because the runtime's interning system made them point to the same location, but there is no guarantee this would happen and the implementation is free to change it at any point. I believe I have also seen this behaviour come up with interning on some Integer wrapper types.

No, optimizations are allowed to change the ordering or exact implementations, but they cannot change observable behavior unless the behavior depends on undefined (e.g the compiler is the adversary) or unspecified (in which the compiler is required to be self-consistent, e.g parameter evaluation order is (was?) unspecified so a compiler could choose left to right or right to left evaluation, but it must pick one and use that everywhere).

The C abstract machine defines the behavior, and optimization passes aren't allowed to change the behavior.

-ffast-math is the option that allows incorrect semantics (e.g commutative floating point addition), but compilers have a desire to do incorrect things for "performance".

I would hope it is obvious that changing behavior for performance isn't ok, but lets say it was. A compiler could change

y=1.0/fsqrt(x)

from (v. approximate, untested, and written in a text box :D)

movsd xmm0, $(wherever x is) sqrtsd xmm0 movsd xmm1, $(location of 1.0 constant) divsd xmm1, xmm0 movsd $(addr of y), xmm1

to something like

movsd xmm0, $(wherever x is) rsqrtsd xmm0 movsd $(addr of y), xmm0

This would be much much faster, and vastly incorrect (IIRC rsqrt is only 12bits of precision)

Or even more dumb, remove calls to printf, because printf is slow.

A compiler does not have absolute leeway in all things, it is still restricted to ensuring that observable results of the C abstract machine are correct.

> I believe I have also seen this behaviour come up with interning on some Integer wrapper types.

Python, for example:

  >>> 8 is 8
  True
  >>> 8**1000 is 8**1000
  False

Because python is broken in this respect -- JS engines do exactly the same object optimisations and get comparisons correct.

Meh. They're different languages with different expectations. "is" is distinct from "==" in both, and Python gets "==" right (obviously). Javascript doesn't really have any high ground here[0]. (In contrast, Python:)

  >>> [] == False
  False
  >>> object() == False
  False
  >>> "" == False
  False
  >>> {} == False
  False

They're just different.

[0]: https://www.youtube.com/watch?v=et8xNAc2ic8

JS has "strict equality" comparison. It's not the same as "identity" comparison.

(Well string addition should be associative)

Hurrr derp :D

You are of course right :)