Re: [r12-4725 Regression] FAIL: libgomp.c/doacross-1.c (test for excess errors) on Linux/x86_64

[Martin Sebor <msebor@gmail.com>]

On 10/27/21 7:30 AM, Jakub Jelinek wrote:
> On Tue, Oct 26, 2021 at 10:22:19PM -0700, sunil.k.pandey via Gcc-patches wrote:
>> FAIL: libgomp.c/doacross-1.c (test for excess errors)

I don't see this failure in my logs (or the other one) or any
evidence of the libhomp tests having run.  Does the libgomp
test suite need something special to enable?

> 
> At least this one is a clear false positive.
> int a[256];
> ...
>      #pragma omp for schedule(static, 1) ordered (1) nowait
>      for (i = 0; i < 256; i++)
>        {
>          #pragma omp atomic write
>          a[i] = 1;
>          #pragma omp ordered depend(sink: i - 1)
>          if (i)
>            {
>              #pragma omp atomic read
>              l = a[i - 1];		// <-------- Here is the false positive warning: '__atomic_load_4' writing 4 bytes into a region of size 0 overflows the destination [-Wstring-overflow=]
> 					// note: at offset [-8589934592, -8] into destination object ‘a’ of size 1024
>              if (l < 2)
>                abort ();
>            }
> The loop iterates i from 0 to 255 and the if body is guarded with i != 0,
> so __atomic_load_4 (&a[i - 1].
> Due to the doacross loop vrp doesn't know that the loop iterates from 0 to
> 256, because different threads are given just some subset of that interval,
> so it is effectively VARYING.

The warning is in the IL below:

   <bb 167> [local count: 30]:
   _865 = ivtmp.273_871 + 4294967294;
   _923 = (int) _865;
   _308 = (sizetype) _923;
   _707 = _308 * 4;
   _924 = &a + _707;
   _926 = __atomic_load_4 (_924, 0);

The code calls range_of_expr (vr, val, stmt) where val is _707
and stmt is the assignment _924 = &a + _707.  The result is
the VR_RANGE [-8589934592, -8].  The code is in get_range() in
tree-ssa-strlen.c of all places.  The warning uses the range
as is, treating it as signed.  The debug_ranger() output for
the block is below.  Am I missing something here?

=========== BB 167 ============
Imports: _926
Exports: _926  l.0_927
          l.0_927 : _926(I)
_243	int VARYING
ivtmp.272_874	unsigned int [2147483648, +INF]
Relational : (_865 != ivtmp.273_871)
     <bb 167> [local count: 30]:
     _865 = ivtmp.273_871 + 4294967294;
     _923 = (int) _865;
     _308 = (sizetype) _923;
     _707 = _308 * 4;
     _924 = &a + _707;
     _926 = __atomic_load_4 (_924, 0);
     l.0_927 = (int) _926;
     if (l.0_927 <= 1)
       goto <bb 13>; [0.00%]
     else
       goto <bb 166>; [100.00%]

_308 : sizetype [18446744071562067968, 18446744073709551614]
_707 : sizetype [18446744065119617024, 18446744073709551608]
_923 : int [-INF, -2]
_924 : int * [1B, +INF]
167->13  (T) _926 : 	unsigned int [0, 1][2147483648, +INF]
167->13  (T) l.0_927 : 	int [-INF, 1]
167->166  (F) _926 : 	unsigned int [2, 2147483647]
167->166  (F) l.0_927 : 	int [2, +INF]

Martin

> Perhaps it derives some quite useless range
> from the i - 1 or i + 1 expressions on signed integer, but that doesn't mean
> the warnings should assume the value is likely to be out of bounds.
> And there is no warning on the a[i] either (which is also in bounds, but
> if for the atomic load the warning code thinks i - 1 can be in
> [-8589934592, -8] range, why doesn't it think that i can be in
> [-8589934588, -4] range?
> 
> 	Jakub
>