[PATCH] Diagnose implicitly prototyped builtins called with wrong arguments (PR middle-end/38360, take 2)
Joseph S. Myers
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
More information about the Gcc-patches