From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 30E4B385C335; Thu, 25 Aug 2022 08:28:34 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 30E4B385C335
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1661416114;
	bh=3SZh9xF7QrRj2xAy6w/eccF9k9sU+Tu7q4NkdrV4Plk=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=xIZV1pbsiRAa+bedh9vmWLQp2rR9njxQ6GKLowX4NAsDUFQ+bB1lYPJUx0Yw5DoEF
	 yHZLR2rFdv/DZuhqw6yg0Mz2SsPVWhrkTYxhFlSQosyzfJgJelqCD8JqdUuUVsFIh6
	 Sj+hTspDTyx11yTq4PqZKKFmOkcWwgtaqRFiJgzI=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/102316] Unexpected stringop-overflow Warnings on
 POWER CPU
Date: Thu, 25 Aug 2022 08:28:33 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 11.2.1
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: everconfirmed bug_status cf_reconfirmed_on
Message-ID: <bug-102316-4-Iuvj8PWoYb@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-102316-4@http.gcc.gnu.org/bugzilla/>
References: <bug-102316-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102316

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-08-25

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to HaoChen Gui from comment #4)
> #define LEN 4
>=20
> struct {
>   char c[LEN]
> } d;
>=20
> extern int a;
> extern char* b;
>=20
> int p() {
>   for (int i =3D 0; i < a; i++) {
>     d.c[i] =3D b[i];
>   }
>   return 0;
> }
>=20
> Above codes cause the same errors on x86. When setting the LEN to 8, it c=
an
> be also reproduced on aarch64. It's a common problem.
>=20
> The iteration number of reset loop after vectorization should not only
> decided by variable "a" but also by the length of array. If the len is 5 =
and
> vector size is 4, the reset loop should be only executed once. Currently
> iteration number only depends on variable "a". Then it is complete unroll=
ed
> 3 times if vector size is 4. That causes the warning.
>=20
>   <bb 17> [local count: 398179264]:
>   # i_30 =3D PHI <i_36(18), tmp.9_40(20)>
>   _32 =3D (sizetype) i_30;
>   _33 =3D b.0_1 + _32;
>   _34 =3D *_33;
>   d.c[i_30] =3D _34;
>   i_36 =3D i_30 + 1;
>    if (i_36 < a.1_13)  // iterations depend on "a" only, the length of ar=
ray
> is not take into consideration
>     goto <bb 18>; [89.00%]
>   else
>     goto <bb 19>; [11.00%]

It does take this into account when unrolling.  The issue is - at least for
the vectorized epilogue - that when we set the iteration bound based on
the VF we do not factor in the iteration bound of the scalar loop when we
know the vector loop is iterating at least once.  That's something we could
improve.

The real issue is of course that the diagnostic code is too trigger-happy
and the unroll code is prone to leaving one not executable iteration (part)=
.=