Builtin mismatch warning

[Paul Koning]

I noticed a curious inconsistency.

Some testcases (like gcc.dg/Wrestrict-4.c) have declarations like this:

void *alloca();
void* memcpy ();

Those don't generate warnings in a just built V9.0 gcc for x86. And the testcase clearly doesn't expect warnings.

But I do get a warning (warning: conflicting types for built-in function ‘memcpy’) when I compile that same code on GCC built for pdp11. I don't know why changing the target should affect whether that message appears.

paul

[Martin Sebor]

Post by Paul Koning
I noticed a curious inconsistency.
void *alloca();
void* memcpy ();
Those don't generate warnings in a just built V9.0 gcc for x86. And the testcase clearly doesn't expect warnings.

Wrestrict-4.c is about verifying there is no ICE. It doesn't check
for warnings (or expect them) only because GCC doesn't issue them,
even though it should. I submitted a patch to enable warnings for
built-in declarations without a prototype back in June but it wasn't
been approved:

https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01645.html

I'm still hoping to resuscitate it before the end of stage 1.

Post by Paul Koning
But I do get a warning (warning: conflicting types for built-in function ‘memcpy’) when I compile that same code on GCC built for pdp11. I don't know why changing the target should affect whether that message appears.

Apparently because the warning depends on whether arguments to
such functions are affected by default promotions (determined
by self_promoting_args_p()) and on pdp11 that isn't the case
for size_t. So on pdp11, the type of void* memcpy() isn't
considered compatible with the type of the built-in function.

IMO, the warning should be issued regardless of compatibility.
Function declarations without a prototype have been deprecated
since C99, and are being considered for removal from C2X. There
is no reason for maintained software not to adopt the much safer
declaration style in general, and certainly not for built-in
functions. Even if safety weren't reason enough, declaring
built-ins with correct prototypes improves the quality of
generated code: GCC will expand a call like memcpy(d, s, 32)
inline when the the function is declared with a prototype but
it declines to do so when it isn't declared with one, because
the type of 32 doesn't match size_t.

Martin

[Paul Koning]

Post by Martin Sebor

Post by Paul Koning
I noticed a curious inconsistency.
void *alloca();
void* memcpy ();
Those don't generate warnings in a just built V9.0 gcc for x86. And the testcase clearly doesn't expect warnings.

Wrestrict-4.c is about verifying there is no ICE. It doesn't check
for warnings (or expect them) only because GCC doesn't issue them,
even though it should. I submitted a patch to enable warnings for
built-in declarations without a prototype back in June but it wasn't
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01645.html
I'm still hoping to resuscitate it before the end of stage 1.

Post by Paul Koning
But I do get a warning (warning: conflicting types for built-in function ‘memcpy’) when I compile that same code on GCC built for pdp11. I don't know why changing the target should affect whether that message appears.

Apparently because the warning depends on whether arguments to
such functions are affected by default promotions (determined
by self_promoting_args_p()) and on pdp11 that isn't the case
for size_t. So on pdp11, the type of void* memcpy() isn't
considered compatible with the type of the built-in function.
IMO, the warning should be issued regardless of compatibility.
Function declarations without a prototype have been deprecated
since C99, and are being considered for removal from C2X. There
is no reason for maintained software not to adopt the much safer
declaration style in general, and certainly not for built-in
functions. Even if safety weren't reason enough, declaring
built-ins with correct prototypes improves the quality of
generated code: GCC will expand a call like memcpy(d, s, 32)
inline when the the function is declared with a prototype but
it declines to do so when it isn't declared with one, because
the type of 32 doesn't match size_t.
Martin

Thanks. So I'm wondering if I should add
{ dg-warning "conflicting types" "" { "pdp11*-*-*" } }
for now, and then if your patch goes in that simply changes to apply to all targets.

paul

[Martin Sebor]

Post by Paul Koning

Post by Martin Sebor

Post by Paul Koning
I noticed a curious inconsistency.
void *alloca();
void* memcpy ();
Those don't generate warnings in a just built V9.0 gcc for x86. And the testcase clearly doesn't expect warnings.

Wrestrict-4.c is about verifying there is no ICE. It doesn't check
for warnings (or expect them) only because GCC doesn't issue them,
even though it should. I submitted a patch to enable warnings for
built-in declarations without a prototype back in June but it wasn't
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01645.html
I'm still hoping to resuscitate it before the end of stage 1.

Post by Paul Koning
But I do get a warning (warning: conflicting types for built-in function ‘memcpy’) when I compile that same code on GCC built for pdp11. I don't know why changing the target should affect whether that message appears.

Apparently because the warning depends on whether arguments to
such functions are affected by default promotions (determined
by self_promoting_args_p()) and on pdp11 that isn't the case
for size_t. So on pdp11, the type of void* memcpy() isn't
considered compatible with the type of the built-in function.
IMO, the warning should be issued regardless of compatibility.
Function declarations without a prototype have been deprecated
since C99, and are being considered for removal from C2X. There
is no reason for maintained software not to adopt the much safer
declaration style in general, and certainly not for built-in
functions. Even if safety weren't reason enough, declaring
built-ins with correct prototypes improves the quality of
generated code: GCC will expand a call like memcpy(d, s, 32)
inline when the the function is declared with a prototype but
it declines to do so when it isn't declared with one, because
the type of 32 doesn't match size_t.
Martin

Thanks. So I'm wondering if I should add
{ dg-warning "conflicting types" "" { "pdp11*-*-*" } }
for now, and then if your patch goes in that simply changes to apply to all targets.

I would suggest to filter out the warning instead via dg-prune-
output. The warning isn't important to what the test exercises
and with it filtered out the test can stay the same regardless
of any changes in this area.

Martin