Re: java/6820: miscompilation of (a,++a) as arguments to final method

Re: java/6820: miscompilation of (a,++a) as arguments to final method

[tromey]

Synopsis: miscompilation of (a,++a) as arguments to final method

Responsible-Changed-From-To: unassigned->tromey
Responsible-Changed-By: tromey
Responsible-Changed-When: Mon Jul  1 19:57:39 2002
Responsible-Changed-Why:
    I'm handling the administrivia
State-Changed-From-To: open->closed
State-Changed-By: tromey
State-Changed-When: Mon Jul  1 19:57:39 2002
State-Changed-Why:
    Bryce checked in a fix for this a while ago,
    so I'm closing the PR.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6820

Re: java/6820: miscompilation of (a,++a) as arguments to final method

[Bryce McKinlay]

The following reply was made to PR java/6820; it has been noted by GNATS.

From: Bryce McKinlay <bryce@waitaki.otago.ac.nz>
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: java/6820: miscompilation of (a,++a) as arguments to final method
Date: Mon, 27 May 2002 17:53:33 +1200

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6820
 
 I checked in a similar test case to the testsuite:
 
 public class PR6820
 {
   static void m(int a, int b) {
     System.out.println("a="+a+" b="+b);
   }
 
   static int a = 10;
 
   public static void main(String[] args) {
     int b = 10;
     m(a,++a);
     m(b,++b);
   }
 }
 
 This appears to be a problem with the (deprecated) RTL inliner which is 
 still used by gcj. When a call is inlined, the Java evalutation order 
 for the arguments (set by force_evaluation_order() in java/expr.c) seems 
 to get lost.
 
 Workaround is to compile with -O2 -fno-inline
 
 Solution may be to switch gcj to use the AST inliner.
 
 

java/6820: miscompilation of (a,++a) as arguments to final method

[Oskar Liljeblad]

>Number:         6820
>Category:       java
>Synopsis:       miscompilation of (a,++a) as arguments to final method
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun May 26 10:16:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Oskar Liljeblad <oskar@osk.mine.nu>
>Release:        3.1
>Organization:
>Environment:
Linux/x86
>Description:
(Let's hope this is not a dupe...)

See the code below. With Demo compiled with gcj from source to x86 machine code, the output is "a=11 b=11". The output is correctly "a=10 b=11" when:

 * compiling and running with Sun JDK 1.4 javac.

 * compiling from source to .class and interpreting
   with gij.

 * compiling from source to .class, and .class to
   machine code with gcj.

Note that this bug only happens when calling methods that are final (or in final classes).

Oskar Liljeblad (oskar@osk.mine.nu)
>How-To-Repeat:
class Demo {
	public static void main(String[] args) {
		Dummy d = new Dummy();
		int a = 10;
		d.m(a,++a);
	}
}

final class Dummy {
	public void m(int a, int b) {
		System.out.println("a="+a+" b="+b);
	}
}
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: