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 65F673858414; Mon, 20 Mar 2023 10:58:20 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 65F673858414
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1679309900;
	bh=l9ESeWmiuihMBMABOjGzI3S9HHzPPUYY7+/KFPtX7Gg=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=aDIobkPWW94angAxocXoIkuYordfR6V4j2BZVfC5WamXoA/04GxXupbRPHNpEEFkQ
	 nsLFgT8+feTQr02rrN3JqI7hppJLFJHWXvYWmgaDH3hlrZpkl8iRDkJAuMXkwH7Hud
	 2odgkZEfiM/sFT/AzujTWkoeiU+n6nV+suoPLPBU=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/109184] [10/11/12/13 Regression] csmith: 2017
 bug with -floop-interchange
Date: Mon, 20 Mar 2023 10:58:19 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 10.5
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-109184-4-PpExBeJr00@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-109184-4@http.gcc.gnu.org/bugzilla/>
References: <bug-109184-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=3D109184

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #6)
> Confirmed with -O2 -floop-interchange.  There's just a single interchange
> done:
>=20
> runData/keep/in.713.c:648:32: optimized: loops interchanged in loop nest
>=20
> that's in func_2 for the nest
>=20
>         for (g_149 =3D 0; (g_149 > (-15)); g_149--)
>         {
>             for (l_1719 =3D 4; (l_1719 >=3D 1); l_1719 -=3D 1)
>             {
>                 for (l_1721 =3D 0; (l_1721 >=3D 0); l_1721 -=3D 1)
>                 {
>                     struct S1 l_1935 =3D {0x13186D76L,0xC9L,36,24,1L,0x87=
L};
>                     for (g_1179 =3D 0; (g_1179 <=3D 4); g_1179 +=3D 1)
>                     {
>                         int32_t l_1942 =3D (-3L);
>                         int32_t *****l_1947 =3D &l_1946[0][6];
>                         int i, j;
>                         l_1942 ^=3D ((safe_add_func_uint64_t_u_u((l_1935 ,
> (((l_1936[1] !=3D (void*)0) < (*g_511)) & (g_1731[(l_1719 + 1)][l_1721] &=
=3D
> (((0x943C8AB0L | 0xE398A931L) !=3D g_20) , (0x26L &
> (safe_add_func_uint64_t_u_u((--l_1930[g_1179]), 0xFC07342370A5FE25LL)))))=
)),
> 4L)) <=3D p_5.f0);
>                         l_1943[0][1][1]++;
>                         l_1949 =3D (((*l_1947) =3D l_1946[0][6]) =3D=3D g=
_1948);
>                     }
>                 }
>             }
>         }

And we are interchanging the outer two loops.  Since the outer loop IV isn't
used in the body it doesn't change anything data dep wise?

Interchanging the loops in the source reproduces the issue, so somehow
for the only use of l_1719

(g_1731[(l_1719 + 1)][l_1721] &=3D (((0x943C8AB0L | 0xE398A931L) !=3D g_20)=
 ,
(0x26L & (safe_add_func_uint64_t_u_u((--l_1930[g_1179]),
0xFC07342370A5FE25LL)))))

it makes a difference.  It's

  g_1731[(l_1719 + 1)][l_1721] &=3D val;

the order we & values into it shouldn't matter.  But it's so much obfuscated
code ...=