https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #7 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Thu, Apr 13, 2023 at 07:44:36PM +0000, leandro.lupori at linaro dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500 > > --- Comment #5 from Leandro Lupori <leandro.lupori at linaro dot org> --- > Ok, thanks for the detailed explanations. Now I see that the standard doesn't > allow the return of an unallocated value. This can be closed as invalid. > > But may I just ask a last related question? As mentioned in the last comment > and according to Note 1 in F2018 8.5.3 ALLOCATABLE attribute, the result of > referencing a function cannot be used as an allocatable argument. This is > however allowed by gfortran (and ifort), with the exception of intrinsic > procedures, and seems to work correctly. Should this be considered an > extension > or does it just work by accident and there are no guarantees at all when using > it? > I suspect it works by accident, but I don't have enough time at the moment to go read the gfortran source. What is likely happening is gfortran checks that the actual and dummy argument both have the allocatable attribute. For the actual argument, the symbol is probably marked an allocatable attribute and an internal attribute that designates this as a function-result, and gfortran does not check for the latter.
