Builtin mismatch warning

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Builtin mismatch warning

Paul Koning-6
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

Reply | Threaded
Open this post in threaded view
|

Re: Builtin mismatch warning

Martin Sebor-2
On 10/31/2018 12:15 PM, Paul Koning wrote:
> 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.

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.

> 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
Reply | Threaded
Open this post in threaded view
|

Re: Builtin mismatch warning

Paul Koning-6


> On Oct 31, 2018, at 4:21 PM, Martin Sebor <[hidden email]> wrote:
>
> On 10/31/2018 12:15 PM, Paul Koning wrote:
>> 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.
>
> 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.
>
>> 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

Reply | Threaded
Open this post in threaded view
|

Re: Builtin mismatch warning

Martin Sebor-2
On 10/31/2018 03:10 PM, Paul Koning wrote:

>
>
>> On Oct 31, 2018, at 4:21 PM, Martin Sebor <[hidden email]> wrote:
>>
>> On 10/31/2018 12:15 PM, Paul Koning wrote:
>>> 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.
>>
>> 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.
>>
>>> 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