Ping: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00076.html

On 02/01/2018 04:45 PM, Martin Sebor wrote:
The previous patch didn't resolve all the false positives
in the Linux kernel.  The attached is an update that fixes
the remaining one having to do with multidimensional array
members:

  struct S { char a[2][4]; };

  void f (struct S *p, int i)
  {
    strcpy (p->a[0], "012");
    strcpy (p->a[i] + 1, p->a[0]);   // false positive here
  }

In the process of fixing this I also made a couple of minor
restructuring changes to the builtin_memref constructor to
in order to make the code easier to follow: I broke it out
into a couple of helper functions and called those.

As with the first revision of the patch, this one is also
meant to be applied on top of

  https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01488.html

Sorry about the late churn.  Even though I tested the original
implementation with the Linux kernel the bugs were only exposed
non-default configurations that I didn't build.

Jakub, you had concerns about the code in the constructor
and about interpreting the offsets in the diagnostics.
I tried to address those in the patch.  Please review
the changes and let me know if you have any further comments.

Thanks
Martin

On 01/30/2018 04:19 PM, Martin Sebor wrote:
Testing GCC 8 with recent Linux kernel sources has uncovered
a bug in the handling of arrays of arrays by the -Wrestrict
checker where it fails to take references to different array
elements into consideration, issuing false positives.

The attached patch corrects this mistake.

In addition, to make warnings involving excessive offset bounds
more meaningful (less confusing), I've made a cosmetic change
to constrain them to the bounds of the accessed object.  I've
done this in response to multiple comments indicating that
the warnings are hard to interpret.  This change is meant to
be applied on top of the patch for bug 83698 (submitted mainly
to improve the readability of the offsets):

  https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01488.html

Martin


Reply via email to