[PATCH] False-positive -Warray-bounds for char[1] on a non-zero offset in a referenced buffer

[Martin Sebor]

On 5/6/20 4:35 PM, Joey Liu via Gcc-patches wrote:
> Hi all,
> 
> I think the assumption in builtin_memref::set_base_and_offset
> (gimple-ssa-warn-restrict.c) is not correct. It seems multiple levels of
> indirection may confuse gcc. When it loses the reference to the original
> buffer (e.g.the buffer is allocated by one of the parent class but it's
> used by a different parent class), the subsequent tree::component_ref_size
> will just return NULL_TREE.

It's best to open a bug in Bugzilla first and only submit a patch if
the bug is acknowledged (or at least not disputed).

> 
> In that case, the refsize will remain as 0 incorrectly set by the code
> below (set_base_and_offset). The problem is unique for char[1]. For the
> char array with more than 1 elements, the size of the domain is always
> returned.
> 
> In builtin_memref::set_base_and_offset (gimple-ssa-warn-restrict.c)
> -
> -      if (!integer_zerop (memrefoff))
> -       /* A non-zero offset into an array of struct with flexible array
> -          members implies that the array is empty because there is no
> -          way to initialize such a member when it belongs to an array.
> -          This must be some sort of a bug.  */
> -       refsize = 0;
> 
> I've attached the patch with the test case and I'd suggest removal of the
> code block here. It seems to me it's ok for non-zero offset here.

The code above is tested by gcc.dg/Warray-bounds-46.c which fails
a number of cases when the patch is applied.

I tend to agree the warning for the test case is a false positive:
the strncpy call writes 1 byte to a 1-character buffer which is
safe.  The comment also talks about flexible arrays but there is
none in the test case).

But I'm not convinced that removing the hunk is the right way to
fix the bug: it just trades false negatives for false positives.
I suggest you open a bug for this in Bugzilla and take it from
there.

Martin