[Bug fortran/95366] New: TYPE IS(character(*)) no longer matches

[Bug fortran/95366] New: TYPE IS(character(*)) no longer matches

[gcc at abeckmann dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95366

            Bug ID: 95366
           Summary: TYPE IS(character(*)) no longer matches
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc at abeckmann dot de
  Target Milestone: ---

Created attachment 48618
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48618&action=edit
2 modules and a main program that demonstrate the bug

This is a regression in gfortran-10: in some cases 
  SELECT TYPE (arg)
  TYPE IS(CHARACTER(*))
    ...
  CLASS DEFAULT
    ...
does not match a polymorphic (class(*)) argument as character but falls through
to the class default, even though the subroutine was called with a
character(len=42) argument. This bug seems require caller and callee residing
in different modules (i.e. different compilation units).

A test case is attached:

gfortran-10 -W -Wall -Wextra  -c -o mod1.o mod1.f90
gfortran-10 -W -Wall -Wextra  -c -o mod2.o mod2.f90
gfortran-10 -W -Wall -Wextra  -c -o main.o main.f90
gfortran-10 main.o mod1.o mod2.o
./a.out
 int
 unknown

while building with gfortran-9 works:

gfortran-9 -W -Wall -Wextra  -c -o mod1.o mod1.f90
gfortran-9 -W -Wall -Wextra  -c -o mod2.o mod2.f90
gfortran-9 -W -Wall -Wextra  -c -o main.o main.f90
gfortran-9 main.o mod1.o mod2.o
./a.out
 int
 char

I observed this with the Debian 10.1.0-2 build (corresponding to git as of
20200515) and I could confirm it with git master
(6c8e16aea85286721eb5689f9bcae09d36003cb1).

[Bug fortran/95366] [10/11 Regression] TYPE IS(character(*)) no longer matches since r10-3605-gf61e54e59cda5a2e

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95366

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-05-27
                 CC|                            |markeggleston at gcc dot gnu.org,
                   |                            |marxin at gcc dot gnu.org
            Summary|TYPE IS(character(*)) no    |[10/11 Regression] TYPE
                   |longer matches              |IS(character(*)) no longer
                   |                            |matches since
                   |                            |r10-3605-gf61e54e59cda5a2e
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Confirmed, started with r10-3605-gf61e54e59cda5a2e.

[Bug fortran/95366] [10/11 Regression] TYPE IS(character(*)) no longer matches since r10-3605-gf61e54e59cda5a2e

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95366

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.2
           Priority|P3                          |P4

[Bug fortran/95366] [10/11 Regression] TYPE IS(character(*)) no longer matches since r10-3605-gf61e54e59cda5a2e

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95366

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tkoenig at gcc dot gnu.org

--- Comment #2 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Mark, can you take this on?

[Bug fortran/95366] [10/11 Regression] TYPE IS(character(*)) no longer matches since r10-3605-gf61e54e59cda5a2e

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95366

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ABI
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |tkoenig at gcc dot gnu.org

--- Comment #3 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
The problem is in the hash, only a single bit seems to be different:

+++ mod1.f90.004t.original      2020-06-30 07:14:25.582667830 +0000
@@ -105,7 +105,7 @@
           }
           goto L.2;
         }
-      if (poly->_vptr->_hash == 85893463)
+      if (poly->_vptr->_hash == 85827864)
         {
           {
             integer(kind=8) D.2336;

--- Comment #4 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
And there are the diffs of the unzipped module files:

[tkoenig@gcc135 Bad]$ diff ../Good/mod1.unzip mod1.unzip
37c37
< UNKNOWN 0 0) PRIVATE (CONSTANT (INTEGER 4 0 0 0 INTEGER ()) 0 '85893463'
---
> UNKNOWN 0 0) PRIVATE (CONSTANT (INTEGER 4 0 0 0 INTEGER ()) 0 '85827864'
[tkoenig@gcc135 Bad]$ diff ../Good/mod2.unzip mod2.unzip
24c24
< UNKNOWN 0 0) PRIVATE (CONSTANT (INTEGER 4 0 0 0 INTEGER ()) 0 '85893463'
---
> UNKNOWN 0 0) PRIVATE (CONSTANT (INTEGER 4 0 0 0 INTEGER ()) 0 '16547404'

Seems that change also broke the ABI :-(

--- Comment #5 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Here are the differences in the -fdump-fortran-original files:

--- ../Good/main.dump   2020-06-30 08:11:42.135005236 +0000
+++ main.dump   2020-06-30 08:09:57.907665704 +0000
@@ -4,7 +4,7 @@
   symtree: '__vtab_CHARACTER_1_'|| symbol: '__vtab_CHARACTER_1_' 
     type spec : (DERIVED __vtype_CHARACTER_1_)
     attributes: (VARIABLE IMPLICIT-SAVE TARGET USE-ASSOC(mod2))
-    value: __vtype_CHARACTER_1_(85893463 , () , () , () , () , NULL())
+    value: __vtype_CHARACTER_1_(16547404 , () , () , () , () , NULL())
   symtree: '__vtab_INTEGER_4_'|| symbol: '__vtab_INTEGER_4_' 
     type spec : (DERIVED __vtype_INTEGER_4_)
     attributes: (VARIABLE IMPLICIT-SAVE TARGET USE-ASSOC(mod2))
--- ../Good/mod1.dump   2020-06-30 08:08:08.780451149 +0000
+++ mod1.dump   2020-06-30 08:07:32.811369252 +0000
@@ -14,7 +14,7 @@
   symtree: '__vtab_CHARACTER_1_'|| symbol: '__vtab_CHARACTER_1_' 
     type spec : (DERIVED __vtype_CHARACTER_1_)
     attributes: (VARIABLE PUBLIC IMPLICIT-SAVE TARGET)
-    value: __vtype_CHARACTER_1_(85893463 , 1_8 , NULL() , NULL() ,
__copy_character_1:__copy_character_1 , NULL())
+    value: __vtype_CHARACTER_1_(85827864 , 1_8 , NULL() , NULL() ,
__copy_character_1:__copy_character_1 , NULL())
   symtree: '__vtab_INTEGER_4_'|| symbol: '__vtab_INTEGER_4_' 
     type spec : (DERIVED __vtype_INTEGER_4_)
     attributes: (VARIABLE PUBLIC IMPLICIT-SAVE TARGET)
@@ -143,7 +143,7 @@
         DT_END
       END ASSOCIATE 

-      CASE (_loc[((mod1:__vtab_CHARACTER_1_))] 85893463) 
+      CASE (_loc[((mod1:__vtab_CHARACTER_1_))] 85827864) 

       ASSOCIATE   = showpoly:poly % _data(FULL)
         symtree: 'block@3'     || symbol: 'block@3'      
--- ../Good/mod2.dump   2020-06-30 08:09:18.888661654 +0000
+++ mod2.dump   2020-06-30 08:08:55.019270915 +0000
@@ -4,7 +4,7 @@
   symtree: '__vtab_CHARACTER_1_'|| symbol: '__vtab_CHARACTER_1_' 
     type spec : (DERIVED __vtype_CHARACTER_1_)
     attributes: (VARIABLE PUBLIC IMPLICIT-SAVE TARGET)
-    value: __vtype_CHARACTER_1_(85893463 , 1_8 , NULL() , NULL() ,
__copy_character_1:__copy_character_1 , NULL())
+    value: __vtype_CHARACTER_1_(16547404 , 1_8 , NULL() , NULL() ,
__copy_character_1:__copy_character_1 , NULL())
   symtree: '__vtab_INTEGER_4_'|| symbol: '__vtab_INTEGER_4_' 
     type spec : (DERIVED __vtype_INTEGER_4_)
     attributes: (VARIABLE PUBLIC IMPLICIT-SAVE TARGET)
@@ -90,7 +90,7 @@
     symtree: '__vtab_CHARACTER_1_'|| symbol: '__vtab_CHARACTER_1_' 
       type spec : (DERIVED __vtype_CHARACTER_1_)
       attributes: (VARIABLE IMPLICIT-SAVE TARGET USE-ASSOC(mod1))
-      value: __vtype_CHARACTER_1_(85893463 , () , () , () , () , NULL())
+      value: __vtype_CHARACTER_1_(85827864 , () , () , () , () , NULL())
     symtree: '__vtab_INTEGER_4_'|| symbol: '__vtab_INTEGER_4_' 
       type spec : (DERIVED __vtype_INTEGER_4_)
       attributes: (VARIABLE IMPLICIT-SAVE TARGET USE-ASSOC(mod1))

So, basically the hash values for CHARACTER are all over the place.

--- Comment #6 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
In the bad revision, gfc_typename returns CHARACTER(0), in the
good revision CHARACTER(1).

--- Comment #7 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 2b760efe8d7..08705c7e95d 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -564,7 +564,7 @@ unsigned int
 gfc_intrinsic_hash_value (gfc_typespec *ts)
 {
   unsigned int hash = 0;
-  const char *c = gfc_typename (ts);
+  const char *c = gfc_typename (ts, true);
   int i, len;

   len = strlen (c);
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 836e0b3063d..24c5101c4cb 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -2931,7 +2931,7 @@ void gfc_clear_ts (gfc_typespec *);
 FILE *gfc_open_file (const char *);
 const char *gfc_basic_typename (bt);
 const char *gfc_dummy_typename (gfc_typespec *);
-const char *gfc_typename (gfc_typespec *);
+const char *gfc_typename (gfc_typespec *, bool for_hash = false);
 const char *gfc_typename (gfc_expr *);
 const char *gfc_op2string (gfc_intrinsic_op);
 const char *gfc_code2string (const mstring *, int);
diff --git a/gcc/fortran/misc.c b/gcc/fortran/misc.c
index 46c6277c2b9..25aefd3ab36 100644
--- a/gcc/fortran/misc.c
+++ b/gcc/fortran/misc.c
@@ -122,7 +122,7 @@ gfc_basic_typename (bt type)
    the argument list of a single statement.  */

 const char *
-gfc_typename (gfc_typespec *ts)
+gfc_typename (gfc_typespec *ts, bool for_hash)
 {
   static char buffer1[GFC_MAX_SYMBOL_LEN + 7];  /* 7 for "TYPE()" + '\0'.  */
   static char buffer2[GFC_MAX_SYMBOL_LEN + 7];
@@ -149,6 +149,10 @@ gfc_typename (gfc_typespec *ts)
       sprintf (buffer, "LOGICAL(%d)", ts->kind);
       break;
     case BT_CHARACTER:
+      if (for_hash)
+       sprintf (buffer, "CHARACTER(%d)", ts->kind);
+      break;
+
       if (ts->u.cl && ts->u.cl->length)
        length = gfc_mpz_get_hwi (ts->u.cl->length->value.integer);
       if (ts->kind == gfc_default_character_kind)


looks reasonably simple.

--- Comment #8 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
https://gcc.gnu.org/g:5958b926dcc3332aec0a2e34653c4394d2613401

commit r11-1729-g5958b926dcc3332aec0a2e34653c4394d2613401
Got the PR number wrong in the commit message...

Author: Thomas Koenig <tkoenig@gcc.gnu.org>
Date:   Tue Jun 30 13:01:36 2020 +0200

    Use CHARACTER(kind) string for calculating the type hash.

    This regression came about because of a change in the way
    types are displayed in error messages.  The character
    representation is also used to calculate the hashes for
    our types, so this patch restores the old behavior if
    we are indeed calculating a hash.

    The test case also checks for the specific hash value because
    changing that would be an ABI change, which we should not
    be doing unintentionally.

    gcc/fortran/ChangeLog:

    2020-06-30  Thomas Koenig  <tkoenig@gcc.gnu.org>

            PR fortran/95355
            * gfortran.h (gfc_typename): Add optional argument for_hash.
            * misc.c (gfc_typename): When for_hash is true, just retur
              CHARACTER(kind).
            * class.c (gfc_intrinsic_hash_value): Call gfc_typename with
              for_hash = true.

[Bug fortran/95366] [10/11 Regression] TYPE IS(character(*)) no longer matches since r10-3605-gf61e54e59cda5a2e

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95366

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Thomas Kथà¤nig
<tkoenig@gcc.gnu.org>:

https://gcc.gnu.org/g:858b288d2a6afc2f71f817344be3af4b7c3d4b3f

commit r10-8427-g858b288d2a6afc2f71f817344be3af4b7c3d4b3f
Author: Thomas Koenig <tkoenig@gcc.gnu.org>
Date:   Tue Jun 30 13:01:36 2020 +0200

    Use CHARACTER(kind) string for calculating the type hash.

    This regression came about because of a change in the way
    types are displayed in error messages.  The character
    representation is also used to calculate the hashes for
    our types, so this patch restores the old behavior if
    we are indeed calculating a hash.

    The test case also checks for the specific hash value because
    changing that would be an ABI change, which we should not
    be doing unintentionally.

    gcc/fortran/ChangeLog:

    2020-06-30  Thomas Koenig  <tkoenig@gcc.gnu.org>

            PR fortran/95366
            * gfortran.h (gfc_typename): Add optional argument for_hash.
            * misc.c (gfc_typename): When for_hash is true, just retur
              CHARACTER(kind).
            * class.c (gfc_intrinsic_hash_value): Call gfc_typename with
              for_hash = true.

    (cherry picked from commit 5958b926dcc3332aec0a2e34653c4394d2613401)

[Bug fortran/95366] [10/11 Regression] TYPE IS(character(*)) no longer matches since r10-3605-gf61e54e59cda5a2e

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95366

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #10 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Fixed in time for gcc 10.2.

Thanks a lot for the bug report!