public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrew Haley <aph@redhat.com>
To: "Moritz Strübe" <moritz.struebe@redheads.de>,
	"Jakub Jelinek" <jakub@redhat.com>,
	"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: GCC turns &~ into | due to undefined bit-shift without warning
Date: Thu, 21 Mar 2019 09:52:00 -0000	[thread overview]
Message-ID: <6d48ceb5-9ebb-cd08-d6ed-ab6f7306d730@redhat.com> (raw)
In-Reply-To: <42becef3-3cc8-de91-238b-673a931a73d9@redheads.de>

On 3/21/19 8:53 AM, Moritz Strübe wrote:
> Hey.
> 
> Am 20.03.2019 um 18:36 schrieb Andrew Haley:
>> On 3/20/19 2:08 PM, Moritz Strübe wrote:
>>> Ok, I played around a bit. Interestingly, if I set
>>> -fsanitize=udefined and -fsanitize-undefined-trap-on-error the
>>> compiler detects that it will always trap, and optimizes the code
>>> accordingly (the code after the trap is removed).* Which kind of
>>> brings me to David's argument: Shouldn't the compiler warn if there
>>> is undefined behavior it certainly knows of?
>> Maybe an example would help.
>>
>> Consider this code:
>>
>> for (int i = start; i < limit; i++) {
>>    foo(i * 5);
>> }
>>
>> Should GCC be entitled to turn it into
>>
>> int limit_tmp = i * 5;
>> for (int i = start * 5; i < limit_tmp; i += 5) {
>>    foo(i);
>> }
>>
>> If you answered "Yes, GCC should be allowed to do this", would you
>> want a warning? And how many such warnings might there be in a typical
>> program?
> 
> Ok, let me see whether I get your point. I assume that should be "int 
> limit_tmp = limit * 5;".

Yes, sorry.

> In the original version I have a potential integer overflow while 
> passing a parameter. While in the second version, I have a potential 
> overflow in limit_tmp and therefore the loop range and number of calls 
> of foo is changed.

That's right.

> I think I start getting your point, but I none the less think it would 
> be really nice to have an option(!) to warn me about such things 
> nonetheless.

There aren't necesarily points in the compiler where GCC says "look,
this would be UB, so delete the code." Sometimes GCC simply assumes
that things like overflows cannot happen, so it ignores the
possibility. The code I provided is an example of that.

I suppose we could utilize the sanitize=undefined framework and emit a
warning everywhere a runtime check was inserted. That will at least
allow you to check in every case that the overflow, null pointer
exception, etc, cannot happen.

There would be a lot of warnings.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

  reply	other threads:[~2019-03-21  9:52 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-11  8:49 Moritz Strübe
2019-03-11  9:14 ` Jakub Jelinek
2019-03-11 11:06   ` Moritz Strübe
2019-03-11 11:17     ` Jakub Jelinek
2019-03-20 14:08       ` Moritz Strübe
2019-03-20 14:26         ` Christophe Lyon
2019-03-20 15:39           ` Moritz Strübe
2019-03-20 15:49         ` Jakub Jelinek
2019-03-20 17:36         ` Andrew Haley
2019-03-21  8:17           ` Richard Biener
2019-03-21  8:25             ` Alexander Monakov
2019-03-21  8:35               ` Richard Biener
2019-03-21  8:54           ` Moritz Strübe
2019-03-21  9:52             ` Andrew Haley [this message]
2019-03-11 11:24     ` Vincent Lefevre
2019-03-11 12:51       ` David Brown
2019-03-12 15:40         ` Vincent Lefevre
2019-03-12 20:57           ` David Brown
2019-03-13  2:25             ` Vincent Lefevre
2019-03-13 10:18               ` David Brown
2019-03-26 22:51                 ` Vincent Lefevre
2019-03-21 22:20   ` Allan Sandfeld Jensen
2019-03-21 22:31     ` Jakub Jelinek
2019-03-22  9:27       ` Allan Sandfeld Jensen
2019-03-22  9:50         ` Jakub Jelinek
2019-03-22 10:02     ` Andrew Haley
2019-03-22 10:20       ` Allan Sandfeld Jensen
2019-03-22 12:28         ` David Brown
2019-03-22 12:40           ` Jakub Jelinek
2019-03-22 13:38         ` Andrew Haley
2019-03-22 14:35           ` Allan Sandfeld Jensen
2019-03-22 22:08             ` Andrew Pinski
2019-03-22 22:38               ` Andrew Pinski
2019-03-22 23:42               ` Joseph Myers

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=6d48ceb5-9ebb-cd08-d6ed-ab6f7306d730@redhat.com \
    --to=aph@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=moritz.struebe@redheads.de \
    /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: link
Be 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).