Bug 19810 - Finally handling inconsistent when compiling to class/executable
Summary: Finally handling inconsistent when compiling to class/executable
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: 4.3.0
Assignee: Not yet assigned to anyone
Depends on: 28067
  Show dependency treegraph
Reported: 2005-02-07 19:15 UTC by Jonathan Hogg
Modified: 2007-01-09 20:47 UTC (History)
2 users (show)

See Also:
Host: i486-linux
Target: i486-linux
Build: i486-linux
Known to work:
Known to fail:
Last reconfirmed: 2005-05-22 14:07:15


Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Hogg 2005-02-07 19:15:51 UTC
From this code fragment:

class Confuse {

        public static void main (String[] bob) 
                boolean jim;

                System.out.print("Calling wtf(true):");

                System.out.print("Calling wtf(false):");

        static boolean wtf(boolean jam) {
                while (jam)
                        try {
                                return true;
                        finally {
                return false;

jdh41@chloe:~/src$ gcj -v
Using built-in specs.
Reading specs from
rename spec lib to liborig
Configured with: ../configure --enable-languages=java --disable-checking
--disable-static --enable-java-awt=gtk --with-system-zlib --prefix=/home/jdh41/gcc
Thread model: posix
gcc version 4.0.0 20050129 (experimental)
jdh41@chloe:~/src$ gcj -C Confuse.java
jdh41@chloe:~/src$ java -v Confuse
Calling wtf(true):true
Calling wtf(false):false
jdh41@chloe:~/src$ ~/j2sdk1.4.2_06/bin/java Confuse
Calling wtf(true):true
Calling wtf(false):false
jdh41@chloe:~/src$ gcj -o confuse_me Confuse.java --main=Confuse
jdh41@chloe:~/src$ ./confuse_me 
Calling wtf(true):false
Calling wtf(false):false
jdh41@chloe:~/src$ ~/j2sdk1.4.2_06/bin/javac Confuse.java 
jdh41@chloe:~/src$ ~/j2sdk1.4.2_06/bin/java Confuse
Calling wtf(true):false
Calling wtf(false):false

As you can see the compile to class files seems to be wrong, and further the
compiler and not the VM.
Comment 1 Tom Tromey 2005-02-07 19:21:05 UTC
This also affects 3.3.

The code for the wtf() method forgets to call the finally handler:

  0: iload_0
  1: ifeq 7
  4: iconst_1
  5: ireturn
  6: pop
  7: iconst_0
  8: ireturn
Comment 2 Tom Tromey 2005-02-19 00:19:41 UTC
I investigated this some more.

The code generator for "return" looks at the finally
stack to decide whether to call any finally handlers.

But, the code generator for "try" has a special case
when the finally clause cannot complete normally.
This confuses the "return" handler.

One fix would be to turn off this optimization.
Comment 3 Tom Tromey 2007-01-09 20:47:05 UTC
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.