Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names

Andrew Benson-3
*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

Reply | Threaded
Open this post in threaded view
|

Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names

Andrew Benson-3
*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

Reply | Threaded
Open this post in threaded view
|

Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names

Andrew Benson-3
In reply to this post by Andrew Benson-3
*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

Reply | Threaded
Open this post in threaded view
|

Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names

Steve Kargl
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
Reply | Threaded
Open this post in threaded view
|

Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names

Andrew Benson-3
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

Reply | Threaded
Open this post in threaded view
|

Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names

Thomas Koenig-6
In reply to this post by Steve Kargl
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
Reply | Threaded
Open this post in threaded view
|

Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names

Paul Richard Thomas
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
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names

Andrew Benson-3
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
>
> <[hidden email]> 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