Created attachment 52950 [details]
integer(1) test program
Hi gcc/gfortran team,
I have two routines that encode and decode two integer(1) IDs (in [1:6] and [1:32] respectively) to a unique 8-byte integer(1), for 192 possible cases.
The example that fails should behave like
encode(1, 32) returns 77
decode(77) returns [1, 32]
but returns either [-5, 33] or sometimes [3,71]
With -O3, there are both versions and architectures of gfortran that either work or not. On godbolt (https://godbolt.org/z/5GboahWs1), this is what I see:
gfortran | -O3 -mtune=generic | -O3 -march=core-avx2 |
12.1 | OK | OK |
11.3 | OK | OK |
11.2 | OK | OK |
11.1 | OK | OK |
10.3 | OK | ERROR |
10.2 | OK | ERROR |
10.1 | OK | ERROR |
9.4 | OK | ERROR |
9.3 | OK | ERROR |
9.2 | OK | ERROR |
9.1 | OK | ERROR |
8.5 | ERROR | ERROR |
8.4 | ERROR | ERROR |
8.3 | ERROR | ERROR |
8.2 | ERROR | ERROR |
8.1 | ERROR | ERROR |
7.3 | OK | OK |
7.2 | OK | OK |
7.1 | OK | OK |
6.3 | OK | OK |
5.5 | OK | OK |
Also note that:
- problem is with int8 only; all is OK with int16,int32,int64
- no problems with -O2.
I'm attaching the code here as well,
Can I ask you to see whether -O3 -fno-tree-vectorize avoids the issue and whether -O3 -fno-vect-cost-model makes the issue appear in more versions? It could be that this is a resolved issue that awaits backporting of a fix (or where backporting is too difficult).
I can confirm the -O3 -march=core-avx2 failure with GCC 10 and success with GCC 11.
Ok so we have:
gfortran | [...] -fno-tree-vectorize | [...] -fno-vect-cost-model
10.3 | OK | ERROR
9.3 | OK | ERROR
8.3 | OK | ERROR
-fno-vect-cost model also does not change behavior on gcc 11/7/6/5 (all OK)
Fixed on master with r11-3718-g91ae6930ed4a87d7.
(In reply to Martin Liška from comment #4)
> Fixed on master with r11-3718-g91ae6930ed4a87d7.
If anything that just made the issue latent I suspect.
Would be interesting to find what patch broke this and what patch fixed the -mtune=generic case.
We don't know the failure mode and the identified fix isn't likely the fix. Leaving open as non-regression.
(In reply to Andrew Pinski from comment #6)
> Would be interesting to find what patch broke this and what patch fixed the
> -mtune=generic case.
It is not easy bisecting with old compilers - compilation issues keep
coming up on more modern systems, and sometimes newer compilers do
not compile older compilers...