Re: [PATCH] java.util.StringTokenizer assumes order of parameterevaluation

[Andrew Haley <aph at redhat dot com>]

Mark Wielaard writes:

 > I saw that you applied this patch so I tried a new gcj checkout on the
 > attached testcase from Casey Marshall that he found when trying to
 > analyse why compiling GNU Crypto with gcj -O2 produced incorrect
 > results.
 > 
 > GNU Crypto already contains a workaround for this issue but the attached
 > program does not produce correct results (with or without! -O2).
 > 
 > It seems that the arguments to the methods get mixed up in the following
 > statement:
 > 
 > result[j++] = (byte)(
 >     (fromDigit(s.charAt(i++)) << 4) | fromDigit(s.charAt(i++)));
 > 
 > Compiling with gcj -C produces bytecode that runs correctly with gij.
 > 
 > Correct output should be:
 > 
 > 0123456789ABCDEF
 > 0123456789ABCDEF
 > 0123456789ABCDEF
 > 
 > But is:
 > 
 > 0123456789ABCDEF
 > 0123456789ABCDEF
 > 1032547698BADCFE

I get this also, but only at -O2.

I'm pretty sure that it has nothing to do with the problem my patch
fixed.

The difference seems to be in the initial RTL generation.  I'll have a
look.

Andrew.