On Wed, Feb 07, 2018 at 03:52:39PM -0500, Jason Merrill wrote:
> > E.g. the constexpr function uses same_type_ignoring_top_level_qualifiers_p
> > instead of == type comparisons, the COMPONENT_REF stuff, ...
>
> > For poly_* stuff, I think Richard S. wants to introduce it into the FEs at
> > some point, but I could be wrong; certainly it hasn't been done yet and
> > generally, poly*int seems to be a nightmare to deal with.
>
> Yes, I understand how we got to this point, but having the functions
> diverge because of this guideline seems like a mistake. And there
> seem to be two ways to avoid the divergence: make an exception to the
> guideline, or move the function.
Functionally, I think the following patch should turn fold_indirect_ref_1
to be equivalent to the patched constexpr.c version (with the known
documented differences), so if this is the obstackle for the acceptance
of the patch, I can test this.
Otherwise, I must say I have no idea how to share the code,
same_type_ignoring_qualifiers is only a C++ FE function, so the middle-end
can't use it even conditionally, and similarly with the TBAA issues.
--- gcc/fold-const.c.jj 2018-01-26 18:41:34.316410713 +0100
+++ gcc/fold-const.c 2018-02-07 22:10:54.958628078 +0100
@@ -14172,7 +14172,16 @@ fold_indirect_ref_1 (location_t loc, tre
/* ((foo*)&vectorfoo)[1] => BIT_FIELD_REF<vectorfoo,...> */
if (TREE_CODE (op00type) == VECTOR_TYPE
- && type == TREE_TYPE (op00type))
+ && type == TREE_TYPE (op00type)
+ /* POINTER_PLUS_EXPR second operand is sizetype, unsigned,
+ but we want to treat offsets with MSB set as negative.
+ For the code below negative offsets are invalid and
+ TYPE_SIZE of the element is something unsigned, so
+ check whether op01 fits into poly_int64, which implies
+ it is from 0 to INTTYPE_MAXIMUM (HOST_WIDE_INT), and
+ then just use poly_uint64 because we want to treat the
+ value as unsigned. */
+ && tree_fits_poly_int64_p (op01))
{
tree part_width = TYPE_SIZE (type);
poly_uint64 max_offset
Jakub
