[Bug fortran/59941] [4.7 Regression] [OOP] ICE with polymorphic types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59941 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.4
[Bug fortran/59941] [4.7 Regression] [OOP] ICE with polymorphic types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59941 --- Comment #14 from janus at gcc dot gnu.org --- Author: janus Date: Mon Feb 3 08:16:06 2014 New Revision: 207417 URL: http://gcc.gnu.org/viewcvs?rev=207417root=gccview=rev Log: 2014-02-03 Janus Weil ja...@gcc.gnu.org PR fortran/59941 * expr.c (replace_comp): Check for isym to avoid ICE. 2014-02-03 Janus Weil ja...@gcc.gnu.org PR fortran/59941 * gfortran.dg/typebound_proc_26.f90: New. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/typebound_proc_26.f90 Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/expr.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug fortran/59941] [4.7 Regression] [OOP] ICE with polymorphic types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59941 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from janus at gcc dot gnu.org --- Fixed on the 4.7 branch with r207417 (for a future release 4.7.4). Closing. Thanks for the report!
[Bug fortran/59941] [4.7 Regression] [OOP] ICE with polymorphic types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59941 --- Comment #10 from janus at gcc dot gnu.org --- (In reply to janus from comment #8) Backtrace from gdb: Program received signal SIGSEGV, Segmentation fault. 0x004d19d6 in replace_comp (expr=expr@entry=0x146cc10, sym=sym@entry=0x146f7a0, i=i@entry=0x7fffdc6c) at /home/jweil/gcc47/branch/gcc/fortran/expr.c:4199 4199 !gfc_is_intrinsic (expr-symtree-n.sym, 0, expr-where))) (gdb) bt #0 0x004d19d6 in replace_comp (expr=expr@entry=0x146cc10, sym=sym@entry=0x146f7a0, i=i@entry=0x7fffdc6c) at /home/jweil/gcc47/branch/gcc/fortran/expr.c:4199 Here in replace_comp, the sym is 'get_smatrix', and the problem is that expr-symtree is NULL. #1 0x004d46ba in gfc_traverse_expr (expr=0x146cc10, sym=sym@entry=0x146f7a0, func=func@entry=0x4d19a0 replace_comp, f=f@entry=0) at /home/jweil/gcc47/branch/gcc/fortran/expr.c:3929 #2 0x004d6c9c in gfc_expr_replace_comp (expr=optimized out, dest=dest@entry=0x146f7a0) at /home/jweil/gcc47/branch/gcc/fortran/expr.c:4218 #3 0x00524615 in resolve_fl_derived0 (sym=sym@entry=0x146e590) at /home/jweil/gcc47/branch/gcc/fortran/resolve.c:11724 #4 0x0052c80d in resolve_fl_derived (sym=sym@entry=0x146e590) at /home/jweil/gcc47/branch/gcc/fortran/resolve.c:12046 In here the sym is '__vtype_beam_structures_Beam_structure_t' (the vtabs and vtypes are always imported when loading a module).
[Bug fortran/59941] [4.7 Regression] [OOP] ICE with polymorphic types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59941 --- Comment #11 from janus at gcc dot gnu.org --- The reason why the ICE is gone in 4.8 is that 'replace_comp' was completely removed in r195562 (for PR 54107). However this commit is a bit too heavy for a backport, I guess.
[Bug fortran/59941] [4.7 Regression] [OOP] ICE with polymorphic types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59941
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
--- Comment #12 from janus at gcc dot gnu.org ---
Here is a more lightweight fix (pretty much straightforward):
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c(revision 207198)
+++ gcc/fortran/expr.c(working copy)
@@ -4195,7 +4195,7 @@ replace_comp (gfc_expr *expr, gfc_symbol *sym, int
gfc_component *comp;
comp = (gfc_component *)sym;
if ((expr-expr_type == EXPR_VARIABLE
- || (expr-expr_type == EXPR_FUNCTION
+ || (expr-expr_type == EXPR_FUNCTION !expr-value.function.isym
!gfc_is_intrinsic (expr-symtree-n.sym, 0, expr-where)))
expr-symtree-n.sym-ns == comp-ts.interface-formal_ns)
{
Removes the ICE on comment 0, comment 5 and comment 7.
[Bug fortran/59941] [4.7 Regression] [OOP] ICE with polymorphic types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59941 --- Comment #13 from janus at gcc dot gnu.org --- (In reply to janus from comment #12) Here is a more lightweight fix (pretty much straightforward): ... and regtesting cleanly.
[Bug fortran/59941] [4.7 Regression] [OOP] ICE with polymorphic types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59941 --- Comment #9 from janus at gcc dot gnu.org --- (In reply to janus from comment #6) Somewhat reminds me of PR 58007. Unfortunately r207119 does not seem to fix it on the 4.7 branch. Apparently it's a different problem after all ...
[Bug fortran/59941] [4.7 Regression] [OOP] ICE with polymorphic types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59941 janus at gcc dot gnu.org changed: What|Removed |Added Summary|[OOP] ICE with polymorphic |[4.7 Regression] [OOP] ICE |types in 4.7.x |with polymorphic types --- Comment #4 from janus at gcc dot gnu.org --- The current bug list shows three 4.7-only regressions, two of which are OOP-related: * PR 53718 * PR 56731 At first sight the problem here seems to be different, though.
[Bug fortran/59941] [4.7 Regression] [OOP] ICE with polymorphic types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59941 --- Comment #5 from janus at gcc dot gnu.org --- Reduced test case: module tao_random_numbers integer, dimension(10), private :: s_buffer integer, private :: s_buffer_end = size (s_buffer) end module module beam_structures type :: smatrix_t end type type :: beam_structure_t type(smatrix_t), dimension(:), allocatable :: smatrix contains procedure :: get_smatrix end type contains function get_smatrix (beam_structure) result (smatrix) class(beam_structure_t), intent(in) :: beam_structure type(smatrix_t), dimension (size (beam_structure%smatrix)) :: smatrix end function end module module sf_circe1 use tao_random_numbers use beam_structures end module
[Bug fortran/59941] [4.7 Regression] [OOP] ICE with polymorphic types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59941 janus at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #6 from janus at gcc dot gnu.org --- Definitely some kind of module madness is at work here. Somewhat reminds me of PR 58007.
[Bug fortran/59941] [4.7 Regression] [OOP] ICE with polymorphic types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59941 --- Comment #7 from janus at gcc dot gnu.org --- Another variant with the same behavior (ICEs only with 4.7): module tao_random_numbers integer, dimension(10), private :: s_buffer integer, private :: s_buffer_end = size (s_buffer) end module module beam_structures private type :: beam_structure_t integer, dimension(:), allocatable :: smatrix contains procedure :: get_smatrix end type contains function get_smatrix (beam_structure) result (matrix) class(beam_structure_t), intent(in) :: beam_structure integer, dimension (size (beam_structure%smatrix)) :: matrix end function end module program p use tao_random_numbers use beam_structures end Everything in the modules is private, so the USE statements should not have any effect in principle. Btw, maybe a warning for all-private modules would be appropriate? A module without any public entities is not very useful, I guess ...
[Bug fortran/59941] [4.7 Regression] [OOP] ICE with polymorphic types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59941 --- Comment #8 from janus at gcc dot gnu.org --- Backtrace from gdb: Program received signal SIGSEGV, Segmentation fault. 0x004d19d6 in replace_comp (expr=expr@entry=0x146cc10, sym=sym@entry=0x146f7a0, i=i@entry=0x7fffdc6c) at /home/jweil/gcc47/branch/gcc/fortran/expr.c:4199 4199!gfc_is_intrinsic (expr-symtree-n.sym, 0, expr-where))) (gdb) bt #0 0x004d19d6 in replace_comp (expr=expr@entry=0x146cc10, sym=sym@entry=0x146f7a0, i=i@entry=0x7fffdc6c) at /home/jweil/gcc47/branch/gcc/fortran/expr.c:4199 #1 0x004d46ba in gfc_traverse_expr (expr=0x146cc10, sym=sym@entry=0x146f7a0, func=func@entry=0x4d19a0 replace_comp, f=f@entry=0) at /home/jweil/gcc47/branch/gcc/fortran/expr.c:3929 #2 0x004d6c9c in gfc_expr_replace_comp (expr=optimized out, dest=dest@entry=0x146f7a0) at /home/jweil/gcc47/branch/gcc/fortran/expr.c:4218 #3 0x00524615 in resolve_fl_derived0 (sym=sym@entry=0x146e590) at /home/jweil/gcc47/branch/gcc/fortran/resolve.c:11724 #4 0x0052c80d in resolve_fl_derived (sym=sym@entry=0x146e590) at /home/jweil/gcc47/branch/gcc/fortran/resolve.c:12046 #5 0x00522238 in resolve_symbol (sym=0x146e590) at /home/jweil/gcc47/branch/gcc/fortran/resolve.c:12308 #6 0x00540a84 in do_traverse_symtree (st=0x146ca50, st_func=st_func@entry=0x0, sym_func=sym_func@entry=0x521ac0 resolve_symbol) at /home/jweil/gcc47/branch/gcc/fortran/symbol.c:3387 #7 0x0054440d in gfc_traverse_ns (ns=ns@entry=0x146bf80, sym_func=sym_func@entry=0x521ac0 resolve_symbol) at /home/jweil/gcc47/branch/gcc/fortran/symbol.c:3412 #8 0x005209d1 in resolve_types (ns=ns@entry=0x146bf80) at /home/jweil/gcc47/branch/gcc/fortran/resolve.c:13885 #9 0x005213c1 in gfc_resolve (ns=0x146bf80) at /home/jweil/gcc47/branch/gcc/fortran/resolve.c:13985 #10 0x0052f7a5 in gfc_resolve (ns=optimized out) at /home/jweil/gcc47/branch/gcc/fortran/resolve.c:13978 #11 0x00516153 in resolve_all_program_units (gfc_global_ns_list=0x145ab60) at /home/jweil/gcc47/branch/gcc/fortran/parse.c:4392
