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 E576D3858D34; Wed, 17 Jul 2024 03:33:44 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E576D3858D34
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1721187224;
	bh=ut0wxTyJE7bZy9ICafogOsbvguraTa5GACclbgUaml8=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=hN84oDN2V15m77F7LF8LKUa0cthdbQdekAMxvzOhZa/UiOt8toRz/F+5c5Nz1uoRb
	 L/y8XAGTljI6q6JQHiw8zWZdyuKvcVZTJNXP61iK0jeHoTIB8hLsok2IF9EMQ/fmMK
	 Z1Tk60L/b9TUVFOahWqWzN9yE7OgpqqHkIkDJ6pc=
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/115961] [15 Regression] wrong code on llvm-18.1.8
 since r15-1936-g80e446e829d818 with bitfields less than the type mode
 precision
Date: Wed, 17 Jul 2024 03:33:44 +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: 15.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia 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: 15.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-115961-4-aNx2FYXBeO@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-115961-4@http.gcc.gnu.org/bugzilla/>
References: <bug-115961-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=3D115961

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Li Pan from comment #3)
> Only x86 implemented the .SAT_TRUNC for scalar, so I bet it is almost the
> same as this https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D115863 ?

No it is a different issue.

here we have a uint:4; an unsigned integer with 4 bit precision which is not
the same precision as QImode (8bit).

Since the optabs are only mode, we only check the mode of the type which is
QImode but the type has a lower precision than the mode itself.
So we get a SAT_TRUNC which is using the QImode sat_truncate opcode but we
really need 4bit sat_truncate.

This is why I mentioned there is a missing check for type_has_mode_precisio=
n_p
here.

type_has_mode_precision_p is defined as:
```
inline bool
type_has_mode_precision_p (const_tree t)
{
  return known_eq (TYPE_PRECISION (t), GET_MODE_PRECISION (TYPE_MODE (t)));
}
```

I wonder if we have the same issue with some other direct calls internal
functions too. But I have not looked into others that is accessible except =
for
__builtin_clzg which always does the right thing.=