[Bug fortran/45438] [4.6 Regression] [OOP] ICE with -fcheck=pointer
--- Comment #3 from janus at gcc dot gnu dot org 2010-09-20 16:29 --- Here is a reduced test case: module base_mat_mod type :: base_sparse_mat contains procedure :: get_fmt end type contains function get_fmt(a) result(res) implicit none class(base_sparse_mat), intent(in) :: a character(len=5) :: res res = 'NULL' end function subroutine errlog(name) character(len=*) :: name end subroutine subroutine test (a) implicit none class(base_sparse_mat), intent(in) :: a call errlog(a%get_fmt()) end subroutine end module -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45438
[Bug fortran/45438] [4.6 Regression] [OOP] ICE with -fcheck=pointer
--- Comment #4 from janus at gcc dot gnu dot org 2010-09-20 17:41 --- Mine (have a patch). -- 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-08-28 10:27:07 |2010-09-20 17:41:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45438
[Bug fortran/45438] [4.6 Regression] [OOP] ICE with -fcheck=pointer
--- Comment #5 from janus at gcc dot gnu dot org 2010-09-20 21:43 --- Subject: Bug 45438 Author: janus Date: Mon Sep 20 21:42:54 2010 New Revision: 164462 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164462 Log: 2010-09-20 Janus Weil ja...@gcc.gnu.org PR fortran/45438 * trans-expr.c (gfc_conv_procedure_call): Fix pointer checking for TBPs, PPCs and pointer/allocatable components. 2010-09-20 Janus Weil ja...@gcc.gnu.org PR fortran/45438 * gfortran.dg/pointer_check_7.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/pointer_check_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45438
[Bug fortran/45438] [4.6 Regression] [OOP] ICE with -fcheck=pointer
--- Comment #6 from janus at gcc dot gnu dot org 2010-09-20 21:44 --- Fixed with r164462. 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=45438
[Bug fortran/45674] [OOP] Undefined references for extended types
--- Comment #5 from janus at gcc dot gnu dot org 2010-09-16 12:10 --- (In reply to comment #3) Thanks for the quick fix! Well, it was *your* fix, so *I* should thank *you* :) Anyway, I think the patch in comment #2 qualifies as obvious, and has no regressions, as noted by Dominique. Will commit soon. -- 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-09-15 13:57:41 |2010-09-16 12:10:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45674
[Bug fortran/45674] [OOP] Undefined references for extended types
--- Comment #6 from janus at gcc dot gnu dot org 2010-09-16 13:13 --- Subject: Bug 45674 Author: janus Date: Thu Sep 16 13:12:59 2010 New Revision: 164338 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164338 Log: 2010-09-16 Janus Weil ja...@gcc.gnu.org PR fortran/45674 * interface.c (compare_parameter): Create vtab for actual argument, instead of formal (if needed). 2010-09-16 Janus Weil ja...@gcc.gnu.org PR fortran/45674 * gfortran.dg/class_dummy_2.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/class_dummy_2.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45674
[Bug fortran/45674] [OOP] Undefined references for extended types
--- Comment #7 from janus at gcc dot gnu dot org 2010-09-16 13:14 --- Fixed with r164338. Closing. 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=45674
[Bug fortran/45577] [4.6 Regression] Bogus(?) ... type incompatible with source-expr ... error
--- Comment #9 from janus at gcc dot gnu dot org 2010-09-15 13:50 --- Subject: Bug 45577 Author: janus Date: Wed Sep 15 13:50:15 2010 New Revision: 164305 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164305 Log: 2010-09-15 Janus Weil ja...@gcc.gnu.org PR fortran/45577 * resolve.c (resolve_allocate_expr): Do default initialization via EXEC_INIT_ASSIGN. 2010-09-15 Janus Weil ja...@gcc.gnu.org PR fortran/45577 * gfortran.dg/allocate_derived_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/allocate_derived_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45577
[Bug fortran/45577] [4.6 Regression] Bogus(?) ... type incompatible with source-expr ... error
--- Comment #10 from janus at gcc dot gnu dot org 2010-09-15 13:52 --- Fixed with r164305. 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=45577
[Bug fortran/45674] [OOP] Undefined references for extended types
--- Comment #1 from janus at gcc dot gnu dot org 2010-09-15 13:57 --- Confirmed. From a quick glimpse it seems the patch goes in the right direction. Will have a closer look soon. -- 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-09-15 13:57:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45674
[Bug fortran/45674] [OOP] Undefined references for extended types
--- Comment #2 from janus at gcc dot gnu dot org 2010-09-15 14:46 ---
(In reply to comment #0)
Index: fortran/interface.c
===
--- fortran/interface.c (revision 164288)
+++ fortran/interface.c (working copy)
@@ -1428,10 +1428,12 @@
actual-ts.u.derived actual-ts.u.derived-ts.is_iso_c)
return 1;
- if (formal-ts.type == BT_CLASS)
+ if (formal-ts.type == BT_CLASS) {
/* Make sure the vtab symbol is present when
the module variables are generated. */
gfc_find_derived_vtab (formal-ts.u.derived);
+gfc_find_derived_vtab (actual-ts.u.derived);
+ }
if (actual-ts.type == BT_PROCEDURE)
{
Actually I think this patch is ok. Are you interested in committing it
yourself? [Note that you'll need an FSF copyright assignment, if you don't
already have one.] Otherwise I can commit it for you.
Side note: One can (should) extend the patch in the following way ...
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (revision 164304)
+++ gcc/fortran/interface.c (working copy)
@@ -1428,10 +1428,10 @@ compare_parameter (gfc_symbol *formal, gfc_expr *a
actual-ts.u.derived actual-ts.u.derived-ts.is_iso_c)
return 1;
- if (formal-ts.type == BT_CLASS)
+ if (formal-ts.type == BT_CLASS actual-ts.type == BT_DERIVED)
/* Make sure the vtab symbol is present when
the module variables are generated. */
-gfc_find_derived_vtab (formal-ts.u.derived);
+gfc_find_derived_vtab (actual-ts.u.derived);
if (actual-ts.type == BT_PROCEDURE)
{
(I have not regtested this yet.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45674
[Bug fortran/45592] [F03] Valid structure constructor rejected for extended types
--- Comment #1 from janus at gcc dot gnu dot org 2010-09-08 09:49 --- This problem is apparently related to type extension (but not to abstract types). The following still fails: implicit none type :: pointGen end type pointGen type, extends(pointGen) :: point2d real :: x,y end type type(point2d) :: myPoint myPoint = point2d(2.3, 4.2)! The problem is here myPoint = point2d(x=2.3,y=4.2) ! ok with that end It works when removing the EXTENDS clause. -- 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-09-08 09:49:09 date|| Summary|[OOP] Valid structure |[F03] Valid structure |constructor rejected|constructor rejected for ||extended types http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45592
[Bug fortran/45577] [4.6 Regression] Bogus(?) ... type incompatible with source-expr ... error
--- Comment #2 from janus at gcc dot gnu dot org 2010-09-07 10:26 --- (In reply to comment #1) Hi Janus. I wonder whether it could be due to the fix PR fortran/45507; could you have a look? Yes. This seems to be the same problem reported by Salvatore (cf. http://gcc.gnu.org/ml/fortran/2010-09/msg00148.html and follow-ups). I posted a patch at http://gcc.gnu.org/ml/fortran/2010-09/msg00176.html. -- 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-09-07 10:26:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45577
[Bug fortran/45577] [4.6 Regression] Bogus(?) ... type incompatible with source-expr ... error
--- Comment #4 from janus at gcc dot gnu dot org 2010-09-07 22:13 --- (In reply to comment #3) I posted a patch at http://gcc.gnu.org/ml/fortran/2010-09/msg00176.html. The patch fixes this pr. Well, unfortunately the patch does not really fix the problem, but only defers it. The test case still fails when adding a component with default initialization, e.g.: type b_obj integer,allocatable :: c(:) real :: r = 5. end type b_obj -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45577
[Bug fortran/45577] [4.6 Regression] Bogus(?) ... type incompatible with source-expr ... error
--- Comment #5 from janus at gcc dot gnu dot org 2010-09-07 22:34 ---
Here is a better patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 163946)
+++ gcc/fortran/resolve.c (working copy)
@@ -6727,10 +6727,16 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code
if (ts.type == BT_CLASS)
ts = ts.u.derived-components-ts;
- if (ts.type == BT_DERIVED)
+ if (ts.type == BT_DERIVED gfc_has_default_initializer(ts.u.derived))
{
- code-expr3 = gfc_default_initializer (ts);
- gfc_resolve_expr (code-expr3);
+ gfc_expr *init_e = gfc_default_initializer (ts);
+ gfc_code *init_st = gfc_get_code ();
+ init_st-loc = code-loc;
+ init_st-op = EXEC_INIT_ASSIGN;
+ init_st-expr1 = gfc_expr_to_initialize (e);
+ init_st-expr2 = init_e;
+ init_st-next = code-next;
+ code-next = init_st;
}
}
else if (code-expr3-mold code-expr3-ts.type == BT_DERIVED)
--
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-09-07 10:26:48 |2010-09-07 22:34:36
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45577
[Bug fortran/45507] [4.6 Regression] Bogus Error: Can't convert TYPE(c_ptr) to INTEGER(4)
--- Comment #5 from janus at gcc dot gnu dot org 2010-09-04 09:29 --- Subject: Bug 45507 Author: janus Date: Sat Sep 4 09:29:11 2010 New Revision: 163856 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163856 Log: 2010-09-04 Janus Weil ja...@gcc.gnu.org PR fortran/45507 * resolve.c (resolve_allocate_expr): Generate default initializers already at this point, resolve them and put them into expr3, ... * trans-stmt.c (gfc_trans_allocate): ... instead of waiting until translation stage. 2010-09-04 Janus Weil ja...@gcc.gnu.org PR fortran/45507 * gfortran.dg/allocate_alloc_opt_12.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/allocate_alloc_opt_12.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45507
[Bug fortran/45507] [4.6 Regression] Bogus Error: Can't convert TYPE(c_ptr) to INTEGER(4)
--- Comment #6 from janus at gcc dot gnu dot org 2010-09-04 09:31 --- Fixed with r163856. 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=45507
[Bug fortran/45516] New: [F08] allocatable compontents of recursive type
John Reid, The new features of Fortran 2008, chapter 5.3: A recursive type is permitted to be based on allocatable components. Here is a simple example of a type that holds a stack: type entry real :: value integer :: index type(entry), allocatable :: next end type entry [...] For this gfortran currently gives: type(entry), allocatable :: next 1 Error: Component at (1) must have the POINTER attribute -- Summary: [F08] allocatable compontents of recursive type 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 OtherBugsDependingO 39627 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45516
[Bug fortran/45516] [F08] allocatable compontents of recursive type
--- Comment #1 from janus at gcc dot gnu dot org 2010-09-03 09:59 ---
Here is a patch to accept the type declaration in comment #0:
Index: decl.c
===
--- decl.c (revision 163798)
+++ decl.c (working copy)
@@ -1494,11 +1494,11 @@ build_struct (const char *name, gfc_charlen *cl, g
gfc_component *c;
gfc_try t = SUCCESS;
- /* F03:C438/C439. If the current symbol is of the same derived type that
we're
- constructing, it must have the pointer attribute. */
+ /* F08:C440. If the current symbol is of the same derived type that we're
+ constructing, it must be POINTER or ALLOCATABLE. */
if ((current_ts.type == BT_DERIVED || current_ts.type == BT_CLASS)
current_ts.u.derived == gfc_current_block ()
- current_attr.pointer == 0)
+ !current_attr.pointer !current_attr.allocatable)
{
gfc_error (Component at %C must have the POINTER attribute);
return FAILURE;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45516
[Bug fortran/45507] [4.6 Regression] Bogus Error: Can't convert TYPE(c_ptr) to INTEGER(4)
--- Comment #4 from janus at gcc dot gnu dot org 2010-09-03 10:29 --- Mine. -- 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-09-02 19:45:28 |2010-09-03 10:29:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45507
[Bug fortran/44541] [OOP] wrong code for polymorphic variable with INTENT(OUT)/Alloc w/ MOLD
--- Comment #8 from janus at gcc dot gnu dot org 2010-09-02 12:34 --- Subject: Bug 44541 Author: janus Date: Thu Sep 2 12:34:26 2010 New Revision: 163773 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163773 Log: 2010-09-02 Janus Weil ja...@gcc.gnu.org PR fortran/44541 * resolve.c (resolve_symbol): Correct check for attributes of CLASS variable. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44541
[Bug fortran/45494] [OOP] Wrong dummy argument not rejected
--- Comment #2 from janus at gcc dot gnu dot org 2010-09-02 12:55 --- Confirmed. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2010-09-02 12:55:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45494
[Bug fortran/45507] [4.6 Regression] Bogus Error: Can't convert TYPE(c_ptr) to INTEGER(4)
--- Comment #1 from janus at gcc dot gnu dot org 2010-09-02 19:45 --- Reduced test case: use, intrinsic :: iso_c_binding type :: cType type(c_ptr) :: accelPtr = c_null_ptr end type cType type(cType), allocatable, dimension(:) :: filters allocate(filters(1)) end The failure was supposedly introduced by r163744. -- janus at gcc dot gnu dot org changed: What|Removed |Added CC||janus at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-02 19:45:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45507
[Bug fortran/45507] [4.6 Regression] Bogus Error: Can't convert TYPE(c_ptr) to INTEGER(4)
--- Comment #3 from janus at gcc dot gnu dot org 2010-09-02 19:59 --- (In reply to comment #1) Reduced test case: Sorry, I messed this one up. Should be: use, intrinsic :: iso_c_binding type :: cType type(c_ptr) :: accelPtr = c_null_ptr end type cType type(cType), allocatable, dimension(:) :: filters allocate(filters(1)) end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45507
[Bug fortran/43018] alloc_comp_scalar_1.f90: Valgrind Invalid read of size 4
--- Comment #1 from janus at gcc dot gnu dot org 2010-09-01 14:26 --- (In reply to comment #0) Invalid read of size 1 I don't see this at r163721 (probably has been fixed by r159445). Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43018
[Bug fortran/44541] [OOP] wrong code for polymorphic variable with INTENT(OUT)/Alloc w/ MOLD
--- Comment #6 from janus at gcc dot gnu dot org 2010-09-01 20:51 --- Subject: Bug 44541 Author: janus Date: Wed Sep 1 20:50:46 2010 New Revision: 163744 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163744 Log: 2010-09-01 Janus Weil ja...@gcc.gnu.org PR fortran/44541 * class.c (gfc_find_derived_vtab): Add component '$def_init'. * resolve.c (resolve_allocate_expr): Defer handling of default initialization to 'gfc_trans_allocate'. (apply_default_init,resolve_symbol): Handle polymorphic dummies. (resolve_fl_derived): Suppress error messages for vtypes. * trans-stmt.c (gfc_trans_allocate): Handle initialization via polymorphic MOLD expression. * trans-expr.c (gfc_trans_class_init_assign): Now only used for dummy initialization. 2010-09-01 Janus Weil ja...@gcc.gnu.org PR fortran/44541 * gfortran.dg/allocate_alloc_opt_10.f90: Extended. * gfortran.dg/class_dummy_1.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/class_dummy_1.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/allocate_alloc_opt_10.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44541
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
--- Comment #6 from janus at gcc dot gnu dot org 2010-08-31 14:17 --- (In reply to comment #5) In the meantime, I tried with MOLD= in place of SOURCE=, and in the full application it still gives a segfault; I think that variant should be checked as well. Note that for MOLD there is PR 44541 left (which I am about to fix). Up to now MOLD works only with non-polymorphic expressions. Once the PR is fixed, polymorphics should work too. Until this has happened, please refrain from opening further PRs on MOLD. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
-- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2010-08-30 16:31:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
[Bug fortran/45456] New: [4.6 Regression] [OOP] Bogus pointer initialization error on pointer-valued TBP
Reported by Andrew Benson at http://gcc.gnu.org/ml/fortran/2010-08/msg00462.html: module Merger_Trees private public :: mergerTree type mergerTree contains procedure :: getNode = Tree_Node_Get end type mergerTree contains function Tree_Node_Get(thisTree,nodeIndex) result(foundNode) implicit none class(mergerTree), intent(inout) :: thisTree integer, intent(in):: nodeIndex integer, pointer :: foundNode return end function Tree_Node_Get end module Merger_Trees gives: During initialization Error: Pointer initialization target at (1) must have the SAVE attribute -- Summary: [4.6 Regression] [OOP] Bogus pointer initialization error on pointer-valued TBP 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=45456
[Bug fortran/45456] [4.6 Regression] [OOP] Bogus pointer initialization error on pointer-valued TBP
--- Comment #1 from janus at gcc dot gnu dot org 2010-08-30 20:36 --- Here' the fix: Index: resolve.c === --- resolve.c (revision 163648) +++ resolve.c (working copy) @@ -1083,7 +1083,8 @@ comp-name); } - if (!comp-attr.pointer || cons-expr-expr_type == EXPR_NULL) + if (!comp-attr.pointer || comp-attr.proc_pointer + || cons-expr-expr_type == EXPR_NULL) continue; a = gfc_expr_attr (cons-expr); -- 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-08-30 20:36:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45456
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-30 20:48 --- Ok, I could reduce this quite a bit: program bug23 implicit none type :: psb_base_sparse_mat integer, allocatable :: irp(:) end type psb_base_sparse_mat class(psb_base_sparse_mat), allocatable :: a type(psb_base_sparse_mat) :: acsr allocate(acsr%irp(4)) acsr%irp(1:4) = (/1,3,4,5/) write(*,*) acsr%irp(:) allocate(a,source=acsr) write(*,*) a%irp(:) call move_alloc(acsr%irp, a%irp) write(*,*) a%irp(:) end program bug23 Executing gives: 1 3 4 5 1 3 4 5 0 0 4 5 The last line here should be the same as the first two. Changing the CLASS variable into a TYPE makes it work. Running through valgrind shows: ==11502== Command: ./a.out ==11502== 1 3 4 5 1 3 4 5 ==11502== Invalid read of size 4 ==11502==at 0x4EE59B8: extract_int (write.c:450) ==11502==by 0x4EE67B1: write_integer (write.c:1260) ==11502==by 0x4EE9BDE: _gfortrani_list_formatted_write (write.c:1552) ==11502==by 0x4EDECA7: _gfortran_transfer_array (transfer.c:2000) ==11502==by 0x400B07: MAIN__ (in /home/jweil/GSoC/PRs/45451/a.out) ==11502==by 0x400BA8: main (in /home/jweil/GSoC/PRs/45451/a.out) ==11502== Address 0x5934360 is 0 bytes inside a block of size 16 free'd ==11502==at 0x4C280BD: free (vg_replace_malloc.c:366) ==11502==by 0x4EEF5A8: _gfortran_move_alloc (move_alloc.c:41) ==11502==by 0x400AAC: MAIN__ (in /home/jweil/GSoC/PRs/45451/a.out) ==11502==by 0x400BA8: main (in /home/jweil/GSoC/PRs/45451/a.out) ==11502== 1 3 4 5 ==11502== ==11502== HEAP SUMMARY: ==11502== in use at exit: 0 bytes in 0 blocks ==11502== total heap usage: 18 allocs, 18 frees, 3,844 bytes allocated ==11502== ==11502== All heap blocks were freed -- no leaks are possible ==11502== ==11502== For counts of detected and suppressed errors, rerun with: -v ==11502== ERROR SUMMARY: 4 errors from 1 contexts (suppressed: 4 from 4) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
[Bug fortran/45456] [4.6 Regression] [OOP] Bogus pointer initialization error on pointer-valued TBP
--- Comment #2 from janus at gcc dot gnu dot org 2010-08-30 21:56 --- Subject: Bug 45456 Author: janus Date: Mon Aug 30 21:56:28 2010 New Revision: 163661 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163661 Log: 2010-08-30 Janus Weil ja...@gcc.gnu.org PR fortran/45456 * resolve.c (resolve_structure_cons): Handle pointer-valued PPCs. 2010-08-30 Janus Weil ja...@gcc.gnu.org PR fortran/45456 * gfortran.dg/typebound_proc_18.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_proc_18.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45456
[Bug fortran/45456] [4.6 Regression] [OOP] Bogus pointer initialization error on pointer-valued TBP
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-30 21:58 --- Fixed with r163661. 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=45456
[Bug fortran/45439] [OOP] SELECT TYPE bogus complaint about INTENT
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-29 09:56 --- Subject: Bug 45439 Author: janus Date: Sun Aug 29 09:56:45 2010 New Revision: 163626 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163626 Log: 2010-08-29 Janus Weil ja...@gcc.gnu.org PR fortran/45439 * match.c (gfc_match_select_type): Give the associate-name the FL_VARIABLE attribute. 2010-08-29 Janus Weil ja...@gcc.gnu.org PR fortran/45439 * gfortran.dg/select_type_16.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/select_type_16.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45439
[Bug fortran/45439] [OOP] SELECT TYPE bogus complaint about INTENT
--- Comment #5 from janus at gcc dot gnu dot org 2010-08-29 09:57 --- Fixed with r163626. 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=45439
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
--- Comment #6 from janus at gcc dot gnu dot org 2010-08-29 17:22 --- cf. PR 44529 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440
[Bug fortran/44541] [OOP] wrong code for polymorphic variable with INTENT(OUT)/Alloc w/ MOLD
--- Comment #5 from janus at gcc dot gnu dot org 2010-08-29 21:10 --- Mine (working on a patch). -- 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-06-15 18:40:31 |2010-08-29 21:10:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44541
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
--- Comment #29 from janus at gcc dot gnu dot org 2010-08-29 21:29 --- Subject: Bug 42769 Author: janus Date: Sun Aug 29 21:29:38 2010 New Revision: 163631 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163631 Log: 2010-08-29 Janus Weil ja...@gcc.gnu.org PR fortran/42769 * resolve.c (resolve_structure_cons): For derived types, make sure the type has been resolved. (resolve_typebound_procedures): Make sure the vtab has been generated. 2010-08-29 Janus Weil ja...@gcc.gnu.org PR fortran/42769 * gfortran.dg/dynamic_dispatch_11.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_11.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
--- Comment #30 from janus at gcc dot gnu dot org 2010-08-29 21:36 --- r163631 fixes comment #27, but the other stuff still fails: 1) the original test case (comment #1, ICE) 2) the reduced version (comment #8, ICE) 3) the variant in comment #24 (wrong-code) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
[Bug fortran/45438] [OOP] ICE with -fcheck=pointer
-- janus at gcc dot gnu dot org changed: What|Removed |Added CC||janus at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-28 10:27:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45438
[Bug fortran/45439] [OOP] SELECT TYPE bogus complaint about INTENT
-- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2010-08-28 11:27:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45439
[Bug fortran/45440] ALLOCATE with SOURCE gives an ICE (segfault)
--- Comment #1 from janus at gcc dot gnu dot org 2010-08-28 11:34 --- Confirmed. One does not even need allocatable components for this. The following also fails: logical, allocatable :: z(:) allocate ( z, source = [ .true., .false., .true.]) ! ICE(segfault) print *, z end -- 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-08-28 11:34:22 date|| Summary|[OOP] ALLOCATE with SOURCE |ALLOCATE with SOURCE gives |gives an ICE (segfault) |an ICE (segfault) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
--- Comment #2 from janus at gcc dot gnu dot org 2010-08-28 11:46 --- valgrind says: ==29743== Invalid read of size 4 ==29743==at 0x52B37DB: __gmpz_set (in /usr/lib/libgmp.so.3.5.2) ==29743==by 0x532C37: conformable_arrays (resolve.c:6525) ==29743==by 0x533175: resolve_allocate_expr (resolve.c:6679) ==29743==by 0x533EA6: resolve_allocate_deallocate (resolve.c:6990) ==29743==by 0x537AB4: resolve_code (resolve.c:9017) ==29743==by 0x541422: resolve_codes (resolve.c:13320) ==29743==by 0x54151D: gfc_resolve (resolve.c:13347) ==29743==by 0x51E86A: resolve_all_program_units (parse.c:4187) ==29743==by 0x51EEE5: gfc_parse_file (parse.c:4416) ==29743==by 0x562C6E: gfc_be_parse_file (f95-lang.c:241) ==29743==by 0xA35DA8: compile_file (toplev.c:971) ==29743==by 0xA38051: do_compile (toplev.c:2321) ==29743== Address 0x7c is not stack'd, malloc'd or (recently) free'd -- janus at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org Known to fail||4.5.2 4.6.0 Summary|ALLOCATE with SOURCE gives |[F03] ALLOCATE with SOURCE |an ICE (segfault) |gives an ICE (segfault) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-28 11:51 --- The following variant segfaults as well (same backtrace): logical, allocatable :: z(:) logical, dimension(1:3) :: src = (/ .true., .false., .true. /) allocate ( z, source = src) print *, z end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-28 11:55 --- It works though when explicitly specifying the size of z to allocate: logical, allocatable :: z(:) allocate ( z(3), source = [ .true., .false., .true. ] ) print *, z end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440
[Bug fortran/45439] [OOP] SELECT TYPE bogus complaint about INTENT
--- Comment #2 from janus at gcc dot gnu dot org 2010-08-28 12:18 --- Reduced test case: module d_base_mat_mod implicit none type :: d_base_sparse_mat contains procedure, pass(a) :: mv_to_coo = d_base_mv_to_coo end type d_base_sparse_mat interface subroutine d_base_mv_to_coo(a) import d_base_sparse_mat class(d_base_sparse_mat), intent(inout) :: a end subroutine d_base_mv_to_coo end interface type :: d_sparse_mat class(d_base_sparse_mat), allocatable :: a end type d_sparse_mat contains subroutine bug21(ax) type(d_sparse_mat), intent(inout) :: ax select type(aa= ax%a) class default call aa%mv_to_coo() end select end subroutine bug21 end module d_base_mat_mod -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45439
[Bug fortran/45439] [OOP] SELECT TYPE bogus complaint about INTENT
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-28 12:49 --- Here's the fix: Index: match.c === --- match.c (revision 163612) +++ match.c (working copy) @@ -4532,6 +4532,7 @@ gfc_match_select_type (void) expr1-symtree-n.sym-attr.untyped = 1; else expr1-symtree-n.sym-ts = expr2-ts; + expr1-symtree-n.sym-attr.flavor = FL_VARIABLE; expr1-symtree-n.sym-attr.referenced = 1; expr1-symtree-n.sym-attr.class_ok = 1; } I'll commit as obvious after a regtest. -- 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-08-28 11:27:22 |2010-08-28 12:49:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45439
[Bug fortran/45420] [OOP] polymorphic TBP call in a CLASS DEFAULT clause
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-27 09:06 --- (In reply to comment #3) First, the patch did not apply cleanly, the first hunk was rejected. I applied it by hand, and I got a problem down the road in my library: === gfortran -ggdb -I.. -I../modules -I. -c psb_srwextd.f90 psb_srwextd.f90:76.13: call aa%mv_to_coo(actmp,info) 1 Error: Actual argument at (1) must be definable as the dummy argument 'a' is INTENT = OUT/INOUT psb_srwextd.f90:84.39: if (info == psb_success_) call aa%mv_from_coo(actmp,info) 1 Error: Actual argument at (1) must be definable as the dummy argument 'a' is INTENT = OUT/INOUT I tried to reproduce this by modifying your original test case, but did not succeed so far. Can you provide a standalone test case for this problem? My feeling is that this is another bug uncovered by the fix for the previous one. The patch in comment #2 is free of testsuite regressions and certainly does the right thing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45420
[Bug fortran/45420] [OOP] polymorphic TBP call in a CLASS DEFAULT clause
--- Comment #7 from janus at gcc dot gnu dot org 2010-08-27 19:02 --- Subject: Bug 45420 Author: janus Date: Fri Aug 27 19:02:15 2010 New Revision: 163594 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163594 Log: 2010-08-27 Janus Weil ja...@gcc.gnu.org PR fortran/45420 * match.c (select_type_set_tmp): Add the possibility to reset the temporary to NULL. (gfc_match_class_is): Reset the temporary in CLASS DEFAULT clauses. 2010-08-27 Janus Weil ja...@gcc.gnu.org PR fortran/45420 * gfortran.dg/select_type_15.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/select_type_15.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45420
[Bug fortran/45420] [OOP] polymorphic TBP call in a CLASS DEFAULT clause
--- Comment #8 from janus at gcc dot gnu dot org 2010-08-27 19:14 --- Fixed with r163594. Closing. (Salvatore, please open a new PR for your problem in comment #3 if you have reduced it.) -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|janus at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45420
[Bug fortran/45420] [OOP] polymorphic TBP call in a CLASS DEFAULT clause
--- Comment #9 from janus at gcc dot gnu dot org 2010-08-27 19:15 --- Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45420
[Bug fortran/45432] gfortran.dg/allocate_alloc_opt_9.f90: Segfault due to invalid FREE
--- Comment #1 from janus at gcc dot gnu dot org 2010-08-27 19:40 ---
This should fix it (it was some kind of double-free problem):
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 163594)
+++ gcc/fortran/match.c (working copy)
@@ -2955,6 +2955,7 @@ alloc_opt_list:
}
stat = tmp;
+ tmp = NULL;
saw_stat = true;
if (gfc_check_do_variable (stat-symtree))
@@ -2981,6 +2982,7 @@ alloc_opt_list:
}
errmsg = tmp;
+ tmp = NULL;
saw_errmsg = true;
if (gfc_match_char (',') == MATCH_YES)
@@ -3019,6 +3021,7 @@ alloc_opt_list:
}
source = tmp;
+ tmp = NULL;
saw_source = true;
if (gfc_match_char (',') == MATCH_YES)
@@ -3050,6 +3053,7 @@ alloc_opt_list:
}
mold = tmp;
+ tmp = NULL;
saw_mold = true;
mold-mold = 1;
--
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-08-27 19:40:17
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45432
[Bug fortran/45432] gfortran.dg/allocate_alloc_opt_9.f90: Segfault due to invalid FREE
--- Comment #2 from janus at gcc dot gnu dot org 2010-08-27 21:51 --- Subject: Bug 45432 Author: janus Date: Fri Aug 27 21:50:47 2010 New Revision: 163599 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163599 Log: 2010-08-27 Janus Weil ja...@gcc.gnu.org PR fortran/45432 * match.c (gfc_match_allocate): Avoid double free on error. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45432
[Bug fortran/45432] gfortran.dg/allocate_alloc_opt_9.f90: Segfault due to invalid FREE
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-27 21:51 --- Fixed with r163599. 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=45432
[Bug fortran/45420] New: [OOP] poylmorphic TBP calls in a CLASS DEFAULT clause
Reported by Salvatore at http://gcc.gnu.org/ml/fortran/2010-08/msg00351.html. Here is a slightly simplified version of the test case: module base_mat_mod type :: base_sparse_mat contains procedure, pass(a) :: get_fmt = base_get_fmt end type base_sparse_mat contains function base_get_fmt(a) result(res) implicit none class(base_sparse_mat), intent(in) :: a character(len=5) :: res res = 'NULL' end function base_get_fmt end module base_mat_mod module d_base_mat_mod use base_mat_mod type, extends(base_sparse_mat) :: d_base_sparse_mat contains procedure, pass(a) :: get_fmt = d_base_get_fmt end type d_base_sparse_mat type, extends(d_base_sparse_mat) :: x_base_sparse_mat contains procedure, pass(a) :: get_fmt = x_base_get_fmt end type x_base_sparse_mat contains function d_base_get_fmt(a) result(res) implicit none class(d_base_sparse_mat), intent(in) :: a character(len=5) :: res res = 'DBASE' end function d_base_get_fmt function x_base_get_fmt(a) result(res) implicit none class(x_base_sparse_mat), intent(in) :: a character(len=5) :: res res = 'XBASE' end function x_base_get_fmt end module d_base_mat_mod program bug20 use d_base_mat_mod class(d_base_sparse_mat), allocatable :: a allocate(x_base_sparse_mat :: a) write(0,*) 'Dynamic type on entry: ',a%get_fmt() select type(a) type is (d_base_sparse_mat) write(0,*) 'Dynamic type TYPE IS clause: ',a%get_fmt() class default write(0,*) 'Dynamic type CLASS DEFAULT clause: ',a%get_fmt() end select end program bug20 Current output: Dynamic type on entry: XBASE Dynamic type CLASS DEFAULT clause: DBASE Expected output: Dynamic type on entry: XBASE Dynamic type CLASS DEFAULT clause: XBASE -- Summary: [OOP] poylmorphic TBP calls in a CLASS DEFAULT clause 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=45420
[Bug fortran/45420] [OOP] poylmorphic TBP calls in a CLASS DEFAULT clause
--- Comment #1 from janus at gcc dot gnu dot org 2010-08-26 17:54 --- The dump shows that the first call to 'get_fmt' is executed dynamically as 'a.$vptr-get_fmt(...)', while the ones inside the SELECT TYPE block are resolved statically to 'd_base_get_fmt'. For the TYPE IS clause this is fine, but not so for CLASS DEFAULT, where a polymorphic call should be generated. F08 quotes (chapter 8.1.9.2): Within the block following a TYPE IS type guard statement, the associating entity (16.5.5) is not polymorphic (4.3.1.3), has the type named in the type guard statement, and has the type parameter values of the selector. Within the block following a CLASS IS type guard statement, the associating entity is polymorphic and has the declared type named in the type guard statement. The type parameter values of the associating entity are the corresponding type parameter values of the selector. Within the block following a CLASS DEFAULT type guard statement, the associating entity is polymorphic and has the same declared type as the selector. The type parameter values of the associating entity are those of the declared type of the selector. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45420
[Bug fortran/45420] [OOP] poylmorphic TBP calls in a CLASS DEFAULT clause
--- Comment #2 from janus at gcc dot gnu dot org 2010-08-26 19:55 ---
It turns out this bug is rather easy to fix. The problem was the we used the
temporary needed for the TYPE IS clause also in the CLASS DEFAULT clause (where
we need none). The following patch fixes it (haven't checked for regressions
yet):
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 163470)
+++ gcc/fortran/match.c (working copy)
@@ -4460,6 +4460,12 @@ select_type_set_tmp (gfc_typespec *ts)
char name[GFC_MAX_SYMBOL_LEN];
gfc_symtree *tmp;
+ if (!ts)
+{
+ select_type_stack-tmp = NULL;
+ return;
+}
+
if (!gfc_type_is_extensible (ts-u.derived))
return;
@@ -4702,6 +4708,7 @@ gfc_match_class_is (void)
c-where = gfc_current_locus;
c-ts.type = BT_UNKNOWN;
new_st.ext.case_list = c;
+ select_type_set_tmp (NULL);
return MATCH_YES;
}
--
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-08-26 19:55:39
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45420
[Bug fortran/45420] [OOP] polymorphic TBP call in a CLASS DEFAULT clause
-- janus at gcc dot gnu dot org changed: What|Removed |Added Summary|[OOP] poylmorphic TBP calls |[OOP] polymorphic TBP call |in a CLASS DEFAULT clause |in a CLASS DEFAULT clause Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45420
[Bug fortran/45395] [OOP] internal compiler error: Segmentation fault
--- Comment #6 from janus at gcc dot gnu dot org 2010-08-25 19:09 --- Ok, I'll close this as fixed since it works on 4.6. And I think we already have similar test cases from the PRs mentioned above. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45395
[Bug fortran/45395] [OOP] internal compiler error: Segmentation fault
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-24 11:32 --- (In reply to comment #3) Could be a duplicate of PR41784, PR44662 or PR44584. The fixes for those PRs were not backported to 4.5. Might be. I'm rather guessing for PR 44064/44065. Actually most of the 34 OOP-related PRs that were fixed on the post-4.5 trunk were not backported. For some a backport is simply not possible since the internal representation was modified heavily. For others it should be possible, but the question is if it's worth the effort (since OOP in 4.5 is marked as experimental anyway and will never be perfect). Btw, the following variant gives me an undefined reference to `vtab$t.1562': module m1 implicit none type :: t contains procedure :: s end type t contains subroutine s(v) class(t), intent(in) :: v end subroutine s end module m1 module m2 use m1 implicit none contains subroutine ss() type(t) :: v call v%s() end subroutine ss end module m2 program pr end program pr The original test case hangs in an infinite loop on my machine. -- 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-08-24 11:32:10 date|| Summary|internal compiler error:|[OOP] internal compiler |Segmentation fault |error: Segmentation fault http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45395
[Bug fortran/45384] [OOP] double free with SELECT TYPE
--- Comment #6 from janus at gcc dot gnu dot org 2010-08-24 12:57 --- (In reply to comment #5) However, when the same change is applied to the original library, a double free pops up in another place, unrelated to this issue; this would indicate that there are other instances of some sort of flaw in the cleanup of temporaries. Cf. PR 44047 (which is similar to this, except that the polymorphic selector itself is allocatable). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45384
[Bug fortran/45366] Problem with procedure pointer dummy in PURE function
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-23 12:26 --- Subject: Bug 45366 Author: janus Date: Mon Aug 23 12:26:42 2010 New Revision: 163468 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163468 Log: 2010-08-23 Janus Weil ja...@gcc.gnu.org PR fortran/45366 * resolve.c (resolve_procedure_interface): New function split off from 'resolve_symbol'. (resolve_formal_arglist): Call it here ... (resolve_symbol): ... and here. 2010-08-23 Janus Weil ja...@gcc.gnu.org PR fortran/45366 * gfortran.dg/proc_ptr_29.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_29.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45366
[Bug fortran/45366] Problem with procedure pointer dummy in PURE function
--- Comment #5 from janus at gcc dot gnu dot org 2010-08-23 12:29 --- Fixed with r163468. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail||4.4.3 4.5.2 4.6.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45366
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
--- Comment #27 from janus at gcc dot gnu dot org 2010-08-23 13:25 --- (In reply to comment #24) Here is a somewhat modified version of comment #14, which compiles but produces wrong code: The example in comment #24 contains a statically-resolved TBP call (the pass object is non-polymorphic). One can construct an analogous version with a polymorphic TBP call, which also fails: module mod1 type :: t1 contains procedure, nopass :: get = my_get end type contains subroutine my_get() print *,my_get (mod1) end subroutine end module module mod2 contains subroutine my_get() ! must have the same name as the function in mod1 print *,my_get (mod2) end subroutine end module use mod2 use mod1 ! order of use statements is important class(t1),allocatable :: a allocate(a) call a%get() end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
--- Comment #28 from janus at gcc dot gnu dot org 2010-08-23 13:32 ---
Comment #27 can be fixed by:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 163468)
+++ gcc/fortran/resolve.c (working copy)
@@ -10937,10 +10937,12 @@ error:
stree-n.tb-error = 1;
}
+
static gfc_try
resolve_typebound_procedures (gfc_symbol* derived)
{
int op;
+ gfc_symbol *vtab;
if (!derived-f2k_derived || !derived-f2k_derived-tb_sym_root)
return SUCCESS;
@@ -10948,6 +10950,9 @@ resolve_typebound_procedures (gfc_symbol* derived)
resolve_bindings_derived = derived;
resolve_bindings_result = SUCCESS;
+ /* Make sure the vtab has been generated. */
+ vtab = gfc_find_derived_vtab (derived);
+
if (derived-f2k_derived-tb_sym_root)
gfc_traverse_symtree (derived-f2k_derived-tb_sym_root,
resolve_typebound_procedure);
--
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-01-16 21:04:41 |2010-08-23 13:32:36
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
[Bug fortran/45384] [OOP] double free with SELECT TYPE
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-23 15:36 --- Reduced test case: program bug20 type :: d_base_sparse_mat integer :: v(10) = 0. end type d_base_sparse_mat class(d_base_sparse_mat),allocatable :: a allocate (d_base_sparse_mat :: a) select type(aa = a) type is (d_base_sparse_mat) write(0,*) 'NV = ',size(aa%v) class default write(0,*) 'Not implemented yet ' end select end program bug20 Note: The double free only happens when an associate-name is used. -- 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-08-23 15:36:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45384
[Bug fortran/45366] Problem with abstract interface to PURE function
--- Comment #1 from janus at gcc dot gnu dot org 2010-08-22 10:50 --- Confirmed. Thanks for reporting. -- 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 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2010-08-22 10:50:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45366
[Bug fortran/45366] Problem with abstract interface to PURE function
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-22 11:10 --- (In reply to comment #2) The problems seems to be that resolve_symbol is called later than the resolve_formal_arglist check for pureness, i.e. one first checks whether p is pure before one copies the attr.pure from ts.interface-attr.pure - which explains the failure. Exactly. I'm regtesting a patch right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45366
[Bug fortran/44863] [OOP] Fortran runtime error: internal error: bad hash value in dynamic dispatch
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-21 14:51 --- Subject: Bug 44863 Author: janus Date: Sat Aug 21 14:50:57 2010 New Revision: 163445 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163445 Log: 2010-08-21 Janus Weil ja...@gcc.gnu.org PR fortran/45271 PR fortran/45290 * class.c (add_proc_comp): Add static initializer for PPCs. (add_procs_to_declared_vtab): Modified comment. * module.c (mio_component): Add argument 'vtype'. Don't read/write the initializer if the component is part of a vtype. (mio_component_list): Add argument 'vtype', pass it on to 'mio_component'. (mio_symbol): Modified call to 'mio_component_list'. * trans.h (gfc_conv_initializer): Modified prototype. (gfc_trans_assign_vtab_procs): Removed. * trans-common.c (create_common): Modified call to 'gfc_conv_initializer'. * trans-decl.c (gfc_get_symbol_decl,get_proc_pointer_decl, gfc_emit_parameter_debug_info): Modified call to 'gfc_conv_initializer'. (build_function_decl): Remove assertion. * trans-expr.c (gfc_conv_derived_to_class,gfc_trans_class_assign): Removed call to 'gfc_trans_assign_vtab_procs'. (gfc_conv_initializer): Add argument 'procptr'. (gfc_conv_structure): Modified call to 'gfc_conv_initializer'. (gfc_trans_assign_vtab_procs): Removed. * trans-stmt.c (gfc_trans_allocate): Removed call to 'gfc_trans_assign_vtab_procs'. 2010-08-21 Janus Weil ja...@gcc.gnu.org PR fortran/44863 PR fortran/45271 PR fortran/45290 * gfortran.dg/dynamic_dispatch_10.f03: New (PR 44863 comment #1). * gfortran.dg/pointer_init_5.f90: New (PR 45290 comment #6). * gfortran.dg/typebound_call_18.f03: New (PR 45271 comment #3). Added: trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_10.f03 trunk/gcc/testsuite/gfortran.dg/pointer_init_5.f90 trunk/gcc/testsuite/gfortran.dg/typebound_call_18.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/module.c trunk/gcc/fortran/trans-common.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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44863
[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
--- Comment #11 from janus at gcc dot gnu dot org 2010-08-21 14:51 --- Subject: Bug 45271 Author: janus Date: Sat Aug 21 14:50:57 2010 New Revision: 163445 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163445 Log: 2010-08-21 Janus Weil ja...@gcc.gnu.org PR fortran/45271 PR fortran/45290 * class.c (add_proc_comp): Add static initializer for PPCs. (add_procs_to_declared_vtab): Modified comment. * module.c (mio_component): Add argument 'vtype'. Don't read/write the initializer if the component is part of a vtype. (mio_component_list): Add argument 'vtype', pass it on to 'mio_component'. (mio_symbol): Modified call to 'mio_component_list'. * trans.h (gfc_conv_initializer): Modified prototype. (gfc_trans_assign_vtab_procs): Removed. * trans-common.c (create_common): Modified call to 'gfc_conv_initializer'. * trans-decl.c (gfc_get_symbol_decl,get_proc_pointer_decl, gfc_emit_parameter_debug_info): Modified call to 'gfc_conv_initializer'. (build_function_decl): Remove assertion. * trans-expr.c (gfc_conv_derived_to_class,gfc_trans_class_assign): Removed call to 'gfc_trans_assign_vtab_procs'. (gfc_conv_initializer): Add argument 'procptr'. (gfc_conv_structure): Modified call to 'gfc_conv_initializer'. (gfc_trans_assign_vtab_procs): Removed. * trans-stmt.c (gfc_trans_allocate): Removed call to 'gfc_trans_assign_vtab_procs'. 2010-08-21 Janus Weil ja...@gcc.gnu.org PR fortran/44863 PR fortran/45271 PR fortran/45290 * gfortran.dg/dynamic_dispatch_10.f03: New (PR 44863 comment #1). * gfortran.dg/pointer_init_5.f90: New (PR 45290 comment #6). * gfortran.dg/typebound_call_18.f03: New (PR 45271 comment #3). Added: trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_10.f03 trunk/gcc/testsuite/gfortran.dg/pointer_init_5.f90 trunk/gcc/testsuite/gfortran.dg/typebound_call_18.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/module.c trunk/gcc/fortran/trans-common.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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45271
[Bug fortran/45290] [F08] pointer initialization
--- Comment #7 from janus at gcc dot gnu dot org 2010-08-21 14:51 --- Subject: Bug 45290 Author: janus Date: Sat Aug 21 14:50:57 2010 New Revision: 163445 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163445 Log: 2010-08-21 Janus Weil ja...@gcc.gnu.org PR fortran/45271 PR fortran/45290 * class.c (add_proc_comp): Add static initializer for PPCs. (add_procs_to_declared_vtab): Modified comment. * module.c (mio_component): Add argument 'vtype'. Don't read/write the initializer if the component is part of a vtype. (mio_component_list): Add argument 'vtype', pass it on to 'mio_component'. (mio_symbol): Modified call to 'mio_component_list'. * trans.h (gfc_conv_initializer): Modified prototype. (gfc_trans_assign_vtab_procs): Removed. * trans-common.c (create_common): Modified call to 'gfc_conv_initializer'. * trans-decl.c (gfc_get_symbol_decl,get_proc_pointer_decl, gfc_emit_parameter_debug_info): Modified call to 'gfc_conv_initializer'. (build_function_decl): Remove assertion. * trans-expr.c (gfc_conv_derived_to_class,gfc_trans_class_assign): Removed call to 'gfc_trans_assign_vtab_procs'. (gfc_conv_initializer): Add argument 'procptr'. (gfc_conv_structure): Modified call to 'gfc_conv_initializer'. (gfc_trans_assign_vtab_procs): Removed. * trans-stmt.c (gfc_trans_allocate): Removed call to 'gfc_trans_assign_vtab_procs'. 2010-08-21 Janus Weil ja...@gcc.gnu.org PR fortran/44863 PR fortran/45271 PR fortran/45290 * gfortran.dg/dynamic_dispatch_10.f03: New (PR 44863 comment #1). * gfortran.dg/pointer_init_5.f90: New (PR 45290 comment #6). * gfortran.dg/typebound_call_18.f03: New (PR 45271 comment #3). Added: trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_10.f03 trunk/gcc/testsuite/gfortran.dg/pointer_init_5.f90 trunk/gcc/testsuite/gfortran.dg/typebound_call_18.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/module.c trunk/gcc/fortran/trans-common.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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290
[Bug fortran/44863] [OOP] Fortran runtime error: internal error: bad hash value in dynamic dispatch
--- Comment #5 from janus at gcc dot gnu dot org 2010-08-21 14:59 --- r163445 adds comment #1 to the testsuite, because it uncovered a regression in my recent patch for PR 45271 (thanks to Dominique for noticing). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44863
[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
--- Comment #12 from janus at gcc dot gnu dot org 2010-08-21 15:00 --- Fixed with r163445. 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=45271
[Bug fortran/44541] [OOP] wrong code for polymorphic variable with INTENT(OUT)/Alloc w/ MOLD
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-21 15:14 --- (In reply to comment #3) Is this now fixable using the default pointer initialization? At least pointer initialization enables us to initalize the $def_init pointer component. But still we will need a default-initialized variable which $def_init can point to. The question is if we even need a $def_init component in the vtab (I think the answer is yes, since we don't know the dynamic type to use for initialization in the general case). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44541
[Bug fortran/45290] [F08] pointer initialization
--- Comment #8 from janus at gcc dot gnu dot org 2010-08-21 16:21 --- Comment #6 is fixed by r163445, but comment #5 is still open. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290
[Bug fortran/45290] [F08] pointer initialization
--- Comment #6 from janus at gcc dot gnu dot org 2010-08-19 11:11 --- There are also still problems with procedure pointers: module m implicit none procedure(f1), pointer :: pp = f1 contains integer function f1() f1 = 42 end function end module use m implicit none if (pp()/=42) call abort() end This one fails with: f951: internal compiler error: in build_function_decl, at fortran/trans-decl.c:1611 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290
[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
--- Comment #10 from janus at gcc dot gnu dot org 2010-08-19 13:08 --- (In reply to comment #9) (In reply to comment #4) Possible solutions: 1) Make sure we use the right symbol from the right module. 2) Do the vtab initialization inside the module that defines the class, i.e. add a module procedure like 'vtab$trivial_gradient_type$init' which does it, and call this from the main program. Then there is no name ambiguity. 3) Do it in the original module (like in #2), but statically via default initialization. Mine. I'm working on a patch which implements solution #3. It already fixes the test case, but still has a few regresssions. -- 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-08-13 08:22:22 |2010-08-19 13:08:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45271
[Bug fortran/45290] [F08] pointer initialization
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-18 22:32 --- Subject: Bug 45290 Author: janus Date: Wed Aug 18 22:32:22 2010 New Revision: 163356 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163356 Log: 2010-08-19 Janus Weil ja...@gcc.gnu.org PR fortran/45290 * gfortran.h (gfc_add_save): Modified prototype. * decl.c (add_init_expr_to_sym): Defer checking of proc pointer init. (match_pointer_init): New function to match F08 pointer initialization. (variable_decl,match_procedure_decl,match_ppc_decl): Use 'match_pointer_init'. (match_attr_spec): Module variables are implicitly SAVE. (gfc_match_save): Modified call to 'gfc_add_save'. * expr.c (gfc_check_assign_symbol): Extra checks for pointer initialization. * primary.c (gfc_variable_attr): Handle SAVE attribute. * resolve.c (resolve_structure_cons): Add new argument and do pointer initialization checks. (gfc_resolve_expr): Modified call to 'resolve_structure_cons'. (resolve_values): Call 'resolve_structure_cons' directly with init arg. (resolve_fl_variable): Handle SAVE_IMPLICIT. * symbol.c (gfc_add_save,gfc_copy_attr,save_symbol): Handle SAVE_IMPLICIT. * trans-decl.c (gfc_create_module_variable): Module variables with TARGET can already exist. * trans-expr.c (gfc_conv_variable): Check for 'current_function_decl'. (gfc_conv_initializer): Implement non-NULL pointer initialization. 2010-08-19 Janus Weil ja...@gcc.gnu.org PR fortran/45290 * gfortran.dg/proc_ptr_comp_3.f90: Modified. * gfortran.dg/pointer_init_2.f90: New. * gfortran.dg/pointer_init_3.f90: New. * gfortran.dg/pointer_init_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/pointer_init_2.f90 trunk/gcc/testsuite/gfortran.dg/pointer_init_3.f90 trunk/gcc/testsuite/gfortran.dg/pointer_init_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/primary.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/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290
[Bug fortran/45290] [F08] pointer initialization
--- Comment #5 from janus at gcc dot gnu dot org 2010-08-18 22:37 --- r163356 implements pointer initialization. Leftover To-Do items: (1) ICE on module m implicit none integer, target, save :: t1 integer, pointer :: p1 = t integer, pointer :: p2 = p1! ICE end module m (2) Making global variables in a program SAVE_IMPLICIT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290
[Bug fortran/45290] [F08] pointer initialization
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-16 09:37 --- (In reply to comment #2) (In reply to comment #0) Note: For procedure-pointer components I was not able to find any specific reference to non-NULL default initialization. It is allowed per: R440 proc-component-def-stmt is PROCEDURE ( [ proc-interface ] ) , proc-component-attr-spec-list :: proc-decl-list As proc-decl-list refers to (click on it in the PDF): R1214 proc-decl is procedure-entity-name [ = proc-pointer-init ] Right. I missed that. (I guess I was expecting an explicit reference to 'proc-pointer-init' around R440.) Also: Mine. (I'm working on a patch.) -- 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-08-16 07:34:39 |2010-08-16 09:37:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290
[Bug fortran/45290] New: [F08] pointer initialization
John Reid, The new features of Fortran 2008, chapter 5.5: A pointer may be initially associated with a target: type (entry), target :: bottom type (entry), pointer :: top = bottom * Currently gfortran responds with: type (entry), pointer :: top = bottom 1 Error: Pointer initialization requires a NULL() at (1) * A look at the current draft of F08 seems to indicate that this is allowed for any kind of pointer: Data pointers and data pointer components as well as procedure pointers and procedure pointer components. See: R442 component-initialization R443 initial-data-target C460 R505 initialization C511 R1216 proc-pointer-init R1217 initial-proc-target Note: For procedure-pointer components I was not able to find any specific reference to non-NULL default initialization. However, chapter 4.5.4.6 (Default initialization for components) explicitly mentions the possibility of having an initial-proc-target for a PPC. -- Summary: [F08] pointer initialization 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 OtherBugsDependingO 39627 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290
[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
--- Comment #9 from janus at gcc dot gnu dot org 2010-08-15 20:01 --- (In reply to comment #4) Possible solutions: 1) Make sure we use the right symbol from the right module. 2) Do the vtab initialization inside the module that defines the class, i.e. add a module procedure like 'vtab$trivial_gradient_type$init' which does it, and call this from the main program. Then there is no name ambiguity. 3) Do it in the original module (like in #2), but statically via default initialization. This is definitely the most elegant and efficient way. It should be possible once PR45290 is implemented. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45271
[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
--- Comment #2 from janus at gcc dot gnu dot org 2010-08-13 08:22 ---
Confirmed.
-fdump-tree-original shows only one difference when exchanging the use
statements:
--- c1.f90.003t.original2010-08-13 10:05:17.720283742 +0200
+++ c1.f90.003t.original.bug2010-08-13 10:04:53.912784753 +0200
@@ -215,7 +215,7 @@ MAIN__ ()
if (vtab$trivial_gradient_type.assign == 0B)
{
-vtab$trivial_gradient_type.assign = my_assign;
+vtab$trivial_gradient_type.assign = (void (*T4a1) (struct
class$trivial_gradient_type restrict, struct class$vector_class restrict))
my_assign;
}
class.8.$vptr = (struct vtype$gradient_class * {ref-all})
vtab$trivial_gradient_type;
class.8.$data = (struct gradient_class *) g_initial;
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
CC||janus at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2010-08-13 08:22:22
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45271
[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-13 09:29 --- Here is a reduced test case: module abstract_vector implicit none type, abstract :: vector_class contains procedure(op_assign_v_v), deferred :: assign end type vector_class abstract interface subroutine op_assign_v_v(this,v) import vector_class class(vector_class), intent(inout) :: this class(vector_class), intent(in):: v end subroutine end interface end module abstract_vector module concrete_vector use abstract_vector implicit none type, extends(vector_class) :: trivial_vector_type contains procedure :: assign = my_assign end type contains subroutine my_assign (this,v) class(trivial_vector_type), intent(inout) :: this class(vector_class),intent(in):: v write (*,*) 'Oops in concrete_vector::my_assign' call abort () end subroutine end module concrete_vector module concrete_gradient use abstract_vector implicit none type, extends(vector_class) :: trivial_gradient_type contains procedure :: assign = my_assign end type contains subroutine my_assign (this,v) class(trivial_gradient_type), intent(inout) :: this class(vector_class), intent(in):: v write (*,*) 'concrete_gradient::my_assign' end subroutine end module concrete_gradient program main !--- exchange these two lines to make the code work: use concrete_vector! (1) use concrete_gradient ! (2) !--- implicit none type(trivial_gradient_type) :: g_initial class(vector_class), allocatable :: g print *, cg: before g%assign allocate(trivial_gradient_type :: g) call g%assign (g_initial) print *, cg: after g%assign end program main -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45271
[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-13 09:50 ---
The problem is the following:
We have two routines called 'my_assign' (in two different modules). When
initializing the vtabs in the main program, we happen to use the wrong one:
if (vtab$trivial_gradient_type.assign == 0B)
{
vtab$trivial_gradient_type.assign = my_assign;
}
Possible solutions:
1) Make sure we use the right symbol from the right module.
2) Do the vtab initialization inside the module that defines the class, i.e.
add a module procedure like 'vtab$trivial_gradient_type$init' which does it,
and call this from the main program. Then there is no name ambiguity.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45271
[Bug fortran/45275] New: [4.6 Regression] FAIL: gfortran.dg/array_memcpy_3.f90
On x86_64-unknown-linux-gnu at r163221 I see the following testsuite regression: FAIL: gfortran.dg/array_memcpy_3.f90 -O scan-tree-dump-times original memcpy|(ref-all.*ref-all) 2 -- Summary: [4.6 Regression] FAIL: gfortran.dg/array_memcpy_3.f90 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=45275
[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
--- Comment #5 from janus at gcc dot gnu dot org 2010-08-13 12:36 --- We have two routines called 'my_assign' (in two different modules). When initializing the vtabs in the main program, we happen to use the wrong one: This is because the 'f2k_derived' namespace of 'trivial_gradient_type' contains the wrong symbol for 'my_assign'. Apparently the symbols are mixed up when reading the module files. The initialization of the vtab happens in gfc_trans_assign_vtab_procs (trans-expr.c). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45271
[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
--- Comment #7 from janus at gcc dot gnu dot org 2010-08-13 14:31 --- (In reply to comment #6) There is code to prevent duplicate names to be imported, but it is bypassed by vtab and vtype stuff: This is fine. The problem is not in importing the vtab symbols, but importing the TBP targets (i.e. my_assign in the test case). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45271
[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
--- Comment #8 from janus at gcc dot gnu dot org 2010-08-13 17:23 --- Actually I think it's a duplicate of PR42769, or at least related. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45271
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
--- Comment #26 from janus at gcc dot gnu dot org 2010-08-13 17:28 --- cf. also PR45271 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
[Bug fortran/44595] INTENT of arguments to intrinsic procedures not checked
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-11 10:50 --- Subject: Bug 44595 Author: janus Date: Wed Aug 11 10:49:56 2010 New Revision: 163096 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163096 Log: 2010-08-11 Janus Weil ja...@gcc.gnu.org PR fortran/44595 * intrinsic.c (gfc_current_intrinsic_arg): Change type from 'char' to 'gfc_intrinsic_arg'. (check_arglist,check_specific): Add reference to 'name' field. (init_arglist): Remove reference to 'name' field. * intrinsic.h (gfc_current_intrinsic_arg): Modify prototype. * check.c (variable_check): Reverse order of checks. Respect intent of formal arg. (int_or_proc_check): New function. (coarray_check): New function. (allocatable_check): New function. (gfc_check_allocated,gfc_check_move_alloc): Use 'allocatable_check'. (gfc_check_complex): Use 'int_or_real_check'. (gfc_check_lcobound,gfc_check_image_index,gfc_check_this_image, gfc_check_ucobound): Use 'coarray_check'. (gfc_check_pack): Use 'real_or_complex_check'. (gfc_check_alarm_sub,gfc_check_signal,gfc_check_signal_sub): Use 'int_or_proc_check'. (scalar_check,type_check,numeric_check,int_or_real_check, real_or_complex_check,kind_check,double_check,logical_array_check, array_check,same_type_check,rank_check,nonoptional_check, kind_value_check,gfc_check_a_p,gfc_check_associated,gfc_check_cmplx, gfc_check_cshift,gfc_check_dcmplx,gfc_check_dot_product,gfc_check_dprod, gfc_check_eoshift,gfc_check_fn_rc2008,gfc_check_index,gfc_check_kind, gfc_check_matmul,gfc_check_minloc_maxloc,check_reduction,gfc_check_null, gfc_check_present,gfc_check_reshape,gfc_check_same_type_as, gfc_check_spread,gfc_check_unpack,gfc_check_random_seed, gfc_check_getarg,gfc_check_and,gfc_check_storage_size): Add reference to 'name' field. 2010-08-11 Janus Weil ja...@gcc.gnu.org Steve Kargl ka...@gcc.gnu.org PR fortran/44595 * gfortran.dg/move_alloc_3.f90: New. * gfortran.dg/random_seed_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/move_alloc_3.f90 trunk/gcc/testsuite/gfortran.dg/random_seed_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44595
[Bug fortran/44595] INTENT of arguments to intrinsic procedures not checked
--- Comment #5 from janus at gcc dot gnu dot org 2010-08-11 11:01 --- Fixed with r163096. 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=44595
[Bug fortran/40994] ICE in gfc_undo_symbols
--- Comment #8 from janus at gcc dot gnu dot org 2010-08-11 19:30 --- Both comment #0 and comment #6 work for me without ICE on 4.6 trunk r163095. Closing as fixed. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to fail|4.4.1 4.5.0 4.6.0 |4.4.1 4.5.0 Known to work||4.6.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40994
[Bug fortran/44595] INTENT of argeuments to intrinsics procedure not check
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-09 17:41 --- (In reply to comment #0) The problem is in check_variable() in check.c. The first if-statement prevents the second one from being reached. Right. However, exchanging them produces lots of regressions, since the intent of the formal argument is not checked. -- 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-08-09 17:41:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44595
[Bug fortran/44065] [OOP] Undefined reference to vtab$...
--- Comment #14 from janus at gcc dot gnu dot org 2010-08-05 11:58 --- (In reply to comment #13) On x86_64-apple-darwin10.4.0 at r162881, I have tested all the codelets I have for the PRs fixed by r162879 with both -m32 and -m64 without linking error. Great. So I guess we can close this PR. -- 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=44065
[Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument
--- Comment #23 from janus at gcc dot gnu dot org 2010-08-05 12:11 --- For me all the test cases seems to be working now. Mikael, can we close this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051
[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'
--- Comment #21 from janus at gcc dot gnu dot org 2010-08-05 13:56 --- Subject: Bug 44929 Author: janus Date: Thu Aug 5 13:56:00 2010 New Revision: 162914 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162914 Log: 2010-08-05 Janus Weil ja...@gcc.gnu.org Steven G. Kargl ka...@gcc.gnu.org PR fortran/44929 * match.c (match_type_spec): Try to parse derived types before intrinsic types. 2010-08-05 Janus Weil ja...@gcc.gnu.org PR fortran/44929 * gfortran.dg/allocate_derived_3.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/allocate_derived_3.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/match.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44929
[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'
--- Comment #22 from janus at gcc dot gnu dot org 2010-08-05 13:57 --- Fixed on trunk an 4.5. 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=44929
[Bug fortran/42207] [OOP] Compile-time errors on typed allocation and pointer function result assignment
--- Comment #19 from janus at gcc dot gnu dot org 2010-08-04 07:31 --- (In reply to comment #16) Here is a better patch: This patch also fixes the error messages in comment #0 on darwin with -m32. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42207
[Bug fortran/44065] [OOP] Undefined reference to vtab$...
--- Comment #10 from janus at gcc dot gnu dot org 2010-08-04 08:32 --- (In reply to comment #9) With the patch in comment #5 there is one regression: FAIL: gfortran.dg/typebound_operator_4.f03 -O (test for excess errors) the extra errors are: /opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_operator_4.f03:73.7: USE m 1 Error: Invalid expression in the derived type constructor for pointer component '$extends' at (1) in PURE procedure This regression can be fixed by: Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c (revision 162842) +++ gcc/fortran/resolve.c (working copy) @@ -12320,6 +12323,10 @@ gfc_impure_variable (gfc_symbol *sym) gfc_symbol *proc; gfc_namespace *ns; + if (sym-attr.vtab) +return 0; + if (sym-attr.use_assoc || sym-attr.in_common) return 1; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44065
