On 10/23/22 07:54, Arsen Arsenović via Gcc-patches wrote:
On Friday, 21 October 2022 23:02:02 CEST Joseph Myers wrote:
I have no objections to the C changes.
Great! Thanks for the review. I don't have push rights currently, so I
must ask that someone else pushes this patch for me.
Have a gr
On Friday, 21 October 2022 23:02:02 CEST Joseph Myers wrote:
> I have no objections to the C changes.
Great! Thanks for the review. I don't have push rights currently, so I
must ask that someone else pushes this patch for me.
Have a great day!
--
Arsen Arsenović
signature.asc
Description: T
On Fri, 21 Oct 2022, Arsen Arsenović via Gcc wrote:
> Ping on this patch.
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603574.html
>
> For context, see the rest of this thread. TL;DR is that `int main'
> should implicitly return 0 on freestanding, without the other burdens of
>
Ping on this patch.
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603574.html
For context, see the rest of this thread. TL;DR is that `int main'
should implicitly return 0 on freestanding, without the other burdens of
main (hosted should remain unchanged, as well as non-int `main's).
On 10/14/22 06:04, Arsen Arsenović wrote:
On Thursday, 13 October 2022 23:16:02 CEST Jason Merrill wrote:
I liked in the previous version that you checked the return type of
main when !flag_hosted, here and in c_missing_noreturn_ok_p. Let's
bring that back.
Ah, right; I forgot about that. Wha
On Thursday, 13 October 2022 23:16:02 CEST Jason Merrill wrote:
> I liked in the previous version that you checked the return type of
> main when !flag_hosted, here and in c_missing_noreturn_ok_p. Let's
> bring that back.
Ah, right; I forgot about that. What do you think of this?
Thanks,
--
A
On 10/13/22 16:14, Arsen Arsenović wrote:
On Thursday, 13 October 2022 19:24:41 CEST Jason Merrill wrote:
I was arguing that we don't need the new flag; there shouldn't be any
need to turn it off.
At the time, I opted to go with a more conservative route; I haven't
been around enough to have ve
On Thursday, 13 October 2022 19:24:41 CEST Jason Merrill wrote:
> I was arguing that we don't need the new flag; there shouldn't be any
> need to turn it off.
At the time, I opted to go with a more conservative route; I haven't
been around enough to have very strong opinions ;) I certainly can't
On Thursday, 13 October 2022 19:10:10 CEST Jakub Jelinek wrote:
> Don't we have such a test already elsewhere? If not, then certain
> "warn for main" part should be removed or replaced...
Whoops, missed that comment. There is actually an equivalent test that
I overlooked (noreturn-1.c), so mayb
On 10/13/22 13:02, Arsen Arsenović wrote:
Hi,
On Friday, 7 October 2022 15:51:31 CEST Jason Merrill wrote:
* gcc.dg/noreturn-4.c: Likewise.
I'd be inclined to drop this test.
That seems like an odd choice, why do that over using another function
for the test case? (there's nothing sp
On Thu, Oct 13, 2022 at 07:03:24PM +0200, Arsen Arsenović wrote:
> @@ -1,10 +1,10 @@
> /* Check for "noreturn" warning in main. */
> /* { dg-do compile } */
> -/* { dg-options "-O2 -Wmissing-noreturn -ffreestanding" } */
> +/* { dg-options "-O2 -Wmissing-noreturn" } */
> extern void exit (int) _
Hi,
On Friday, 7 October 2022 15:51:31 CEST Jason Merrill wrote:
> > * gcc.dg/noreturn-4.c: Likewise.
>
> I'd be inclined to drop this test.
That seems like an odd choice, why do that over using another function
for the test case? (there's nothing specific to main in this test, and
it doesn
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
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 ha
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
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
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)
On Thu, 29 Sept 2022 at 08:12, Jakub Jelinek 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
> > wrote:
> > >
> > > As part of implementing a C++23 proposal [1] to massively increase the
> > > scope of
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
> 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
> > a
On Wed, Sep 28, 2022 at 10:17 PM Jonathan Wakely via Gcc
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 r
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 t
21 matches
Mail list logo
