[Bug target/110643] New: arm64: Miscompilation at O1 level (O0 is working)

[Bug target/110643] New: arm64: Miscompilation at O1 level (O0 is working)

[malat at debian dot org]

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

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

I am seeing a test failure in highway test-suite when using GCC 13.1.0 compared
to  GCC 12.3.0.

Symptoms:

```
    Start 111: HwyMathTestGroup/HwyMathTest.TestAllAtan2/NEON_WITHOUT_AES  #
GetParam() = 536870912

111: Test command: /home/malat/highway/bin/tests/math_test
"--gtest_filter=HwyMathTestGroup/HwyMathTest.TestAllAtan2/NEON_WITHOUT_AES"
"--gtest_also_run_disabled_tests"
111: Working Directory: /home/malat/highway/bin
111: Test timeout computed to be: 1500
111: Running main() from ./googletest/src/gtest_main.cc
111: Note: Google Test filter =
HwyMathTestGroup/HwyMathTest.TestAllAtan2/NEON_WITHOUT_AES
111: [==========] Running 1 test from 1 test suite.
111: [----------] Global test environment set-up.
111: [----------] 1 test from HwyMathTestGroup/HwyMathTest
111: [ RUN      ] HwyMathTestGroup/HwyMathTest.TestAllAtan2/NEON_WITHOUT_AES
111: Mismatch for i=14 expected 2.356194 actual 3.141593
111: Abort at /home/malat/highway/hwy/contrib/math/math_test.cc:401: Assert 0
1/1 Test #111: HwyMathTestGroup/HwyMathTest.TestAllAtan2/NEON_WITHOUT_AES  #
GetParam() = 536870912 ...Subprocess aborted***Exception:   0.01 sec
```

[Bug target/110643] arm64: Miscompilation at O1 level (O0 is working)

[malat at debian dot org]

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

--- Comment #1 from Mathieu Malaterre <malat at debian dot org> ---
Upstream ref:

* https://github.com/google/highway/issues/1549

[Bug target/110643] arm64: Miscompilation at O1 level (O0 is working)

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|arm64                       |aarch64
           Keywords|                            |wrong-code

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
arm64 is not a thing ... (ok, it is the arch name for Linux kernel but that is
it).

[Bug target/110643] arm64: Miscompilation at O1 level (O0 is working)

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Does -ffp-contract=on help?

[Bug target/110643] aarch64: Miscompilation at O1 level (O0 is working)

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-07-12
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
We are going to need a self contained testcase to figure this out ...

[Bug target/110643] aarch64: Miscompilation at O1 level (O0 is working)

[malat at debian dot org]

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

--- Comment #5 from Mathieu Malaterre <malat at debian dot org> ---
> We are going to need a self contained testcase to figure this out ...

You are not going to like it. Anyway here it goes:

[using Debian sid/arm64]
$ git clone https://github.com/google/highway.git
$ export CXX=-O1
$ export CXXFLAGS=g++-13
$ cmake -S highway -B build -DHWY_SYSTEM_GTEST=ON
$ cmake --build build -- -j8 math_test
$ ctest --test-dir build -R
HwyMathTestGroup/HwyMathTest.TestAllAtan2/NEON_WITHOUT_AES

I can provide the *.ii file if needed.

[Bug target/110643] aarch64: Miscompilation at O1 level (O0 is working)

[malat at debian dot org]

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

--- Comment #6 from Mathieu Malaterre <malat at debian dot org> ---
> $ export CXX=-O1
> $ export CXXFLAGS=g++-13

should read:

$ export CXX=g++-13
$ export CXXFLAGS=-O1

[Bug target/110643] aarch64: Miscompilation at O1 level (O0 is working)

[malat at debian dot org]

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

--- Comment #7 from Mathieu Malaterre <malat at debian dot org> ---
(In reply to Andrew Pinski from comment #3)
> Does -ffp-contract=on help?

Nope, I do not see any difference in symptoms:

```
73: [ RUN      ] HwyMathTestGroup/HwyMathTest.TestAllAtan2/NEON_WITHOUT_AES
73: Mismatch for i=14 expected 2.356194 actual 3.141593
73: Abort at /home/malat/h/highway/hwy/contrib/math/math_test.cc:401: Assert 0
```

[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |13.1.0
            Summary|aarch64: Miscompilation at  |[13/14 Regression] aarch64:
                   |O1 level (O0 is working)    |Miscompilation at O1 level
                   |                            |(O0 is working)
      Known to work|                            |12.3.0
   Target Milestone|---                         |13.2

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
I wonder if you can try a recent GCC 13 snapshot or the head of the branch and
also confirm with GCC 14 trunk?

[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)

[malat at debian dot org]

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

--- Comment #9 from Mathieu Malaterre <malat at debian dot org> ---
(In reply to Richard Biener from comment #8)
> I wonder if you can try a recent GCC 13 snapshot or the head of the branch
> and also confirm with GCC 14 trunk?

Could you suggest a docker image I could use ?

   $ docker run -it <???>

[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)

[alice at ayaya dot dev]

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

psykose <alice at ayaya dot dev> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alice at ayaya dot dev

--- Comment #10 from psykose <alice at ayaya dot dev> ---
with 13-20230722 i can reproduce the exact same failures

[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.2                        |13.3

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 13.2 is being released, retargeting bugs to GCC 13.3.

[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)

[malat at debian dot org]

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

--- Comment #12 from Mathieu Malaterre <malat at debian dot org> ---
regression started today

% cvise check.sh math_test.cc                               
00:00:27 INFO ===< 3971165 >===
00:00:27 INFO running 4 interestingness tests in parallel
00:00:27 INFO INITIAL PASSES
00:00:27 INFO ===< IncludesPass >===

[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)

[malat at debian dot org]

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

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

[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)

[malat at debian dot org]

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

--- Comment #14 from Mathieu Malaterre <malat at debian dot org> ---
Here is a first reproducer. Using GCC-13.2.0

% g++ -O0 -o works  tu.cc && ./works
% g++ -O1 -o fails  tu.cc && ./fails
zsh: abort      ./fails

[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)

[pinskia at gcc dot gnu.org]

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

--- Comment #15 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Well the cvise reduced testcase is undefined code:
template <int __i, typename... _Elements>
__tuple_element_t<__i, tuple<_Elements...>> get(tuple<_Elements...>) {
  double __trans_tmp_23{};
  double *__trans_tmp_21 = &__trans_tmp_23;
  return __trans_tmp_21;
}

That returns a address to a local variable ...

Which is why you get this warning:
```
<source>: In function 'void hwy::AssertVecEqual(Vec<Simd<double> >)':
<source>:174:45: warning: '__trans_tmp_23' is used uninitialized
[-Wuninitialized]
  174 |          __trans_tmp_20 = *actual_lanes.get();
      |                                             ^
<source>:42:10: note: '__trans_tmp_23' was declared here
   42 |   double __trans_tmp_23{};
      |          ^~~~~~~~~~~~~~
```

[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)

[malat at debian dot org]

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

Mathieu Malaterre <malat at debian dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #56015|0                           |1
        is obsolete|                            |

--- Comment #16 from Mathieu Malaterre <malat at debian dot org> ---
Created attachment 56045
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56045&action=edit
inf6.cc

[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)

[malat at debian dot org]

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

--- Comment #17 from Mathieu Malaterre <malat at debian dot org> ---
(In reply to Andrew Pinski from comment #15)
> That returns a address to a local variable ...

Sorry I am having a hard time driving cvise correctly.

Here is the latest version:

g++-13 -g -o works inf6.cc -O0 -Wall -Wextra -Werror -Wfatal-errors
-> no issue

valgrind --error-exitcode=1 ./works
-> should only report a memleak

clang++-16 -fsanitize=undefined -g -o works0 inf6.cc -Wall -Wextra -Werror
-Wfatal-errors
-> no issue


You can reproduce the abort using:

g++-13 -g -o fails inf6.cc -O1 -Wall -Wextra -Werror -Wfatal-errors
-> abort

Please note that my version of g++-11 & g++-12 compile the TU just fine using
-O1.

Could you please run a regression to identify which commit along GCC-13 branch
introduce the change at least to get the ball rolling ?

Thanks !

[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)

[alice at ayaya dot dev]

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

--- Comment #18 from psykose <alice at ayaya dot dev> ---
> Could you please run a regression to identify which commit along GCC-13 branch introduce the change at least to get the ball rolling ?  

note that it might not actually be a regression; it's possible the cvise
minimisation (above) results in "easy to spot UB in testcase" because the
original (non-minimised) program was actually broken because of UB somewhere
(with newer gcc then breaking it via new optimisations), just with it being
harder to find. knowing which commit causes the final bad output may or may not
help find that, if it's the case. the investigation hasn't concluded quite yet.

[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)

[pinskia at gcc dot gnu.org]

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

--- Comment #19 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Hmm, adding -fwrapv allows the testcase to pass ...

[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)

[pinskia at gcc dot gnu.org]

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

--- Comment #20 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
With -fwrapv:
  _87 = _92 * 2;
  NativeSet___trans_tmp_3 = { -2 };
  _84 = _87 == -2;

Without:
  _84 = _92 == -1;

I think that is correct ...

[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)

[pinskia at gcc dot gnu.org]

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

--- Comment #21 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
That is the code in IsInf causes the difference ...

[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |MOVED
             Status|WAITING                     |RESOLVED

--- Comment #22 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
template <typename T, size_t N, HWY_IF_FLOAT(T)>
HWY_API Mask128<T, N> IsInf(const Vec128<T, N> v) {
  const DFromV<decltype(v)> d;
  const RebindToSigned<decltype(d)> di;
  const VFromD<decltype(di)> vi = BitCast(di, v);
  // 'Shift left' to clear the sign bit, check for exponent=max and mantissa=0.
  return RebindMask(d, Eq(Add(vi, vi), Set(di, hwy::MaxExponentTimes2<T>())));
}


Most likely should have been:
```
template <typename T, size_t N, HWY_IF_FLOAT(T)>
HWY_API Mask128<T, N> IsInf(const Vec128<T, N> v) {
  const DFromV<decltype(v)> d;
  const RebindToUnsigned<decltype(d)> du;
  const VFromD<decltype(du)> vi = BitCast(du, v);
  // 'Shift left' to clear the sign bit, check for exponent=max and mantissa=0.
  return RebindMask(d, Eq(Add(vi, vi), Set(du, hwy::MaxExponentTimes2<T>())));
}
```

I noticed the bug happens in other places in highway for other targets too
(including x86_64).

this code is undefined due to an signed integer overflow and that is why using
unsigned is needed.


Yes -fsanitize=undefined does not currently work for vectors (that is a known
limitation).

[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)

[pinskia at gcc dot gnu.org]

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

--- Comment #23 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note even though the optimization was in GCC 11+ (r11-2550-gca2b8c082c4f added
it), only GCC 13+ hits it in this case as GCC 13 lowers the vector comparison
and uses the scalar for the one element signed 64bit long. I have not looked
into which revision changed the behavior there though. But as I mentioned this
is not a GCC bug really.