https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #16 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- 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=109500 > > --- 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. > > 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 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. > > 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. > > So a run-time check needs to be put where the function return is generated. > If we go back to the original code and modify to allocate f by say doing 'f = 42' in f(), gfortran produces % gfcx -o z -Wall a.f90 && ./z T This is the problem. Yes, f is allocated and assigned 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 gfortran resolves argument association. If a dummy argument is allocatable, the actual argument needs to be allocatable and cannot not also be a function result variable.
