[Bug c/96804] New: Arguments are swapped in floating-point addition

[Bug c/96804] New: Arguments are swapped in floating-point addition

[chfast at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96804

            Bug ID: 96804
           Summary: Arguments are swapped in floating-point addition
           Product: gcc
           Version: 10.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: chfast at gmail dot com
  Target Milestone: ---

Created attachment 49132
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49132&action=edit
C source code

In the following function, when compiling without optimizations -O0 with GCC
10.2.0 (x86_64-linux-gnu) the arguments to the add instructions are swapped.

float fadd(const float* a, const float* b)
{
    return *a + *b;
}

Assembly snippet:

        movq    %rdi, -8(%rbp)   # a
        movq    %rsi, -16(%rbp)  # b
        movq    -8(%rbp), %rax   # a
        movss   (%rax), %xmm1    # *a
        movq    -16(%rbp), %rax  # b
        movss   (%rax), %xmm0    # *b
        addss   %xmm1, %xmm0     # = *b + *a

This is a problem because when both arguments are NaNs, the result may be
different than the one predicted by IEEE 754.

[Bug c/96804] Arguments are swapped in floating-point addition

[chfast at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96804

--- Comment #1 from Paweł Bylica <chfast at gmail dot com> ---
Created attachment 49133
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49133&action=edit
Assembly output

[Bug c/96804] Arguments are swapped in floating-point addition

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96804

--- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Paweł Bylica from comment #0)
> This is a problem because when both arguments are NaNs, the result may be
> different than the one predicted by IEEE 754.

Could you quote the sentence in IEEE 754 that you believe is violated? As far
as I can tell, the order doesn't matter:

"For an operation with quiet NaN inputs, other than maximum and minimum
operations, if a floating-point result is to be delivered the result shall be a
quiet NaN which should be one of the input NaNs."

[Bug c/96804] Arguments are swapped in floating-point addition

[chfast at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96804

--- Comment #3 from Paweł Bylica <chfast at gmail dot com> ---
Yes, you are right, that is not violation of IEEE 754 (I assumed wrongly
previously, sorry).

However, it still maybe undesired to get different binary results depending on
optimization enabled/disabled.

[Bug target/96804] Arguments are swapped in floating-point addition

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96804

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
IEEE 754 does not specify the choice of output NaN.  None of the C 
bindings to IEEE 754 specify the choice of output NaN.  There are various 
architecture differences in choice of output NaN (for example, RISC-V 
always uses a canonical quiet NaN, x87 chooses based on comparing the 
payloads, SSE chooses based on the operand order to the instruction).  
Since none of the C bindings specify anything about the choice of output 
NaN, there is no expectation that particular C syntax constructs map to 
any particular rules for choice of NaN.  And even once you have a choice 
of NaN from an arithmetic operation, the C bindings leave it 
implementation-defined whether assignment, function return and other 
conversions as if by assignment are a convertFormat or copy operation (and 
convertFormat from a type to itself might change a NaN payload).

[Bug target/96804] Arguments are swapped in floating-point addition

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96804

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
I don't think it is reasonably possible to preserve "operand order" for
commutative operations.