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 2F23238A90B9; Tue, 15 Nov 2022 19:34:55 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2F23238A90B9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1668540895;
	bh=ffzisLB5XH0D7Ucu6JUR599myouWEqkC8+poepFaNVc=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=qkHebvskqGpAK1y6LIIjttXksG/zhOJfvL3byA3l68HaEX/ID90qYjTvze6Qrw3da
	 FRc3SAwYsFijHGHtPs4p3dQ98DS8z4gOUHywH/3jOD7CxFNn2XCjEC1SozxEEJxuez
	 GWHxE+rqYU6iw27cN7kCX3YZtzTsHSl1BBaOI56k=
From: "anlauf at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/107680] ICE in arith_power, at fortran/arith.cc:989 and
 :1006
Date: Tue, 15 Nov 2022 19:34:54 +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: 13.0
X-Bugzilla-Keywords: ice-on-valid-code
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: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-107680-4-rhyzmpj5Ft@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107680-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107680-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=3D107680

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #3)
> I thought the call to gfc_type_convert_binary in eval_intrinsic was taking
> care of mismatching types, doesn't it?

It does, and then it doesn't do it sometimes...

For

  real, parameter :: x(*) =3D [real :: ([1])]   **  2.0

after adding breakpoints in gfc_type_convert_binary and arith_power,
I see correct types in the former (e->value.op.op2->ts.type =3D BT_REAL)
but incorrect types in the latter (op1->ts.type =3D BT_INTEGER).

It seems to be the ratatouille of parentheses, array constructors,
typespec, and arithmetic operation that is crucial to get this type
of error.

In 12-branch, I also see other bad things happening, which I believe have
partially been fixed by the series of patches for pr107000 and friends.
Try:

  print *, [integer :: ([3.0])] **  2.0

This gives

0.00000000

for all versions <=3D 12, and

9.00000000

for mainline.

Given these observations, I suspect that typespecs are not consistently
handled...  See also the previous discussions.=