From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 035343858C33; Wed, 19 Apr 2023 19:02:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 035343858C33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1681930947; bh=eHJuuzNJVLS0aPm6GWV5VlC+SfL2lZFVKlMGmtTX9oU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=EeD8HjHwyxHXlYNWUNfVLA28l+NctGp5ScwcDyZ7JZEgK2+rS0brG2Bur0lBxw7eI dsWQnphWgHuZcshFWAThGQgfSM9vu25Dn/JOHi0yjmSOQRKgRtYpKnHEWn8XPxfVOF hrQpG2q4subknNIikvU0ucb8ZMOi4QQHIQiCHGf4= From: "sgk at troutmask dot apl.washington.edu" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value Date: Wed, 19 Apr 2023 19:02:26 +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: 12.0 X-Bugzilla-Keywords: accepts-invalid, diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: sgk at troutmask dot apl.washington.edu X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P5 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109500 --- Comment #13 from Steve Kargl = --- On Wed, Apr 19, 2023 at 05:25:20PM +0000, leandro.lupori at linaro dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109500 >=20 > I'm trying to check with the issue reporter how extensive is his usage of= this > extension and how much effort it would require for him to avoid using it. >=20 It's not an extension. It is a bug in the original Fortran code. The Fortran standard requires a function result to be available at the completion of execution of a function reference. The code in the original bug report clearly violates this. Note 1 in Fortran 2023, Sec. 8.5.3, p. 100, is non-normative text. I suppose one can claim that gfortran should throw an error when a function result is marked with the allocatable attribute. Unfortunately, it is likely a catch-22 situation in that gfortran needs to know the function result is allocatable so it can do the allocaton within the function, but it is not an allocatable outside of the function. Not sure gfortran can mark an internal symbol to do both.=