Atomic cmpxchg note clarification #1909
Conversation
We now have explicit floating-point specializations for atomic. We had cmpxchg for them before, but people are now looking at increased usage and are confused about what the behavior is for `-0.` with `0.`, as well as NaNs. I propose clarifying the note to make this extra clear. This is a note and is therefore purely editorial, and would be a waste of SG1's time.
source/atomics.tex
Outdated
| @@ -931,7 +931,8 @@ | |||
| \begin{note} The \tcode{memcpy} and \tcode{memcmp} semantics of the compare-and-exchange | |||
| operations may result in failed comparisons for values that compare equal with | |||
| \tcode{operator==} if the underlying type has padding bits, trap bits, or alternate | |||
| representations of the same value.\end{note} | |||
| representations of the same value. Notably, floating-point \tcode{-0.} and \tcode{0.} | |||
There was a problem hiding this comment.
Please use "-0.0" and "+0.0" for extra clarity.
source/atomics.tex
Outdated
| @@ -931,7 +931,8 @@ | |||
| \begin{note} The \tcode{memcpy} and \tcode{memcmp} semantics of the compare-and-exchange | |||
| operations may result in failed comparisons for values that compare equal with | |||
| \tcode{operator==} if the underlying type has padding bits, trap bits, or alternate | |||
| representations of the same value.\end{note} | |||
| representations of the same value. Notably, floating-point \tcode{-0.0} and \tcode{+0.0} | |||
There was a problem hiding this comment.
I think "will" is too strong here, given that the core language rules do not require 0.0 and -0.0 to be distinct values, and nor do they require NaNs to exist. Can you weaken this by using "may" or "will typically" or "on implementations conforming to ISO/IEC/IEEE 60559" or similar?
source/atomics.tex
Outdated
| representations of the same value.\end{note} | ||
| representations of the same value. Notably, on implementations conforming to | ||
| ISO/IEC/IEEE 60559, floating-point \tcode{-0.0} and \tcode{+0.0} | ||
| will compare not-equal and NaNs with the same payload will compare equal.\end{note} |
There was a problem hiding this comment.
Reading through this again, there seems to be a mismatch in how "compare equal" is used in the first and second half of the note. In the first half, we talk about "compare equal with operator==", but when we say "compare not-equal" and "compare equal" in the second half, we're talking about the memcmp semantics.
At the risk of verbosity, how about:
\tcode{-0.0} and \tcode{+0.0} will not compare equal with \tcode{memcmp} but will compare equal with \tcode{operator==}, and NaNs with the same payload will compare equal with \tcode{memcmp} but will not compare equal with \tcode{operator==}.
SG1 loves notes.
We now have explicit floating-point specializations for atomic. We had cmpxchg for them before, but people are now looking at increased usage and are confused about what the behavior is for
-0.with0., as well as NaNs. I propose clarifying the note to make this extra clear. This is a note and is therefore purely editorial, and would be a waste of SG1's time.