From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17427 invoked by alias); 29 Jan 2020 00:46:05 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 17285 invoked by uid 89); 29 Jan 2020 00:46:04 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-17.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-pg1-f194.google.com Received: from mail-pg1-f194.google.com (HELO mail-pg1-f194.google.com) (209.85.215.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 Jan 2020 00:46:02 +0000 Received: by mail-pg1-f194.google.com with SMTP id u131so7914897pgc.10; Tue, 28 Jan 2020 16:46:02 -0800 (PST) Return-Path: Received: from andrew-precision-3520.localnet (pool-239.obs.carnegiescience.edu. [192.91.178.239]) by smtp.gmail.com with ESMTPSA id x66sm226545pfd.71.2020.01.28.16.45.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jan 2020 16:45:59 -0800 (PST) From: Andrew Benson To: fortran@gcc.gnu.org Cc: gcc-patches@gcc.gnu.org Subject: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names Date: Wed, 29 Jan 2020 02:18:00 -0000 Message-ID: <2861300.JBue2MTAIU@andrew-precision-3520> User-Agent: KMail/5.2.3 (Linux/4.4.0-170-generic; KDE/5.36.0; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart2105097.NJ08ot1UZh" Content-Transfer-Encoding: 7Bit X-SW-Source: 2020-01/txt/msg01901.txt.bz2 This is a multi-part message in MIME format. --nextPart2105097.NJ08ot1UZh Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Content-length: 2940 I opened PR93486 for this problem: The following causes an ICE with revision ad690d79cfbb905c5546c9333c5fd089d906505b: module ivs interface l module procedure l_ end interface l contains function l_() end function l_ end module ivs module aModeratleyLongModuleName use ivs interface module subroutine cmo() end subroutine cmo end interface end module aModeratleyLongModuleName submodule (aModeratleyLongModuleName) aNameForASubmoduleThatIsVeryLongButWhichIsLegalStill contains module procedure cmo end procedure cmo end submodule aNameForASubmoduleThatIsVeryLongButWhichIsLegalStill submodule (aModeratleyLongModuleName:aNameForASubmoduleThatIsVeryLongButWhichIsLegalStill) sb end submodule sb submodule (aModeratleyLongModuleName:sb) sc end submodule sc $ 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 20200128 (experimental) (GCC) $ gfortran -c test.F90 -o test.o f951: internal compiler error: Segmentation fault 0xe1bc9f crash_signal ../../gcc-git/gcc/toplev.c:328 0x7f98119c71ef ??? /data001/abenson/Galacticus/Tools/glibc-2.12.1/signal/../sysdeps/unix/ sysv/linux/x86_64/sigaction.c:0 0x84b3f0 gfc_use_modules() ../../gcc-git/gcc/fortran/module.c:7315 0x85acc8 use_modules ../../gcc-git/gcc/fortran/parse.c:114 0x866daa parse_module ../../gcc-git/gcc/fortran/parse.c:6111 0x86733c gfc_parse_file() ../../gcc-git/gcc/fortran/parse.c:6428 0x8b780f 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 for instructions. The ICE goes away if the module and/or submodule names are made shorter. The problem is caused when loading (generic or operator) interfaces from a module file. The module name can include the submodule name, so a size of 2*GFC_MAX_SYMBOL_LEN+2 is required to read this in. The attached patch fixes this problem and regression tests cleanly *if* the patch for PR87103 is applied (otherwise that problem gets triggered by the new test case). PR87103 has been a long-standing issue - there's a patch that works (either my original ugly fix, or the better fix proposed by Bernhard at https:// gcc.gnu.org/ml/fortran/2018-09/msg00044.html ). It would be very nice to get one of these patches committed. -Andrew -- * Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html * Galacticus: https://github.com/galacticusorg/galacticus --nextPart2105097.NJ08ot1UZh Content-Disposition: attachment; filename="patch.diff" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="patch.diff" Content-length: 1947 diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c index 4487f65..b6a4e87 100644 --- a/gcc/fortran/module.c +++ b/gcc/fortran/module.c @@ -4568,7 +4568,9 @@ static void load_operator_interfaces (void) { const char *p; - char name[GFC_MAX_SYMBOL_LEN + 1], module[GFC_MAX_SYMBOL_LEN + 1]; + /* "module" must be large enough for the case of submodules in which the name + has the form module.submodule */ + char name[GFC_MAX_SYMBOL_LEN + 1], module[2 * GFC_MAX_SYMBOL_LEN + 2]; gfc_user_op *uop; pointer_info *pi = NULL; int n, i; @@ -4624,7 +4626,9 @@ static void load_generic_interfaces (void) { const char *p; - char name[GFC_MAX_SYMBOL_LEN + 1], module[GFC_MAX_SYMBOL_LEN + 1]; + /* "module" must be large enough for the case of submodules in which the name + has the form module.submodule */ + char name[GFC_MAX_SYMBOL_LEN + 1], module[2 * GFC_MAX_SYMBOL_LEN + 2]; gfc_symbol *sym; gfc_interface *generic = NULL, *gen = NULL; int n, i, renamed; diff --git a/gcc/testsuite/gfortran.dg/pr93486.f90 b/gcc/testsuite/gfortran.dg/pr93486.f90 new file mode 100644 index 0000000..5037d40 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/pr93486.f90 @@ -0,0 +1,30 @@ +! { dg-do compile } +! PR fortran/93486 +module ivs + interface l + module procedure l_ + end interface l +contains + function l_() + end function l_ +end module ivs + +module aModeratleyLongModuleName + use ivs + interface + module subroutine cmo() + end subroutine cmo + end interface +end module aModeratleyLongModuleName + +submodule (aModeratleyLongModuleName) aNameForASubmoduleThatIsVeryLongButWhichIsLegalStill +contains + module procedure cmo + end procedure cmo +end submodule aNameForASubmoduleThatIsVeryLongButWhichIsLegalStill + +submodule (aModeratleyLongModuleName:aNameForASubmoduleThatIsVeryLongButWhichIsLegalStill) sb +end submodule sb + +submodule (aModeratleyLongModuleName:sb) sc +end submodule sc --nextPart2105097.NJ08ot1UZh Content-Disposition: attachment; filename="ChangeLog" Content-Transfer-Encoding: 7Bit Content-Type: text/x-changelog; charset="UTF-8"; name="ChangeLog" Content-length: 300 2020-01-28 Andrew Benson PR fortran/93486 * module.c: Increase size of variables used to read module names when loading interfaces from module files to permit cases where the name is the concatenation of a module and submodule name. * gfortran.dg/pr93486.f90: New test. --nextPart2105097.NJ08ot1UZh--