From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) by sourceware.org (Postfix) with ESMTPS id 705F23858D28 for ; Sun, 30 Jan 2022 10:51:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 705F23858D28 Received: by mail-wr1-x42e.google.com with SMTP id s9so19790176wrb.6 for ; Sun, 30 Jan 2022 02:51:12 -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=JxLJghqhfbASzLVDbIqs7IWsuoDMAwbZvhiU6lviiIQ=; b=ORZmgCj/G4XKcOLVbeJxiW4TA9f7s3TRQyrhPA++XOnMxIMIgljH2FszDJhxMm0ohu 0KjNxThxq/a/bX4f1Dcnh8iNQnwCUEzOuc30Ils91RiK2VKqsrSfmPhCow4AOWys1lyw lsBXL1olfqEv76LK0sm4MVwJ3A/qr+lDxbJMerFtRlKjfH3FNu3iBNxpwlwj+tVXT5cr zrpdjMNxurn9WhUWtdXlrIlF1ZeWEq/LHYeYGNiCic3iEETRtJ0UJVrLh9HmAUZATN4R foYpiv5ouRPyN7rW6fbJb7PkIXcJhm/M1wwxaboNpDGCAkNwcgzJ5zCjZiLLzYFC6OCn S+kw== X-Gm-Message-State: AOAM533Z0GPtdVWTOC5o5J+EGYAcCLBivg1238cRY4MsgyUaPexDnP9B hlF8BAiQPtN/KLFRTf+EvAUFzGP0s29rh8Bj8Yc= X-Google-Smtp-Source: ABdhPJwzpR0Tvqx/XqRzWD2dXcfAbkYrayBZygipxCbrA1OHscbtZOncBLLoGKdAC59u/RKRzUqImORHcpJckC54iDY= X-Received: by 2002:a5d:4c81:: with SMTP id z1mr13263725wrs.568.1643539871272; Sun, 30 Jan 2022 02:51:11 -0800 (PST) MIME-Version: 1.0 References: <20220130104145.GC2646553@tucnak> In-Reply-To: <20220130104145.GC2646553@tucnak> From: Jonathan Wakely Date: Sun, 30 Jan 2022 10:50:56 +0000 Message-ID: Subject: Re: Enquiry To: Jakub Jelinek Cc: Theodore Papadopoulo , "gcc@gcc.gnu.org" 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, HTML_MESSAGE, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Sun, 30 Jan 2022 10:51:14 -0000 On Sun, 30 Jan 2022, 10:42 Jakub Jelinek via Gcc, wrote: > On Sun, Jan 30, 2022 at 10:47:41AM +0100, Theodore Papadopoulo wrote: > > Before creating a bug report, I want to check with the GCC community (all > > the more that checking that the problem has not yet been reported is > > complicated at leat for me). > > > > The following (admitedly buggy) program generates a segmentation > violation > > on fedora 35 (this is with g++ 11.2.1 20211203 (Red Hat 11.2.1-7) (GCC)) > > when compiled with -O3 (other versions replacing unisgned by std::string > may > > trigger the exception instead of the segv) > > > > bool assert_sthg(const unsigned s) { > > if (s==123) > > throw 1; > > } > > > > int main() { > > assert_sthg(0); > > return 0; > > } > > > > When compiling, we indeed get a warning: > > > > test.C:4:1: warning: control reaches end of non-void function > > [-Wreturn-type] > > > > I can well understand that the program being buggy that the optimizer is > > allowed to do anything including the observed segmentation violation. > > Yet the result is quite surprising.... > > Undefined behavior can have any kind of surprising behavior. > > > The question is, in that case, wouldn't it be better to turn the warning > > into an error at -O3 ? > > No, it can't be an error by default, it is undefined behavior only at > runtime, if you never call the function or always call it with > assert_sthg(123), then the program can be valid. > 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.