[Bug fortran/84143] Intrinsic output of PDT incorrectly includes type parameters

2018-10-05 Thread jvdelisle at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84143

Jerry DeLisle  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||jvdelisle at gcc dot gnu.org

[Bug fortran/84143] Intrinsic output of PDT incorrectly includes type parameters

2018-02-24 Thread jvdelisle at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84143

--- Comment #6 from Jerry DeLisle  ---
The patch fixes the first part of the problem so the write will ignore the kind
and len parameters.

The component n is simply not being initialized at all. I am searching code for
where this ought to happen. I was thinking possibly in build_struct in decl.c,
but I am not sure yet.

[Bug fortran/84143] Intrinsic output of PDT incorrectly includes type parameters

2018-02-23 Thread jvdelisle at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84143

--- Comment #5 from Jerry DeLisle  ---
Looking at the tree dump we have:

_gfortran_st_write (_parm.0);
{
  struct Pdtfoo_1 * D.3772;

  D.3772 = 
  _gfortran_transfer_integer_write (_parm.0, >k1, 4);
  _gfortran_transfer_integer_write (_parm.0, >l1, 4);
  _gfortran_transfer_integer_write (_parm.0, >n, 4);
}
_gfortran_st_write_done (_parm.0);

And so in trans-io.c I am going to try:

diff --git a/gcc/fortran/trans-io.c b/gcc/fortran/trans-io.c
index 36adb034475..d492ed8cc4e 100644
--- a/gcc/fortran/trans-io.c
+++ b/gcc/fortran/trans-io.c
@@ -2483,7 +2483,8 @@ transfer_expr (gfc_se * se, gfc_typespec * ts, tree
addr_expr,
  se->string_length = strlen;
}

- transfer_expr (se, >ts, tmp, code, NULL_TREE);
+ if (c->attr.pdt_kind == 0 && c->attr.pdt_len == 0)
+   transfer_expr (se, >ts, tmp, code, NULL_TREE);

  /* Reset so that the pdt string length does not propagate
 through to other strings.  */

Its not clear to me yet why printing x%n is coming out zero however. I will
explore some more.

[Bug fortran/84143] Intrinsic output of PDT incorrectly includes type parameters

2018-02-22 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84143

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #4 from Dominique d'Humieres  ---
> Assign to Jerry per his request.

So moved status to ASSIGN.

[Bug fortran/84143] Intrinsic output of PDT incorrectly includes type parameters

2018-02-22 Thread kargl at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84143

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org
  Known to fail||8.0

--- Comment #3 from kargl at gcc dot gnu.org ---
Assign to Jerry per his request.

[Bug fortran/84143] Intrinsic output of PDT incorrectly includes type parameters

2018-01-31 Thread neil.n.carlson at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84143

--- Comment #2 from Neil Carlson  ---
(In reply to Dominique d'Humieres from comment #1)
> 
> gives 0. Should not it be 3?

Yeah. I noticed the same thing myself.  It is 3 if the type parameters are
removed.  I was intending to report it, but I thought I might have seen a
similar PR linked from the PDT meta bug and was going to look again before
doing so.

[Bug fortran/84143] Intrinsic output of PDT incorrectly includes type parameters

2018-01-31 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84143

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-31
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

Note that

print *, x%n

gives 0. Should not it be 3?