[Bug fortran/45081] New: ICE in gfc_conv_array_initializer, at fortran/trans-array.c:4208
The following code, with default options, module m implicit none type t integer :: i end type t type(t), dimension(1), parameter :: a1 = (/ t(1) /) type(t), dimension(1), parameter :: a = reshape ( (/ a1 /), (/ 1 /) ) end module m triggers: f951: internal compiler error: in gfc_conv_array_initializer, at fortran/trans-array.c:4208 in GNU Fortran (GCC) 4.6.0 20100726 (experimental) The code compiles with the NAG compiler, as it should. gfortran also compiles the equivalent code for INTEGERS instead of the derived type. Maybe there is a relation to bug #44742. -- Summary: ICE in gfc_conv_array_initializer, at fortran/trans- array.c:4208 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ohl at physik dot uni-wuerzburg dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45081
[Bug fortran/44742] ICE in gfc_conv_array_initializer
--- Comment #12 from ohl at physik dot uni-wuerzburg dot de 2010-07-06 07:38 --- (In reply to comment #10) It is not particularly efficient to use a huge static variable. [...] initialization at run time is the better choice for large arrays. The best solution for PARAMETER depends on the purpose. In the real-life application, the non-trivial PARAMETER values are computed by an external code generator to match the code and its impossible to compute them in Fortran at runtime. It would be possible to read the values from a separate file generated together with the code, but it's tedious and introduces another failure mode. However, I cannot see that this would be more efficient than loading the equivalent data sections. Furthermore, declaring the data as PARAMETER helps the optimizer and OpenMP, doesn't it? -- ohl at physik dot uni-wuerzburg dot de changed: What|Removed |Added CC||ohl at physik dot uni- ||wuerzburg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44742
[Bug fortran/43591] PPC: internal compiler error: in gfc_traverse_expr, at fortran/expr.c:3604
--- Comment #6 from ohl at physik dot uni-wuerzburg dot de 2010-04-01 11:47 --- (In reply to comment #5) Well, using type omega_procedures procedure(number_particles_out), nopass, pointer :: number_particles_out = NULL() end type omega_procedures is definitely wrong: You tell that the procedure pointer has the interface of itself. But that's not the problem: module m implicit none type t procedure(p1_type), nopass, pointer :: p1 = NULL() procedure(p2_type), nopass, pointer :: p2 = NULL() end type t contains subroutine proc (t1, t2) type(t), intent(in) :: t1, t2 integer, dimension(t1%p1(), t2%p2()) :: table end subroutine proc end module m produces the same error. What is invaild about the code is that t1%p1() and t2%p2() are not initialization expressions. Everthing works fine, when the tables are allocatable. BTW: gfortran produces correct code for the variant when the procedures are not procedure pointers. I stumpled over this OCE when rewriting some code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43591
[Bug fortran/43591] PPC: internal compiler error: in gfc_traverse_expr, at fortran/expr.c:3604
--- Comment #10 from ohl at physik dot uni-wuerzburg dot de 2010-04-01 12:45 --- (In reply to comment #8) That's not valid either as you have not defined p1_type - replacing it by INTEGER should work, though. -- Well, it actually does not as specification expressions need to be PURE. Doesn't help module m implicit none type t procedure(p1_type), nopass, pointer :: p1 = NULL() procedure(p2_type), nopass, pointer :: p2 = NULL() end type t abstract interface pure function p1_type () result (n) integer :: n end function p1_type pure function p2_type () result (n) integer :: n end function p2_type end interface contains subroutine proc (t1, t2) type(t), intent(in) :: t1, t2 integer, dimension(t1%p1(), t2%p2()) :: table end subroutine proc end module m (The abstract interface is in the original bug report, but was removed in Dominiques's reduction). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43591
[Bug fortran/43591] New: internal compiler error: in gfc_traverse_expr, at fortran/expr.c:3604
When compiling the attached sources, I get Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/archive/ohl/tools64/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/ohl/archive/gcc/svn/configure --prefix=/archive/ohl/tools64/ --enable-languages=c,c++,fortran Thread model: posix gcc version 4.5.0 20100330 (experimental) (GCC) ward.f90:79:0: internal compiler error: in gfc_traverse_expr, at fortran/expr.c:3604 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: internal compiler error: in gfc_traverse_expr, at fortran/expr.c:3604 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ohl at physik dot uni-wuerzburg dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43591
[Bug fortran/43591] internal compiler error: in gfc_traverse_expr, at fortran/expr.c:3604
--- Comment #1 from ohl at physik dot uni-wuerzburg dot de 2010-03-30 17:21 --- Created an attachment (id=20261) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20261action=view) program that triggers the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43591
