https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64044
Bug ID: 64044 Summary: Java emits bogus .class$ decls Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: java Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org CC: aph at gcc dot gnu.org Currently the Java FE is lucky that not all -findirect-dispatch testcases are miscompiled as gimple-fold.c:get_symbol_constant_value has /* Variables declared 'const' without an initializer have zero as the initializer if they may not be overridden at link or run time. */ if (!val && (INTEGRAL_TYPE_P (TREE_TYPE (sym)) || SCALAR_FLOAT_TYPE_P (TREE_TYPE (sym)))) return build_zero_cst (TREE_TYPE (sym)); which for unkown reason avoids to fold the reads from .class$ at the beginning of all functions to NULL (because the above doesn't allow pointer types). I ran into this when doing the same during value-numbering but "forgetting" to paper over the Java FE bug. The Java FE emits (for example) <var_decl 0x7ffff6c6e360 Array_2.class$ type <pointer_type 0x7ffff6c69a80 type <record_type 0x7ffff6c69930 java.lang.Class readonly type_4 BLK size <integer_cst 0x7ffff6c43858 constant 2240> unit size <integer_cst 0x7ffff6c43828 constant 280> align 64 symtab 0 alias set -1 canonical type 0x7ffff6c69930 fields <field_decl 0x7ffff6c521c8 D.89> pointer_to_this <pointer_type 0x7ffff6c699d8>> readonly public unsigned DI size <integer_cst 0x7ffff6c25bb8 constant 64> unit size <integer_cst 0x7ffff6c25bd0 constant 8> align 64 symtab 0 alias set -1 canonical type 0x7ffff6c69a80 pointer_to_this <pointer_type 0x7ffff6c7f888>> readonly constant addressable public static unsigned ignored DI file Array_2.java line 4 col 0 size <integer_cst 0x7ffff6c25bb8 64> unit size <integer_cst 0x7ffff6c25bd0 8> align 64 context <record_type 0x7ffff6c5e540 Array_2> (mem/u/f/c:DI (symbol_ref:DI ("_ZN7Array_27class$$E") [flags 0x2] <var_decl 0x7ffff6c6e360 Array_2.class$>) [2 Array_2.class$+0 S8 A64])> which misses an initializer (it seems to be not initialized in .s either, thus the flags on it are wrong? Probably they get initialized by the runtime?).