From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) by sourceware.org (Postfix) with ESMTPS id 03A883858C20 for ; Mon, 31 Jan 2022 10:34:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 03A883858C20 Received: by mail-wr1-x42c.google.com with SMTP id k18so24465099wrg.11 for ; Mon, 31 Jan 2022 02:34:02 -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=R+Vj9pPJBZTzD63rMbGXCwH/eaoqYJcYVbzgtffqyXo=; b=awkmDbV+lKZT9BRrnhVl+ajoGM8pDjI+Zb42Vwomo8JYB054wAHJ9gsxzAFkR4zY+N T+S5d1do6PSugMk1dKZfvzcsGS+Z5xbpWXz+nbeID48h36LL2sj+6GeNYH+tQY7Vq89t BBWRA49gLvgyXjDIy+99Kt6FSx92VKmhy2uQHveiPaLRa17YN/6r5td57n8b3zi7s3Op NLlgQAbQOABcvVnwshJXC010vdXmM2yRhese7dpLJ6a86P/sYIuMKx9Ozs7lwo66fZRU CxXY1M1bc0NyZiJCggrqWPuOYRdiQaDbiK4LOHoA13oubH7tj4Z5WrkyDkfUpeshk6hI lUKA== X-Gm-Message-State: AOAM531Ru3WyrsmvRZA7s8HKqyzjvRQyVounUB5ZjtuVDxUlslTr0yfM /fm56RxqWJQ/e7m0wNvtYW8RfV20aRQ2my6S9BY= X-Google-Smtp-Source: ABdhPJx8dNEdOO2uuQxhom746eQ0eMwuaNv+/kn5zfVNaIu4OVOtnrLEg6e8vqcGXTOkoN4JfJrt6DsZW5otn9+UrQ8= X-Received: by 2002:a5d:548a:: with SMTP id h10mr7909340wrv.221.1643625242131; Mon, 31 Jan 2022 02:34:02 -0800 (PST) MIME-Version: 1.0 References: <20220130104145.GC2646553@tucnak> <20220130105822.GD2646553@tucnak> <87czk86w2l.fsf@igel.home> In-Reply-To: <87czk86w2l.fsf@igel.home> From: Jonathan Wakely Date: Mon, 31 Jan 2022 10:33:50 +0000 Message-ID: Subject: Re: Enquiry To: Andreas Schwab Cc: Jonathan Wakely via Gcc , Jakub Jelinek , Theodore Papadopoulo 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:34:04 -0000 On Mon, 31 Jan 2022 at 10:25, Andreas Schwab wrote: > > On Jan 30 2022, Jonathan Wakely via Gcc wrote: > > > On Sun, 30 Jan 2022, 10: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 > > > > > > What if we inserted the trap for -O0? > > Note that in C it is not an error to fall through the end of a non-void > function if the caller does not use the return value. Indeed. Theo's program is undefined in C++ and valid in C. I would love to see the trap inserted for C++ though.