[PATCH] avoid warning on vectorized past-the-end stores (PR 93200)

[Martin Sebor]

On 1/9/20 9:24 PM, Jeff Law wrote:
> On Wed, 2020-01-08 at 17:23 +0000, Martin Sebor wrote:
>> A recent improvement to the vectorizer (r278334 if my bisection
>> is right) can transform multiple stores to adjacent struct members
>> into single vectorized assignments that write over all the members
>> in a single MEM_REF.  These are then flagged by -Wstringop-overflow
>> thanks to its also recently enhanced past-the-end store detection.
>> The warnings have been causing failures in some of Jeff's periodic
>> builds (e.g., in cjdns-v20.4).
>>
>> Reliably distinguishing these transformed, multi-member, MEM_REF
>> stores from accidental bugs the warning is designed to detect will
>> require annotating them somehow at the time they are introduced.
>> Until that happens, the attached patch simply tweaks the logic that
>> determines the size of the destination objects to punt on these
>> vectorized MEM_REFs.
> I thought we had other code which could combine stores into consecutive
> memory locations that might run afoul of this warning as well.  But I
> can't seem to find that code -- we may well have throttled it a while
> back because of data store races.

The only other case I can think of is stores into consecutive array
elements.  Those can get merged into MEM_REF <T> where T is either
a bigger scalar type than the array element type or an array of such
a type (or, apparently only at -O3, a vector).  But (AFAIK) those
are handled correctly (both by the strlen pass and by compute_objsize
and the warning).  For example this:

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

   void f (void)
   {
     s.a[0] = '1'; s.a[1] = '2'; s.a[2] = '2'; s.a[3] = 0;
   }

at -O2 results in:

   MEM <unsigned int> [(char *)&s] = 3289649;

and at -O3 in:

   MEM <vector(4) char> [(char *)&s] = { 49, 50, 50, 0 };

(For reasons I don't yet understand it doesn't happen when the struct
object is local to the function or referenced by a pointer passed to
the function.)

What I hadn't seen or anticipate is the merging of stores into
distinct members.

It's possible that some valid cases involving unions could trigger
warnings.  I haven't seen GCC introduce such transformations for
"clean" code but as I said above, I will look into avoiding warnings
for such code if/when I come across it.  Other than that, I'm not
concerned about issuing warnings for user code that abuses unions
to get around the type system.  Authors of code that skirts
the rules or good practices need to be prepared to deal with
warnings.

Martin

> 
> OK.  Thanks for taking care of this so quickly.
> 
> jeff
> 
>