Bug 1488993

Summary: No warning when generating incorrect code due to undefined behaviour in loop iteration
Product: Red Hat Enterprise Linux 7 Reporter: Paulo Andrade <pandrade>
Component: gccAssignee: Marek Polacek <mpolacek>
Status: CLOSED WONTFIX QA Contact: Michael Petlan <mpetlan>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.2CC: jakub, ohudlick
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-10-11 11:01:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
foo.cpp none

Description Paulo Andrade 2017-09-06 14:51:38 UTC 
Created attachment 1322692 [details]
foo.cpp

The issue is not generating any warning, and generating "expected"
result when declaring a virtual destructor.

  Customer was told that the issue would be fixed by declaring the
"i" variable as long (as unsigned would also work).

  gcc 7.1.1 shows a warning with -fno-tree-vrp that would be expected
to be also shown if tree-vrp is also enabled, thus the bug report:

$ g++ --std=c++11 -O2 -fno-tree-vrp  -S foo.cpp
foo.cpp: In function ‘void foo()’:
foo.cpp:66:35: warning: iteration 7 invokes undefined behavior [-Waggressive-loop-optimizations]
     if (rsp.fun(i) != (0x11111111 * (i+1))) {
                       ~~~~~~~~~~~~^~~~~~~~
foo.cpp:65:21: note: within this loop
   for (int i = 0; i < 8; ++i) {
                   ~~^~~
Comment 2 Jakub Jelinek 2017-09-06 15:04:47 UTC 
The -Waggressive-loop-optimizations warning certainly doesn't have the goal to detect all possible UBs in loops, that is really impossible, it just handles some easy cases of loops with single exit that provably have to invoke a small set of UBs in one of the iterations.
I bet you don't get a warning here because zonk could throw an exception and therefore the loop has multiple exits and could never invoke the UB if the exception is thrown before the UB.
The customer should better use -fsanitize=undefined to look for some UB in the code at runtime and then to fix it.
Comment 3 Marek Polacek 2017-10-11 11:01:20 UTC 
I don't think there's anything to do for RHEL7.5.