Bug 19758 - compiler allows super.fun() even if abstract
Summary: compiler allows super.fun() even if abstract
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 4.0.0
: P2 minor
Target Milestone: 4.3.0
Assignee: Not yet assigned to anyone
Keywords: accepts-invalid
Depends on: 12893 28067
  Show dependency treegraph
Reported: 2005-02-02 15:04 UTC by Kalle Olavi Niemitalo
Modified: 2007-01-09 20:47 UTC (History)
2 users (show)

See Also:
Host: i386-pc-linux-gnu
Target: i386-pc-linux-gnu
Build: i386-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2005-05-04 02:10:44


Note You need to log in before you can comment on or make changes to this bug.
Description Kalle Olavi Niemitalo 2005-02-02 15:04:13 UTC
A GCC checked out from CVS on 2005-01-29 compiles the following
code without complaint, generating an invokespecial to the
abstract method First.fun().  The linker will detect the error,
but I think it would make sense to reject such code at compile
time, like KJC and Jikes do, or at least warn about it.
KJC gives "JLS 15.12.3" as a rationale.

abstract class First {
    abstract void fun();

class Second extends First {
    void fun() {

$ /usr/lib/kaffe/bin/kjc abstract.java
abstract.java:7: error:Can not call abstract method "void First.fun()" with
prefix "super"  [JLS 15.12.3]
$ jikes-gij abstract.java

Found 1 semantic error compiling "abstract.java":

     7.         super.fun();
*** Semantic Error: An abstract method, "fun", cannot be invoked.
$ gcj -C -Wall -Wextra abstract.java
$ gcj -v abstract.java
Using built-in specs.
Reading specs from
rename spec lib to liborig
Configured with: /home/kalle/src/FOREIGN-CVS/gcc/configure --prefix=/home/kalle
--exec-prefix=/home/kalle/i386-pc-linux-gnu --host=i386-pc-linux-gnu
--build=i386-pc-linux-gnu --enable-java-awt=gtk,xlib
Thread model: posix
gcc version 4.0.0 20050129 (experimental)

/home/kalle/stow/gcc/i386-pc-linux-gnu/bin/../libexec/gcc/i386-pc-linux-gnu/4.0.0/jc1 abstract.java -fhash-synchronization -fno-use-divide-subroutine
-fuse-boehm-gc -fnon-call-exceptions -fno-omit-frame-pointer
-fkeep-inline-functions -quiet -dumpbase abstract.java -auxbase abstract -g1
-version -o /tmp/ccS8XoWC.s
GNU Java version 4.0.0 20050129 (experimental) (i386-pc-linux-gnu)
	compiled by GNU C version 4.0.0 20050129 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Class path starts here:
/home/kalle/stow/gcc/i386-pc-linux-gnu/bin/../lib/gcc/../../../share/java/libgcj-4.0.0.jar/ (system) (zip)
 as -V -Qy -o /tmp/cc6hh3qe.o /tmp/ccS8XoWC.s
GNU assembler version 2.15 (i386-linux) using BFD version 2.15

/home/kalle/stow/gcc/i386-pc-linux-gnu/bin/../libexec/gcc/i386-pc-linux-gnu/4.0.0/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2
/usr/lib/crt1.o /usr/lib/crti.o
-L/home/kalle/stow/gcc/i386-pc-linux-gnu/bin/../lib/gcc/i386-pc-linux-gnu/4.0.0/../../.. -L/home/kalle/i386-pc-linux-gnu/lib/gcc/i386-pc-linux-gnu/4.0.0/../../..
/tmp/cc6hh3qe.o -lgcc_s -lgcc -lgcj -lm -lpthread -ldl -lgcc_s -lgcc -lc -lgcc_s
/home/kalle/stow/gcc/i386-pc-linux-gnu/bin/../lib/gcc/i386-pc-linux-gnu/4.0.0/crtend.o /usr/lib/crtn.o
/usr/lib/crt1.o(.text+0x18): In function `_start':
../sysdeps/i386/elf/start.S:98: undefined reference to `main'
/tmp/cc6hh3qe.o(.text+0xe): In function `Second::fun()':
: undefined reference to `First::fun()'
/tmp/cc6hh3qe.o(.data+0xc): undefined reference to `First::fun()'
collect2: ld returned 1 exit status
Comment 1 Andrew Pinski 2005-02-02 15:13:38 UTC
Confirmed, it might turn out this is a dup of bug 12893.
Comment 2 Tom Tromey 2007-01-09 20:47:04 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.