On 06/13/2018 02:45 PM, Joseph Myers wrote:
This patch (commit r261518) has broken the build of the glibc testsuite.
I see, for example for aarch64-linux-gnu with build-many-glibcs.py:

In function 'test_strncat',
    inlined from 'main' at tester.c:1621:3:
tester.c:490:13: error: 'strncat' accessing 18446744073709551600 or more bytes 
at offsets 0 and 0 overlaps 9223372036854775793 bytes at offset 
-9223372036854775793 [-Werror=restrict]
      check (strncat (buf1 + n2, buf2 + n1, ~((size_t) 0) - n4)
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

The code in question already has -Wstringop-overflow= and -Warray-bounds
warnings disabled as it's deliberately testing a large size.  But a
-Wrestrict warning makes no sense to me at all here.  The arguments are
based on two different variables, buf1 and buf2, and regardless of sizes
and offsets I wouldn't expect a -Wrestrict warning when the arguments are
based on different array variables like that.

I couldn't readily reproduce the warning with the Glibc test
but I think it triggers for the same reason as the one below:

  extern char a[16], b[16];

  void f (void)
  {
    __builtin_strncat (a, b, __SIZE_MAX__ - 16);
  }

  In function ‘f’:
warning: ‘__builtin_strncat’ accessing 18446744073709551599 or more bytes at offsets 0 and 0 overlaps 9223372036854775792 bytes at offset -9223372036854775792 [-Wrestrict]

There's logic in -Wrestrict that tries to determine the sizes
even distinct objects would need to have in order for an access
to them of a given kind not to overlap.  (This code starts on
line 1209 in gimple-ssa-warn-restrict.c.)    This is probably
unnecessary when the objects sizes are known (and may even be
redundant when they aren't in some cases since other warnings
might catch that).  Then again, the test does some bad things
so it's not surprising (or necessarily bad) that they get
caught by multiple checkers.

What could stand to be improved is the diagnostic.  Some of
the offsets in it don't look very meaningful (they may not
be wrong, but they don't help the user make sense out of
the warning).

Martin

Reply via email to