Re: Builtin mismatch warning

[Paul Koning <paulkoning at comcast dot net>]

> On Oct 31, 2018, at 4:21 PM, Martin Sebor <msebor@gmail.com> 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