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

[Thomas Schwinge]

Hi!

On 2022-02-04T13:09:29+0100, Tom de Vries via Gcc  wrote:
> On 2/4/22 08:21, Thomas Schwinge wrote:
>> On 2022-02-03T13:35:55+, "vries at gcc dot gnu.org via Gcc-bugs" 
>>  wrote:
>>> while iterating over dimensions { -mptx=3.1 , -mptx=6.3 } x { 
>>> GOMP_NVPTX_JIT=-O0,  }.
>>
>> Do you use separate (nvptx-none offload target only?) builds for
>> different '-mptx' variants (likewise: '-misa'), or have you hacked up the
>> multilib configuration?
>
> Neither, I'm using --target_board=unix/foffload= for that.

OK, so that's for libgomp nvptx offloading testing.

What about nvptx target testing:
'gcc/testsuite/gcc.target/nvptx/nvptx.exp'.

We have a DejaGnu board file, say 'BOARD', invoking the nvptx-tools
'nvptx-none-run' launcher
():

$ make check RUNTESTFLAGS='--target_board=BOARD'

That generally works as expected.

But now suppose that 'BOARD' needs '-mptx=3.1', because old CUDA, for
example.  Running the obvious '--target_board=BOARD/-mptx=3.1' FAILs in a
number of 'gcc.target/nvptx/nvptx.exp' test cases, for example:

FAIL: gcc.target/nvptx/alias-1.c (test for excess errors)
Excess errors:
[...]/gcc.target/nvptx/alias-1.c:13:6: error: alias definitions not 
supported in this configuration

That's because we then invoke GCC as follows:

[GCC] [...]/gcc.target/nvptx/alias-1.c [...] -malias -mptx=6.3 [...] 
-mptx=3.1 -o ./alias-1.exe

Here, '-malias -mptx=6.3' are due to 'dg-add-options ptx_alias' in the
test case, but our '-mptx=3.1' overrides that, thus FAIL.  I think these
would work if the '-mptx=3.1' came first?

Do we need something like this:

gcc/config/rs6000/rs6000.h:/* Only for use in the testsuite: 
-mdejagnu-cpu= filters out all
gcc/config/rs6000/rs6000.h-   -mcpu= as well as -mtune= options then simply 
adds -mcpu=,
gcc/config/rs6000/rs6000.h:   while -mdejagnu-tune= filters out all 
-mtune= options then
gcc/config/rs6000/rs6000.h-   simply adds -mtune=.
gcc/config/rs6000/rs6000.h-   With older versions of Dejagnu the command 
line arguments you set in
gcc/config/rs6000/rs6000.h-   RUNTESTFLAGS override those set in the 
testcases; with these options,
gcc/config/rs6000/rs6000.h-   the testcase will always win.  */
gcc/config/rs6000/rs6000.h-#define DRIVER_SELF_SPECS \
gcc/config/rs6000/rs6000.h:  "%{mdejagnu-cpu=*: % does not affect the -m assembler option)"
  - commit 75d20d6c84c12bedd65a904e462f02f0b9eb3f77 "rs6000: Adjust 
-mdejagnu-cpu to filter out -mtune [PR106345]"

(For example, we'd then use '-mdejagnu-ptx=[...]' in the test case (here, via
'dg-add-options ptx_alias'), overriding the '-mptx=3.1' of 'RUNTESTFLAGS'.)


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

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

[Jonathan Wakely via Gcc]

On Wed, 28 Sept 2022 at 14:50, Thomas Schwinge  wrote:
>
> Hi!
>
> On 2022-02-04T13:09:29+0100, Tom de Vries via Gcc  wrote:
> > On 2/4/22 08:21, Thomas Schwinge wrote:
> >> On 2022-02-03T13:35:55+, "vries at gcc dot gnu.org via Gcc-bugs" 
> >>  wrote:
> >>> while iterating over dimensions { -mptx=3.1 , -mptx=6.3 } x { 
> >>> GOMP_NVPTX_JIT=-O0,  }.
> >>
> >> Do you use separate (nvptx-none offload target only?) builds for
> >> different '-mptx' variants (likewise: '-misa'), or have you hacked up the
> >> multilib configuration?
> >
> > Neither, I'm using --target_board=unix/foffload= for that.
>
> OK, so that's for libgomp nvptx offloading testing.
>
> What about nvptx target testing:
> 'gcc/testsuite/gcc.target/nvptx/nvptx.exp'.
>
> We have a DejaGnu board file, say 'BOARD', invoking the nvptx-tools
> 'nvptx-none-run' launcher
> ():
>
> $ make check RUNTESTFLAGS='--target_board=BOARD'
>
> That generally works as expected.
>
> But now suppose that 'BOARD' needs '-mptx=3.1', because old CUDA, for
> example.  Running the obvious '--target_board=BOARD/-mptx=3.1' FAILs in a
> number of 'gcc.target/nvptx/nvptx.exp' test cases, for example:
>
> FAIL: gcc.target/nvptx/alias-1.c (test for excess errors)
> Excess errors:
> [...]/gcc.target/nvptx/alias-1.c:13:6: error: alias definitions not 
> supported in this configuration
>
> That's because we then invoke GCC as follows:
>
> [GCC] [...]/gcc.target/nvptx/alias-1.c [...] -malias -mptx=6.3 [...] 
> -mptx=3.1 -o ./alias-1.exe
>
> Here, '-malias -mptx=6.3' are due to 'dg-add-options ptx_alias' in the
> test case, but our '-mptx=3.1' overrides that, thus FAIL.  I think these
> would work if the '-mptx=3.1' came first?

Which version of Dejagnu are you using? There was a fix in 6.1 or 6.2
to change the order that the RUNTESTFLAGS and dg-options get added to
the command line.

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.

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

[Segher Boessenkool]

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
> to change the order that the RUNTESTFLAGS and dg-options get added to
> the command line.
> 
> 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.


Segher

Re: commit signing

[Ulrich Drepper via Gcc]

On Wed, Sep 14, 2022 at 2:07 PM Ulrich Drepper  wrote:

> On Wed, Sep 14, 2022 at 1:31 PM Richard Biener 
> wrote:
>
>> How does this improve supply chain security if the signing happens
>> automagically rather than manually at points somebody actually
>> did extra verification?
>
>
> It works only automatically if you have ssh-agent (and/or gpg-agent)
> running.  I assume that's what developers do anyway because that's how they
> like push changes to sourceware.  If you don't have an agent you'll have to
> provide the signature of the signing key at the time of the commit.
>


This was the last message I sent and no further questions or comments
arrived.

Shall I prepare a small patch with an initial version of the key files
(with my key), perhaps a patch to the setup script Jonathan mentioned, and
a few words to be added to a README or similar file (which?)?

Initially this could be optional and we could gather data on the pickup and
only after an initial period switch to make the signing mandatory.

Re: GNU Tools Cauldron 2022

[Vineet Gupta]

Hi,

On 9/16/22 00:47, Jan Hubicka via Gcc wrote:

Hello,

Hello,

We are pleased to invite you all to the next GNU Tools Cauldron,
taking place in Paris on September 16-18, 2022.  We are looking forward
to meet you again after three years!

As for the previous instances, we have setup a wiki page for
details:

  https://gcc.gnu.org/wiki/cauldron2022  



I was interest in watching the RISC-V Vector presentation:
First presentation of Day 2 @ S9 [1].
But it seems it was not recorded or am I looking at wrong place.

Also Juzhe is it possible to share the slides, as they seem to be 
missing on Cauldron page [2]


Thx,
-Vineet

[1] https://www.youtube.com/watch?v=dOIwE2932XI
[2] https://gcc.gnu.org/wiki/cauldron2022

Re: GNU Tools Cauldron 2022

[Vineet Gupta]

On 9/28/22 10:03, Vineet Gupta wrote:

We are pleased to invite you all to the next GNU Tools Cauldron,
taking place in Paris on September 16-18, 2022.  We are looking forward
to meet you again after three years!

As for the previous instances, we have setup a wiki page for
details:

https://gcc.gnu.org/wiki/cauldron2022 



I was interest in watching the RISC-V Vector presentation:
First presentation of Day 2 @ S9 [1].
But it seems it was not recorded or am I looking at wrong place.


At seems it starts later around 57 minute mark.

Thx

Handling of main() function for freestanding

[Jonathan Wakely via Gcc]

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

Re: The GNU Toolchain Infrastructure project

[David Edelsohn via Gcc]

On Tue, Sep 27, 2022 at 4:05 PM David Edelsohn  wrote:

> Carlos O'Donell and I are proud to announce and provide more detail about
> the GNU Toolchain Infrastructure project.
>
> https://sourceware.org/pipermail/overseers/2022q3/018896.html
>
> Thanks, David
>

The minutes from the first GTI TAC meeting, the slides of the LF IT
presentation, and the video recording of the meeting have been published on
the GNU LIBC website:

https://sourceware.org/pipermail/libc-alpha/2022-September/142288.html

Thanks, David

Re: Handling of main() function for freestanding

[Richard Biener via Gcc]

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)

Richard.

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