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 898B43858D37; Wed,  6 Apr 2022 08:22:14 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 898B43858D37
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/31178] VRP can infer a range for b in a >> b
 and a << b
Date: Wed, 06 Apr 2022 08:22:14 +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: 4.3.0
X-Bugzilla-Keywords: easyhack, missed-optimization
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: rguenther at suse dot de
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-31178-4-Ml8tHld2Tj@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-31178-4@http.gcc.gnu.org/bugzilla/>
References: <bug-31178-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
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Apr 2022 08:22:14 -0000

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

--- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 6 Apr 2022, vincent-gcc at vinc17 dot net wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D31178
>=20
> --- Comment #17 from Vincent Lef=C3=A8vre <vincent-gcc at vinc17 dot net>=
 ---
> (In reply to Richard Biener from comment #16)
> > Note for shifts the precision of the shift operand does not have to mat=
ch
> > that of the shifted operand.  In your case you have vector << scalar, s=
o you
> > definitely want to look at scalars precision when deriving a range for
> > scalar, _not_ at element_precision of vector (or the LHS)!
>=20
> I'm not sure I understand what you mean, but the C standard says:
>=20
>   The integer promotions are performed on each of the operands. The type
>   of the result is that of the promoted left operand. If the value of the
>   right operand is negative or is greater than or equal to the width of
>   the promoted left operand, the behavior is undefined.
>=20
> So, what matters is the type of the promoted *left* operand (correspondin=
g to
> vector above).

Sure, if that's what the precision is used for.  The message from Andrew
sounded like 'I want the precision for the shift operand but let me
just use that of the shifted anyway'=