Bug 105558 - simple 8-bit integer calculation fails with -O3 / march=core-avx2 on some gfortran 8/9/10 versions
Summary: simple 8-bit integer calculation fails with -O3 / march=core-avx2 on some gfo...
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 10.3.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: needs-bisection, wrong-code
Depends on:
Blocks: vectorizer
  Show dependency treegraph
 
Reported: 2022-05-11 07:05 UTC by federico
Modified: 2023-11-07 06:19 UTC (History)
2 users (show)

See Also:
Host:
Target: x86_64-linux-gnu
Build:
Known to work: 11.1.0, 7.3.0
Known to fail: 10.5.0, 8.1.0
Last reconfirmed: 2022-05-11 00:00:00


Attachments
integer(1) test program (1.06 KB, text/plain)
2022-05-11 07:05 UTC, federico
Details

Note You need to log in before you can comment on or make changes to this bug.
Description federico 2022-05-11 07:05:45 UTC
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
Comment 1 Richard Biener 2022-05-11 07:51:38 UTC
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.
Comment 2 federico 2022-05-11 08:15:42 UTC
Ok so we have: 

gfortran | [...] -fno-tree-vectorize | [...] -fno-vect-cost-model
    10.3 |                        OK |                     ERROR
     9.3 |                        OK |                     ERROR 
     8.3 |                        OK |                     ERROR
Comment 3 federico 2022-05-11 08:17:21 UTC
-fno-vect-cost model also does not change behavior on gcc 11/7/6/5 (all OK)
Comment 4 Martin Liška 2022-07-15 10:45:21 UTC
Fixed on master with r11-3718-g91ae6930ed4a87d7.
Comment 5 Andrew Pinski 2022-10-27 04:57:08 UTC
(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.
Comment 6 Andrew Pinski 2022-10-27 04:58:51 UTC
Would be interesting to find what patch broke this and what patch fixed the -mtune=generic case.
Comment 7 Richard Biener 2023-07-07 10:00:53 UTC
We don't know the failure mode and the identified fix isn't likely the fix.  Leaving open as non-regression.
Comment 8 Thomas Koenig 2023-11-07 06:19:19 UTC
(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...