https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62142
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kargl at gcc dot gnu.org
--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Ondřej Čertík from comment #0)
> Created attachment 33327 [details]
> Source file to reproduce the segfault
>
> $ cat test_segfault.f90
> program test_segfault
> implicit none
> integer, parameter :: dp=kind(0.d0)
> real(dp) :: L
> real(dp), allocatable :: X(:)
> X = X - L*floor(X/L)
> end program
>
(snip)
> When I execute "gfortran -v -save-temps test_segfault.f90", it doesn't
> produce preprocessed sources, I assume the segfault happens in the parser. I
> have isolated the segfault, it happens in a large codebase and prevents its
> compilation (the array is allocated in our code, the above is the simplest
> code to reproduce the problem).
>
> This is my first bug report, please let me know if you need further
> information.
For such a short program, we don't necessarily need -save-temps.
Note, your reduce test case is nonconforming code because it
uses L and X in a RHS expression without being defined. With the
small change
program test_segfault
implicit none
integer, parameter :: dp=kind(0.d0)
real(dp) :: L
real(dp), allocatable :: X(:)
L = 42
X = [1, 2]
X = X - L*floor(X/L)
end program
the code is now conforming and it still exhibits the bug.
I suspect that the bug is due to a combination of -frealloc-lhs
and that floor is generated as inline code. With -frealloc-lhs,
I get the same ICE that you find. With -fno-realloc-lhs, I get
a compiled executable but it segfaults at runtime because x = [1,2]
obviously won't work. If I add an allocate(x(2)) prior to
x = [1,2], then -fno-realloc-lhs produced executable runs as
expected. So, as a workaround explicitly allocate memory and
use -fno-realloc-lhs.
