(This is superficially similar to bug 16439, in that it involves "synthetic code" being tagged with insufficiently precise line numbers.) Compiling the attached .class file with gcj -findirect-dispatch -shared -S -O0 -g WebappClassLoader.class results in the following (i386) assembly code for line 1578: .loc 1 1578 0 movl _CD_org_apache_catalina_loader_WebappClassLoader+200, %eax subl $12, %esp .LCFI2993: pushl %eax .LCFI2994: call _Jv_AllocObjectNoFinalizer addl $16, %esp .LCFI2995: movl %eax, -368(%ebp) movl -368(%ebp), %eax movl %eax, -364(%ebp) movl -364(%ebp), %eax movl %eax, -368(%ebp) movl 12(%ebp), %eax movl %eax, -272(%ebp) .loc 1 1651 0 movl -364(%ebp), %ecx movl _atable_org_apache_catalina_loader_WebappClassLoader+92, %eax movl %eax, %edx movl -272(%ebp), %eax subl $8, %esp .LCFI2996: pushl %eax .LCFI2997: pushl %ecx .LCFI2998: call *%edx addl $16, %esp .LCFI2999: .loc 1 1578 0 movl -368(%ebp), %eax subl $12, %esp .LCFI3000: pushl %eax .LCFI3001: call _Jv_Throw Note that while the start and end of this code block is correctly marked as being from line 1578, the middle (the indirect dispatch) is incorrectly marked as being from line 1651 (which happens to be the line number of the last statement in the method.) This causes line numbers in some stack traces to be incorrect. Original source file attached below. # gcj -v Using built-in specs. Reading specs from /usr/lib/gcc/i386-redhat-linux/4.0.0/libgcj.spec rename spec lib to liborig Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk --host=i386-redhat-linux Thread model: posix gcc version 4.0.0 20050405 (Red Hat 4.0.0-0.40)
Created attachment 8623 [details] test case
Created attachment 8624 [details] .java source corresponding to the test case
Is this still an issue?
Closing as won't fix as the Java front-end has been removed from the trunk.