(Well, it's a big document. I searched for the string "addition", which occurs just 41 times.)
I failed, but I believe I can show that the standard requires addition to be commutative in all cases:
1. "Clause 5 of this standard specifies the result of a single arithmetic operation." (§10.1)
2. "All conforming implementations of this standard shall provide the operations listed in this clause for all
supported arithmetic formats, except as stated below. Unless otherwise specified, each of the computational
operations specified by this standard that returns a numeric result shall be performed as if it first produced
an intermediate result correct to infinite precision and with unbounded range, and then rounded that
intermediate result, if necessary, to fit in the destination’s format" (§5.1)
Obviously, addition of real numbers is commutative, so the intermediate result produced for addition(a,b) must be equal to that produced for addition(b,a). I hope, but cannot guarantee, that the rounding applied to that intermediate result would not then depend on the order of operands provided to the addition operator.
3. "The operation addition(x, y) computes x+y. The preferred exponent is min(Q(x), Q(y))." (§5.4.1). This is the entire definition of addition, as far as I could find. (It's also defined, just above this statement, as being a general-computational operation. According to §5.1, a general-computational operation is one which produces floating-point or integer results, rounds all results according to §4, and might signal floating-point exceptions according to §7.)
4. The standard encourages programming language implementations to treat IEEE 754 addition as commutative (§10.4):
> A language implementation preserves the literal meaning of the source code by, for example:
> - Applying the properties of real numbers to floating-point expressions only when they preserve numerical results and flags raised:
> -- Applying the commutative law only to operations, such as addition and multiplication, for which neither the numerical values of the results, nor the representations of the results, depend on the order of the operands.
> -- Applying the associative or distributive laws only when they preserve numerical results and flags raised.
> -- Applying the identity laws (0 + x and 1 × x) only when they preserve numerical results and flags raised.
This looks like a guarantee that, in IEEE 754 addition, "the representation of the result" (i.e. the sign/exponent/significand triple, or a special infinite or NaN value - §3.2) does not "depend on the order of the operands". §3.2 specifically allows an implementation to map multiple bitstrings ("encodings") to a single "representation", so it's possible that the bit pattern of the result of an addition may differ depending on the order of the addends.
5. "Except for the quantize operation, the value of a floating-point result (and hence its cohort) is determined
by the operation and the operands’ values; it is never dependent on the representation or encoding of an
operand."
"The selection of a particular representation for a floating-point result is dependent on the operands’
representations, as described below, but is not affected by their encoding." (both from §5.2)
HOWEVER...
6. §6, dealing with infinite and NaN values, implicitly contemplates that there might be a distinction between addition(a,b) and addition(b,a):
> Operations on infinite operands are usually exact and therefore signal no exceptions, including, among
others,
> - addition(∞, x), addition(x, ∞), subtraction(∞, x), or subtraction(x, ∞), for finite x (§6.1)
(Well, it's a big document. I searched for the string "addition", which occurs just 41 times.)
I failed, but I believe I can show that the standard requires addition to be commutative in all cases:
1. "Clause 5 of this standard specifies the result of a single arithmetic operation." (§10.1)
2. "All conforming implementations of this standard shall provide the operations listed in this clause for all supported arithmetic formats, except as stated below. Unless otherwise specified, each of the computational operations specified by this standard that returns a numeric result shall be performed as if it first produced an intermediate result correct to infinite precision and with unbounded range, and then rounded that intermediate result, if necessary, to fit in the destination’s format" (§5.1)
Obviously, addition of real numbers is commutative, so the intermediate result produced for addition(a,b) must be equal to that produced for addition(b,a). I hope, but cannot guarantee, that the rounding applied to that intermediate result would not then depend on the order of operands provided to the addition operator.
3. "The operation addition(x, y) computes x+y. The preferred exponent is min(Q(x), Q(y))." (§5.4.1). This is the entire definition of addition, as far as I could find. (It's also defined, just above this statement, as being a general-computational operation. According to §5.1, a general-computational operation is one which produces floating-point or integer results, rounds all results according to §4, and might signal floating-point exceptions according to §7.)
4. The standard encourages programming language implementations to treat IEEE 754 addition as commutative (§10.4):
> A language implementation preserves the literal meaning of the source code by, for example:
> - Applying the properties of real numbers to floating-point expressions only when they preserve numerical results and flags raised:
> -- Applying the commutative law only to operations, such as addition and multiplication, for which neither the numerical values of the results, nor the representations of the results, depend on the order of the operands.
> -- Applying the associative or distributive laws only when they preserve numerical results and flags raised.
> -- Applying the identity laws (0 + x and 1 × x) only when they preserve numerical results and flags raised.
This looks like a guarantee that, in IEEE 754 addition, "the representation of the result" (i.e. the sign/exponent/significand triple, or a special infinite or NaN value - §3.2) does not "depend on the order of the operands". §3.2 specifically allows an implementation to map multiple bitstrings ("encodings") to a single "representation", so it's possible that the bit pattern of the result of an addition may differ depending on the order of the addends.
5. "Except for the quantize operation, the value of a floating-point result (and hence its cohort) is determined by the operation and the operands’ values; it is never dependent on the representation or encoding of an operand."
"The selection of a particular representation for a floating-point result is dependent on the operands’ representations, as described below, but is not affected by their encoding." (both from §5.2)
HOWEVER...
6. §6, dealing with infinite and NaN values, implicitly contemplates that there might be a distinction between addition(a,b) and addition(b,a):
> Operations on infinite operands are usually exact and therefore signal no exceptions, including, among others,
> - addition(∞, x), addition(x, ∞), subtraction(∞, x), or subtraction(x, ∞), for finite x (§6.1)