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?
