On Tue, 6 Mar 2012, Richard Guenther wrote:
>
> This splits out some small chunks from the patch killing
> TYPE_IS_SIZETYPE. It introduces a helper function that
> performs object-size checks and uses it in the few places
> that would need adjustments when host_integerp is no longer
> appropriate for verifying that the size fits in half of the
> address-space.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk?
>
> --
>
> Eric, this starts the series of getting rid of TYPE_IS_SIZETYPE.
> This patch will break Ada bootstrap (fixed by subsequent patches),
> because copy_and_substitute_in_size () will sometimes (in this
> case for the secondary stack size) compute a constant TYPE_SIZE_UNIT
> with TREE_OVERFLOW set (compiling s-secsta.adb). With the theory that
> sizetypes cannot have overflow this looks like a latent bug somewhere in
> the construction of the expression that leads to it. When sizetypes
> are finally unsigned the overflow bit will not be set anymore and
> this bug does not trigger.
>
> Happens when substitute_in_expr with
> exp = (sizetype) ((bitsizetype) -<PLACEHOLDER_EXPR struct
> system__secondary_stack__chunk_id>.first + 10241)
> f = first
> r = 1
> we then convert bitsizetype 0x100002800 to sizetype via
> fold_convert_const_int_from_int (this is -m32 multilib), which
> leads to an overflowed value. Not sure how we arrive at this
> call of substitute_in_expr as the original expression we substitute in
> is
>
> ((sizetype) (_GLOBAL.SZ4_system.secondary_stack (<PLACEHOLDER_EXPR struct
> system__secondary_stack__chunk_id>.last, <PLACEHOLDER_EXPR struct
> system__secondary_stack__chunk_id>.first) /[cl] 8) + 15 & -16) + 16
>
> and thus the bitsize quantity _GLOBAL.SZ4_system.secondary_stack
> (<PLACEHOLDER_EXPR struct
> system__secondary_stack__chunk_id>.last, <PLACEHOLDER_EXPR struct
> system__secondary_stack__chunk_id>.first) is first divided by 8
> and _then_ converted to sizetype. I suspect some existing bug
> in some re-association. It's appearantly not
>
> 2011-09-04 Richard Guenther <rguent...@suse.de>
>
> Revert
> 2011-08-31 Richard Guenther <rguent...@suse.de>
>
> * fold-const.c (extract_muldiv_1): Remove bogus TYPE_IS_SIZETYPE
> special-casing.
>
> though.
>
> I'm not sure how much I need to care for Ada at this point, and I am
> definitely wanting to kill off TYPE_IS_SIZETYPE and sizetypes
> sign-extending. That's a definite prerequesite to continue on
> no-undefined-overflow.
Btw, digging down this rat-hole again shows that the first issue
you hit is the "negative" DECL_FIELD_OFFSETs. If you paper over
some issues with
2011-09-02 Richard Guenther <rguent...@suse.de>
ada/
* gcc-interface/utils.c (shift_unc_components_for_thin_pointers):
Drop overflow bit on negative offsets.
Index: trunk/gcc/ada/gcc-interface/utils.c
===================================================================
*** trunk.orig/gcc/ada/gcc-interface/utils.c 2012-03-06 16:00:04.000000000
+0100
--- trunk/gcc/ada/gcc-interface/utils.c 2012-03-06 16:04:26.000000000 +0100
*************** shift_unc_components_for_thin_pointers (
*** 3447,3452 ****
--- 3447,3460 ----
DECL_FIELD_OFFSET (bounds_field)
= size_binop (MINUS_EXPR, size_zero_node, byte_position (array_field));
+ /* The above computation overflows to a "negative" unsigned value.
+ Drop the overflow flag. */
+ if (TREE_CODE (DECL_FIELD_OFFSET (bounds_field)) == INTEGER_CST
+ && TREE_OVERFLOW (DECL_FIELD_OFFSET (bounds_field)))
+ DECL_FIELD_OFFSET (bounds_field)
+ = build_int_cst_wide (sizetype,
+ TREE_INT_CST_LOW (DECL_FIELD_OFFSET (bounds_field)),
+ TREE_INT_CST_HIGH (DECL_FIELD_OFFSET
(bounds_field)));
DECL_FIELD_OFFSET (array_field) = size_zero_node;
DECL_FIELD_BIT_OFFSET (array_field) = bitsize_zero_node;
Index: trunk/gcc/ada/gcc-interface/trans.c
===================================================================
*** trunk.orig/gcc/ada/gcc-interface/trans.c 2012-03-06 16:00:03.000000000
+0100
--- trunk/gcc/ada/gcc-interface/trans.c 2012-03-06 16:02:37.000000000 +0100
*************** Attribute_to_gnu (Node_Id gnat_node, tre
*** 1959,1964 ****
--- 1959,1971 ----
gnu_type = TYPE_OBJECT_RECORD_TYPE (gnu_type);
gnu_result = size_binop (MINUS_EXPR, bitsize_zero_node,
bit_position (TYPE_FIELDS (gnu_type)));
+ /* The above computation overflows from "negative" to positive.
+ Drop the overflow flag. */
+ if (TREE_CODE (gnu_result) == INTEGER_CST
+ && TREE_OVERFLOW (gnu_result))
+ gnu_result = build_int_cst_wide (bitsizetype,
+ TREE_INT_CST_LOW (gnu_result),
+ TREE_INT_CST_HIGH (gnu_result));
gnu_result_type = get_unpadded_type (Etype (gnat_node));
prefix_unused = true;
break;
then you run into the above code
gnu_result = size_binop (MINUS_EXPR, bitsize_zero_node,
bit_position (TYPE_FIELDS (gnu_type)));
where bit_position computes sth way off (because the "negative" byte
offset is not sign-extended and on a 64bit HWI platform bitsizetype
has precision 64 - that makes it a poor twos-complement arithmetic
type. Subtracting a non-sign-extended 35-bit value from 64-bit
zero makes it very off. Now I bet there is a reason for choosing
the TYPE_PRECISION of bitsize types to match an available mode
(but never larger than 2 * HWI) - but I doubt, or at least I hope,
that we never emit code for computations in bitsizetype (which would
make the 'sizetypes never overflow'-thing not apply to bitsizetype,
as then it wouldn't be true twos-complement semantics anymore but
a-bit-more-but-not-arbitrary-precision arithmetic).
Well. I suppose fixing that negative DECL_FIELD_OFFSET thing should
be #1 priority.
Trying what happens with a properly precisioned bitsizetype now ...
Richard.
