On 11/5/19 5:00 PM, Martin Sebor wrote:
> After considering more instances of the enhanced -Warray-bounds
> and the new -Wzero-length-array-bounds warnings I realized that
> there are some where the former is being issued for zero-length
> arrays but where the latter would be more appropriate.
>
> The attached change tweaks the logic in component_ref_size to
> have some of the latter instances replace some of the former,
> effectively relaxing -Warray-bounds a bit.
>
> -Wzero-length-array-bounds triggers for accesses to zero-length
> arrays with non-negative indices, interior or otherwise, that
> are within the bounds of the largest enclosing object. All other
> accesses are diagnosed via -Warray-bounds.
>
> The change replaces all instances of -Warray-bounds in Glibc with
> -Wzero-length-array-bounds. In the kernel, it similarly turns
> the vast majority of distinct -Warray-bounds warnings (56) into
> -Wzero-length-array-bounds, leaving only four -Warray-bounds.
>
> This should make adopting GCC 10 much easier for low-level code
> that relies on dangerous "tricks" involving zero-length arrays
> without sacrificing the ability to detect bugs in other projects.
>
> While making the change I also removed an incorrect assumption
> I introduced last week that was causing an ICE (as reported in
> PR 92373).
>
> Tested on x86_64-linux.
>
> Martin
>
> gcc-92373.diff
>
> PR tree-optimization/92373 - ICE in -Warray-bounds on access to member array
> in an initialized char buffer
>
> gcc/testsuite/ChangeLog:
>
> PR tree-optimization/92373
> * gcc.dg/Warray-bounds-55.c: New test.
> * gcc.dg/Wzero-length-array-bounds-2.c: New test.
>
> gcc/ChangeLog:
>
> PR tree-optimization/92373
> * tree.c (component_ref_size): Only consider initializers of objects
> of matching struct types.
> Return null for for instances of interior zero-length arrays.
OK
jeff