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 9BB0F3858C52; Fri, 21 Apr 2023 21:32:44 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9BB0F3858C52
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1682112764;
	bh=I7I5FL/mYoba9MWjLMrfVziWx51pXkmWGTPE/AFfzuI=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=VFjb/6dlcCt4nhW68yn58VgHYsjJWDcHCV1bQ1kml1zbDQgPv6Vdv7H4ZovjYzlNl
	 jSIBYJhVHUkJImd0+DwlnVFt+VY4XItlSTBEygiceY/Edx3W48rwvzKaSsxbT5IHZf
	 escklax3j21Amttw1P1S2t/UjqMmiztiUhg9+Dmc=
From: "sgk at troutmask dot apl.washington.edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/109575] Implement runtime check for valid function
 result
Date: Fri, 21 Apr 2023 21:32: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: unknown
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: sgk at troutmask dot apl.washington.edu
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-109575-4-qN0EyjJQBJ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-109575-4@http.gcc.gnu.org/bugzilla/>
References: <bug-109575-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=3D109575

--- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> -=
--
On Fri, Apr 21, 2023 at 08:24:45PM +0000, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109575
>=20
> --- Comment #2 from anlauf at gcc dot gnu.org ---
> I have some idea how (and where) the runtime checks need to be implemente=
d,
> but I am confused by the following observations on the occurence of an
> explicit RETURN statement and the use of a RESULT variable:
>=20
> __attribute__((fn spec (". ")))
> integer(kind=3D4) q2 ()
> {
>   integer(kind=3D4) f;
>=20
>   f =3D 2;
>   return f;
> }
>=20
>=20
> __attribute__((fn spec (". ")))
> integer(kind=3D4) g ()
> {
>   integer(kind=3D4) __result_g;
>=20
>   return __result_g;
>   return __result_g;
> }
>=20

So, if I follow you correctly, you're worried by about
the two 'return __result_g' versus the one 'return f'?
Dead code elimination likely removes the second=20
'return __result_g'.  It indeed seems odd!=