This is the mail archive of the
mailing list for the GCC project.
RE: Questions about match.pd
> > 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
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));
> Yes, the FEs likely do not expect internal FNs around in the IL at random
> 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!