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


Reply via email to