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

Reply via email to