https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> ---
The debugger shows for the example in comment 4 for the line
69 | history_new(1:s) = res_set%history(1:s)
the following expression:
(gdb) p gfc_debug_expr(expr)
t3_set_expand:history_new(1:__convert_i4_i8[[((t3_set_expand:s))]]) %
resonances(FULL)
That's F03:C614 - or in F2018:
C919 (R911) There shall not be more than one part-ref with nonzero rank. A
part-name to the right of a part-ref with nonzero rank shall not have the
ALLOCATABLE or POINTER attribute.
For the 'expr' shown in the debugger, that's violated as 'resonances' is
allocatable.
The 'expr' shown above is generated via
generate_component_assignments -> gfc_resolve_expr
-> resolve_variable -> gfc_resolve_ref
where generate_component_assignments's gfc_debug_code(*code) is
ASSIGN
t3_set_expand:history_new(1:__convert_i4_i8[[((t3_set_expand:s))]])
t3_set_expand:res_set % history(1:__convert_i4_i8[[((t3_set_expand:s))]])
which matches the user code and looks fine.
(BTW: We should also check whether there is now an issue with generating
redundant (re)allocate on assignment code in trans*.cc.)
