gfortran ICE regression with nested allocatable derived types using getter method #30
Comments
|
I forgot to mention that if this is a gfortran bug, I'm happy to report it on bugzilla. However, I would like to avoid keeping the reference to StringiFor and reduce the MWE further, but I think I would need some help since my understanding of the internals of StringiFor is limited. |
|
@epagone thanks for reporting the bug. I am checking it right now. btw an ICE is highly a compiler bug thus probably I can only try to find a workaround. |
|
I have read the test, it looks standard compliant to me. I have tested with Intel Fortran compiler and it seems to work as expected. As consequence for me is a real ICE and I cannot find a workaround for it. If you can report the bug to the GNU Fortran team I'll appreciate it very much, bugzilla is often a nightmare for me. I left open this issue in order to try your test with future versions of GNU Fortran. cheers |
|
Thanks @szaghi! I have reported the ICE on bugzilla yesterday. However, I think that my test case is suboptimal because it depends directly on StringiFor (external library) and this might deter gfortran volunteers to look into the issue. If you have time, it would be great if you could help me to reduce the test case further without relying on StringiFor, but I know you're very busy. Thank you very much for checking my test case and testing it with Intel Fortran. |
|
@epagone I can try, but not sure when I'll have the time, sorry |
epagone
changed the title
FWIW, I have posted on Bugzilla a new MWE that exposes the ICE without using StringiFor. However, it might take a long time to fix the issue. @szaghi any suggestion for a workaround? I am trying to find one with no luck and in my case using the old version of StringiFor is a pain :( |
|
I read your MWE, nice. However, it is really difficult for me to find a workaround. There was a version of Stringifor that does not raise this ICE? If you can tell me which version I can try to find a workaround for the current version. |
|
The version of StringiFor prior to the fix of bug #28 (commit module foo_m
use stringifor
implicit none
type :: foo_t
type(string), allocatable :: foo_s(:)
contains
procedure, public :: get_s
end type foo_t
type :: data_t
integer :: n_foo_s
type(foo_t), allocatable :: foo(:)
contains
procedure, public :: data_get_foo_s
end type data_t
contains
function get_s(self)
class(foo_t), intent(in) :: self
type(string) :: get_s( size(self%foo_s) )
get_s = self%foo_s
end function get_s
function data_get_foo_s(self, ith)
class(data_t), intent(in) :: self
integer, intent(in) :: ith
type(string) :: data_get_foo_s( self%n_foo_s )
data_get_foo_s = self%foo(ith)%get_s()
end function data_get_foo_s
end module foo_m
program bug_stringifor
use foo_m
implicit none
type(data_t) :: data
type(string), allocatable :: bar(:)
data%n_foo_s = 5
allocate( data%foo(1) )
allocate( data%foo(1)%foo_s( data%n_foo_s ) )
data%foo(1)%foo_s = [string("alpha"), string("bravo"), string("charlie"), &
string("delta"), string("foxtrot")]
allocate( bar( data%n_foo_s ) )
bar = data%data_get_foo_s(1)
print *, "bar = ", bar
end program bug_stringiforI keep my fingers crossed for a workaround, thanks for your time. |
|
Another interesting thing that I have discovered is that a Stringifor-free version of the test case above does still expose the ICE module foo_m
implicit none
type :: string
character(len=:), allocatable :: s
end type string
type :: foo_t
type(string), allocatable :: foo_s(:)
contains
procedure, public :: get_s
end type foo_t
type :: data_t
integer :: n_foo_s
type(foo_t), allocatable :: foo(:)
contains
procedure, public :: data_get_foo_s
end type data_t
contains
function get_s(self)
class(foo_t), intent(in) :: self
type(string) :: get_s( size(self%foo_s) )
get_s = self%foo_s
end function get_s
function data_get_foo_s(self, ith)
class(data_t), intent(in) :: self
integer, intent(in) :: ith
type(string) :: data_get_foo_s( self%n_foo_s )
data_get_foo_s = self%foo(ith)%get_s()
end function data_get_foo_s
end module foo_m
program bug_stringifor
use foo_m
implicit none
type(data_t) :: data
type(string), allocatable :: bar(:)
data%n_foo_s = 5
allocate( data%foo(1) )
allocate( data%foo(1)%foo_s( data%n_foo_s ) )
data%foo(1)%foo_s = [string("alpha"), string("bravo"), string("charlie"), &
string("delta"), string("foxtrot")]
allocate( bar( data%n_foo_s ) )
bar = data%data_get_foo_s(1)
print *, "bar = ", bar(1)%s
end program bug_stringiforSo @szaghi in StringiFor commit |
|
Ok, the relevant changes were the scope of |
|
For the records, my report on Bugzilla has been analysed and reduced further. I admit I do not understand clearly what is triggering the problem even after the detailed analysis, but this might help you, @szaghi. Just a heads-up. |
|
Still present in gfortran 10.1 |
The fix for bug #28 introduced a regression (or exposed a bug in gfortran 9.2.1).
The previous version of StringiFor (before bug #28 was fixed) worked as expected and did not expose this ICE.
(Maybe the test case can be reduced further but it took me already a lot of time to reduce it to the present form from the original case.)
The text was updated successfully, but these errors were encountered: