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 B68D53858401; Fri, 12 May 2023 19:41:44 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B68D53858401
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1683920504;
	bh=PMUsxvALUkLEKI6G9U6RpQwwpBvEavgYnezFl1LIU5c=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=sVeZdDFj/ACA/O8nBfS2P4746bZE/m5SKcabAY74W5vBuJr3vrdOLprb4bfYd7wkb
	 uFUppZOKCOXcrJJ3ymnx8LTJ593AcGlU/Oh3jMr11Nwwa4EBN9BfltsySB/M8CkNIr
	 iLFz2W3BzSop+WpFSXTI9QNc57EZV1Mk627vUsLo=
From: "anlauf at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/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: Fri, 12 May 2023 19:41:44 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: anlauf 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: 14.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-109788-4-DlMKKBjpch@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

--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #11)
> If you e.g. put breakpoint on the spot I changed and stopon the testcase
> with -Os when t =3D=3D global_trees[TI_VOID_LIST_NODE] you can then see in
> e->callee the FUNCTION_TYPE with just 5 arguments.

I am not too experienced to debug this kind of stuff, but I guess I've seen
what happens.  I was then wondering if one of the dump files would show the
function decl, like we can see it for normal procedures, but did not succee=
d.

The following (partial) patch seems to fix the decl:

diff --git a/gcc/fortran/iresolve.cc b/gcc/fortran/iresolve.cc
index 7880aba63bb..615d3ec98d4 100644
--- a/gcc/fortran/iresolve.cc
+++ b/gcc/fortran/iresolve.cc
@@ -2664,6 +2664,10 @@ gfc_resolve_spread (gfc_expr *f, gfc_expr *source,
gfc_expr *dim,
        f->value.function.name =3D PREFIX ("spread");
     }

+  /* Take formal argument type from SOURCE so that a function decl with the
+     right number of arguments is generated (hidden character length).  */
+  f->value.function.isym->formal->ts =3D source->ts;
+
   if (dim && gfc_is_constant_expr (dim)
       && ncopies && gfc_is_constant_expr (ncopies) && source->shape[0])
     {

It would be interesting to see if you see issues with the following code:

program p
  character(3) :: a =3D 'abc'
  real         :: b =3D 42.0
  complex      :: c =3D (2.0,0.0)
  type t
     integer :: i
  end type t
  type(t)      :: d =3D t(3)
  associate (y =3D> spread(a,1,2) // "d")
  end associate
  associate (x =3D> spread(b,1,2))
  end associate
  associate (z =3D> spread(c,1,2))
  end associate
  associate (w =3D> spread(d,1,2))
  end associate
end program p

The library function _gfortran_spread_char_scalar should now have 6 argumen=
ts,
while the uses of _gfortran_spread_scalar have 4 arguments, which are in pa=
rt
pointers to either intrinsic or user-defined types.  I do hope that does not
lead to new problems.=