From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13538 invoked by alias); 21 Mar 2019 09:52:02 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 13530 invoked by uid 89); 21 Mar 2019 09:52:01 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:42becef, H*i:sk:42becef, H*MI:sk:42becef X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 21 Mar 2019 09:52:00 +0000 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1389285541; Thu, 21 Mar 2019 09:51:59 +0000 (UTC) Received: from zebedee.pink (unknown [10.33.36.158]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3C3791001E7A; Thu, 21 Mar 2019 09:51:58 +0000 (UTC) To: =?UTF-8?Q?Moritz_Str=c3=bcbe?= , Jakub Jelinek , "gcc@gcc.gnu.org" References: <4af9e251-f4c3-a5a4-e33d-fb8750c87e36@redheads.de> <20190311091449.GB7611@tucnak> <9085342b-41a6-851c-28e3-08a40cc30103@redheads.de> <20190311111702.GD7611@tucnak> <99e48024-6331-2ba6-272c-51f8cf9e9780@redheads.de> <7644f9cc-2fcd-c13c-a631-53c62c17333b@redhat.com> <42becef3-3cc8-de91-238b-673a931a73d9@redheads.de> From: Andrew Haley Openpgp: preference=signencrypt Subject: Re: GCC turns &~ into | due to undefined bit-shift without warning Message-ID: <6d48ceb5-9ebb-cd08-d6ed-ab6f7306d730@redhat.com> Date: Thu, 21 Mar 2019 09:52:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <42becef3-3cc8-de91-238b-673a931a73d9@redheads.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00155.txt.bz2 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. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671