Hi! In this code, both bitpos and bitsize are poly_int64, but we know that bitpos is >= 0 and bitsize. On the testcase mentioned in the PR (but even without -mavx512f, so we already invoke it during testing) we would overflow the computation, 0x7ffffffffffsomething + 0x2000000000 (and then cast it to poly_uint64). This patch fixes it by casting to poly_uint64 earlier.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2018-03-19 Jakub Jelinek <ja...@redhat.com> PR tree-optimization/84946 * gimple-ssa-store-merging.c (mem_valid_for_store_merging): Compute bitsize + bitsize in poly_uint64 rather than poly_int64. --- gcc/gimple-ssa-store-merging.c.jj 2018-02-22 09:28:07.000000000 +0100 +++ gcc/gimple-ssa-store-merging.c 2018-03-19 17:55:22.486472527 +0100 @@ -3948,7 +3948,8 @@ mem_valid_for_store_merging (tree mem, p if (known_eq (bitregion_end, 0U)) { bitregion_start = round_down_to_byte_boundary (bitpos); - bitregion_end = round_up_to_byte_boundary (bitpos + bitsize); + bitregion_end = bitpos; + bitregion_end = round_up_to_byte_boundary (bitregion_end + bitsize); } if (offset != NULL_TREE) Jakub