On Sat, 2006-04-01 at 12:11 -0700, Tom Tromey wrote:
> >>>>> "Mark" == Mark Wielaard <mark@xxxxxxxxx> writes:
> Mark> Unfortunately it seems to trigger some gcj bug with the svn trunk
> Mark> development version on builder (see below). I checked against 4.0.3 and
> Mark> 4.1 and they both seem fine. I am not 100% sure it is caused by this
> Mark> patch (still building a 4.2 version myself, but I need to go for today,
> Mark> so might not be able to check definitely till Monday).
> I think this crash predates the split-for-gcj change by several hours.
Seems you are right. I tested against gcc/java revisions 112102, 112499
and 112540 which seem to compile things fine. Revision 112574 seems to
cause the failure, so it was probably this patch:
2006-03-30 Andrew Haley <aph@xxxxxxxxxx>
* lang.c (java_attribute_table): New.
* expr.c (build_field_ref): Add a null pointer check for all
fields of offset > 4k. Don't do so for accesses via the this
pointer, which we know can never be null.
* class.c (build_java_method_type): Mark arg 1 of all nonstatic
After generating the list files in classpath/lib you can trigger the
compile error by:
$ /usr/local/gcc42/bin/gcj -Wno-deprecated --encoding=UTF-8
-C -d . -MD -MF lists/java-lang.deps -MT lists/java-lang.stamp -MP
../java/lang/Class.java: In class 'java.lang.Class':
../java/lang/Class.java: In constructor
../java/lang/Class.java:141: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
It seems to be triggered by the assignment of this.pd to some other
Class pd field. Strangely enough the following workaround seems to not
trigger the compile failure:
diff -u -r1.43 Class.java
--- java/lang/Class.java 18 Dec 2005 13:03:48 -0000 1.43
+++ java/lang/Class.java 2 Apr 2006 20:27:40 -0000
@@ -138,7 +138,7 @@
// saves the VM from having to worry about protection domains for array
if (pd == null && isArray())
- this.pd = getComponentType().pd;
+ this.pd = getComponentType().internalGetProtectionDomain();
this.pd = pd;
@@ -1162,6 +1162,11 @@
if (sm != null)
+ return internalGetProtectionDomain();
+ private ProtectionDomain internalGetProtectionDomain()
return pd == null ? StaticData.unknownProtectionDomain : pd;
So, if all else fails we can use that as workaround. But it would be
nice to know why it fails.