On Wed, 2020-04-22 at 09:36 -0600, Martin Sebor via Gcc-patches wrote: > On 4/22/20 7:28 AM, Christophe Lyon wrote: > > On Tue, 21 Apr 2020 at 11:07, Richard Biener via Gcc-patches > > <gcc-patches@gcc.gnu.org> wrote: > > > On Mon, Apr 20, 2020 at 11:29 PM Martin Sebor via Gcc-patches > > > <gcc-patches@gcc.gnu.org> wrote: > > > > The restrict pass computes the wrong lower bound of the size > > > > of accesses to member arrays passed to strncpy as the source: > > > > it uses the third argument to the function even though the size > > > > of the read is limited by the length of the source when it is > > > > a string. This results in false positive -Warray-bounds > > > > warnings in such cases. > > > > > > > > The attached patch corrects this bug. In addition, it adjusts > > > > the range of offsets of the overlap printed in diagnostics to > > > > be in an increasing order (i.e., [LOW, HIGH]), and removes > > > > a hack was in place to adjust the offsets that's obviated by > > > > the fix above. > > > > > > > > Tested on x86_64-linux. > > > > Hi, > > > > The update of Warray-bounds-2.c fails on 32 bits targets: > > /gcc/testsuite/c-c++-common/Warray-bounds-2.c:192:3: warning: > > 'strncpy' pointer overflow between offset 2147483647 and size [1, 0] > > [-Warray-bounds] > > because the uppper limit is hardcoded in the testcase with the 64-bits > > value. Can you adjust it? > > Done. I was going to suggest the (x|y|z) syntax to be a little tighter on what we accept on the 16, 32 and 64bit targets (I was in the middle of building appropriate toolchains to verify the change). But your solution is fine as well. Thanks for taking care of it.
Jeff
