Summary: | [OOP] ICE in gfc_conv_variable, at fortran/trans-expr.c:551 | ||
---|---|---|---|
Product: | gcc | Reporter: | Fran Martinez Fadrique <ffadrique> |
Component: | fortran | Assignee: | janus |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | burnus, ffadrique, gcc-bugs, janus |
Priority: | P3 | Keywords: | ice-on-valid-code |
Version: | 4.5.0 | ||
Target Milestone: | 4.6.0 | ||
Host: | Target: | ||
Build: | Known to work: | ||
Known to fail: | Last reconfirmed: | 2010-04-26 20:40:53 | |
Attachments: |
Just a module, with a type and associated methods. Needed by the one causing the error.
The file causing the error during compilation. |
Description
Fran Martinez Fadrique
2010-04-26 15:33:27 UTC
Created attachment 20493 [details]
Just a module, with a type and associated methods. Needed by the one causing the error.
Created attachment 20494 [details]
The file causing the error during compilation.
Confirmed. The ICE happens with 4.5, trunk and fortran-dev. Thanks for the report! Confirmed with 4.5.0 and 4.6.0. At least NAG f95 thinks that the current code is invalid; it writes for the second file: Error: m_vector.f03, line 394: Reference via operator * to impure ROTATION_MATRIX_TIMES_VECTOR from pure ROTATION_MATRIX_TIMES_VECTOR which is in the following line: ! Compute result res%x = rot * right%x * * * The assert fails at gfc_conv_variable for: sym = expr->symtree->n.sym; if (se->ss != NULL) { /* Check that something hasn't gone horribly wrong. */ gcc_assert (se->ss != gfc_ss_terminator); gcc_assert (se->ss->expr == expr); <<<<<<< ICE * * * My old "4.6.0 20100421 fortran-dev revision 158628" fails with another ICE: ICE in gfc_build_null_descriptor, at fortran/trans-array.c:373 (In reply to comment #3) > The ICE happens with 4.5, trunk and fortran-dev. Actually this is only half-true. With fortran-dev one already gets an ICE on the first file, which is different from the one reported in comment #0: gfortran-dev -c m_rotation_matrix.f03 f951: internal compiler error: in gfc_build_null_descriptor, at fortran/trans-array.c:373 So obviously this is a fortran-dev regression. Here is a reduced test case for the fortran-dev failure, which turns out to be pretty trivial. All it takes is an array-valued TBP (wonder if we don't have such a thing in the testsuite already): module m_rotation_matrix type t_rotation_matrix contains procedure :: array => rotation_matrix_array end type contains function rotation_matrix_array( rot ) result(array) class(t_rotation_matrix) :: rot double precision, dimension(3,3) :: array end function end module Actually both ROTATION_MATRIX_TIMES_VECTOR are pure; the one in m_vector is elemental, therefore pure, and the one in m_rotation_matrix is pure.
I have changed the one in m_rotation_matrix to ROTATION_MATRIX_TIMES_ARRAY to remove the names collision and the ICE remains (I guess as expected)
I am a bit surprised about the NAG compiler behaviour.
> Confirmed with 4.5.0 and 4.6.0.
>
> At least NAG f95 thinks that the current code is invalid; it writes for the
> second file:
>
> Error: m_vector.f03, line 394: Reference via operator * to impure
> ROTATION_MATRIX_TIMES_VECTOR from pure ROTATION_MATRIX_TIMES_VECTOR
> which is in the following line:
>
> ! Compute result
> res%x = rot * right%x
>
> * * *
>
> The assert fails at gfc_conv_variable for:
> sym = expr->symtree->n.sym;
> if (se->ss != NULL)
> {
> /* Check that something hasn't gone horribly wrong. */
> gcc_assert (se->ss != gfc_ss_terminator);
> gcc_assert (se->ss->expr == expr); <<<<<<< ICE
>
> * * *
>
> My old "4.6.0 20100421 fortran-dev revision 158628" fails with another ICE:
> ICE in gfc_build_null_descriptor, at fortran/trans-array.c:373
>
Ok, here is a preliminary patch which fixes the fortran-dev problem: Index: gcc/fortran/symbol.c =================================================================== --- gcc/fortran/symbol.c (revision 158741) +++ gcc/fortran/symbol.c (working copy) @@ -4831,8 +4831,7 @@ add_proc_component (gfc_component *c, gfc_symbol * /* A static initializer cannot be used here because the specific function is not a constant; internal compiler error: in output_constant, at varasm.c:4623 */ - c->initializer = gfc_get_expr (); - c->initializer->expr_type = EXPR_NULL; + c->initializer = NULL; } @@ -4944,8 +4943,7 @@ copy_vtab_proc_comps (gfc_symbol *declared, gfc_sy c->ts.u.derived = cmp->ts.u.derived; c->attr.flavor = FL_VARIABLE; c->attr.pointer = 1; - c->initializer = gfc_get_expr (); - c->initializer->expr_type = EXPR_NULL; + c->initializer = NULL; continue; } @@ -4959,8 +4957,7 @@ copy_vtab_proc_comps (gfc_symbol *declared, gfc_sy c->ts.interface = cmp->ts.interface; c->attr.untyped = 1; c->attr.if_source = IFSRC_IFBODY; - c->initializer = gfc_get_expr (); - c->initializer->expr_type = EXPR_NULL; + c->initializer = NULL; } } Will regtest now. (In reply to comment #7) > Actually both ROTATION_MATRIX_TIMES_VECTOR are pure; the one in m_vector is > elemental, therefore pure, and the one in m_rotation_matrix is pure. > I have changed the one in m_rotation_matrix to ROTATION_MATRIX_TIMES_ARRAY to > remove the names collision and the ICE remains (I guess as expected) > I am a bit surprised about the NAG compiler behaviour. Same with me - at least that part looks OK; having the same name confuses the programmer, but it should not confuse the compiler (for generic/operator resolution) and looks valid (as the specific function is PRIVATE). [NAG f95 = version 5.1] Subject: Bug 43896 Author: janus Date: Tue Apr 27 07:38:06 2010 New Revision: 158767 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158767 Log: 2010-04-27 Janus Weil <janus@gcc.gnu.org> PR fortran/43896 * symbol.c (add_proc_component,copy_vtab_proc_comps): Remove initializers for PPC members of the vtabs. 2010-04-27 Janus Weil <janus@gcc.gnu.org> PR fortran/43896 * gfortran.dg/class_16.f03: New. Added: branches/fortran-dev/gcc/testsuite/gfortran.dg/class_16.f03 Modified: branches/fortran-dev/gcc/fortran/ChangeLog.fortran-dev branches/fortran-dev/gcc/fortran/symbol.c branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev The commit in comment #10 fixes the fortran-dev regression, but not the original problem in comment #0. > The commit in comment #10 fixes the fortran-dev regression, but not the > original problem in comment #0. The original problem in comment #0 is probably a duplicate of pr42051 both fails with internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:556 In my tree I have the patch in comment #3 of pr42051 and comment #4 of pr41539 and I don't get the ICE. However I think there is still something wrong as I get the following link error: Undefined symbols: "_vtab$t_rotation_matrix.2313", referenced from: ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o ld: symbol(s) not found collect2: ld returned 1 exit status I have not got that far to the linking step. I am converting some code to a more OOP style.
I have tried to patch my local version but unfrtunately what I have downloaded, 4.5_20100422 and 4.5_20100424, do not seem to match in the symbol.c with the patch distributed yesterday in the comments. Am I getting the wrong versions of the source?
Please help.
> > The commit in comment #10 fixes the fortran-dev regression, but not the
> > original problem in comment #0.
> The original problem in comment #0 is probably a duplicate of pr42051 both
> fails with
> internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:556
> In my tree I have the patch in comment #3 of pr42051 and comment #4 of pr41539
> and I don't get the ICE. However I think there is still something wrong as I
> get the following link error:
> Undefined symbols:
> "_vtab$t_rotation_matrix.2313", referenced from:
> ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
> ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
> ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
> ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
> ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
> ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
> ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
> ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
> ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
> ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
> ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
> ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
> ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
> ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
(In reply to comment #13) > I have not got that far to the linking step. I am converting some code to a > more OOP style. I have tried to patch my local version but unfrtunately what > I have downloaded, 4.5_20100422 and 4.5_20100424, do not seem to match in > the symbol.c with the patch distributed yesterday in the comments. Am I > getting the wrong versions of the source? Well, there are three development "branches": * 4.5 ("gcc-4_5-branch", which you seemingly have downloaded): Last stable release of GCC, which only sees regression fixes and serious fixes * 4.6 experimental ("trunk"): The version which will be 4.6.0 in about a year, which is continuously being modified. * "fortran-dev": Based on 4.6, but contains some additional fixes for polymorphism/OOP. The commit in comment 10 was against fortran-dev, which fixed an additional problem on Fortran-dev, which was revealed with your example. It does not yet fix the initial problem - neither on Fortran-dev nor on the trunk (i.e. 4.6.0). In the next few days, the changes from "fortran-dev" will be merged into the trunk as "fortran-dev" fixes severals OOP-related issues (but not yet yours). Dominique (comment 12) used a few patches on top of fortran-dev. I think the simplest is to wait a few days and then use the 4.6 version (not 4.5_...). I've reduced the test case to the bare minimum required to trigger the ICE: module m_rotation_matrix type t_rotation_matrix end type contains function rotation_matrix_times_vector( left ) result(res) class(t_rotation_matrix), intent(in) :: left double precision, dimension(3) :: res res = 0 end function end module use m_rotation_matrix type(t_rotation_matrix) :: rot print *, rotation_matrix_times_vector (rot ) end And yes, I agree that it's a duplicate of PR 42051. Subject: Bug 43896 Author: pault Date: Thu Apr 29 19:10:48 2010 New Revision: 158910 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158910 Log: 2010-04-29 Janus Weil <janus@gcc.gnu.org> PR fortran/43896 * symbol.c (add_proc_component,copy_vtab_proc_comps): Remove initializers for PPC members of the vtabs. 2010-04-29 Janus Weil <janus@gcc.gnu.org> PR fortran/42274 * symbol.c (add_proc_component,add_proc_comps): Correctly set the 'ppc' attribute for all PPC members of the vtypes. (copy_vtab_proc_comps): Copy the correct interface. * trans.h (gfc_trans_assign_vtab_procs): Modified prototype. * trans-expr.c (gfc_trans_assign_vtab_procs): Pass the derived type as a dummy argument and make sure all PPC members of the vtab are initialized correctly. (gfc_conv_derived_to_class,gfc_trans_class_assign): Additional argument in call to gfc_trans_assign_vtab_procs. * trans-stmt.c (gfc_trans_allocate): Ditto. 2010-04-29 Paul Thomas <pault@gcc.gnu.org> PR fortran/43326 * resolve.c (resolve_typebound_function): Renamed resolve_class_compcall.Do all the detection of class references here. (resolve_typebound_subroutine): resolve_class_typebound_call renamed. Otherwise same as resolve_typebound_function. (gfc_resolve_expr): Call resolve_typebound_function. (resolve_code): Call resolve_typebound_subroutine. 2010-04-29 Janus Weil <janus@gcc.gnu.org> PR fortran/43492 * resolve.c (resolve_typebound_generic_call): For CLASS methods pass back the specific symtree name, rather than the target name. 2010-04-29 Paul Thomas <pault@gcc.gnu.org> PR fortran/42353 * resolve.c (resolve_structure_cons): Make the initializer of the vtab component 'extends' the same type as the component. 2010-04-29 Jerry DeLisle <jvdelisle@gcc.gnu.org> PR fortran/42680 * interface.c (check_interface1): Pass symbol name rather than NULL to gfc_compare_interfaces.(gfc_compare_interfaces): Add assert to trap MULL. (gfc_compare_derived_types): Revert previous change incorporated incorrectly during merge from trunk, r155778. * resolve.c (check_generic_tbp_ambiguity): Pass symbol name rather than NULL to gfc_compare_interfaces. * symbol.c (add_generic_specifics): Likewise. 2010-02-29 Janus Weil <janus@gcc.gnu.org> PR fortran/42353 * interface.c (gfc_compare_derived_types): Add condition for vtype. * symbol.c (gfc_find_derived_vtab): Sey access to private. (gfc_find_derived_vtab): Likewise. * module.c (ab_attribute): Add enumerator AB_VTAB. (mio_symbol_attribute): Use new attribute, AB_VTAB. (check_for_ambiguous): Likewise. 2010-04-29 Paul Thomas <pault@gcc.gnu.org> Janus Weil <janus@gcc.gnu.org> PR fortran/41829 * trans-expr.c (select_class_proc): Remove function. (conv_function_val): Delete reference to previous. (gfc_conv_derived_to_class): Add second argument to the call to gfc_find_derived_vtab. (gfc_conv_structure): Exclude proc_pointer components when accessing $data field of class objects. (gfc_trans_assign_vtab_procs): New function. (gfc_trans_class_assign): Add second argument to the call to gfc_find_derived_vtab. * symbol.c (gfc_build_class_symbol): Add delayed_vtab arg and implement holding off searching for the vptr derived type. (add_proc_component): New function. (add_proc_comps): New function. (add_procs_to_declared_vtab1): New function. (copy_vtab_proc_comps): New function. (add_procs_to_declared_vtab): New function. (void add_generic_specifics): New function. (add_generics_to_declared_vtab): New function. (gfc_find_derived_vtab): Add second argument to the call to gfc_find_derived_vtab. Add the calls to add_procs_to_declared_vtab and add_generics_to_declared_vtab. * decl.c (build_sym, build_struct): Use new arg in calls to gfc_build_class_symbol. * gfortran.h : Add vtype bitfield to symbol_attr. Remove the definition of struct gfc_class_esym_list. Modify prototypes of gfc_build_class_symbol and gfc_find_derived_vtab. * trans-stmt.c (gfc_trans_allocate): Add second argument to the call to gfc_find_derived_vtab. * module.c : Add the vtype attribute. * trans.h : Add prototype for gfc_trans_assign_vtab_procs. * resolve.c (resolve_typebound_generic_call): Add second arg to pass along the generic name for class methods. (resolve_typebound_call): The same. (resolve_compcall): Use the second arg to carry the generic name from the above. Remove the reference to class_esym. (check_members, check_class_members, resolve_class_esym, hash_value_expr): Remove functions. (resolve_class_compcall, resolve_class_typebound_call): Modify to use vtable rather than member by member calls. (gfc_resolve_expr): Modify second arg in call to resolve_compcall. (resolve_select_type): Add second arg in call to gfc_find_derived_vtab. (resolve_code): Add second arg in call resolve_typebound_call. (resolve_fl_derived): Exclude vtypes from check for late procedure definitions. Likewise for checking of explicit interface and checking of pass arg. * iresolve.c (gfc_resolve_extends_type_of): Add second arg in calls to gfc_find_derived_vtab. * match.c (select_type_set_tmp): Use new arg in call to gfc_build_class_symbol. * trans-decl.c (gfc_get_symbol_decl): Complete vtable if necessary. * parse.c (endType): Finish incomplete classes. 2010-04-29 Janus Weil <janus@gcc.gnu.org> PR fortran/42274 * gfortran.dg/class_16.f03: New test. 2010-04-29 Janus Weil <janus@gcc.gnu.org> PR fortran/42274 * gfortran.dg/class_15.f03: New. 2010-04-29 Paul Thomas <pault@gcc.gnu.org> PR fortran/43326 * gfortran.dg/dynamic_dispatch_9.f03: New test. 2010-04-29 Janus Weil <janus@gcc.gnu.org> PR fortran/43492 * gfortran.dg/generic_22.f03 : New test. 2010-04-29 Paul Thomas <pault@gcc.gnu.org> PR fortran/42353 * gfortran.dg/class_14.f03: New test. 2010-04-29 Jerry DeLisle <jvdelisle@gcc.gnu.org> PR fortran/42680 * gfortran.dg/interface_32.f90: New test. 2009-04-29 Paul Thomas <pault@gcc.gnu.org> Janus Weil <janus@gcc.gnu.org> PR fortran/41829 * gfortran.dg/dynamic_dispatch_5.f03 : Change to "run". * gfortran.dg/dynamic_dispatch_7.f03 : New test. * gfortran.dg/dynamic_dispatch_8.f03 : New test. Added: trunk/gcc/testsuite/gfortran.dg/class_14.f03 trunk/gcc/testsuite/gfortran.dg/class_15.f03 trunk/gcc/testsuite/gfortran.dg/class_16.f03 trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_8.f03 trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_9.f03 trunk/gcc/testsuite/gfortran.dg/generic_22.f03 trunk/gcc/testsuite/gfortran.dg/interface_32.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/match.c trunk/gcc/fortran/module.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_5.f03 trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_7.f03 So it seems tht the bug is not gone. I have tried again with version from May 8th and I still get the problem on line 556. I tried to submit a comment yesterday but it seems that it failed. Here it goes again. (In reply to comment #17) > So it seems tht the bug is not gone. I have tried again with version from May > 8th and I still get the problem on line 556. Yes, the issue is not fixed yet. The commit in comment #16 was just the merging of the fortran-dev branch to trunk, which did nothing about the ICE. We'll take care of this soon ... Subject: Bug 43896 Author: janus Date: Fri Jun 11 16:45:48 2010 New Revision: 160622 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160622 Log: 2010-06-11 Paul Thomas <pault@gcc.gnu.org> PR fortran/42051 PR fortran/43896 * trans-expr.c (gfc_conv_derived_to_class): Handle array-valued functions with CLASS formal arguments. 2010-06-11 Paul Thomas <pault@gcc.gnu.org> PR fortran/42051 PR fortran/43896 * gfortran.dg/class_23.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/class_23.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog Fixed with r160622. Closing. Similarly to PR 41539, I now get linking errors of the kind vtab$... /tmp/ccd6KJqa.o: In function `__m_vector_MOD_rotation_matrix_times_vector': test.f90:(.text+0x238b): undefined reference to `vtab$t_rotation_matrix.2317' Author: janus Date: Tue Aug 16 21:22:31 2011 New Revision: 177800 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177800 Log: 2011-08-16 Paul Thomas <pault@gcc.gnu.org> PR fortran/42051 PR fortran/43896 PR fortran/49962 * trans-expr.c (gfc_conv_derived_to_class): Handle array-valued functions with CLASS formal arguments. 2011-08-16 Paul Thomas <pault@gcc.gnu.org> PR fortran/42051 PR fortran/43896 PR fortran/49962 * gfortran.dg/class_23.f03: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/class_23.f03 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/trans-expr.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog *** Bug 60701 has been marked as a duplicate of this bug. *** |