[PATCH] Diagnose implicitly prototyped builtins called with wrong arguments (PR middle-end/38360, take 2)

[Richard Guenther]

On Tue, Dec 2, 2008 at 11:13 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Tue, 2 Dec 2008, Jakub Jelinek wrote:
>
>> --- gcc/testsuite/gcc.dg/redecl-4.c.jj        2008-12-02 17:35:44.000000000 +0100
>> +++ gcc/testsuite/gcc.dg/redecl-4.c   2008-12-02 17:44:33.000000000 +0100
>> @@ -20,9 +20,11 @@ f (void)
>>        strcmp (1);
>>      /* Likewise, implicitly declared memcmp.  */
>>      if (0)
>> -      memcmp (1);
>> +      memcmp (1); /* { dg-error "too few arguments" } */
>
> The fact that this testcase is changing rather indicates that the proposed
> change is wrong and this call should not be rejected.
>
> The requirement that allows rejecting some bad uses of built-in functions
> is that all declarations referring to memcmp - both in the library and
> directly in the program - specify compatible types.  An implicit
> declaration is one without a prototype, which is compatible with that in
> the library even if it has the wrong arguments (provided the library one
> returns int, isn't variadic, etc.).  It can't be optimized as a built-in
> call and is undefined behavior if executed (so could be changed into
> evaluating the function designator and arguments then aborting), but it's
> valid C90 code if not executed.  And the case for strcmp (where a
> non-prototype declaration is given before calling the function, which your
> patch doesn't cause to be diagnosed) is also valid C99 if not executed.
>
> I suppose you could add an extra argument to convert_arguments, indicating
> that invalid arguments should cause a trap to be generated and no error to
> be generated.  That in turn would need to pass something down to
> convert_for_assignment (a new ic_* value, maybe) to tell it not to
> generate errors but to pass up an indication to generate a trap instead.
> That would avoid the front end producing GIMPLE containing bad calls to
> built-in functions.  Except that if a pointer to the built-in function is
> stored in a function pointer variable (whose type does not include a
> prototype, or using a cast) I'd imagine such calls could be generated
> after the front end has finished and something in the optimizers would
> need to deal with them.  Maybe the original patch is better after all....

Can we somehow avoid using a builtin decl for such cases?  It is really
error-prone to ask everyone looking at builtin function calls to verify that
the calls do actually match what is required.

Thanks,
Richard.