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

[Andrew Benson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.diff
Type: text/x-patch
Size: 1731 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20200128/34ab91f4/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ChangeLog
Type: text/x-changelog
Size: 216 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20200128/34ab91f4/attachment-0001.bin>