How disgusting. Java still emits RTL from the front end:

Breakpoint 1, internal_error (gmsgid=0x1551007 "in %s, at %s:%d") at ../../trunk/gcc/diagnostic.c:843
843       va_start (ap, gmsgid);
(gdb) up
#1  0x000000000120a503 in fancy_abort (file=0x135398c "../../trunk/gcc/varasm.c", line=2179, function=0x1354450 "assemble_external") at ../../trunk/gcc/diagnostic.c:899
899       internal_error ("in %s, at %s:%d", function, trim_filename (file), line);
(gdb) 
#2  0x0000000000d8942d in assemble_external (decl=0x7ffff70d7be0) at ../../trunk/gcc/varasm.c:2178
2178      gcc_assert (cgraph_state == CGRAPH_STATE_EXPANSION
(gdb) l
2173      /* This function should only be called if we are expanding, or have
2174         expanded, to RTL.
2175         Ideally, only final.c would be calling this function, but it is
2176         not clear whether that would break things somehow.  See PR 17982
2177         for further discussion.  */
2178      gcc_assert (cgraph_state == CGRAPH_STATE_EXPANSION
2179                  || cgraph_state == CGRAPH_STATE_FINISHED);
2180
2181      if (!DECL_P (decl) || !DECL_EXTERNAL (decl) || !TREE_PUBLIC (decl))
2182        return;
(gdb) p cgraph_state
$1 = CGRAPH_STATE_CONSTRUCTION
(gdb) bt 20
#0  internal_error (gmsgid=0x1551007 "in %s, at %s:%d") at ../../trunk/gcc/diagnostic.c:843
#1  0x000000000120a503 in fancy_abort (file=0x135398c "../../trunk/gcc/varasm.c", line=2179, function=0x1354450 "assemble_external") at ../../trunk/gcc/diagnostic.c:899
#2  0x0000000000d8942d in assemble_external (decl=0x7ffff70d7be0) at ../../trunk/gcc/varasm.c:2178
#3  0x00000000006f0c48 in output_addr_const (file=0x1ad94f0, x=0x7ffff71b2c00) at ../../trunk/gcc/final.c:3568
#4  0x0000000000d89ee4 in assemble_integer_with_op (op=0x135e56d "\t.quad\t", x=0x7ffff71b2c00) at ../../trunk/gcc/varasm.c:2466
#5  0x0000000000d89fa8 in default_assemble_integer (x=0x7ffff71b2c00, size=8, aligned_p=1) at ../../trunk/gcc/varasm.c:2482
#6  0x0000000000d8a05c in assemble_integer (x=0x7ffff71b2c00, size=8, align=64, force=0) at ../../trunk/gcc/varasm.c:2498
#7  0x0000000000d96806 in output_constant (exp=0x7ffff6df5e38, size=8, align=64) at ../../trunk/gcc/varasm.c:4562
#8  0x00000000004baedf in emit_register_classes (list_p=0x7fffffffd880) at ../../trunk/gcc/java/class.c:2833
#9  0x000000000050b1e5 in java_emit_static_constructor () at ../../trunk/gcc/java/jcf-parse.c:1697
#10 0x000000000050c298 in java_parse_file () at ../../trunk/gcc/java/jcf-parse.c:1978
#11 0x0000000000a5c6a2 in compile_file () at ../../trunk/gcc/toplev.c:556
#12 0x0000000000a5eb5a in do_compile () at ../../trunk/gcc/toplev.c:1936
#13 0x0000000000a5ecaf in toplev_main (argc=33, argv=0x7fffffffdb88) at ../../trunk/gcc/toplev.c:2012
#14 0x00000000005235e3 in main (argc=33, argv=0x7fffffffdb88) at ../../trunk/gcc/main.c:36
(gdb)

I believe the following should fix the problem, altough I fail to see how this can ever have worked with LTO.  HJ, could you test this for me, please? I have no access to ia32 anymore. 

Index: class.c
===================================================================
--- class.c     (revision 185813)
+++ class.c     (working copy)
@@ -3241,6 +3241,7 @@ java_write_globals (void)
   write_global_declarations ();
   emit_debug_global_declarations (vec, len);
   VEC_free (tree, gc, pending_static_fields);
+  java_emit_static_constructor ();
 }
 
 #include "gt-java-class.h"
Index: jcf-parse.c
===================================================================
--- jcf-parse.c (revision 185813)
+++ jcf-parse.c (working copy)
@@ -1689,7 +1689,7 @@ predefined_filename_p (tree node)
 /* Generate a function that does all static initialization for this 
    translation unit.  */
 
-static void
+void
 java_emit_static_constructor (void)
 {
   tree body = NULL;
@@ -1974,8 +1974,6 @@ java_parse_file (void)
   bitmap_obstack_release (&bit_obstack);
 
  finish:
-  /* Arrange for any necessary initialization to happen.  */
-  java_emit_static_constructor ();
   gcc_assert (global_bindings_p ());
 }
 
Index: java-tree.h
===================================================================
--- java-tree.h (revision 185813)
+++ java-tree.h (working copy)
@@ -940,6 +940,7 @@ struct GTY((variable_size)) lang_type {
 struct eh_range;
 
 extern void java_parse_file (void);
+extern void java_emit_static_constructor (void);
 extern tree java_type_for_mode (enum machine_mode, int);
 extern tree java_type_for_size (unsigned int, int);
 extern tree java_truthvalue_conversion (tree);

> I believe the following should fix the problem, altough I fail to see how this
> can ever have worked with LTO. 

Java doesn't work with LTO.

(In reply to comment #2)
> I believe the following should fix the problem, altough I fail to see how this
> can ever have worked with LTO.  HJ, could you test this for me, please? I have
> no access to ia32 anymore. 

It also failed on Linux/x86-64:

http://gcc.gnu.org/ml/gcc-regression/2012-03/msg00268.html

when configured with

--prefix=/usr/local --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld --with-fpmath=sse --enable-languages=c,c++,fortran,java,lto,objc

Yes, I've reverted that patch for the time being.

Created attachment 27018 [details]
Stop using output_constant in class.c

I believe something like this should work, but I don't want to have a named variable (now I output a constructor for "_Jv_CLS") and I have not yet been able to figure out how to do so. Input from Java maintainer appreciated...

Java maintainer help needed.

Author: steven
Date: Thu Mar 29 21:00:23 2012
New Revision: 185977

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185977
Log:
	PR java/52730
	* class.c (emit_register_classes_in_jcr_section): New function.
	(emit_Jv_RegisterClass_calls): New function, split out from ...
	(emit_register_classes): ... here. Reorganize.  Do not call
	output_constant.


Modified:
    trunk/gcc/java/ChangeLog
    trunk/gcc/java/class.c

Java now emits a constructor to a static variable with DECL_SECTION_NAME set to the .jcr section name.