From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) by sourceware.org (Postfix) with ESMTPS id 524BA3858C20 for ; Mon, 31 Jan 2022 10:24:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 524BA3858C20 Received: by mail-wr1-x434.google.com with SMTP id s18so24375248wrv.7 for ; Mon, 31 Jan 2022 02:24:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O3c31PCMb+8E6r0FNaPway2rqZt0Zm93Diu5tJuSz4E=; b=rCV52bNuQ72Jgkuf+dgrxFWhCWcGKEQc8CStQgu7qyNr/0w54Csm5DQ8VRaVYqvcdb HbUicOoNAMSRnr5RQntzD/DsfW2lrW8cLTImWHKXVzsTzifo6ouI2OmEe6DtRpS3m9vf OZP9tV++/uyaU7CpFfbmQ3dKkMFUOwH9glNyBRrhAf+r1Rxxn0snBDHs+phvOEvx49Sk R0tzKpVJ/lTEjMYZE+HdW88m57OROzA26jwTLBVD4eNrx44WiXfkHm0N/cJXh1wh2lgX +DBXtJ9+o54ZzY6U7Zn7DYmhRvq7aDM8qTJejdFuJ0RYunsIoxCBnmywSGsmgO0ZpVNl lYEg== X-Gm-Message-State: AOAM532237mB9x3gyOMRECUWPosqAbbHagnvxZqOQCooubqv2kvjdIj6 e0cF1MhcnsmjWiIStFuuzroGsXkdGwJ+tudodp0= X-Google-Smtp-Source: ABdhPJxtzeitjgzCVJqW1WGoHePr/ClECrI+YXH3OnVWVlCrQlnXj+MI4xXOBhAVOZgWdCpwBU2WqF/iuU7BoPOV+ps= X-Received: by 2002:a5d:6da7:: with SMTP id u7mr16393269wrs.152.1643624645201; Mon, 31 Jan 2022 02:24:05 -0800 (PST) MIME-Version: 1.0 References: <20220130104145.GC2646553@tucnak> <20220130105822.GD2646553@tucnak> In-Reply-To: From: Jonathan Wakely Date: Mon, 31 Jan 2022 10:23:53 +0000 Message-ID: Subject: Re: Enquiry To: Theodore Papadopoulo Cc: Jakub Jelinek , "gcc@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, 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:24:07 -0000 On Mon, 31 Jan 2022 at 10:16, Theodore Papadopoulo wrote: > > 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. No, not really. You're looking at a very simple example, but the general case can be much more complicated, and undecidable by the compiler. The rules of the standard tend to be consistent, and not depend on how close the compiler can get to solving the halting problem. If there is a possible set of arguments to the function that avoids undefined behaviour, the compiler assumes the user only plans to use those arguments, and so will only warn and not give an error. Otherwise valid programs would be rejected. > 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). How can the compiler tell the difference between "the user forgot to handle a case" and "the user knows this case cannot happen and doesn't need to be handled"?