Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1488993 - No warning when generating incorrect code due to undefined behaviour in loop iteration
Summary: No warning when generating incorrect code due to undefined behaviour in loop ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gcc
Version: 7.2
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Marek Polacek
QA Contact: Michael Petlan
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-06 14:51 UTC by Paulo Andrade
Modified: 2020-12-14 09:54 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-10-11 11:01:20 UTC
Target Upstream Version:


Attachments (Terms of Use)
foo.cpp (1.33 KB, text/x-csrc)
2017-09-06 14:51 UTC, Paulo Andrade
no flags Details

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.


Note You need to log in before you can comment on or make changes to this bug.