This is the mail archive of the
mailing list for the GCC project.
Re: generate_bytecode_insn - tree code not implemented: min_expr
- From: Tom Tromey <tromey at redhat dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: Andrew Haley <aph at redhat dot com>, Erik Poupaert <erik at poupaert dot hurricanedev dot com>, <gcc at gcc dot gnu dot org>, <java at gcc dot gnu dot org>
- Date: 13 Sep 2003 10:46:54 -0600
- Subject: Re: generate_bytecode_insn - tree code not implemented: min_expr
- References: <Pine.LNX.email@example.com>
- Reply-to: tromey at redhat dot com
>>>>> "Roger" == Roger Sayle <firstname.lastname@example.org> 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
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.