public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Moritz Strübe" <moritz.struebe@redheads.de>
To: Andrew Haley <aph@redhat.com>, 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 08:54:00 -0000	[thread overview]
Message-ID: <42becef3-3cc8-de91-238b-673a931a73d9@redheads.de> (raw)
In-Reply-To: <7644f9cc-2fcd-c13c-a631-53c62c17333b@redhat.com>

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;".
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.
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. Use cases would be libraries, or at least their interfaces 
and critical software or just support finding potential bugs. Especially 
when using third party libraries this would can help find potential issues.
Would it be possible to annotate the inserted checks with a debug symbol 
or similar? That way one could compile using LTO and then search for the 
remaining symbols? That would allow static analysis tools to search for 
these symbols and annotate the code.

Cheers
Moritz


-- 
Redheads Ltd. Softwaredienstleistungen
Schillerstr. 14
90409 Nürnberg

Telefon: +49 (0)911 180778-50
E-Mail: moritz.struebe@redheads.de | Web: www.redheads.de

Geschäftsführer: Andreas Hanke
Sitz der Gesellschaft: Lauf
Amtsgericht Nürnberg HRB 22681
Ust-ID: DE 249436843


  parent reply	other threads:[~2019-03-21  8:54 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 [this message]
2019-03-21  9:52             ` Andrew Haley
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=42becef3-3cc8-de91-238b-673a931a73d9@redheads.de \
    --to=moritz.struebe@redheads.de \
    --cc=aph@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jakub@redhat.com \
    /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).