Tom Tromey wrote:

>>>>>>"Per" == Per Bothner <per@bothner.com> writes:
>>>>>>
>[ revisiting old email ]
>
>Per> So patch_binop when generating bytecodes, to be safe, only calls
>Per> fold when both operands are constant. One fix to to do our own
>Per> folding for '||' and '&&'.  I'll look into that.
>
>I think we need our own fold() anyway.  The fold in gcc doesn't
>implement Java semantics precisely.  As I recall there are lots of
>Jacks test failures resulting from our deviations here.
>
Folding a binary operator when both operand are constants is presumably
safe - or are the some traps I'm not aware of?

The hard part is all the logic in fold that re-arranges the computation
when the operands are not both constants.  That is where you can get
the non-obvous optimizations - but it is also the case where the
difference between Java and C/C++ semantics can cause mistakes.
Perhaps rather than writing our own fold it would be better to add
some flag to force fold to respect evaluation order and otherwise
not do anything that might break Java semantics.  I suspect we can
get such a change into the existing fold - but it requires someone
understanding the issues better than I do to propose a clean solution.

I did implement a patch as I suggested, but I haven't gotten around
to checking it in.  This is partly because it only handles the case where
first operand is constant.  The case when the second operand is constant
is a little trickier.   But I can certainly check in what I have.

    --Per