RE: libjava failed to build on Linux/x86

RE: libjava failed to build on Linux/x86

[Boehm, Hans]

This happened once before.  IIRC, the conclusion then was that it might be
better to change "=m" to "+m" and to remove the "0"(*(addr)) argument.  But
as it stands, this very closely follows one of the examples in the gcc
manual, so it seems to primarily be a gcc bug.

Hans

> -----Original Message-----
> From: Per Bothner [mailto:per@bothner.com]
> In 
> function `bool
>     compare_and_swap(volatile obj_addr_t*, unsigned int, 
> unsigned int)':
> /home/bothner/GNU/gcc/libjava/java/lang/natObject.cc:329: 
> inconsistent 
> operand
>     constraints in an `asm'
> make[3]: *** [java/lang/natObject.lo] Error 1
> 
> The asm is:
> 
>    inline static bool
>    compare_and_swap(volatile obj_addr_t *addr,
> 		 
> 				obj_addr_t old,
> 						obj_addr_t new_val)
>    {
>      char result;
>      __asm__ __volatile__("lock; cmpxchgl %2, %0; setz %1"
> 	    	: "=m"(*(addr)), "=q"(result)
> 		: "r" (new_val), "0"(*(addr)), "a"(old) : "memory");
>      return (bool) result;
>    }
> 
> 
> -- 
> 	--Per Bothner
> per@bothner.com   http://www.bothner.com/per/
> 

Re: libjava failed to build on Linux/x86

[Richard Henderson]

On Thu, Jan 24, 2002 at 03:42:32PM -0800, Boehm, Hans wrote:
> This happened once before.  IIRC, the conclusion then was that it might be
> better to change "=m" to "+m" and to remove the "0"(*(addr)) argument.

The two are functionally identical, as "+" is expanded to "="/"0".
With memories, matching constraints are rarely needed or useful.


r~

Re: libjava failed to build on Linux/x86

[Tom Tromey]

>>>>> "Bryce" == Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:

>> This is really outside my area of expertise.  All I know is that this
>> was working fine with the Jan 4 compiler.

Bryce> Are you sure? The bug seems to occur for me going back as far
Bryce> as early December.

That's strange.  Over the last day or so I've updated and built from
scratch 4 different versions of gcc -- latest, Jan 4, Jan 20, and then
Jan 22.  All of them seemed to work for me on this build.  I don't
understand why they would work for me and fail for you :-(

Tom

Re: libjava failed to build on Linux/x86

[Bryce McKinlay]

Bryce McKinlay wrote:

> The bug seems to occur for me going back as far as early December. In 
> fact after some binary searching I currently suspect it was introduced 
> with this patch:
>
> Mon Dec  3 16:16:37 CET 2001  Jan Hubicka  <jh@suse.cz> 


Sorry, I lied. It was actually this one:

2001-12-03  Per Bothner  <per@bothner.com>

        * decl.c (complete_start_java_method):  Now generate 
TRY_FINALLY_EXPR
        instead of CLEANUP_POINT_EXPR and WITH_CLEANUP_EXPR.
        * jcf-write.c (generate_bytecode_insns):  Remove support for
        CLEANUP_POINT_EXPR and WITH_CLEANUP_EXPR as they are no longer used.
        * check-init.c (check_init):  Likewise.

There doesn't seem to be anything wrong with Per's patch, however - so I 
guess this is a general bug with TRY_FINALLY_EXPR that we just havn't 
noticed until now.

Here is an alternate test case which reproduces the problem without a 
"synchronized" keyword:

class Bug2
{
  boolean x = false;

  private void b() {}

  void a()
  {
    try
    {
      if (x == true);
    }
    finally
    {
       b();
    }
  }
}

regards

Bryce.

Re: libjava failed to build on Linux/x86

[Bryce McKinlay]

Tom Tromey wrote:

>>>>>>"Tom" == Tom Tromey <tromey@redhat.com> writes:
>>>>>>
>
>Tom> I suspect a non-gcj compiler bug.  I built code with a compiler which
>Tom> was current as of last week sometime.  I imagine some bug was
>Tom> introduced or revealed between then and now.  I've updated and I'm
>Tom> rebuilding to see if I can reproduce the problem here.
>
>I reproduced the crash here.
>I've appended a stack trace.
>The proximate problem is that `e->dest' is 0.
>
>This is really outside my area of expertise.  All I know is that this
>was working fine with the Jan 4 compiler.
>
Are you sure? The bug seems to occur for me going back as far as early 
December. In fact after some binary searching I currently suspect it was 
introduced with this patch:

Mon Dec  3 16:16:37 CET 2001  Jan Hubicka  <jh@suse.cz>

    * gcse.c (delete_null_pointer_checks_1): Do not use delete_list;
    call purge_dead_edges after removing.
    (delete_null_pointer_checks): Do not handle delete_list.

    * cfgbuild.c (inside_basic_block_p, control_flow_insn_p): Break out 
from ...
    (count_basic_blocks): ... here.
    (find_basic_blocks, find_bb_boundaries): Cleanup.

    * stor-layout.c (fixup_signed_type, fixup_unsigned_type): Avoid
    overflow for types greater then 2 * HOST_WIDE_INT.

    * reload.c (find_reloads): Update the duplicates after swapingg.

The bug occurs at -O on x86, and does not occur if -fPIC is used.

Java test case:

class Bug
{
  boolean x = false;

  synchronized void a()
  {
    if (x == true);
  }
}

Stack trace:

Program received signal SIGSEGV, Segmentation fault.
0x08235ad7 in find_unreachable_blocks () at ../../gcc/cfganal.c:363
363             if (!(e->dest->flags & BB_REACHABLE))
(gdb) bt
#0  0x08235ad7 in find_unreachable_blocks () at ../../gcc/cfganal.c:363
#1  0x0823a96c in delete_unreachable_blocks () at 
../../gcc/cfgcleanup.c:1715
#2  0x0823a9f3 in cleanup_cfg (mode=3) at ../../gcc/cfgcleanup.c:1743
#3  0x08200fa6 in rest_of_compilation (decl=0x401a73a0)
    at ../../gcc/toplev.c:3270
#4  0x0805f702 in source_end_java_method () at ../../gcc/java/parse.y:7476
#5  0x0806109e in java_expand_method_bodies (class=0x0)
    at ../../gcc/java/parse.y:8152
#6  0x0806389e in java_expand_classes () at ../../gcc/java/parse.y:9043
#7  0x0809edd1 in yyparse () at ../../gcc/java/jcf-parse.c:1207
#8  0x081ff732 in compile_file () at ../../gcc/toplev.c:2122
#9  0x08204156 in do_compile () at ../../gcc/toplev.c:5177
#10 0x082041b7 in toplev_main (argc=14, argv=0xbffff934)
    at ../../gcc/toplev.c:5209
#11 0x080add27 in main (argc=14, argv=0xbffff934) at ../../gcc/main.c:35

regards

Bryce.

Re: libjava failed to build on Linux/x86

[Tom Tromey]

>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:

Tom> I suspect a non-gcj compiler bug.  I built code with a compiler which
Tom> was current as of last week sometime.  I imagine some bug was
Tom> introduced or revealed between then and now.  I've updated and I'm
Tom> rebuilding to see if I can reproduce the problem here.

I reproduced the crash here.
I've appended a stack trace.
The proximate problem is that `e->dest' is 0.

This is really outside my area of expertise.  All I know is that this
was working fine with the Jan 4 compiler.

Tom

Program received signal SIGSEGV, Segmentation fault.
0x0826d2f7 in find_unreachable_blocks () at ../../gcc/gcc/cfganal.c:363
363		if (!(e->dest->flags & BB_REACHABLE))
(gdb) bt
#0  0x0826d2f7 in find_unreachable_blocks () at ../../gcc/gcc/cfganal.c:363
#1  0x08271f51 in delete_unreachable_blocks ()
    at ../../gcc/gcc/cfgcleanup.c:1715
#2  0x08271fca in cleanup_cfg (mode=0) at ../../gcc/gcc/cfgcleanup.c:1743
#3  0x08231de9 in rest_of_compilation (decl=0x4014df68)
    at ../../gcc/gcc/toplev.c:3270
#4  0x08061a4c in source_end_java_method () at parse.y:7457
#5  0x08063935 in java_expand_method_bodies (class=0x857ef44) at parse.y:8133
#6  0x0806677d in java_expand_classes () at parse.y:9024
#7  0x080a9a1f in yyparse () at ../../gcc/gcc/java/jcf-parse.c:1207
#8  0x08230384 in compile_file () at ../../gcc/gcc/toplev.c:2122
#9  0x08235ae9 in do_compile () at ../../gcc/gcc/toplev.c:5177
#10 0x08235b4b in toplev_main (argc=0, argv=0x0) at ../../gcc/gcc/toplev.c:5209
#11 0x080bb3fb in main (argc=0, argv=0x0) at ../../gcc/gcc/main.c:35
#12 0x400349cb in __libc_start_main (main=0x80bb3e0 <main>, argc=24, 
    argv=0xbffff644, init=0x8049328 <_init>, fini=0x82f4e38 <_fini>, 
    rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbffff63c)
    at ../sysdeps/generic/libc-start.c:92

Re: libjava failed to build on Linux/x86

[Tom Tromey]

>>>>> "H.J." == H J Lu <hjl@lucon.org> writes:

H.J.> http://gcc.gnu.org/ml/java-patches/2002-q1/msg00123.html

H.J.> In class `java.awt.image.MemoryImageSource':
H.J.> /home/hjl/work/gnu/src/gcc/gcc/libjava/java/awt/image/MemoryImageSource.java:
H.J.> In method
H.J.> `java.awt.image.MemoryImageSource.newPixels(byte[],java.awt.image.ColorModel,int,int)':
H.J.> /home/hjl/work/gnu/src/gcc/gcc/libjava/java/awt/image/MemoryImageSource.java:319:
H.J.> internal error: Segmentation fault


I suspect a non-gcj compiler bug.  I built code with a compiler which
was current as of last week sometime.  I imagine some bug was
introduced or revealed between then and now.  I've updated and I'm
rebuilding to see if I can reproduce the problem here.

Tom

Re: libjava failed to build on Linux/x86

[Per Bothner]

It's failing for me too, but in a different place:

/home/bothner/GNU/linux-gcc/gcc/g++ -B/home/bothner/GNU/linux-gcc/gcc/ 
-nostdinc++ -nostdinc++ 
-I/home/bothner/GNU/linux-gcc/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu 
-I/home/bothner/GNU/linux-gcc/i686-pc-linux-gnu/libstdc++-v3/include 
-I/home/bothner/GNU/gcc/libstdc++-v3/libsupc++ 
-I/home/bothner/GNU/gcc/libstdc++-v3/libio 
-I/home/bothner/GNU/gcc/libstdc++-v3/include/backward 
-I/home/bothner/GNU/gcc/libstdc++-v3/testsuite 
-L/home/bothner/GNU/linux-gcc/i686-pc-linux-gnu/libstdc++-v3/src 
-L/home/bothner/GNU/linux-gcc/i686-pc-linux-gnu/libstdc++-v3/src/.libs 
-B/home/bothner/GNU/install-gcc/i686-pc-linux-gnu/bin/ 
-B/home/bothner/GNU/install-gcc/i686-pc-linux-gnu/lib/ -isystem 
/home/bothner/GNU/install-gcc/i686-pc-linux-gnu/include -DHAVE_CONFIG_H 
-I. -I/home/bothner/GNU/gcc/libjava -I./include -I./gcj 
-I/home/bothner/GNU/gcc/libjava -Iinclude 
-I/home/bothner/GNU/gcc/libjava/include 
-I/home/bothner/GNU/gcc/libjava/../boehm-gc/include -DGC_LINUX_THREADS=1 
-D_REENTRANT=1 -DTHREAD_LOCAL_ALLOC=1 -DSILENT=1 -DNO_SIGNALS=1 
-DNO_EXECUTE_PERMISSION=1 -DALL_INTERIOR_POINTERS=1 
-DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 
-I/home/bothner/GNU/gcc/libjava/libltdl 
-I/home/bothner/GNU/gcc/libjava/libltdl 
-I/home/bothner/GNU/gcc/libjava/.././libjava/../gcc 
-I/home/bothner/GNU/gcc/libjava/../zlib 
-I/home/bothner/GNU/gcc/libjava/../libffi/include -I../libffi/include 
-fno-rtti -fnon-call-exceptions -fdollars-in-identifiers 
-D__NO_MATH_INLINES -ffloat-store -I/usr/X11R6/include -W -Wall 
-D_GNU_SOURCE -DPREFIX=\"/home/bothner/GNU/install-gcc\" -g 
-D_GNU_SOURCE -MD -MT java/lang/natObject.lo -MF java/lang/natObject.pp 
-c /home/bothner/GNU/gcc/libjava/java/lang/natObject.cc  -fPIC -DPIC -o 
java/lang/.libs/natObject.o
In file included from 
/home/bothner/GNU/gcc/libjava/java/lang/natObject.cc:281:
/home/bothner/GNU/gcc/boehm-gc/include/gc.h:53:1: warning: 
"GC_LINUX_THREADS" redefined
/home/bothner/GNU/gcc/libjava/java/lang/natObject.cc:1:1: warning: this 
is the location of the previous definition
/home/bothner/GNU/gcc/libjava/java/lang/natObject.cc: In function `bool
    compare_and_swap(volatile obj_addr_t*, unsigned int, unsigned int)':
/home/bothner/GNU/gcc/libjava/java/lang/natObject.cc:329: inconsistent 
operand
    constraints in an `asm'
make[3]: *** [java/lang/natObject.lo] Error 1

The asm is:

   inline static bool
   compare_and_swap(volatile obj_addr_t *addr,
		 
				obj_addr_t old,
						obj_addr_t new_val)
   {
     char result;
     __asm__ __volatile__("lock; cmpxchgl %2, %0; setz %1"
	    	: "=m"(*(addr)), "=q"(result)
		: "r" (new_val), "0"(*(addr)), "a"(old) : "memory");
     return (bool) result;
   }


-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

libjava failed to build on Linux/x86

[H . J . Lu]

Since

http://gcc.gnu.org/ml/java-patches/2002-q1/msg00123.html

I got

# /export/build/gnu/gcc/build-i686-linux/gcc/gcj -B/export/build/gnu/gcc/build-i686-linux/i686-pc-linux-gnu/libjava/ -B/export/build/gnu/gcc/build-i686-linux/gcc/ --encoding=UTF-8 -fassume-compiled -fclasspath=/export/build/gnu/gcc/build-i686-linux/i686-pc-linux-gnu/libjava -L/export/build/gnu/gcc/build-i686-linux/i686-pc-linux-gnu/libjava -ffloat-store -g -O2 -MD -MT java/awt/image/MemoryImageSource.lo -MF java/awt/image/MemoryImageSource.d -c /home/hjl/work/gnu/src/gcc/gcc/libjava/java/awt/image/MemoryImageSource.java -o java/awt/image/MemoryImageSource.o
/home/hjl/work/gnu/src/gcc/gcc/libjava/java/awt/image/MemoryImageSource.java:
In class `java.awt.image.MemoryImageSource':
/home/hjl/work/gnu/src/gcc/gcc/libjava/java/awt/image/MemoryImageSource.java:
In method
`java.awt.image.MemoryImageSource.newPixels(byte[],java.awt.image.ColorModel,int,int)':
/home/hjl/work/gnu/src/gcc/gcc/libjava/java/awt/image/MemoryImageSource.java:319:
internal error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

It is configured with:

--enable-clocale=gnu --with-system-zlib --enable-shared --enable-threads=posix --enable-haifa --disable-checking --prefix=/usr/gcc-3.1 --with-local-prefix=/usr/local



H.J.