From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sourceware.org (Postfix) with ESMTPS id 0B9D13858C20 for ; Mon, 31 Jan 2022 10:16:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0B9D13858C20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=inria.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=inria.fr X-IronPort-AV: E=Sophos;i="5.88,330,1635199200"; d="scan'208";a="4547134" Received: from for59-1_migr-88-160-150-141.fbx.proxad.net (HELO [192.168.86.171]) ([88.160.150.141]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Jan 2022 11:16:16 +0100 Message-ID: Date: Mon, 31 Jan 2022 11:16:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Jakub Jelinek , Jonathan Wakely Cc: "gcc@gcc.gnu.org" References: <20220130104145.GC2646553@tucnak> <20220130105822.GD2646553@tucnak> From: Theodore Papadopoulo Organization: INRIA Subject: Re: Enquiry In-Reply-To: <20220130105822.GD2646553@tucnak> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2022 10:16:19 -0000 On 1/30/22 11:58, Jakub Jelinek wrote: > On Sun, Jan 30, 2022 at 10:50:56AM +0000, Jonathan Wakely wrote: >> We could put a trap instruction at the end of the function though, which >> would make the result a bit less arbitrary. >> >> I've come around to thinking that's preferable for cases like this. > Depends on which exact cases. > Because for > int foo (int s) { if (s == 123) return 1; } > we want to optimize it into > return 1; > rather than if (s == 123) return 1; else __builtin_trap (); > For debugging we have -fsanitize=undefined > > Jakub > I understand completely, it is undefined behaviour.  What I had not realized is that undefined behaviour is not a property of the function itself, but of the function call when parameters are specified. That seems more difficult to handle from the compiler perspective, but if that is the rule, so be it... It seems to me that this is a case that just makes things more complicated for programmers (and compiler developers) for the benefit of only a small community which will know the precise limits of the undefined behaviour and would like to play at the boundary of the cliff. Honestly, for the user perspective (or more exactly a majority of users), it would be nice if there was a way to catch such situations at compile time (making of course more strict assumptions on the compiler side). Of course, I can fire gdb or -fsanitize=undefined, but whatever can be caught earlier is better.... I will turn that specific warning into a an error with -Werrror=XXX for my own usage. Thank's for the explanations. At least, I learned something. Hope I did not waste too much of your time.     Theo.