cygwin failures - assertion "!(addr & FLAGS)" failed:

cygwin failures - assertion "!(addr & FLAGS)" failed:

[Billinghurst, David (CRTS)]

At last a real bug in the cygwin libjava testsuite.  Most of the 
compilation tests pass, but all (that I could find) executable 
tests fail with 

assertion "!(addr & FLAGS)" failed: file "/usr/local/src/gcc3.1/libjava/java/lang/natObject.cc", line 772

Enough for today.  I will wait for CVS to catch up with Jerome and I, 
then switch to the trunk for further work.



spawn /usr/local/obj/gcc-3.1-java/i686-pc-cygwin/libjava/testsuite/../libtool --silent --tag=GCJ --mode=link /usr/local/obj/gcc-3.1-java/gcc/gcj -B/usr/local/obj/gcc-3.1-java/gcc/ --encoding=UTF-8 -B/usr/local/obj/gcc-3.1-java/i686-pc-cygwin/libjava/testsuite/../ /usr/local/src/gcc-3.1/libjava/testsuite/libjava.lang/anfi.java -no-install --main=anfi -g -L/usr/local/obj/gcc-3.1-java/i686-pc-cygwin//libjava/.libs -L/usr/local/obj/gcc-3.1-java/i686-pc-cygwin//boehm-gc/.libs -o /usr/local/obj/gcc-3.1-java/i686-pc-cygwin/libjava/testsuite/anfi.exe  PASS: anfi compilation from source
spawn [open ...] assertion "!(addr & FLAGS)" failed: file "/usr/local/src/gcc-3.1/libjava/java/lang/natObject.cc", line 772
FAIL: anfi execution from source compiled test

spawn /usr/local/obj/gcc-3.1-java/i686-pc-cygwin/libjava/testsuite/../libtool --silent --tag=GCJ --mode=link /usr/local/obj/gcc-3.1-java/gcc/gcj -B/usr/local/obj/gcc-3.1-java/gcc/ --encoding=UTF-8 -B/usr/local/obj/gcc-3.1-java/i686-pc-cygwin/libjava/testsuite/../ /usr/local/obj/gcc-3.1-java/i686-pc-cygwin/libjava/testsuite/anfi.class /usr/local/obj/gcc-3.1-java/i686-pc-cygwin/libjava/testsuite/anfi$1.class /usr/local/obj/gcc-3.1-java/i686-pc-cygwin/libjava/testsuite/itf.class -no-install --main=anfi -g -L/usr/local/obj/gcc-3.1-java/i686-pc-cygwin//libjava/.libs -L/usr/local/obj/gcc-3.1-java/i686-pc-cygwin//boehm-gc/.libs -o /usr/local/obj/gcc-3.1-java/i686-pc-cygwin/libjava/testsuite/anfi  PASS: anfi compilation from bytecode
spawn [open ...] assertion "!(addr & FLAGS)" failed: file "/usr/local/src/gcc-3.1/libjava/java/lang/natObject.cc", line 772
FAIL: anfi execution from bytecode->native test

/usr/local/obj/gcc-3.1-java/i686-pc-cygwin/libjava/testsuite/../libtool --silent --tag=GCJ --mode=link /usr/local/obj/gcc-3.1-java/gcc/gcj -B/usr/local/obj/gcc-3.1-java/gcc/ --encoding=UTF-8 -B/usr/local/obj/gcc-3.1-java/i686-pc-cygwin/libjava/testsuite/../ /usr/local/src/gcc-3.1/libjava/testsuite/libjava.lang/anfi.java -no-install --main=anfi -O -g -L/usr/local/obj/gcc-3.1-java/i686-pc-cygwin//libjava/.libs -L/usr/local/obj/gcc-3.1-java/i686-pc-cygwin//boehm-gc/.libs -o /usr/local/obj/gcc-3.1-java/i686-pc-cygwin/libjava/testsuite/anfi.exe  PASS: anfi -O compilation from source
spawn [open ...] assertion "!(addr & FLAGS)" failed: file "/usr/local/src/gcc-3.1/libjava/java/lang/natObject.cc", line 772
FAIL: anfi -O execution from source compiled test

Re: cygwin failures - assertion "!(addr & FLAGS)" failed:

[Tom Tromey]

>>>>> "David" == Billinghurst, David (CRTS) <David.Billinghurst@riotinto.com> writes:

David> At last a real bug in the cygwin libjava testsuite.  Most of the 
David> compilation tests pass, but all (that I could find) executable 
David> tests fail with 

David> assertion "!(addr & FLAGS)" failed: file "/usr/local/src/gcc3.1/libjava/java/lang/natObject.cc", line 772

My understanding is that we use the lowest 3 bits to keep some
information about the thin locks.  If this assertion fails, it means
that we've found an object which isn't suitably aligned.  I think this
can mean one of two things:

1. There is a bug in the allocator (unlikely), or
2. The compiler isn't properly aligning an object which it lays out
   statically.  For instance this could happen with some Class object

A bug along these lines was fixed pretty recently:

2002-04-18  Bryce McKinlay  <bryce@waitaki.otago.ac.nz>

	* class.c (make_class_data): Set DECL_ALIGN on static class data,
	for hash synchronization.
	* expr.c (java_expand_expr): Set DECL_ALIGN on static array objects.
	* decl.c (java_init_decl_processing): Don't set TYPE_ALIGN for
	class_type_node.

If you already have this patch then I guess there's another such bug :-(

Tom