[patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name

[patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name

[Andrew Benson]

[-- 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 */

Re: [patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name

[Bernhard Reutner-Fischer]

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,

Re: [patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name

[Bernhard Reutner-Fischer]

[-- 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;
 }
 

Re: [patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name

[Andrew Benson]

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

Re: [patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name

[Andrew Benson]

[-- 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;
 }
 

Re: [patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name

[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.  
> 
> 

Re: [patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name

[Andrew Benson]

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

Re: [patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name

[Andrew Benson]

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

Re: [patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name

[Bernhard Reutner-Fischer]

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.

Re: [patch, fortan] PR87103 - [OOP] ICE in gfc_new_symbol() due to overlong symbol name

[Andrew Benson]

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

[patch, fortran] PR93461 - Bogus "symbol is already defined" with long subroutine names in submodule

[Andrew Benson]

[-- 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.

Re: [patch, fortran] PR93461 - Bogus "symbol is already defined" with long subroutine names in submodule

[Tobias Burnus]

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...

Re: [patch, fortran] PR93461 - Bogus "symbol is already defined" with long subroutine names in submodule

[Andrew Benson]

[-- 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.

Re: [patch, fortran] PR93461 - Bogus "symbol is already defined" with long subroutine names in submodule

[Tobias Burnus]

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.

Re: [patch, fortran] PR93461 - Bogus "symbol is already defined" with long subroutine names in submodule

[Andrew Benson]

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

Re: [patch, fortran, wwwdocs] PR93461 - Bogus "symbol is already defined" with long subroutine names in submodule

[Andrew Benson]

[-- 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> -->

Re: [patch, fortran, wwwdocs] PR93461 - Bogus "symbol is already defined" with long subroutine names in submodule

[Gerald Pfeifer]

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

Re: [patch, fortran, wwwdocs] PR93461 - Bogus "symbol is already defined" with long subroutine names in submodule

[Tobias Burnus]

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
>

Re: [patch, fortran, wwwdocs] PR93461 - Bogus "symbol is already defined" with long subroutine names in submodule

[Andrew Benson]

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

[patch, fortran] PR93473 - ICE on valid with long module + submodule names

[Andrew Benson]

[-- 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.

Re: [patch, fortran] PR93473 - ICE on valid with long module + submodule names

[Tobias Burnus]

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

Re: [patch, fortran] PR93473 - ICE on valid with long module + submodule names

[Andrew Benson]

[-- 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__

Re: [patch, fortran] PR93473 - ICE on valid with long module + submodule names

[Tobias Burnus]

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
>

Re: [patch, fortran] PR93473 - ICE on valid with long module + submodule names

[Andrew Benson]

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