From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-f44.google.com (mail-oa1-f44.google.com [209.85.160.44]) by sourceware.org (Postfix) with ESMTPS id 738C03858C50 for ; Tue, 4 Oct 2022 23:28:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 738C03858C50 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rtems.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oa1-f44.google.com with SMTP id 586e51a60fabf-12c8312131fso18247915fac.4 for ; Tue, 04 Oct 2022 16:28:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=b1KR0UCZvTHRBY3bMGWwzMeyyGC306tEtocoyfbUbhE=; b=0X4Ti3YWrk6Y4fjsKHENZju6XMEMcJswgR8MdLhrxokxLK+nlqWhNV+4kNpBPCYO4w uIXI161o74YjoJSAgrY2hwxMt0SYG7LQF5SiVvqtjLXHAV+qol68z3SZItPqzxsxzkUl mEjw8Nj11kprnrWFRsrh4NtKFIb+f7xh943HAmZMBufdo9ZhlmXBe1bRM7Z6/siVGwx0 Xi5bouegKsmpqP08zIFPUoyzi0fPoFDAw5cpWo1vI1if8tyouk/PQPJ5f2KRWWolQwpf zgWtU/r+hDcZsbHhFY8N2rs1Y/GflPqJOkwC1R7n5jLxf+ZShDE/fL66PVzrJ8pTFn11 rLUQ== X-Gm-Message-State: ACrzQf3Dg1Jk3Im0Hm+z8p50nHnAxnj0TwRMBsd4SYArtXM1ghZD4PBK Xv05WT1RMDOzKtt0sMBJRQ8xDFmOAEM= X-Google-Smtp-Source: AMsMyM4fFaZ+ifF3wThlvg7cAuxdg1Kbyq/RYKV2AIwmjhehXlmz6qIyOR2NGzFv1IzTvP4DEN+61g== X-Received: by 2002:a05:6871:153:b0:132:6934:1a73 with SMTP id z19-20020a056871015300b0013269341a73mr1150387oab.258.1664926117428; Tue, 04 Oct 2022 16:28:37 -0700 (PDT) Received: from mail-oa1-f42.google.com (mail-oa1-f42.google.com. [209.85.160.42]) by smtp.gmail.com with ESMTPSA id bx14-20020a0568081b0e00b00342fedaf7d9sm3461444oib.43.2022.10.04.16.28.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Oct 2022 16:28:37 -0700 (PDT) Received: by mail-oa1-f42.google.com with SMTP id 586e51a60fabf-13207a86076so13969355fac.3 for ; Tue, 04 Oct 2022 16:28:36 -0700 (PDT) X-Received: by 2002:a05:6870:638f:b0:132:a103:ae12 with SMTP id t15-20020a056870638f00b00132a103ae12mr1102833oap.185.1664926116581; Tue, 04 Oct 2022 16:28:36 -0700 (PDT) MIME-Version: 1.0 References: <44594c0c-db9d-459a-7ecc-29c4f5544b28@redhat.com> In-Reply-To: <44594c0c-db9d-459a-7ecc-29c4f5544b28@redhat.com> Reply-To: joel@rtems.org From: Joel Sherrill Date: Tue, 4 Oct 2022 18:28:25 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Handling of main() function for freestanding To: Jason Merrill Cc: Jonathan Wakely , GCC Content-Type: multipart/alternative; boundary="000000000000c199d605ea3dd10b" X-Spam-Status: No, score=-3031.1 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000c199d605ea3dd10b Content-Type: text/plain; charset="UTF-8" Speaking from an RTEMS perspective, many of our examples show an initialisation thread setting up arguments to invoke main() with argc and argv and processing the return code. I would lean to main(int, char**) being known special by gcc. It won't bother the RTEMS embedded environment at all to do so. If it causes others an issue, perhaps they need to align with standards a bit better. :) --joel On Tue, Oct 4, 2022, 5:26 PM Jason Merrill via Gcc wrote: > On 9/28/22 16:15, Jonathan Wakely wrote: > > As part of implementing a C++23 proposal [1] to massively increase the > > scope of the freestanding C++ standard library some questions came up > > about the special handling of main() that happens for hosted > > environments. > > > > As required by both C++ (all versions) and C (since C99), falling off > > the end of the main() function is not undefined, the compiler is > > required to insert an implicit 'return 0' [2][3]. However, this > > special handling only applies to hosted environments. For freestanding > > the return type or even the existence of main is > > implementation-defined. As a result, GCC gives a -Wreturn-type warning > > for this code with -ffreestanding, but not with -fhosted: > > > > int main() { } > > > > Arsen (CC'd) has been working on the libstdc++ changes for the > > freestanding proposal, and several thousand libstdc++ tests were > > failing when using -ffreestanding, because of the -Wreturn-type > > warnings. He wrote a patch to the compiler [4] to add a new > > -fspecial-main flag which defaults to on for -fhosted, but can be used > > with -ffreestanding to do the implicit 'return 0' (and so disable the > > -Wreturn-type warnings) for freestanding as well. This fixes the > > libstdc++ test FAILs. > > > > However, after discussing this briefly with Jason it occurred to us > > that if the user declares an 'int main()' function, it's a pretty big > > hint that they do want main() to return an int. And so having > > undefined behaviour do to a missing return isn't really doing anybody > > any favours. If you're compiling for freestanding and you *don't* want > > to return a value from main(), then just declare it as void main() > > instead. So now we're wondering if we need -fspecial-main at all, or > > if int main() and int main(int, char**) should always be "special", > > even for freestanding. So Arsen wrote a patch to do that too [5]. > > > > The argument against making 'int main()' imply 'special main' is that > > in a freestanding environment, a function called 'int main()' might be > > just a normal function, not the program's entry point. And in that > > case, maybe you really do want -Wreturn-type warnings. I don't know > > how realistic that is. > > > > So the question is, should Arsen continue with his -fspecial-main > > patch, and propose it along with the libstdc++ changes, or should gcc > > change to always make 'int main()' "special" even for freestanding? > > void main() and long main() and other signatures would still be > > allowed for freestanding, and would not have the implicit 'return 0'. > > I would rather not add a flag. No well-defined freestanding program is > affected by implicit return 0 from main, it should always be enabled. > > > I have no horse in this race, so if the maintainers of bare metal > > ports think int main() should not be special for -ffreestanding, so be > > it. I hope the first patch to add -fspecial-main would be acceptable > > in that case, and libstdc++ will use it when testing with > > -ffreestanding. > > > > [1] > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1642r11.html > > [2] https://eel.is/c++draft/basic.start.main#5.sentence-2 > > [3] https://cigix.me/c17#5.1.2.2.3.p1 > > [4] > https://github.com/ArsenArsen/gcc/commit/7e67edaced33e31a0dd4db4b3dd404c4a8daba59 > > [5] > https://github.com/ArsenArsen/gcc/commit/c9bf2f9ed6161a38238e9c7f340d2c3bb04fe443 > > > > --000000000000c199d605ea3dd10b--