On March 19, 2018 9:05:23 PM GMT+01:00, Jakub Jelinek <ja...@redhat.com> wrote:
>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?
OK.
Richard.
>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
