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 EEF213858C78; Wed,  7 Feb 2024 20:24:50 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EEF213858C78
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1707337490;
	bh=VnBHiJXCxIIzWeLpu5riVXp05MrRGgY99cp9oIpW/NE=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=ujNWZVHJ1HrwMi5F/uTWu4ViJ/m1pF/NNPallWKxpkIPpzpK0R9oIomsEy+cjAhER
	 eh4Qhdd2Pa5j0Nep4FWpRVZHgBZuAPJ71WKfdqL1aFFhHlt3FAKOoiFZ+71HRKDNHJ
	 XzWwQrtZ4wGYkXPh9wDwCcQRN4ATv0TIGpkvqfEg=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/113774] wrong code with _BitInt() arithmetics
 at -O2
Date: Wed, 07 Feb 2024 20:24:45 +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: 14.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub 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: 
Message-ID: <bug-113774-4-xR6dCDRyZ5@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-113774-4@http.gcc.gnu.org/bugzilla/>
References: <bug-113774-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=3D113774

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
unsigned long long a[32], b[32], v[32], r[32];

void
foo (unsigned int n)
{
  unsigned long long c =3D 0;
  for (unsigned long i =3D 0; i < n; i +=3D 2)
    {
      unsigned long j =3D i + 1;
      b[i] =3D __builtin_addcll (b[i], v[i], c, &c);
      b[j] =3D __builtin_addcll (b[j], v[j], c, &c);
    }
  b[4] =3D __builtin_addcll (b[4] & 1, v[4] & 1, c, &c) & 1;
  c =3D 0;
  for (unsigned long i =3D 0; i < n; i +=3D 2)
    {
      unsigned long j =3D i + 1;
      unsigned long long k =3D i < 3 ? a[i] : 0;
      r[i] =3D b[i] | __builtin_subcll (k, b[i], c, &c);
      unsigned long long l =3D b[j];
      if (j <=3D 3)
        {
          if (j =3D=3D 3)
            k =3D a[3] & 0x7fffffffffffffffULL;
          else
            k =3D a[3];
        }
      else
        k =3D 0;
      r[j] =3D l | __builtin_subcll (k, b[j], c, &c);
    }
  r[4] =3D (b[4] | __builtin_subcll (0, b[4] & 1, c, &c)) & 1;
}

might help understand better what bitintlower emits there, except it uses
PARM_DECLs or automatic VAR_DECLs instead of the global ones (except for v)=
 and
n is 4 (I've used function argument only to avoid VRP figuring out earlier =
that
certain paths are dead) and the var sizes is actually just 4 (for a) or 5 e=
lts.
That said, even _134 in the #c2 testcase at -O2 in the PHI argument is fish=
y,
but the
point is that bb 6 is really dead but it isn't known to the compiler yet; i=
t is
reached if _49 <=3D 2 is false, but given that _49 is incremented in increm=
ents
of 2 and the array size is 5 maybe PRE knows that _49 then would have to be=
 4.
bb 6 either jumps directly to bb 10 (if _140 (aka _49 + 1) > 3) or hops thr=
ough
bb 8 to bb 10.=