Re: Handling of main() function for freestanding

[Jakub Jelinek via Gcc]

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
> > 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...

Jakub

Re: DejaGnu: flags via 'RUNTESTFLAGS' overriding those specified in test cases

[Thomas Schwinge]

Hi!

On 2022-09-28T10:39:59-0500, Segher Boessenkool  
wrote:
> On Wed, Sep 28, 2022 at 03:12:23PM +0100, Jonathan Wakely wrote:
>> Which version of Dejagnu are you using? There was a fix in 6.1 or 6.2

(1.6.1, 1.6.2.)

>> to change the order that the RUNTESTFLAGS and dg-options get added to
>> the command line.

Ah, right,
...

However, that was not the problem here -- I'd been using such a DejaGnu
version.  That was strange, so I dug deeper, and found: in our *local*
DejaGnu board files a '[...]_target_compile' proc that likewise did need
to be fixed...  :-| With that done, the problem is then gone.

(I'm anyways attaching my "[WIP] nvptx: '-mdejagnu-ptx'", in case that's
ever useful for anyone, but not proposing to push that one.)

>> It's a pain to make the testsuite work consistently for both old and
>> new versions. I would be very happy if we just said you need a modern
>> version of Dejagnu, and relied on the semantics in the newer versions.
>
> Unfortunately there quite often are bugs in newer versions of DejaGnu
> as well, making it impossible to require very new versions of it.

The "require a more recent version of DejaGnu" discussion never gets old,
eh...  ;-P


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 3ce58c891359cd439518786448fd21a94c5a70a4 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 28 Sep 2022 22:14:55 +0200
Subject: [PATCH] [WIP] nvptx: '-mdejagnu-ptx'

Similar to 'gcc/config/rs6000/rs6000.h:DRIVER_SELF_SPECS'.
---
 gcc/config/nvptx/nvptx.h | 9 +
 gcc/testsuite/gcc.target/nvptx/atomic-store-1.c  | 2 +-
 gcc/testsuite/gcc.target/nvptx/atomic-store-2.c  | 2 +-
 gcc/testsuite/gcc.target/nvptx/float16-1.c   | 2 +-
 gcc/testsuite/gcc.target/nvptx/float16-2.c   | 2 +-
 gcc/testsuite/gcc.target/nvptx/float16-3.c   | 2 +-
 gcc/testsuite/gcc.target/nvptx/float16-4.c   | 2 +-
 gcc/testsuite/gcc.target/nvptx/float16-5.c   | 2 +-
 gcc/testsuite/gcc.target/nvptx/float16-6.c   | 2 +-
 gcc/testsuite/gcc.target/nvptx/nvptx.exp | 4 ++--
 gcc/testsuite/gcc.target/nvptx/ptx31.c   | 2 +-
 gcc/testsuite/gcc.target/nvptx/ptx60.c   | 2 +-
 gcc/testsuite/gcc.target/nvptx/ptx63.c   | 2 +-
 gcc/testsuite/gcc.target/nvptx/ptx70.c   | 2 +-
 gcc/testsuite/gcc.target/nvptx/sm53.c| 2 +-
 gcc/testsuite/gcc.target/nvptx/sm70.c| 2 +-
 gcc/testsuite/gcc.target/nvptx/sm75.c| 2 +-
 gcc/testsuite/gcc.target/nvptx/sm80.c| 2 +-
 gcc/testsuite/gcc.target/nvptx/tanh-1.c  | 2 +-
 gcc/testsuite/gcc.target/nvptx/uniform-simt-1.c  | 2 +-
 gcc/testsuite/gcc.target/nvptx/uniform-simt-2.c  | 2 +-
 gcc/testsuite/gcc.target/nvptx/uniform-simt-3.c  | 2 +-
 gcc/testsuite/gcc.target/nvptx/uniform-simt-4.c  | 2 +-
 libgomp/testsuite/libgomp.c/declare-variant-3-sm30.c | 2 +-
 libgomp/testsuite/libgomp.c/declare-variant-3-sm35.c | 2 +-
 libgomp/testsuite/libgomp.c/declare-variant-3-sm53.c | 2 +-
 libgomp/testsuite/libgomp.c/declare-variant-3-sm70.c | 2 +-
 libgomp/testsuite/libgomp.c/declare-variant-3-sm75.c | 2 +-
 libgomp/testsuite/libgomp.c/declare-variant-3-sm80.c | 2 +-
 libgomp/testsuite/libgomp.c/reverse-offload-sm30.c   | 2 +-
 30 files changed, 39 insertions(+), 30 deletions(-)

diff --git a/gcc/config/nvptx/nvptx.h b/gcc/config/nvptx/nvptx.h
index 0afc83b10a3..b015182a7d8 100644
--- a/gcc/config/nvptx/nvptx.h
+++ b/gcc/config/nvptx/nvptx.h
@@ -27,6 +27,15 @@
 
 /* Run-time Target.  */
 
+/* Only for use in the testsuite: -mdejagnu-ptx= filters out all
+   -mptx= options then simply adds -mptx=.
+   With older versions of Dejagnu the command line arguments you set in
+   RUNTESTFLAGS override those set in the testcases; with these options,
+   the testcase will always win.  */
+#define DRIVER_SELF_SPECS \
+  "%{mdejagnu-ptx=*: %

Re: Handling of main() function for freestanding

[Jonathan Wakely via Gcc]

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 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.

gcc-10-20220929 is now available

[GCC Administrator via Gcc]

Snapshot gcc-10-20220929 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/10-20220929/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-10 revision 4e80bbbf45352e5894fbebb7f33e984ada47aff4

You'll find:

 gcc-10-20220929.tar.xz   Complete GCC

  SHA256=cb31a81f807da2fdbb5a0bbf6876c29ea5a641e3910848616aacc34971e6b2a3
  SHA1=558c52744ee811a7bb72d04d91e9ac0028db9d1e

Diffs from 10-20220922 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-10
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.