From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DF8103858C83; Wed, 19 Apr 2023 19:42:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DF8103858C83 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1681933353; bh=ZaJmuTHqfXWkk4Y+mPOELgVnntbmHbblauEpMns1UzM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=fBhj9/IIWc3Onoy2YF8SeQGUPe5OCSUZhYebkZ1VUOO3R105Q8etORsI5UqGIevcK vUImVIO/8kiSjefUQek8ica5SBI9q+osOFcyF5Rug8VkirrKHxHJYFO9TUp8nBWuTO ynI771P3YJfkDDIumGgjEGhtHS7ce6ezd53F4r7I= 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:42:33 +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 #16 from Steve Kargl = --- On Wed, Apr 19, 2023 at 07:15:50PM +0000, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109500 >=20 > --- Comment #15 from anlauf at gcc dot gnu.org --- > (In reply to Steve Kargl from comment #13) > > 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. >=20 > You mean when the function result is not allocated in that case? First, note, 'allocated(f())' throws an error. Error: 'array' argument of 'allocated' intrinsic at (1) must be a variable You get this error regardless of the allocation status of the=20 function result. Now, with the original code, is_allocated(f()) The function reference is evaluated, and then the function result (aka it's value) is argument associated with an allocatable dummy argument. This is technically wrong as the actual argument (aka value returned by the function reference) should not have the allocatable attribute. Fortran 2018 15.5.2.6 Allocatable dummy variables The requirements in this subclause apply to actual arguments that correspond to allocatable dummy data objects. The actual argument shall be allocatable. It is permissible for the actual argument to have an allocation status of unallocated. I'll repeat. The actual argument is the value resulting from the function reference. The "shall" in "shall be allocatable" applies to something the programmer must ensure. > > 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. >=20 > I checked how to implement a run-time check for a non-allocated > function result, but did this in the wrong place - in the caller. > This did work when I did allocate and the deallocate before return, > otherwise the result variable is simply undefined, and the check does > not work. >=20 > So a run-time check needs to be put where the function return is generate= d. >=20 If we go back to the original code and modify to allocate f by say doing 'f =3D 42' in f(), gfortran produces=20 % gfcx -o z -Wall a.f90 && ./z T This is the problem. Yes, f is allocated and assigned=20 42. The printed 'T' is bogus because 42 is value of the function. 42 is no allocatable. One place to possibly check for an error is when=20 gfortran resolves argument association. If a dummy argument is allocatable, the actual argument needs=20 to be allocatable and cannot not also be a function result variable.=