From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-478343-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 113831 invoked by alias); 24 Feb 2015 16:14:22 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 113785 invoked by uid 48); 24 Feb 2015 16:14:18 -0000
From: "ams at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/64491] [5 Regression] incorrect warning: loop exit may only be reached after undefined behavior
Date: Tue, 24 Feb 2015 17:01:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: ams at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64491-4-L2LX6vbr1F@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64491-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64491-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg02675.txt.bz2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64491

--- Comment #11 from Andrew Stubbs <ams at gcc dot gnu.org> ---
The compiler has constructed the loop such that it reads like this:

f = 0;
tmp = 0;
do {
  B[f] = tmp | A[f + 1];
  if (f + 1 == 8)
    break;

  if (f + 1 > 0)
    tmp = A[f];

  if (f + 1 == 7) {
    B[f + 1] = tmp;
    break;
  }

  f++;
} while (1);

It calculates the upper bound for f to be 7, which would make f + 1 a problem.
maybe_lower_iteration_bound then correctly identifies this, and reduces the
upper bound to 6. Consequently, the unnecessary "if (f + 1 == 8)" is removed,
and all is well with the world.

The problem is that leaves no path, from the loop header, that reaches a loop
exit without passing the "undefined" statement.

This makes it difficult to tell the difference between UB in the source code,
and this temporary UB introduced by the compiler. I've no idea why the bounds
are reduced here, rather than set properly in the first place?

I've tried only warning when *all* the exit routes are to be removed, but
they're not all listed in loop->bounds, so I'm stuck.