From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-422648-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 24242 invoked by alias); 20 May 2013 14:26:32 -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 24181 invoked by uid 48); 20 May 2013 14:26:23 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/57199] [4.8/4.9 Regression] Bogus warning: iteration NNNN invokes undefined behavior -Waggressive-loop-optimizations
Date: Mon, 20 May 2013 14:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.1
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57199-4-FqkV4Wa5qp@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57199-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57199-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: 2013-05/txt/msg01321.txt.bz2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57199

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
But this isn't any form of the may invoke, the loop certainly unconditionally
invokes undefined behavior, just the whole loop is very unlikely to be ever
executed (in this case if size is supposed to represent the length of an array
with elements bigger than 1, then already the size would need to be invalid,
but that is something the compiler can't understand, for it the size_t field is
likely any other field, and there is no guarantee it won't be -1).

It is in principle no different from say:

void
foo (size_t x)
{
  if (x == (size_t) -1)
    {
      unsigned int a[128];
      int i;

      for (i = 0; i < 128; ++i)     /* { dg-message "note: containing loop" }
*/
        a[i] = i * 0x02000001;      /* { dg-warning "invokes undefined
behavior" } */
      bar (a);
    }
}

where you know you are never going to call foo with (size_t) -1, but the
compiler doesn't know.  How is the above different from say:
void
bar (void)
{
  unsigned int a[128];
  int i;

  for (i = 0; i < 128; ++i)     /* { dg-message "note: containing loop" } */
    a[i] = i * 0x02000001;      /* { dg-warning "invokes undefined behavior" }
*/
  bar (a);
}
...
/* in another CU */
void
baz (size_t x)
{
  if (x == (size_t) -1)
    bar ();
}

In your original testcase, you wouldn't get the warning if size was a signed
integer instead of unsigned one, then the compiler would know it is undefined
behavior if the size wraps and would just optimize the loop away altogether. 
Or perhaps some __builtin_unreachable assert that size isn't (size_t) -1?