public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug fortran/95366] New: TYPE IS(character(*)) no longer matches
@ 2020-05-27 13:55 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
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: gcc at abeckmann dot de @ 2020-05-27 13:55 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug fortran/95366] [10/11 Regression] TYPE IS(character(*)) no longer matches since r10-3605-gf61e54e59cda5a2e 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 ` marxin at gcc dot gnu.org 2020-05-28 7:35 ` rguenth at gcc dot gnu.org ` (4 subsequent siblings) 5 siblings, 0 replies; 7+ messages in thread From: marxin at gcc dot gnu.org @ 2020-05-27 14:27 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/95366] [10/11 Regression] TYPE IS(character(*)) no longer matches since r10-3605-gf61e54e59cda5a2e 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 ` (3 subsequent siblings) 5 siblings, 0 replies; 7+ messages in thread From: rguenth at gcc dot gnu.org @ 2020-05-28 7:35 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/95366] [10/11 Regression] TYPE IS(character(*)) no longer matches since r10-3605-gf61e54e59cda5a2e 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 ` (2 subsequent siblings) 5 siblings, 0 replies; 7+ messages in thread From: tkoenig at gcc dot gnu.org @ 2020-06-13 7:13 UTC (permalink / raw) To: gcc-bugs 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? ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/95366] [10/11 Regression] TYPE IS(character(*)) no longer matches since r10-3605-gf61e54e59cda5a2e 2020-05-27 13:55 [Bug fortran/95366] New: TYPE IS(character(*)) no longer matches gcc at abeckmann dot de ` (2 preceding siblings ...) 2020-06-13 7:13 ` tkoenig at gcc dot gnu.org @ 2020-06-30 13:59 ` tkoenig at gcc dot gnu.org 2020-07-05 17:51 ` cvs-commit at gcc dot gnu.org 2020-07-05 17:52 ` tkoenig at gcc dot gnu.org 5 siblings, 0 replies; 7+ messages in thread From: tkoenig at gcc dot gnu.org @ 2020-06-30 13:59 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/95366] [10/11 Regression] TYPE IS(character(*)) no longer matches since r10-3605-gf61e54e59cda5a2e 2020-05-27 13:55 [Bug fortran/95366] New: TYPE IS(character(*)) no longer matches gcc at abeckmann dot de ` (3 preceding siblings ...) 2020-06-30 13:59 ` tkoenig at gcc dot gnu.org @ 2020-07-05 17:51 ` cvs-commit at gcc dot gnu.org 2020-07-05 17:52 ` tkoenig at gcc dot gnu.org 5 siblings, 0 replies; 7+ messages in thread From: cvs-commit at gcc dot gnu.org @ 2020-07-05 17:51 UTC (permalink / raw) To: gcc-bugs 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) ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/95366] [10/11 Regression] TYPE IS(character(*)) no longer matches since r10-3605-gf61e54e59cda5a2e 2020-05-27 13:55 [Bug fortran/95366] New: TYPE IS(character(*)) no longer matches gcc at abeckmann dot de ` (4 preceding siblings ...) 2020-07-05 17:51 ` cvs-commit at gcc dot gnu.org @ 2020-07-05 17:52 ` tkoenig at gcc dot gnu.org 5 siblings, 0 replies; 7+ messages in thread From: tkoenig at gcc dot gnu.org @ 2020-07-05 17:52 UTC (permalink / raw) To: gcc-bugs 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! ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-07-05 17:52 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 2020-07-05 17:51 ` cvs-commit at gcc dot gnu.org 2020-07-05 17:52 ` tkoenig at gcc dot gnu.org
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).