[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 Mikael Morin changed: What|Removed |Added Assignee|mikael at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #23 from Mikael Morin --- (In reply to anlauf from comment #22) > Mikael, > > since you did the essential work and commit, I am reassigning to you. Well, I'm not working on this any more. As far as I know, comment #0 is fixed, but comment #14 remains unfixed.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|anlauf at gcc dot gnu.org |mikael at gcc dot gnu.org --- Comment #22 from anlauf at gcc dot gnu.org --- Mikael, since you did the essential work and commit, I am reassigning to you.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 --- Comment #20 from CVS Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:71e4d568b1264bca46d30c5fc4933f137d05ca24 commit r14-2520-g71e4d568b1264bca46d30c5fc4933f137d05ca24 Author: Mikael Morin Date: Fri Jul 14 14:15:21 2023 +0200 fortran: Factor data references for scalar class argument wrapping [PR92178] In the case of a scalar actual arg passed to a polymorphic assumed-rank dummy with INTENT(OUT) attribute, avoid repeatedly evaluating the actual argument reference by saving a pointer to it. This is non-optimal, but may also be invalid, because the data reference may depend on its own content. In that case the expression can't be evaluated after the data has been deallocated. There are two ways redundant expressions are generated: - parmse.expr, which contains the actual argument expression, is reused to get or set subfields in gfc_conv_class_to_class. - gfc_conv_class_to_class, to get the virtual table pointer associated with the argument, generates a new expression from scratch starting with the frontend expression. The first part is fixed by saving parmse.expr to a pointer and using the pointer instead of the original expression. The second part is fixed by adding a separate field to gfc_se that is set to the class container expression when the expression to evaluate is polymorphic. This needs the same field in gfc_ss_info so that its value can be propagated to gfc_conv_class_to_class which is modified to use that value. Finally gfc_conv_procedure saves the expression in that field to a pointer in between to avoid the same problem as for the first part. PR fortran/92178 gcc/fortran/ChangeLog: * trans.h (struct gfc_se): New field class_container. (struct gfc_ss_info): Ditto. (gfc_evaluate_data_ref_now): New prototype. * trans.cc (gfc_evaluate_data_ref_now): Implement it. * trans-array.cc (gfc_conv_ss_descriptor): Copy class_container field from gfc_se struct to gfc_ss_info struct. (gfc_conv_expr_descriptor): Copy class_container field from gfc_ss_info struct to gfc_se struct. * trans-expr.cc (gfc_conv_class_to_class): Use class container set in class_container field if available. (gfc_conv_variable): Set class_container field on encountering class variables or components, clear it on encountering non-class components. (gfc_conv_procedure_call): Evaluate data ref to a pointer now, and replace later references by usage of the pointer. gcc/testsuite/ChangeLog: * gfortran.dg/intent_out_20.f90: New test.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 --- Comment #21 from CVS Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:9206641d0899e4bae3ad6765129661ff3bcc423a commit r14-2521-g9206641d0899e4bae3ad6765129661ff3bcc423a Author: Mikael Morin Date: Fri Jul 14 14:15:51 2023 +0200 fortran: Reorder array argument evaluation parts [PR92178] In the case of an array actual arg passed to a polymorphic array dummy with INTENT(OUT) attribute, reorder the argument evaluation code to the following: - first evaluate arguments' values, and data references, - deallocate data references associated with an allocatable, intent(out) dummy, - create a class container using the freed data references. The ordering used to be incorrect between the first two items, when one argument was deallocated before a later argument evaluated its expression depending on the former argument. r14-2395-gb1079fc88f082d3c5b583c8822c08c5647810259 fixed it by treating arguments associated with an allocatable, intent(out) dummy in a separate, later block. This, however, wasn't working either if the data reference of such an argument was depending on its own content, as the class container initialization was trying to use deallocated content. This change generates class container initialization code in a separate block, so that it is moved after the deallocation block without moving the rest of the argument evaluation code. This alone is not sufficient to fix the problem, because the class container generation code repeatedly uses the full expression of the argument at a place where deallocation might have happened already. This is non-optimal, but may also be invalid, because the data reference may depend on its own content. In that case the expression can't be evaluated after the data has been deallocated. As in the scalar case previously treated, this is fixed by saving the data reference to a pointer before any deallocation happens, and then only refering to the pointer. gfc_reset_vptr is updated to take into account the already evaluated class container if it's available. Contrary to the scalar case, one hunk is needed to wrap the parameter evaluation in a conditional, to avoid regressing in optional_class_2.f90. This used to be handled by the class wrapper construction which wrapped the whole code in a conditional. With this change the class wrapper construction can't see the parameter evaluation code, so the latter is updated with an additional handling for optional arguments. PR fortran/92178 gcc/fortran/ChangeLog: * trans.h (gfc_reset_vptr): Add class_container argument. * trans-expr.cc (gfc_reset_vptr): Ditto. If a valid vptr can be obtained through class_container argument, bypass evaluation of e. (gfc_conv_procedure_call): Wrap the argument evaluation code in a conditional if the associated dummy is optional. Evaluate the data reference to a pointer now, and replace later references with usage of the pointer. gcc/testsuite/ChangeLog: * gfortran.dg/intent_out_21.f90: New test.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 --- Comment #19 from CVS Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:e93452a5712e87ba624562ba7164b1e1394d18fb commit r14-2519-ge93452a5712e87ba624562ba7164b1e1394d18fb Author: Mikael Morin Date: Fri Jul 14 14:15:07 2023 +0200 fortran: defer class wrapper initialization after deallocation [PR92178] If an actual argument is associated with an INTENT(OUT) dummy, and code to deallocate it is generated, generate the class wrapper initialization after the actual argument deallocation. This is achieved by passing a cleaned up expression to gfc_conv_class_to_class, so that the class wrapper initialization code can be isolated and moved independently after the deallocation. PR fortran/92178 gcc/fortran/ChangeLog: * trans-expr.cc (gfc_conv_procedure_call): Use a separate gfc_se struct, initalized from parmse, to generate the class wrapper. After the class wrapper code has been generated, copy it back depending on whether parameter deallocation code has been generated. gcc/testsuite/ChangeLog: * gfortran.dg/intent_out_19.f90: New test.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #18 from Mikael Morin --- Followup patches submitted: https://gcc.gnu.org/pipermail/fortran/2023-July/059580.html https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624081.html
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 --- Comment #17 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:b1079fc88f082d3c5b583c8822c08c5647810259 commit r14-2395-gb1079fc88f082d3c5b583c8822c08c5647810259 Author: Harald Anlauf Date: Wed Jul 5 22:21:09 2023 +0200 Fortran: fixes for procedures with ALLOCATABLE,INTENT(OUT) arguments [PR92178] gcc/fortran/ChangeLog: PR fortran/92178 * trans-expr.cc (gfc_conv_procedure_call): Check procedures for allocatable dummy arguments with INTENT(OUT) and move deallocation of actual arguments after evaluation of argument expressions before the procedure is executed. gcc/testsuite/ChangeLog: PR fortran/92178 * gfortran.dg/intent_out_16.f90: New test. * gfortran.dg/intent_out_17.f90: New test. * gfortran.dg/intent_out_18.f90: New test. Co-authored-by: Steven G. Kargl
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 --- Comment #16 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-July/059545.html
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 --- Comment #15 from anlauf at gcc dot gnu.org --- Created attachment 55453 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55453=edit Revised patch Revised patch that takes Tobias' suggestion into account that we scan the formal argument list first to determine whether we better evaluate argument expressions first. This may avoid creating of temporaries for many cases when none is needed. This does not yet handle the case of character arguments, where for yet unknown reasons no temporary is created. Might be deferred for a second patch. Working on testcases right now.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 --- Comment #14 from anlauf at gcc dot gnu.org --- I looked at cases with character arguments, and it appears that there is a general issue with (lack or improper) generation of temporaries. Consider: program p implicit none character(4), allocatable :: a(:) integer :: k = -999 a = ["aa","bb"] ! call assign_s (a, (a(2) // "")) ! OK ! call assign_s (a, a(2) // "" ) ! OK ! call assign_s (a, (a(2))) ! no proper temporary ! call assign_s (a, a(2) ) ! invalid Fortran call assign_s (a, (a(2)(1:3))) ! no proper temporary print *, allocated (a), k contains subroutine assign_s (a, b) character(*), allocatable, intent(out) :: a(:) ! character(*), value :: b! rejected (-> pr110290) character(*) :: b k = len (b) print *, b end subroutine end The first two variants work as expected, the fourth is IMHO invalid because of aliasing, but the third and fifth should work. However, compiling with -fsanitize=address,undefined shows that they don't. Inspecting the dump-tree suggests that there is no proper temporary for the second argument, even though it is requested. Also, running under gdb, I see that the gfc_evaluate_now from the patch is called. Do we need to do something special to get temporaries here?
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #13 from kargl at gcc dot gnu.org --- (In reply to anlauf from comment #12) > Created attachment 55333 [details] > Updated version of Steve's patch > > This patch adds evaluation of arguments that are neither constant, variables, > or pointers from functions that may appear in a variable definition context. > > This appears to fix all testcases here and "regresses" only for > gfortran.dg/assumed_type_17.f90, where the scan pattern does no longer match. > The tree-dump shows an additional intermediate variable for the call with > explicit parens as compared to without the patch, but the resulting assembler > is unchanged. > > I was expecting trouble with finalization, but all current testcases pass. Harald, Thanks for finding this! I have no pr92178.diff file on any of systems, and I quite frankly don't know if I can reconstruct the analysis I gave earlier. :-( It's a good sign that the patch doesn't interfere with finalization. Hopefully, Mikael or Paul can take a quick peek at the patch. I doubt I'm allowed to approve your new patch.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #12 from anlauf at gcc dot gnu.org --- Created attachment 55333 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55333=edit Updated version of Steve's patch This patch adds evaluation of arguments that are neither constant, variables, or pointers from functions that may appear in a variable definition context. This appears to fix all testcases here and "regresses" only for gfortran.dg/assumed_type_17.f90, where the scan pattern does no longer match. The tree-dump shows an additional intermediate variable for the call with explicit parens as compared to without the patch, but the resulting assembler is unchanged. I was expecting trouble with finalization, but all current testcases pass.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #11 from Tobias Burnus --- See also patch submitted at https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01686.html And patch review showing some additional issues, https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01970.html
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 --- Comment #10 from Steve Kargl --- On Thu, Oct 24, 2019 at 05:09:55AM +, mscfd at gmx dot net wrote: > > --- Comment #9 from martin --- > Is this possibly related to bug 87142? > Certainly appears that way. If I add a 'print *, ">"//trim(str%cs)//"<" to the end of the program, when I compile and run it, the result is >0123456789<
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 martin changed: What|Removed |Added CC||mscfd at gmx dot net --- Comment #9 from martin --- Is this possibly related to bug 87142?
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 --- Comment #8 from kargl at gcc dot gnu.org --- Patch submitted. https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01686.html
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
--- Comment #7 from Steve Kargl ---
On Tue, Oct 22, 2019 at 10:22:42PM +, sgk at troutmask dot
apl.washington.edu wrote:
> --- Comment #6 from Steve Kargl ---
> On Tue, Oct 22, 2019 at 09:30:14PM +, sgk at troutmask dot
> apl.washington.edu wrote:
> >
> > Cutting the -ftree-dump-original down to the 'call' statement
> > gives
> >
> > MAIN__ ()
> > {
> > {
> > integer(kind=4) D.3955;
> > integer(kind=4) D.3956;
> > integer(kind=4) M.7;
> >
> > D.3955 = (*(integer(kind=4)[0:] * restrict) a.data)[a.offset + 1];
> > D.3956 = D.3955 * D.3955;
> > M.7 = D.3956;
> > M.7 = MIN_EXPR ;
> > if ((integer(kind=4)[0:] * restrict) a.data != 0B)
> > {
> > __builtin_free ((void *) a.data);
> > (integer(kind=4)[0:] * restrict) a.data = 0B;
> > }
> > assign (M.7, );
> > }
> > }
> >
> > which shows the argument evaluation is done correctly. In short,
> > gfortran needs to scan the effective and dummy arguments for a
> > deallocation and just do the right thing.
> >
>
> The evaluation of arguments seems to be done in trans-expr.c
> gfc_conv_procedure_call(), where the argument list is simply
> walked and evaluated. That's not good as this pr shows. :(
>
There is a massive for-loop (lines: 5478-6638) that is used
for the evaluation of arguments. Within those lines, the
blocks 5924-5981, 6071-6111, and 6242-6273 are used to
delete allocated actual args for intent(out) dummy args.
I suspect that those blocks need to be removed, and second
following for-loop should scan the arg list to do the
deallocations.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
--- Comment #6 from Steve Kargl ---
On Tue, Oct 22, 2019 at 09:30:14PM +, sgk at troutmask dot
apl.washington.edu wrote:
>
> Cutting the -ftree-dump-original down to the 'call' statement
> gives
>
> MAIN__ ()
> {
> {
> integer(kind=4) D.3955;
> integer(kind=4) D.3956;
> integer(kind=4) M.7;
>
> D.3955 = (*(integer(kind=4)[0:] * restrict) a.data)[a.offset + 1];
> D.3956 = D.3955 * D.3955;
> M.7 = D.3956;
> M.7 = MIN_EXPR ;
> if ((integer(kind=4)[0:] * restrict) a.data != 0B)
> {
> __builtin_free ((void *) a.data);
> (integer(kind=4)[0:] * restrict) a.data = 0B;
> }
> assign (M.7, );
> }
> }
>
> which shows the argument evaluation is done correctly. In short,
> gfortran needs to scan the effective and dummy arguments for a
> deallocation and just do the right thing.
>
The evaluation of arguments seems to be done in trans-expr.c
gfc_conv_procedure_call(), where the argument list is simply
walked and evaluated. That's not good as this pr shows. :(
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
--- Comment #5 from Steve Kargl ---
On Tue, Oct 22, 2019 at 09:03:42PM +, vladimir.fuka at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
>
> --- Comment #4 from Vladimir Fuka ---
> It would be really strange if even expressions like below were not possible.
>
> implicit none
> integer, allocatable :: a(:)
> allocate(a, source=[1])
> call assign(a, (min(a(1)**2,0)))
> print *, allocated(a)
> contains
> subroutine assign(a, i)
> integer, allocatable, intent(out) :: a(:)
> integer, value :: i
> print *, i
> end subroutine
> end program
Yep. I agree. In fact, if you reverse the arguments, like,
implicit none
integer, allocatable :: a(:)
allocate(a, source=[1])
call assign((min(a(1)**2,0)), a)
print *, allocated(a)
contains
subroutine assign(i, a)
integer, allocatable, intent(out) :: a(:)
integer, value :: i
print *, i
end subroutine
end
gfortran gives
% gfcx -o z a.f90 && ./z
0
F
Cutting the -ftree-dump-original down to the 'call' statement
gives
MAIN__ ()
{
{
integer(kind=4) D.3955;
integer(kind=4) D.3956;
integer(kind=4) M.7;
D.3955 = (*(integer(kind=4)[0:] * restrict) a.data)[a.offset + 1];
D.3956 = D.3955 * D.3955;
M.7 = D.3956;
M.7 = MIN_EXPR ;
if ((integer(kind=4)[0:] * restrict) a.data != 0B)
{
__builtin_free ((void *) a.data);
(integer(kind=4)[0:] * restrict) a.data = 0B;
}
assign (M.7, );
}
}
which shows the argument evaluation is done correctly. In short,
gfortran needs to scan the effective and dummy arguments for a
deallocation and just do the right thing.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 --- Comment #4 from Vladimir Fuka --- It would be really strange if even expressions like below were not possible. implicit none integer, allocatable :: a(:) allocate(a, source=[1]) call assign(a, (min(a(1)**2,0))) print *, allocated(a) contains subroutine assign(a, i) integer, allocatable, intent(out) :: a(:) integer, value :: i print *, i end subroutine end program
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 --- Comment #3 from Steve Kargl --- On Tue, Oct 22, 2019 at 07:32:59PM +, kargl at gcc dot gnu.org wrote: > > The effect of the intent(out) in assign is to deallocate the code on entry to > assign. This is done with the if-block. The side-effect of evaluating the > first dummy argument is that 'a' in the expression of the 2nd dummy argument > is > undefined. > > F2018 (well 18-007r1) page 308: > >If a dummy argument has INTENT (OUT) or INTENT (INOUT), the actual >argument shall be definable. If a dummy argument has INTENT (OUT) >and its associated actual argument is allocated, the actual argument >is deallocated on procedure invocation (9.7.3.2). > > then later > >15.5.2.13 Restrictions on entities associated with dummy arguments > >While an entity is associated with a dummy argument, the following >restrictions hold. > >(1) Action that affects the allocation status of the entity or a >subobject thereof shall be taken through the dummy argument. > >(2) If the allocation status of the entity or a subobject thereof >is affected through the dummy argument, then at any time during >the invocation and execution of the procedure, either before or >after the allocation or deallocation, it shall be referenced only >through the dummy argument. > > It seems that code is non-conforming. > Seems to be some wiggle room. 15.5.4 Subroutine reference A subroutine is invoked by execution of a CALL statement, ... When a subroutine is invoked, all actual argument expressions are evaluated, then the arguments are associated, and then the subroutine is executed. So, it comes down to when the deallocation occur? P. 308 says the deallocation occurs when the procedure is invoked. But, 15.5.4 defines the sequence of events that occur when it procedure is invoked. Is the reference to the subroutine name the initiation of invocation? No where does it say when the deallocation occurs.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-10-22
CC||kargl at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from kargl at gcc dot gnu.org ---
Compiling the code with -fdump-tree-original and stripping out the unessential
intermediate code gives
assign (struct array01_integer(kind=4) & restrict a, integer(kind=4) b)
{
}
foo ()
{
if ((integer(kind=4)[0:] * restrict) a.data != 0B)
{
__builtin_free ((void *) a.data);
(integer(kind=4)[0:] * restrict) a.data = 0B;
}
assign (, (*(integer(kind=4)[0:] * restrict) a.data)[a.offset + 1]);
}
The effect of the intent(out) in assign is to deallocate the code on entry to
assign. This is done with the if-block. The side-effect of evaluating the
first dummy argument is that 'a' in the expression of the 2nd dummy argument is
undefined.
F2018 (well 18-007r1) page 308:
If a dummy argument has INTENT (OUT) or INTENT (INOUT), the actual
argument shall be definable. If a dummy argument has INTENT (OUT)
and its associated actual argument is allocated, the actual argument
is deallocated on procedure invocation (9.7.3.2).
then later
15.5.2.13 Restrictions on entities associated with dummy arguments
While an entity is associated with a dummy argument, the following
restrictions hold.
(1) Action that affects the allocation status of the entity or a
subobject thereof shall be taken through the dummy argument.
(2) If the allocation status of the entity or a subobject thereof
is affected through the dummy argument, then at any time during
the invocation and execution of the procedure, either before or
after the allocation or deallocation, it shall be referenced only
through the dummy argument.
It seems that code is non-conforming.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 --- Comment #1 from Vladimir Fuka --- It also crashes with passing just a(1) instead of (a(1)) and when removing the value attribute.
