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

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.

Martin

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.

OK.  Thanks for taking care of this so quickly.

jeff

On Wed, Jan 08, 2020 at 09:24:48PM -0700, 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.

E.g. store-merging does that, but that runs fairly late.
And as it is mentioned in other PRs, if the warning code determines anything
e.g. from pointers used in MEM_REFs, then any kind of value numbering can cause
that, as for pointers the optimizers only care about the value and not
access path.  So all those cases e.g. with union where we access one union
member at one point and another one later in the same function and the two
pointers through which the access is made have the same value.

	Jakub

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
> 
>