public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
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 [thread overview] Message-ID: <bug-57199-4-FqkV4Wa5qp@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-57199-4@http.gcc.gnu.org/bugzilla/> 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?
next prev parent reply other threads:[~2013-05-20 14:26 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-05-07 22:09 [Bug c++/57199] New: [4.8, 4.9] " ppluzhnikov at google dot com 2013-05-07 23:01 ` [Bug c++/57199] [4.8/4.9 Regression] " paolo.carlini at oracle dot com 2013-05-08 8:58 ` [Bug tree-optimization/57199] " rguenth at gcc dot gnu.org 2013-05-08 12:55 ` ppluzhnikov at google dot com 2013-05-15 13:29 ` rguenth at gcc dot gnu.org 2013-05-20 8:12 ` jakub at gcc dot gnu.org 2013-05-20 14:10 ` ppluzhnikov at google dot com 2013-05-20 14:26 ` jakub at gcc dot gnu.org [this message] 2013-05-20 15:19 ` ppluzhnikov at google dot com 2014-03-26 20:39 ` dichlofos-mv at yandex dot ru 2014-03-26 20:56 ` ppluzhnikov at google dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-57199-4-FqkV4Wa5qp@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).