[Bug fortran/66544] [F03] ICE on function with procedure-pointer result in combination with implicit none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66544 --- Comment #6 from Gerhard Steinmetz --- When running several private scripts, there was a difference between some scripts including option -fimplicit-none, and some others that didn't. Reducing and simplifying gave example z0.f90 from comment 1. Explicitly including "implicit none" into source then gives first example in comment 0. > Btw, I don't fully understand why "implicit none" should make any > difference here. Me too. > There is also the very closely related PR54107, which is fixed already. Now interestingly, compiling examples from ./gcc/testsuite/gfortran.dg/ with an additional -fimplicit-none shows the same error message as above for these sources : automatic_char_len_1.f90 data_value_1.f90 init_flag_9.f90 recursive_interface_1.f90 recursive_interface_2.f90 $ gfortran-6 --version GNU Fortran (SUSE Linux) 6.0.0 20160121 (experimental) [trunk revision 232670] $ gfortran-6 -c recursive_interface_1.f90 # ok $ gfortran-6 -fimplicit-none -c recursive_interface_1.f90 recursive_interface_1.f90:16:0: function baz() result(r3) internal compiler error: in gfc_typenode_for_spec, at fortran/trans-types.c:1064
[Bug fortran/40737] Pointer references sometimes fail to define "span" symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40737 Gerhard Steinmetz changed: What|Removed |Added CC||gerhard.steinmetz.fortran@t ||-online.de --- Comment #18 from Gerhard Steinmetz --- FYI, compiling example from comment 17 together with -flto : $ gfortran-6 -flto -c pr40737_c17.f90 pr40737_last.f90:23:0: internal compiler error: in get_partitioning_class, at symtab.c:1794 $ gfortran-5.3.1 -flto -c pr40737_c17.f90 pr40737_last.f90:23:0: internal compiler error: in write_symbol, at lto-streamer-out.c:2547
[Bug fortran/69603] New: ICE: segfault with -fimplicit-none and proc_ptr_comp_24.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69603 Bug ID: 69603 Summary: ICE: segfault with -fimplicit-none and proc_ptr_comp_24.f90 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- While playing around, one example from ./gcc/testsuite/gfortran.dg/ together with option -fimplicit-none segfaults : $ gfortran-6 -fimplicit-none -c proc_ptr_comp_24.f90 f951: internal compiler error: Segmentation fault $ gfortran-5.3.1 -fimplicit-none -c proc_ptr_comp_24.f90 f951: internal compiler error: Segmentation fault Whereas, no error/ICE with : $ gfortran-6 -c proc_ptr_comp_24.f90 $ gfortran-5.3.1 -c proc_ptr_comp_24.f90 Example originates to pr42045.
[Bug fortran/69604] New: ICE in gfc_add_modify_loc, at fortran/trans.c:159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69604 Bug ID: 69604 Summary: ICE in gfc_add_modify_loc, at fortran/trans.c:159 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- The following examples together with : $ gfortran-6 --version GNU Fortran (SUSE Linux) 6.0.0 20160121 (experimental) [trunk revision 232670] $ cat z1.f90 program p x(n) = n() print *, x(n) end $ cat z2.f90 program p x(n) = n(1.0) print *, x(n) end $ cat z4.f90 program p complex :: z[*] real :: x[*] z = x / cmplx(0.0, x) yield : $ gfortran-6 -c z1.f90 internal compiler error: in gfc_add_modify_loc, at fortran/trans.c:159 $ gfortran-6 -fcoarray=single -c z4.f90 internal compiler error: in gfc_add_modify_loc, at fortran/trans.c:159 A previous version gives : $ gfortran-5.3.1 -c z1.f90 internal compiler error: in conv_function_val, at fortran/trans-expr.c:3489
[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69604 --- Comment #1 from Gerhard Steinmetz --- While playing around, one example from ./gcc/testsuite/gfortran.dg/ shows the same error with v6.0.0, but not with v5.3.1 : $ gfortran-6 -c complex_intrinsic_6.f90 internal compiler error: in gfc_add_modify_loc, at fortran/trans.c:159 $ gfortran-5 -c complex_intrinsic_6.f90 # no ICE --- Please correct : last line was cut away for example z4.f90 -- add "end"
[Bug fortran/69514] ICE with nested array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69514 --- Comment #2 from Gerhard Steinmetz --- Test case from comment 0 can be reduced to e.g. $ cat z3.f90 program p real, parameter :: w(2) = [real :: 0, 3.0*[real :: 2]] print *, w end program $ gfortran-6 -c z3.f90 f951: internal compiler error: Segmentation fault Another variation is to revers operands. As known, this compiles and runs, but gives WRONG results. $ cat z4.f90 program p real, parameter :: w(2) = [real :: 0, [real :: 2]*3.0] print *, w end program $ gfortran-6 z4.f90 $ a.out 0. 0. Analogous for other operations, other intrinsic types, other combinations - look up especially in attached files of pr66193. Some variants segfault, some compile and run silently wrong. This theme is known from pr66193.
[Bug fortran/69636] New: ICE(s) on using option -fmodule-private
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69636 Bug ID: 69636 Summary: ICE(s) on using option -fmodule-private Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- A validation run with option -fmodule-private exposes a few problems when running on test files from ./gcc/testsuite/gfortran.dg/ $ gfortran-6 -fmodule-private -c function_kinds_3.f90 f951: internal compiler error: in gfc_convert_chartype, at fortran/intrinsic.c:4812 $ gfortran-6 -fmodule-private -c entry_16.f90 f951: internal compiler error: Unable to find symbol ‘cx_radc’ $ gfortran-6 -fmodule-private -c associate_6.f03 f951: internal compiler error: find_array_spec(): Missing spec And, respectively : f951: internal compiler error: Segmentation fault $ gfortran-6 -fmodule-private -c derived_external_function_1.f90 $ gfortran-6 -fmodule-private -c derived_function_interface_1.f90 $ gfortran-6 -fmodule-private -c function_kinds_1.f90 $ gfortran-6 -fmodule-private -c function_types_2.f90 $ gfortran-6 -fmodule-private -c typebound_operator_9.f03
[Bug fortran/69636] ICE(s) on using option -fmodule-private
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69636
--- Comment #1 from Gerhard Steinmetz
---
To begin with a short example, namely function_kinds_3.f90.
Placing statement "private" explicit in source, reducing a bit,
then compiling without "-fmodule-private" :
$ cat z1.f90
module m
private
integer, parameter :: char_t = kind('a')
end module m
character(1,char_t) function test1()
use m
test1 = 'A'
end function test1
$ gfortran-6 --version
GNU Fortran (SUSE Linux) 6.0.0 20160121 (experimental) [trunk revision 232670]
$ gfortran-6 -c z1.f90
z1.f90:6:12:
character(1,char_t) function test1()
1
Error: Parameter ‘char_t’ at (1) has not been declared or is a variable, which
does not reduce to a constant expression
f951: internal compiler error: in gfc_convert_chartype, at
fortran/intrinsic.c:4812
$ gfortran-5.3.1 -c z1.f90
(null):0: confused by earlier errors, bailing out
$ gfortran-4.9.0 -c z1.f90
f951: internal compiler error: in gfc_convert_chartype, at
fortran/intrinsic.c:4623
[Bug fortran/69659] [6 Regression] ICE on using option -frepack-arrays, in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69659 --- Comment #1 from Gerhard Steinmetz --- List of affected files : actual_array_offset_1.f90 allocate_class_3.f90 allocate_with_source_16.f90 allocate_with_source_8.f08 class_array_11.f03 class_array_20.f03 class_array_21.f03 class_array_6.f03 class_array_7.f03 class_to_type_1.f03 elemental_dependency_5.f90 finalize_10.f90 finalize_15.f90 finalize_29.f08 sizeof_4.f90 typebound_generic_14.f03 type_to_class_1.f03 unlimited_polymorphic_17.f90 unlimited_polymorphic_18.f90 unlimited_polymorphic_19.f90 unlimited_polymorphic_1.f03
[Bug fortran/69659] New: [6 Regression] ICE on using option -frepack-arrays, in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69659 Bug ID: 69659 Summary: [6 Regression] ICE on using option -frepack-arrays, in gfc_conv_descriptor_data_get Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- A validation run with option -frepack-arrays exposes a regression when running on test files from ./gcc/testsuite/gfortran.dg/ ... One example : $ gfortran-6 --version GNU Fortran (SUSE Linux) 6.0.0 20160121 (experimental) [trunk revision 232670] $ gfortran-6 -frepack-arrays -c class_array_11.f03 class_array_11.f03:17:0: SUBROUTINE vector_operation(pvec) internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:144 $ gfortran-5.3.1 -frepack-arrays -c class_array_11.f03 # no ICE $ gfortran-4.9.0 -frepack-arrays -c class_array_11.f03 # no ICE
[Bug fortran/69636] ICE(s) on using option -fmodule-private
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69636 --- Comment #3 from Gerhard Steinmetz --- Thank you for commenting. A few comments will follow with melt down (simplified) test cases. Hopefully, nothing gets lost. It might have been better to post a handful of separate problem reports instead of this lengthy one. But on the other hand, theses issues belong together thematically. And there are several more cases/variants. My best regards.
[Bug fortran/69636] ICE(s) on using option -fmodule-private
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69636 --- Comment #4 from Gerhard Steinmetz --- Applying same operations as in comment 1 to derived_external_function_1.f90 : $ cat z2.f90 module m private type t integer g end type end type(t) function f() result(ff) use m ff%g = 42 end $ gfortran-6 -c z2.f90 f951: internal compiler error: Segmentation fault
[Bug fortran/69636] ICE(s) on using option -fmodule-private
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69636 --- Comment #5 from Gerhard Steinmetz --- The ICE with associate_6.f03 and -fmodule-private depends on including "implicit none" in main program : $ cat z3.f90 module m private contains pure function func (n) result (f) integer, intent(in) :: n integer :: f(n) f = 0.0 end function end module program p use m implicit none associate (arr => func (4)) print *, arr(1) end associate end $ gfortran-6 -c z3.f90 z3.f90:14:20: associate (arr => func (4)) 1 Error: Function 'func' at (1) has no IMPLICIT type z3.f90:14:28: associate (arr => func (4)) 1 Error: Symbol 'arr' at (1) has no IMPLICIT type f951: internal compiler error: find_array_spec(): Missing spec --- $ cat z3b.f90 module m private contains pure function func (n) result (f) integer, intent(in) :: n integer :: f(n) f = 0.0 end function end module program p use m ! implicit none associate (arr => func (4)) print *, arr(1) end associate end $ gfortran-6 -c z3b.f90 z3b.f90:14:28: associate (arr => func (4)) 1 Error: Associate-name 'arr' at (1) is used as array
[Bug fortran/69636] ICE(s) on using option -fmodule-private
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69636 --- Comment #6 from Gerhard Steinmetz --- And for visibility of functions etc., a reduced and modified entry_16.f90 : $ cat z4.f90 module complex private :: cx_cadr, cx_radc type cx integer :: re integer :: im end type interface operator (+) module procedure cx_cadr, cx_radc end interface contains function cx_cadr(z, r) entry cx_radc(r, z) type(cx), intent(in) :: z integer, intent(in) :: r type(cx) :: cx_cadr, cx_radc cx_cadr%re = z%re + r cx_cadr%im = z%im end function end module program p use complex type(cx) :: a = cx(1, 2) print *, (a + 2) print *, (2 + a) end $ gfortran-6 -c z4.f90 f951: internal compiler error: Unable to find symbol 'cx_cadr'
[Bug fortran/69659] [6 Regression] ICE on using option -frepack-arrays, in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69659 --- Comment #3 from Gerhard Steinmetz --- Responsible is the class declaration of "x" : $ cat z1.f90 program p type t integer :: a end type contains subroutine s (x) class(t), intent(inout) :: x(:) print *, x(1)%a end end $ gfortran-6 -frepack-arrays -c z1.f90 z1.f90:6:0: subroutine s (x) internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:144 --- Replacing "class" with "type" : $ cat z2.f90 program p type t integer :: a end type contains subroutine s (x) type(t), intent(inout) :: x(:) print *, x(1)%a end end $ gfortran-6 -frepack-arrays -c z2.f90 # ok
[Bug fortran/69659] [6 Regression] ICE on using option -frepack-arrays, in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69659 --- Comment #4 from Gerhard Steinmetz --- Another test scheme : $ cat z4.f90 module m type t class(*), allocatable :: z(:) end type contains subroutine s (x) class(*), intent(in) :: x(:) print *, size(x) end subroutine end module $ gfortran-6 -frepack-arrays -c z4.f90 z4.f90:6:0: subroutine s (x) internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:144 $ gfortran-5.3.1 -frepack-arrays -c z4.f90 # ok --- Replacing "class" with "type" : $ cat z5.f90 module m type t class(*), allocatable :: z(:) end type contains subroutine s (x) type(t), intent(in) :: x(:) print *, size(x) end subroutine end module $ gfortran-6 -frepack-arrays -c z5.f90 # ok $ gfortran-5.3.1 -frepack-arrays -c z5.f90 # ok
[Bug fortran/57284] [OOP] ICE with find_array_spec for polymorphic arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57284 --- Comment #4 from Gerhard Steinmetz --- As known, causative is the class declaration of "a", when using size(a). Some variants, replacing "class" with "type" : $ cat z2.f90 module m type t end type contains function foo(a, b) result(add) class(t), intent(in) :: a(:) type(t), intent(in) :: b(size(a)) type(t) :: add(size(a)) end function end module program p use m end program $ gfortran-6 -c z2.f90 f951: internal compiler error: find_array_spec(): unused as(1) --- $ cat z3.f90 module m type t end type contains function foo(a, b) result(add) type(t), intent(in) :: a(:) class(t), intent(in) :: b(size(a)) type(t) :: add(size(a)) end function end module program p use m end program $ gfortran-6 -c z3.f90 # ok --- $ cat z4.f90 module m type t end type contains function foo(a, b) result(add) type(t), intent(in) :: a(:) type(t), intent(in) :: b(size(a)) type(t) :: add(size(a)) end function end module program p use m end program $ gfortran-6 -c z4.f90 # ok
[Bug fortran/69499] [F03] ICE-on-invalid on combining select type with wrong statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69499 --- Comment #3 from Gerhard Steinmetz --- Yet another example : $ cat z4.f90 module m class(*) :: z select type (x => z) end
[Bug fortran/69859] New: ICE on incomplete character declaration statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69859 Bug ID: 69859 Summary: ICE on incomplete character declaration statement Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- With an incomplete declaration : $ cat z1.f90 program p type t character x y end type end $ gfortran-6 z1.f90 z1.f90:3:17: character x y 1 Error: Syntax error in data declaration at (1) f951: internal compiler error: gfc_is_constant_expr(): Unknown expression type --- Whereas, without embedding in type : $ cat z2.f90 program p character x y end $ gfortran-6 z2.f90 z2.f90:2:14: character x y 1 Error: Syntax error in data declaration at (1) # no ICE
[Bug fortran/69859] ICE on incomplete character declaration statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69859 --- Comment #1 from Gerhard Steinmetz --- Some other variants : $ cat z3.f90 program p type t character a , character b = character c : character d + character e . character f % !... end type end $ cat z5.f90 program p type t character, allocatable :: x(:) y(:) end type end $ gfortran-6 z3.f90 #... Error: Syntax error in data declaration at (1) f951: internal compiler error: gfc_is_constant_expr(): Unknown expression type
[Bug fortran/69859] ICE on incomplete character declaration statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69859 --- Comment #2 from Gerhard Steinmetz --- A bit different : $ cat z7.f90 program p type t character(2), allocatable :: a(*) character(*), allocatable :: b(2) character(*), allocatable :: c(*) end type end $ gfortran-6 z7.f90 #... Error: Allocatable component of structure at (1) must have a deferred shape f951: internal compiler error: gfc_is_constant_expr(): Unknown expression type
[Bug fortran/69860] New: ICE on missing end apostrophe with character(kind=4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69860 Bug ID: 69860 Summary: ICE on missing end apostrophe with character(kind=4) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- With a missing end apostrophe : $ cat z1.f90 program p character(len=2, kind=4) :: a = 'aa', b = 'bb end $ gfortran-6 -g z1.f90 z1.f90:2:46: character(len=2, kind=4) :: a = 'aa', b = 'bb 1 Error: Unterminated character constant beginning at (1) f951: internal compiler error: gfc_is_constant_expr(): Unknown expression type For some other compile options, error message may depend on $LANG etc.
[Bug fortran/69860] ICE on missing end apostrophe with character(kind=4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69860 --- Comment #1 from Gerhard Steinmetz --- No ICE if "kind=4" is changed to "kind=1" : $ cat z2.f90 program p character(len=2, kind=1) :: a = 'aa', b = 'bb end $ gfortran-6 -g z2.f90 z2.f90:2:46: character(len=2, kind=1) :: a = 'aa', b = 'bb 1 Error: Unterminated character constant beginning at (1)
[Bug fortran/69861] New: ICE on declaring class parameter array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69861
Bug ID: 69861
Summary: ICE on declaring class parameter array
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: gerhard.steinmetz.fort...@t-online.de
Target Milestone: ---
A code snippet with a parameter array :
$ cat z1.f90
program p
type t
character :: c
end type
class(t), parameter :: z(2) = t('a')
print *, z%c
end
$ gfortran-6 z1.f90
z1.f90:6:0:
print *, z%c
internal compiler error: in insert_component_ref, at fortran/class.c:86
[Bug fortran/69861] ICE on declaring class parameter array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69861
--- Comment #1 from Gerhard Steinmetz
---
Whereas, with a scalar parameter :
$ cat z2.f90
program p
type t
character :: c
end type
class(t), parameter :: z = t('a')
print *, z%c
end
$ gfortran-6 z2.f90
$ a.out
a
# no error
[Bug fortran/69867] New: ICE on initializing character in type with array of incompatible data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69867 Bug ID: 69867 Summary: ICE on initializing character in type with array of incompatible data Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- An array on lhs with incompatible data : $ cat z1.f90 program p type t character(1) :: c(1) = [1] end type end $ gfortran-6 z1.f90 f951: internal compiler error: Segmentation fault More variants : $ cat z2.f90 program p type t character(1) :: d(1) = [1.] character(1) :: e(1) = [1d1] character(1) :: f(1) = [(0.,1.)] character(1) :: g(1) = [.true.] character(1) :: h(1) = [.false.] character(1) :: n(1) = [null()] end type end rhs needs not to be an array to trigger an ICE : (incompatible ranks 0 and 1 in assignment) $ cat z3.f90 program p type t character(1) :: c = [1] character(1) :: d = [1.] character(1) :: e = [1d1] character(1) :: f = [(0.,1.)] character(1) :: g = [.true.] character(1) :: h = [.false.] character(1) :: n = [null()] end type end
[Bug fortran/69867] ICE on initializing character in type with array of incompatible data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69867 --- Comment #1 from Gerhard Steinmetz --- Detected when lhs is a scalar : $ cat z4.f90 program p type t character(1) :: c(1) = 1 end type end $ gfortran-6 z4.f90 z4.f90:3:28: character(1) :: c(1) = 1 1 Error: Can't convert INTEGER(4) to CHARACTER(1) at (1) And detected outside of a type, e.g. : $ cat z5.f90 program p character(1) :: b = [1] character(1) :: c(1) = [1] end $ gfortran-6 z5.f90 z5.f90:2:20: character(1) :: b = [1] 1 Error: Incompatible ranks 0 and 1 in assignment at (1) z5.f90:3:25: character(1) :: c(1) = [1] 1 Error: Can't convert INTEGER(4) to CHARACTER(1) at (1)
[Bug fortran/69867] ICE on initializing character in type with array of incompatible data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69867 --- Comment #3 from Gerhard Steinmetz --- These issues are thematically related to pr67804 (... more or less).
[Bug fortran/69867] ICE on initializing character in type with array of incompatible data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69867 --- Comment #2 from Gerhard Steinmetz --- One exception from comment 1 : $ cat z7.f90 program p type t character(1) :: b = null() character(1) :: c(1) = null() end type end $ gfortran-6 z7.f90 f951: internal compiler error: Segmentation fault
[Bug fortran/69962] New: ICE on missing parameter attribute, in gfc_set_constant_character_len
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69962 Bug ID: 69962 Summary: ICE on missing parameter attribute, in gfc_set_constant_character_len Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- The following snippet is wrong because n is not declared as parameter : $ cat z1.f90 program p integer :: n = 1 character(3), parameter :: x(2) = ['abc', 'xyz'] character(2), parameter :: y(2) = [x(2)(2:3), x(n)(1:2)] end $ gfortran-6 z1.f90 f951: internal compiler error: in gfc_set_constant_character_len, at fortran/decl.c:1304 --- Correct with parameter attribute : $ cat z2.f90 program p integer, parameter :: n = 1 character(3), parameter :: x(2) = ['abc', 'xyz'] character(2), parameter :: y(2) = [x(2)(2:3), x(n)(1:2)] print *, x print *, y end $ gfortran-6 z2.f90 $ a.out abcxyz yzab --- Thematically related to pr66107.
[Bug fortran/69963] New: ICE out of memory on displaced implicit character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69963 Bug ID: 69963 Summary: ICE out of memory on displaced implicit character Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Something goes wrong when a "implicit character" statement is mixed in at wrong places. There is NO ice, NO out of memory if "implicit none" or "implicit real" etc. is mixed in instead. In most runs "out of memory" hits, but segfault or other error messages are possible too, depending on compile options and additional statements. $ cat z01.f90 program p character(4) c implicit character(8) (a-z) end $ cat z02.f90 program p x = 1 implicit character(8) (a-z) end $ cat z03.f90 module m private implicit character(8) (a-z) end $ gfortran-6 -c z01.f90 f951: out of memory allocating 22352811504 bytes after a total of 634880 bytes $ gfortran-6 -c z02.f90 f951: out of memory allocating 22352811504 bytes after a total of 634880 bytes $ gfortran-6 -c z03.f90 f951: out of memory allocating 22352811504 bytes after a total of 634880 bytes Please find attached a list with several more examples.
[Bug fortran/69963] ICE out of memory on displaced implicit character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69963 --- Comment #1 from Gerhard Steinmetz --- Created attachment 37795 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37795&action=edit More tiny examples
[Bug fortran/69964] New: ICE on misspelled end block data, in gfc_ascii_statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69964 Bug ID: 69964 Summary: ICE on misspelled end block data, in gfc_ascii_statement Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- With a typo : $ cat z1.f90 block data q end blook data q block data q2 end block data q2 $ cat z2.f90 block data q end block q block data q2 end block data q2 $ gfortran-6 z1.f90 f951: internal compiler error: gfc_ascii_statement(): Bad statement code
[Bug fortran/69965] New: ICE: tree check: expected tree that contains ‘typed’ structure, have ‘’ in gfc_get_character_type, at fortran/trans-types.c:1048
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69965 Bug ID: 69965 Summary: ICE: tree check: expected tree that contains ‘typed’ structure, have ‘’ in gfc_get_character_type, at fortran/trans-types.c:1048 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- With an abstract class dummy argument : $ cat z1.f90 module m type, abstract :: tab contains procedure(fab), deferred :: f end type type, extends(tab) :: t contains procedure :: f end type abstract interface function fab(x) result(z) import tab class(tab) :: x character(*) :: z end end interface contains function f(x) class(t) :: x character(1) :: f f = 'a' end subroutine s(x) class(tab) :: x print *, x%f() end end module $ gfortran-6 --version GNU Fortran (SUSE Linux) 6.0.0 20160202 (experimental) [trunk revision 233076] $ gfortran-6 -c z1.f90 z1.f90:30:0: print *, x%f() internal compiler error: Segmentation fault In approximately 3 out of 100 runs the error message is : internal compiler error: tree check: expected tree that contains ‘typed’ structure, have ‘’ in gfc_get_character_type, at fortran/trans-types.c:1048
[Bug fortran/69965] ICE: tree check: expected tree that contains ‘typed’ structure, have ‘’ in gfc_get_character_type, at fortran/trans-types.c:1048
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69965 --- Comment #1 from Gerhard Steinmetz --- Compiles if abstract "class(tab)" is replaced with extended "class(t)" : $ cat z2.f90 module m type, abstract :: tab contains procedure(fab), deferred :: f end type type, extends(tab) :: t contains procedure :: f end type abstract interface function fab(x) result(z) import tab class(tab) :: x character(*) :: z end end interface contains function f(x) class(t) :: x character(1) :: f f = 'a' end subroutine s(x) class(t) :: x print *, x%f() end end module
[Bug fortran/70068] New: ICE: out of memory on involving empty substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70068 Bug ID: 70068 Summary: ICE: out of memory on involving empty substring Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Looks strange, is legal (empty substring, zero length) : $ cat z1.f90 program p character(99), parameter :: x(2) = ' ' character(99), parameter :: y = x(2)(99:1) end $ gfortran-6 z1.f90 f951: out of memory allocating 18446744073709551232 bytes after a total of 634880 bytes $ cat z2.f90 program p character(99), parameter :: x(2) = ' ' character(99) :: y = x(2)(99:1) end $ gfortran-6 z2.f90 f951: out of memory allocating 18446744073709551232 bytes after a total of 626688 bytes Compiles and works : $ cat z3.f90 program p character(99), parameter :: x(2) = 'x' character(99) :: y y = x(2)(99:1) print *, y end Works with a scalar x instead of an array : $ cat z4.f90 program p character(99), parameter :: x = ' ' character(99), parameter :: y = x(99:1) print *, y end
[Bug fortran/70068] ICE: out of memory on involving empty substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70068 --- Comment #1 from Gerhard Steinmetz --- Similar : $ cat z7.f90 program p integer :: i character(3), parameter :: x(3) = ['abc', 'ijk', 'xyz'] character(3), parameter :: y(2) = [(x(i)(i:1), i=2,3)] end $ gfortran-6 z7.f90 *** Error in `/usr/lib64/gcc/x86_64-suse-linux/6/f951': malloc(): memory corruption: 0x03081750 *** $ cat z8.f90 program p integer :: i character(3), parameter :: x(3) = ['abc', 'ijk', 'xyz'] character(3) :: y(2) = [(x(i)(i:1), i=2,3)] end $ gfortran-6 z8.f90 *** Error in `/usr/lib64/gcc/x86_64-suse-linux/6/f951': malloc(): memory corruption: 0x025d6730 *** $ cat z9.f90 program p integer :: i character(3), parameter :: x(3) = ['abc', 'ijk', 'xyz'] character(3) :: y(2) y = [(x(i)(i:1), i=2,3)] end $ gfortran-6 z9.f90 *** Error in `/usr/lib64/gcc/x86_64-suse-linux/6/f951': malloc(): memory corruption: 0x02b57900 *** Compiles and runs : $ cat za.f90 program p integer :: i character(3) :: x(3) character(3) :: y(2) x = ['abc', 'ijk', 'xyz'] y = [(x(i)(i:1), i=2,3)] print *, len_trim(x), x print *, len_trim(y) end $ gfortran-6 za.f90 $ a.out 3 3 3 abcijkxyz 0 0
[Bug fortran/70070] New: ICE on initializing character data beyond min/max bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70070 Bug ID: 70070 Summary: ICE on initializing character data beyond min/max bound Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This code accidentally accesses invalid data : $ cat z1.f90 program p integer :: i character(1) :: c data (c(i:i), i=1,11) /11*'c'/ end $ gfortran-6 z1.f90 *** Error in `/usr/lib64/gcc/x86_64-suse-linux/6/f951': free(): invalid next size (fast): 0x029ac080 *** ... internal compiler error: Aborted $ cat z3.f90 program p integer :: i character(99) :: c data (c(i:i), i=1,999) /999*'c'/ end $ gfortran-6 z3.f90 *** Error in `/usr/lib64/gcc/x86_64-suse-linux/6/f951': free(): invalid next size (normal): 0x02fa2440 *** *** Error in `/usr/lib64/gcc/x86_64-suse-linux/6/f951': corrupted double-linked list: 0x02f226f0 ***
[Bug fortran/70070] ICE on initializing character data beyond min/max bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70070 --- Comment #1 from Gerhard Steinmetz --- Similar : $ cat z5.f90 program p integer :: i character(2) :: c data (c(i:i), i=-1,2) /2*'c'/ end $ gfortran-6 -c z5.f90 Error: DATA statement at (1) has more variables than values *** Error in `/usr/lib64/gcc/x86_64-suse-linux/6/f951': munmap_chunk(): invalid pointer: 0x025a8b20 *** ... internal compiler error: Aborted
[Bug fortran/70071] New: ICE on wrong usage of a subscript triplet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70071 Bug ID: 70071 Summary: ICE on wrong usage of a subscript triplet Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- A wrong usage of a subscript triplet : $ cat z1.f90 program p integer, allocatable :: z(:)[:,:] allocate (z(2)[1::2,*]) end $ gfortran-6 -fcoarray=single z1.f90 f951: internal compiler error: gfc_ref_dimen_size(): Bad dimension $ cat z2.f90 program p integer, allocatable :: z(:)[:,:] allocate (z(2)[1:3:2,*]) end $ gfortran-6 -fcoarray=single z2.f90 f951: internal compiler error: gfc_ref_dimen_size(): Bad dimension
[Bug fortran/70071] ICE on wrong usage of a subscript triplet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70071 --- Comment #1 from Gerhard Steinmetz --- Whereas : $ cat z3.f90 program p integer, allocatable :: z(:)[:,:] allocate (z(1::2)[2,*]) end $ gfortran-6 -fcoarray=single z3.f90 z3.f90:3:13: allocate (z(1::2)[2,*]) 1 Error: Bad array specification in ALLOCATE statement at (1)
[Bug fortran/70072] New: ICE in gfc_find_array_ref(): No ref found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70072 Bug ID: 70072 Summary: ICE in gfc_find_array_ref(): No ref found Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- A short test case : $ cat z1.f90 program p type t integer :: n end type class(t), parameter :: z(2,3) = t(1) print *, size(z, dim=1) print *, lbound(z, dim=1) print *, ubound(z, dim=1) end $ gfortran-6 z1.f90 f951: internal compiler error: gfc_find_array_ref(): No ref found
[Bug fortran/70072] ICE in gfc_find_array_ref(): No ref found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70072 --- Comment #1 from Gerhard Steinmetz --- Whereas with "type" instead of "class" : $ cat z2.f90 program p type t integer :: n end type type(t), parameter :: z(2,3) = t(1) print *, size(z, dim=1) print *, lbound(z, dim=1) print *, ubound(z, dim=1) end $ gfortran-6 z2.f90 $ a.out 2 1 2
[Bug fortran/70260] ICE: gimplification failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70260
--- Comment #1 from Gerhard Steinmetz
---
Another situation :
$ cat z3.f90
subroutine s (f)
integer, external :: f, g
integer :: h
g = f(2)
h = g(2)
end
$ gfortran-6 -c z3.f90
gimplification failed:
g
QI
size
unit size
align 8 symtab 0 alias set -1 canonical type 0x2abc6cc7e738
attributes
value >>
pointer_to_this >
unsigned DI
size
unit size
align 64 symtab 0 alias set -1 canonical type 0x2abc6ce1d1f8>
constant
arg 0
addressable used public external QI file z3.f90 line 2 col 0 align 8
context
chain
public static QI file z3.f90 line 1 col 0 align 8 context
initial
result
(mem:QI (symbol_ref:DI ("s_") [flags 0x3] ) [0 S1 A8]) arguments
struct-function 0x2abc6ce1d498 chain >>
z3.f90:4:0 start: z3.f90:4:0 finish: z3.f90:4:0>
z3.f90:4:0:
g = f(2)
internal compiler error: gimplification failed
Before :
$ gfortran-5 -c z3.f90
z3.f90:4:0:
g = f(2)
^
internal compiler error: in gimplify_expr, at gimplify.c:9063
Working variant :
$ cat z4.f90
subroutine s (f)
integer, external :: f, g
integer :: h
h = f(2)
h = g(2)
end
[Bug fortran/68566] ICE on using unusable array in reshape (double free or corruption)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68566 --- Comment #4 from Gerhard Steinmetz --- Simplified a bit : $ cat z7.f90 program p integer, parameter :: a(:) = 1 integer, parameter :: b(2,2) = reshape([a], [2,2]) end $ gfortran-6 z7.f90 *** Error in `/usr/lib64/gcc/x86_64-suse-linux/6/f951': double free or corruption (fasttop): 0x03a00630 *** ... f951: internal compiler error: Aborted
[Bug fortran/70260] New: ICE: gimplification failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70260 Bug ID: 70260 Summary: ICE: gimplification failed Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- A situation where gimplification fails : $ cat z1.f90 module m interface gkind procedure g end interface contains integer function g() g => 1 end subroutine f(x) character(kind=kind(gkind())) :: x end end $ gfortran-6 -c z1.f90 gimplification failed: &__result_g unit size align 32 symtab 0 alias set -1 canonical type 0x2af0601367e0 precision 32 min max pointer_to_this > unsigned DI size unit size align 64 symtab 0 alias set -1 canonical type 0x2af06014b930> arg 0 addressable used decl_5 SI file z1.f90 line 6 col 0 size unit size align 32 context > z1.f90:7:0 start: z1.f90:7:0 finish: z1.f90:7:0> z1.f90:7:0: g => 1 internal compiler error: gimplification failed Before : $ gfortran-5 -c z1.f90 z1.f90:7:0: g => 1 ^ internal compiler error: in gimplify_expr, at gimplify.c:9063 Working variant : $ cat z2.f90 module m interface gkind procedure g end interface contains integer function g() g = 1 end subroutine f(x) character(kind=kind(gkind())) :: x end end
[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69604 --- Comment #9 from Gerhard Steinmetz --- Update, using fresh new release gfortran-6 --version GNU Fortran (SUSE Linux) 6.1.0 20160427 [gcc-6-branch revision 235475] The error message has changed : $ gfortran-6 -c z1.f90 internal compiler error: in conv_function_val, at fortran/trans-expr.c:3683 $ gfortran-6 -c z2.f90 internal compiler error: in conv_function_val, at fortran/trans-expr.c:3683 $ gfortran-6 -fcoarray=single -c z4.f90 $ gfortran-6 -fcoarray=lib -c z4.f90 # NO error now As noted in comment 2, the error message depends on configuration, still differs for --enable-checking=release and --enable-checking=yes. --- And for the following examples there seems to be no ICEs for many different combinations of compile options. Only one problem remaining with -fcoarray=lib and -finit-real. For example -finit-real=zero : $ gfortran-6 -fcoarray=single -finit-real=zero -c z4.f90 # NO error $ gfortran-6 -fcoarray=lib -finit-real=zero -c z4.f90 internal compiler error: in fold_convert_loc, at fold-const.c:2256 $ gfortran-6 -fcoarray=lib -finit-real=zero -c z5_harald_anlauf.f90 internal compiler error: in fold_convert_loc, at fold-const.c:2256 $ gfortran-6 -fcoarray=lib -finit-real=zero -c z6_harald_anlauf.f90 internal compiler error: in fold_convert_loc, at fold-const.c:2256 $ gfortran-6 -fcoarray=lib -finit-real=zero -c z8_harald_anlauf.f90 internal compiler error: in fold_convert_loc, at fold-const.c:2256 --- Running some examples, with suboptimal results : $ gfortran-6 -fcoarray=single z6_harald_anlauf_print_z.f90 $ a.out ( -4.75674592E-16, 1.53246000E-41) $ gfortran-6 -fcoarray=single z8_harald_anlauf.f90 $ a.out ( 42.000, 0.) 42.000 ( 42.000, 0.) 42.000 ( 1., 0.) 2. ( 1., 0.) 2. ( 1., 0.) ( 1.54857493E-41, -9.79143559E+14) 2. 2. ( 1.54857493E-41, -9.79143559E+14)
[Bug fortran/70853] New: ICE on pointing to null, in gfc_add_block_to_block, at fortran/trans.c:1599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70853 Bug ID: 70853 Summary: ICE on pointing to null, in gfc_add_block_to_block, at fortran/trans.c:1599 Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- With the following codes : $ cat z1.f90 program p real, pointer :: z(:) z(1:2) => null() end $ gfortran-6 -c z1.f90 internal compiler error: in gfc_add_block_to_block, at fortran/trans.c:1599 $ cat z2.f90 program p real, pointer :: z(:) z(2:1) => null() end $ gfortran-6 -c z2.f90 internal compiler error: in gfc_add_block_to_block, at fortran/trans.c:1599 $ gfortran-5.3.1 -c z2.f90 internal compiler error: Segmentation fault
[Bug fortran/70853] ICE on pointing to null, in gfc_add_block_to_block, at fortran/trans.c:1599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70853 --- Comment #1 from Gerhard Steinmetz --- Messages interchanged (v5/v6) with a user defined type : $ cat z3.f90 program p type t end type type(t), pointer :: z(:) z(1:2) => null() end $ gfortran-6 -c z3.f90 internal compiler error: Segmentation fault $ gfortran-5.3.1 -c z3.f90 internal compiler error: in gfc_add_block_to_block, at fortran/trans.c:1630 Another error message with "class" instead of "type" : $ cat z4.f90 program p type t end type class(t), pointer :: z(:) z(1:2) => null() end $ gfortran-6 -c z4.f90 internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:144 $ gfortran-5.3.1 -c z4.f90 internal compiler error: Segmentation fault
[Bug fortran/69659] [6/7 Regression] ICE on using option -frepack-arrays, in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69659 --- Comment #8 from Gerhard Steinmetz --- > Can you confirm that the patch fixes the issue in all cases > and does not raise new issues? Yes, I can confirm this now. FYI, there is a separate/independed issue, see pr70853 comment 1. My best regards.
[Bug fortran/70854] ICE in gfc_process_block_locals, at fortran/trans-decl.c:6447
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70854 --- Comment #1 from Gerhard Steinmetz --- Similar for other intrinsic types : $ cat z3.f90 program p real :: x(2), y(2) block real, parameter :: a(2) = 0.0 x = a block y = 0.0 end block end block end $ gfortran-6 -finit-real=zero -c z3.f90 internal compiler error: in gfc_process_block_locals, at fortran/trans-decl.c:6447 $ gfortran-6 -finit-real=inf -c z3.f90 internal compiler error: in gfc_process_block_locals, at fortran/trans-decl.c:6447 $ gfortran-6 -finit-local-zero -c z3.f90 internal compiler error: in gfc_process_block_locals, at fortran/trans-decl.c:6447 --- $ cat z5.f90 program p logical :: x(2), y(2) block logical, parameter :: a(2) = .true. x = a block y = .false. end block end block end $ gfortran-6 -finit-logical=true -c z5.f90 internal compiler error: in gfc_process_block_locals, at fortran/trans-decl.c:6447 $ gfortran-6 -finit-local-zero -c z5.f90 internal compiler error: in gfc_process_block_locals, at fortran/trans-decl.c:6447 --- $ cat z7.f90 program p character :: x(2), y(2) block character, parameter :: a(2) = 'a' x = a block y = 'y' end block end block end $ gfortran-6 -finit-character=7 -c z7.f90 internal compiler error: in gfc_process_block_locals, at fortran/trans-decl.c:6447 $ gfortran-6 -finit-local-zero -c z7.f90 internal compiler error: in gfc_process_block_locals, at fortran/trans-decl.c:6447
[Bug fortran/70855] New: [6 Regression] ICE with -fopenmp in gfc_trans_omp_workshare(): Bad statement code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70855 Bug ID: 70855 Summary: [6 Regression] ICE with -fopenmp in gfc_trans_omp_workshare(): Bad statement code Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- With GNU Fortran (SUSE Linux) 6.1.0 20160427 and optimization level -Og, -Os, -O1 or higher : $ cat z1.f90 program p integer, parameter :: m = 4 integer, parameter :: n = 2 real :: a(m,n) real :: x(n) real :: y(m) a = 1.0 x = 1.0 !$omp parallel !$omp workshare y(1:m) = matmul ( a(1:m,1:n), x(1:n) ) !$omp end workshare !$omp end parallel end $ gfortran-6 -O2 -fopenmp -c z1.f90 f951: internal compiler error: gfc_trans_omp_workshare(): Bad statement code
[Bug fortran/70854] New: ICE in gfc_process_block_locals, at fortran/trans-decl.c:6447
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70854 Bug ID: 70854 Summary: ICE in gfc_process_block_locals, at fortran/trans-decl.c:6447 Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- The following code with an inner block aborts when combined with an appropriate option -finit-*. Here "integer" and -finit-integer : $ cat z1.f90 program p integer :: x(2), y(2) block integer, parameter :: a(2) = 0 x = a block y = 0 end block end block end $ gfortran-6 -finit-integer=-7 -c z1.f90 internal compiler error: in gfc_process_block_locals, at fortran/trans-decl.c:6447 $ gfortran-6 -finit-local-zero -c z1.f90 internal compiler error: in gfc_process_block_locals, at fortran/trans-decl.c:6447 --- Compiles fine without that inner block : $ cat z2.f90 program p integer :: x(2), y(2) block integer, parameter :: a(2) = 0 x = a y = 0 end block end $ gfortran-6 -finit-integer=-7 -c z2.f90 $ gfortran-6 -finit-local-zero -c z2.f90 # no ICE
[Bug fortran/70856] New: [6 Regression] ICE with -fopenacc in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2952
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70856 Bug ID: 70856 Summary: [6 Regression] ICE with -fopenacc in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2952 Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Compiling the following snippet with optimization level -Os, -O2 or higher : $ cat z1.f90 program p print *, sin([1.0, 2.0]) print *, cos([1.0, 2.0]) end $ gfortran-6 -O2 -fopenacc z1.f90 internal compiler error: in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2952 Affects several files from gfortran testsuite, too. $ make check-fortran RUNTESTFLAGS="--target_board=unix/-fopenacc" ... # of expected passes40537 # of unexpected failures1377 # of expected failures 62 # of unresolved testcases 609
[Bug fortran/70857] New: [6 Regression] ICE with -fopenmp -fopenacc in insert_vi_for_tree, at tree-ssa-structalias.c:2813
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70857 Bug ID: 70857 Summary: [6 Regression] ICE with -fopenmp -fopenacc in insert_vi_for_tree, at tree-ssa-structalias.c:2813 Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- For testcase .../gcc/testsuite/gfortran.dg/gomp/gridify-1.f90 and optimization level -Og, -Os, -O1 or higher : $ gfortran-6 -O2 -fopenmp -fopenacc -c gridify-1.f90 internal compiler error: in insert_vi_for_tree, at tree-ssa-structalias.c:2813
[Bug fortran/60561] ICE in gimplify_var_or_parm_decl, at gimplify.c:1721 for gfortran.dg/associate_1.f03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60561 Gerhard Steinmetz changed: What|Removed |Added CC||gerhard.steinmetz.fortran@t ||-online.de --- Comment #7 from Gerhard Steinmetz --- On my environment, the examples from comment 0 and comment 4 no longer give an ICE now. $ gfortran-6 --version GNU Fortran (SUSE Linux) 6.1.0 20160427 [gcc-6-branch revision 235475]
[Bug fortran/70854] ICE in gfc_process_block_locals, at fortran/trans-decl.c:6447
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70854 --- Comment #2 from Gerhard Steinmetz --- As a side note, above examples are more or less a follow-up of pr67885. --- As tested recently, some more examples from gfortran's testsuite seem to be affected when running for example with -finit-local-zero $ make check-fortran RUNTESTFLAGS="--target_board=unix/-finit-local-zero" ... # of expected passes38678 # of unexpected failures293 # of expected failures 45 # of unresolved testcases 14 # of unsupported tests 407
[Bug fortran/70913] New: ICE in gfc_encode_character, at fortran/target-memory.c:227
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70913 Bug ID: 70913 Summary: ICE in gfc_encode_character, at fortran/target-memory.c:227 Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- When len of string a is larger than len(c) : $ cat z1.f90 program p character(3), parameter :: a = 'abc' type t character :: c end type type t2 character :: q = transfer(t(a), 'b') end type type(t2) :: x print *, x end $ gfortran-6 z1.f90 f951: internal compiler error: in gfc_encode_character, at fortran/target-memory.c:227
[Bug fortran/70913] ICE in gfc_encode_character, at fortran/target-memory.c:227
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70913
--- Comment #1 from Gerhard Steinmetz
---
For completeness, these variants compile without errors :
$ cat z2.f90
program p
type t
character :: c
end type
type t2
character :: q = transfer(t('a'), 'b')
end type
type(t2) :: x
print *, x
end
$ cat z3.f90
program p
type t
character(4) :: c
end type
type t2
character :: q = transfer(t('abc'), 'b')
end type
type(t2) :: x
print *, x
end
[Bug fortran/70914] New: ICE in gimplify_var_or_parm_decl, at gimplify.c:1851 (and endless compilation)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70914 Bug ID: 70914 Summary: ICE in gimplify_var_or_parm_decl, at gimplify.c:1851 (and endless compilation) Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This case is interesting. On my environment with gfortran 6.1.0 20160427 and SUSE Linux 64 bit, this compilation runs forever : $ cat z3.f90 program p character(:), allocatable :: z z = 'z' z = z z = z z = z print *, z end $ gfortran-6 -c z3.f90 # ... $ cat z2.f90 program p character(:), allocatable :: z z = 'z' z = z z = z print *, z end $ time timeout 10.0 gfortran-6 -c z2.f90 real0m10.001s And for the simplest case an ICE : $ cat z1.f90 program p character(:), allocatable :: z z = 'z' z = z print *, z end $ gfortran-6 -c z1.f90 internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1851
[Bug fortran/70870] Segmentation violation in gfc_assign_data_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70870 --- Comment #2 from Gerhard Steinmetz --- A variant that aborts with this message directly : $ gfortran-6 z1.f90 f951: internal compiler error: in gfc_assign_data_value, at fortran/data.c:449 $ cat z1.f90 program p type t integer :: n end type type(t), pointer :: z => null() data z%n / 3 / print *, z%n end --- A minimal change of z1.f90 immediately points to pr50410 : $ cat z2.f90 program p type t integer :: n end type type(t), pointer :: z data z%n / 3 / print *, z%n end $ gfortran-6 z2.f90 f951: internal compiler error: in record_reference, at cgraphbuild.c:64
[Bug fortran/48776] ICE(segfault) after -std=f95 diagnostic error involving PROCEDURE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776 --- Comment #2 from Gerhard Steinmetz --- On my environment, the example from comment 0 compiles now without an ICE. $ gfortran-6 --version GNU Fortran (SUSE Linux) 6.1.1 20160502 [gcc-6-branch revision 235698] $ gfortran-6 -std=f95 pr48776.f90 pr48776.f90:6:18: procedure get1 1 Error: Fortran 2003: PROCEDURE statement at (1) pr48776.f90:9:14: integer :: h 1 Error: Procedure ‘h’ in generic interface 'get' at (1) is neither function nor subroutine pr48776.f90:10:13: call set1 (get (h)) 1 Error: There is no specific function for the generic ‘get’ at (1)
[Bug fortran/67542] ICE on initializing type variable with a longer array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67542 --- Comment #4 from Gerhard Steinmetz --- The ICE from above is gone a while ago. $ gfortran-6 --version GNU Fortran (SUSE Linux) 6.1.1 20160502 [gcc-6-branch revision 235698] $ gfortran-6 -g -O0 -Wall -fcheck=all z1.f90 z1.f90:6:15: type(t) :: x = t(1, ['a']) 1 Warning: Unused variable ‘x’ declared at (1) [-Wunused-variable] z1.f90:7:15: type(t) :: y = t(2, ['a', 'b']) 1 Warning: Unused variable ‘y’ declared at (1) [-Wunused-variable] --- $ cat z3.f90 program p character(1), parameter :: a(4) = ['a','b','c','d'] type t integer :: n character(2) :: c(3) end type type(t) :: x = t(1, a(1:2)) type(t) :: y = t(2, a(1:4)) type(t) :: z = t(3, a) print *, x print *, y print *, z end $ gfortran-6 -g -O0 -Wall -fcheck=all z3.f90 $ a.out 1 a b 2 a b c 3 a b c
[Bug fortran/67542] ICE on initializing type variable with a longer array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67542 --- Comment #5 from Gerhard Steinmetz --- If not covered elsewhere, one problem is remaining. Nondeterministic and depending on used options : $ cat z4.f90 program p character(1), parameter :: a(4) = ['a','b','c','d'] type t integer :: n character(2) :: c(3) end type type(t) :: x = t(4, [a]) print *, x end $ cat z5.f90 program p character(1), parameter :: a(4) = ['a','b','c','d'] type t integer :: n character(2) :: c(3) end type type(t) :: x = t(4, [a(1:4)]) print *, x end $ cat z6.f90 program p integer :: k character(1), parameter :: a(4) = ['a','b','c','d'] type t integer :: n character(2) :: c(3) end type type(t) :: x = t(4, [(a(k),k=1,4)]) print *, x end $ gfortran-6 -O0 -g -Wall -fcheck=all z6.f90 internal compiler error: Segmentation fault $ gfortran-7-20160501 -g z6.f90 internal compiler error: Segmentation fault 0xbf6ebf crash_signal ../../gcc/toplev.c:333 0x72f8c3 gfc_emit_parameter_debug_info ../../gcc/fortran/trans-decl.c:4894 0x6f9d3b do_traverse_symtree ../../gcc/fortran/symbol.c:3817 0x73eb65 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6328 0x6cabc0 translate_all_program_units ../../gcc/fortran/parse.c:5613 0x6cabc0 gfc_parse_file() ../../gcc/fortran/parse.c:5819 0x70ca32 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:201
[Bug fortran/70931] New: ICE with -g in native_encode_initializer, bei dwarf2out.c:17768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70931 Bug ID: 70931 Summary: ICE with -g in native_encode_initializer, bei dwarf2out.c:17768 Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Up to now observed only with compile option -g. Under the hoods possibly related to pr67542. $ cat z1.f90 program p type t integer :: a integer :: b(0) end type type(t), parameter :: z = t(1, [2]) print *, z end $ gfortran-6 -g -c z1.f90 internal compiler error: in native_encode_initializer, at dwarf2out.c:17767 $ gfortran-7-20160501 -g z1.f90 internal compiler error: in native_encode_initializer, at dwarf2out.c:17768 0x881dc0 native_encode_initializer ../../gcc/dwarf2out.c:17768 0x881982 native_encode_initializer ../../gcc/dwarf2out.c:17810 0x88ce15 tree_add_const_value_attribute ../../gcc/dwarf2out.c:17852 0x89aaef gen_const_die ../../gcc/dwarf2out.c:21258 0x89aaef gen_decl_die ../../gcc/dwarf2out.c:23404 0x89b82e dwarf2out_decl ../../gcc/dwarf2out.c:23954 0x8b2fc8 dwarf2out_early_global_decl ../../gcc/dwarf2out.c:23627 0x6f9d3b do_traverse_symtree ../../gcc/fortran/symbol.c:3817 0x73eb65 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6328 0x6cabc0 translate_all_program_units ../../gcc/fortran/parse.c:5613 0x6cabc0 gfc_parse_file() ../../gcc/fortran/parse.c:5819 0x70ca32 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:201
[Bug fortran/70931] ICE with -g in native_encode_initializer, bei dwarf2out.c:17768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70931 --- Comment #1 from Gerhard Steinmetz --- Whereas, these variants compile without problems : $ cat z2.f90 program p type t integer :: b(0) end type type(t), parameter :: z = t([2]) print *, z end $ cat z3.f90 program p type t integer :: a integer :: b(0) end type type(t), parameter :: z = t(1, 2) print *, z end
[Bug fortran/50410] [4.9/5/6/7 Regression] ICE in record_reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 --- Comment #23 from Gerhard Steinmetz --- These variants give : $ cat z1.f90 program p type ta integer :: a end type type t type(ta), pointer :: b end type type(t) :: z data z / t(ta(1)) / end $ gfortran-6 z1.f90 f951: internal compiler error: in record_reference, at cgraphbuild.c:64 $ cat z2.f90 program p type ta integer :: a end type type t type(ta) :: b end type type(t), pointer :: z data z / t(ta(1)) / end $ gfortran-6 z2.f90 f951: internal compiler error: in record_reference, at cgraphbuild.c:64 $ cat z3.f90 program p type ta integer :: a end type type t type(ta), pointer :: b end type type(t), pointer :: z data z / t(ta(1)) / end $ gfortran-6 z3.f90 internal compiler error: in fold_convert_loc, at fold-const.c:2256
[Bug fortran/50410] [4.9/5/6/7 Regression] ICE in record_reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 --- Comment #24 from Gerhard Steinmetz --- And an exotic case : $ cat z5.f90 module m real, target :: a[*] real, pointer :: z => a end $ gfortran-6 -fcoarray=lib -c z5.f90 f951: internal compiler error: in record_reference, at cgraphbuild.c:64 $ cat z6.f90 program p real, target :: a[*] real, pointer :: z => a end $ gfortran-6 -fcoarray=lib -finit-local-zero -c z6.f90 internal compiler error: in fold_convert_loc, at fold-const.c:2256
[Bug fortran/70949] ICE in propagate_necessity, at tree-ssa-dce.c:924
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70949 --- Comment #1 from Gerhard Steinmetz --- This variant works : (as known from several other PRs : change "class" to "type") $ cat z2.f90 program p type t1 end type type t2 type(t1), pointer :: q end type type(t1), pointer :: a type(t2) :: c allocate(a) c%q => a print *, 'a', associated(a, f(c)) contains function f(x) result (z) type(t2), intent(in) :: x type(t1), pointer :: z z => x%q end end
[Bug fortran/70949] New: ICE in propagate_necessity, at tree-ssa-dce.c:924
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70949 Bug ID: 70949 Summary: ICE in propagate_necessity, at tree-ssa-dce.c:924 Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Compiling with optimization level -Og, -Os, -O1 or higher : (affects older gfortran versions too) $ cat z1.f90 program p type t1 end type type t2 type(t1), pointer :: q end type type(t1), pointer :: a type(t2) :: c allocate(a) c%q => a print *, 'a', associated(a, f(c)) contains function f(x) result (z) type(t2), intent(in) :: x class(t1), pointer :: z z => x%q end end $ gfortran-6 -O2 z1.f90 z1.f90:12:0: print *, 'a', associated(a, f(c)) internal compiler error: in propagate_necessity, at tree-ssa-dce.c:924
[Bug fortran/70950] New: ICE with -O0 in simplify_subreg, at simplify-rtx.c:5895
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70950 Bug ID: 70950 Summary: ICE with -O0 in simplify_subreg, at simplify-rtx.c:5895 Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This error message is generated with optimization level -O0 : (affects older gfortran versions too) $ cat z1.f90 program p type t1 end type type t2 type(t1), pointer :: q => null() end type type(t1), pointer :: a, b type(t2) :: c allocate(a) call s(a, c) print *, 'a', associated(a, f(c)) b => f(c) print *, 'b', associated(a, b) contains subroutine s(x, y) type(t1), pointer :: x type(t2), intent(out) :: y y%q => x end function f(x) result (z) type(t2), intent(in) :: x class(t1), pointer :: z z => x%q end end $ gfortran-6 -O0 z1.f90 z1.f90:12:0: print *, 'a', associated(a, f(c)) internal compiler error: in simplify_subreg, at simplify-rtx.c:5895
[Bug fortran/70950] ICE with -O0 in simplify_subreg, at simplify-rtx.c:5895
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70950 --- Comment #1 from Gerhard Steinmetz --- Please note : both examples from pr70949 are simplifications of this PR, thus related. Behaviour differs for -O0 (with/without ICE). Compiling the example from above with optimization level -Og, -Os, -O1 or higher shows the same ICE as in PR70949 comment 0. In total, pr70949 is more or less a subcase. Code compiles and works if "class" is changed to "type" : $ cat z2.f90 program p type t1 end type type t2 type(t1), pointer :: q => null() end type type(t1), pointer :: a, b type(t2) :: c allocate(a) call s(a, c) print *, 'a', associated(a, f(c)) b => f(c) print *, 'b', associated(a, b) contains subroutine s(x, y) type(t1), pointer :: x type(t2), intent(out) :: y y%q => x end function f(x) result (z) type(t2), intent(in) :: x type(t1), pointer :: z z => x%q end end $ gfortran-6 -O0 -g z2.f90 $ a.out a T b T
[Bug fortran/56765] [OOP] compilation errors/ICE with polymorphic array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56765 --- Comment #6 from Gerhard Steinmetz --- On my environment, all tests compile now without an ICE. (also tested with several other compile options) $ gfortran-6 --version GNU Fortran (SUSE Linux) 6.1.1 20160502 [gcc-6-branch revision 235698] $ gfortran-6 -Wall -Wextra pr56765_comment0_t2.f90 $ a.out $ gfortran-6 -Wall -Wextra pr56765_comment0_t3.f90 pr56765_comment0_t3.f90:4:4: u => sub() 1 Error: Different ranks in pointer assignment at (1) $ gfortran-6 -Wall -Wextra pr56765_comment4.f90 $ a.out
[Bug fortran/57197] [Fortran-Dev][Regression] ICE in record_reference, at cgraphbuild.c:66
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57197 --- Comment #2 from Gerhard Steinmetz --- For me, test compiles now without ICE -- same with "use thing" added. $ gfortran-6 --version GNU Fortran (SUSE Linux) 6.1.1 20160502 [gcc-6-branch revision 235698]
[Bug fortran/71066] New: ICE in set_loop_bounds, at fortran/trans-array.c:4680
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71066 Bug ID: 71066 Summary: ICE in set_loop_bounds, at fortran/trans-array.c:4680 Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This first example is partially related to pr50410 : $ cat z1.f90 program p type t real, allocatable :: a(:,:) end type type(t), pointer :: x data x%a / 1.0 / end $ gfortran-6 z1.f90 internal compiler error: in set_loop_bounds, at fortran/trans-array.c:4680 --- Another situation : $ cat z3.f90 program p real :: a(2,2)[*] data a /4*0.0/ end $ gfortran-6 -fcoarray=single z3.f90 $ gfortran-6 -fcoarray=lib z3.f90 internal compiler error: in set_loop_bounds, at fortran/trans-array.c:4680
[Bug fortran/71067] New: ICE on data initialization with insufficient value or wrong boz-constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71067 Bug ID: 71067 Summary: ICE on data initialization with insufficient value or wrong boz-constants Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- With a missing parameter attribute, or value not initialized : $ cat z1.f90 program p integer :: i = 0 integer :: z(2) data z /2*i/ end $ gfortran-6 z1.f90 f951: internal compiler error: free_expr0(): Bad expr type $ cat z2.f90 program p integer :: i, z(2) data z /2*i/ end $ gfortran-6 z2.f90 f951: internal compiler error: free_expr0(): Bad expr type Incidentally observed, with wrong boz-constants : $ cat z4.f90 program p integer :: a(2), b(2), c(2) data a /2*b1'/ data b /2*o1' data c /2*z1 end $ gfortran-6 z4.f90 f951: internal compiler error: free_expr0(): Bad expr type
[Bug fortran/71067] ICE on data initialization with insufficient value or wrong boz-constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71067 --- Comment #1 from Gerhard Steinmetz --- A) correct with parameter : $ cat z3.f90 program p integer, parameter :: i = 0 integer :: z(2) data z /2*i/ print *, z end $ gfortran-6 z3.f90 $ a.out 0 0 B) wrong code detected with scalars : $ cat z5.f90 program p integer :: a, b, c data a /b1'/ data b /o1' data c /z1 end $ gfortran-6 z5.f90 z5.f90:3:13: data a /b1'/ 1 Error: Symbol ‘b1’ must be a PARAMETER in DATA statement at (1) z5.f90:4:13: data b /o1' 1 Error: Symbol ‘o1’ must be a PARAMETER in DATA statement at (1) z5.f90:5:13: data c /z1 1 Error: Symbol ‘z1’ must be a PARAMETER in DATA statement at (1)
[Bug fortran/71068] New: ICE in check_data_variable(): Bad expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71068 Bug ID: 71068 Summary: ICE in check_data_variable(): Bad expression Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- With this wrong code : $ cat z1.f90 program p integer :: a(2)[*] data a(1)[1] /1/ data a(2)[1] /2/ end $ gfortran-6 -fcoarray=lib z1.f90 f951: internal compiler error: check_data_variable(): Bad expression Whereas : $ gfortran-6 -fcoarray=single z1.f90 z1.f90:4:7: data a(2)[1] /2/ 1 Error: DATA element ‘a’ at (1) cannot have a coindex z1.f90:3:7: data a(1)[1] /1/ 1 Error: DATA element ‘a’ at (1) cannot have a coindex
[Bug fortran/66461] [4.9/5/6/7 Regression] ICE on missing end program in fixed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461 --- Comment #11 from Gerhard Steinmetz --- ... some more variations with slightly different "line breaks" : $ cat z6.f program p integer x x = 0 if ( x > &0 ) continue !end $ gfortran-6 z6.f f951: internal compiler error: free_expr0(): Bad expr type $ cat z7.f program p integer x x = 0 if ( x > 0 & ) continue !end $ gfortran-6 z7.f z7.f:4:19: if ( x > 0 1 Error: Syntax error in IF-expression at (1) f951: Error: Unexpected end of file in ‘z7.f’ --- $ cat z8.f program p integer x x = 0 if ( &.true. ) continue !end $ gfortran-6 z8.f f951: internal compiler error: free_expr0(): Bad expr type $ cat z9.f program p integer x x = 0 if ( .true. ) & continue !end $ gfortran-6 z9.f z9.f:4:72: if ( .true. ) 1 Error: Cannot assign to a named constant at (1) f951: Error: Unexpected end of file in ‘z9.f’ --- $ cat za.f program p integer x x = 0 if ( .true. ) x = x + & 1 !end $ gfortran-6 za.f za.f:4:72: if ( .true. ) x = x + 1 Error: Syntax error in expression at (1) f951: Error: Unexpected end of file in ‘za.f’
[Bug fortran/71203] New: ICE in add_init_expr_to_sym, at fortran/decl.c:1512 and :1564
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71203 Bug ID: 71203 Summary: ICE in add_init_expr_to_sym, at fortran/decl.c:1512 and :1564 Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- While exploring "source space" around pr68019 and pr68154, another issue came into focus : $ cat z1.f90 program p character(3), parameter :: a(4) = ' ' character(*), parameter :: x(0) = a(2:1) end $ gfortran-6 z1.f90 f951: internal compiler error: in add_init_expr_to_sym, at fortran/decl.c:1512 $ cat z2.f90 program p character(3), parameter :: a(4) = ' ' character(*), parameter :: x(*) = a(2:1) end $ gfortran-6 z2.f90 f951: internal compiler error: in add_init_expr_to_sym, at fortran/decl.c:1512 $ cat z3.f90 program p character(*), parameter :: a(4) = ' ' character(*), parameter :: x(*) = a(1:2)(3:1) end $ gfortran-6 z3.f90 *** Error in `/usr/lib64/gcc/x86_64-suse-linux/6/f951': malloc(): memory corruption: 0x032ff390 ***
[Bug fortran/71203] ICE in add_init_expr_to_sym, at fortran/decl.c:1512 and :1564
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71203 --- Comment #1 from Gerhard Steinmetz --- $ cat z4.f90 program p integer :: i integer, parameter :: x(2) = 0 integer, parameter :: y(*) = [(x(i:i), i=1,2)] end $ gfortran-6 z4.f90 f951: internal compiler error: in add_init_expr_to_sym, at fortran/decl.c:1564 $ cat z5.f90 program p integer :: i integer, parameter :: x(2,2) = 0 integer, parameter :: y(*) = [(x(i:i,i), i=1,2)] end $ gfortran-6 z5.f90 f951: internal compiler error: in add_init_expr_to_sym, at fortran/decl.c:1564
[Bug fortran/71204] New: ICE with -O0 in expand_expr_real_1, at expr.c:9651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71204 Bug ID: 71204 Summary: ICE with -O0 in expand_expr_real_1, at expr.c:9651 Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Full reduction and simplification from a production code base results in the following reproducer, aborting at -O0 : $ cat z1.f90 module m character(10), allocatable :: z(:) end module subroutine s1 use m z(2) = z(1) end subroutine s2 use m z(2) = z(1) end $ gfortran-6 --version GNU Fortran (SUSE Linux) 6.1.1 20160502 [gcc-6-branch revision 235698] $ gfortran-6 -O2 -c z1.f90 $ gfortran-6 -O1 -c z1.f90 $ gfortran-6 -O0 -c z1.f90 z1.f90:12:0: z(2) = z(1) internal compiler error: in expand_expr_real_1, at expr.c:9651
[Bug fortran/70913] ICE in gfc_encode_character, at fortran/target-memory.c:227
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70913 --- Comment #3 from Gerhard Steinmetz --- Another situation : $ cat z4.f90 program p character(3) :: a(2) = ['abc', 'xyz'] character(3) :: b(1,2) = ' ' equivalence (b, a) end $ gfortran-6 z4.f90 internal compiler error: in gfc_encode_character, at fortran/target-memory.c:227 --- Interestingly, this works without initializer of b : $ cat z5.f90 program p character(3) :: a(2) = ['abc', 'xyz'] character(3) :: b(1,2) equivalence (b, a) print *, b end $ gfortran-6 z5.f90 $ a.out abcxyz Even more, with option -finit-character/-finit-local-zero : $ gfortran-6 -g -O0 -Wall -fcheck=all -finit-character=7 z5.f90 $ a.out abcxyz
[Bug fortran/71203] ICE in add_init_expr_to_sym, at fortran/decl.c:1512 and :1564
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71203 --- Comment #2 from Gerhard Steinmetz --- Forgotten to mention subcases : $ cat z3a.f90 program p character(3), parameter :: a(4) = ' ' character(*), parameter :: x(*) = a(1:2)(3:1) end $ gfortran-6 z3a.f90 *** Error in `/usr/lib64/gcc/x86_64-suse-linux/6/f951': malloc(): memory corruption: 0x02873390 *** $ cat z3b.f90 program p character(3), parameter :: a(4) = ' ' character(*), parameter :: x(*) = a(2:2)(3:0) end $ gfortran-6 z3b.f90 f951: out of memory allocating 18446744073709551612 bytes after a total of 634880 bytes
[Bug fortran/78479] New: ICE in gfc_apply_init, at fortran/expr.c:4135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78479 Bug ID: 78479 Summary: ICE in gfc_apply_init, at fortran/expr.c:4135 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- With valid code down to at least 4.8 : $ cat z1.f90 program p type t character(3) :: c(1) = 'a' // ['b'] end type end $ cat z2.f90 program p type t character(1) :: c(1) = 'a' // ['b'] end type end $ gfortran-7-20161120 z1.f90 f951: internal compiler error: Segmentation fault 0xc4265f crash_signal ../../gcc/toplev.c:333 0x68f1b2 gfc_apply_init(gfc_typespec*, symbol_attribute*, gfc_expr*) ../../gcc/fortran/expr.c:4135 0x6828bf build_struct ../../gcc/fortran/decl.c:1943 0x6828bf variable_decl ../../gcc/fortran/decl.c:2443 0x6828bf gfc_match_data_decl() ../../gcc/fortran/decl.c:4898 0x6daa89 match_word_omp_simd ../../gcc/fortran/parse.c:93 0x6de03e match_word ../../gcc/fortran/parse.c:377 0x6de03e decode_statement ../../gcc/fortran/parse.c:377 0x6dfe44 next_free ../../gcc/fortran/parse.c:1180 0x6dfe44 next_statement ../../gcc/fortran/parse.c:1413 0x6e138a parse_derived ../../gcc/fortran/parse.c:3233 0x6e138a parse_spec ../../gcc/fortran/parse.c:3773 0x6e3bc3 parse_progunit ../../gcc/fortran/parse.c:5615 0x6e51b4 gfc_parse_file() ../../gcc/fortran/parse.c:6124 0x729052 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:202
[Bug fortran/78479] ICE in gfc_apply_init, at fortran/expr.c:4135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78479 --- Comment #1 from Gerhard Steinmetz --- Whereas, these variants are ok : $ cat z3.f90 program p type t character(2) :: c(1) = 'a' // ['b'] end type type(t) :: z print *, len(z%c), size(z%c), z end $ gfortran-7-20161120 z3.f90 $ a.out 2 1 ab $ cat z4.f90 program p type t character(3) :: c(1) end type type(t) :: z z%c = 'a' // ['b'] print *, len(z%c), size(z%c), z end $ gfortran-7-20161120 z4.f90 $ a.out 3 1 ab
[Bug fortran/78499] New: ICE in gfc_typename, at fortran/misc.c:158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78499 Bug ID: 78499 Summary: ICE in gfc_typename, at fortran/misc.c:158 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- With invalid code down to at least 4.8 : (configured with --enable-checking=yes) $ cat z1.f90 program p type t end type class(t) :: x = 0 end $ gfortran-7-20161120 z1.f90 z1.f90:4:16: class(t) :: x = 0 1 Error: CLASS variable 'x' at (1) must be dummy, allocatable or pointer f951: internal compiler error: Segmentation fault 0xc4265f crash_signal ../../gcc/toplev.c:333 0x6c239b gfc_typename(gfc_typespec*) ../../gcc/fortran/misc.c:158 0x6aa429 gfc_convert_type_warn(gfc_expr*, gfc_typespec*, int, int) ../../gcc/fortran/intrinsic.c:5020 0x695b49 gfc_check_assign_symbol(gfc_symbol*, gfc_component*, gfc_expr*) ../../gcc/fortran/expr.c:3878 0x71612b do_traverse_symtree ../../gcc/fortran/symbol.c:3994 0x6ff279 resolve_types ../../gcc/fortran/resolve.c:15963 0x6fac7c gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:16058 0x6e520a resolve_all_program_units ../../gcc/fortran/parse.c:5977 0x6e520a gfc_parse_file() ../../gcc/fortran/parse.c:6224 0x729052 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:202
[Bug fortran/78499] ICE in gfc_typename, at fortran/misc.c:158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78499 --- Comment #1 from Gerhard Steinmetz --- Whereas : $ cat z2.f90 program p type t end type type(t) :: x = 0 end $ gfortran-7-20161120 z2.f90 z2.f90:4:17: type(t) :: x = 0 1 Error: Can't convert INTEGER(4) to TYPE(t) at (1)
[Bug fortran/78500] New: ICE in gfc_check_vardef_context, at fortran/expr.c:5289
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78500 Bug ID: 78500 Summary: ICE in gfc_check_vardef_context, at fortran/expr.c:5289 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- With invalid code down to at least 4.8 : (configured with --enable-checking=yes) $ cat z1.f90 class(t) function f() f = 1 end $ gfortran-7-20161120 -c z1.f90 z1.f90:1:0: class(t) function f() Error: CLASS variable 'f' at (1) must be dummy, allocatable or pointer f951: internal compiler error: Segmentation fault 0xc4265f crash_signal ../../gcc/toplev.c:333 0x69642c gfc_check_vardef_context(gfc_expr*, bool, bool, bool, char const*) ../../gcc/fortran/expr.c:5289 0x6f81e6 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:10915 0x6fab92 resolve_codes ../../gcc/fortran/resolve.c:16025 0x6fac8e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:16060 0x6e520a resolve_all_program_units ../../gcc/fortran/parse.c:5977 0x6e520a gfc_parse_file() ../../gcc/fortran/parse.c:6224 0x729052 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:202
[Bug fortran/78500] ICE in gfc_check_vardef_context, at fortran/expr.c:5289
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78500 --- Comment #1 from Gerhard Steinmetz --- Whereas : $ cat z2.f90 type(t) function f() f = 1 end $ gfortran-7-20161120 -c z2.f90 z2.f90:1:0: type(t) function f() Error: The type for function 'f' at (1) is not accessible z2.f90:2:3: f = 1 1 Error: Type inaccessible in variable definition context (assignment) at (1)
[Bug fortran/70070] ICE on initializing character data beyond min/max bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70070 --- Comment #4 from Gerhard Steinmetz --- At a first glance with gfortran-6 (configured with --enable-checking=yes), still ICEs for all posted and unposted cases. A dedicated one : $ gfortran-6 z3.f90 f951: internal compiler error: Segmentation fault 0xbb372f crash_signal ../../gcc/toplev.c:333 0x61cf32 create_character_initializer ../../gcc/fortran/data.c:191 0x61cf32 gfc_assign_data_value(gfc_expr*, gfc_expr*, __mpz_struct*, __mpz_struct (*) [1]) ../../gcc/fortran/data.c:488 0x693442 check_data_variable ../../gcc/fortran/resolve.c:14714 0x693442 traverse_data_var ../../gcc/fortran/resolve.c:14843 0x6937ad traverse_data_list ../../gcc/fortran/resolve.c:14799 0x6937ad traverse_data_var ../../gcc/fortran/resolve.c:14841 0x69dc71 resolve_data ../../gcc/fortran/resolve.c:14898 0x69dc71 resolve_types ../../gcc/fortran/resolve.c:15651 0x69947c gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:15737 0x6848da resolve_all_program_units ../../gcc/fortran/parse.c:5849 0x6848da gfc_parse_file() ../../gcc/fortran/parse.c:6101 0x6c7212 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:201 Please let me have a closer look next week.
[Bug fortran/70070] ICE on initializing character data beyond min/max bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70070 --- Comment #5 from Gerhard Steinmetz --- FYI, for some circumstances there existed related issues like : using LANG=de_DE.UTF-8 f951: internal compiler error: Speicherzugriffsfehler 0xc4265f crash_signal ../../gcc/toplev.c:333 0x13f4b86 diagnostic_action_after_output(diagnostic_context*, diagnostic_t) ../../gcc/diagnostic.c:509 0x13f542a diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) ../../gcc/diagnostic.c:956 0x68dbff gfc_internal_error(char const*, ...) ../../gcc/fortran/error.c:1327 0x6f1d93 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:6549 ...
[Bug fortran/70070] ICE on initializing character data beyond min/max bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70070 Gerhard Steinmetz changed: What|Removed |Added Version|6.0 |7.0 --- Comment #6 from Gerhard Steinmetz --- gfortran-7-20161127 (configured with --enable-checking=yes) also ICEs for all posted and unposted tests, with different messages. Special backtrace from comment 4 is not reproducible with 7. Apart from that, there is another variant, using LANG=de_DE.UTF-8 : $ cat z2.f90 program p integer :: i character(10) :: c data (c(i:i), i=1,100) /100*'c'/ end $ gfortran-7-20161127 z2.f90 f951: internal compiler error: Speicherzugriffsfehler 0xc4532f crash_signal ../../gcc/toplev.c:333 0x67803e formalize_init_expr ../../gcc/fortran/data.c:642 0x716fbb do_traverse_symtree ../../gcc/fortran/symbol.c:3994 0x7001c3 resolve_types ../../gcc/fortran/resolve.c:15973 0x6fbb0c gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:16058 0x6e609a resolve_all_program_units ../../gcc/fortran/parse.c:5977 0x6e609a gfc_parse_file() ../../gcc/fortran/parse.c:6224 0x729ee2 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:202 With LANG=C : $ gfortran-7-20161127 z2.f90 *** Error in `/home/gst/gcc/gcc-7-20161127-oyd/lib/gcc/x86_64-pc-linux-gnu/7.0.0/f951': corrupted double-linked list: 0x03e0f690 *** # hangs
[Bug fortran/78570] New: ICE in free_expr0, at fortran/expr.c:494
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78570 Bug ID: 78570 Summary: ICE in free_expr0, at fortran/expr.c:494 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Follow-up of pr78479 : $ cat z1.f90 program p type t character(3) :: c(2) = 'a' // ['b', 'c'] end type type(t) :: z print *, size(z%c), len(z%c), z end $ cat z2.f90 program p type t character(2) :: c(2) = '' // ['a'] end type type(t) :: z print *, size(z%c), len(z%c), z end $ gfortran-7-20161127 z1.f90 f951: internal compiler error: free_expr0(): Bad expr type 0x68ea6f gfc_internal_error(char const*, ...) ../../gcc/fortran/error.c:1327 0x68f7cb free_expr0 ../../gcc/fortran/expr.c:494 0x68f81d gfc_free_expr(gfc_expr*) ../../gcc/fortran/expr.c:513 0x71b273 gfc_free_charlen(gfc_charlen*, gfc_charlen*) ../../gcc/fortran/symbol.c:3840 0x71b349 gfc_free_namespace(gfc_namespace*) ../../gcc/fortran/symbol.c:3890 0x71b89c gfc_symbol_done_2() ../../gcc/fortran/symbol.c:3926 0x6c33d8 gfc_done_2() ../../gcc/fortran/misc.c:264 0x6e61f6 translate_all_program_units ../../gcc/fortran/parse.c:6057 0x6e61f6 gfc_parse_file() ../../gcc/fortran/parse.c:6238 0x729ee2 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:202
[Bug fortran/78571] New: ICE in create_character_initializer, at fortran/data.c:191
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78571
Bug ID: 78571
Summary: ICE in create_character_initializer, at
fortran/data.c:191
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: gerhard.steinmetz.fort...@t-online.de
Target Milestone: ---
With invalid code, down to at least 4.8 (with --enable-checking=yes).
A different facet; ICE does not depend on compile options, nor on locale.
Potentially related to pr70070.
$ cat z1.f90
program p
type t
character :: c
end type
character :: x = t('a')
data x /'b'/
end
$ gfortran-7-20161127 z1.f90
z1.f90:5:19:
character :: x = t('a')
1
Error: Can't convert TYPE(t) to CHARACTER(1) at (1)
f951: internal compiler error: Segmentation fault
0xc4532f crash_signal
../../gcc/toplev.c:333
0x678c32 create_character_initializer
../../gcc/fortran/data.c:191
0x678c32 gfc_assign_data_value(gfc_expr*, gfc_expr*, __mpz_struct*,
__mpz_struct (*) [1])
../../gcc/fortran/data.c:488
0x6f5779 check_data_variable
../../gcc/fortran/resolve.c:15032
0x6f5779 traverse_data_var
../../gcc/fortran/resolve.c:15161
0x700181 resolve_data
../../gcc/fortran/resolve.c:15216
0x700181 resolve_types
../../gcc/fortran/resolve.c:15970
0x6fbb0c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16058
0x6e609a resolve_all_program_units
../../gcc/fortran/parse.c:5977
0x6e609a gfc_parse_file()
../../gcc/fortran/parse.c:6224
0x729ee2 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:202
[Bug fortran/78573] New: ICE in resolve_component, at fortran/resolve.c:13405
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78573 Bug ID: 78573 Summary: ICE in resolve_component, at fortran/resolve.c:13405 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Appeared between 20161023 (no ICE) and 20161030, with invalid code : $ cat z1.f90 program p type t1 class(t2), pointer :: q(2) end type end $ gfortran-7-20161127 z1.f90 z1.f90:3:32: class(t2), pointer :: q(2) 1 Error: Pointer array component of structure at (1) must have a deferred shape z1.f90:3:32: class(t2), pointer :: q(2) 1 Error: The pointer component 'q' of 't1' at (1) is a type that has not been declared z1.f90:1:9: program p 1 Error: Argument 'src' of '_copy' with PASS(src) at (1) must be of the derived type '__class_p_T2_1_0p' z1.f90:1:9: program p 1 Error: Argument 'array' of '_final' with PASS(array) at (1) must be of the derived type '__class_p_T2_1_0p' f951: internal compiler error: Segmentation fault 0xc4532f crash_signal ../../gcc/toplev.c:333 0x7019ca resolve_component ../../gcc/fortran/resolve.c:13405 0x701c6a resolve_fl_derived0 ../../gcc/fortran/resolve.c:13735 0x702037 resolve_fl_derived0 ../../gcc/fortran/resolve.c:13119 0x702037 resolve_fl_derived ../../gcc/fortran/resolve.c:13812 0x6fce07 resolve_symbol ../../gcc/fortran/resolve.c:14143 0x716fbb do_traverse_symtree ../../gcc/fortran/symbol.c:3994 0x6fffba resolve_types ../../gcc/fortran/resolve.c:15945 0x6fbb0c gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:16058 0x6e609a resolve_all_program_units ../../gcc/fortran/parse.c:5977 0x6e609a gfc_parse_file() ../../gcc/fortran/parse.c:6224 0x729ee2 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:202
[Bug fortran/78592] New: ICE in gfc_find_specific_dtio_proc, at fortran/interface.c:4939
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78592 Bug ID: 78592 Summary: ICE in gfc_find_specific_dtio_proc, at fortran/interface.c:4939 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Affects version 7 (configured with --enable-checking=yes) since about 20160904 : $ cat z1.f90 program p type t end type type(t) :: z interface write(formatted) module procedure wf end interface print *, z end $ gfortran-7-20161127 z1.f90 z1.f90:6:23: module procedure wf 1 Error: Procedure 'wf' in generic interface '_dtio_formatted_write' at (1) is neither function nor subroutine f951: internal compiler error: Segmentation fault 0xc4532f crash_signal ../../gcc/toplev.c:333 0x69ff6d gfc_find_specific_dtio_proc(gfc_symbol*, bool, bool) ../../gcc/fortran/interface.c:4939 0x6fa32b resolve_transfer ../../gcc/fortran/resolve.c:8973 0x6fa32b gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11138 0x6f8c07 gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:9865 0x6f903b gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:10808 0x6fba22 resolve_codes ../../gcc/fortran/resolve.c:16025 0x6fbb1e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:16060 0x6e609a resolve_all_program_units ../../gcc/fortran/parse.c:5977 0x6e609a gfc_parse_file() ../../gcc/fortran/parse.c:6224 0x729ee2 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:202
[Bug fortran/58904] ICE: accessing a component field of an unavailable type results in a seg fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58904 Gerhard Steinmetz changed: What|Removed |Added CC||gerhard.steinmetz.fortran@t ||-online.de --- Comment #2 from Gerhard Steinmetz --- Update, gives an ICE from 7 down to at least 4.8 : $ gfortran-7-20161127 -c pr58904.f90 f951: internal compiler error: Segmentation fault 0xc4532f crash_signal ../../gcc/toplev.c:333 0x6e97dc gfc_match_varspec(gfc_expr*, int, bool, bool) ../../gcc/fortran/primary.c:2053 0x6e9f04 match_variable ../../gcc/fortran/primary.c:3659 0x6bb401 gfc_match(char const*, ...) ../../gcc/fortran/match.c:1174 0x6bcb9c gfc_match_assignment() ../../gcc/fortran/match.c:1351 0x6db919 match_word_omp_simd ../../gcc/fortran/parse.c:93 0x6deccb match_word ../../gcc/fortran/parse.c:357 0x6deccb decode_statement ../../gcc/fortran/parse.c:362 0x6e0cd4 next_free ../../gcc/fortran/parse.c:1180 0x6e0cd4 next_statement ../../gcc/fortran/parse.c:1413 0x6e23e8 parse_spec ../../gcc/fortran/parse.c:3828 0x6e4a53 parse_progunit ../../gcc/fortran/parse.c:5615 0x6e4ee0 parse_contained ../../gcc/fortran/parse.c:5518 0x6e5bd9 parse_module ../../gcc/fortran/parse.c:5857 0x6e65a9 gfc_parse_file() ../../gcc/fortran/parse.c:6160 0x729ee2 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:202
[Bug fortran/78593] New: ICE in gfc_match_varspec, at fortran/primary.c:2053
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78593 Bug ID: 78593 Summary: ICE in gfc_match_varspec, at fortran/primary.c:2053 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Invalid code with a hidden type declaration. Affects version 6 and 7 (configured with --enable-checking=yes) (bailed out if configured with --enable-checking=release). No ICE (or bailing out) seen with version 5 and older. $ cat z1.f90 module m1 private type t integer :: a end type end module m2 use m1 interface operator(+) module procedure add end interface contains type(t) function add (x, y) type(t), intent(in) :: x, y add%a = x%a + y%a end end $ gfortran-7-20161127 -c z1.f90 z1.f90:15:13: type(t), intent(in) :: x, y 1 Error: Derived type 't' at (1) is being used before it is defined f951: internal compiler error: Segmentation fault 0xc4532f crash_signal ../../gcc/toplev.c:333 0x6e97dc gfc_match_varspec(gfc_expr*, int, bool, bool) ../../gcc/fortran/primary.c:2053 0x6eb136 gfc_match_rvalue(gfc_expr**) ../../gcc/fortran/primary.c:3335 0x6c237e match_primary ../../gcc/fortran/matchexp.c:157 0x6c237e match_level_1 ../../gcc/fortran/matchexp.c:211 0x6c237e match_mult_operand ../../gcc/fortran/matchexp.c:267 0x6c25c8 match_add_operand ../../gcc/fortran/matchexp.c:356 0x6c285c match_level_2 ../../gcc/fortran/matchexp.c:480 0x6c29b2 match_level_3 ../../gcc/fortran/matchexp.c:551 0x6c2ac4 match_level_4 ../../gcc/fortran/matchexp.c:599 0x6c2ac4 match_and_operand ../../gcc/fortran/matchexp.c:693 0x6c2c82 match_or_operand ../../gcc/fortran/matchexp.c:722 0x6c2d72 match_equiv_operand ../../gcc/fortran/matchexp.c:765 0x6c2e62 match_level_5 ../../gcc/fortran/matchexp.c:811 0x6c21d1 gfc_match_expr(gfc_expr**) ../../gcc/fortran/matchexp.c:870 0x6bb534 gfc_match(char const*, ...) ../../gcc/fortran/match.c:1162 0x6c11f0 gfc_match_ptr_fcn_assign() ../../gcc/fortran/match.c:5504 0x6db919 match_word_omp_simd ../../gcc/fortran/parse.c:93 0x6deeae match_word ../../gcc/fortran/parse.c:365 0x6deeae decode_statement ../../gcc/fortran/parse.c:374
[Bug fortran/78593] ICE in gfc_match_varspec, at fortran/primary.c:2053
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78593 --- Comment #1 from Gerhard Steinmetz --- Works with a public type declaration : $ cat z2.f90 module m1 public type t integer :: a end type end module m2 use m1 interface operator(+) module procedure add end interface contains type(t) function add (x, y) type(t), intent(in) :: x, y add%a = x%a + y%a end end
