Bug 93473 - ICE on valid with long module + submodule names
Summary: ICE on valid with long module + submodule names
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 10.0
: P3 normal
Target Milestone: ---
Assignee: Andrew Benson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-27 22:58 UTC by Andrew Benson
Modified: 2020-07-09 21:13 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2020-01-28 00:00:00


Attachments
Proposed patch (243 bytes, patch)
2020-01-27 23:06 UTC, Andrew Benson
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Benson 2020-01-27 22:58:53 UTC
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.
Comment 1 Andrew Benson 2020-01-27 23:06:04 UTC
Created attachment 47722 [details]
Proposed patch
Comment 2 Andrew Benson 2020-01-27 23:07:41 UTC
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.
Comment 3 Martin Liška 2020-01-28 09:09:39 UTC
@Andrew: Can you please send a patch to GCC ML?
Comment 4 Andrew Benson 2020-01-28 16:14:03 UTC
@Martin - yes, thanks for the reminder, I'll send the updated patch to the GCC mailing list.
Comment 5 GCC Commits 2020-01-28 18:03:48 UTC
The master branch has been updated by Andrew Benson <abensonca@gcc.gnu.org>:

https://gcc.gnu.org/g:a83b5cc5828ee34471de415e8893242dd3b0a91b

commit r10-6295-ga83b5cc5828ee34471de415e8893242dd3b0a91b
Author: Andrew Benson <abenson@carnegiescience.edu>
Date:   Tue Jan 28 17:58:40 2020 +0000

    Allow concatenated module+submodule names.
    
    Increase length of char variables "parent1" and "parent2" in
    set_syms_host_assoc() to allow them to hold concatenated module +
    submodule names.
    
            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.
Comment 7 Rainer Orth 2020-01-28 22:06:52 UTC
The new testcase ICEs on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (both 32
and 64-bit) as well as powerpc64-unknown-linux-gnu and powerpc64le-unknown-linux-gnu:

+FAIL: gfortran.dg/pr93473.f90   -O  (internal compiler error)
+FAIL: gfortran.dg/pr93473.f90   -O  (test for excess errors)

Excess errors:
f951: internal compiler error: new_symbol(): Symbol name too long
0x8b450a2 gfc_report_diagnostic
        /vol/gcc/src/hg/master/local/gcc/fortran/error.c:782
0x8b450a2 gfc_internal_error(char const*, ...)
        /vol/gcc/src/hg/master/local/gcc/fortran/error.c:1402
0x8bebb58 gfc_new_symbol(char const*, gfc_namespace*)
        /vol/gcc/src/hg/master/local/gcc/fortran/symbol.c:3139
0x8b8bb5b read_module
        /vol/gcc/src/hg/master/local/gcc/fortran/module.c:5398
0x8b8bb5b gfc_use_module
        /vol/gcc/src/hg/master/local/gcc/fortran/module.c:7192
0x8b8e216 gfc_use_modules()
        /vol/gcc/src/hg/master/local/gcc/fortran/module.c:7316
0x8b9e6bc use_modules
        /vol/gcc/src/hg/master/local/gcc/fortran/parse.c:114
0x8baa73a parse_module
        /vol/gcc/src/hg/master/local/gcc/fortran/parse.c:6111
0x8baab4c gfc_parse_file()
        /vol/gcc/src/hg/master/local/gcc/fortran/parse.c:6428
0x8bfbffd gfc_be_parse_file
        /vol/gcc/src/hg/master/local/gcc/fortran/f95-lang.c:210
Comment 8 Andrew Benson 2020-01-28 22:16:02 UTC
I think this is PR87103 causing this problem. There's a patch in that PR (simply removing the check for the overlong symbol name also works as the symbol name length is already checked elsewhere). The patch has not been approved though as there's a better fix in the works -see https://gcc.gnu.org/ml/fortran/2018-09/msg00016.html
Comment 9 Christophe Lyon 2020-01-29 09:05:55 UTC
(In reply to Rainer Orth from comment #7)
> The new testcase ICEs on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (both
> 32
> and 64-bit) as well as powerpc64-unknown-linux-gnu and
> powerpc64le-unknown-linux-gnu:
> 
> +FAIL: gfortran.dg/pr93473.f90   -O  (internal compiler error)
> +FAIL: gfortran.dg/pr93473.f90   -O  (test for excess errors)
> 

Fails on arm and aarch64 too.
Comment 10 Andrew Benson 2020-01-30 17:52:53 UTC
PR87103 is now resolved, which should also solve this problem.
Comment 11 anlauf 2020-07-09 21:06:27 UTC
Anything left to do?

I looked at the gcc-testresults, and it appears things are fixed now,
e.g. for Solaris or aarch64.
Comment 12 Andrew Benson 2020-07-09 21:13:17 UTC
No - this can be resolved - PR87103 was resolved which fixed the remaining issue with this PR. Apologies for not resolving sooner.