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 824673858C53; Tue,  9 May 2023 12:44:43 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 824673858C53
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1683636283;
	bh=zXne2TN+w77m0whja4J6HGzhpiYSfEh8b8RGiCm5CMM=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=vNcSttrdaOhixa0VLJJcGWtlVIi8QVg6Ecrmdcl6EA+N9S1zynhBC7CrMpv/w3h7/
	 YKXMXkKLKE/8NCFx8zhSzkJCt5T8iSTTfP1tDcAnrOnP14AQPWDVimhmXBw3xed980
	 xhks7qP0qkoJh39r48/AJM3gqsRI/jYT2L/4dqas=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/109788] [14 Regression] gcc/hwint.h:293:61:
 runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned
 int since r14-377-gc92b8be9b52b7e
Date: Tue, 09 May 2023 12:44:42 +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: 13.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub 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: cc
Message-ID: <bug-109788-4-AcuQflOwEC@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-109788-4@http.gcc.gnu.org/bugzilla/>
References: <bug-109788-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=3D109788

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This is on
_gfortran_spread_char_scalar (&atmp.0, _1, &a, &C.4290, &C.4292, _1);
and ipa_compute_jump_functions_for_edge on the _1 arg, which is
 <ssa_name 0x7fffea134ab0
    type <integer_type 0x7fffea146738 integer(kind=3D8) public DI
        size <integer_cst 0x7fffea12cc48 constant 64>
        unit-size <integer_cst 0x7fffea12cc60 constant 8>
        align:64 warn_if_not_align:0 symtab:0 alias-set 6 canonical-type
0x7fffea146738 precision:64 min <integer_cst 0x7fffea12ced0
-9223372036854775808> max <integer_cst 0x7fffea12cee8 9223372036854775807>
        pointer_to_this <pointer_type 0x7fffea17c738> reference_to_this
<reference_type 0x7fffe9f02498>>
    visited
    def_stmt _1 =3D MAX_EXPR <_20, 0>;
    version:1
    ptr-info 0x7fffe9f186e0>
but somehow
       tree param_type =3D ipa_get_callee_param_type (cs, n);
returns VOID_TYPE.  So, either it is a bug that parm_type can be some
completely unrelated type to the argument's type, or if it has some special
meaning,
          if (TREE_CODE (arg) =3D=3D SSA_NAME
              && param_type
              /* Limit the ranger query to integral types as the rest
                 of this file uses value_range's, which only hold
                 integers and pointers.  */
              && irange::supports_p (TREE_TYPE (arg))
              && get_range_query (cfun)->range_of_expr (vr, arg)
              && !vr.undefined_p ())
should also check that irange::supports_p (param_type) or something similar.
The exact ICE is trying to compute wide_int -1 with precision 0.=