https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566
--- Comment #4 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> --- Hi Tobias, You are grappling with exactly the error that I am grappling with in backporting my deferred character patches to 8-branch. The problem is the following and it is specific to deferred character components: 1) The string length of these components is stored in a hidden component, which gfc_conv_expr and gfc_conv_expr_descriptor successfully return as the string length. 2) Unfortunately, we are forced in the field decl for these components to make them zero length (NULL fails for reasons that I simply do not understand). This means that the ts.u.backend_decl is also constant zero and so must not be assigned to. 3) What I have been doing is to avoid assigning to the backend_decl by applying a guard that it is not integer_zerop and instead, looking for TREE_CODE (se->string_length) == COMPONENT_REF and assigning to that. I have to run Jan to the eye hospital this morning for an injection (the final one). When I get home, I will take a look at your partial patch and try to identify the spot where this happens. It's good to have you back. Thomas and I were getting rather lonely! Regards Paul On Fri, 12 Oct 2018 at 22:07, burnus at gcc dot gnu.org <gcc-bugzi...@gcc.gnu.org> wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566 > > --- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> --- > @Paul: Some guidance is welcome! > > (In reply to Tobias Burnus from comment #2) > > For some odd reasons the gimplfier does not like that f951 assigns a value > > to the digit 0 (last but one line of the "finally") ... > > That's in trans-expr.c's gfc_conv_class_to_class(): > > if (UNLIMITED_POLY (e)) > tmp = gfc_class_len_get (tmp); > else if (e->ts.type == BT_CHARACTER) > tmp = slen; > else > tmp = build_zero_cst (size_type_node); > gfc_add_modify (&parmse->pre, ctree, > fold_convert (TREE_TYPE (ctree), tmp)); > > OK so far – now comes the finally part: > > if (!elemental && full_array && copyback) > gfc_add_modify (&parmse->post, tmp, > fold_convert (TREE_TYPE (tmp), ctree)); > > And here we have assigned (if the "else" branch for tmp branch was taken) a > value to the build_zero_cst()! > > > Actually, I wonder whether the _len = 0 is needed. The current code is: > > class.0._len = 0; > class.0._data = > __tmp_class_object_array_pointer->_data->p._data; > class.0._vptr = > __tmp_class_object_array_pointer->_data->p._vptr; > class.0._len = > __tmp_class_object_array_pointer->_data->p._len; > > i.e. we set _len twice. And also in finally, we have it also twice: > > 0 = (unsigned long) class.0._len; > __tmp_class_object_array_pointer->_data->p._len = class.0._len; > > As band-aid the following works (on top of the patch from attachment 44831) > > --- a/gcc/fortran/trans-expr.c > +++ b/gcc/fortran/trans-expr.c > @@ -1133,3 +1133,3 @@ gfc_conv_class_to_class (gfc_se *parmse, gfc_expr *e, > gfc_typespec class_ts, > references, where the dynamic type cannot change. */ > - if (!elemental && full_array && copyback) > + if (!elemental && full_array && copyback && !INTEGER_CST_P (tmp)) > gfc_add_modify (&parmse->post, tmp, > > -- > You are receiving this mail because: > You are on the CC list for the bug.
