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
