This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: [PATCH] java.util.StringTokenizer assumes order of parameterevaluation
- From: Anthony Green <green at redhat dot com>
- To: Ranjit Mathew <rmathew at hotmail dot com>
- Cc: java-patches at gcc dot gnu dot org
- Date: 16 Oct 2002 07:39:38 -0700
- Subject: Re: [PATCH] java.util.StringTokenizer assumes order of parameterevaluation
- References: <aoj2fe$em6$1@main.gmane.org> <aoj5et$oge$1@main.gmane.org>
On Wed, 2002-10-16 at 00:46, Ranjit Mathew wrote:
> BTW, does GCJ guarantee this order at all times? (I just saw
> Andrew Haley's patch for a fix for *static* method invocation,
> but the StringTokenizer problem is in a member method.)
This problem also exists on x86 Linux. I thought I had reproduced the
StringTokenizer problem in a small test case...
http://gcc.gnu.org/ml/gcc-bugs/2002-10/msg00556.html
This is the case that Andrew just fixed. It now seems that I stumbled
across a different argument order problem -- not the one in
StringTokenizer.
With the PreIncr.java test program you just posted on
java@gcc.gnu.org....
$ gcj -o PreIncr --main=PreIncr PreIncr.java -mcpu=i386
$ ./PreIncr
a = 1
b = 1
$ gcj -o PreIncr --main=PreIncr PreIncr.java -mcpu=i686
$ ./PreIncr
a = 0
b = 1
AG