https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #17 from anlauf at gcc dot gnu.org --- (In reply to Steve Kargl from comment #16) > First, note, 'allocated(f())' throws an error. Agree. > 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. Agree. See also the discussion on the J3 mailing list. > 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. Agree. > 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. Agree again. The point is that there is a bug in gfortran which currently effectively generates code which resembles integer, allocatable :: p p = f() print *, is_allocated(p) deallocate (p) (of course with a temporary for the function result). The technical reason for the crash is the copying of the function (non)result. The patch in comment#9 rejects all related misuses. Given the lengthy thread on the J3 mailing list, I am wondering whether there ever was an explicit IR on the issue, or was it considered so obvious that the clarification was deferred to the F2018 document. > 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.
