https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #10 from Jürgen Reuter <juergen.reuter at desy dot de> --- (In reply to Tobias Burnus from comment #8) > 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.) Thanks for checking, Tobias. Are you saying that the code violates the standard, or the code generation after parsing by gcc/gfortran has generated code violating the standard?
