C89isms in the test suite

C89isms in the test suite

[Florian Weimer]

What should we do about these when they are not relevant to what's being
tested?  For example, gcc/testsuite/gcc.c-torture/execute/ieee/mzero6.c
has this:

  int main ()
  {
    if (__builtin_copysign (1.0, func (0.0 / -5.0, 10)) != -1.0)
      abort ();
    exit (0);
  }

but no include files, so abort and exit are implicitly declared.

Should we inject a header with -include with the most common
declarations (which includes at least abort and exit)?  Or add the
missing #include directives?  But the latter might not work for
freestanding targets.

Implicit ints and function declarations without prototypes are also
common (not just for main).

Other tests look like they might be intended to be built in C89 mode,
e.g.  gcc/testsuite/gcc.c-torture/compile/386.c, although it's not
immediately obvious to me what they test.

Thanks,
Florian

Re: C89isms in the test suite

[Jakub Jelinek]

On Fri, Oct 21, 2022 at 10:40:16AM +0200, Florian Weimer via Gcc wrote:
> What should we do about these when they are not relevant to what's being
> tested?  For example, gcc/testsuite/gcc.c-torture/execute/ieee/mzero6.c
> has this:
> 
>   int main ()
>   {
>     if (__builtin_copysign (1.0, func (0.0 / -5.0, 10)) != -1.0)
>       abort ();
>     exit (0);
>   }
> 
> but no include files, so abort and exit are implicitly declared.
> 
> Should we inject a header with -include with the most common
> declarations (which includes at least abort and exit)?  Or add the
> missing #include directives?  But the latter might not work for
> freestanding targets.
> 
> Implicit ints and function declarations without prototypes are also
> common (not just for main).
> 
> Other tests look like they might be intended to be built in C89 mode,
> e.g.  gcc/testsuite/gcc.c-torture/compile/386.c, although it's not
> immediately obvious to me what they test.

I think these days we at least for abort tend to use __builtin_abort ();
if we don't want to declare it (in other tests we declare it ourselves).
exit we usually don't use at all, but sometimes we handle it similarly
to abort.

	Jakub

Re: C89isms in the test suite

[Florian Weimer]

* Jakub Jelinek:

> On Fri, Oct 21, 2022 at 10:40:16AM +0200, Florian Weimer via Gcc wrote:
>> What should we do about these when they are not relevant to what's being
>> tested?  For example, gcc/testsuite/gcc.c-torture/execute/ieee/mzero6.c
>> has this:
>> 
>>   int main ()
>>   {
>>     if (__builtin_copysign (1.0, func (0.0 / -5.0, 10)) != -1.0)
>>       abort ();
>>     exit (0);
>>   }
>> 
>> but no include files, so abort and exit are implicitly declared.
>> 
>> Should we inject a header with -include with the most common
>> declarations (which includes at least abort and exit)?  Or add the
>> missing #include directives?  But the latter might not work for
>> freestanding targets.
>> 
>> Implicit ints and function declarations without prototypes are also
>> common (not just for main).
>> 
>> Other tests look like they might be intended to be built in C89 mode,
>> e.g.  gcc/testsuite/gcc.c-torture/compile/386.c, although it's not
>> immediately obvious to me what they test.
>
> I think these days we at least for abort tend to use __builtin_abort ();
> if we don't want to declare it (in other tests we declare it ourselves).
> exit we usually don't use at all, but sometimes we handle it similarly
> to abort.

So we would patch the tests?  I guess we can make sure we use “int main
(void)” etc. at the same time.

One thing we haven't discussed much so far is PR106416 (-Wint-conversion
should be an error, not a pedwarn).  I think I found the place in the
GCC sources to patch to turn this into an error, but I haven't tried it
yet to see what happens.  I assume the rule is the same for the other
historic stuff (accepted in C89 mode with a warning, error in C99 or
later language modes).

What's the expected default behavior for GCC 14 regarding old-style
function definitions (function definitions which do not have a
prototype)?  I assume if GCC 14 defaults to C2x mode, these no longer
valid constructs would be rejected by default?  Based on some earlier
experiments, the C2x changes for unnamed parameters is in fact
compatible with GCC's existing implementation of implicit ints and
old-syle function definitions: identifiers which denote a type are
already rejected today and not treated as a parameter of type int.

Thanks,
Florian

Re: C89isms in the test suite

[Jakub Jelinek]

On Fri, Oct 21, 2022 at 11:17:40AM +0200, Florian Weimer wrote:
> So we would patch the tests?

Depends on how large the patch is, but I'd say so.

>  I guess we can make sure we use “int main
> (void)” etc. at the same time.

Why?  Isn't int main () {} in C2X the same thing as int main (void) {} ?
int main () {...} is in 3500+ C tests and every day a few are added...

> One thing we haven't discussed much so far is PR106416 (-Wint-conversion
> should be an error, not a pedwarn).  I think I found the place in the
> GCC sources to patch to turn this into an error, but I haven't tried it
> yet to see what happens.  I assume the rule is the same for the other
> historic stuff (accepted in C89 mode with a warning, error in C99 or
> later language modes).

Or no warning in C89 mode and just error in C99+?
I think you want Joseph to chime in and decide.

	Jakub

Re: C89isms in the test suite

[Florian Weimer]

* Jakub Jelinek:

> On Fri, Oct 21, 2022 at 11:17:40AM +0200, Florian Weimer wrote:
>> So we would patch the tests?
>
> Depends on how large the patch is, but I'd say so.
>
>>  I guess we can make sure we use “int main
>> (void)” etc. at the same time.
>
> Why?  Isn't int main () {} in C2X the same thing as int main (void) {} ?
> int main () {...} is in 3500+ C tests and every day a few are added...

Is this really possible?  For function pointers, it's an ABI change.
int (*) () and int (*) (void) have different calling conventions on some
ABIs (e.g., powerpc64le-linux-gnu).  The ABI difference goes away once
the callees are rebuilt, and I think such rebuilt callees are compatible
with either calling convention.

But still, if C2X forces such a silent ABI change, that's kind of
troublesome.  On the other hand, it addresses a potential
interoperability trap with C++ code.

Thanks,
Florian

Re: C89isms in the test suite

[Florian Weimer]

* Florian Weimer via Gcc:

> * Jakub Jelinek:
>
>> On Fri, Oct 21, 2022 at 11:17:40AM +0200, Florian Weimer wrote:
>>> So we would patch the tests?
>>
>> Depends on how large the patch is, but I'd say so.
>>
>>>  I guess we can make sure we use “int main
>>> (void)” etc. at the same time.
>>
>> Why?  Isn't int main () {} in C2X the same thing as int main (void) {} ?
>> int main () {...} is in 3500+ C tests and every day a few are added...
>
> Is this really possible?  For function pointers, it's an ABI change.
> int (*) () and int (*) (void) have different calling conventions on some
> ABIs (e.g., powerpc64le-linux-gnu).  The ABI difference goes away once
> the callees are rebuilt, and I think such rebuilt callees are compatible
> with either calling convention.

I'm probably wrong about that.  I kind find the place where the rs6000
backend would use the extra space for general-purpose spilling.

Thanks,
Florian

Re: C89isms in the test suite

[Joseph Myers]

On Fri, 21 Oct 2022, Florian Weimer via Gcc wrote:

> Is this really possible?  For function pointers, it's an ABI change.
> int (*) () and int (*) (void) have different calling conventions on some
> ABIs (e.g., powerpc64le-linux-gnu).  The ABI difference goes away once
> the callees are rebuilt, and I think such rebuilt callees are compatible
> with either calling convention.

The semantics of int (*) (void) are a refinement of those of pre-C2x 
int (*) (): any non-variadic function whose argument types are unchanged 
by the default argument promotions can be called through an int (*) () 
pointer, but only functions with no arguments can be called through an 
int (*) (void) pointer.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: C89isms in the test suite

[Florian Weimer]

* Joseph Myers:

> On Fri, 21 Oct 2022, Florian Weimer via Gcc wrote:
>
>> Is this really possible?  For function pointers, it's an ABI change.
>> int (*) () and int (*) (void) have different calling conventions on some
>> ABIs (e.g., powerpc64le-linux-gnu).  The ABI difference goes away once
>> the callees are rebuilt, and I think such rebuilt callees are compatible
>> with either calling convention.
>
> The semantics of int (*) (void) are a refinement of those of pre-C2x 
> int (*) (): any non-variadic function whose argument types are unchanged 
> by the default argument promotions can be called through an int (*) () 
> pointer, but only functions with no arguments can be called through an 
> int (*) (void) pointer.

Pre-C2x powerpc64le-linux-gnu, a call through int (*) () with no
arguments still sets up a parameter save area, while a call through int
(*) (void) does not.  With C2x, neither will set up a parameter save
area.  Hopefully, the current rs6000 backend already uses the parameter
save area just for, well, saving parameters, and not for general-purpose
spilling.  In this case, there won't be any ABI problems from the C2x
change for powerpc64le.

(Sorry that I keep bringing this up, it's confusing to me, and I once
spent quite some time tracking down a stack corruption because glibc's
open implementation assumed a parameter save area that the caller did
not provide.)

Thanks,
Florian

Re: C89isms in the test suite

[Joseph Myers]

On Fri, 21 Oct 2022, Florian Weimer via Gcc wrote:

> What's the expected default behavior for GCC 14 regarding old-style
> function definitions (function definitions which do not have a
> prototype)?  I assume if GCC 14 defaults to C2x mode, these no longer
> valid constructs would be rejected by default?  Based on some earlier

The existing situation is that it's a warning enabled by default in C2x 
mode.  You could of course argue for an error instead.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: C89isms in the test suite

[Joseph Myers]

On Fri, 21 Oct 2022, Florian Weimer via Gcc wrote:

> What should we do about these when they are not relevant to what's being
> tested?  For example, gcc/testsuite/gcc.c-torture/execute/ieee/mzero6.c
> has this:
> 
>   int main ()
>   {
>     if (__builtin_copysign (1.0, func (0.0 / -5.0, 10)) != -1.0)
>       abort ();
>     exit (0);
>   }
> 
> but no include files, so abort and exit are implicitly declared.
> 
> Should we inject a header with -include with the most common
> declarations (which includes at least abort and exit)?  Or add the
> missing #include directives?  But the latter might not work for
> freestanding targets.

If it's clear the test is testing something other than those implicit 
function declarations, either declaring the functions or using 
__builtin_exit and __builtin_abort seems reasonable.

> Implicit ints and function declarations without prototypes are also
> common (not just for main).
> 
> Other tests look like they might be intended to be built in C89 mode,
> e.g.  gcc/testsuite/gcc.c-torture/compile/386.c, although it's not
> immediately obvious to me what they test.

For tests that might be deliberately testing implicit function 
declarations or unprototyped functions, it's probably better to use 
explicit options that avoid errors (note that the c-torture tests already 
use -w to disable all warnings).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: C89isms in the test suite

[Florian Weimer]

* Joseph Myers:

>> Other tests look like they might be intended to be built in C89 mode,
>> e.g.  gcc/testsuite/gcc.c-torture/compile/386.c, although it's not
>> immediately obvious to me what they test.
>
> For tests that might be deliberately testing implicit function 
> declarations or unprototyped functions, it's probably better to use 
> explicit options that avoid errors (note that the c-torture tests already 
> use -w to disable all warnings).

That may incur future maintenance overhead because if it's possible to
re-enable implicit declarations in later language modes, we might run
into conflicts with future standardization.

>> What's the expected default behavior for GCC 14 regarding old-style
>> function definitions (function definitions which do not have a
>> prototype)?  I assume if GCC 14 defaults to C2x mode, these no longer
>> valid constructs would be rejected by default?  Based on some earlier
>
> The existing situation is that it's a warning enabled by default in C2x 
> mode.  You could of course argue for an error instead.

I plan to make the case for a change to an error in GCC 14, but would
argue against doing this in GCC 13 already.  I just got my tester going
today (I think) and found non-trivial problem in a generic Python
distutils check, and what appears to be a systemic issue in the SWIG
binding generator.  We may have to iterate through one or more (non-GCC)
upstream releases to roll out fixes.

Thanks,
Florian

Re: C89isms in the test suite

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]



> On 21 Oct 2022, at 09:40, Florian Weimer via Gcc <gcc@gcc.gnu.org> wrote:
> 
> What should we do about these when they are not relevant to what's being
> tested?  For example, gcc/testsuite/gcc.c-torture/execute/ieee/mzero6.c
> has this:
> 
>  int main ()
>  {
>    if (__builtin_copysign (1.0, func (0.0 / -5.0, 10)) != -1.0)
>      abort ();
>    exit (0);
>  }
> 
> but no include files, so abort and exit are implicitly declared.
> 
> Should we inject a header with -include with the most common
> declarations (which includes at least abort and exit)?  Or add the
> missing #include directives?  But the latter might not work for
> freestanding targets.
> 
> Implicit ints and function declarations without prototypes are also
> common (not just for main).
> 
> Other tests look like they might be intended to be built in C89 mode,
> e.g.  gcc/testsuite/gcc.c-torture/compile/386.c, although it's not
> immediately obvious to me what they test.

Would you be able to backport 6be2672e4ee41c566a9e072088cccca263bab5f7
and 885b6660c17fb91980b5682514ef54668e544b02 to the active <13
branches?

Thanks,
sam

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

Re: C89isms in the test suite

[Florian Weimer]

* Sam James:

> Would you be able to backport 6be2672e4ee41c566a9e072088cccca263bab5f7
> and 885b6660c17fb91980b5682514ef54668e544b02 to the active <13
> branches?

Jakub, okay to backport these two (to 12, 11, 10 I presume)?

commit 6be2672e4ee41c566a9e072088cccca263bab5f7
Author: Florian Weimer <fweimer@redhat.com>
Date:   Tue Oct 18 16:58:48 2022 +0200

    libsanitizer: Avoid implicit function declaration in configure test
    
    libsanitizer/
    
            * configure.ac (sanitizer_supported): Include <unistd.h> for
            syscall prototype.
            * configure: Regenerate.

commit 885b6660c17fb91980b5682514ef54668e544b02
Author: Florian Weimer <fweimer@redhat.com>
Date:   Tue Oct 18 16:58:48 2022 +0200

    libiberty: Fix C89-isms in configure tests
    
    libiberty/
    
            * acinclude.m4 (ac_cv_func_strncmp_works): Add missing
            int return type and parameter list to the definition of main.
            Include <stdlib.h> and <string.h> for prototypes.
            (ac_cv_c_stack_direction): Add missing
            int return type and parameter list to the definitions of
            main, find_stack_direction.  Include <stdlib.h> for exit
            prototype.
            * configure: Regenerate.

Thanks,
Florian

Re: C89isms in the test suite

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 455 bytes --]



> On 14 Nov 2022, at 08:19, Florian Weimer <fweimer@redhat.com> wrote:
> 
> * Sam James:
> 
>> Would you be able to backport 6be2672e4ee41c566a9e072088cccca263bab5f7
>> and 885b6660c17fb91980b5682514ef54668e544b02 to the active <13
>> branches?
> 
> Jakub, okay to backport these two (to 12, 11, 10 I presume)?

(Yes please. It's also given me something to poke at as I didn't log
the failure and only noticed when libasan wasn't installed...)

Thanks.

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

Re: C89isms in the test suite

[Jakub Jelinek]

On Mon, Nov 14, 2022 at 09:19:26AM +0100, Florian Weimer wrote:
> * Sam James:
> 
> > Would you be able to backport 6be2672e4ee41c566a9e072088cccca263bab5f7
> > and 885b6660c17fb91980b5682514ef54668e544b02 to the active <13
> > branches?
> 
> Jakub, okay to backport these two (to 12, 11, 10 I presume)?

Ok.

> commit 6be2672e4ee41c566a9e072088cccca263bab5f7
> Author: Florian Weimer <fweimer@redhat.com>
> Date:   Tue Oct 18 16:58:48 2022 +0200
> 
>     libsanitizer: Avoid implicit function declaration in configure test
>     
>     libsanitizer/
>     
>             * configure.ac (sanitizer_supported): Include <unistd.h> for
>             syscall prototype.
>             * configure: Regenerate.
> 
> commit 885b6660c17fb91980b5682514ef54668e544b02
> Author: Florian Weimer <fweimer@redhat.com>
> Date:   Tue Oct 18 16:58:48 2022 +0200
> 
>     libiberty: Fix C89-isms in configure tests
>     
>     libiberty/
>     
>             * acinclude.m4 (ac_cv_func_strncmp_works): Add missing
>             int return type and parameter list to the definition of main.
>             Include <stdlib.h> and <string.h> for prototypes.
>             (ac_cv_c_stack_direction): Add missing
>             int return type and parameter list to the definitions of
>             main, find_stack_direction.  Include <stdlib.h> for exit
>             prototype.
>             * configure: Regenerate.

	Jakub