http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47552
Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |patch
CC| |fxcoudert at gcc dot
| |gnu.org
--- Comment #3 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org>
2011-03-11 21:32:33 UTC ---
(In reply to comment #2)
> This seems to be because the libgfortran implementation uses gfc_charlen_type
> for the length of the string,
Which is the correct thing the do!
> but the frontend passes the address of an
> integer(8) variable
Which is wrong. This is fixed by the patch:
Index: trans-intrinsic.c
===================================================================
--- trans-intrinsic.c (revision 170612)
+++ trans-intrinsic.c (working copy)
@@ -1501,7 +1501,7 @@
args = XALLOCAVEC (tree, num_args);
var = gfc_create_var (pchar_type_node, "pstr");
- len = gfc_create_var (gfc_get_int_type (8), "len");
+ len = gfc_create_var (gfc_charlen_type_node, "len");
gfc_conv_intrinsic_function_args (se, expr, &args[2], num_args - 2);
args[0] = gfc_build_addr_expr (NULL_TREE, var);
> If not before, perhaps something to fix when/if we change to use size_t for
> string lengths, see http://gcc.gnu.org/wiki/LibgfortranAbiCleanup
Just as a remark: you're not going to use size_t, but the signed ssize_t,
right?
