https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98516
Bug ID: 98516
Summary: Wrong code generated by tree vectorizer
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mar...@mpa-garching.mpg.de
Target Milestone: ---
Created attachment 49879
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49879&action=edit
Code to reproduce the problem
The attached code is a distilled test case from an FFT library, which works
fine with current released GCC versions, but produces incorrect results with
current trunk when tree optimization is switched on via -O3:
martin@debian:~/codes/ducc$ g++ -I src/ -std=c++17 -O3 -march=native
-ffast-math bug.cc
martin@debian:~/codes/ducc$ ./a.out
(0.362978,0.601326) (0.362155,0.18782) (1.63193,-0.0779749) (1.26662,0.327246)
(-1.0024,1.03302)
The third complex number in the result line is wrong.
When disabling tree vectorization (or when using a released GCC version), the
correct answer is produced:
martin@debian:~/codes/ducc$ g++ -I src/ -std=c++17 -O3 -march=native
-ffast-math bug.cc -fno-tree-vectorize
martin@debian:~/codes/ducc$ ./a.out
(0.362978,0.601326) (0.362155,0.18782) (0.380433,0.228703) (1.26662,0.327246)
(-1.0024,1.03302)
My gcc version is
martin@debian:~/codes/ducc$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/martin/codes/umaster/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/martin/codes/gccgit/configure --disable-bootstrap
--disable-multilib --prefix=/home/martin/codes/umaster
--enable-languages=c++,fortran --enable-target=all --enable-checking=release
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20210103 (experimental) [master revision
37d0bb1f5b5:d78f978936b:3335c9f954f8939403eabb5ad3d8739be9984f81] (GCC)
I have tried to narrow down this failure further, but without success so far.
It's quite possible that the mistake is on my side, but using the sanitizers
and valgrind I have not been able to find anything.
Maybe a git bisect could locate the commit that introduced the change in
behaviour.
