https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118954
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rsandifo at gcc dot gnu.org
--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
/* We may not associate the constant offset across the pointer plus
expression because that might form a pointer to before the object
then. But for some cases we can retain that to allow tree_could_trap_p
to return false - see gcc.dg/tree-ssa/predcom-1.c */
tree addr, alias_ptr;
if (integer_zerop (off))
{
alias_ptr = fold_convert (reference_alias_ptr_type (ref), coff);
addr = DR_BASE_ADDRESS (dr);
so we anticipate the problem but wrongly assume any problematic offset
is in DR_OFFSET. But it can also be in DR_BASE_ADDRESS:
(int *) &g + (sizetype) _23 * 18446744073709551612
you can probably argue that data-ref analysis decomposed the ref in an
invalid way given DR_BASE_ADDRESS is &g[-1] here.
It's split_constant_offset that decomposes
(int *) &g + (long unsigned int) (int) ((unsigned int) _2 + 4294967295) * 4
as
(int *) &g + (sizetype) _23 * 18446744073709551612
and the constant offset 8 and we are not re-evaluating what we consider
the "offset" (that's only computed from get_inner_reference of the original
MEM, not what simple_iv or split_constant_offset makes of it).
It's a bit late in the cycle to try fixing that and I also don't have a good
idea here (CCed Richard as split_constant_offset expert).
But I can mitigate this from predcom as well, in some ad-hoc way (rather
than trying to be conservative). Testing a patch.
