https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #38 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #37)
> > > [...]
> > > if (D.3430.chars.data != 0B)
> > > {
> > > __builtin_free ((void *) D.3430.chars.data);
> > > }
> > > D.3430.chars.data = 0B;
> >
> > D.3430.chars.data is freed.
> >
> > So every iteration of the do loop has the side-effect of freeing
> > prt_in.chars.data.
>
> Could you please give me a pointer to the code emitting this side-effect?
The code you quoted (the call to free) comes from:
#0 gfc_deallocate_with_status at fortran/trans.c:1279
#1 gfc_trans_dealloc_allocated at fortran/trans-array.c:7428
#2 structure_alloc_comps at fortran/trans-array.c:7760
#3 gfc_deallocate_alloc_comp at fortran/trans-array.c:8060
#4 gfc_conv_expr_reference at fortran/trans-expr.c:7139
#5 gfc_conv_procedure_call at fortran/trans-expr.c:4360
#6 gfc_conv_function_expr at fortran/trans-expr.c:6974
#8 gfc_trans_assignment_1 at /fortran/trans-expr.c:8710
#9 trans_code at fortran/trans.c:1650
#10 gfc_trans_code_cond at fortran/trans.c:1946
#11 gfc_trans_simple_do at fortran/trans-stmt.c:1540
#12 gfc_trans_do at fortran/trans-stmt.c:1703
#13 trans_code at fortran/trans.c:1759
#14 gfc_trans_code at fortran/trans.c:1954
#15 gfc_generate_function_code at fortran/trans-decl.c:5842
#16 gfc_generate_code at fortran/trans.c:1971
#17 translate_all_program_units at fortran/parse.c:5341
#18 gfc_parse_file at fortran/parse.c:5538
#19 gfc_be_parse_file at fortran/f95-lang.c:228
#20 compile_file at toplev.c:594
#21 do_compile at toplev.c:2066
#22 toplev::main at toplev.c:2164
#23 main at main.c:39
However, it's not clear to me where the bug comes from, or at least where the
fix should go.
It's an artefact of temporary management which on one hand avoids deep copies,
but on the other hand frees allocated components as for a regular object, as if
a deep copy had happened before.
By the way, I'm not sure that it's at all correct to avoid deep copies.
