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 2C5313858C54; Wed,  7 Jun 2023 20:57:48 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2C5313858C54
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1686171468;
	bh=Goqusy+S9W8zWV7pwPB6dJI0XWloOGxXIZn25DVXHuQ=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=Zk3Q9yxkP2qvfe2HIiXhCDHeb8bNVYBtELKopFeSjTA2qqCbghs9qtpZELPAxPed0
	 duj39Ssj70ZzUwDUM2vPtFZDTozU16CIdEeN0AUx82e4loQ+CFlgD64W97i9PyaFiI
	 9rgU95K/bFDR3wPK+SvYq1jZmMaatq/ZNNb27Pvs=
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: Wed, 07 Jun 2023 20:57:47 +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: cc
Message-ID: <bug-109886-4-ZijaRYr1bb@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

Andrew Macleod <amacleod at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amacleod at redhat dot com

--- Comment #6 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Martin Jambor from comment #5)
> (In reply to Aldy Hernandez from comment #4)
> > (In reply to Andrew Pinski from comment #3)

> > > That is correct. The generated code has a VIEW_CONVERT_EXR from an in=
teger
> > > 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 exp=
erts
> > could opine?
>=20
> 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.

The new range-op dispatch code is coming shortly.. when an unsupported type=
 is
passed in to any ranger routine, we'll simply return false instead of trapp=
ing
like we do now.=