Bug 106931 - [12 Regression] -Wstringop-overflow false positive -O3 -fno-tree-vectorize with loop unrolling since r12-3300-gece28da924ddda8b
Summary: [12 Regression] -Wstringop-overflow false positive -O3 -fno-tree-vectorize w...
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 12.2.0
: P2 normal
Target Milestone: 12.4
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks: Wstringop-overflow
  Show dependency treegraph
 
Reported: 2022-09-13 18:34 UTC by Kacper Michajłow
Modified: 2024-03-15 00:45 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2022-09-13 00:00:00


Attachments
minimal test case (157 bytes, text/plain)
2022-09-13 18:34 UTC, Kacper Michajłow
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kacper Michajłow 2022-09-13 18:34:57 UTC
Created attachment 53572 [details]
minimal test case

Hello,

I noticed increased amount of -Wstringop-overflow warnings on FFmpeg build with gcc 12.2.0, doesn't happen with gcc 11.3.0. At first glance most of them are bogus and happen only when specific set of compiler flags are used.

I minimized one case, see attachment, it is pretty simple. I think gcc should handle this properly. Happens with this specific command
gcc -O3 -fno-tree-vectorize -Wstringop-overflow -c test.c

Attached case is minimized cbs_av1.c. For more cases which looks like gcc12 regression you can compile FFmpeg
./configure --enable-lto
make

Note that lto has to be enabled, without lto it doesn't produce those warnings. I can minimize more cases, but frankly I don't want to spend time minimizing it only to see the same pattern at the end. So maybe let's work on this first.

Tested with FFmpeg 60d8c2019f

Thanks,
Kacper
Comment 1 Martin Liška 2022-09-13 19:21:57 UTC
Started with r12-3300-gece28da924ddda8b.
Comment 2 Martin Sebor 2022-09-13 20:09:22 UTC
The false positive is issued for the store to A[i_90] in BB 10 by the strlen pass, where i_90's range is [8, 8].

  <bb 10> [local count: 712060]:
  _35 = (sizetype) i_90;
  _36 = B.1_83 + _35;
  _37 = *_36;
  A[i_90] = _37;    << -Wstringop-overflow
  _20 = _93 + 9;
  i_39 = (int) _20;
  goto <bb 12>; [100.00%]

Changing i's type to unsigned avoids the warning.  The IL looks very close but i_90's range in BB 10 is VR_UNDEFINED instead.

The following is debug_ranger() output for BBs 9 and 10 in the original test case.

=========== BB 9 ============
Imports: _93  
Exports: _8  i_90  _93  
         _8 : _93(I)  
         _86 : i_82(I)  
         _87 : i_82(I)  B.1_83(I)  _86  
         i_90 : _8  _93(I)  
i_82	[irange] int [7, 7] NONZERO 0x7
_93	[irange] unsigned int [0, 0] NONZERO 0x0
Relational : (_8 > _93)
    <bb 9> [local count: 801058]:
    _86 = (sizetype) i_82;
    _87 = B.1_83 + _86;
    _88 = *_87;
    A[i_82] = _88;
    _8 = _93 + 8;
    i_90 = (int) _8;
    if (i_90 != 8)
      goto <bb 10>; [88.89%]
    else
      goto <bb 12>; [11.11%]

_8 : [irange] unsigned int [8, 8] NONZERO 0x8
_86 : [irange] sizetype [7, 7] NONZERO 0x7
_87 : [irange] char * [1, +INF]
i_90 : [irange] int [8, 8] NONZERO 0x8
9->10  (T) _8 : 	[irange] UNDEFINED
9->10  (T) i_90 : 	[irange] UNDEFINED
9->10  (T) _93 : 	[irange] UNDEFINED
9->12  (F) _8 : 	[irange] unsigned int [8, 8] NONZERO 0x8
9->12  (F) i_90 : 	[irange] int [8, 8] NONZERO 0x8
9->12  (F) _93 : 	[irange] unsigned int [0, 0] NONZERO 0x0

=========== BB 10 ============
_93	[irange] UNDEFINED
    <bb 10> [local count: 712060]:
    _35 = (sizetype) i_90;
    _36 = B.1_83 + _35;
    _37 = *_36;
    A[i_90] = _37;
    _20 = _93 + 9;
    i_39 = (int) _20;
    goto <bb 12>; [100.00%]

whereas for the unsigned case:

=========== BB 10 ============
_85	[irange] UNDEFINED
i_90	[irange] UNDEFINED
Comment 3 Richard Biener 2023-05-08 12:25:31 UTC
GCC 12.3 is being released, retargeting bugs to GCC 12.4.
Comment 4 Jeffrey A. Law 2024-03-15 00:45:42 UTC
False positive is fixed w/ gcc-13 and the trunk.