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 AA8A93858D38; Mon, 25 Mar 2024 13:57:32 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AA8A93858D38
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1711375052;
	bh=e+AILnkS85UkKbcW1M0dvqQLk8HVmK1xRtbHhYwDsoI=;
	h=From:To:Subject:Date:From;
	b=E+fEph4DVeh3rD1rQVzcb8gYTIp+3kroWh1S7TXrTaQqLm159RsVuOhHje8eH0WxA
	 D8IKYnhQhYqx8gjynoDbgKGu42io2VZ02puY4fuV2ifI3jHYlqbJBytojz2EC8X9xf
	 L8Ykm5LoRJ4llSIz8R1SZz06WBxpxh3RaM4tH088=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/114469] New: gcc.dg/torture/bitint-64.c
 failure with -O2 -flto -std=c23 -fwrapv
Date: Mon, 25 Mar 2024 13:57:32 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-114469-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=3D114469

            Bug ID: 114469
           Summary: gcc.dg/torture/bitint-64.c failure with -O2 -flto
                    -std=3Dc23 -fwrapv
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

This test fails with
make check-gcc GCC_TEST_RUN_EXPENSIVE=3D1
RUNTESTFLAGS=3D"dg-torture.exp=3Dbitint-64.c"
FAIL: gcc.dg/torture/bitint-64.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
The question is if _Atomic _BitInt(5) should be in memory always sign exten=
ded,
or as the ABI says the upper bits are unspecified.
If the former, then I'd say the problem is on the
/* Strip inner integral conversions that do not change precision or size, or
   zero-extend while keeping the same size (for bool-to-char).  */
(simplify
  (view_convert (convert@0 @1))
  (if ((INTEGRAL_TYPE_P (TREE_TYPE (@0)) || POINTER_TYPE_P (TREE_TYPE (@0)))
       && (INTEGRAL_TYPE_P (TREE_TYPE (@1)) || POINTER_TYPE_P (TREE_TYPE (@=
1)))
       && TYPE_SIZE (TREE_TYPE (@0)) =3D=3D TYPE_SIZE (TREE_TYPE (@1))
       && (TYPE_PRECISION (TREE_TYPE (@0)) =3D=3D TYPE_PRECISION (TREE_TYPE=
 (@1))
           || (TYPE_PRECISION (TREE_TYPE (@0)) > TYPE_PRECISION (TREE_TYPE
(@1))
               && TYPE_UNSIGNED (TREE_TYPE (@1)))))
   (view_convert @1)))
match.pd simplification which transforms
  _5 =3D (unsigned _BitInt(5)) _4;
  _7 =3D (unsigned _BitInt(5)) e.0_1;
  _8 =3D _5 + _7;
  _9 =3D (_BitInt(5)) _8;
  _10 =3D VIEW_CONVERT_EXPR<unsigned char>(_9);
to just
  _5 =3D (unsigned _BitInt(5)) _4;
  _7 =3D (unsigned _BitInt(5)) e.0_1;
  _8 =3D _5 + _7;
  _10 =3D VIEW_CONVERT_EXPR<unsigned char>(_8);
so it is no longer sign extended in the unsigned char.
If the upper bits are undefined as the psABI on x86 says, then perhaps the
VIEW_CONVERT_EXPR emitted by c-common.cc (resolve_overloaded_builtin) is the
culprit:
      _13 =3D __atomic_load_1 (&b, 5);
      _14 =3D VIEW_CONVERT_EXPR<_BitInt(5)>(_13);
and we should change that
            /* Cast function result from I{1,2,4,8,16} to the required type=
.=20
*/
            result =3D build1 (VIEW_CONVERT_EXPR, TREE_TYPE (new_return),
result);
to something like if (INTEGRAL_TYPE_P (TREE_TYPE (new_return))IINTEGRAL_TYP=
E_P
(TREE_TYPE (new_return))NTEGRAL_TYPE_P (TREE_TYPE (new_return)))
            if (INTEGRAL_TYPE_P (TREE_TYPE (new_return)))
              result =3D fold_convert (TREE_TYPE (new_return), result);
            else
              result =3D build1 (VIEW_CONVERT_EXPR, TREE_TYPE (new_return),
result);
Joseph, thoughts on this?=