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 8C2DD3858D3C; Fri,  9 Jun 2023 13:58:53 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8C2DD3858D3C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1686319133;
	bh=3Ixs9brKum/bE1yy3qFWFthttT6geEdSxZa/DBjo3/E=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=L+rBWo3GJ4axmPS7FRvkOEMuKboA8SWR5ZMnPwGoA8KkCl7yP4pzTTG07kTLnXJ0h
	 6uttY1NK38rxj4V/y4OIDut5ODeqtwUtBA0Lyo1vYZkKjEpOjzChJKLRhd4YMKR+8T
	 Ye4c1QmC6FEf5YNC5ydp+lCMVjW59lWQ8HavsNGQ=
From: "amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/109886] UBSAN error: shift exponent 64 is too large for
 64-bit type when compiling gcc.c-torture/compile/pr96796.c
Date: Fri, 09 Jun 2023 13:58:53 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: amacleod at redhat dot com
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-109886-4-GpVYZVDhIn@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-109886-4@http.gcc.gnu.org/bugzilla/>
References: <bug-109886-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=3D109886

--- Comment #11 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Martin Jambor from comment #9)
> A buildbot run which checked out this revision unfortunately still reports
> this problem with UBSAN-bootstrapped compiler.

Actually, I do not think that range_cast is the root problem upon further
review... Discussing it with Aldy, I think there is a typo in the code:

  value_range resvr =3D vr;
  range_cast (resvr, param_type);

That should be

  Value_Range resvr =3D vr;
  range_cast (resvr, param_type);

value_range is the legacy int_range (which should be going away this releas=
e)
and Value_Range is the new range type that supports multiple ranges, includ=
ing
unsupported ranges for UNDEFINED and VARYING.

So the set_varying call in range_cast is trying to cast the integer to a
different class which isnt supported by int_range.

BUt then, i see that ipa_set_jfunc_vr (jfunc, &resvr); is expecting a
value_range *, so perhapsd this is really a can of worms.  we're checking t=
hat
arg is an irange supported, we should also perhaps just check that param_ty=
pe
is too...=