This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question about bitsizetype

On Wed, May 9, 2012 at 1:36 PM, William J. Schmidt
<> wrote:
> 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
> Â Â Â Â{
> Â Â Â Â Â/* 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)),
> Â Â Â Â Â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);

And that was fixed by not calling type_for_size with the following patch:
r185226 | rguenth | 2012-03-12 06:04:43 -0700 (Mon, 12 Mar 2012) | 9 lines

2012-03-12  Richard Guenther  <>

        * tree.c (signed_or_unsigned_type_for): Use
        (signed_type_for): Adjust documentation.
        (unsigned_type_for): Likewise.
        * tree-pretty-print.c (dump_generic_node): Use standard names
        for non-standard integer types if available.
Andrew Pinski

> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]