public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "tkoenig at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/95366] [10/11 Regression] TYPE IS(character(*)) no longer matches since r10-3605-gf61e54e59cda5a2e
Date: Tue, 30 Jun 2020 13:59:48 +0000	[thread overview]
Message-ID: <bug-95366-4-yF2ycdExOo@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-95366-4@http.gcc.gnu.org/bugzilla/>

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.

  parent reply	other threads:[~2020-06-30 13:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-27 13:55 [Bug fortran/95366] New: TYPE IS(character(*)) no longer matches gcc at abeckmann dot de
2020-05-27 14:27 ` [Bug fortran/95366] [10/11 Regression] TYPE IS(character(*)) no longer matches since r10-3605-gf61e54e59cda5a2e marxin at gcc dot gnu.org
2020-05-28  7:35 ` rguenth at gcc dot gnu.org
2020-06-13  7:13 ` tkoenig at gcc dot gnu.org
2020-06-30 13:59 ` tkoenig at gcc dot gnu.org [this message]
2020-07-05 17:51 ` cvs-commit at gcc dot gnu.org
2020-07-05 17:52 ` tkoenig at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-95366-4-yF2ycdExOo@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).