A headache with fold_ternary and CALL_EXPR.

[Zack Weinberg]

Kazu Hirata <kazu@cs.umass.edu> writes:

> It turns out that the CALL_EXPR case of fold_ternary needs the
> original tree like so.  (Notice a reference to t.)
...
> If we want to change fold_builtin to take operands like op0, op1, and
> op2, I would have to change so many things that depend on
> fold_builtin.  (Note that the subroutines of fold_builtin also depends
> on fold_builtin in a sense that they need the original tree, one whose
> TREE_CODE is CALL_EXPR is available.)

In my half-considered opinion, the fact that CALL_EXPR counts as a
ternary operator is an accident; function calls probably ought to get
their own fold_call() primitive or something like that.  Perhaps this
is what fold_builtin already is.  Of course it would be nice not to
have to construct the CALL_EXPR if it's just going to be folded out...

zw