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

Joseph S. Myers joseph@codesourcery.com
Tue Dec 2 22:38:00 GMT 2008


On Tue, 2 Dec 2008, Richard Guenther wrote:

> > 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.

You can check things as I described and generate a trap, but then you 
still need to deal with cases where the fact that a built-in function is 
being called with wrong arguments isn't visible to the front end but is to 
the optimizers.  Maybe something else already handles that; the front end 
generates a trap for calls it can tell are through a function cast to a 
different type, but such calls could also arise in the optimizers.

-- 
Joseph S. Myers
joseph@codesourcery.com



More information about the Gcc-patches mailing list