Re: generate_bytecode_insn - tree code not implemented: min_expr

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Roger" == Roger Sayle <roger@eyesopen.com> writes:

Roger> I don't believe that its necessarily "fold" at fault.  The
Roger> middle-end considers MIN_EXPR and MAX_EXPR nodes the be the
Roger> canonical form of certain forms of COND_EXPR.

gcj works strangely here.  We build somewhat different trees when
generating bytecode, and the bytecode writer only recognizes a certain
subset of tree expressions.  The problem isn't so much changing gcj to
recognize something new, but rather that any change can potentially
cause problems.

I think we shouldn't be using fold() here, anyway.  fold() doesn't
respect the Java rules for constant folding (as far as I know), and we
still have a lot of bugs in this area...  Unfortunately, changing this
is pretty substantial, and nobody has volunteered.

In the meantime, it wouldn't be hard for someone to change jcf-write
to handle MIN_EXPR and MAX_EXPR.

Roger> For example, I'm not sure if you've noticed but java/builtins.c creates
Roger> MIN_EXPR and MAX_EXPR tree nodes to "inline" java.lang.Math.min and
Roger> java.lang.Math.max respectively.

This code should never be run when generating bytecode.

Tom