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, thank you, Federico
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...