[Bug java/19810] New: Finally handling inconsistent when compiling to class/executable

[Bug java/19810] New: Finally handling inconsistent when compiling to class/executable

[jdh41@cantab.net]

>From this code fragment:

class Confuse {

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

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

                jim=wtf(false);
                System.out.print("Calling wtf(false):");
                System.out.println(jim);
        }

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

Session:
jdh41@chloe:~/src$ gcj -v
Using built-in specs.
Reading specs from
/home/jdh41/gcc/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../libgcj.spec
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.

-- 
           Summary: Finally handling inconsistent when compiling to
                    class/executable
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: java
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jdh41 at cantab dot net
                CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
                    dot org
 GCC build triplet: i486-linux
  GCC host triplet: i486-linux
GCC target triplet: i486-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19810

[Bug java/19810] Finally handling inconsistent when compiling to class/executable

[tromey@gcc.gnu.org]

------- Additional Comments From tromey at gcc dot gnu dot org  2005-02-07 19:21 -------
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


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-02-07 19:21:05
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19810

[Bug java/19810] Finally handling inconsistent when compiling to class/executable

[tromey at gcc dot gnu dot org]

------- Additional Comments From tromey at gcc dot gnu dot org  2005-02-19 00:19 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19810

[Bug java/19810] Finally handling inconsistent when compiling to class/executable

[tromey at gcc dot gnu dot org]

------- Comment #3 from tromey at gcc dot gnu dot org  2007-01-09 20:47 -------
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.
Thanks.


-- 

tromey at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19810