Kazu Hirata <[EMAIL PROTECTED]> 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
