[Bug c++/110622] New: x86: Miscompilation at O1 level (O0 is working)

[Bug c++/110622] New: x86: Miscompilation at O1 level (O0 is working)

[malat at debian dot org]

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

            Bug ID: 110622
           Summary: x86: Miscompilation at O1 level (O0 is working)
           Product: gcc
           Version: 13.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: malat at debian dot org
  Target Milestone: ---

I can trigger an assertion in highway unit test suite on Debian/i386 when using
-O1 (does not happen at -O0).

Symptoms:

[...]
f32x2: Log1p(5.5968112995194757e-20) expected 5.5968112995194757e-20 actual 0
ulp 5.28754e+08 max ulp 3
[...]

For some reason the code return exactly zero (0) during a math computation of a
log1p function. The code runs fine at O2 on all other Debian arches (amd64,
mipsel, armel, ppc32 ...).

Since the return value is exactly 0, I suspect this is not a case of excess
precision (x87). This is not a hardware issue as I can reproduce it on multiple
hosts (Debian buildds machine, and x86 porterbox).

If I extract the math logic and call it in a `main` function, then the compiler
is able to optimize the code correctly (even at O2) and return appropriate
result (correct tolerance).

I did not observe any suspicious behavior under valgrind and/or -fsanitize.

[Bug c++/110622] x86: Miscompilation at O1 level (O0 is working)

[malat at debian dot org]

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

--- Comment #1 from Mathieu Malaterre <malat at debian dot org> ---
For reference:
* https://github.com/google/highway/issues/1488#issuecomment-1621528097

[Bug c++/110622] x86: Miscompilation at O1 level (O0 is working)

[malat at debian dot org]

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

--- Comment #2 from Mathieu Malaterre <malat at debian dot org> ---
Created attachment 55518
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55518&action=edit
Preprocessed source

% /usr/bin/g++-13 -save-temps -DHWY_STATIC_DEFINE -DTOOLCHAIN_MISS_ASM_HWCAP_H
-I/home/mathieu/Perso/highway -O1 -fPIE -fvisibility=hidden
-fvisibility-inlines-hidden -Wno-builtin-macro-redefined
-D__DATE__=\"redacted\" -D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\"
-fmerge-all-constants -Wall -Wextra -Wconversion -Wsign-conversion -Wvla
-Wnon-virtual-dtor -fmath-errno -fno-exceptions -DHWY_IS_TEST=1
-DGTEST_HAS_PTHREAD=1 -MD -MT
CMakeFiles/math_test.dir/hwy/contrib/math/math_test.cc.o -MF
CMakeFiles/math_test.dir/hwy/contrib/math/math_test.cc.o.d -o
CMakeFiles/math_test.dir/hwy/contrib/math/math_test.cc.o -c
/home/mathieu/Perso/highway/hwy/contrib/math/math_test.cc

[Bug c++/110622] x86: Miscompilation at O1 level (O0 is working)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://github.com/google/h
                   |                            |ighway/issues/1488#issuecom
                   |                            |ment-1621528097

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Does adding -fexcess-precision=standard help? What about -ffloat-store ?

[Bug c++/110622] x86: Miscompilation at O1 level (O0 is working)

[malat at debian dot org]

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

--- Comment #4 from Mathieu Malaterre <malat at debian dot org> ---
Here is my current state of work:

*
https://github.com/malaterre/highway/commit/771ca57d2d29b48f91beae033f6854f9b2dfb730

I am open to suggestion to further reduce the test case, as I am not familiar
with those sort of symptoms and how to drive c-reduce in this case.

Thanks all

[Bug c++/110622] x86: Miscompilation at O1 level (O0 is working)

[malat at debian dot org]

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

--- Comment #5 from Mathieu Malaterre <malat at debian dot org> ---
> Does adding -fexcess-precision=standard help? What about -ffloat-store ?

highway is c++ only. Those flags are C only

[Bug c++/110622] x86: Miscompilation at O1 level (O0 is working)

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Mathieu Malaterre from comment #5)
> > Does adding -fexcess-precision=standard help? What about -ffloat-store ?
> 
> highway is c++ only. Those flags are C only

No they are not. -fexcess-precision=standard C++ was added for GCC 13.
-ffloat-store is generic middle-end option and has been supported by all
front-ends since at least GCC 3.

[Bug target/110622] x86: Miscompilation at O1 level (O0 is working)

[malat at debian dot org]

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

Mathieu Malaterre <malat at debian dot org> changed:

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

--- Comment #7 from Mathieu Malaterre <malat at debian dot org> ---
Either `-fexcess-precision=standard` or `-ffloat-store` makes the symptoms go
away (tested at -O2).

Sorry for the noise. Thanks for the quick suggestion.

[Bug target/110622] x86: Miscompilation at O1 level (O0 is working)

[malat at debian dot org]

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

Mathieu Malaterre <malat at debian dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |DUPLICATE

--- Comment #8 from Mathieu Malaterre <malat at debian dot org> ---


*** This bug has been marked as a duplicate of bug 323 ***

[Bug target/110622] x86: Miscompilation at O1 level (O0 is working)

[malat at debian dot org]

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

Mathieu Malaterre <malat at debian dot org> changed:

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

--- Comment #9 from Mathieu Malaterre <malat at debian dot org> ---
(In reply to Mathieu Malaterre from comment #7)
> Either `-fexcess-precision=standard` or `-ffloat-store` makes the symptoms
> go away (tested at -O2).

The above statement is 100% accurate. However I still believe the optimizer is
doing a little too much on a limited range of values. Let me provide a reduce
test case.

[Bug target/110622] x87: Miscompilation at O2 level (O1 is working)

[malat at debian dot org]

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

--- Comment #10 from Mathieu Malaterre <malat at debian dot org> ---
Created attachment 55959
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55959&action=edit
cvise reduced test case

[Bug target/110622] x87: Miscompilation at O2 level (O1 is working)

[malat at debian dot org]

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

--- Comment #11 from Mathieu Malaterre <malat at debian dot org> ---
Typical setup:

g++ -fno-asynchronous-unwind-tables -fno-exceptions -fno-rtti -DHIDESYMPTOM
-std=c++11 -g -m32 -fexcess-precision=fast -O2 -o works math_test.cc
-Wfatal-errors -Wall -Wextra -Wpedantic -Wconversion -Werror

and:

g++ -fno-asynchronous-unwind-tables -fno-exceptions -fno-rtti -std=c++11 -g
-m32 -fexcess-precision=fast -O2 -o fails math_test.cc -Wfatal-errors -Wall
-Wextra -Wpedantic -Wconversion -Werror

You can observe that the only difference is that I am preventing an elision :

```
% grep -A2 HIDE math_test.cc
#ifdef HIDESYMPTOM
  asm volatile("" : "+r"(y.raw[0]) : : "memory");
#endif
```

[Bug target/110622] x87: Miscompilation at O2 level (O1 is working)

[malat at debian dot org]

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

--- Comment #12 from Mathieu Malaterre <malat at debian dot org> ---
I am seeing a difference in result (log1p computation) in the range:

4318952042648305665 - 0x1.0000000000001p-64
4368493837572636672 - 0x1.002p-53

the other values seems to match expectation of log1p computation.

[Bug target/110622] x87: Miscompilation at O2 level (O1 is working)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

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

--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Mathieu Malaterre from comment #12)
> I am seeing a difference in result (log1p computation) in the range:
> 
> 4318952042648305665 - 0x1.0000000000001p-64
> 4368493837572636672 - 0x1.002p-53
> 
> the other values seems to match expectation of log1p computation.

But you used excess-precision=fast

*** This bug has been marked as a duplicate of bug 323 ***

[Bug target/110622] x87: Miscompilation at O2 level (O1 is working)

[malat at debian dot org]

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

--- Comment #14 from Mathieu Malaterre <malat at debian dot org> ---
(In reply to Andrew Pinski from comment #13)
> (In reply to Mathieu Malaterre from comment #12)
> > I am seeing a difference in result (log1p computation) in the range:
> > 
> > 4318952042648305665 - 0x1.0000000000001p-64
> > 4368493837572636672 - 0x1.002p-53
> > 
> > the other values seems to match expectation of log1p computation.
> 
> But you used excess-precision=fast
> 
> *** This bug has been marked as a duplicate of bug 323 ***

AFAIK bug #323 does not mention my trick:

  asm volatile("" : "+r"(y.raw[0]) : : "memory");

That simple line totally changed the optimizer code generation.

[Bug target/110622] x87: Miscompilation at O2 level (O1 is working)

[xry111 at gcc dot gnu.org]

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

--- Comment #15 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Mathieu Malaterre from comment #14)
> (In reply to Andrew Pinski from comment #13)
> > (In reply to Mathieu Malaterre from comment #12)
> > > I am seeing a difference in result (log1p computation) in the range:
> > > 
> > > 4318952042648305665 - 0x1.0000000000001p-64
> > > 4368493837572636672 - 0x1.002p-53
> > > 
> > > the other values seems to match expectation of log1p computation.
> > 
> > But you used excess-precision=fast
> > 
> > *** This bug has been marked as a duplicate of bug 323 ***
> 
> AFAIK bug #323 does not mention my trick:
> 
>   asm volatile("" : "+r"(y.raw[0]) : : "memory");
> 
> That simple line totally changed the optimizer code generation.

Because in x87 the excessive precision only exists in x87 stack-like registers.
 The "memory" clobber forces a store and reload for all non-register variables,
thus the value is truncated into a normal double value and the excessive
precision is lost.

There are infinite ways to work around an issue, but it does not mean PR 323
must mention all of them.

[Bug target/110622] x87: Miscompilation at O2 level (O1 is working)

[malat at debian dot org]

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

--- Comment #16 from Mathieu Malaterre <malat at debian dot org> ---
(In reply to Xi Ruoyao from comment #15)
> (In reply to Mathieu Malaterre from comment #14)
> > (In reply to Andrew Pinski from comment #13)
> > > (In reply to Mathieu Malaterre from comment #12)
> > > > I am seeing a difference in result (log1p computation) in the range:
> > > > 
> > > > 4318952042648305665 - 0x1.0000000000001p-64
> > > > 4368493837572636672 - 0x1.002p-53
> > > > 
> > > > the other values seems to match expectation of log1p computation.
> > > 
> > > But you used excess-precision=fast
> > > 
> > > *** This bug has been marked as a duplicate of bug 323 ***
> > 
> > AFAIK bug #323 does not mention my trick:
> > 
> >   asm volatile("" : "+r"(y.raw[0]) : : "memory");
> > 
> > That simple line totally changed the optimizer code generation.
> 
> Because in x87 the excessive precision only exists in x87 stack-like
> registers.  The "memory" clobber forces a store and reload for all
> non-register variables, thus the value is truncated into a normal double
> value and the excessive precision is lost.
> 
> There are infinite ways to work around an issue, but it does not mean PR 323
> must mention all of them.

Oh, I see. Basically my trick is convoluted `-ffloat-store`.

I finally took myself by the hand and convinced me with a simple code:

```
// gcc -m32 -fexcess-precision=fast -O2 t.c
#include <inttypes.h>
#include <stdint.h>
#include <stdio.h>
#include <string.h>

[[gnu::noipa]] void test(uint64_t v, double x, double y) {
  const double y2 = x + 1.0;
  if (y != y2)
    printf("error %" PRIu64 " %.17g %a\n", v, x, x);
  else
    printf("ok %" PRIu64 " %.17g %a\n", v, x, x);
}

void main() {

  uint64_t kSamplesPerRange = 4000, start = 0, stop = 9218868437227405311;
  uint64_t step = (stop / kSamplesPerRange);
  for (uint64_t value_bits = start; value_bits <= stop; value_bits += step) {
    double value;
    memcpy(&value, &value_bits, sizeof value);
    double x = value;
    double y = x + 1.0;

    test(value_bits, x, y);
  }
}
```

please accept my apologies for the noise.