------- Comment #3 from pault at gcc dot gnu dot org 2008-03-26 21:38 -------
> If I would hazard a guess, something is going wrong in
> trans-expr.c(gfc_trans_string_copy), where LEN=1 is treated separately.
Yes, this is correct. In this particular case, we have:
lhs => (void *) &(*(character(kind=1)[0:][1:1] *) atmp.4.data)[S.5]
rhs => (void *) &(*tda1l.0)[(S.5 + 1) * D.590 + D.578].c[1]{lb: 1 sz: 1}
which will clearly run afoul of the check in trans.c. Rather than mess around
casting and uncasting the rhs, which I know from experience is a pain in the
posterior, I propose the following:
Index: gcc/fortran/trans-expr.c
===================================================================
*** gcc/fortran/trans-expr.c (revision 133278)
--- gcc/fortran/trans-expr.c (working copy)
***************
*** 2857,2864 ****
if (dlength != NULL_TREE && POINTER_TYPE_P (TREE_TYPE (dest)))
dsc = gfc_to_single_character (dlen, dest);
!
! if (dsc != NULL_TREE && ssc != NULL_TREE)
{
gfc_add_modify_expr (block, dsc, ssc);
return;
--- 2840,2848 ----
if (dlength != NULL_TREE && POINTER_TYPE_P (TREE_TYPE (dest)))
dsc = gfc_to_single_character (dlen, dest);
! /* Assign directly if the types are compatible. */
! if (dsc != NULL_TREE && ssc != NULL_TREE
! && TREE_TYPE (dsc) == TREE_TYPE (ssc))
{
gfc_add_modify_expr (block, dsc, ssc);
return;
It does not produce the most efficient code for this case but is guaranteed to
work. This has just gone on to regtest.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35702
