> > 2) Why doesn't the GIMPLE pass match on the GIMPLE code produced by
> the Fortran version?
> > I have created an example where the GIMPLE trees of the two match
> exactly % some attributes
> > on the expressions.
>
> Fortran (and other frontends besides C-family) do not get their builtins from
> builtins.def but need to provide their own version. See
> fortran/mathbuiltins.def.
>
Ah! Thanks you! I had not realized this at all. It works perfectly in GIMPLE
now.
> >
> > The rule seems to be matching early in the GIMPLE phase and not the
> generic, fair enough as long as it works.
>
> Btw, why are you interested in GENERIC matching at all here?
>
It was the road I ended up down when I was trying to debug the matches. I
couldn't
Quite understand from the code why the GIMPLE one was rejecting the
substitution but
The GENERIC one was simple enough to do. So I went with that.
> {
> tree fndecl = builtin_decl_implicit (as_builtin_fn (fn));
> if (!fndecl)
> return NULL_TREE;
> return build_call_expr_loc_array (loc, fndecl, n, argarray);
>
> but subject to the same implicit rule as GIMPLE (but handled more
> conservatively as I outlined above).
Ah, my confusion comes from not really knowing the difference between
builtin_decl_implicit (as_builtin_fn (fn));
and
internal_fn_p (fn)
well enough.
>
> Yes, the FEs likely do not expect internal FNs around in the IL at random
> places.
>
> So first of all I suggest to not try matching on GENERIC (or at least not
> spend
> too much energy in making it work there).
>
Yes I'll drop the GENERIC one. I had thought I needed it for Fortran but that
isn't the case.
Thanks for the help!
Regards,
Tamar
