Re: Handling of main() function for freestanding

[Jonathan Wakely <jwakely.gcc@gmail.com>]

On Thu, 29 Sept 2022 at 08:12, Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Thu, Sep 29, 2022 at 08:00:15AM +0200, Richard Biener via Gcc wrote:
> > On Wed, Sep 28, 2022 at 10:17 PM Jonathan Wakely via Gcc
> > <gcc@gcc.gnu.org> 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.
> >  ^^^^^^^^^^^^^^^^^^^^^^
> >
> > so just document that 'int main(int, char **)' is special to GCC even in
> > freestanding environments and do not emit -Wreturn-type diagnostics?
> > I think that's entirely reasonable (but of course make sure to add
> > an implicit return 0; then as well)
>
> -fspecial-main is weirdly named, I wonder if we couldn't do the
> above by default and have -fno-builtin-main turn that special behavior
> off (in that case then don't append return 0 and emit -Wreturn-type
> diagnostics).  Not all our builtins are about whether we expand them inline, but
> about whether we apply special handling to those functions, assume special
> properties etc.  Just -fno-builtin shouldn't imply -fno-builtin-main...

Yeah, that sounds like a good compromise. Make int main do the right
thing by default, but offer a switch to restore the current behaviour
for anybody who really wants it.