* [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names
@ 2020-01-29 2:18 Andrew Benson
2020-02-11 0:22 ` Andrew Benson
` (3 more replies)
0 siblings, 4 replies; 11+ messages in thread
From: Andrew Benson @ 2020-01-29 2:18 UTC (permalink / raw)
To: fortran; +Cc: gcc-patches
[-- Attachment #1: Type: text/plain, Size: 2940 bytes --]
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 <https://gcc.gnu.org/bugs/> 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
[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 1947 bytes --]
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
[-- Attachment #3: ChangeLog --]
[-- Type: text/x-changelog, Size: 300 bytes --]
2020-01-28 Andrew Benson <abensonca@gmail.com>
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names
2020-01-29 2:18 [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names Andrew Benson
@ 2020-02-11 0:22 ` Andrew Benson
2020-02-18 23:30 ` Andrew Benson
` (2 subsequent siblings)
3 siblings, 0 replies; 11+ messages in thread
From: Andrew Benson @ 2020-02-11 0:22 UTC (permalink / raw)
To: fortran; +Cc: gcc-patches
*ping*
On Tuesday, January 28, 2020 4:45:59 PM PST Andrew Benson wrote:
> 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:aNameForASubmoduleThatIsVeryLongButWhichIsLegalSt
> ill) 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 <https://gcc.gnu.org/bugs/> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names
2020-01-29 2:18 [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names Andrew Benson
2020-02-11 0:22 ` Andrew Benson
@ 2020-02-18 23:30 ` Andrew Benson
2020-02-25 0:45 ` Andrew Benson
2020-03-01 19:33 ` Andrew Benson
3 siblings, 0 replies; 11+ messages in thread
From: Andrew Benson @ 2020-02-18 23:30 UTC (permalink / raw)
To: fortran; +Cc: gcc-patches
*ping*
On Tuesday, January 28, 2020 4:45:59 PM PST Andrew Benson wrote:
> 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:aNameForASubmoduleThatIsVeryLongButWhichIsLegalSt
> ill) 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 <https://gcc.gnu.org/bugs/> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names
2020-01-29 2:18 [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names Andrew Benson
2020-02-11 0:22 ` Andrew Benson
2020-02-18 23:30 ` Andrew Benson
@ 2020-02-25 0:45 ` Andrew Benson
2020-03-01 19:33 ` Andrew Benson
3 siblings, 0 replies; 11+ messages in thread
From: Andrew Benson @ 2020-02-25 0:45 UTC (permalink / raw)
To: fortran; +Cc: gcc-patches
*ping*
On Tuesday, January 28, 2020 4:45:59 PM PST Andrew Benson wrote:
> 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:aNameForASubmoduleThatIsVeryLongButWhichIsLegalSt
> ill) 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 <https://gcc.gnu.org/bugs/> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names
2020-01-29 2:18 [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names Andrew Benson
` (2 preceding siblings ...)
2020-02-25 0:45 ` Andrew Benson
@ 2020-03-01 19:33 ` Andrew Benson
2020-03-01 22:42 ` Steve Kargl
3 siblings, 1 reply; 11+ messages in thread
From: Andrew Benson @ 2020-03-01 19:33 UTC (permalink / raw)
To: fortran; +Cc: gcc-patches
*ping*
On Tuesday, January 28, 2020 4:45:59 PM PST Andrew Benson wrote:
> 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:aNameForASubmoduleThatIsVeryLongButWhichIsLegalSt
> ill) 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 <https://gcc.gnu.org/bugs/> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names
2020-03-01 19:33 ` Andrew Benson
@ 2020-03-01 22:42 ` Steve Kargl
2020-03-01 22:43 ` Andrew Benson
2020-03-01 22:43 ` Thomas Koenig
0 siblings, 2 replies; 11+ messages in thread
From: Steve Kargl @ 2020-03-01 22:42 UTC (permalink / raw)
To: Andrew Benson; +Cc: fortran, gcc-patches
On Sun, Mar 01, 2020 at 11:33:10AM -0800, Andrew Benson wrote:
> *ping*
>
Andrew,
The patch looks fine to me. PS: in general, after multiple
pings, just commit the patch.
--
Steve
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names
2020-03-01 22:42 ` Steve Kargl
@ 2020-03-01 22:43 ` Andrew Benson
2020-03-01 22:43 ` Thomas Koenig
1 sibling, 0 replies; 11+ messages in thread
From: Andrew Benson @ 2020-03-01 22:43 UTC (permalink / raw)
To: sgk; +Cc: fortran, gcc-patches
Thanks, Steve. I'll get this committed tomorrow morning.
-Andrew
On Sunday, March 1, 2020 2:42:13 PM PST Steve Kargl wrote:
> On Sun, Mar 01, 2020 at 11:33:10AM -0800, Andrew Benson wrote:
> > *ping*
>
> Andrew,
>
> The patch looks fine to me. PS: in general, after multiple
> pings, just commit the patch.
--
* Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html
* Galacticus: https://github.com/galacticusorg/galacticus
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names
2020-03-01 22:42 ` Steve Kargl
2020-03-01 22:43 ` Andrew Benson
@ 2020-03-01 22:43 ` Thomas Koenig
2020-03-02 2:10 ` Steve Kargl
1 sibling, 1 reply; 11+ messages in thread
From: Thomas Koenig @ 2020-03-01 22:43 UTC (permalink / raw)
To: sgk, Andrew Benson; +Cc: fortran, gcc-patches
Am 01.03.20 um 23:42 schrieb Steve Kargl:
> PS: in general, after multiple
> pings, just commit the patch.
... well, maybe after a "If there is no reply within a
couple of days, I will commit this" :-)
Regards
Thomas
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names
2020-03-01 22:43 ` Thomas Koenig
@ 2020-03-02 2:10 ` Steve Kargl
2020-03-02 6:42 ` Paul Richard Thomas
0 siblings, 1 reply; 11+ messages in thread
From: Steve Kargl @ 2020-03-02 2:10 UTC (permalink / raw)
To: Thomas Koenig; +Cc: Andrew Benson, fortran, gcc-patches
On Sun, Mar 01, 2020 at 11:43:23PM +0100, Thomas Koenig wrote:
> Am 01.03.20 um 23:42 schrieb Steve Kargl:
> > PS: in general, after multiple
> > pings, just commit the patch.
>
> ... well, maybe after a "If there is no reply within a
> couple of days, I will commit this" :-)
>
Andrew submitted the patch and pinged it twice. gfortran
development is running on fumes. Beating one's head
against a wall seems counter productive. I'm operating
on a principle that if one has commit access for gfortran,
one is committing a patch with the best attentions. Could
this lead to a regression? Sure. The alternative of
constantly pinging patches is to simply stop submitting
patches.
--
Steve
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names
2020-03-02 2:10 ` Steve Kargl
@ 2020-03-02 6:42 ` Paul Richard Thomas
2020-03-02 17:33 ` Andrew Benson
0 siblings, 1 reply; 11+ messages in thread
From: Paul Richard Thomas @ 2020-03-02 6:42 UTC (permalink / raw)
To: Steve Kargl; +Cc: Thomas Koenig, Andrew Benson, fortran, gcc-patches
Andrew,
I agree with Steve. That said, I took a look at your patch and it's
just fine. OK to commit.
Cheers
Paul
On Mon, 2 Mar 2020 at 02:10, Steve Kargl
<sgk@troutmask.apl.washington.edu> wrote:
>
> On Sun, Mar 01, 2020 at 11:43:23PM +0100, Thomas Koenig wrote:
> > Am 01.03.20 um 23:42 schrieb Steve Kargl:
> > > PS: in general, after multiple
> > > pings, just commit the patch.
> >
> > ... well, maybe after a "If there is no reply within a
> > couple of days, I will commit this" :-)
> >
>
> Andrew submitted the patch and pinged it twice. gfortran
> development is running on fumes. Beating one's head
> against a wall seems counter productive. I'm operating
> on a principle that if one has commit access for gfortran,
> one is committing a patch with the best attentions. Could
> this lead to a regression? Sure. The alternative of
> constantly pinging patches is to simply stop submitting
> patches.
>
>
> --
> Steve
--
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names
2020-03-02 6:42 ` Paul Richard Thomas
@ 2020-03-02 17:33 ` Andrew Benson
0 siblings, 0 replies; 11+ messages in thread
From: Andrew Benson @ 2020-03-02 17:33 UTC (permalink / raw)
To: Paul Richard Thomas; +Cc: Steve Kargl, Thomas Koenig, fortran, gcc-patches
Hi Paul,
Thanks for the review. This is now committed as:
r10-6976-gf3c276aec26d9e406cc4bbf0e18b1105df63f0ee
I'll keep this in mind for future patches - this one seemed simple enough that
I'd be confident to commit it without review after waiting for a few days. I'm
hoping to find time to finish some other patches soon, some of which are more
complicated and I'd definitely want to get reviewed before I commit them.
Thanks again everyone.
-Andrew
On Monday, March 2, 2020 6:41:46 AM PST Paul Richard Thomas wrote:
> Andrew,
>
> I agree with Steve. That said, I took a look at your patch and it's
> just fine. OK to commit.
>
> Cheers
>
> Paul
>
> On Mon, 2 Mar 2020 at 02:10, Steve Kargl
>
> <sgk@troutmask.apl.washington.edu> wrote:
> > On Sun, Mar 01, 2020 at 11:43:23PM +0100, Thomas Koenig wrote:
> > > Am 01.03.20 um 23:42 schrieb Steve Kargl:
> > > > PS: in general, after multiple
> > > > pings, just commit the patch.
> > >
> > > ... well, maybe after a "If there is no reply within a
> > > couple of days, I will commit this" :-)
> >
> > Andrew submitted the patch and pinged it twice. gfortran
> > development is running on fumes. Beating one's head
> > against a wall seems counter productive. I'm operating
> > on a principle that if one has commit access for gfortran,
> > one is committing a patch with the best attentions. Could
> > this lead to a regression? Sure. The alternative of
> > constantly pinging patches is to simply stop submitting
> > patches.
> >
> >
> > --
> > Steve
--
* Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html
* Galacticus: https://github.com/galacticusorg/galacticus
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-03-02 17:33 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-29 2:18 [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names Andrew Benson
2020-02-11 0:22 ` Andrew Benson
2020-02-18 23:30 ` Andrew Benson
2020-02-25 0:45 ` Andrew Benson
2020-03-01 19:33 ` Andrew Benson
2020-03-01 22:42 ` Steve Kargl
2020-03-01 22:43 ` Andrew Benson
2020-03-01 22:43 ` Thomas Koenig
2020-03-02 2:10 ` Steve Kargl
2020-03-02 6:42 ` Paul Richard Thomas
2020-03-02 17:33 ` Andrew Benson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).