https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566
--- Comment #5 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> --- Sorry, forget that last. I got out on the wrong side of the bed I think. I will take a proper look later. Cheers Paul On Sat, 13 Oct 2018 at 07:45, paul.richard.thomas at gmail dot com <gcc-bugzi...@gcc.gnu.org> wrote: > > 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. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
