Re: Handling of main() function for freestanding
On Tue, 4 Oct 2022 at 23:25, Jason Merrill 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.
There are some tests that fail if we do that. For whatever reason,
they're checking the current semantics.
Arsen implemented Jakub's suggestion which is to add the implicit
return by default, but add -fno-builtin-main to restore the previous
behaviour. Is that acceptable? If not, can you and Jakub reach
consensus so that Arsen knows what to do instead?
His -fno-builtin-main patch is at
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602644.html
(This is the only one of his patch series not committed, and results
in 100s of FAILs for libstdc++ when testing with -fffreestanding).
Quickbase Software Potential Clients
Hi, I hope you are staying healthy! Would you be interested in our 3D Architecture Software Contact sets? Few 3D Architecture Software Counts as below: Competitors Counts AutoCAD 15 3ds Max 11 Autodesk Revit 85000 V-Ray 30900 MicroStation 28500 Bluebeam Revu 18700 If you're looking for any other Software Users or Competitors datasets Share with me what you are looking for so that I can provide you with few samples accordingly. Awaiting a reply from you. Regards, Fluorine
Re: The GNU Toolchain Infrastructure Project
Hi, On Thu, 2022-10-06 at 17:37 -0400, Siddhesh Poyarekar wrote: > Also as I responded to Mark, the technical details of the transition are > the responsibility of the GTI TAC (which you were invited to be member > of and you declined) and not the LF IT, although they'd be the ones > implementing and maintaining it. > > We're at that stage at the moment where we look for consensus from the > project communities so that we understand if we can move all of > sourceware to LF IT or if we need both to coexist somehow. > > Once we have a direction, we talk about what that transition would look > like and ask questions accordingly. Are there services that you > absolutely cannot move to LF IT and why? Why would you support (or > oppose) porting the wiki to something like readthedocs backed by a git repo? > > I respect your outright rejection of the proposal because at least it is > clear that you don't have any stake in its fine tuning. Lets try to make this a little less adversarial. This doesn't have to be a clash of communities where there can be only one. Yes, the way this was introduced caused things to become very contentious. But at Cauldron we also agreed to bring this proposal to the overseers list and discuss it together. Of course we can coexist. Lets do a reset. Now that the plans are more public there will hopefully be less opportunity for speculation and misunderstandings. But there are still some unclear details and people have had various (unanswered) questions. It would be good to get answers to the questions people asked on overseers. And it would be great if the GTI TAC members discussed how they see the technical details of various services on the overseers list. We can then file specific sourceware infrastructure bugs to track the various technical needs from a community perspective. And hopefully we can then, as one community, take up shared responsibility of how to move things forward together. Cheers, Mark
Re: Handling of main() function for freestanding
On 10/7/22 07:30, Jonathan Wakely wrote:
On Tue, 4 Oct 2022 at 23:25, Jason Merrill 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.
There are some tests that fail if we do that. For whatever reason,
they're checking the current semantics.
* gcc.dg/c11-noreturn-4.c: Add -fno-builtin-main to options.
* gcc.dg/inline-10.c: Likewise.
IMO we still shouldn't emit these pedwarns when freestanding, we
shouldn't require people to add another flag to avoid them.
Adding the implicit return 0 unconditionally doesn't mean we also need
to adopt all the other special treatment of main.
And I guess we shouldn't implicitly return 0 if the function is declared
noreturn.
* gcc.dg/noreturn-4.c: Likewise.
I'd be inclined to drop this test.
Arsen implemented Jakub's suggestion which is to add the implicit
return by default, but add -fno-builtin-main to restore the previous
behaviour. Is that acceptable? If not, can you and Jakub reach
consensus so that Arsen knows what to do instead?
His -fno-builtin-main patch is at
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602644.html
(This is the only one of his patch series not committed, and results
in 100s of FAILs for libstdc++ when testing with -fffreestanding).
Re: Handling of main() function for freestanding
On Fri, Oct 07, 2022 at 09:51:31AM -0400, Jason Merrill wrote: > > There are some tests that fail if we do that. For whatever reason, > > they're checking the current semantics. > > > * gcc.dg/c11-noreturn-4.c: Add -fno-builtin-main to options. > > * gcc.dg/inline-10.c: Likewise. > > IMO we still shouldn't emit these pedwarns when freestanding, we shouldn't > require people to add another flag to avoid them. > > Adding the implicit return 0 unconditionally doesn't mean we also need to > adopt all the other special treatment of main. > > And I guess we shouldn't implicitly return 0 if the function is declared > noreturn. > > > * gcc.dg/noreturn-4.c: Likewise. > > I'd be inclined to drop this test. Ok. > > Arsen implemented Jakub's suggestion which is to add the implicit > > return by default, but add -fno-builtin-main to restore the previous > > behaviour. Is that acceptable? If not, can you and Jakub reach > > consensus so that Arsen knows what to do instead? > > His -fno-builtin-main patch is at > > https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602644.html > > (This is the only one of his patch series not committed, and results > > in 100s of FAILs for libstdc++ when testing with -fffreestanding). Jakub
Re: Question regarding copyright assignment
On Thu, Oct 6, 2022 at 8:58 PM Antoni Boucher via Gcc wrote: > Hi. > I contribute to gcc outside of work, but I'm about to sign a new work > contract which contains a work ownership clause saying that I give the > ownership to the company of any work not listed in some appendix. > > What exactly should I list to make sure my contributions to GCC are not > affected by this? > Do I need to do something more than this to make sure there are no > issues with the FSF copyright assignment? > > We cannot provide legal advice, employment advice or labor advice. One option is for you to contribute through a copyright assignment by your company or DCO authorized by your company. Another option is to enumerate FOSS projects in your employment agreement, if your company and hiring manager will permit that. The term GCC (GNU Compiler Collection) is interpreted to include the compiler and all components, including runtime libraries. You also might consider listing GLIBC, GDB and BINUTILS for completeness and potential overlap. Those four components are the terms used for Free Software Foundation copyright assignment forms and in the FSF file listing copyright assignments. Thanks, David
Re: Question regarding copyright assignment
Antoni, You'll want to get an employer disclaimer signed by your employer to make sure your contributions cannot be claimed by them. Please email ass...@fsf.org and we can work through the process. -- All the best, Craig Topham Copyright & Licensing Associate Free Software Foundation 51 Franklin Street, Fifth Floor Boston, MA 02110 Phone: +1-617-542-5942 Fax: +1-617-542-2652 Email: cra...@fsf.org GPG key: 36C9 950D 2F68 254E D89C 7C03 F9C1 3A10 581A B853
gcc-11-20221007 is now available
Snapshot gcc-11-20221007 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20221007/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision 02e0537caac41f177bc846edb6ba3bba15039867 You'll find: gcc-11-20221007.tar.xz Complete GCC SHA256=d139f25d352a51e890024328a79183dfe3fad68e76106b80ed722aa429ceb884 SHA1=1b3eed3e29db7c0c761310ca69fb8a6573d1ab7a Diffs from 11-20220930 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: How do I create a GCC source code tarball?
On Tue, 4 Oct 2022 12:03:12 -0700 Andrew Pinski via Gcc wrote: > > Building a full distribution of this tree isn't done > > via 'make dist'. Check out the etc/ subdirectory ... > You just tar up the source. > You could use maintainer-scripts/gcc_release to make a snapshot but in > the end it just does `tar xcfj file.tar.bz2 gcc` . If I may, the error message would be improved by making it shorter: > Building a full distribution of this tree isn't done > via 'make dist'. since that at least would be accurate! But why not just make it work again? Change the dist target in Makefile.in: dist: tar xcfj file.tar.bz2 gcc or dist: $(srcdir)/maintainer-scripts/gcc_release $(RELEASE_OPTS) where RELEASE_OPTS has some simple default. The user wishing to know more can inspect the script to determine what options to use. I spent several hours looking for information on how to do this. I wasn't counting on a decade of misdirection. It's not mentioned anywhere that I could find in the source tree or the wiki. I missed maintainer-scripts among the 75 files because it wasn't in upper case, where I expect to find developer information. If the process of generating nightly tarballs is documented, I missed that, too. I'm happy to open a PR or submit a patch. --jkl
