* ICE in gfc_new_symbol() due to overlong symbol name @ 2018-08-25 20:51 Andrew Benson 2018-09-04 16:43 ` [patch, fortan] PR87103 - [OOP] " Andrew Benson 0 siblings, 1 reply; 25+ messages in thread From: Andrew Benson @ 2018-08-25 20:51 UTC (permalink / raw) To: fortran I just opened PR for this: 87103 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87103 The following code causes an ICE with gfortan 9.0.0 (r263855): module a type :: nameThatIsVeryLongButNotTooLongThatItShouldBeInvalid end type nameThatIsVeryLongButNotTooLongThatItShouldBeInvalid contains subroutine b(self) class(nameThatIsVeryLongButNotTooLongThatItShouldBeInvalid), intent(in) :: self select type (self) class is (nameThatIsVeryLongButNotTooLongThatItShouldBeInvalid) end select end subroutine b end module a $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc- linux-gnu/9.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran --disable-multilib : (reconfigured) ../gcc- trunk/configure --prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c+ +,fortran --disable-multilib : (reconfigured) ../gcc-trunk/configure --prefix=/ home/abenson/Galacticus/Tools --disable-multilib --enable-languages=c,c+ +,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools --disable-multilib --enable- languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc- trunk/configure --prefix=/home/abenson/Galacticus/Tools --disable-multilib -- enable-languages=c,c++,fortran,lto --no-create --no-recursion Thread model: posix gcc version 9.0.0 20180825 (experimental) (GCC) $ gfortran -c tmp1.F90 -o tmp1.o f951: internal compiler error: new_symbol(): Symbol name too long 0x7b9711 gfc_internal_error(char const*, ...) ../../gcc-trunk/gcc/fortran/error.c:1362 0x84a838 gfc_new_symbol(char const*, gfc_namespace*) ../../gcc-trunk/gcc/fortran/symbol.c:3132 0x84ab97 gfc_get_sym_tree(char const*, gfc_namespace*, gfc_symtree**, bool) ../../gcc-trunk/gcc/fortran/symbol.c:3373 0x7e565d select_type_set_tmp ../../gcc-trunk/gcc/fortran/match.c:6114 0x7ee260 gfc_match_class_is() ../../gcc-trunk/gcc/fortran/match.c:6470 0x808c79 match_word ../../gcc-trunk/gcc/fortran/parse.c:65 0x80a4f1 decode_statement ../../gcc-trunk/gcc/fortran/parse.c:462 0x80d04c next_free ../../gcc-trunk/gcc/fortran/parse.c:1234 0x80d04c next_statement ../../gcc-trunk/gcc/fortran/parse.c:1466 0x810861 parse_select_type_block ../../gcc-trunk/gcc/fortran/parse.c:4236 0x810861 parse_executable ../../gcc-trunk/gcc/fortran/parse.c:5330 0x8118e6 parse_progunit ../../gcc-trunk/gcc/fortran/parse.c:5697 0x811bfc parse_contained ../../gcc-trunk/gcc/fortran/parse.c:5574 0x812a4c parse_module ../../gcc-trunk/gcc/fortran/parse.c:5944 0x812f75 gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:6247 0x859d3f gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:204 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. The problem seems to be that gfc_new_symbol() is passed a name '__tmp_class_namethatisverylongbutnottoolongthatitshouldbeinvalid' in this case which exceeds GFC_MAX_SYMBOL_LEN=64. My understanding is that the code is valid since the symbol name itself, 'namethatisverylongbutnottoolongthatitshouldbeinvalid', is less than 64 characters. I'm not sure what the correct fix for this is - should the name length limit in gfc_new_symbol() just be increased by enough to allow the '__tmp_class_' prefix? This appears to be a regression as the same code (with the same long-but- legal) symbol names compiled under earlier versions of gfortran. I'll attempt to rollback to previous versions and see if I can identify where the change occurred. -Andrew -- * Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html * Galacticus: https://bitbucket.org/abensonca/galacticus ^ permalink raw reply [flat|nested] 25+ messages in thread
* [patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name 2018-08-25 20:51 ICE in gfc_new_symbol() due to overlong symbol name Andrew Benson @ 2018-09-04 16:43 ` Andrew Benson 2018-09-04 17:43 ` Bernhard Reutner-Fischer ` (2 more replies) 0 siblings, 3 replies; 25+ messages in thread From: Andrew Benson @ 2018-09-04 16:43 UTC (permalink / raw) To: fortran, gcc-patches [-- Attachment #1: Type: text/plain, Size: 4437 bytes --] As suggested by Janus, PR87103 is easily fixed by the attached patch which increases GFC_MAX_SYMBOL_LEN to 76 (sufficient to hold the maximum allowed F08 symbol length of 63, plus a null terminator, plus the "__tmp_class_" prefix). Bootstraps and regtests successfully. OK for trunk? -Andrew On Saturday, August 25, 2018 1:50:57 PM PDT Andrew Benson wrote: > I just opened PR for this: 87103 > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87103 > > The following code causes an ICE with gfortan 9.0.0 (r263855): > > module a > type :: nameThatIsVeryLongButNotTooLongThatItShouldBeInvalid > end type nameThatIsVeryLongButNotTooLongThatItShouldBeInvalid > contains > subroutine b(self) > class(nameThatIsVeryLongButNotTooLongThatItShouldBeInvalid), intent(in) > :: self > select type (self) > class is (nameThatIsVeryLongButNotTooLongThatItShouldBeInvalid) > end select > end subroutine b > end module a > > $ gfortran -v > Using built-in specs. > COLLECT_GCC=gfortran > COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc- > linux-gnu/9.0.0/lto-wrapper > Target: x86_64-pc-linux-gnu > Configured with: ../gcc-trunk/configure > --prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran > --disable-multilib : (reconfigured) ../gcc- trunk/configure > --prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c+ +,fortran > --disable-multilib : (reconfigured) ../gcc-trunk/configure --prefix=/ > home/abenson/Galacticus/Tools --disable-multilib --enable-languages=c,c+ > +,fortran,lto --no-create --no-recursion : (reconfigured) > ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools > --disable-multilib --enable- languages=c,c++,fortran,lto --no-create > --no-recursion : (reconfigured) ../gcc- trunk/configure > --prefix=/home/abenson/Galacticus/Tools --disable-multilib -- > enable-languages=c,c++,fortran,lto --no-create --no-recursion > Thread model: posix > gcc version 9.0.0 20180825 (experimental) (GCC) > > > $ gfortran -c tmp1.F90 -o tmp1.o > f951: internal compiler error: new_symbol(): Symbol name too long > 0x7b9711 gfc_internal_error(char const*, ...) > ../../gcc-trunk/gcc/fortran/error.c:1362 > 0x84a838 gfc_new_symbol(char const*, gfc_namespace*) > ../../gcc-trunk/gcc/fortran/symbol.c:3132 > 0x84ab97 gfc_get_sym_tree(char const*, gfc_namespace*, gfc_symtree**, bool) > ../../gcc-trunk/gcc/fortran/symbol.c:3373 > 0x7e565d select_type_set_tmp > ../../gcc-trunk/gcc/fortran/match.c:6114 > 0x7ee260 gfc_match_class_is() > ../../gcc-trunk/gcc/fortran/match.c:6470 > 0x808c79 match_word > ../../gcc-trunk/gcc/fortran/parse.c:65 > 0x80a4f1 decode_statement > ../../gcc-trunk/gcc/fortran/parse.c:462 > 0x80d04c next_free > ../../gcc-trunk/gcc/fortran/parse.c:1234 > 0x80d04c next_statement > ../../gcc-trunk/gcc/fortran/parse.c:1466 > 0x810861 parse_select_type_block > ../../gcc-trunk/gcc/fortran/parse.c:4236 > 0x810861 parse_executable > ../../gcc-trunk/gcc/fortran/parse.c:5330 > 0x8118e6 parse_progunit > ../../gcc-trunk/gcc/fortran/parse.c:5697 > 0x811bfc parse_contained > ../../gcc-trunk/gcc/fortran/parse.c:5574 > 0x812a4c parse_module > ../../gcc-trunk/gcc/fortran/parse.c:5944 > 0x812f75 gfc_parse_file() > ../../gcc-trunk/gcc/fortran/parse.c:6247 > 0x859d3f gfc_be_parse_file > ../../gcc-trunk/gcc/fortran/f95-lang.c:204 > Please submit a full bug report, > with preprocessed source if appropriate. > Please include the complete backtrace with any bug report. > See <https://gcc.gnu.org/bugs/> for instructions. > > > The problem seems to be that gfc_new_symbol() is passed a name > '__tmp_class_namethatisverylongbutnottoolongthatitshouldbeinvalid' in this > case which exceeds GFC_MAX_SYMBOL_LEN=64. My understanding is that the code > is valid since the symbol name itself, > 'namethatisverylongbutnottoolongthatitshouldbeinvalid', is less than 64 > characters. > > I'm not sure what the correct fix for this is - should the name length limit > in gfc_new_symbol() just be increased by enough to allow the '__tmp_class_' > prefix? > > This appears to be a regression as the same code (with the same long-but- > legal) symbol names compiled under earlier versions of gfortran. I'll > attempt to rollback to previous versions and see if I can identify where > the change occurred. > > -Andrew [-- Attachment #2: ChangeLog --] [-- Type: text/x-changelog, Size: 221 bytes --] 2018-09-04 Andrew Benson <abensonca@gmail.com> * gfortan.h: Increase GFC_MAX_SYMBOL_LEN to 76, sufficient to hold the maximum allowed F08 symbol length of 63, plus a null terminator, plus the "__tmp_class_" prefix. [-- Attachment #3: patch.diff --] [-- Type: text/x-patch, Size: 576 bytes --] Index: gcc/fortran/gfortran.h =================================================================== --- gcc/fortran/gfortran.h (revision 264085) +++ gcc/fortran/gfortran.h (working copy) @@ -54,7 +54,9 @@ not after. /* Major control parameters. */ -#define GFC_MAX_SYMBOL_LEN 63 /* Must be at least 63 for F2003. */ +/* Must be at least 63 for F2003, +1 for null terminator, + +12 for prefix "__tmp_class_". */ +#define GFC_MAX_SYMBOL_LEN 76 #define GFC_LETTERS 26 /* Number of letters in the alphabet. */ #define MAX_SUBRECORD_LENGTH 2147483639 /* 2**31-9 */ ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name 2018-09-04 16:43 ` [patch, fortan] PR87103 - [OOP] " Andrew Benson @ 2018-09-04 17:43 ` Bernhard Reutner-Fischer [not found] ` <5aa0135b-1bdd-46de-e235-daed0a9a97e1@charter.net> 2020-01-27 20:57 ` [patch, fortran] PR93461 - Bogus "symbol is already defined" with long subroutine names in submodule Andrew Benson 2020-01-27 23:41 ` [patch, fortran] PR93473 - ICE on valid with long module + submodule names Andrew Benson 2 siblings, 1 reply; 25+ messages in thread From: Bernhard Reutner-Fischer @ 2018-09-04 17:43 UTC (permalink / raw) To: abenson; +Cc: gfortran, GCC Patches On Tue, 4 Sep 2018 at 18:43, Andrew Benson <abenson@carnegiescience.edu> wrote: > > As suggested by Janus, PR87103 is easily fixed by the attached patch which > increases GFC_MAX_SYMBOL_LEN to 76 (sufficient to hold the maximum allowed F08 > symbol length of 63, plus a null terminator, plus the "__tmp_class_" prefix). This is so much wrong. Note that this will be fixed properly by the changes contained in the https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/aldot/fortran-fe-stringpool branch. There we keep the GFC_MAX_SYMBOL_LEN at 63 proper but use an internal buffer double that size which in turn is sufficient to hold all compiler-generated identifiers. See gfc_get_string() even in current TOT. Maybe we should bite the bullet and start to merge the stringpool changes now instead of this hack? thanks and cheers, ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <5aa0135b-1bdd-46de-e235-daed0a9a97e1@charter.net>]
* Re: [patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name [not found] ` <5aa0135b-1bdd-46de-e235-daed0a9a97e1@charter.net> @ 2018-09-05 10:35 ` Bernhard Reutner-Fischer 2018-09-05 14:24 ` Andrew Benson 2019-08-24 21:15 ` Andrew Benson 0 siblings, 2 replies; 25+ messages in thread From: Bernhard Reutner-Fischer @ 2018-09-05 10:35 UTC (permalink / raw) To: Jerry DeLisle, gfortran, GCC Patches [-- Attachment #1: Type: text/plain, Size: 2071 bytes --] On Wed, 5 Sep 2018 at 03:30, Jerry DeLisle <jvdelisle@charter.net> wrote: > > On 09/04/2018 10:43 AM, Bernhard Reutner-Fischer wrote: > > On Tue, 4 Sep 2018 at 18:43, Andrew Benson <abenson@carnegiescience.edu> wrote: > >> > >> As suggested by Janus, PR87103 is easily fixed by the attached patch which > >> increases GFC_MAX_SYMBOL_LEN to 76 (sufficient to hold the maximum allowed F08 > >> symbol length of 63, plus a null terminator, plus the "__tmp_class_" prefix). > > > > This is so much wrong. > > Note that this will be fixed properly by the changes contained in the > > https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/aldot/fortran-fe-stringpool > > branch. > > There we keep the GFC_MAX_SYMBOL_LEN at 63 proper but use an internal > > buffer double that size which in turn is sufficient to hold all > > compiler-generated identifiers. > > See gfc_get_string() even in current TOT. > > > > Maybe we should bite the bullet and start to merge the stringpool > > changes now instead of this hack? > > It all makes sense to me, please proceed. (my 2 cents worth) Ok so i will reread the fortran-fe-stringpool series and submit it here for review. Let's return to the issue at hand for a moment, though. I tested the attached alternate fix on top of the fortran-fe-stringpool branch where it fixes PR87103. Maybe somebody has spare cycles to test it on top of current trunk? thanks, [PATCH,FORTRAN] PR87103: Remove max symbol length check from gfc_new_symbol gfc_match_name does check for too long names already. Since gfc_new_symbol is also called for symbols with internal names containing compiler-generated prefixes, these internal names can easily exceed the max_identifier_length mandated by the standard. gcc/fortran/ChangeLog 2018-09-04 Bernhard Reutner-Fischer <aldot@gcc.gnu.org> PR fortran/87103 * expr.c (gfc_check_conformance): Check vsnprintf for truncation. * iresolve.c (gfc_get_string): Likewise. * symbol.c (gfc_new_symbol): Remove check for maximum symbol name length. Remove redundant 0 setting of new calloc()ed gfc_symbol. [-- Attachment #2: pr87103-alt.00.patch --] [-- Type: text/x-patch, Size: 2692 bytes --] Remove max symbol length check from gfc_new_symbol gfc_match_name does check for too long names already. Since gfc_new_symbol is also called for symbols with internal names containing compiler-generated prefixes, these internal names can easily exceed the max_identifier_length mandated by the standard. gcc/fortran/ChangeLog 2018-09-04 Bernhard Reutner-Fischer <aldot@gcc.gnu.org> PR fortran/87103 * expr.c (gfc_check_conformance): Check vsnprintf for truncation. * iresolve.c (gfc_get_string): Likewise. * symbol.c (gfc_new_symbol): Remove check for maximum symbol name length. Remove redundant 0 setting of new calloc()ed gfc_symbol. diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c index c5bf822cd24..6b5671390ec 100644 --- a/gcc/fortran/expr.c +++ b/gcc/fortran/expr.c @@ -3225,8 +3225,10 @@ gfc_check_conformance (gfc_expr *op1, gfc_expr *op2, const char *optype_msgid, . return true; va_start (argp, optype_msgid); - vsnprintf (buffer, 240, optype_msgid, argp); + d = vsnprintf (buffer, sizeof (buffer), optype_msgid, argp); va_end (argp); + if (d < 1 || d >= (int) sizeof (buffer)) /* Reject truncation. */ + gfc_internal_error ("optype_msgid overflow: %d", d); if (op1->rank != op2->rank) { diff --git a/gcc/fortran/iresolve.c b/gcc/fortran/iresolve.c index 61663fec7e5..d7bd0545173 100644 --- a/gcc/fortran/iresolve.c +++ b/gcc/fortran/iresolve.c @@ -60,9 +60,12 @@ gfc_get_string (const char *format, ...) } else { + int ret; va_start (ap, format); - vsnprintf (temp_name, sizeof (temp_name), format, ap); + ret = vsnprintf (temp_name, sizeof (temp_name), format, ap); va_end (ap); + if (ret < 1 || ret >= (int) sizeof (temp_name)) /* Reject truncation. */ + gfc_internal_error ("identifier overflow: %d", ret); temp_name[sizeof (temp_name) - 1] = 0; str = temp_name; } diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c index cde34c67482..fc3354f0457 100644 --- a/gcc/fortran/symbol.c +++ b/gcc/fortran/symbol.c @@ -3142,25 +3142,9 @@ gfc_new_symbol (const char *name, gfc_namespace *ns) gfc_clear_ts (&p->ts); gfc_clear_attr (&p->attr); p->ns = ns; - p->declared_at = gfc_current_locus; - - if (strlen (name) > GFC_MAX_SYMBOL_LEN) - gfc_internal_error ("new_symbol(): Symbol name too long"); - p->name = gfc_get_string ("%s", name); - /* Make sure flags for symbol being C bound are clear initially. */ - p->attr.is_bind_c = 0; - p->attr.is_iso_c = 0; - - /* Clear the ptrs we may need. */ - p->common_block = NULL; - p->f2k_derived = NULL; - p->assoc = NULL; - p->dt_next = NULL; - p->fn_result_spec = 0; - return p; } ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name 2018-09-05 10:35 ` Bernhard Reutner-Fischer @ 2018-09-05 14:24 ` Andrew Benson 2019-08-24 21:15 ` Andrew Benson 1 sibling, 0 replies; 25+ messages in thread From: Andrew Benson @ 2018-09-05 14:24 UTC (permalink / raw) To: fortran; +Cc: Bernhard Reutner-Fischer, Jerry DeLisle, GCC Patches On Wednesday, September 5, 2018 12:35:04 PM PDT Bernhard Reutner-Fischer wrote: > On Wed, 5 Sep 2018 at 03:30, Jerry DeLisle <jvdelisle@charter.net> wrote: > > On 09/04/2018 10:43 AM, Bernhard Reutner-Fischer wrote: > > > On Tue, 4 Sep 2018 at 18:43, Andrew Benson <abenson@carnegiescience.edu> wrote: > > >> As suggested by Janus, PR87103 is easily fixed by the attached patch > > >> which > > >> increases GFC_MAX_SYMBOL_LEN to 76 (sufficient to hold the maximum > > >> allowed F08 symbol length of 63, plus a null terminator, plus the > > >> "__tmp_class_" prefix).> > > > > This is so much wrong. > > > Note that this will be fixed properly by the changes contained in the > > > https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/aldot/fortran > > > -fe-stringpool branch. > > > There we keep the GFC_MAX_SYMBOL_LEN at 63 proper but use an internal > > > buffer double that size which in turn is sufficient to hold all > > > compiler-generated identifiers. > > > See gfc_get_string() even in current TOT. > > > > > > Maybe we should bite the bullet and start to merge the stringpool > > > changes now instead of this hack? > > > > It all makes sense to me, please proceed. (my 2 cents worth) > > Ok so i will reread the fortran-fe-stringpool series and submit it > here for review. > > Let's return to the issue at hand for a moment, though. > I tested the attached alternate fix on top of the > fortran-fe-stringpool branch where it fixes PR87103. > Maybe somebody has spare cycles to test it on top of current trunk? > > thanks, > > [PATCH,FORTRAN] PR87103: Remove max symbol length check from gfc_new_symbol > > gfc_match_name does check for too long names already. Since > gfc_new_symbol is also called for symbols with internal names containing > compiler-generated prefixes, these internal names can easily exceed the > max_identifier_length mandated by the standard. > > gcc/fortran/ChangeLog > > 2018-09-04 Bernhard Reutner-Fischer <aldot@gcc.gnu.org> > > PR fortran/87103 > * expr.c (gfc_check_conformance): Check vsnprintf for truncation. > * iresolve.c (gfc_get_string): Likewise. > * symbol.c (gfc_new_symbol): Remove check for maximum symbol > name length. Remove redundant 0 setting of new calloc()ed > gfc_symbol. This patch tests successfully on the current trunk for me. -- * Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html * Galacticus: https://bitbucket.org/abensonca/galacticus ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name 2018-09-05 10:35 ` Bernhard Reutner-Fischer 2018-09-05 14:24 ` Andrew Benson @ 2019-08-24 21:15 ` Andrew Benson 2019-08-28 22:48 ` Bernhard Reutner-Fischer 1 sibling, 1 reply; 25+ messages in thread From: Andrew Benson @ 2019-08-24 21:15 UTC (permalink / raw) To: fortran; +Cc: Bernhard Reutner-Fischer, Jerry DeLisle, GCC Patches [-- Attachment #1: Type: text/plain, Size: 2664 bytes --] This PR is still open - I re-tested the patch on the current trunk. The patch still applies with some line offsets (I've attached the updated patch) and regtests cleanly. It would be very helpful to me to get this patch committed if possible. Thanks, Andrew On Wednesday, September 5, 2018 12:35:04 PM PDT Bernhard Reutner-Fischer wrote: > On Wed, 5 Sep 2018 at 03:30, Jerry DeLisle <jvdelisle@charter.net> wrote: > > On 09/04/2018 10:43 AM, Bernhard Reutner-Fischer wrote: > > > On Tue, 4 Sep 2018 at 18:43, Andrew Benson <abenson@carnegiescience.edu> wrote: > > >> As suggested by Janus, PR87103 is easily fixed by the attached patch > > >> which > > >> increases GFC_MAX_SYMBOL_LEN to 76 (sufficient to hold the maximum > > >> allowed F08 symbol length of 63, plus a null terminator, plus the > > >> "__tmp_class_" prefix).> > > > > This is so much wrong. > > > Note that this will be fixed properly by the changes contained in the > > > https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/aldot/fortran > > > -fe-stringpool branch. > > > There we keep the GFC_MAX_SYMBOL_LEN at 63 proper but use an internal > > > buffer double that size which in turn is sufficient to hold all > > > compiler-generated identifiers. > > > See gfc_get_string() even in current TOT. > > > > > > Maybe we should bite the bullet and start to merge the stringpool > > > changes now instead of this hack? > > > > It all makes sense to me, please proceed. (my 2 cents worth) > > Ok so i will reread the fortran-fe-stringpool series and submit it > here for review. > > Let's return to the issue at hand for a moment, though. > I tested the attached alternate fix on top of the > fortran-fe-stringpool branch where it fixes PR87103. > Maybe somebody has spare cycles to test it on top of current trunk? > > thanks, > > [PATCH,FORTRAN] PR87103: Remove max symbol length check from gfc_new_symbol > > gfc_match_name does check for too long names already. Since > gfc_new_symbol is also called for symbols with internal names containing > compiler-generated prefixes, these internal names can easily exceed the > max_identifier_length mandated by the standard. > > gcc/fortran/ChangeLog > > 2018-09-04 Bernhard Reutner-Fischer <aldot@gcc.gnu.org> > > PR fortran/87103 > * expr.c (gfc_check_conformance): Check vsnprintf for truncation. > * iresolve.c (gfc_get_string): Likewise. > * symbol.c (gfc_new_symbol): Remove check for maximum symbol > name length. Remove redundant 0 setting of new calloc()ed > gfc_symbol. -- * Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html * Galacticus: https://bitbucket.org/galacticusdev/galacticus [-- Attachment #2: pr87103-alt.01.patch --] [-- Type: text/x-patch, Size: 2099 bytes --] Index: gcc/fortran/expr.c =================================================================== --- gcc/fortran/expr.c (revision 274889) +++ gcc/fortran/expr.c (working copy) @@ -3467,8 +3467,10 @@ gfc_check_conformance (gfc_expr *op1, gfc_expr *op return true; va_start (argp, optype_msgid); - vsnprintf (buffer, 240, optype_msgid, argp); + d = vsnprintf (buffer, sizeof (buffer), optype_msgid, argp); va_end (argp); + if (d < 1 || d >= (int) sizeof (buffer)) /* Reject truncation. */ + gfc_internal_error ("optype_msgid overflow: %d", d); if (op1->rank != op2->rank) { Index: gcc/fortran/iresolve.c =================================================================== --- gcc/fortran/iresolve.c (revision 274889) +++ gcc/fortran/iresolve.c (working copy) @@ -61,9 +61,12 @@ gfc_get_string (const char *format, ...) } else { + int ret; va_start (ap, format); - vsnprintf (temp_name, sizeof (temp_name), format, ap); + ret = vsnprintf (temp_name, sizeof (temp_name), format, ap); va_end (ap); + if (ret < 1 || ret >= (int) sizeof (temp_name)) /* Reject truncation. */ + gfc_internal_error ("identifier overflow: %d", ret); temp_name[sizeof (temp_name) - 1] = 0; str = temp_name; } Index: gcc/fortran/symbol.c =================================================================== --- gcc/fortran/symbol.c (revision 274889) +++ gcc/fortran/symbol.c (working copy) @@ -3135,25 +3135,9 @@ gfc_new_symbol (const char *name, gfc_namespace *n gfc_clear_ts (&p->ts); gfc_clear_attr (&p->attr); p->ns = ns; - p->declared_at = gfc_current_locus; - - if (strlen (name) > GFC_MAX_SYMBOL_LEN) - gfc_internal_error ("new_symbol(): Symbol name too long"); - p->name = gfc_get_string ("%s", name); - /* Make sure flags for symbol being C bound are clear initially. */ - p->attr.is_bind_c = 0; - p->attr.is_iso_c = 0; - - /* Clear the ptrs we may need. */ - p->common_block = NULL; - p->f2k_derived = NULL; - p->assoc = NULL; - p->dt_next = NULL; - p->fn_result_spec = 0; - return p; } ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name 2019-08-24 21:15 ` Andrew Benson @ 2019-08-28 22:48 ` Bernhard Reutner-Fischer 2019-08-30 8:22 ` Andrew Benson 2020-01-29 20:19 ` Andrew Benson 0 siblings, 2 replies; 25+ messages in thread From: Bernhard Reutner-Fischer @ 2019-08-28 22:48 UTC (permalink / raw) To: Andrew Benson Cc: fortran, Jerry DeLisle, GCC Patches, Bernhard Reutner-Fischer On Fri, 23 Aug 2019 17:17:37 -0700 Andrew Benson <abenson@carnegiescience.edu> wrote: > This PR is still open - I re-tested the patch on the current trunk. The patch > still applies with some line offsets (I've attached the updated patch) and > regtests cleanly. It would be very helpful to me to get this patch committed > if possible. I think Jerry ACKed the patch back then. I'll try to find the time to commit it maybe during one of the coming weekends unless someone else beats me to it.. Thanks for the reminder! Bernhard > > Thanks, > Andrew > > On Wednesday, September 5, 2018 12:35:04 PM PDT Bernhard Reutner-Fischer > wrote: > > On Wed, 5 Sep 2018 at 03:30, Jerry DeLisle <jvdelisle@charter.net> wrote: > > > On 09/04/2018 10:43 AM, Bernhard Reutner-Fischer wrote: > > > > On Tue, 4 Sep 2018 at 18:43, Andrew Benson <abenson@carnegiescience.edu> > wrote: > > > >> As suggested by Janus, PR87103 is easily fixed by the attached patch > > > >> which > > > >> increases GFC_MAX_SYMBOL_LEN to 76 (sufficient to hold the maximum > > > >> allowed F08 symbol length of 63, plus a null terminator, plus the > > > >> "__tmp_class_" prefix).> > > > > > This is so much wrong. > > > > Note that this will be fixed properly by the changes contained in the > > > > https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/aldot/fortran > > > > -fe-stringpool branch. > > > > There we keep the GFC_MAX_SYMBOL_LEN at 63 proper but use an internal > > > > buffer double that size which in turn is sufficient to hold all > > > > compiler-generated identifiers. > > > > See gfc_get_string() even in current TOT. > > > > > > > > Maybe we should bite the bullet and start to merge the stringpool > > > > changes now instead of this hack? > > > > > > It all makes sense to me, please proceed. (my 2 cents worth) > > > > Ok so i will reread the fortran-fe-stringpool series and submit it > > here for review. > > > > Let's return to the issue at hand for a moment, though. > > I tested the attached alternate fix on top of the > > fortran-fe-stringpool branch where it fixes PR87103. > > Maybe somebody has spare cycles to test it on top of current trunk? > > > > thanks, > > > > [PATCH,FORTRAN] PR87103: Remove max symbol length check from gfc_new_symbol > > > > gfc_match_name does check for too long names already. Since > > gfc_new_symbol is also called for symbols with internal names containing > > compiler-generated prefixes, these internal names can easily exceed the > > max_identifier_length mandated by the standard. > > > > gcc/fortran/ChangeLog > > > > 2018-09-04 Bernhard Reutner-Fischer <aldot@gcc.gnu.org> > > > > PR fortran/87103 > > * expr.c (gfc_check_conformance): Check vsnprintf for truncation. > > * iresolve.c (gfc_get_string): Likewise. > > * symbol.c (gfc_new_symbol): Remove check for maximum symbol > > name length. Remove redundant 0 setting of new calloc()ed > > gfc_symbol. > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name 2019-08-28 22:48 ` Bernhard Reutner-Fischer @ 2019-08-30 8:22 ` Andrew Benson 2020-01-29 20:19 ` Andrew Benson 1 sibling, 0 replies; 25+ messages in thread From: Andrew Benson @ 2019-08-30 8:22 UTC (permalink / raw) To: Bernhard Reutner-Fischer; +Cc: fortran, Jerry DeLisle, GCC Patches Thanks Bernhard. On Wednesday, August 28, 2019 9:00:36 PM PDT Bernhard Reutner-Fischer wrote: > On Fri, 23 Aug 2019 17:17:37 -0700 > > Andrew Benson <abenson@carnegiescience.edu> wrote: > > This PR is still open - I re-tested the patch on the current trunk. The > > patch still applies with some line offsets (I've attached the updated > > patch) and regtests cleanly. It would be very helpful to me to get this > > patch committed if possible. > > I think Jerry ACKed the patch back then. I'll try to find the time to > commit it maybe during one of the coming weekends unless someone else > beats me to it.. > > Thanks for the reminder! > Bernhard > > > Thanks, > > Andrew > > > > On Wednesday, September 5, 2018 12:35:04 PM PDT Bernhard Reutner-Fischer > > > > wrote: > > > On Wed, 5 Sep 2018 at 03:30, Jerry DeLisle <jvdelisle@charter.net> wrote: > > > > On 09/04/2018 10:43 AM, Bernhard Reutner-Fischer wrote: > > > > > On Tue, 4 Sep 2018 at 18:43, Andrew Benson > > > > > <abenson@carnegiescience.edu> > > > > wrote: > > > > >> As suggested by Janus, PR87103 is easily fixed by the attached > > > > >> patch > > > > >> which > > > > >> increases GFC_MAX_SYMBOL_LEN to 76 (sufficient to hold the maximum > > > > >> allowed F08 symbol length of 63, plus a null terminator, plus the > > > > >> "__tmp_class_" prefix).> > > > > > > > > > > > This is so much wrong. > > > > > Note that this will be fixed properly by the changes contained in > > > > > the > > > > > https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/aldot/for > > > > > tran > > > > > -fe-stringpool branch. > > > > > There we keep the GFC_MAX_SYMBOL_LEN at 63 proper but use an > > > > > internal > > > > > buffer double that size which in turn is sufficient to hold all > > > > > compiler-generated identifiers. > > > > > See gfc_get_string() even in current TOT. > > > > > > > > > > Maybe we should bite the bullet and start to merge the stringpool > > > > > changes now instead of this hack? > > > > > > > > It all makes sense to me, please proceed. (my 2 cents worth) > > > > > > Ok so i will reread the fortran-fe-stringpool series and submit it > > > here for review. > > > > > > Let's return to the issue at hand for a moment, though. > > > I tested the attached alternate fix on top of the > > > fortran-fe-stringpool branch where it fixes PR87103. > > > Maybe somebody has spare cycles to test it on top of current trunk? > > > > > > thanks, > > > > > > [PATCH,FORTRAN] PR87103: Remove max symbol length check from > > > gfc_new_symbol > > > > > > gfc_match_name does check for too long names already. Since > > > gfc_new_symbol is also called for symbols with internal names containing > > > compiler-generated prefixes, these internal names can easily exceed the > > > max_identifier_length mandated by the standard. > > > > > > gcc/fortran/ChangeLog > > > > > > 2018-09-04 Bernhard Reutner-Fischer <aldot@gcc.gnu.org> > > > > > > PR fortran/87103 > > > * expr.c (gfc_check_conformance): Check vsnprintf for truncation. > > > * iresolve.c (gfc_get_string): Likewise. > > > * symbol.c (gfc_new_symbol): Remove check for maximum symbol > > > name length. Remove redundant 0 setting of new calloc()ed > > > gfc_symbol. -- * Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html * Galacticus: https://bitbucket.org/galacticusdev/galacticus ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name 2019-08-28 22:48 ` Bernhard Reutner-Fischer 2019-08-30 8:22 ` Andrew Benson @ 2020-01-29 20:19 ` Andrew Benson 2020-01-30 16:28 ` Bernhard Reutner-Fischer 1 sibling, 1 reply; 25+ messages in thread From: Andrew Benson @ 2020-01-29 20:19 UTC (permalink / raw) To: Bernhard Reutner-Fischer; +Cc: fortran, Jerry DeLisle, GCC Patches I think this patch is still waiting to be applied. I checked that it applies against trunk (with line offsets) and reg tests cleanly and posted an updated version (diff'd against current trunk) at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87103#c7 I'm happy to go ahead and commit this if Bernhard is ok with me doing so. -Andrew On Wednesday, August 28, 2019 9:00:36 PM PST Bernhard Reutner-Fischer wrote: > On Fri, 23 Aug 2019 17:17:37 -0700 > > Andrew Benson <abenson@carnegiescience.edu> wrote: > > This PR is still open - I re-tested the patch on the current trunk. The > > patch still applies with some line offsets (I've attached the updated > > patch) and regtests cleanly. It would be very helpful to me to get this > > patch committed if possible. > > I think Jerry ACKed the patch back then. I'll try to find the time to > commit it maybe during one of the coming weekends unless someone else > beats me to it.. > > Thanks for the reminder! > Bernhard > > > Thanks, > > Andrew > > > > On Wednesday, September 5, 2018 12:35:04 PM PDT Bernhard Reutner-Fischer > > > > wrote: > > > On Wed, 5 Sep 2018 at 03:30, Jerry DeLisle <jvdelisle@charter.net> wrote: > > > > On 09/04/2018 10:43 AM, Bernhard Reutner-Fischer wrote: > > > > > On Tue, 4 Sep 2018 at 18:43, Andrew Benson > > > > > <abenson@carnegiescience.edu> > > > > wrote: > > > > >> As suggested by Janus, PR87103 is easily fixed by the attached > > > > >> patch > > > > >> which > > > > >> increases GFC_MAX_SYMBOL_LEN to 76 (sufficient to hold the maximum > > > > >> allowed F08 symbol length of 63, plus a null terminator, plus the > > > > >> "__tmp_class_" prefix).> > > > > > > > > > > > This is so much wrong. > > > > > Note that this will be fixed properly by the changes contained in > > > > > the > > > > > https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/aldot/for > > > > > tran > > > > > -fe-stringpool branch. > > > > > There we keep the GFC_MAX_SYMBOL_LEN at 63 proper but use an > > > > > internal > > > > > buffer double that size which in turn is sufficient to hold all > > > > > compiler-generated identifiers. > > > > > See gfc_get_string() even in current TOT. > > > > > > > > > > Maybe we should bite the bullet and start to merge the stringpool > > > > > changes now instead of this hack? > > > > > > > > It all makes sense to me, please proceed. (my 2 cents worth) > > > > > > Ok so i will reread the fortran-fe-stringpool series and submit it > > > here for review. > > > > > > Let's return to the issue at hand for a moment, though. > > > I tested the attached alternate fix on top of the > > > fortran-fe-stringpool branch where it fixes PR87103. > > > Maybe somebody has spare cycles to test it on top of current trunk? > > > > > > thanks, > > > > > > [PATCH,FORTRAN] PR87103: Remove max symbol length check from > > > gfc_new_symbol > > > > > > gfc_match_name does check for too long names already. Since > > > gfc_new_symbol is also called for symbols with internal names containing > > > compiler-generated prefixes, these internal names can easily exceed the > > > max_identifier_length mandated by the standard. > > > > > > gcc/fortran/ChangeLog > > > > > > 2018-09-04 Bernhard Reutner-Fischer <aldot@gcc.gnu.org> > > > > > > PR fortran/87103 > > > * expr.c (gfc_check_conformance): Check vsnprintf for truncation. > > > * iresolve.c (gfc_get_string): Likewise. > > > * symbol.c (gfc_new_symbol): Remove check for maximum symbol > > > name length. Remove redundant 0 setting of new calloc()ed > > > gfc_symbol. -- * Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html * Galacticus: https://github.com/galacticusorg/galacticus ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name 2020-01-29 20:19 ` Andrew Benson @ 2020-01-30 16:28 ` Bernhard Reutner-Fischer 2020-01-30 17:50 ` Andrew Benson 0 siblings, 1 reply; 25+ messages in thread From: Bernhard Reutner-Fischer @ 2020-01-30 16:28 UTC (permalink / raw) To: Andrew Benson; +Cc: fortran, Jerry DeLisle, GCC Patches On 29 January 2020 21:19:52 CET, Andrew Benson <abenson@carnegiescience.edu> wrote: >I think this patch is still waiting to be applied. I checked that it >applies >against trunk (with line offsets) and reg tests cleanly and posted an >updated >version (diff'd against current trunk) at: > >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87103#c7 > >I'm happy to go ahead and commit this if Bernhard is ok with me doing >so. Please go ahead and push it. Many thanks in advance and sorry for the delay! thanks, > >-Andrew > >On Wednesday, August 28, 2019 9:00:36 PM PST Bernhard Reutner-Fischer >wrote: >> On Fri, 23 Aug 2019 17:17:37 -0700 >> >> Andrew Benson <abenson@carnegiescience.edu> wrote: >> > This PR is still open - I re-tested the patch on the current trunk. >The >> > patch still applies with some line offsets (I've attached the >updated >> > patch) and regtests cleanly. It would be very helpful to me to get >this >> > patch committed if possible. >> >> I think Jerry ACKed the patch back then. I'll try to find the time to >> commit it maybe during one of the coming weekends unless someone else >> beats me to it.. >> >> Thanks for the reminder! >> Bernhard >> >> > Thanks, >> > Andrew >> > >> > On Wednesday, September 5, 2018 12:35:04 PM PDT Bernhard >Reutner-Fischer >> > >> > wrote: >> > > On Wed, 5 Sep 2018 at 03:30, Jerry DeLisle ><jvdelisle@charter.net> >wrote: >> > > > On 09/04/2018 10:43 AM, Bernhard Reutner-Fischer wrote: >> > > > > On Tue, 4 Sep 2018 at 18:43, Andrew Benson >> > > > > <abenson@carnegiescience.edu> >> > >> > wrote: >> > > > >> As suggested by Janus, PR87103 is easily fixed by the >attached >> > > > >> patch >> > > > >> which >> > > > >> increases GFC_MAX_SYMBOL_LEN to 76 (sufficient to hold the >maximum >> > > > >> allowed F08 symbol length of 63, plus a null terminator, >plus the >> > > > >> "__tmp_class_" prefix).> > >> > > > > >> > > > > This is so much wrong. >> > > > > Note that this will be fixed properly by the changes >contained in >> > > > > the >> > > > > >https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/aldot/for >> > > > > tran >> > > > > -fe-stringpool branch. >> > > > > There we keep the GFC_MAX_SYMBOL_LEN at 63 proper but use an >> > > > > internal >> > > > > buffer double that size which in turn is sufficient to hold >all >> > > > > compiler-generated identifiers. >> > > > > See gfc_get_string() even in current TOT. >> > > > > >> > > > > Maybe we should bite the bullet and start to merge the >stringpool >> > > > > changes now instead of this hack? >> > > > >> > > > It all makes sense to me, please proceed. (my 2 cents worth) >> > > >> > > Ok so i will reread the fortran-fe-stringpool series and submit >it >> > > here for review. >> > > >> > > Let's return to the issue at hand for a moment, though. >> > > I tested the attached alternate fix on top of the >> > > fortran-fe-stringpool branch where it fixes PR87103. >> > > Maybe somebody has spare cycles to test it on top of current >trunk? >> > > >> > > thanks, >> > > >> > > [PATCH,FORTRAN] PR87103: Remove max symbol length check from >> > > gfc_new_symbol >> > > >> > > gfc_match_name does check for too long names already. Since >> > > gfc_new_symbol is also called for symbols with internal names >containing >> > > compiler-generated prefixes, these internal names can easily >exceed the >> > > max_identifier_length mandated by the standard. >> > > >> > > gcc/fortran/ChangeLog >> > > >> > > 2018-09-04 Bernhard Reutner-Fischer <aldot@gcc.gnu.org> >> > > >> > > PR fortran/87103 >> > > * expr.c (gfc_check_conformance): Check vsnprintf for truncation. >> > > * iresolve.c (gfc_get_string): Likewise. >> > > * symbol.c (gfc_new_symbol): Remove check for maximum symbol >> > > name length. Remove redundant 0 setting of new calloc()ed >> > > gfc_symbol. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name 2020-01-30 16:28 ` Bernhard Reutner-Fischer @ 2020-01-30 17:50 ` Andrew Benson 0 siblings, 0 replies; 25+ messages in thread From: Andrew Benson @ 2020-01-30 17:50 UTC (permalink / raw) To: Bernhard Reutner-Fischer; +Cc: fortran, Jerry DeLisle, GCC Patches Thanks Bernhard - this is now committed: https://gcc.gnu.org/g:004ac7b780308dc899e565b887c7def0a6e100f2 On Thursday, January 30, 2020 5:27:55 PM PST Bernhard Reutner-Fischer wrote: > On 29 January 2020 21:19:52 CET, Andrew Benson <abenson@carnegiescience.edu> wrote: > >I think this patch is still waiting to be applied. I checked that it > >applies > >against trunk (with line offsets) and reg tests cleanly and posted an > >updated > >version (diff'd against current trunk) at: > > > >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87103#c7 > > > >I'm happy to go ahead and commit this if Bernhard is ok with me doing > >so. > > Please go ahead and push it. > Many thanks in advance and sorry for the delay! > thanks, > > >-Andrew > > > >On Wednesday, August 28, 2019 9:00:36 PM PST Bernhard Reutner-Fischer > > > >wrote: > >> On Fri, 23 Aug 2019 17:17:37 -0700 > >> > >> Andrew Benson <abenson@carnegiescience.edu> wrote: > >> > This PR is still open - I re-tested the patch on the current trunk. > > > >The > > > >> > patch still applies with some line offsets (I've attached the > > > >updated > > > >> > patch) and regtests cleanly. It would be very helpful to me to get > > > >this > > > >> > patch committed if possible. > >> > >> I think Jerry ACKed the patch back then. I'll try to find the time to > >> commit it maybe during one of the coming weekends unless someone else > >> beats me to it.. > >> > >> Thanks for the reminder! > >> Bernhard > >> > >> > Thanks, > >> > Andrew > >> > > >> > On Wednesday, September 5, 2018 12:35:04 PM PDT Bernhard > > > >Reutner-Fischer > > > >> > wrote: > >> > > On Wed, 5 Sep 2018 at 03:30, Jerry DeLisle > > > ><jvdelisle@charter.net> > > > >wrote: > >> > > > On 09/04/2018 10:43 AM, Bernhard Reutner-Fischer wrote: > >> > > > > On Tue, 4 Sep 2018 at 18:43, Andrew Benson > >> > > > > <abenson@carnegiescience.edu> > >> > > >> > wrote: > >> > > > >> As suggested by Janus, PR87103 is easily fixed by the > > > >attached > > > >> > > > >> patch > >> > > > >> which > >> > > > >> increases GFC_MAX_SYMBOL_LEN to 76 (sufficient to hold the > > > >maximum > > > >> > > > >> allowed F08 symbol length of 63, plus a null terminator, > > > >plus the > > > >> > > > >> "__tmp_class_" prefix).> > > >> > > > > > >> > > > > This is so much wrong. > >> > > > > Note that this will be fixed properly by the changes > > > >contained in > > > >> > > > > the > > > >https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/aldot/for > > > >> > > > > tran > >> > > > > -fe-stringpool branch. > >> > > > > There we keep the GFC_MAX_SYMBOL_LEN at 63 proper but use an > >> > > > > internal > >> > > > > buffer double that size which in turn is sufficient to hold > > > >all > > > >> > > > > compiler-generated identifiers. > >> > > > > See gfc_get_string() even in current TOT. > >> > > > > > >> > > > > Maybe we should bite the bullet and start to merge the > > > >stringpool > > > >> > > > > changes now instead of this hack? > >> > > > > >> > > > It all makes sense to me, please proceed. (my 2 cents worth) > >> > > > >> > > Ok so i will reread the fortran-fe-stringpool series and submit > > > >it > > > >> > > here for review. > >> > > > >> > > Let's return to the issue at hand for a moment, though. > >> > > I tested the attached alternate fix on top of the > >> > > fortran-fe-stringpool branch where it fixes PR87103. > >> > > Maybe somebody has spare cycles to test it on top of current > > > >trunk? > > > >> > > thanks, > >> > > > >> > > [PATCH,FORTRAN] PR87103: Remove max symbol length check from > >> > > gfc_new_symbol > >> > > > >> > > gfc_match_name does check for too long names already. Since > >> > > gfc_new_symbol is also called for symbols with internal names > > > >containing > > > >> > > compiler-generated prefixes, these internal names can easily > > > >exceed the > > > >> > > max_identifier_length mandated by the standard. > >> > > > >> > > gcc/fortran/ChangeLog > >> > > > >> > > 2018-09-04 Bernhard Reutner-Fischer <aldot@gcc.gnu.org> > >> > > > >> > > PR fortran/87103 > >> > > * expr.c (gfc_check_conformance): Check vsnprintf for truncation. > >> > > * iresolve.c (gfc_get_string): Likewise. > >> > > * symbol.c (gfc_new_symbol): Remove check for maximum symbol > >> > > name length. Remove redundant 0 setting of new calloc()ed > >> > > gfc_symbol. -- * Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html * Galacticus: https://github.com/galacticusorg/galacticus ^ permalink raw reply [flat|nested] 25+ messages in thread
* [patch, fortran] PR93461 - Bogus "symbol is already defined" with long subroutine names in submodule 2018-09-04 16:43 ` [patch, fortan] PR87103 - [OOP] " Andrew Benson 2018-09-04 17:43 ` Bernhard Reutner-Fischer @ 2020-01-27 20:57 ` Andrew Benson 2020-01-28 8:21 ` Tobias Burnus 2020-01-27 23:41 ` [patch, fortran] PR93473 - ICE on valid with long module + submodule names Andrew Benson 2 siblings, 1 reply; 25+ messages in thread From: Andrew Benson @ 2020-01-27 20:57 UTC (permalink / raw) To: fortran; +Cc: gcc-patches [-- Attachment #1: Type: text/plain, Size: 2654 bytes --] I created PR93461 for this issue: The following code causes a bogus "symbol is already defined" error (using git commit 73380abd6b2783215c7950a2ade5e3f4b271e2bc): module aModuleWithAnAllowedName interface module subroutine aShortName() end subroutine aShortName end interface end module aModuleWithAnAllowedName submodule (aModuleWithAnAllowedName) aSubmoduleWithAVeryVeryVeryLongButEntirelyLegalName contains subroutine aShortName() call aSubroutineWithAVeryLongNameThatWillCauseAProblem() call aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso() end subroutine aShortName subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblem() end subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblem subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso() end subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso end submodule aSubmoduleWithAVeryVeryVeryLongButEntirelyLegalName $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/data001/abenson/Galacticus/Tools_Devel_Install/bin/../ libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-git/configure --prefix=/home/abenson/Galacticus/ Tools_Devel --enable-languages=c,c++,fortran --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.0.1 20200124 (experimental) (GCC) $ gfortran -c symlength.F90 -o symlength.o -ffree-line-length-none - frecursive -pthread -Wall -fbacktrace -ffpe-trap=invalid,zero,overflow -fdump- core -O3 -ffinite-math-only -fno-math-errno -fopenmp -g /tmp/cc8B4Hmp.s: Assembler messages: /tmp/cc8B4Hmp.s:20: Error: symbol `__amodulewithanallowedname.asubmodulewithaveryveryverylongbutentirelylegalname_MOD_asubroutinewithaverylongnamethatwillcauseaprobl' is already defined The problem occurs because GFC_MAX_MANGLED_SYMBOL_LEN is set to GFC_MAX_SYMBOL_LEN*2+4, which is sufficient for a module name plus function name (plus the additional "_"'s that get prepended), but insufficient if a submodule name is included. The name then gets truncated and can lead to two different functions having the same (truncated) symbol name. The fix is to increase this length to GFC_MAX_SYMBOL_LEN*3+5 - which allows for the submodule name plus the "." added between module and submodule names. I've attached a patch for this which includes a new test case for this PR. The patch regression tests cleanly. OK to commit? -Andrew -- * Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html * Galacticus: https://github.com/galacticusorg/galacticus [-- Attachment #2: patch.diff --] [-- Type: text/x-patch, Size: 1658 bytes --] diff --git a/gcc/fortran/trans.h b/gcc/fortran/trans.h index 52bc045..5942320 100644 --- a/gcc/fortran/trans.h +++ b/gcc/fortran/trans.h @@ -24,7 +24,7 @@ along with GCC; see the file COPYING3. If not see #include "predict.h" /* For enum br_predictor and PRED_*. */ /* Mangled symbols take the form __module__name. */ -#define GFC_MAX_MANGLED_SYMBOL_LEN (GFC_MAX_SYMBOL_LEN*2+4) +#define GFC_MAX_MANGLED_SYMBOL_LEN (GFC_MAX_SYMBOL_LEN*3+5) /* Struct for holding a block of statements. It should be treated as an opaque entity and not modified directly. This allows us to change the diff --git a/gcc/testsuite/gfortran.dg/pr93461.f90 b/gcc/testsuite/gfortran.dg/pr93461.f90 new file mode 100644 index 0000000..3bef326 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/pr93461.f90 @@ -0,0 +1,22 @@ +! { dg-do compile } +! PR fortran/93461 +module aModuleWithAnAllowedName + interface + module subroutine aShortName() + end subroutine aShortName + end interface +end module aModuleWithAnAllowedName + +submodule (aModuleWithAnAllowedName) aSubmoduleWithAVeryVeryVeryLongButEntirelyLegalName +contains + subroutine aShortName() + call aSubroutineWithAVeryLongNameThatWillCauseAProblem() + call aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso() + end subroutine aShortName + + subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblem() + end subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblem + + subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso() + end subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso +end submodule aSubmoduleWithAVeryVeryVeryLongButEntirelyLegalName [-- Attachment #3: ChangeLog --] [-- Type: text/x-changelog, Size: 217 bytes --] 2020-01-27 Andrew Benson <abensonca@gmail.com> * trans.h: Increase GFC_MAX_MANGLED_SYMBOL_LEN to GFC_MAX_SYMBOL_LEN*3+5 to allow for inclusion of submodule name, plus the "." between module and submodule names. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [patch, fortran] PR93461 - Bogus "symbol is already defined" with long subroutine names in submodule 2020-01-27 20:57 ` [patch, fortran] PR93461 - Bogus "symbol is already defined" with long subroutine names in submodule Andrew Benson @ 2020-01-28 8:21 ` Tobias Burnus 2020-01-28 16:41 ` Andrew Benson 0 siblings, 1 reply; 25+ messages in thread From: Tobias Burnus @ 2020-01-28 8:21 UTC (permalink / raw) To: Andrew Benson, fortran; +Cc: gcc-patches Hi Andrew, On 1/27/20 9:57 PM, Andrew Benson wrote: > The problem occurs because GFC_MAX_MANGLED_SYMBOL_LEN is set to > GFC_MAX_SYMBOL_LEN*2+4, which is sufficient for a module name plus function name > (plus the additional "_"'s that get prepended), but insufficient if a submodule > name is included. The name then gets truncated and can lead to two different > functions having the same (truncated) symbol name. > > The fix is to increase this length to GFC_MAX_SYMBOL_LEN*3+5 - which allows for > the submodule name plus the "." added between module and submodule names. > > I've attached a patch for this which includes a new test case for this PR. The > patch regression tests cleanly. > > OK to commit? Can you also update the comment before the #define? It currently has: /* Mangled symbols take the form __module__name. */ -#define GFC_MAX_MANGLED_SYMBOL_LEN (GFC_MAX_SYMBOL_LEN*2+4) +#define GFC_MAX_MANGLED_SYMBOL_LEN (GFC_MAX_SYMBOL_LEN*3+5) Otherweise, it LGTM. Tobias PS: I wonder whether there are relevant systems which will fail because they do not handle that long symbol names... ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [patch, fortran] PR93461 - Bogus "symbol is already defined" with long subroutine names in submodule 2020-01-28 8:21 ` Tobias Burnus @ 2020-01-28 16:41 ` Andrew Benson 2020-01-28 17:50 ` Tobias Burnus 0 siblings, 1 reply; 25+ messages in thread From: Andrew Benson @ 2020-01-28 16:41 UTC (permalink / raw) To: Tobias Burnus; +Cc: fortran, gcc-patches [-- Attachment #1: Type: text/plain, Size: 1738 bytes --] Hi Tobias, > > The problem occurs because GFC_MAX_MANGLED_SYMBOL_LEN is set to > > GFC_MAX_SYMBOL_LEN*2+4, which is sufficient for a module name plus > > function name (plus the additional "_"'s that get prepended), but > > insufficient if a submodule name is included. The name then gets > > truncated and can lead to two different functions having the same > > (truncated) symbol name. > > > > The fix is to increase this length to GFC_MAX_SYMBOL_LEN*3+5 - which > > allows for the submodule name plus the "." added between module and > > submodule names. > > > > I've attached a patch for this which includes a new test case for this PR. > > The patch regression tests cleanly. > > > > OK to commit? > > Can you also update the comment before the #define? It currently has: > > /* Mangled symbols take the form __module__name. */ > -#define GFC_MAX_MANGLED_SYMBOL_LEN (GFC_MAX_SYMBOL_LEN*2+4) > +#define GFC_MAX_MANGLED_SYMBOL_LEN (GFC_MAX_SYMBOL_LEN*3+5) Thanks for the suggestion. An updated patch is attached. > PS: I wonder whether there are relevant systems which will fail because they > do not handle that long symbol names... Good question. Should I hold off on committing the patch until this can be tested further? Or should I just go ahead and commit and deal with any such problems if they show up? Also, Richard Biener raised the question (in the PR) of whether this patch would be an ABI change. I can see that it probably would be, but don't know for sure. If it would change the ABI is there anything else that I need to include in the patch? Thanks, Andrew -- * Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html * Galacticus: https://github.com/galacticusorg/galacticus [-- Attachment #2: patch.diff --] [-- Type: text/x-patch, Size: 1742 bytes --] diff --git a/gcc/fortran/trans.h b/gcc/fortran/trans.h index 52bc045..69171f3 100644 --- a/gcc/fortran/trans.h +++ b/gcc/fortran/trans.h @@ -23,8 +23,8 @@ along with GCC; see the file COPYING3. If not see #include "predict.h" /* For enum br_predictor and PRED_*. */ -/* Mangled symbols take the form __module__name. */ -#define GFC_MAX_MANGLED_SYMBOL_LEN (GFC_MAX_SYMBOL_LEN*2+4) +/* Mangled symbols take the form __module__name or __module.submodule__name. */ +#define GFC_MAX_MANGLED_SYMBOL_LEN (GFC_MAX_SYMBOL_LEN*3+5) /* Struct for holding a block of statements. It should be treated as an opaque entity and not modified directly. This allows us to change the diff --git a/gcc/testsuite/gfortran.dg/pr93461.f90 b/gcc/testsuite/gfortran.dg/pr93461.f90 new file mode 100644 index 0000000..3bef326 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/pr93461.f90 @@ -0,0 +1,22 @@ +! { dg-do compile } +! PR fortran/93461 +module aModuleWithAnAllowedName + interface + module subroutine aShortName() + end subroutine aShortName + end interface +end module aModuleWithAnAllowedName + +submodule (aModuleWithAnAllowedName) aSubmoduleWithAVeryVeryVeryLongButEntirelyLegalName +contains + subroutine aShortName() + call aSubroutineWithAVeryLongNameThatWillCauseAProblem() + call aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso() + end subroutine aShortName + + subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblem() + end subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblem + + subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso() + end subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso +end submodule aSubmoduleWithAVeryVeryVeryLongButEntirelyLegalName [-- Attachment #3: ChangeLog --] [-- Type: text/x-changelog, Size: 274 bytes --] 2020-01-28 Andrew Benson <abensonca@gmail.com> PR fortran/93461 * trans.h: Increase GFC_MAX_MANGLED_SYMBOL_LEN to GFC_MAX_SYMBOL_LEN*3+5 to allow for inclusion of submodule name, plus the "." between module and submodule names. * gfortran.dg/pr93461.f90: New test. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [patch, fortran] PR93461 - Bogus "symbol is already defined" with long subroutine names in submodule 2020-01-28 16:41 ` Andrew Benson @ 2020-01-28 17:50 ` Tobias Burnus 2020-01-28 18:14 ` Andrew Benson 2020-01-29 0:45 ` [patch, fortran, wwwdocs] " Andrew Benson 0 siblings, 2 replies; 25+ messages in thread From: Tobias Burnus @ 2020-01-28 17:50 UTC (permalink / raw) To: Andrew Benson; +Cc: fortran, gcc-patches Hi Andrew, On 1/28/20 5:41 PM, Andrew Benson wrote: >> Can you also update the comment before the #define? It currently has: > Thanks for the suggestion. An updated patch is attached. Thanks. LGTM now. >> PS: I wonder whether there are relevant systems which will fail because they >> do not handle that long symbol names... > Good question. Should I hold off on committing the patch until this can be > tested further? Or should I just go ahead and commit and deal with any such > problems if they show up? I think it is fine – as a user, one can always choose a shorter name if the system one is interested in doesn't support it. Besides, following the current scheme, we do not really have a choice without breaking the ABI. > Also, Richard Biener raised the question (in the PR) of whether this patch > would be an ABI change. I can see that it probably would be, but don't know > for sure. If it would change the ABI is there anything else that I need to > include in the patch? As just mentioned on the PR, I think it is a small ABI change – before a very long identified got cut off now it is available in full extent. — I do not see any simple way to avoid this ABI change and, frankly, I also do not think any real-world program uses that long identifiers. Namely, instead of using 3 times the length of 42 character ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnop") the standard permits 3 times the length of 63 characters (ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890_). Already 42 is quite long for a module, submodule or procedure name. And that does work even without the patch. And as only the sum counts, if one part only uses 10 characters (e.g. "my_module5"), now 2*58 characters available two others. If at the end it really causes problems (source code not available), the user still can modify the module file and change the procedure name to the trimmed value and continue. Thus, I do not think it is a real problem in practice. We could be nice, however, and add a note to the release notes (i.e. https://gcc.gnu.org/gcc-10/changes.html); I not completely sure whether it is worthwhile but why not. [See https://gcc.gnu.org/about.html#git about how to change WWW files and CC Gerald as web maintainer when submitting wwwdocs patches.] Thanks, Tobias > patch.diff > > diff --git a/gcc/fortran/trans.h b/gcc/fortran/trans.h > index 52bc045..69171f3 100644 > --- a/gcc/fortran/trans.h > +++ b/gcc/fortran/trans.h > @@ -23,8 +23,8 @@ along with GCC; see the file COPYING3. If not see > > #include "predict.h" /* For enum br_predictor and PRED_*. */ > > -/* Mangled symbols take the form __module__name. */ > -#define GFC_MAX_MANGLED_SYMBOL_LEN (GFC_MAX_SYMBOL_LEN*2+4) > +/* Mangled symbols take the form __module__name or __module.submodule__name. */ > +#define GFC_MAX_MANGLED_SYMBOL_LEN (GFC_MAX_SYMBOL_LEN*3+5) > > /* Struct for holding a block of statements. It should be treated as an > opaque entity and not modified directly. This allows us to change the > diff --git a/gcc/testsuite/gfortran.dg/pr93461.f90 b/gcc/testsuite/gfortran.dg/pr93461.f90 > new file mode 100644 > index 0000000..3bef326 > --- /dev/null > +++ b/gcc/testsuite/gfortran.dg/pr93461.f90 > @@ -0,0 +1,22 @@ > +! { dg-do compile } > +! PR fortran/93461 > +module aModuleWithAnAllowedName > + interface > + module subroutine aShortName() > + end subroutine aShortName > + end interface > +end module aModuleWithAnAllowedName > + > +submodule (aModuleWithAnAllowedName) aSubmoduleWithAVeryVeryVeryLongButEntirelyLegalName > +contains > + subroutine aShortName() > + call aSubroutineWithAVeryLongNameThatWillCauseAProblem() > + call aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso() > + end subroutine aShortName > + > + subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblem() > + end subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblem > + > + subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso() > + end subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso > +end submodule aSubmoduleWithAVeryVeryVeryLongButEntirelyLegalName > > ChangeLog > > 2020-01-28 Andrew Benson<abensonca@gmail.com> > > PR fortran/93461 > * trans.h: Increase GFC_MAX_MANGLED_SYMBOL_LEN to > GFC_MAX_SYMBOL_LEN*3+5 to allow for inclusion of submodule name, > plus the "." between module and submodule names. > > * gfortran.dg/pr93461.f90: New test. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [patch, fortran] PR93461 - Bogus "symbol is already defined" with long subroutine names in submodule 2020-01-28 17:50 ` Tobias Burnus @ 2020-01-28 18:14 ` Andrew Benson 2020-01-29 0:45 ` [patch, fortran, wwwdocs] " Andrew Benson 1 sibling, 0 replies; 25+ messages in thread From: Andrew Benson @ 2020-01-28 18:14 UTC (permalink / raw) To: Tobias Burnus; +Cc: fortran, gcc-patches Hi Tobias, Thanks - committed as https://gcc.gnu.org/git/gitweb.cgi? p=gcc.git;a=commit;h=ad690d79cfbb905c5546c9333c5fd089d906505b I'll send a separate email about changes to the release notes. -Andrew On Tuesday, January 28, 2020 6:49:54 PM PST Tobias Burnus wrote: > Hi Andrew, > > On 1/28/20 5:41 PM, Andrew Benson wrote: > >> Can you also update the comment before the #define? It currently has: > > Thanks for the suggestion. An updated patch is attached. > > Thanks. LGTM now. > > >> PS: I wonder whether there are relevant systems which will fail because > >> they do not handle that long symbol names... > > > > Good question. Should I hold off on committing the patch until this can be > > tested further? Or should I just go ahead and commit and deal with any > > such > > problems if they show up? > > I think it is fine – as a user, one can always choose a shorter name if > the system one is interested in doesn't support it. Besides, following > the current scheme, we do not really have a choice without breaking the ABI. > > Also, Richard Biener raised the question (in the PR) of whether this patch > > would be an ABI change. I can see that it probably would be, but don't > > know > > for sure. If it would change the ABI is there anything else that I need to > > include in the patch? > > As just mentioned on the PR, I think it is a small ABI change – before a > very long identified got cut off now it is available in full extent. — I > do not see any simple way to avoid this ABI change and, frankly, I also > do not think any real-world program uses that long identifiers. > > Namely, instead of using 3 times the length of 42 character > ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnop") the standard permits 3 > times the length of 63 characters > (ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890_). > Already 42 is quite long for a module, submodule or procedure name. And > that does work even without the patch. And as only the sum counts, if > one part only uses 10 characters (e.g. "my_module5"), now 2*58 > characters available two others. > > If at the end it really causes problems (source code not available), the > user still can modify the module file and change the procedure name to > the trimmed value and continue. > > Thus, I do not think it is a real problem in practice. We could be nice, > however, and add a note to the release notes (i.e. > https://gcc.gnu.org/gcc-10/changes.html); I not completely sure whether > it is worthwhile but why not. [See https://gcc.gnu.org/about.html#git > about how to change WWW files and CC Gerald as web maintainer when > submitting wwwdocs patches.] > > Thanks, > > Tobias > > > patch.diff > > > > diff --git a/gcc/fortran/trans.h b/gcc/fortran/trans.h > > index 52bc045..69171f3 100644 > > --- a/gcc/fortran/trans.h > > +++ b/gcc/fortran/trans.h > > @@ -23,8 +23,8 @@ along with GCC; see the file COPYING3. If not see > > > > #include "predict.h" /* For enum br_predictor and PRED_*. */ > > > > -/* Mangled symbols take the form __module__name. */ > > -#define GFC_MAX_MANGLED_SYMBOL_LEN (GFC_MAX_SYMBOL_LEN*2+4) > > +/* Mangled symbols take the form __module__name or > > __module.submodule__name. */ +#define GFC_MAX_MANGLED_SYMBOL_LEN > > (GFC_MAX_SYMBOL_LEN*3+5) > > > > /* Struct for holding a block of statements. It should be treated as an > > > > opaque entity and not modified directly. This allows us to change > > the > > > > diff --git a/gcc/testsuite/gfortran.dg/pr93461.f90 > > b/gcc/testsuite/gfortran.dg/pr93461.f90 new file mode 100644 > > index 0000000..3bef326 > > --- /dev/null > > +++ b/gcc/testsuite/gfortran.dg/pr93461.f90 > > @@ -0,0 +1,22 @@ > > +! { dg-do compile } > > +! PR fortran/93461 > > +module aModuleWithAnAllowedName > > + interface > > + module subroutine aShortName() > > + end subroutine aShortName > > + end interface > > +end module aModuleWithAnAllowedName > > + > > +submodule (aModuleWithAnAllowedName) > > aSubmoduleWithAVeryVeryVeryLongButEntirelyLegalName +contains > > + subroutine aShortName() > > + call aSubroutineWithAVeryLongNameThatWillCauseAProblem() > > + call aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso() > > + end subroutine aShortName > > + > > + subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblem() > > + end subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblem > > + > > + subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso() > > + end subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso > > +end submodule aSubmoduleWithAVeryVeryVeryLongButEntirelyLegalName > > > > ChangeLog > > > > 2020-01-28 Andrew Benson<abensonca@gmail.com> > > > > PR fortran/93461 > > * trans.h: Increase GFC_MAX_MANGLED_SYMBOL_LEN to > > GFC_MAX_SYMBOL_LEN*3+5 to allow for inclusion of submodule name, > > plus the "." between module and submodule names. > > > > * gfortran.dg/pr93461.f90: New test. -- * Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html * Galacticus: https://github.com/galacticusorg/galacticus ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [patch, fortran, wwwdocs] PR93461 - Bogus "symbol is already defined" with long subroutine names in submodule 2020-01-28 17:50 ` Tobias Burnus 2020-01-28 18:14 ` Andrew Benson @ 2020-01-29 0:45 ` Andrew Benson 2020-01-29 9:08 ` Gerald Pfeifer 2020-01-29 10:57 ` Tobias Burnus 1 sibling, 2 replies; 25+ messages in thread From: Andrew Benson @ 2020-01-29 0:45 UTC (permalink / raw) To: Tobias Burnus; +Cc: fortran, gcc-patches, gerald [-- Attachment #1: Type: text/plain, Size: 746 bytes --] Hi Tobias, On Tuesday, January 28, 2020 6:49:54 PM PST Tobias Burnus wrote: > Thus, I do not think it is a real problem in practice. We could be nice, > however, and add a note to the release notes (i.e. > https://gcc.gnu.org/gcc-10/changes.html); I not completely sure whether > it is worthwhile but why not. [See https://gcc.gnu.org/about.html#git > about how to change WWW files and CC Gerald as web maintainer when > submitting wwwdocs patches.] I've attached a draft patch to update the release notes about this ABI breakage. I don't know if I've explained it sufficiently clearly though? -Andrew -- * Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html * Galacticus: https://github.com/galacticusorg/galacticus [-- Attachment #2: patch.diff --] [-- Type: text/x-patch, Size: 805 bytes --] diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html index dcce6b8..5a959a1 100644 --- a/htdocs/gcc-10/changes.html +++ b/htdocs/gcc-10/changes.html @@ -446,6 +446,13 @@ a work-in-progress.</p> objects with allocatable components. In this case, the optional arguments <code>STAT=</code> and <code>ERRMSG=</code> are currently ignored. </li> + <li> + The handling of module and submodule names has been reworked to allow the + full 63-character length mandated by the standard. Previously symbol names + were truncated if the combined length of module, submodule, and function + name exceeded 126 characters. This change therefore breaks the ABI, but only + for cases where this 126 character limit was exceeded. + </li> </ul> <!-- <h3 id="go">Go</h3> --> ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [patch, fortran, wwwdocs] PR93461 - Bogus "symbol is already defined" with long subroutine names in submodule 2020-01-29 0:45 ` [patch, fortran, wwwdocs] " Andrew Benson @ 2020-01-29 9:08 ` Gerald Pfeifer 2020-01-29 10:57 ` Tobias Burnus 1 sibling, 0 replies; 25+ messages in thread From: Gerald Pfeifer @ 2020-01-29 9:08 UTC (permalink / raw) To: Andrew Benson; +Cc: Tobias Burnus, fortran, gcc-patches On Tue, 28 Jan 2020, Andrew Benson wrote: > I've attached a draft patch to update the release notes about this ABI > breakage. I don't know if I've explained it sufficiently clearly though? I do not speak Fortran, but your description was easy to read and understand for me. :-) Thank you, and okay - let's just give the Fortran team a day or two to chime in before you push the change. Gerald ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [patch, fortran, wwwdocs] PR93461 - Bogus "symbol is already defined" with long subroutine names in submodule 2020-01-29 0:45 ` [patch, fortran, wwwdocs] " Andrew Benson 2020-01-29 9:08 ` Gerald Pfeifer @ 2020-01-29 10:57 ` Tobias Burnus 2020-01-29 16:37 ` Andrew Benson 1 sibling, 1 reply; 25+ messages in thread From: Tobias Burnus @ 2020-01-29 10:57 UTC (permalink / raw) To: Andrew Benson, Tobias Burnus; +Cc: fortran, gcc-patches, gerald LGTM – and also to Gerald. Hence, go ahead! Thanks for the patch, Tobias On 1/29/20 1:45 AM, Andrew Benson wrote: > Hi Tobias, > > On Tuesday, January 28, 2020 6:49:54 PM PST Tobias Burnus wrote: >> Thus, I do not think it is a real problem in practice. We could be nice, >> however, and add a note to the release notes (i.e. >> https://gcc.gnu.org/gcc-10/changes.html); I not completely sure whether >> it is worthwhile but why not. [See https://gcc.gnu.org/about.html#git >> about how to change WWW files and CC Gerald as web maintainer when >> submitting wwwdocs patches.] > I've attached a draft patch to update the release notes about this ABI > breakage. I don't know if I've explained it sufficiently clearly though? > > -Andrew > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [patch, fortran, wwwdocs] PR93461 - Bogus "symbol is already defined" with long subroutine names in submodule 2020-01-29 10:57 ` Tobias Burnus @ 2020-01-29 16:37 ` Andrew Benson 0 siblings, 0 replies; 25+ messages in thread From: Andrew Benson @ 2020-01-29 16:37 UTC (permalink / raw) To: Tobias Burnus; +Cc: fortran, gcc-patches, gerald Thanks Tobias and Gerald - that change is now committed: https://gcc.gnu.org/git/?p=gcc-wwwdocs.git;a=commit;h=b88b1edba71bbca44429c28b7518d76678ab6acb On Wednesday, January 29, 2020 11:57:02 AM PST Tobias Burnus wrote: > LGTM – and also to Gerald. Hence, go ahead! > > Thanks for the patch, > > Tobias > > On 1/29/20 1:45 AM, Andrew Benson wrote: > > Hi Tobias, > > > > On Tuesday, January 28, 2020 6:49:54 PM PST Tobias Burnus wrote: > >> Thus, I do not think it is a real problem in practice. We could be nice, > >> however, and add a note to the release notes (i.e. > >> https://gcc.gnu.org/gcc-10/changes.html); I not completely sure whether > >> it is worthwhile but why not. [See https://gcc.gnu.org/about.html#git > >> about how to change WWW files and CC Gerald as web maintainer when > >> submitting wwwdocs patches.] > > > > I've attached a draft patch to update the release notes about this ABI > > breakage. I don't know if I've explained it sufficiently clearly though? > > > > -Andrew -- * Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html * Galacticus: https://github.com/galacticusorg/galacticus ^ permalink raw reply [flat|nested] 25+ messages in thread
* [patch, fortran] PR93473 - ICE on valid with long module + submodule names 2018-09-04 16:43 ` [patch, fortan] PR87103 - [OOP] " Andrew Benson 2018-09-04 17:43 ` Bernhard Reutner-Fischer 2020-01-27 20:57 ` [patch, fortran] PR93461 - Bogus "symbol is already defined" with long subroutine names in submodule Andrew Benson @ 2020-01-27 23:41 ` Andrew Benson 2020-01-28 8:28 ` Tobias Burnus 2 siblings, 1 reply; 25+ messages in thread From: Andrew Benson @ 2020-01-27 23:41 UTC (permalink / raw) To: fortran; +Cc: gcc-patches [-- Attachment #1: Type: text/plain, Size: 2784 bytes --] I created PR93473 for this problem: The following code causes a bogus "symbol is already defined" error (using git commit 472dc648ce3e7661762931d584d239611ddca964): module aModestlyLongModuleName type :: aTypeWithASignificantlyLongNameButStillAllowedOK end type aTypeWithASignificantlyLongNameButStillAllowedOK interface module function aFunctionWithALongButStillAllowedName(parameters) result(self) type(aTypeWithASignificantlyLongNameButStillAllowedOK) :: self end function aFunctionWithALongButStillAllowedName end interface end module aModestlyLongModuleName submodule (aModestlyLongModuleName) aTypeWithASignificantlyLongNameButStillAllowedOK_ contains module procedure aFunctionWithALongButStillAllowedName class(*), pointer :: genericObject end procedure aFunctionWithALongButStillAllowedName end submodule aTypeWithASignificantlyLongNameButStillAllowedOK_ submodule (aModestlyLongModuleName:aTypeWithASignificantlyLongNameButStillAllowedOK_) aSubmoduleWithASignificantlyLongButStillAllowedName__ end submodule aSubmoduleWithASignificantlyLongButStillAllowedName__ $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/data001/abenson/Galacticus/Tools_Devel_Install/bin/../ libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-git/configure --prefix=/home/abenson/Galacticus/ Tools_Devel --enable-languages=c,c++,fortran --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.0.1 20200127 (experimental) (GCC) $ gfortran -c 1057.F90 -o test.o -ffree-line-length-none f951: internal compiler error: Segmentation fault 0xe1021f crash_signal ../../gcc-git/gcc/toplev.c:328 0x7fd1480c91ef ??? /data001/abenson/Galacticus/Tools/glibc-2.12.1/signal/../sysdeps/unix/ sysv/linux/x86_64/sigaction.c:0 0x891106 do_traverse_symtree ../../gcc-git/gcc/fortran/symbol.c:4173 0x85739b parse_module ../../gcc-git/gcc/fortran/parse.c:6111 0x85782d gfc_parse_file() ../../gcc-git/gcc/fortran/parse.c:6427 0x8a7f2f gfc_be_parse_file ../../gcc-git/gcc/fortran/f95-lang.c:210 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. The problem occurs in set_syms_host_assoc() where the "parent1" and "parent2" variables have a maximum length of GFC_MAX_SYMBOL_LEN+1. This is insufficient when the parent names are a module+submodule name concatenated with a ".". The patch above fixes this by increasing their length to 2*GFC_MAX_SYMBOL_LEN+2. A patch to fix this is attached. The patch regression tests cleanly - ok to commit? -Andrew [-- Attachment #2: patch.diff --] [-- Type: text/x-patch, Size: 1731 bytes --] diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c index 4bff0c8..cbace25 100644 --- a/gcc/fortran/parse.c +++ b/gcc/fortran/parse.c @@ -6045,8 +6045,8 @@ set_syms_host_assoc (gfc_symbol *sym) { gfc_component *c; const char dot[2] = "."; - char parent1[GFC_MAX_SYMBOL_LEN + 1]; - char parent2[GFC_MAX_SYMBOL_LEN + 1]; + char parent1[2 * GFC_MAX_SYMBOL_LEN + 2]; + char parent2[2 * GFC_MAX_SYMBOL_LEN + 2]; if (sym == NULL) return; diff --git a/gcc/testsuite/gfortran.dg/pr93473.f90 b/gcc/testsuite/gfortran.dg/pr93473.f90 new file mode 100644 index 0000000..dda8525 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/pr93473.f90 @@ -0,0 +1,28 @@ +! { dg-do compile } +! { dg-options "-ffree-line-length-none" } +! PR fortran/93473 +module aModestlyLongModuleName + + type :: aTypeWithASignificantlyLongNameButStillAllowedOK + end type aTypeWithASignificantlyLongNameButStillAllowedOK + + interface + module function aFunctionWithALongButStillAllowedName(parameters) result(self) + type(aTypeWithASignificantlyLongNameButStillAllowedOK) :: self + end function aFunctionWithALongButStillAllowedName + end interface + +end module aModestlyLongModuleName + +submodule (aModestlyLongModuleName) aTypeWithASignificantlyLongNameButStillAllowedOK_ + +contains + + module procedure aFunctionWithALongButStillAllowedName + class(*), pointer :: genericObject + end procedure aFunctionWithALongButStillAllowedName + +end submodule aTypeWithASignificantlyLongNameButStillAllowedOK_ + +submodule (aModestlyLongModuleName:aTypeWithASignificantlyLongNameButStillAllowedOK_) aSubmoduleWithASignificantlyLongButStillAllowedName__ +end submodule aSubmoduleWithASignificantlyLongButStillAllowedName__ [-- Attachment #3: ChangeLog --] [-- Type: text/x-changelog, Size: 216 bytes --] 2020-01-27 Andrew Benson <abensonca@gmail.com> PR fortran/93473 * parse.c: Increase length of char variables to allow them to hold a concatenated module + submodule name. * gfortran.dg/pr93473.f90: New test. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [patch, fortran] PR93473 - ICE on valid with long module + submodule names 2020-01-27 23:41 ` [patch, fortran] PR93473 - ICE on valid with long module + submodule names Andrew Benson @ 2020-01-28 8:28 ` Tobias Burnus 2020-01-28 16:41 ` Andrew Benson 0 siblings, 1 reply; 25+ messages in thread From: Tobias Burnus @ 2020-01-28 8:28 UTC (permalink / raw) To: Andrew Benson, fortran; +Cc: gcc-patches On 1/28/20 12:41 AM, Andrew Benson wrote: > The problem occurs in set_syms_host_assoc() where the "parent1" and "parent2" > variables have a maximum length of GFC_MAX_SYMBOL_LEN+1. This is insufficient > when the parent names are a module+submodule name concatenated with a ".". The > patch above fixes this by increasing their length to 2*GFC_MAX_SYMBOL_LEN+2. > > A patch to fix this is attached. The patch regression tests cleanly - ok to > commit? The patch is okay, but can you add a comment – similar to the other patch – which makes clear why one needs twice the normal GFC_MAX_SYMBOL_LEN (+2)? You currently have: > const char dot[2] = "."; > - char parent1[GFC_MAX_SYMBOL_LEN + 1]; > - char parent2[GFC_MAX_SYMBOL_LEN + 1]; > + char parent1[2 * GFC_MAX_SYMBOL_LEN + 2]; > + char parent2[2 * GFC_MAX_SYMBOL_LEN + 2]; Tobias ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [patch, fortran] PR93473 - ICE on valid with long module + submodule names 2020-01-28 8:28 ` Tobias Burnus @ 2020-01-28 16:41 ` Andrew Benson 2020-01-28 17:32 ` Tobias Burnus 0 siblings, 1 reply; 25+ messages in thread From: Andrew Benson @ 2020-01-28 16:41 UTC (permalink / raw) To: Tobias Burnus; +Cc: fortran, gcc-patches [-- Attachment #1: Type: text/plain, Size: 1234 bytes --] On Tuesday, January 28, 2020 9:27:58 AM PST Tobias Burnus wrote: > On 1/28/20 12:41 AM, Andrew Benson wrote: > > The problem occurs in set_syms_host_assoc() where the "parent1" and > > "parent2" variables have a maximum length of GFC_MAX_SYMBOL_LEN+1. This > > is insufficient when the parent names are a module+submodule name > > concatenated with a ".". The patch above fixes this by increasing their > > length to 2*GFC_MAX_SYMBOL_LEN+2. > > > > A patch to fix this is attached. The patch regression tests cleanly - ok > > to > > commit? > > The patch is okay, but can you add a comment – similar to the other > patch – which makes clear why one needs twice the normal > > GFC_MAX_SYMBOL_LEN (+2)? You currently have: > > const char dot[2] = "."; > > > > - char parent1[GFC_MAX_SYMBOL_LEN + 1]; > > - char parent2[GFC_MAX_SYMBOL_LEN + 1]; > > + char parent1[2 * GFC_MAX_SYMBOL_LEN + 2]; > > + char parent2[2 * GFC_MAX_SYMBOL_LEN + 2]; Yes - I've added a comment here explaining the naming convention. An updated patch is attached. -Andrew -- * Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html * Galacticus: https://github.com/galacticusorg/galacticus [-- Attachment #2: ChangeLog --] [-- Type: text/x-changelog, Size: 216 bytes --] 2020-01-28 Andrew Benson <abensonca@gmail.com> PR fortran/93473 * parse.c: Increase length of char variables to allow them to hold a concatenated module + submodule name. * gfortran.dg/pr93473.f90: New test. [-- Attachment #3: patch.diff --] [-- Type: text/x-patch, Size: 1797 bytes --] diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c index 4bff0c8..f71a95d 100644 --- a/gcc/fortran/parse.c +++ b/gcc/fortran/parse.c @@ -6045,8 +6045,9 @@ set_syms_host_assoc (gfc_symbol *sym) { gfc_component *c; const char dot[2] = "."; - char parent1[GFC_MAX_SYMBOL_LEN + 1]; - char parent2[GFC_MAX_SYMBOL_LEN + 1]; + /* Symbols take the form module.submodule_ or module.name_. */ + char parent1[2 * GFC_MAX_SYMBOL_LEN + 2]; + char parent2[2 * GFC_MAX_SYMBOL_LEN + 2]; if (sym == NULL) return; diff --git a/gcc/testsuite/gfortran.dg/pr93473.f90 b/gcc/testsuite/gfortran.dg/pr93473.f90 new file mode 100644 index 0000000..dda8525 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/pr93473.f90 @@ -0,0 +1,28 @@ +! { dg-do compile } +! { dg-options "-ffree-line-length-none" } +! PR fortran/93473 +module aModestlyLongModuleName + + type :: aTypeWithASignificantlyLongNameButStillAllowedOK + end type aTypeWithASignificantlyLongNameButStillAllowedOK + + interface + module function aFunctionWithALongButStillAllowedName(parameters) result(self) + type(aTypeWithASignificantlyLongNameButStillAllowedOK) :: self + end function aFunctionWithALongButStillAllowedName + end interface + +end module aModestlyLongModuleName + +submodule (aModestlyLongModuleName) aTypeWithASignificantlyLongNameButStillAllowedOK_ + +contains + + module procedure aFunctionWithALongButStillAllowedName + class(*), pointer :: genericObject + end procedure aFunctionWithALongButStillAllowedName + +end submodule aTypeWithASignificantlyLongNameButStillAllowedOK_ + +submodule (aModestlyLongModuleName:aTypeWithASignificantlyLongNameButStillAllowedOK_) aSubmoduleWithASignificantlyLongButStillAllowedName__ +end submodule aSubmoduleWithASignificantlyLongButStillAllowedName__ ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [patch, fortran] PR93473 - ICE on valid with long module + submodule names 2020-01-28 16:41 ` Andrew Benson @ 2020-01-28 17:32 ` Tobias Burnus 2020-01-28 18:05 ` Andrew Benson 0 siblings, 1 reply; 25+ messages in thread From: Tobias Burnus @ 2020-01-28 17:32 UTC (permalink / raw) To: Andrew Benson, Tobias Burnus; +Cc: fortran, gcc-patches LGTM now. Thanks, Tobias On 1/28/20 5:41 PM, Andrew Benson wrote: > On Tuesday, January 28, 2020 9:27:58 AM PST Tobias Burnus wrote: >> On 1/28/20 12:41 AM, Andrew Benson wrote: >>> The problem occurs in set_syms_host_assoc() where the "parent1" and >>> "parent2" variables have a maximum length of GFC_MAX_SYMBOL_LEN+1. This >>> is insufficient when the parent names are a module+submodule name >>> concatenated with a ".". The patch above fixes this by increasing their >>> length to 2*GFC_MAX_SYMBOL_LEN+2. >>> >>> A patch to fix this is attached. The patch regression tests cleanly - ok >>> to >>> commit? >> The patch is okay, but can you add a comment â similar to the other >> patch â which makes clear why one needs twice the normal >> >> GFC_MAX_SYMBOL_LEN (+2)? You currently have: >>> const char dot[2] = "."; >>> >>> - char parent1[GFC_MAX_SYMBOL_LEN + 1]; >>> - char parent2[GFC_MAX_SYMBOL_LEN + 1]; >>> + char parent1[2 * GFC_MAX_SYMBOL_LEN + 2]; >>> + char parent2[2 * GFC_MAX_SYMBOL_LEN + 2]; > Yes - I've added a comment here explaining the naming convention. An updated > patch is attached. > > -Andrew > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [patch, fortran] PR93473 - ICE on valid with long module + submodule names 2020-01-28 17:32 ` Tobias Burnus @ 2020-01-28 18:05 ` Andrew Benson 0 siblings, 0 replies; 25+ messages in thread From: Andrew Benson @ 2020-01-28 18:05 UTC (permalink / raw) To: Tobias Burnus; +Cc: fortran, gcc-patches Thanks - committed as a83b5cc5828ee34471de415e8893242dd3b0a91b https://gcc.gnu.org/git/gitweb.cgi? p=gcc.git;a=commit;h=a83b5cc5828ee34471de415e8893242dd3b0a91b I'll close the PR. Thanks, Andrew On Tuesday, January 28, 2020 6:32:21 PM PST Tobias Burnus wrote: > LGTM now. > > Thanks, > > Tobias > > On 1/28/20 5:41 PM, Andrew Benson wrote: > > On Tuesday, January 28, 2020 9:27:58 AM PST Tobias Burnus wrote: > >> On 1/28/20 12:41 AM, Andrew Benson wrote: > >>> The problem occurs in set_syms_host_assoc() where the "parent1" and > >>> "parent2" variables have a maximum length of GFC_MAX_SYMBOL_LEN+1. This > >>> is insufficient when the parent names are a module+submodule name > >>> concatenated with a ".". The patch above fixes this by increasing their > >>> length to 2*GFC_MAX_SYMBOL_LEN+2. > >>> > >>> A patch to fix this is attached. The patch regression tests cleanly - ok > >>> to > >>> commit? > >> > >> The patch is okay, but can you add a comment – similar to the other > >> patch – which makes clear why one needs twice the normal > >> > >> GFC_MAX_SYMBOL_LEN (+2)? You currently have: > >>> const char dot[2] = "."; > >>> > >>> - char parent1[GFC_MAX_SYMBOL_LEN + 1]; > >>> - char parent2[GFC_MAX_SYMBOL_LEN + 1]; > >>> + char parent1[2 * GFC_MAX_SYMBOL_LEN + 2]; > >>> + char parent2[2 * GFC_MAX_SYMBOL_LEN + 2]; > > > > Yes - I've added a comment here explaining the naming convention. An > > updated patch is attached. > > > > -Andrew -- * Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html * Galacticus: https://github.com/galacticusorg/galacticus ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2020-01-30 17:50 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-08-25 20:51 ICE in gfc_new_symbol() due to overlong symbol name Andrew Benson 2018-09-04 16:43 ` [patch, fortan] PR87103 - [OOP] " Andrew Benson 2018-09-04 17:43 ` Bernhard Reutner-Fischer [not found] ` <5aa0135b-1bdd-46de-e235-daed0a9a97e1@charter.net> 2018-09-05 10:35 ` Bernhard Reutner-Fischer 2018-09-05 14:24 ` Andrew Benson 2019-08-24 21:15 ` Andrew Benson 2019-08-28 22:48 ` Bernhard Reutner-Fischer 2019-08-30 8:22 ` Andrew Benson 2020-01-29 20:19 ` Andrew Benson 2020-01-30 16:28 ` Bernhard Reutner-Fischer 2020-01-30 17:50 ` Andrew Benson 2020-01-27 20:57 ` [patch, fortran] PR93461 - Bogus "symbol is already defined" with long subroutine names in submodule Andrew Benson 2020-01-28 8:21 ` Tobias Burnus 2020-01-28 16:41 ` Andrew Benson 2020-01-28 17:50 ` Tobias Burnus 2020-01-28 18:14 ` Andrew Benson 2020-01-29 0:45 ` [patch, fortran, wwwdocs] " Andrew Benson 2020-01-29 9:08 ` Gerald Pfeifer 2020-01-29 10:57 ` Tobias Burnus 2020-01-29 16:37 ` Andrew Benson 2020-01-27 23:41 ` [patch, fortran] PR93473 - ICE on valid with long module + submodule names Andrew Benson 2020-01-28 8:28 ` Tobias Burnus 2020-01-28 16:41 ` Andrew Benson 2020-01-28 17:32 ` Tobias Burnus 2020-01-28 18:05 ` Andrew Benson
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).