On Sat, Apr 22, 2023 at 05:17:30PM +0200, Mikael Morin wrote: > Le 22/04/2023 à 15:52, Steve Kargl a écrit : > > On Sat, Apr 22, 2023 at 11:25:41AM +0200, Mikael Morin wrote: > > > > > > Le 20/04/2023 à 22:01, Harald Anlauf via Fortran a écrit : > > > > Dear all, > > > > > > > > Fortran 2018 added a clarification that the *result* of a function > > > > whose result *variable* has the ALLOCATABLE attribute is a *value* > > > > that itself does not have the ALLOCATABLE attribute. > > > > > > > > For those interested: there was a thread on the J3 mailing list > > > > some time ago (for links see the PR). > > > > > > > > The patch which implements a related check was co-authored with > > > > Steve and regtested by him. Testcase verified against NAG. > > > > > > > > OK for mainline (gcc-14)? > > > > > > > Looks good in principle, but I think the real fix should be in the > > > gfc_expr_attr function, which copies all the attributes (including > > > allocatable) in the EXPR_FUNCTION case. How would the testsuite react if > > > that attribute was cleared there? Is your patch still needed if > > > gfc_expr_attr is fixed? > > > > You may be correct that something can be done elsewhere. > > I do note that a function result can be allocatable > > (within the funciton body). The issue only arises when > > argument association is done, which is done where Harald > > and I have the patch. Do we know that the function will > > be an actual argument associated with an allocatable > > dummy argument when gfc_expr_attr is invoked? > > > No, there is no context information in gfc_expr_attr, but the result should > not be dependent on context anyway. > > You are probably right that the impact of this bug is limited to the case of > argument association, not as broad as I thought. Yet we should not keep > gfc_expr_attr returning an allocatable attribute for function expressions in > any case.
I suspect we're stuck in a catch-22 situation. The symbol is marked as allocatable, function foo() integer, allocatable :: foo foo = 42 !<--- So that this isn't rejected end but when the function is actually referenced in an expression the result is normally used, and symbol is still marked as allocatable. -- Steve
