[Bug fortran/44110] New: [4.6 Regression] FAIL: gfortran.dg/proc_ptr_23.f90 -O3 -g (test for excess errors) etc
At r159354 I see the following new failures in the testsuite: FAIL: gfortran.dg/proc_ptr_23.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/proc_ptr_25.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/proc_ptr_comp_9.f90 -O3 -g (test for excess errors) They give errors like /tmp/ccJ47x9g.o:(.debug_info+0x81): undefined reference to `abc.1535' /tmp/ccW6t4P4.o:(.debug_loc+0x12f): undefined reference to `add.1539' /tmp/cckErzEU.o:(.debug_info+0x21e): undefined reference to `triple.1552' (only with -O3 -g). I think these failures have not been there at r159303. -- Summary: [4.6 Regression] FAIL: gfortran.dg/proc_ptr_23.f90 -O3 -g (test for excess errors) etc Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44110
[Bug fortran/43207] [OOP] ICE for class pointer = null() initialization
--- Comment #3 from janus at gcc dot gnu dot org 2010-05-13 14:47 --- (In reply to comment #0) fff.f90:26:0: internal compiler error: in gfc_conv_structure, at fortran/trans-expr.c:4390 It turns out this ICE is actually due to the NULL() initialization of the class pointer and has nothing to do with the invalid pointer assignment. Here is a simpler test case: implicit none type :: parent end type class(parent) ,pointer :: this = null() call foo(this) contains subroutine foo(this) class(parent) :: this end subroutine end -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords|ice-on-invalid-code |ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2010-05-13 14:47:03 date|| Summary|[OOP] ICE for invalid |[OOP] ICE for class pointer |pointer assignment = |= null() initialization |type%parent | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43207
[Bug fortran/43207] [OOP] ICE for class pointer = null() initialization
--- Comment #4 from janus at gcc dot gnu dot org 2010-05-13 14:55 ---
When removing the NULL initialization in comment #3, the dump shows:
static struct .class.parent.p this = {.$data=0B};
Zeroing the $data pointer is probably not needed without NULL initialization.
With NULL initialization, both the $data and the $vptr components should be
zeroed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43207
[Bug fortran/44044] [OOP] SELECT TYPE with class-valued function
--- Comment #5 from janus at gcc dot gnu dot org 2010-05-10 12:54 --- Subject: Bug 44044 Author: janus Date: Mon May 10 12:54:25 2010 New Revision: 159217 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159217 Log: 2010-05-10 Janus Weil ja...@gcc.gnu.org PR fortran/44044 * match.c (gfc_match_select_type): Move error message to resolve_select_type. * resolve.c (resolve_select_type): Error message moved here from gfc_match_select_type. Correctly set type of temporary. 2010-05-10 Janus Weil ja...@gcc.gnu.org PR fortran/44044 * gfortran.dg/class_7.f03: Modified. * gfortran.dg/select_type_1.f03: Modified. * gfortran.dg/select_type_12.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/select_type_12.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/class_7.f03 trunk/gcc/testsuite/gfortran.dg/select_type_1.f03 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44044
[Bug fortran/44064] [OOP] ICE with file containing two modules and one program
--- Comment #3 from janus at gcc dot gnu dot org 2010-05-10 21:59 --- For me, compiling the code in comment #0 in a single file seems to get stuck in an endless loop (trunk rev. 159217 on x86_64-unknown-linux-gnu). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44064
[Bug fortran/44065] [OOP] Undefined reference to TBP
--- Comment #2 from janus at gcc dot gnu dot org 2010-05-10 22:06 --- Confirmed. Compiling via ... gfortran-4.6 -c module.f90 gfortran-4.6 test.f90 ... works, though. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|libfortran |fortran Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-10 22:06:33 date|| Summary|Undefined reference to TBP |[OOP] Undefined reference to ||TBP http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44065
[Bug fortran/44047] New: [OOP] SELECT TYPE with associate-name and allocatable selector
The following test case is a modified version of the one in http://gcc.gnu.org/ml/fortran/2009-10/msg00047.html: implicit none type t0 integer :: j = 42 end type t0 type t integer :: i class(t0), allocatable :: foo end type t type(t) :: m allocate(t0 :: m%foo) m%i = 5 select type(bar = m%foo) type is(t0) print *, bar end select end While the original version (using allocatable CLASS arrays) still ICEs, this one here compiles cleanly, but gives a double free runtime error. The reason for this error is that we generate a local temporary for bar, which is auto-deallocated at the end of the SELECT TYPE block, so that the auto-deallocation of m%foo fails. The auto-deallocation of bar should not happen, i.e. bar should not have the ALLOCATABLE attribute (currently the dump shows struct .class.t0.a bar). -- Summary: [OOP] SELECT TYPE with associate-name and allocatable selector Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44047
[Bug fortran/44044] [OOP] SELECT TYPE with class-valued function
-- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-09 11:55:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44044
[Bug fortran/44044] New: [OOP] SELECT TYPE with class-valued function
The following (valid) test case is currently rejected: implicit none type :: t1 integer :: i end type type, extends(t1) :: t2 end type type(t1),target :: x1 type(t2),target :: x2 select type ( y = fun(1) ) type is (t1) print *,t1 type is (t2) print *,t2 class default print *,default end select select type ( y = fun(-1) ) type is (t1) print *,t1 type is (t2) print *,t2 class default print *,default end select contains function fun(i) class(t1),pointer :: fun integer :: i if (i0) then fun = x1 else if (i0) then fun = x2 else fun = NULL() end if end function end ... with the bogus message: select type ( y = fun(1) ) 1 Error: Selector shall be polymorphic in SELECT TYPE statement at (1) -- Summary: [OOP] SELECT TYPE with class-valued function Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44044
[Bug fortran/44044] [OOP] SELECT TYPE with class-valued function
--- Comment #1 from janus at gcc dot gnu dot org 2010-05-08 20:13 --- Side note: Invalid code like function fun() class(t1) :: fun end function is not rejected, although the polymorphic 'fun' is neither a pointer, allocatable nor a dummy. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44044
[Bug fortran/44044] [OOP] SELECT TYPE with class-valued function
--- Comment #2 from janus at gcc dot gnu dot org 2010-05-08 20:20 --- Bonus feature #1: Adding this to comment #0 ... select type ( y = fun(0) ) type is (t1) print *,t1 type is (t2) print *,t2 class default print *,default end select ... should give a runtime error, since fun(0) evaluates to NULL. F08 section 16.5.1.6 demands that, if the selector is a pointer, it should be associated. In the same way, having an allocatable selector which is not allocated, should also give a runtime error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44044
[Bug fortran/44044] [OOP] SELECT TYPE with class-valued function
--- Comment #3 from janus at gcc dot gnu dot org 2010-05-08 20:23 --- Bonus feature #2: select type ( y = fun(1) ) type is (t1) y%i = 1 type is (t2) y%i = 2 end select ... should be rejected, due to (F08): C836 (R847) If selector is not a variable or is a variable that has a vector subscript, associate-name shall not appear in a variable de#64257;nition context (16.6.7). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44044
[Bug fortran/43696] [OOP] Bogus error: Passed-object dummy argument must not be POINTER
--- Comment #7 from janus at gcc dot gnu dot org 2010-05-05 07:45 --- Subject: Bug 43696 Author: janus Date: Wed May 5 07:44:33 2010 New Revision: 159056 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159056 Log: 2010-05-05 Janus Weil ja...@gcc.gnu.org PR fortran/43696 * resolve.c (resolve_fl_derived): Some fixes for class variables. * symbol.c (gfc_build_class_symbol): Add separate class container for class pointers. 2010-05-05 Janus Weil ja...@gcc.gnu.org PR fortran/43696 * gfortran.dg/class_17.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/class_17.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43696
[Bug fortran/43986] [OOP] gfortran.dg/dynamic_dispatch_4.f03 doesn't work on Linux/ia64
--- Comment #1 from janus at gcc dot gnu dot org 2010-05-05 08:12 --- Works for me on x86_64-unknown-linux-gnu. -- janus at gcc dot gnu dot org changed: What|Removed |Added Summary|gfortran.dg/dynamic_dispatch|[OOP] |_4.f03 doesn't work on |gfortran.dg/dynamic_dispatch |Linux/ia64 |_4.f03 doesn't work on ||Linux/ia64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43986
[Bug fortran/43696] [OOP] Bogus error: Passed-object dummy argument must not be POINTER
--- Comment #8 from janus at gcc dot gnu dot org 2010-05-05 08:13 --- Fixed with r159056. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43696
[Bug fortran/43990] New: [OOP] ICE in output_constructor_regular_field, at varasm.c:4995
module m type :: t logical :: l = .true. class(t),pointer :: cp = null() end type type(t),save :: default_t end module Compiling this currently results in: f951: internal compiler error: in output_constructor_regular_field, at varasm.c:4995 Reported by Hans-Werner Boschmann. -- Summary: [OOP] ICE in output_constructor_regular_field, at varasm.c:4995 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43990
[Bug fortran/43986] [OOP] gfortran.dg/dynamic_dispatch_4.f03 doesn't work on Linux/ia64
--- Comment #2 from janus at gcc dot gnu dot org 2010-05-05 13:07 --- It also works on x86_64-apple-darwin10.3.0. Does the failure on ia64 only happen with -O3? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43986
[Bug fortran/43696] [OOP] Bogus error: Passed-object dummy argument must not be POINTER
--- Comment #6 from janus at gcc dot gnu dot org 2010-05-03 20:03 --- Mine. I think fixing comment #0 is as easy as the following two-liner: Index: gcc/fortran/symbol.c === --- gcc/fortran/symbol.c(revision 158970) +++ gcc/fortran/symbol.c(working copy) @@ -4720,6 +4720,8 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_a sprintf (name, .class.%s.%d.a, ts-u.derived-name, (*as)-rank); else if ((*as) (*as)-rank) sprintf (name, .class.%s.%d, ts-u.derived-name, (*as)-rank); + else if (attr-pointer) +sprintf (name, .class.%s.p, ts-u.derived-name); else if (attr-allocatable) sprintf (name, .class.%s.a, ts-u.derived-name); else Apparently this doesn't even induce any testsuite regressions. However, the ICE in comment #4 will need some additional care. Btw, the ICE in comment #0 is gone already since fortran-dev has been merged to trunk. -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-03 20:03:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43696
[Bug fortran/43896] [OOP][fortran-dev Regression] ICE in gfc_conv_variable, at fortran/trans-expr.c:551
--- Comment #10 from janus at gcc dot gnu dot org 2010-04-27 07:38 --- Subject: Bug 43896 Author: janus Date: Tue Apr 27 07:38:06 2010 New Revision: 158767 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158767 Log: 2010-04-27 Janus Weil ja...@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 ja...@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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43896
[Bug fortran/43896] [OOP] ICE in gfc_conv_variable, at fortran/trans-expr.c:551
--- Comment #11 from janus at gcc dot gnu dot org 2010-04-27 07:41 --- The commit in comment #10 fixes the fortran-dev regression, but not the original problem in comment #0. -- janus at gcc dot gnu dot org changed: What|Removed |Added Summary|[OOP][fortran-dev |[OOP] ICE in |Regression] ICE in |gfc_conv_variable, at |gfc_conv_variable, at |fortran/trans-expr.c:551 |fortran/trans-expr.c:551| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43896
[Bug fortran/43896] [OOP] ICE in gfc_conv_variable, at fortran/trans-expr.c:551
--- Comment #15 from janus at gcc dot gnu dot org 2010-04-27 21:40 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43896
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #36 from janus at gcc dot gnu dot org 2010-04-26 09:08 --- Subject: Bug 42274 Author: janus Date: Mon Apr 26 09:07:26 2010 New Revision: 158721 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158721 Log: 2010-04-26 Janus Weil ja...@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-26 Janus Weil ja...@gcc.gnu.org PR fortran/42274 * gfortran.dg/class_15.f03: New. Added: branches/fortran-dev/gcc/testsuite/gfortran.dg/class_15.f03 Modified: branches/fortran-dev/gcc/fortran/ChangeLog.fortran-dev branches/fortran-dev/gcc/fortran/symbol.c branches/fortran-dev/gcc/fortran/trans-expr.c branches/fortran-dev/gcc/fortran/trans-stmt.c branches/fortran-dev/gcc/fortran/trans.h branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/43895] [fortran-dev] internal compiler error: verify_ssa failed
--- Comment #3 from janus at gcc dot gnu dot org 2010-04-26 14:56 --- Note: There is another OOP PR which fails only with optimization: PR41753. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43895
[Bug fortran/43895] [OOP] internal compiler error: verify_ssa failed
--- Comment #4 from janus at gcc dot gnu dot org 2010-04-26 15:04 --- Confirmed. It seems this fails already with the 4.5 release as well as with current trunk, which means that it's not specific to the fortran-dev branch. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-26 15:04:01 date|| Summary|[fortran-dev] internal |[OOP] internal compiler |compiler error: verify_ssa |error: verify_ssa failed |failed | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43895
[Bug fortran/43896] [OOP] ICE in gfc_conv_variable, at fortran/trans-expr.c:551
--- Comment #3 from janus at gcc dot gnu dot org 2010-04-26 17:33 --- Confirmed. The ICE happens with 4.5, trunk and fortran-dev. Thanks for the report! -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2010-04-26 17:33:45 date|| Summary|Compiler internal error |[OOP] ICE in ||gfc_conv_variable, at ||fortran/trans-expr.c:551 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43896
[Bug fortran/43896] [fortran-dev Regression] ICE in gfc_conv_variable, at fortran/trans-expr.c:551
--- Comment #5 from janus at gcc dot gnu dot org 2010-04-26 19:10 --- (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. -- janus at gcc dot gnu dot org changed: What|Removed |Added Keywords|ice-on-invalid-code | Summary|[OOP] ICE in|[fortran-dev Regression] ICE |gfc_conv_variable, at |in gfc_conv_variable, at |fortran/trans-expr.c:551|fortran/trans-expr.c:551 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43896
[Bug fortran/43896] [fortran-dev Regression] ICE in gfc_conv_variable, at fortran/trans-expr.c:551
--- Comment #6 from janus at gcc dot gnu dot org 2010-04-26 19:33 --- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43896
[Bug fortran/43896] [fortran-dev Regression] ICE in gfc_conv_variable, at fortran/trans-expr.c:551
--- Comment #8 from janus at gcc dot gnu dot org 2010-04-26 20:40 --- 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. -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-04-26 17:33:45 |2010-04-26 20:40:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43896
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #17 from janus at gcc dot gnu dot org 2010-04-25 14:32 ---
Created an attachment (id=20482)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20482action=view)
patch v2
The attached patch extends the one in comment #7, fixing all regressions
related to non-generic TBPs (hopefully). However, (at least) the following
regressions are left (all including generic TBPs):
* dynamic_dispatch_{1-3,5,7}.f03 in the testsuite
* comment #8 example 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #18 from janus at gcc dot gnu dot org 2010-04-25 14:42 --- Here is a maximally reduced version of comment #8 example 2, which still fails with the patch in comment #17: module m type :: t1 contains procedure :: make_integer generic :: extract = make_integer end type contains integer function make_integer (arg) class(t1), intent(in) :: arg make_integer = 3 end function end module use m class(t1), allocatable :: a allocate(a) print *, a%extract () end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #19 from janus at gcc dot gnu dot org 2010-04-25 14:56 ---
Created an attachment (id=20484)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20484action=view)
patch v3
Here is an updated patch, which fixes (among others) comment #8 example 2 and
comment #18. The remaining regressions are:
* dynamic_dispatch_{1-3}.f03
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #22 from janus at gcc dot gnu dot org 2010-04-25 16:43 ---
(In reply to comment #21)
/opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_operator_3.f03:84:0:
internal
compiler error: Segmentation fault
Yes, I can confirm that: typebound_operator_{3,4}.f03 both fail with an ICE.
Thanks for pointing that out. I haven't checked the full testsuite yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #23 from janus at gcc dot gnu dot org 2010-04-25 17:09 ---
Created an attachment (id=20485)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20485action=view)
patch v4
The attached update of the patch removes the ICEs in
typebound_operator_{3,4}.f03.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #24 from janus at gcc dot gnu dot org 2010-04-25 17:16 --- (In reply to comment #20) My suspicion, which is strengthened by the remaining regressions for version 3 of your fix, is that the generic components of the vtab should not be marked as ppc. I have been tempted to apply it blind but have been trying to analyse first :-) That does not mean that you should not give it a shot, though! Well, in the light of today's progress I am quite optimistic that it should be possible to have everything working with all the 'ppc' attributes in place. Note that many cases of generic TBPs are working already. The remaining failures seem to be related to generic TBPs with overriding. The following is a reduced version of the runtime failure in dynamic_dispatch_1.f03: module m type :: t1 integer :: i = 42 contains procedure, pass :: make_integer generic, public :: extract = make_integer end type t1 type, extends(t1) :: t2 integer :: j = 99 contains procedure, pass :: make_integer_2 generic, public :: extract = make_integer_2 end type t2 contains integer function make_integer (arg, arg2) class(t1), intent(in) :: arg integer :: arg2 make_integer = arg%i * arg2 end function make_integer integer function make_integer_2 (arg, arg2) class(t2), intent(in) :: arg integer :: arg2 make_integer_2 = arg%j * arg2 end function make_integer_2 end module m use m class(t1), pointer :: a type(t2), target :: c a = c print *,a%extract(3) if (a%extract (3) .ne. 297) call abort! FAIL end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #25 from janus at gcc dot gnu dot org 2010-04-25 18:23 ---
I just did a full testsuite run, verifying that dynamic_dispatch_{1-3}.f03
are indeed the only failures with the patch in comment #23.
This means that, if we can fix the failure in comment #24, the branch will most
probably be clean, and we can finally merge back to trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #30 from janus at gcc dot gnu dot org 2010-04-25 19:50 --- (In reply to comment #29) (In reply to comment #27) Created an attachment (id=20486) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20486action=view) [edit] Tried this patch: compilation goes past the previous point, so we made progress. My library build stops later with Salvatore: As you heard, Paul's patch is screwed up. Maybe you could rather try the patch in comment #23, which is clean (except for a small regression) and fixes your original problem. Does this give the same error on your code? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #31 from janus at gcc dot gnu dot org 2010-04-25 20:17 ---
Ok, back to fixing the remaining regression, namely comment #24. Compiling this
with and without the patch in comment #23 shows the following difference:
--- c24.dump.unpatched 2010-04-25 22:03:44.418204091 +0200
+++ c24.dump.patched2010-04-25 21:55:50.500619202 +0200
@@ -27,7 +27,7 @@ MAIN__ ()
if (vtab$t2.make_integer == 0B)
{
vtab$t2.make_integer = (integer(kind=4) (*T434) (void)) make_integer;
- vtab$vtype$t2$extract.make_integer = make_integer_2;
+ vtab$vtype$t2$extract.make_integer = (integer(kind=4) (*T43f) (struct
.class.t2 restrict, integer(kind=4) restrict)) make_integer;
vtab$t2.extract = vtab$vtype$t2$extract;
vtab$t2.make_integer_2 = (integer(kind=4) (*T434) (void))
make_integer_2;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #33 from janus at gcc dot gnu dot org 2010-04-25 21:44 ---
Created an attachment (id=20488)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20488action=view)
patch v5
The attached version of the patch clears the failures of
dynamic_dispatch_{1-3}.f03. It is free of regressions in class_*, dynamic_* and
typebound_*. Will do a full testsuite run now.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Attachment #20482|0 |1
is obsolete||
Attachment #20484|0 |1
is obsolete||
Attachment #20485|0 |1
is obsolete||
Attachment #20486|0 |1
is obsolete||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #34 from janus at gcc dot gnu dot org 2010-04-25 22:26 --- (In reply to comment #33) Will do a full testsuite run now. The testsuite completed cleanly, without any failures. Paul, if you agree that this patch is ok, I can commit it tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #16 from janus at gcc dot gnu dot org 2010-04-22 20:58 --- For completeness, here is a reduced/modified version of the original test case in comment #1: module mod_A type :: t1 contains procedure,nopass :: fun end type contains logical function fun() end function end module module mod_B use mod_A type, extends(t1) :: t2 contains procedure :: sub1 end type contains subroutine sub1(a) class(t2) :: a end subroutine end module module mod_C contains subroutine sub2(b) use mod_B type(t2) :: b end subroutine end module module mod_D use mod_A use mod_C end module -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/43326] [fortran-dev Regression] dynamic dispatch with CLASS components
--- Comment #5 from janus at gcc dot gnu dot org 2010-04-20 12:26 --- (In reply to comment #4) Technically this PR, fixed on trunk but not on fortran-dev, is now a [fortran-dev Regression]. Could it be marked that way? Yes. -- janus at gcc dot gnu dot org changed: What|Removed |Added Summary|[OOP] dynamic dispatch with |[fortran-dev Regression] |CLASS components|dynamic dispatch with CLASS ||components http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43326
[Bug fortran/43492] [fortran-dev Regression] ICE in gfc_add_component_ref, at fortran/expr.c:352
--- Comment #4 from janus at gcc dot gnu dot org 2010-04-20 20:51 --- Further reduced test case: module base_mod type :: base_mat contains procedure :: transp1 = base_transp1 generic :: transp = transp1 end type base_mat contains subroutine base_transp1(a) class(base_mat) :: a end subroutine base_transp1 subroutine base_transc1(a) class(base_mat) :: a call a%transp() end subroutine base_transc1 end module -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43492
[Bug fortran/43492] [fortran-dev Regression] ICE in gfc_add_component_ref, at fortran/expr.c:352
--- Comment #5 from janus at gcc dot gnu dot org 2010-04-20 21:56 --- Here is a preliminary patch: Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c (revision 158513) +++ gcc/fortran/resolve.c (working copy) @@ -5174,7 +5174,7 @@ resolve_typebound_generic_call (gfc_expr* e, const /* Pass along the name for CLASS methods, where the vtab procedure pointer component has to be referenced. */ if (name) - *name = target-name; + *name = g-specific_st-name; goto success; } } It fixes the test case, but I haven't regtested it yet. -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-04-19 11:07:19 |2010-04-20 21:56:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43492
[Bug fortran/43492] [fortran-dev Regression] ICE in gfc_add_component_ref, at fortran/expr.c:352
--- Comment #3 from janus at gcc dot gnu dot org 2010-04-19 11:07 --- Confirmed. Backtrace: #0 gfc_add_component_ref (e=0x17cb5e0, name=0x77f2fe70 base_transp1) at /home/jweil/gcc46/fortran-dev/gcc/fortran/expr.c:703 #1 0x00528306 in resolve_class_typebound_call (code=0x17cb6a0) at /home/jweil/gcc46/fortran-dev/gcc/fortran/resolve.c:5454 #2 0x0052dd1e in resolve_code (code=0x17cb6a0, ns=0x17caa30) at /home/jweil/gcc46/fortran-dev/gcc/fortran/resolve.c:8345 #3 0x005378fd in resolve_codes (ns=0x17caa30) at /home/jweil/gcc46/fortran-dev/gcc/fortran/resolve.c:12686 #4 0x005377ee in resolve_codes (ns=0x17c4b50) at /home/jweil/gcc46/fortran-dev/gcc/fortran/resolve.c:12672 #5 0x005379f8 in gfc_resolve (ns=0x17c4b50) at /home/jweil/gcc46/fortran-dev/gcc/fortran/resolve.c:12713 #6 0x00516ec1 in gfc_parse_file () at /home/jweil/gcc46/fortran-dev/gcc/fortran/parse.c:4292 #7 0x005591e3 in gfc_be_parse_file (set_yydebug=0) at /home/jweil/gcc46/fortran-dev/gcc/fortran/f95-lang.c:239 #8 0x00a0d48f in compile_file () at /home/jweil/gcc46/fortran-dev/gcc/toplev.c:1053 #9 0x00a0f779 in do_compile () at /home/jweil/gcc46/fortran-dev/gcc/toplev.c:2423 #10 0x00a0f84f in toplev_main (argc=2, argv=0x7fffe308) at /home/jweil/gcc46/fortran-dev/gcc/toplev.c:2465 #11 0x005e0f68 in main (argc=2, argv=0x7fffe308) at /home/jweil/gcc46/fortran-dev/gcc/main.c:35 -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-19 11:07:19 date|| Summary|[fortran-dev] ICE in|[fortran-dev Regression] ICE |gfc_add_component_ref, at |in gfc_add_component_ref, at |fortran/expr.c:352 |fortran/expr.c:352 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43492
[Bug fortran/43227] [4.5/4.6 Regression] ICE: segmentation fault in mio_expr
--- Comment #11 from janus at gcc dot gnu dot org 2010-04-19 12:51 --- (In reply to comment #10) AFAICR the problem is specific to the fortran-dev branch. No, this is definitely not the case! Only the failure of comment #0 is specific to the branch. However, this failure is caused by an underlying problem with procedure pointers, which is also present in the 4.5 release (see comment #3). When searching for the origin of the regression, one should use the test case in comment #3 and look at the 4.5 trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227
[Bug fortran/43227] [4.5/4.6 Regression] ICE: segmentation fault in mio_expr
--- Comment #13 from janus at gcc dot gnu dot org 2010-04-19 13:21 --- I keep forgetting this test!-(on i686-apple-darwin9, it compiles at revision 147438, 20090512, and fails at revision 150825, 20090817). That's a start. I can see two (hypothetical) candidates in this range: * r150725 * r150823 Will try to find out if one of these is the culprit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227
[Bug fortran/43227] [4.5/4.6 Regression] ICE: segmentation fault in mio_expr
--- Comment #14 from janus at gcc dot gnu dot org 2010-04-19 13:46 --- (In reply to comment #13) I keep forgetting this test!-(on i686-apple-darwin9, it compiles at revision 147438, 20090512, and fails at revision 150825, 20090817). That's a start. I can see two (hypothetical) candidates in this range: * r150725 * r150823 I just checked r150724, which also fails. This means that both my guesses were wrong. But at least it bring us down to the range 147438:150724 (which is still three months of development). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227
[Bug fortran/43227] [4.5/4.6 Regression] ICE: segmentation fault in mio_expr
--- Comment #17 from janus at gcc dot gnu dot org 2010-04-19 18:47 --- (In reply to comment #16) I think the culprit is: Date: Sat Jul 25 11:56:35 2009 New Revision: 150078 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150078 Close, but not quite :) It's actually r150047, as I just found out. However, this revision only introduces the first ICE in the test case: module m_string procedure(string_to_char) :: char1! ICE #1 ! procedure(string_to_char),pointer :: char2 ! ICE #2 ! type t_string ! procedure(string_to_char),pointer,nopass :: char3 ! ICE #3 ! end type t_string contains function string_to_char (s) result(res) character, dimension(:), intent(in) :: s character(len=size(s)) :: res end function string_to_char end module m_string The second one is already there at r150046. For this I found a window of 147438:148816 up to now. Will try to find out more. The third ICE is not present at 150047, but is apparently masked by another error: character(len=size(s)) :: res 1 Error: Character length of component 'char3' needs to be a constant specification expression at (1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227
[Bug fortran/43227] [4.5/4.6 Regression] ICE: segmentation fault in mio_expr
--- Comment #21 from janus at gcc dot gnu dot org 2010-04-19 21:34 ---
(In reply to comment #20)
Created an attachment (id=20429)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20429action=view) [edit]
A provisional fix for the PR
Yes, the following parts are approved (they're exactly what I had in mind):
@@ -10292,6 +10298,8 @@
{
c-ts.u.cl = gfc_new_charlen (sym-ns, ifc-ts.u.cl);
gfc_expr_replace_comp (c-ts.u.cl-length, c);
+ if (c-ts.u.cl-length !c-ts.u.cl-resolved)
+ gfc_resolve_expr (c-ts.u.cl-length);
}
}
else if (c-ts.interface-name[0] != '\0' !sym-attr.vtype)
@@ -10805,6 +10813,8 @@
{
sym-ts.u.cl = gfc_new_charlen (sym-ns, ifc-ts.u.cl);
gfc_expr_replace_symbols (sym-ts.u.cl-length, sym);
+ if (sym-ts.u.cl-length !sym-ts.u.cl-resolved)
+ gfc_resolve_expr (sym-ts.u.cl-length);
}
}
else if (sym-ts.interface-name[0] != '\0')
Could you explain what the other stuff is needed for? I currently fail to see
that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227
[Bug fortran/43227] [4.5 Regression] ICE: segmentation fault in mio_expr
--- Comment #3 from janus at gcc dot gnu dot org 2010-04-18 11:09 --- It turns out this problem is not specific to the OOP stuff on fortran-dev, but instead is due to an underlying problem with PROCEDURE statements (which affects procedure pointers as well as PPCs), demonstrated by this test case: module m_string procedure(string_to_char) :: char1! segfault ! procedure(string_to_char),pointer :: char2 ! segfault ! type t_string ! procedure(string_to_char),pointer,nopass :: char3 ! segfault ! end type t_string contains function string_to_char (s) result(res) character, dimension(:), intent(in) :: s character(len=size(s)) :: res end function string_to_char end module m_string All of the three forms of the PROCEDURE statement shown above trigger the same ICE (which is also the same ICE as in comment #0 and #1, due to fortran-dev's usage of PPCs in the implementation of polymorphic TBPs). The above test case segfaults with 4.3, works with 4.4, and then fails again with 4.5, 4.6 and fortran-dev. Therefore this PR is rather a 4.5 regression than a fortran-dev regressions. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2010-04-18 11:09:35 date|| Summary|[fortran-dev Regression]|[4.5 Regression] ICE: |ICE: segmentation fault in |segmentation fault in |mio_expr|mio_expr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227
[Bug fortran/42353] [fortran-dev] Bogus Error: Name 'vtype$...' at (1) is an ambiguous reference ...
--- Comment #26 from janus at gcc dot gnu dot org 2010-04-18 13:13 --- (In reply to comment #25) A provisional fix for this PR Actually, what's the issue here? At rev. 158483 the fortran-dev testsuite runs cleanly on x86_64-unknown-linux-gnu, and the test cases in this PR (gfcbug96.f90, gfcbug96b.f90 and gfcbug96c.f90) all compile without error. Am I missing something? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42353
[Bug fortran/43227] [4.5/4.6 Regression] ICE: segmentation fault in mio_expr
--- Comment #6 from janus at gcc dot gnu dot org 2010-04-18 16:42 --- (In reply to comment #5) What about pr42274? Is it a duplicate or not? I don't think so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227
[Bug fortran/43227] [fortran-dev Regression] ICE: segmentation fault in mio_expr
--- Comment #1 from janus at gcc dot gnu dot org 2010-04-15 21:30 --- Here is a reduced test case, which ICEs with the same backtrace: module m_string type t_string character, dimension(:), allocatable :: string contains procedure :: char = string_to_char end type t_string contains function string_to_char (s) result(res) class(t_string), intent(in) :: s character(len=size(s%string)) :: res end function string_to_char end module m_string -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227
[Bug fortran/43696] [OOP] Bogus error: Passed-object dummy argument must not be POINTER
--- Comment #5 from janus at gcc dot gnu dot org 2010-04-12 09:50 --- (In reply to comment #4) I've tried to isolate the error message from the ICE. The smallest code is a_module for the error and b_module for the ICE. Thanks. However, ... !!$ f951: internal compiler error: in find_typebound_proc_uop, at fortran/symbol.c:4863 this ICE seems to be different from the one in comment #0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43696
[Bug fortran/43696] New: [OOP] Bogus error: Passed-object dummy argument must not be POINTER
Consider the following (supposedly valid) code: MODULE error_stack_module implicit none type,abstract::serializable_class contains procedure(ser_DTV_RF),deferred::read_formatted end type serializable_class abstract interface subroutine ser_DTV_RF(dtv,unit,iotype,v_list,iostat,iomsg) import serializable_class CLASS(serializable_class),INTENT(INOUT) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER (LEN=*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: v_list(:) INTEGER, INTENT(OUT) :: iostat CHARACTER (LEN=*), INTENT(INOUT) :: iomsg end subroutine ser_DTV_RF end interface type,extends(serializable_class)::error_type class(error_type),pointer::next=null() contains procedure::read_formatted=error_read_formatted end type error_type contains recursive subroutine error_read_formatted(dtv,unit,iotype,v_list,iostat,iomsg) CLASS(error_type),INTENT(INOUT) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER (LEN=*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: v_list(:) INTEGER, INTENT(OUT) :: iostat CHARACTER (LEN=*), INTENT(INOUT) :: iomsg character(8),allocatable::type character(8),allocatable::next call basic_read_string(unit,type) call basic_read_string(unit,next) if(next==NEXT)then allocate(dtv%next) call dtv%next%read_formatted(unit,iotype,v_list,iostat,iomsg) end if end subroutine error_read_formatted end MODULE error_stack_module With current trunk, compilation results in: error_stack.f03:25.14: procedure::read_formatted=error_read_formatted 1 Error: Passed-object dummy argument of 'error_read_formatted' at (1) must not be POINTER error_stack.f03:22.46: type,extends(serializable_class)::error_type 1 Error: Derived-type 'error_type' declared at (1) must be ABSTRACT because 'read_formatted' is DEFERRED and not overridden f951: internal compiler error: in resolve_class_esym, at fortran/resolve.c:5255 The first error message is apparently bogus, the second one seems to be a consequence of the first one. The ICE may be a separate issue. -- Summary: [OOP] Bogus error: Passed-object dummy argument must not be POINTER Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43696
[Bug fortran/43696] [OOP] Bogus error: Passed-object dummy argument must not be POINTER
--- Comment #1 from janus at gcc dot gnu dot org 2010-04-08 21:11 --- Forgot to mention: This one was reported by Hans-Werner Boschmann (thanks!). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43696
[Bug fortran/43291] [4.5 regression] [OOP] Type mismatch in argument; passed CLASS(t1) to CLASS(t2)
--- Comment #11 from janus at gcc dot gnu dot org 2010-03-10 20:46 --- (In reply to comment #6) If all appears to be well with the regtest and I do not hear back from you, I will commit the patch to trunk tonight. The patch clobbers dynamic_dispatch_4.f03. Hm, funny. For me the patch from comment #5 survives a full regtest. Ok to commit from my side. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43291
[Bug fortran/43326] New: [OOP] dynamic dispatch with CLASS components
Spin-off from PR 43291 comment #10 ... The following gives the wrong result: module m1 type :: t1 contains procedure :: sizeof end type contains integer function sizeof(a) class(t1) :: a sizeof = 1 end function sizeof end module module m2 use m1 type, extends(t1) :: t2 contains procedure :: sizeof = sizeof2 end type contains integer function sizeof2(a) class(t2) :: a sizeof2 = 2 end function end module module m3 use m2 type :: t3 class(t1), pointer :: a contains procedure :: sizeof = sizeof3 end type contains integer function sizeof3(a) class(t3) :: a sizeof3 = a%a%sizeof() end function end module use m1 use m2 use m3 class(t1), pointer :: a, ptr type(t1), target :: x type(t2), target :: y type(t3) :: z a = x print *, a%sizeof() a = y print *, a%sizeof() z%a = x print *, z%sizeof(), z%a%sizeof() z%a = y print *, z%sizeof(), z%a%sizeof() end gives 1 2 1 1 2 1 The last line should read 2 2 of course. -- Summary: [OOP] dynamic dispatch with CLASS components Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43326
[Bug fortran/43291] [4.5 regression] [OOP] Type mismatch in argument; passed CLASS(t1) to CLASS(t2)
--- Comment #12 from janus at gcc dot gnu dot org 2010-03-10 21:04 --- (In reply to comment #10) In preparing a testcase, I foolishly decided to check the original for correct execution. The following gives the wrong result: I guess this is worth a separate PR. It's PR43326 now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43291
[Bug fortran/43326] [OOP] dynamic dispatch with CLASS components
--- Comment #1 from janus at gcc dot gnu dot org 2010-03-10 22:06 ---
Here is a simple-minded patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 157366)
+++ gcc/fortran/resolve.c (working copy)
@@ -,6 +,8 @@
gfc_resolve_expr (gfc_expr *e)
{
gfc_try t;
+ gfc_typespec ts;
+ gfc_ref *ref = NULL;
if (e == NULL)
return SUCCESS;
@@ -5584,7 +5586,14 @@
break;
case EXPR_COMPCALL:
- if (e-symtree e-symtree-n.sym-ts.type == BT_CLASS)
+ if (e-symtree)
+ ts = e-symtree-n.sym-ts;
+ for (ref = e-ref; ref; ref = ref-next)
+ {
+ if (ref-type == REF_COMPONENT)
+ ts = ref-u.c.component-ts;
+ }
+ if (ts.type == BT_CLASS)
t = resolve_class_compcall (e);
else
t = resolve_compcall (e, true);
This fixes the test case. Haven't tested for regressions yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43326
[Bug fortran/43326] [OOP] dynamic dispatch with CLASS components
--- Comment #2 from janus at gcc dot gnu dot org 2010-03-10 22:50 --- (In reply to comment #1) This fixes the test case. Haven't tested for regressions yet. Regtest was successful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43326
[Bug fortran/43291] [4.5 regression] [OOP] Type mismatch in argument; passed CLASS(t1) to CLASS(t2)
--- Comment #2 from janus at gcc dot gnu dot org 2010-03-09 09:44 --- The problem here is that when resolving a polymorphic TBP call, we resolve the call for each member of the CLASS (i.e. the declared type and all its children, cf. 'resolve_class_compcall'). In 'check_class_members' we set the correct type for the passed object. However, this does not work if the passed object is a component, because the ts we set is overridden when the expr is resolved (e.g. in resolve_actual_arglist). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43291
[Bug fortran/43291] [4.5 regression] [OOP] Type mismatch in argument; passed CLASS(t1) to CLASS(t2)
--- Comment #3 from janus at gcc dot gnu dot org 2010-03-09 09:49 --- (In reply to comment #2) The problem here is that when resolving a polymorphic TBP call, we resolve the call for each member of the CLASS (i.e. the declared type and all its children, cf. 'resolve_class_compcall'). Paul, since you were the one who implemented this: Could you me remind me why this is needed at all? Shouldn't it be enough to resolve the call as is, i.e. just for the base class? Checking the actual arguments for every descendant of the base class seems unnecessary to me. -- janus at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43291
[Bug fortran/43256] [OOP] TBP with missing optional arg
--- Comment #10 from janus at gcc dot gnu dot org 2010-03-08 09:35 --- Subject: Bug 43256 Author: janus Date: Mon Mar 8 09:35:04 2010 New Revision: 157272 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157272 Log: 2010-03-08 Janus Weil ja...@gcc.gnu.org PR fortran/43256 * resolve.c (resolve_compcall): Don't set 'value.function.name' here for TBPs, otherwise they will not be resolved properly. (resolve_function): Use 'value.function.esym' instead of 'value.function.name' to check if we're dealing with a TBP. (check_class_members): Set correct type of passed object for all TBPs, not only generic ones, except if the type is abstract. 2010-03-08 Janus Weil ja...@gcc.gnu.org PR fortran/43256 * gfortran.dg/typebound_call_13.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_call_13.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43256
[Bug fortran/43256] [OOP] TBP with missing optional arg
--- Comment #11 from janus at gcc dot gnu dot org 2010-03-08 09:37 --- Fixed with r157272. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43256
[Bug fortran/42769] ICE in resolve_typebound_procedure
--- Comment #18 from janus at gcc dot gnu dot org 2010-03-08 15:43 --- (In reply to comment #17) At revision 157277, I no longer see the ICE, but a bunch of errors: pr42769.f90:5063.10: res = a%a%csnmi() 1 Error: Type mismatch in argument 'a' at (1); passed CLASS(psb_d_base_sparse_mat) to CLASS(psb_d_coo_sparse_mat) Dominique, thanks for noticing. This is surely due to the patch for PR43256 that I committed today. Note that this only happens for comment #1, but not for comment #8, which still gives the same error as before. I will open a new PR for this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
[Bug fortran/43291] New: [4.5 regression] [OOP] Type mismatch in argument; passed CLASS(t1) to CLASS(t2)
This is a spin-off from PR42769 comment #17. The test case has been extracted from comment #1 in that PR. It was working before r157272 (which fixed PR43256), but fails now: module m1 type :: t1 contains procedure :: sizeof end type contains integer function sizeof(a) class(t1) :: a end function sizeof end module module m2 use m1 type, extends(t1) :: t2 contains procedure :: sizeof = sizeof2 end type contains integer function sizeof2(a) class(t2) :: a end function end module module m3 use m2 type :: t3 class(t1), allocatable :: a contains procedure :: sizeof = sizeof3 end type contains integer function sizeof3(a) class(t3) :: a sizeof3 = a%a%sizeof() end function end module sizeof3 = a%a%sizeof() 1 Error: Type mismatch in argument 'a' at (1); passed CLASS(t1) to CLASS(t2) -- Summary: [4.5 regression] [OOP] Type mismatch in argument; passed CLASS(t1) to CLASS(t2) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43291
[Bug fortran/42769] ICE in resolve_typebound_procedure
--- Comment #20 from janus at gcc dot gnu dot org 2010-03-08 15:50 --- (In reply to comment #18) I will open a new PR for this. This is now PR 43291. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
[Bug fortran/43256] [OOP] TBP with missing optional arg
--- Comment #8 from janus at gcc dot gnu dot org 2010-03-07 14:07 ---
(In reply to comment #7)
This leaves us with the following regressions:
FAIL: gfortran.dg/dynamic_dispatch_1.f03 -O0 (test for excess errors)
FAIL: gfortran.dg/dynamic_dispatch_3.f03 -O0 (test for excess errors)
FAIL: gfortran.dg/dynamic_dispatch_4.f03 -O0 (test for excess errors)
FAIL: gfortran.dg/dynamic_dispatch_6.f03 -O0 (test for excess errors)
due to the error
Error: Type mismatch in argument '...' at (1); passed CLASS(...) to CLASS(...)
These are resolved when adding to the patches in comment #3 and #7 the
following one:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 157262)
+++ gcc/fortran/resolve.c (working copy)
@@ -5178,18 +5178,17 @@ check_class_members (gfc_symbol *derived)
return;
}
- if (tbp-n.tb-is_generic)
+ /* If we have to match a passed class member, force the actual
+ expression to have the correct type. */
+ if (!tbp-n.tb-nopass)
{
- /* If we have to match a passed class member, force the actual
-expression to have the correct type. */
- if (!tbp-n.tb-nopass)
- {
- if (e-value.compcall.base_object == NULL)
- e-value.compcall.base_object =
- extract_compcall_passed_object (e);
+ if (e-value.compcall.base_object == NULL)
+ e-value.compcall.base_object = extract_compcall_passed_object (e);
- e-value.compcall.base_object-ts.type = BT_DERIVED;
- e-value.compcall.base_object-ts.u.derived = derived;
+ if (!derived-attr.abstract)
+ {
+ e-value.compcall.base_object-ts.type = BT_DERIVED;
+ e-value.compcall.base_object-ts.u.derived = derived;
}
}
I hope that's it now. I'll do another regtest to make sure ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43256
[Bug fortran/43256] [OOP] TBP with missing optional arg
--- Comment #6 from janus at gcc dot gnu dot org 2010-03-05 09:36 --- (In reply to comment #5) All of these throw error messages like ABSTRACT INTERFACE '...' must not be referenced at (1) This was PR41873 and was fixed by querying expr-value.function.name, which fails now. We should find a better way to silence this error message for polymorphic calls. Type mismatch in argument '...' at (1); passed CLASS(...) to CLASS(...) This one is a bit more tricky, but understandable. It is not a problem of the one-line patch shown above, but of the implementation of polymorphic calls: When doing a polymorphic call with 'dynamic type /= declared type' of the passed object and an overridden TBP, we have to convert the passed object to a CLASS of the dynamic type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43256
[Bug fortran/43256] [OOP] TBP with missing optional arg
--- Comment #7 from janus at gcc dot gnu dot org 2010-03-05 09:56 ---
(In reply to comment #6)
ABSTRACT INTERFACE '...' must not be referenced at (1)
This was PR41873 and was fixed by querying expr-value.function.name, which
fails now. We should find a better way to silence this error message for
polymorphic calls.
To solve this I propose the following:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 157233)
+++ gcc/fortran/resolve.c (working copy)
@@ -2556,8 +2556,8 @@ resolve_function (gfc_expr *expr)
}
/* If this ia a deferred TBP with an abstract interface (which may
- of course be referenced), expr-value.function.name will be set. */
- if (sym sym-attr.abstract !expr-value.function.name)
+ of course be referenced), expr-value.function.esym will be set. */
+ if (sym sym-attr.abstract !expr-value.function.esym)
{
gfc_error (ABSTRACT INTERFACE '%s' must not be referenced at %L,
sym-name, expr-where);
This leaves us with the following regressions:
FAIL: gfortran.dg/dynamic_dispatch_1.f03 -O0 (test for excess errors)
FAIL: gfortran.dg/dynamic_dispatch_3.f03 -O0 (test for excess errors)
FAIL: gfortran.dg/dynamic_dispatch_4.f03 -O0 (test for excess errors)
FAIL: gfortran.dg/dynamic_dispatch_6.f03 -O0 (test for excess errors)
due to the error
Error: Type mismatch in argument '...' at (1); passed CLASS(...) to CLASS(...)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43256
[Bug fortran/43244] Invalid statement misinterpreted as FINAL declaration
--- Comment #7 from janus at gcc dot gnu dot org 2010-03-04 09:17 ---
(In reply to comment #6)
Without looking at the code yet, the matcher must see a space or double colon
after the word FINAL before matching it. If it sees anything else, its a
MATCH_NO not a MATCH_ERROR. If this is being done then the syntax error in
the
array qualifiers may/should kick in.
Yes, that's exactly what my patch in comment #5 does.
Syntax for FINAL is :
FINAL [ :: ] final-subroutine-name-list
So I think your patch is OK for MATCH_NO but a MATCH_YES must see :: as well.
No, to get a MATCH_YES we don't have to see :: since it's optional. Anyway,
matching the rest of the statement is handled correctly further down in
gfc_match_final_decl. The purpose of this patch is simply to reject the FINAL
statement with a MATCH_NO before we throw an error.
Free or Fixed form is irrelevant. Fixed form may allow things like F I N AL
but it still must have :: (or : whitespace :) to match.
Ok, then the patch may look like this:
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 157215)
+++ gcc/fortran/decl.c (working copy)
@@ -7803,13 +7803,17 @@ error:
match
gfc_match_final_decl (void)
{
- char name[GFC_MAX_SYMBOL_LEN + 1];
+ char name[GFC_MAX_SYMBOL_LEN + 1],c;
gfc_symbol* sym;
match m;
gfc_namespace* module_ns;
bool first, last;
gfc_symbol* block;
+ c = gfc_peek_ascii_char ();
+ if (!gfc_is_whitespace (c) c != ':')
+return MATCH_NO;
+
if (gfc_state_stack-state != COMP_DERIVED_CONTAINS)
{
gfc_error (FINAL declaration at %C must be inside a derived type
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43244
[Bug fortran/43244] Invalid statement misinterpreted as FINAL declaration
--- Comment #10 from janus at gcc dot gnu dot org 2010-03-04 10:35 --- (In reply to comment #9) From: F2003, 3.3.2 Fixed source form: Except in a character context, blanks are insignificant and may be used freely throughout the program. I guess this is what triggered the famous quote Consistently separating words by spaces became a general custom about the tenth century A. D., and lasted until about 1957, when FORTRAN abandoned the practice. To me the code in comment #8 looks completely insane and unreadable, but if some crazy standards document says it's legal, then so be it :) One possibility is simply to return MATCH_NO for fixed form code if one is not in COMP_DERIVED_CONTAINS and do the space/colon check for free-form code. For me it would also be fine to just use the patch in comment #5 and simply ignore the issue in fixed form. I wouldn't expect anyone to use F03 FINAL statements in F77 fixed source form anyways. [Anyone progressive enough to even *think* about FINAL statements would probably have abandoned fixed form long before producing such thoughts.] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43244
[Bug fortran/43244] Invalid statement misinterpreted as FINAL declaration
--- Comment #12 from janus at gcc dot gnu dot org 2010-03-04 12:06 ---
(In reply to comment #11)
I think it dates back to punch cards;
Yes, I've seen those. However, being born too late, I never had the chance to
use them :)
I wouldn't expect anyone to use F03 FINAL statements in F77 fixed source
form anyways.
I do not agree.
Ok then, let's just do this:
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 157216)
+++ gcc/fortran/decl.c (working copy)
@@ -7810,8 +7810,17 @@ gfc_match_final_decl (void)
bool first, last;
gfc_symbol* block;
+ if (gfc_current_form == FORM_FREE)
+{
+ char c = gfc_peek_ascii_char ();
+ if (!gfc_is_whitespace (c) c != ':')
+ return MATCH_NO;
+}
+
if (gfc_state_stack-state != COMP_DERIVED_CONTAINS)
{
+ if (gfc_current_form == FORM_FIXED)
+ return MATCH_NO;
gfc_error (FINAL declaration at %C must be inside a derived type
CONTAINS section);
return MATCH_ERROR;
Ok to commit (after a regtest and with the test case from comment #0)?
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-03-04 12:06:50
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43244
[Bug fortran/43244] Invalid statement misinterpreted as FINAL declaration
--- Comment #14 from janus at gcc dot gnu dot org 2010-03-04 13:42 --- Subject: Bug 43244 Author: janus Date: Thu Mar 4 13:42:06 2010 New Revision: 157226 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157226 Log: 2010-03-04 Janus Weil ja...@gcc.gnu.org PR fortran/43244 * decl.c (gfc_match_final_decl): Make sure variable names starting with 'final...' are not misinterpreted as FINAL statements. 2010-03-04 Janus Weil ja...@gcc.gnu.org PR fortran/43244 * gfortran.dg/finalize_9.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/finalize_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43244
[Bug fortran/43244] Invalid statement misinterpreted as FINAL declaration
--- Comment #15 from janus at gcc dot gnu dot org 2010-03-04 13:58 --- Fixed with r157226. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43244
[Bug fortran/43256] New: [OOP] character-valued TBP with missing optional arg
Consider the following code: module module_myobj implicit none type :: myobj contains procedure :: myfunc end type contains function myfunc(this, status) class(myobj), intent(in) :: this integer, intent(out), optional :: status character(len=80) :: myfunc if (present(status)) then write (*,*) 'myfunc: status is present.' else write (*,*) 'myfunc: status is not present.' end if myfunc = ' ' end function end module program test_optional use :: module_myobj implicit none character(len=80) :: res integer :: status type(myobj) :: myinstance res = myfunc(myinstance) ! OK res = myfunc(myinstance, status) ! OK res = myinstance%myfunc()! FAILED res = myinstance%myfunc(status) ! OK end program This currently produces the output: myfunc: status is not present. myfunc: status is present. myfunc: status is present. myfunc: status is present. The correct output would be: myfunc: status is not present. myfunc: status is present. myfunc: status is not present. myfunc: status is present. Apparently this only happens for type-bound character-valued functions (but not for subroutines or e.g. integer-valued functions). -fdump-tree-original shows the following for the four calls to 'myfunc': myfunc ((character(kind=1)[1:80] *) str.3, 80, class.2, 0B); myfunc ((character(kind=1)[1:80] *) str.5, 80, class.4, status); myfunc ((character(kind=1)[1:80] *) str.7, 80, class.6); myfunc ((character(kind=1)[1:80] *) str.9, 80, class.8, status); In the third case we fail to pass a null pointer for the missing optional arg. -- Summary: [OOP] character-valued TBP with missing optional arg Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43256
[Bug fortran/43256] [OOP] character-valued TBP with missing optional arg
--- Comment #1 from janus at gcc dot gnu dot org 2010-03-04 16:04 --- (In reply to comment #0) Apparently this only happens for type-bound character-valued functions (but not for subroutines or e.g. integer-valued functions). Actually that is wrong. It does work with subroutines, but it fails with all sorts of functions, also integer-valued ones, and with NOPASS: module module_myobj implicit none type :: myobj contains procedure, nopass :: myfunc end type contains integer function myfunc(status) integer, optional :: status if (present(status)) then write (*,*) 'myfunc: status is present.' else write (*,*) 'myfunc: status is not present.' end if myfunc = 1 end function end module program test_optional use :: module_myobj implicit none integer :: res,status type(myobj) :: myinstance res = myfunc() ! OK res = myfunc(status) ! OK res = myinstance%myfunc()! FAILED res = myinstance%myfunc(status) ! OK end program For checking if it works, one should not only look at the output of the program, since this could be correct by chance. Instead, one should look at the dump, to see if a zero is passed for the missing optional arg. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43256
[Bug fortran/43256] [OOP] TBP with missing optional arg
--- Comment #2 from janus at gcc dot gnu dot org 2010-03-04 16:11 --- Btw, I just checked an analogous example with a procedure pointer component instead of a type-bound procedure, and this works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43256
[Bug fortran/43256] [OOP] TBP with missing optional arg
--- Comment #3 from janus at gcc dot gnu dot org 2010-03-04 21:14 --- Ok, think I got it. It's a one-liner: Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c (revision 157225) +++ gcc/fortran/resolve.c (working copy) @@ -5124,7 +5124,7 @@ resolve_compcall (gfc_expr* e, bool fcn) return FAILURE; e-value.function.actual = newactual; - e-value.function.name = e-value.compcall.name; + e-value.function.name = NULL; e-value.function.esym = target-n.sym; e-value.function.class_esym = NULL; e-value.function.isym = NULL; Hope this produces no regressions. [Explanation: The problem was that 'compare_actual_formal', which sets up the null pointer for the missing actual arg, was never called for the TBP call. Due to e-value.function.name being set already, 'resolve_function' always assumed the function call had already been resolved, although it was never done.] -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-04 21:14:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43256
[Bug fortran/43256] [OOP] TBP with missing optional arg
--- Comment #4 from janus at gcc dot gnu dot org 2010-03-04 22:10 --- (In reply to comment #3) Hope this produces no regressions. Unfortunately it does :( FAIL: gfortran.dg/dynamic_dispatch_1.f03 -O0 (test for excess errors) FAIL: gfortran.dg/dynamic_dispatch_3.f03 -O0 (test for excess errors) FAIL: gfortran.dg/dynamic_dispatch_4.f03 -O0 (test for excess errors) FAIL: gfortran.dg/dynamic_dispatch_6.f03 -O0 (test for excess errors) FAIL: gfortran.dg/class_12.f03 -O (test for excess errors) FAIL: gfortran.dg/interface_abstract_4.f90 -O (test for excess errors) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43256
[Bug fortran/43256] [OOP] TBP with missing optional arg
--- Comment #5 from janus at gcc dot gnu dot org 2010-03-04 22:44 --- (In reply to comment #4) FAIL: gfortran.dg/dynamic_dispatch_1.f03 -O0 (test for excess errors) FAIL: gfortran.dg/dynamic_dispatch_3.f03 -O0 (test for excess errors) FAIL: gfortran.dg/dynamic_dispatch_4.f03 -O0 (test for excess errors) FAIL: gfortran.dg/dynamic_dispatch_6.f03 -O0 (test for excess errors) FAIL: gfortran.dg/class_12.f03 -O (test for excess errors) FAIL: gfortran.dg/interface_abstract_4.f90 -O (test for excess errors) All of these throw error messages like ABSTRACT INTERFACE '...' must not be referenced at (1) or Type mismatch in argument '...' at (1); passed CLASS(...) to CLASS(...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43256
[Bug fortran/43244] New: statement misinterpreted as FINAL declaration
I just encountered a rather strange bug in gfortran. Consider the following code: implicit none type particle integer :: ID end type type(particle), dimension(1,1:3) :: finalState finalstate(1,(/1:2/))%ID = (/1,103/) end This is compiled fine with ifort and pgf95, but gfortran 4.5 trunk says: finalstate(1,(/1:2/))%ID = (/1,103/) 1 Error: FINAL declaration at (1) must be inside a derived type CONTAINS section This is very funny. Seems like the first part of the variable name is interpreted as a FINAL declaration. We should at least make sure the FINAL keyword is separated by spaces when parsing stuff like this. This error message appears on trunk and 4.4. Btw gfortran 4.3 and g95 say: finalstate(1,(/1:2/))%ID = (/1,103/) 1 Error: Syntax error in array constructor at (1) And sunf95's opinion is: finalstate(1,(/1:2/))%ID = (/1,103/) ^ test.f90, Line = 7, Column = 17: ERROR: Unexpected syntax: /) was expected but found :. With so many compilers rejecting it, I wonder: Is it actually legal? -- Summary: statement misinterpreted as FINAL declaration Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43244
[Bug fortran/43244] statement misinterpreted as FINAL declaration
--- Comment #1 from janus at gcc dot gnu dot org 2010-03-03 09:49 --- IIRC the parsing of FINAL declarations was implemented by Daniel Kraft. It was committed as r136293. Daniel, could you have a look at this bug? -- janus at gcc dot gnu dot org changed: What|Removed |Added CC||d at domob dot eu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43244
[Bug fortran/43244] statement misinterpreted as FINAL declaration
--- Comment #2 from janus at gcc dot gnu dot org 2010-03-03 09:54 --- (In reply to comment #0) With so many compilers rejecting it, I wonder: Is it actually legal? I guess not. Changing the line in question to finalstate(1,1:2)%ID = (/1,103/) makes all compilers accept it (including gfortran trunk and 4.4). -- janus at gcc dot gnu dot org changed: What|Removed |Added Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43244
[Bug fortran/43169] [OOP] gfortran rejects pure procedure with select type construct
--- Comment #10 from janus at gcc dot gnu dot org 2010-03-03 15:13 --- Subject: Bug 43169 Author: janus Date: Wed Mar 3 15:12:40 2010 New Revision: 157196 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157196 Log: 2010-03-03 Janus Weil ja...@gcc.gnu.org PR fortran/43169 * resolve.c (resolve_code): Correctly set gfc_current_ns for EXEC_SELECT_TYPE. (gfc_impure_variable): Make it work with sub-namespaces (BLOCK etc). (gfc_pure): Ditto. 2010-03-03 Janus Weil ja...@gcc.gnu.org PR fortran/43169 * gfortran.dg/impure_assignment_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/impure_assignment_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43169
[Bug fortran/43169] [OOP] gfortran rejects pure procedure with select type construct
--- Comment #11 from janus at gcc dot gnu dot org 2010-03-03 15:17 --- Fixed with r157196. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43169
[Bug fortran/43244] Invalid statement misinterpreted as FINAL declaration
--- Comment #5 from janus at gcc dot gnu dot org 2010-03-03 15:40 ---
Quick fix for free form:
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 157195)
+++ gcc/fortran/decl.c (working copy)
@@ -7810,6 +7810,13 @@
bool first, last;
gfc_symbol* block;
+ if (gfc_current_form == FORM_FREE)
+{
+ char c = gfc_peek_ascii_char ();
+ if (!gfc_is_whitespace (c) c != ':')
+ return MATCH_NO;
+}
+
if (gfc_state_stack-state != COMP_DERIVED_CONTAINS)
{
gfc_error (FINAL declaration at %C must be inside a derived type
Would this also be acceptable for fixed form?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43244
[Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument
--- Comment #6 from janus at gcc dot gnu dot org 2010-03-02 23:31 --- Here is another very similar example: implicit none type :: lorenz end type lorenz type(lorenz) :: attractor print *,output(attractor) contains function output(this) result(coordinates) class(lorenz), intent(in) :: this real, dimension(:), allocatable :: coordinates end function output end main.f90: In function MAIN__: main.f90:13:0: internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:548 This has been extracted from the code found in http://dx.doi.org/10.1145/1644001.1644004. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051
[Bug fortran/43169] [OOP] gfortran rejects pure procedure with select type construct
--- Comment #9 from janus at gcc dot gnu dot org 2010-03-01 12:47 --- Even with the patch from comment #7, another thing goes wrong with BLOCK statements: pure subroutine swap implicit none real :: r1 block real :: r2 r1 = 42. r2 = 43. end block end subroutine r1 = 42. 1 Error: Cannot assign to variable 'r1' in PURE procedure at (1) This is rejected although it is valid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43169
[Bug fortran/43169] [OOP] gfortran rejects pure procedure with select type construct
--- Comment #1 from janus at gcc dot gnu dot org 2010-02-25 08:38 --- Confirmed. Here is a reduced test case: pure subroutine swap(x) implicit none type :: myType real :: a end type myType class(myType), intent(inout) :: x select type(x) class is (myType) x%a = 42. end select end subroutine Thanks for the report! -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-25 08:38:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43169
[Bug fortran/43169] [OOP] gfortran rejects pure procedure with select type construct
--- Comment #2 from janus at gcc dot gnu dot org 2010-02-25 09:08 --- The problem lies in gfc_impure_variable (resolve.c), where it is checked if the namespace of the variable equals the local namespace of the pure procedure. This check fails if the procedure has sub-namespaces. We have sub-namespaces e.g. in the following cases: 1) BLOCK 2) SELECT TYPE 3) contained procedures 4) ...? Comment #0 shows the failure for case (2), but the others may also be affected. I'll check this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43169
[Bug fortran/43169] [OOP] gfortran rejects pure procedure with select type construct
--- Comment #3 from janus at gcc dot gnu dot org 2010-02-25 09:13 --- Regarding BLOCK, it seems there is an additional problem: Assignments inside a BLOCK are not checked at all, as the following case shows ... implicit none real :: glob contains pure subroutine swap implicit none real :: r1 r1 = 42. block real :: r2 r2 = 43. glob = 0. end block end subroutine end The assignment to 'glob' is clearly invalid, but is not being caught. 'gfc_impure_variable' is only called for 'r1', the other two are left unchecked. Seems like statements inside a BLOCK are not being resolved at all?!? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43169
[Bug fortran/43169] [OOP] gfortran rejects pure procedure with select type construct
--- Comment #4 from janus at gcc dot gnu dot org 2010-02-25 09:19 --- Contained procedures are not affected by this bug, since a procedure contained in a pure procedure must itself be pure. Therefore something like this is invalid (as gfortran correctly detects): module m implicit none contains pure subroutine swap implicit none real :: r1 contains pure subroutine cont real :: r2 r1 = 42. r2 = 43. end subroutine end subroutine end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43169
[Bug fortran/43169] [OOP] gfortran rejects pure procedure with select type construct
--- Comment #5 from janus at gcc dot gnu dot org 2010-02-25 12:16 --- (In reply to comment #3) Seems like statements inside a BLOCK are not being resolved at all?!? Sorry, this is wrong. They are resolved alright. The problem is just that 'gfc_pure' does not work (checking if we're inside a pure function). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43169
[Bug fortran/43169] [OOP] gfortran rejects pure procedure with select type construct
--- Comment #6 from janus at gcc dot gnu dot org 2010-02-25 12:54 --- (In reply to comment #2) The problem lies in gfc_impure_variable (resolve.c), where it is checked if the namespace of the variable equals the local namespace of the pure procedure. This check fails if the procedure has sub-namespaces. Actually it seems that 'gfc_impure_variable' works fine, but for SELECT TYPE the 'gfc_current_ns' is not set correctly. Setting the namespace happens in 'resolve_codes', but the pureness check happens inside 'gfc_resolve_blocks'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43169
[Bug fortran/43169] [OOP] gfortran rejects pure procedure with select type construct
--- Comment #7 from janus at gcc dot gnu dot org 2010-02-25 13:40 ---
(In reply to comment #5)
(In reply to comment #3)
Seems like statements inside a BLOCK are not being resolved at all?!?
Sorry, this is wrong. They are resolved alright. The problem is just that
'gfc_pure' does not work (checking if we're inside a pure function).
The BLOCK issue in comment #3 is fixed by the following patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 157055)
+++ gcc/fortran/resolve.c (working copy)
@@ -11689,18 +11695,30 @@ gfc_impure_variable (gfc_symbol *sym)
}
-/* Test whether a symbol is pure or not. For a NULL pointer, checks the
- symbol of the current procedure. */
+/* Test whether a symbol is pure or not. For a NULL pointer, checks if the
+ current namespace is inside a pure procedure. */
int
gfc_pure (gfc_symbol *sym)
{
symbol_attribute attr;
+ gfc_namespace *ns;
if (sym == NULL)
-sym = gfc_current_ns-proc_name;
- if (sym == NULL)
-return 0;
+{
+ /* Check if the current namespace or one of its parents
+belongs to a pure procedure. */
+ for (ns = gfc_current_ns; ns; ns = ns-parent)
+ {
+ sym = ns-proc_name;
+ if (sym == NULL)
+ return 0;
+ attr = sym-attr;
+ if (attr.flavor == FL_PROCEDURE (attr.pure || attr.elemental))
+ return 1;
+ }
+ return 0;
+}
attr = sym-attr;
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2010-02-25 08:38:03 |2010-02-25 13:40:15
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43169
[Bug fortran/42888] [4.5 Regression] ICE in fold_convert_loc, at fold-const.c:2670
--- Comment #21 from janus at gcc dot gnu dot org 2010-01-31 21:56 --- Subject: Bug 42888 Author: janus Date: Sun Jan 31 21:56:02 2010 New Revision: 156418 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156418 Log: gcc/fortran/ 2010-01-31 Janus Weil ja...@gcc.gnu.org PR fortran/42888 * resolve.c (resolve_allocate_expr): Move default initialization code here from gfc_trans_allocate. * trans.c (gfc_trans_code): Call gfc_trans_class_assign also for EXEC_INIT_ASSIGN. * trans-expr.c (gfc_trans_class_assign): Handle default initialization of CLASS variables via memcpy. * trans-stmt.c (gfc_trans_allocate): Move default initialization code to resolve_allocate_expr. gcc/testsuite/ 2010-01-31 Janus Weil ja...@gcc.gnu.org PR fortran/42888 * gfortran.dg/allocate_derived_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/allocate_derived_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42888
[Bug fortran/42888] [4.5 Regression] ICE in fold_convert_loc, at fold-const.c:2670
--- Comment #22 from janus at gcc dot gnu dot org 2010-01-31 22:01 --- Fixed with r156418. Thanks for the report! -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42888
[Bug fortran/42888] [4.5 Regression] ICE in fold_convert_loc, at fold-const.c:2670
--- Comment #19 from janus at gcc dot gnu dot org 2010-01-30 10:29 --- (In reply to comment #17) There is another problem left with the patch. I am not sure whether the code is legal, but it gives an ICE for me: implicit none type t integer :: X = -999.0 ! Real initializer! end type t class(t), allocatable :: x class(t), allocatable :: y(:) allocate (t::x) allocate (t::y(1)) ! ICE end gfcbug103a.f90: In function MAIN__: gfcbug103a.f90:8:0: internal compiler error: Segmentation fault Yes, it is legal. And the ICE is kind of expected right now, since CLASS arrays are not really supported yet (cf. PR42539, PR41600, PR41951; the second one contains a similar ALLOCATE statement). Implementing CLASS array support requires an array descriptor update, so it is 4.6 stuff. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42888
