From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91063 invoked by alias); 20 Mar 2019 15:49:45 -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 91047 invoked by uid 89); 20 Mar 2019 15:49:45 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_05,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=brings, moritz, Davids, Strbe 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; Wed, 20 Mar 2019 15:49:43 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 65E7030FE5DA; Wed, 20 Mar 2019 15:49:42 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-107.ams2.redhat.com [10.36.116.107]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0C6395D9CD; Wed, 20 Mar 2019 15:49:41 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id x2KFnXEH004264; Wed, 20 Mar 2019 16:49:38 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id x2KFnVfi004262; Wed, 20 Mar 2019 16:49:31 +0100 Date: Wed, 20 Mar 2019 15:49:00 -0000 From: Jakub Jelinek To: Moritz =?iso-8859-1?Q?Str=FCbe?= Cc: "gcc@gcc.gnu.org" Subject: Re: GCC turns &~ into | due to undefined bit-shift without warning Message-ID: <20190320154931.GJ7611@tucnak> Reply-To: Jakub Jelinek 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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <99e48024-6331-2ba6-272c-51f8cf9e9780@redheads.de> User-Agent: Mutt/1.10.1 (2018-07-13) X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00143.txt.bz2 On Wed, Mar 20, 2019 at 02:08:09PM +0000, 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? What does it mean certainly knows of? The sanitization inserts (conditional) traps for all the constructs that it sanitizes, you certainly don't want warning for that. Even if the compiler can simplify or optimize out some of the guarding conditionals around the traps, that doesn't mean it isn't in dead code that will never be executed. The only safe warning might be if the compiler can prove that whenever main is called, there will be a trap executed later on, but that is not the case in most programs, as one can't prove for most functions they actually never loop and always return to the caller instead of say exiting, aborting, etc. (and even if main traps immediately, one could have work done in constructors and exit from there). Otherwise, would you like to warn if there is unconditional trap in some function? That function could not be ever called, or it could make some function calls before the trap that would never return (exit, abort, throw exception, infinite loop). Jakub