On Fri, 3 Jan 2014, Jakub Jelinek wrote:
> On Fri, Jan 03, 2014 at 11:01:13AM +0100, Richard Biener wrote:
> > > Well, see PR59630. The question is if having to handle it everywhere
> > > is worth it.
> >
> > Well, this case happens because we go back to GENERIC which doesn't
> > have this feature. So "everywhere" is somewhat a broad stmt.
> > It's easy to guard the builtins.c folding with a compatibility
> > check of fntype and fndecl type.
>
> Well, clearly the inliner has similar issue, I doubt e.g. IPA cloning
> handles it right, there is just one gimple_call_fntype call in all of ipa*.c
> (which surprises me) and that ignores it if there is a decl:
> tree type = (e->callee
> ? TREE_TYPE (e->callee->decl)
> : gimple_call_fntype (e->call_stmt));
> so if there is a mismatch between TREE_TYPE (e->callee->decl) and
> gimple_call_fntype, it will happily look at the decl type.
> So I'd say it is just a matter of adding more (invalid) testcases.
Of course we have to fix al the bugs. The inliner has a
compatibility check in some of it's can-inline predicates.
ipa_get_callee_param_type looks correct if it really wants
to get at the param type of the _callee_ (not the type
the caller uses!)
static tree
ipa_get_callee_param_type (struct cgraph_edge *e, int i)
{
int n;
tree type = (e->callee
? TREE_TYPE (e->callee->decl)
: gimple_call_fntype (e->call_stmt));
tree t = TYPE_ARG_TYPES (type);
so if there is a decl then use its type signature, otherwise
(indirect calls) use the caller signature (and hope it matches
the callee...). That it later falls back to looking at
DECL_ARGUMENTS is odd (probably a FE issue where we have a
fndecl with a bogus type?)
Richard.
