The following provokes the summary: implicit real*8 (a-h,o-z) character*32 ddname,dname dname(x)= 'h810 e=0.01 ' ddname=dname(0.d0) END Best regards Vittorio Zecca
CONFIRMED - and no regression. Thanks for the report! test.f90:4:0: internal compiler error: in string_to_single_character, at fortran/trans-expr.c:1394 Failing assert: string_to_single_character (tree len, tree str, int kind) { gcc_assert (POINTER_TYPE_P (TREE_TYPE (str)));
The test case recurses infinitely with -fdump-fortran-original: Namespace: A-H: (REAL 8) I-N: (INTEGER 4) O-Z: (REAL 8) procedure name = MAIN__ symtree: 'MAIN__' || symbol: 'MAIN__' type spec : (UNKNOWN 0) attributes: (PROGRAM PUBLIC SUBROUTINE) symtree: 'ddname' || symbol: 'ddname' type spec : (CHARACTER 32) attributes: (VARIABLE ) symtree: 'dname' || symbol: 'dname' type spec : (CHARACTER 32) attributes: (PROCEDURE STATEMENT-PROC FUNCTION) value: 'h810 e=0.01 ' result: dname Formal arglist: x Formal namespace Namespace: A-H: (REAL 8) I-N: (INTEGER 4) O-Z: (REAL 8) procedure name = MAIN__ ... and so on.
Author: tkoenig Date: Fri Dec 3 12:23:11 2010 New Revision: 167416 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167416 Log: 2010-12-03 Thomas Koenig <tkoenig@gcc.gnu.org> PR fortran/44352 * dump-parse-tree.c (show_symbol): Don't show formal namespace for statement functions in order to avoid infinite recursion. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c
The infinite recursion is fixed, the original problem remains.
Reduced test case, not that there was a lot to reduce: character*2 ddname,dname dname(x)= 'x' ddname=dname(0.0) END (the test succeeds with character*1).
This works: character*2 ddname,dname dname(x)= 'x ' ddname=dname(0.0) END We fail to pad the string for this case.
Paul, this involves (for me) some heavy voodoo regarding conversion of strings to trees. Do you have any idea, by any chance?
(In reply to comment #7) > Paul, this involves (for me) some heavy voodoo regarding conversion of > strings to trees. > > Do you have any idea, by any chance? Thomas, The odd thing is that: implicit real*8 (a-h,o-z) character*32 ddname,dname character*4 :: c dname(c) = 'h810 e=0.01 '//c ddname=dname("w") print *, ddname END works, whilst removing the "//c" produces the same failure as the original. This works too: implicit real*8 (a-h,o-z) character*32 ddname,dname dname(x)= 'h810 e=0.01 '//foo(x) ddname=dname(42.0d0) print *, ddname contains character*12 function foo (x) real*8 :: x write (foo, "(e12.5)") x end function END The ICE arises because the result string is not POINTER_TYPE_P in spite of line trans-expr.c:3965 tmp = gfc_build_addr_expr (build_pointer_type (type), tmp); I don't see it at all, right now :-( Paul
(In reply to comment #8) > The ICE arises because the result string is not POINTER_TYPE_P in spite of > line trans-expr.c:3965 > tmp = gfc_build_addr_expr (build_pointer_type (type), tmp); Well, that's a different string. If one looks at the dump (with the patch) for 'h ' and a length-3 string: __builtin_memcpy ((void *) &dname.1, (void *) "h ", 2); __builtin_memset ((void *) &dname.1 + 2, 32, 1); __builtin_memmove ((void *) &ddname, (void *) &dname.1, 3); Thus, one first assigns to the statement-function variable ("dname") and then memmoves the result to the LHS of the assignment ("ddname"). The ICE occured because '"h "' is not an address expression. The following patch works. The dump also looks OK (cf. above) - though, I do not know whether it causes missed-optimization or other issues. --- a/gcc/fortran/trans-expr.c +++ b/gcc/fortran/trans-expr.c @@ -1438,9 +1438,9 @@ gfc_conv_expr_op (gfc_se * se, gfc_expr * expr) tree gfc_string_to_single_character (tree len, tree str, int kind) { - gcc_assert (POINTER_TYPE_P (TREE_TYPE (str))); - if (!INTEGER_CST_P (len) || TREE_INT_CST_HIGH (len) != 0) + if (!INTEGER_CST_P (len) || TREE_INT_CST_HIGH (len) != 0 + || !POINTER_TYPE_P (TREE_TYPE (str))) return NULL_TREE; if (TREE_INT_CST_LOW (len) == 1) @@ -3831,7 +3831,7 @@ gfc_trans_string_copy (stmtblock_t * block, tree dlength, tree dest, else dest = gfc_build_addr_expr (pvoid_type_node, dest); - if (slength) + if (slength && POINTER_TYPE_P (TREE_TYPE (src))) src = fold_convert (pvoid_type_node, src); else src = gfc_build_addr_expr (pvoid_type_node, src);
Author: burnus Date: Tue Dec 7 20:29:22 2010 New Revision: 167569 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167569 Log: 2010-12-07 Tobias Burnus <burnus@net-b.de> PR fortran/44352 * trans-expr.c (gfc_string_to_single_character): Return if not POINTER_TYPE_P. (gfc_trans_string_copy): gfc_build_addr_expr if src or dest is not a pointer. (gfc_trans_string_copy): Make sure the argument string type has a string length, fix indention, and remove not needed gfc_build_addr_expr. 2010-12-07 Tobias Burnus <burnus@net-b.de> PR fortran/44352 * gfortran.dg/string_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/string_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
Tobias, anything left to do here or can this report be closed?
Should this be backported to 4.5?
Anything left to do here ?
Dear Mikael, It needs the backporting that Thomas suggested. I have been away from home for a bit and so have not had access to a 4.5 tree. I'll be back in 04 tomorrow night :-) Cheers Paul On Sun, Feb 27, 2011 at 11:48 PM, mikael at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org> wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44352 > > Mikael Morin <mikael at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |mikael at gcc dot gnu.org > > --- Comment #13 from Mikael Morin <mikael at gcc dot gnu.org> 2011-02-27 22:47:33 UTC --- > Anything left to do here ? > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug. >
Was this ever backported? Should it still be backported?
(In reply to comment #15) > Was this ever backported? Should it still be backported? No, it has only been fixed for 4.6 (and thus 4.7), but not for 4.5. It is not a regression but also existed already in 4.1. Thus, I am inclined to say no - also given that Debian stable and RHEL use 4.4 and SLES uses 4.3 such that no long-term Linux distribution uses that version. The patch is also not obvious (though also not really complicated). Hence, I would suggest to close it as fixed. Unless, someone really wants to backport it.
In the absence of any votes for backporting, closing as FIXED.