Greetings,
I've been debugging a Fedora 17 build problem on ppc64-redhat-linux, and
ran into an issue with bitsizetype. I have a patch that fixes the
problem, but I'm not yet convinced it's the right fix. I'm hoping
someone here can help me sort it out.
The problem occurs when compiling some Java code at -O3. The symptom is
a segv during predictive commoning. The problem comes when analyzing a
data dependence between two field references. The access functions for
the data refs are determined in tree-data-ref.c: dr_analyze_indices ():
else if (TREE_CODE (ref) == COMPONENT_REF
&& TREE_CODE (TREE_TYPE (TREE_OPERAND (ref, 0))) == RECORD_TYPE)
{
/* For COMPONENT_REFs of records (but not unions!) use the
FIELD_DECL offset as constant access function so we can
disambiguate a[i].f1 and a[i].f2. */
tree off = component_ref_field_offset (ref);
off = size_binop (PLUS_EXPR,
size_binop (MULT_EXPR,
fold_convert (bitsizetype, off),
bitsize_int (BITS_PER_UNIT)),
DECL_FIELD_BIT_OFFSET (TREE_OPERAND (ref, 1)));
VEC_safe_push (tree, heap, access_fns, off);
}
Note the use of bitsizetype. On a 64-bit target that defines TImode,
this is apparently set to a 128-bit unsigned type, verified in gdb:
(gdb) ptr bitsizetype
<integer_type 0xfffb5d700a8 bitsizetype public unsigned sizetype TI
size <integer_cst 0xfffb5c82380 type <integer_type 0xfffb5d700a8
bitsizetype> constant 128>
unit size <integer_cst 0xfffb5c823a0 type <integer_type
0xfffb5d70000 sizetype> constant 16>
align 128 symtab 0 alias set -1 canonical type 0xfffb5d700a8
precision 128 min <integer_cst 0xfffb5c823c0 0> max <integer_cst
0xfffb5c82360 -1>>
The problem arises in tree-data-ref.c: analyze_ziv_subscript:
type = signed_type_for_types (TREE_TYPE (chrec_a), TREE_TYPE (chrec_b));
chrec_a = chrec_convert (type, chrec_a, NULL);
chrec_b = chrec_convert (type, chrec_b, NULL);
difference = chrec_fold_minus (type, chrec_a, chrec_b);
Both input types are bitsizetype of mode TImode. This call reduces to a
call to tree.c: signed_or_unsigned_type_for ():
return lang_hooks.types.type_for_size (TYPE_PRECISION (t), unsignedp);
So this is the interesting point. We are calling back to the front end
to find a type having the same precision as bitsizetype, in this case
128. The C lang hook handles this fine, but the Java one does not:
tree
java_type_for_size (unsigned bits, int unsignedp)
{
if (bits <= TYPE_PRECISION (byte_type_node))
return unsignedp ? unsigned_byte_type_node : byte_type_node;
if (bits <= TYPE_PRECISION (short_type_node))
return unsignedp ? unsigned_short_type_node : short_type_node;
if (bits <= TYPE_PRECISION (int_type_node))
return unsignedp ? unsigned_int_type_node : int_type_node;
if (bits <= TYPE_PRECISION (long_type_node))
return unsignedp ? unsigned_long_type_node : long_type_node;
return 0;
}
This returns zero, causing the first call to chrec_convert in
analyze_ziv_subscript to segfault.
I can cause the build to succeed with the following patch...
Index: gcc/java/typeck.c
===================================================================
--- gcc/java/typeck.c (revision 187158)
+++ gcc/java/typeck.c (working copy)
@@ -189,6 +189,12 @@ java_type_for_size (unsigned bits, int unsignedp)
return unsignedp ? unsigned_int_type_node : int_type_node;
if (bits <= TYPE_PRECISION (long_type_node))
return unsignedp ? unsigned_long_type_node : long_type_node;
+ /* A 64-bit target with TImode requires 128-bit type definitions
+ for bitsizetype. */
+ if (int128_integer_type_node
+ && bits == TYPE_PRECISION (int128_integer_type_node))
+ return (unsignedp ? int128_unsigned_type_node
+ : int128_integer_type_node);
return 0;
}
...but I wonder whether this is the correct approach. Is the problem
really that the lang hook is missing handling for bitsizetype for
certain targets, or is the problem that bitsizetype is 128 bits? All of
the other front ends seem to get along fine with a 128-bit bitsizetype;
it's just kind of an odd choice on a 64-bit machine. Or is the problem
in the dr_analyze_indices code that's using bitsizetype?
The thing that gives me pause here is that other machines would likely
have the same problem. Any machine using a 128-bit bitsizetype would
hit this problem sooner or later when optimizing Java code. Perhaps
it's just that few people compile Java statically anymore -- certainly
we don't even build it during normal development.
I had myself convinced that all 64-bit machines with a TImode would have
a 128-bit bitsizetype, but I'm having trouble connecting the dots on
that at the moment, so that may or may not be true. If it is, though,
then this would seemingly come up periodically on Intel building Java.
That makes me suspicious that I don't understand this well enough yet.
Thanks in advance for any help! I'd like to get this resolved quickly
for the Fedora folks, but I want to do it properly.
Thanks,
Bill
