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 1335F3858D37; Tue, 23 May 2023 16:14:28 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1335F3858D37
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1684858468;
	bh=hrmFPjzNuVufjq0/pvAeD/VeKZSrdLdk5PlQqkWT2h8=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=owHplY5htxx1gBLwpB7yxFc1sA0pDq9x+yVpoEPWDimI4pDq8AcokNCMpUVOMTUJk
	 polnaS3jm8YxtgJVOun1EMrsFQeUSmoYrDUuROa0+snLLdMS9wp61/6ByZqn/3rqsc
	 qDDC2Shm3katfO0XXJPzlMI0yUQKPHu954YBQfdU=
From: "jamborm at gcc dot gnu.org" <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: Tue, 23 May 2023 16:14:27 +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: jamborm 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-109886-4-20otXoBod1@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 #5 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > (In reply to Aldy Hernandez from comment #2)
> > > If irange::supports_p (TREE_TYPE (arg)) is true, we're talking about =
an
> > > integer/pointer, but if range_cast is being called on a parm_type of
> > > RECORD_TYPE, someone's trying to cast a structure to an integer.  Is =
that
> > > the intent here, because that will not work with ranges??
> >=20
> > That is correct. The generated code has a VIEW_CONVERT_EXR from an inte=
ger
> > type to a RECORD_TYPE.
>=20
> Eeeech.  In that case, then what you suggest is reasonable.  Bail if
> param_type is not supported by the underlying range.  Maybe the IPA exper=
ts
> could opine?

With LTOed type mismateches or with K&R style code, IPA has to be prepared =
to
deal with such cases, unfortunately.  So a check like that indeed looks
reasonable.=