[Bug testsuite/90806] Warray-bounds-2.c fail on cross-aarch64 on RH6 host

[Bug testsuite/90806] Warray-bounds-2.c fail on cross-aarch64 on RH6 host

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90806

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
                 CC|                            |ebotcazou at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
   Last reconfirmed|                            |2020-12-14

--- Comment #8 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
We have been seeing it for a few days now, along with Warray-bounds-30.c.  What
has changed in our setup is only the base compiler.  The reduction of
Warray-bounds-30.c shows that for:

#define DIFF_MAX __PTRDIFF_MAX__
#define DIFF_MIN (-DIFF_MAX - 1)

#define MIN DIFF_MIN

void sink (int, ...);

#define T(...)   sink (0, __VA_ARGS__)


void test_local_char_array (void)
{
  char ar3[3] = { 1, 2, 3 };
  char *p = ar3;

  T (p[MIN]);       /* { dg-warning "subscript -\[0-9\]+ is outside array
bounds of .char\\\[3]." } */
  T (p[-1]);        /* { dg-warning "subscript -1 is outside array bounds of
.char\\\[3]." } */

  T (&p[MIN]);      /* { dg-warning "subscript -\[0-9\]+ is \(below|outside\)
array bounds of .char\\\[3]." } */
  T (&p[-1]);       /* { dg-warning "subscript -1 is \(below|outside\) array
bounds of .char\\\[3]." } */
}

compiled at -O2, the FRE1 pass behaves differently:

@@ -15,11 +15,11 @@
 Value numbering store ar3 to "\x01\x02\x03"
 Setting value number of .MEM_10 to .MEM_10 (changed)
 Value numbering stmt = _2 = MEM[(char *)&ar3 + -9223372036854775808B];
-Setting value number of _2 to _2 (changed)
-Making available beyond BB2 _2 for value _2
+Setting value number of _2 to 1 (changed)
 Value numbering stmt = _3 = (int) _2;
-Setting value number of _3 to _3 (changed)
-Making available beyond BB2 _3 for value _3
+Match-and-simplified (int) _2 to 1
+RHS (int) _2 simplified to 1
+Setting value number of _3 to 1 (changed)
 Value numbering stmt = sink (0, _3);
 Setting value number of .MEM_12 to .MEM_12 (changed)
 Value numbering stmt = _5 = MEM[(char *)&ar3 + -1B];
@@ -39,21 +39,21 @@
 Value numbering stmt = return;
 marking outgoing edge 2 -> 1 executable
 RPO iteration over 1 blocks visited 1 blocks in total discovering 1 executable
blocks iterating 1.0 times, a block was visited max. 1 times
-RPO tracked 4 values available at 4 locations and 10 lattice elements
+RPO tracked 2 values available at 2 locations and 10 lattice elements
+Replaced MEM[(char *)&ar3 + -9223372036854775808B] with 1 in all uses of _2 =
MEM[(char *)&ar3 + -9223372036854775808B];
+Replaced (int) _2 with 1 in all uses of _3 = (int) _2;
+Removing dead stmt _3 = (int) _2;
+Removing dead stmt _2 = MEM[(char *)&ar3 + -9223372036854775808B];
 test_local_char_array ()
 {
   char * p;
   char ar3[3];
-  char _2;
-  int _3;
   char _5;
   int _6;

   <bb 2> :
   ar3 = "\x01\x02\x03";
-  _2 = MEM[(char *)&ar3 + -9223372036854775808B];
-  _3 = (int) _2;
-  sink (0, _3);
+  sink (0, 1);
   _5 = MEM[(char *)&ar3 + -1B];
   _6 = (int) _5;
   sink (0, _6);


Richard, can you imagine what could be the cause of this?  Didn't you fix
something similar relatively recently, e.g. an expression with side effects
that would depend on the order the C++ compiler chooses for them or something
along this line?

[Bug testsuite/90806] Warray-bounds-2.c fail on cross-aarch64 on RH6 host

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90806

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|6.4.1                       |11.0

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Since -9223372036854775808 is 0x8000000000000000 and ar3[0] == 1 it suggests
that the offset is somewhere truncated to 32bits ... but I can't reproduce
with a x86_64 to aarch64 cross and your reduced testcase for example.

It should probably go "wrong" here: (tree-ssa-sccvn.c:2828 and later):

  /* 3) Assignment from a constant.  We can use folds native encode/interpret
     routines to extract the assigned bits.  */
  else if (known_eq (ref->size, maxsize)
           && is_gimple_reg_type (vr->type)

which sees the def

  ar3 = "\x01\x02\x03";

for the ref

  _2 = MEM[(char *)&ar3 + -9223372036854775808B];

but adjust_offsets_for_equal_base_address fails for me because the LHS base
is not a MEM_REF (and get_ref_base_and_extend refuses to decompose the
MEM[(char *)&ar3 + -9223372036854775808B] base because the offset in bits
doesn't fit a HWI).

[Bug testsuite/90806] Warray-bounds-2.c fail on cross-aarch64 on RH6 host

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90806

--- Comment #10 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Since -9223372036854775808 is 0x8000000000000000 and ar3[0] == 1 it suggests
> that the offset is somewhere truncated to 32bits ... but I can't reproduce
> with a x86_64 to aarch64 cross and your reduced testcase for example.

I should have said that this is for a native x86-64/Linux GCC 10 compiler: if
you compile it with GCC 9 or with GCC 10, then the FRE1 pass behaves
differently

[Bug testsuite/90806] Warray-bounds-2.c fail on cross-aarch64 on RH6 host

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90806

--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 4 Jan 2021, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90806
> 
> --- Comment #10 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> > Since -9223372036854775808 is 0x8000000000000000 and ar3[0] == 1 it suggests
> > that the offset is somewhere truncated to 32bits ... but I can't reproduce
> > with a x86_64 to aarch64 cross and your reduced testcase for example.
> 
> I should have said that this is for a native x86-64/Linux GCC 10 compiler: if
> you compile it with GCC 9 or with GCC 10, then the FRE1 pass behaves
> differently

So you say that a not bootstrapped GCC 10 compiler compiled with
a recent host GCC 11 compiler folds to 1 while using a host GCC 10 (or 9)
compiler does not fold to 1?

My dev build of GCC 10 head (using GCC 7 as host compiler does not
fold to 1)

[Bug testsuite/90806] Warray-bounds-2.c fail on cross-aarch64 on RH6 host

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90806

--- Comment #12 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> So you say that a not bootstrapped GCC 10 compiler compiled with
> a recent host GCC 11 compiler folds to 1 while using a host GCC 10 (or 9)
> compiler does not fold to 1?

Sorry, I mixed things a little bit.  Here's a recipe: bootstrap the current 9
branch with the current 10 branch as base compiler and STAGE1_CFLAGS="-O -g".
Then, for the above reduced testcase, the FRE1 pass does not behave the same at
-O2 for the stage #1 and #2 (or #3) compilers:

--- t.c.033t.fre1.1     2021-01-05 10:32:31.381344944 +0100
+++ t.c.033t.fre1       2021-01-05 10:33:17.053197054 +0100
@@ -12,12 +12,16 @@
 {
   char * p;
   char ar3[3];
+  char _2;
+  int _3;
   char _5;
   int _6;

   <bb 2> :
   ar3 = "\x01\x02\x03";
-  sink (0, 1);
+  _2 = MEM[(char *)&ar3 + -9223372036854775808B];
+  _3 = (int) _2;
+  sink (0, _3);
   _5 = MEM[(char *)&ar3 + -1B];
   _6 = (int) _5;
   sink (0, _6);

I'm trying to find out whether I can reproduce with more recent compilers.

[Bug testsuite/90806] Warray-bounds-2.c fail on cross-aarch64 on RH6 host

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90806

--- Comment #13 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
The divergence appears to stem from get_ref_base_and_extent:

        case MEM_REF:
[...]
          /* Hand back the decl for MEM[&decl, off].  */
          if (TREE_CODE (TREE_OPERAND (exp, 0)) == ADDR_EXPR)
            {
              if (integer_zerop (TREE_OPERAND (exp, 1)))
                exp = TREE_OPERAND (TREE_OPERAND (exp, 0), 0);
              else
                {
                  poly_offset_int off = mem_ref_offset (exp);
                  off <<= LOG2_BITS_PER_UNIT;
                  off += bit_offset;
                  poly_int64 off_hwi;
                  if (off.to_shwi (&off_hwi))
                    {
                      bit_offset = off_hwi;
                      exp = TREE_OPERAND (TREE_OPERAND (exp, 0), 0);
                    }
                }
            }

628                       poly_offset_int off = mem_ref_offset (exp);
(gdb) p debug_generic_expr(exp)
MEM[(char *)&ar3 + -9223372036854775808B]

which yields on the one hand:

(gdb) p off
$60 = {<poly_int_pod<1, generic_wide_int<fixed_wide_int_storage<128> > >> = {
    coeffs = {{<fixed_wide_int_storage<128>> = {val = {-9223372036854775808, 
            140737332966384, 140733193388032}, len = 1}, 
        static is_sign_extended = true}}}, <No data fields>}

and on the other hand:

(gdb) p off
$25 = {<poly_int_pod<1, generic_wide_int<fixed_wide_int_storage<128> > >> = {
    coeffs = {{<fixed_wide_int_storage<128>> = {val = {-9223372036854775808, 
            8097070, -9223372036854775808}, len = 1}, 
        static is_sign_extended = true}}}, <No data fields>}

Then
          off <<= LOG2_BITS_PER_UNIT;

yields on the one hand:

(gdb) p off
$67 = {<poly_int_pod<1, generic_wide_int<fixed_wide_int_storage<128> > >> = {
    coeffs = {{<fixed_wide_int_storage<128>> = {val = {0, -4, 
            140737488342640}, len = 2}, 
        static is_sign_extended = true}}}, <No data fields>}

and on the other hand:

$36 = {<poly_int_pod<1, generic_wide_int<fixed_wide_int_storage<128> > >> = {
    coeffs = {{<fixed_wide_int_storage<128>> = {val = {0, 824633720995, 
            140737334083072}, len = 1}, 
        static is_sign_extended = true}}}, <No data fields>}

The latter passes the off.to_shwi test whereas the former does not.

[Bug testsuite/90806] Warray-bounds-2.c fail on cross-aarch64 on RH6 host

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90806

--- Comment #14 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
The fast path in wi::lshift looks suspicious to me:

      /* For fixed-precision integers like offset_int and widest_int,
         handle the case where the shift value is constant and the
         result is a single nonnegative HWI (meaning that we don't
         need to worry about val[1]).  This is particularly common
         for converting a byte count to a bit count.

         For variable-precision integers like wide_int, handle HWI
         and sub-HWI integers inline.  */
      if (STATIC_CONSTANT_P (xi.precision > HOST_BITS_PER_WIDE_INT)
          ? (STATIC_CONSTANT_P (shift < HOST_BITS_PER_WIDE_INT - 1)
             && xi.len == 1
             && xi.val[0] <= (HOST_WIDE_INT) ((unsigned HOST_WIDE_INT)
                                              HOST_WIDE_INT_MAX >> shift))
          : precision <= HOST_BITS_PER_WIDE_INT)
        {
          val[0] = xi.ulow () << shift;
          result.set_len (1);
        }
      else
        result.set_len (lshift_large (val, xi.val, xi.len,
                                      precision, shift));

and indeed this was fixed in GCC 10 by:

2019-07-10  Marc Glisse  <marc.glisse@inria.fr>

        * wide-int.h (wi::lshift): Reject negative values for the fast path.

[Bug testsuite/90806] Warray-bounds-2.c fail on cross-aarch64 on RH6 host

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90806

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Eric Botcazou from comment #13)
> The divergence appears to stem from get_ref_base_and_extent:
> 
> 	case MEM_REF:
> [...]
> 	  /* Hand back the decl for MEM[&decl, off].  */
> 	  if (TREE_CODE (TREE_OPERAND (exp, 0)) == ADDR_EXPR)
> 	    {
> 	      if (integer_zerop (TREE_OPERAND (exp, 1)))
> 		exp = TREE_OPERAND (TREE_OPERAND (exp, 0), 0);
> 	      else
> 		{
> 		  poly_offset_int off = mem_ref_offset (exp);
> 		  off <<= LOG2_BITS_PER_UNIT;
> 		  off += bit_offset;
> 		  poly_int64 off_hwi;
> 		  if (off.to_shwi (&off_hwi))
> 		    {
> 		      bit_offset = off_hwi;
> 		      exp = TREE_OPERAND (TREE_OPERAND (exp, 0), 0);
> 		    }
> 		}
> 	    }
> 
> 628                       poly_offset_int off = mem_ref_offset (exp);
> (gdb) p debug_generic_expr(exp)
> MEM[(char *)&ar3 + -9223372036854775808B]
> 
> which yields on the one hand:
> 
> (gdb) p off
> $60 = {<poly_int_pod<1, generic_wide_int<fixed_wide_int_storage<128> > >> = {
>     coeffs = {{<fixed_wide_int_storage<128>> = {val = {-9223372036854775808, 
>             140737332966384, 140733193388032}, len = 1}, 
>         static is_sign_extended = true}}}, <No data fields>}
> 
> and on the other hand:
> 
> (gdb) p off
> $25 = {<poly_int_pod<1, generic_wide_int<fixed_wide_int_storage<128> > >> = {
>     coeffs = {{<fixed_wide_int_storage<128>> = {val = {-9223372036854775808, 
>             8097070, -9223372036854775808}, len = 1}, 
>         static is_sign_extended = true}}}, <No data fields>}

Note that's identical data (only val[] up to len - 1 is relevant data).

> Then
> 	  off <<= LOG2_BITS_PER_UNIT;
> 
> yields on the one hand:
> 
> (gdb) p off
> $67 = {<poly_int_pod<1, generic_wide_int<fixed_wide_int_storage<128> > >> = {
>     coeffs = {{<fixed_wide_int_storage<128>> = {val = {0, -4, 
>             140737488342640}, len = 2}, 
>         static is_sign_extended = true}}}, <No data fields>}
> 
> and on the other hand:
> 
> $36 = {<poly_int_pod<1, generic_wide_int<fixed_wide_int_storage<128> > >> = {
>     coeffs = {{<fixed_wide_int_storage<128>> = {val = {0, 824633720995, 
>             140737334083072}, len = 1}, 
>         static is_sign_extended = true}}}, <No data fields>}

the first result is a large zero-extended value (len == 2) while the
second is simply zero.

I suppose we might run into the issue that left-shift of negative
values is undefined?  Thus the "optimization" to replace the
multiplication by BITS_PER_UNIT by a seemingly more cheap left-shift
fires back.

So, does changing the code to

                 off *= BITS_PER_UNIT;

fix the issue?

> The latter passes the off.to_shwi test whereas the former does not.

[Bug testsuite/90806] Warray-bounds-2.c fail on cross-aarch64 on RH6 host

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90806

--- Comment #16 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Richard, any objection to me backporting Marc's fixlet?
  https://gcc.gnu.org/pipermail/gcc-patches/2019-July/525651.html

[Bug testsuite/90806] Warray-bounds-2.c fail on cross-aarch64 on RH6 host

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90806

--- Comment #17 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 6 Jan 2021, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90806
> 
> --- Comment #16 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Richard, any objection to me backporting Marc's fixlet?
>   https://gcc.gnu.org/pipermail/gcc-patches/2019-July/525651.html

It's fine to backport the actual commit.

[Bug testsuite/90806] Warray-bounds-2.c fail on cross-aarch64 on RH6 host

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90806

--- Comment #18 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Eric Botcazou
<ebotcazou@gcc.gnu.org>:

https://gcc.gnu.org/g:9c7a3bf73df4581c8ea9a4db507c290524e91cd5

commit r9-9154-g9c7a3bf73df4581c8ea9a4db507c290524e91cd5
Author: Eric Botcazou <ebotcazou@adacore.com>
Date:   Wed Jan 6 12:06:41 2021 +0100

    Fix PR testsuite/90806 on the 9 branch

    gcc/ChangeLog:
            PR testsuite/90806
            Backport from mainline
                2019-07-10  Marc Glisse  <marc.glisse@inria.fr>

            * wide-int.h (wi::lshift): Reject negative values for the fast
path.

[Bug testsuite/90806] Warray-bounds-2.c fail on cross-aarch64 on RH6 host

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90806

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
   Target Milestone|---                         |9.4
             Status|NEW                         |RESOLVED

--- Comment #19 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Fixed in 9.4 and higher versions.