[Bug fortran/38152] ICE for procedure pointer assignment
--- Comment #2 from janus at gcc dot gnu dot org 2008-11-16 18:59 ---
(In reply to comment #1)
> By the way, the following also fails:
>
> module m
> procedure(), pointer :: procptr
> end module m
>
> use m
> external foo
> procptr => foo
> end
>
> with Error: 'procptr' in the pointer assignment at (1) cannot be an
> l-value since it is a procedure
>
> I think the "proc_ptr" attribute is not properly saved in the .mod file.
Actually this is not the problem. All attributes are saved properly.
The error is fixed by the following trivial patch:
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (revision 141915)
+++ gcc/fortran/expr.c (working copy)
@@ -3034,7 +3034,8 @@ gfc_check_pointer_assign (gfc_expr *lval
}
if (lvalue->symtree->n.sym->attr.flavor == FL_PROCEDURE
- && lvalue->symtree->n.sym->attr.use_assoc)
+ && lvalue->symtree->n.sym->attr.use_assoc
+ && !lvalue->symtree->n.sym->attr.proc_pointer)
{
gfc_error ("'%s' in the pointer assignment at %L cannot be an "
"l-value since it is a procedure",
--
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 |2008-11-16 18:59:41
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug fortran/36463] [4.4 regression] gfc_get_default_type(): Bad symbol
--- Comment #16 from janus at gcc dot gnu dot org 2008-11-17 22:56 --- > I don't know if it is solving the right problem, but at least the testcase in > comment #13 compiles with it. This indeed fixes it. Nice job. Obviously I was looking for the solution in the wrong places. Btw it also makes comment #12 compile, while the resulting executable produces a segfault. But I guess this is due to the weird things which this program does(?). Thanks for finding this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36463
[Bug fortran/38290] ICE with invalid proc-pointer
--- Comment #1 from janus at gcc dot gnu dot org 2008-11-27 22:09 ---
The test case can be further compressed to a 3-liner
procedure( up ) :: p
call p
end
and is fixed by the following simple patch
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 142171)
+++ gcc/fortran/resolve.c (working copy)
@@ -2748,7 +2748,8 @@ resolve_specific_s0 (gfc_code *c, gfc_sy
/* See if we have an intrinsic interface. */
if (sym->ts.interface != NULL && !sym->ts.interface->attr.abstract
- && !sym->ts.interface->attr.subroutine)
+ && !sym->ts.interface->attr.subroutine
+ && sym->ts.interface->attr.intrinsic)
{
gfc_intrinsic_sym *isym;
--
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 |2008-11-27 22:09:01
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38290
[Bug fortran/38289] "procedure( ), pointer" rejected
--- Comment #3 from janus at gcc dot gnu dot org 2008-11-27 22:16 --- (In reply to comment #2) > Is this enough? I guess so :) -- 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 |2008-11-27 22:16:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38289
[Bug fortran/38290] ICE with invalid proc-pointer
--- Comment #2 from janus at gcc dot gnu dot org 2008-11-27 22:50 --- I also tried to compile the other procptr examples from the WikiBooks page, which is linked in comment #0. The only remaining problem I found was: program bsp implicit none abstract interface subroutine up() end subroutine up end interface procedure( up ) , pointer :: pptr pptr => add contains function add( a, b ) integer :: add integer, intent( in ) :: a, b add = a + b end function add end program bsp This is currently accepted by gfortran, although invalid, and is rejected e.g. by ifort with error #8179: The procedure pointer and the procedure target must both be functions or subroutines. Inserting a statement like print *, pptr() produces an ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38290
[Bug fortran/36463] gfc_get_default_type(): Bad symbol
--- Comment #19 from janus at gcc dot gnu dot org 2008-11-28 11:54 --- Since comment #13 is fixed, this should not be labeled a regression any more I guess. Are there still problems with comment #12 (apart from PR35810), or can we close this PR? -- janus at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.4 regression]|gfc_get_default_type(): Bad |gfc_get_default_type(): Bad |symbol |symbol | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36463
[Bug fortran/36463] gfc_get_default_type(): Bad symbol
--- Comment #22 from janus at gcc dot gnu dot org 2008-11-28 13:47 --- (In reply to comment #21) > We could as well add James' gptr as a test case for a procedure pointer PR > (there is probably one?). Yeah, it's PR 36704. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36463
[Bug fortran/36704] Procedure pointer as function result
--- Comment #1 from janus at gcc dot gnu dot org 2008-11-28 21:26 --- Btw the examples in comment #0 slightly miss the point, since they lack the POINTER attribute. Correct version: function foo() result(bar) procedure(),pointer :: bar and function foo() procedure(),pointer :: foo -- 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 |2008-11-28 21:26:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36704
[Bug fortran/36463] gfc_get_default_type(): Bad symbol
--- Comment #23 from janus at gcc dot gnu dot org 2008-11-29 11:25 --- 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=36463
[Bug fortran/38289] "procedure( ), pointer" rejected
--- Comment #4 from janus at gcc dot gnu dot org 2008-11-29 13:38 --- Subject: Bug 38289 Author: janus Date: Sat Nov 29 13:36:35 2008 New Revision: 142276 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142276 Log: 2008-11-29 Janus Weil <[EMAIL PROTECTED]> Mikael Morin <[EMAIL PROTECTED]> PR fortran/38289 PR fortran/38290 * decl.c (match_procedure_decl): Handle whitespaces. * resolve.c (resolve_specific_s0): Bugfix in check for intrinsic interface. 2008-11-29 Janus Weil <[EMAIL PROTECTED]> Tobias Burnus <[EMAIL PROTECTED]> PR fortran/38289 PR fortran/38290 * gfortran.dg/proc_decl_1.f90: Extended test case. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/proc_decl_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38289
[Bug fortran/38290] ICE with invalid proc-pointer
--- Comment #3 from janus at gcc dot gnu dot org 2008-11-29 13:38 --- Subject: Bug 38290 Author: janus Date: Sat Nov 29 13:36:35 2008 New Revision: 142276 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142276 Log: 2008-11-29 Janus Weil <[EMAIL PROTECTED]> Mikael Morin <[EMAIL PROTECTED]> PR fortran/38289 PR fortran/38290 * decl.c (match_procedure_decl): Handle whitespaces. * resolve.c (resolve_specific_s0): Bugfix in check for intrinsic interface. 2008-11-29 Janus Weil <[EMAIL PROTECTED]> Tobias Burnus <[EMAIL PROTECTED]> PR fortran/38289 PR fortran/38290 * gfortran.dg/proc_decl_1.f90: Extended test case. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/proc_decl_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38290
[Bug fortran/38289] "procedure( ), pointer" rejected
--- Comment #5 from janus at gcc dot gnu dot org 2008-11-29 13:39 --- Fixed with r142276. 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=38289
[Bug fortran/37254] Reject valid PROCEDURE statement with implicit interface
--- Comment #6 from janus at gcc dot gnu dot org 2008-11-30 12:28 --- I'm not sure the codes in comment #1 and #3 are actually valid, or if gfortran is right to reject them. See also PR33162 comment #9, where Jerry concludes that a similar thing should be rejected (this is proc_decl_8.f90 is the testsuite). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37254
[Bug fortran/37254] Reject valid PROCEDURE statement with implicit interface
--- Comment #7 from janus at gcc dot gnu dot org 2008-11-30 17:42 --- Regarding the validity see also http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/5d2154a34072eb72/d9d7f1edde9aaa5b -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37254
[Bug fortran/36704] Procedure pointer as function result
--- Comment #2 from janus at gcc dot gnu dot org 2008-11-30 17:50 --- Created an attachment (id=16793) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16793&action=view) patch v1 Attached is a minimal patch, which makes the simple case work where a separate result variable is used, like in this example: procedure(real),pointer :: p p => foo() print *,p(1.0) contains function foo() result(bar) procedure(real),pointer :: bar bar => sin end function end -- 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36704
[Bug fortran/36704] Procedure pointer as function result
--- Comment #3 from janus at gcc dot gnu dot org 2008-11-30 22:00 --- Created an attachment (id=16795) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16795&action=view) patch v2 This updated patch passes the testsuite without regressions and adds some additional checks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36704
[Bug fortran/38290] procedure pointer assignment checking
-- 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|2008-11-27 22:09:01 |2008-12-02 11:46:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38290
[Bug fortran/38290] procedure pointer assignment checking
--- Comment #4 from janus at gcc dot gnu dot org 2008-12-02 11:59 --- Subject: Bug 38290 Author: janus Date: Tue Dec 2 11:58:16 2008 New Revision: 142351 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142351 Log: 2008-12-02 Janus Weil <[EMAIL PROTECTED]> PR fortran/36704 PR fortran/38290 * decl.c (match_result): Result may be a standard variable or a procedure pointer. * expr.c (gfc_check_pointer_assign): Additional checks for procedure pointer assignments. * primary.c (gfc_match_rvalue): Bugfix for procedure pointer assignments. * resolve.c (resolve_function): Check for attr.subroutine. * symbol.c (check_conflict): Addtional checks for RESULT statements. * trans-types.c (gfc_sym_type,gfc_get_function_type): Support procedure pointers as function result. 2008-12-02 Janus Weil <[EMAIL PROTECTED]> PR fortran/36704 PR fortran/38290 * gfortran.dg/entry_7.f90: Modified. * gfortran.dg/proc_ptr_2.f90: Extended. * gfortran.dg/proc_ptr_3.f90: Modified. * gfortran.dg/proc_ptr_11.f90: New. * gfortran.dg/proc_ptr_12.f90: New. * gfortran.dg/result_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_11.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_12.f90 trunk/gcc/testsuite/gfortran.dg/result_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/entry_7.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_2.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38290
[Bug fortran/38290] procedure pointer assignment checking
--- Comment #5 from janus at gcc dot gnu dot org 2008-12-02 12:02 --- Fixed with r142351. 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=38290
[Bug fortran/36704] Procedure pointer as function result
--- Comment #4 from janus at gcc dot gnu dot org 2008-12-02 11:59 --- Subject: Bug 36704 Author: janus Date: Tue Dec 2 11:58:16 2008 New Revision: 142351 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142351 Log: 2008-12-02 Janus Weil <[EMAIL PROTECTED]> PR fortran/36704 PR fortran/38290 * decl.c (match_result): Result may be a standard variable or a procedure pointer. * expr.c (gfc_check_pointer_assign): Additional checks for procedure pointer assignments. * primary.c (gfc_match_rvalue): Bugfix for procedure pointer assignments. * resolve.c (resolve_function): Check for attr.subroutine. * symbol.c (check_conflict): Addtional checks for RESULT statements. * trans-types.c (gfc_sym_type,gfc_get_function_type): Support procedure pointers as function result. 2008-12-02 Janus Weil <[EMAIL PROTECTED]> PR fortran/36704 PR fortran/38290 * gfortran.dg/entry_7.f90: Modified. * gfortran.dg/proc_ptr_2.f90: Extended. * gfortran.dg/proc_ptr_3.f90: Modified. * gfortran.dg/proc_ptr_11.f90: New. * gfortran.dg/proc_ptr_12.f90: New. * gfortran.dg/result_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_11.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_12.f90 trunk/gcc/testsuite/gfortran.dg/result_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/entry_7.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_2.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36704
[Bug fortran/38415] New: procedure pointer assignment to abstract interface
The following program is currently accepted, although it is invalid: abstract interface subroutine bar(a) integer :: a end subroutine bar end interface procedure(bar), pointer :: foo foo => bar end This problem was found by Tobias. -- Summary: procedure pointer assignment to abstract interface Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: accepts-invalid 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=38415
[Bug fortran/38415] procedure pointer assignment to abstract interface
--- Comment #1 from janus at gcc dot gnu dot org 2008-12-05 18:48 --- Btw ifort 11 accepts this, while the g95 version I have (from Sep. 5 2008) gives an ICE. -- 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 |2008-12-05 18:48:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38415
[Bug fortran/38415] procedure pointer assignment to abstract interface
--- Comment #2 from janus at gcc dot gnu dot org 2008-12-06 12:17 --- Subject: Bug 38415 Author: janus Date: Sat Dec 6 12:15:49 2008 New Revision: 142520 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142520 Log: 2008-12-06 Janus Weil <[EMAIL PROTECTED]> PR fortran/38415 * expr.c (gfc_check_pointer_assign): Added a check for abstract interfaces in procedure pointer assignments, removed check involving gfc_compare_interfaces until PR38290 is fixed completely. 2008-12-06 Janus Weil <[EMAIL PROTECTED]> PR fortran/38415 * gfortran.dg/proc_ptr_2.f90: Extended. * gfortran.dg/proc_ptr_11.f90: Modified. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/proc_ptr_11.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38415
[Bug fortran/38415] procedure pointer assignment to abstract interface
--- Comment #3 from janus at gcc dot gnu dot org 2008-12-06 12:18 --- Fixed with r142520. 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=38415
[Bug fortran/38290] procedure pointer assignment checking
--- Comment #6 from janus at gcc dot gnu dot org 2008-12-06 12:23 --- Reopening. The check for comparing the interfaces was taken out again in r142520, since there were problems with intrinsics. Details will follow. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38290
[Bug fortran/38290] procedure pointer assignment checking
--- Comment #8 from janus at gcc dot gnu dot org 2008-12-06 13:57 --- Created an attachment (id=16841) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16841&action=view) patch v1 Here is a draft patch which correctly copies the typespec and formal args for a PROCEDURE statement with INTRINSIC interface. It also makes gfc_compare_interfaces work with intrinsics and re-enables the interface check for procedure pointer assignments. Stuff like the following should work now: procedure(iabs),pointer::p1 procedure(f), pointer::p2 ! valid p1 => iabs p2 => iabs p1 => f p2 => f p2 => p1 p1 => p2 ! invalid p1 => abs p2 => abs contains integer function f(x) integer :: x f = 317 end function end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38290
[Bug fortran/38152] ICE for procedure pointer assignment
--- Comment #8 from janus at gcc dot gnu dot org 2009-01-15 22:56 --- Created an attachment (id=17110) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17110&action=view) patch Here is a patch which fixes the testcases in comment #0, #1 and #7. Dominique: Maybe you could check whether the problems from comment #4 and #5 still persist. Can we still get this into 4.4? In a way the ICE is a regression, since 4.3 just gave an error message (stating that procedure pointers are not implemented) but no ICE. -- 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug fortran/36704] Procedure pointer as function result
--- Comment #5 from janus at gcc dot gnu dot org 2009-01-16 09:42 --- Further test cases: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/e0d04d755453a2a5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36704
[Bug fortran/38152] [4.4 Regression] procedure pointers as module variables
--- Comment #10 from janus at gcc dot gnu dot org 2009-01-16 12:04 --- Subject: Bug 38152 Author: janus Date: Fri Jan 16 12:03:51 2009 New Revision: 143430 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143430 Log: 2009-01-16 Janus Weil PR fortran/38152 * expr.c (gfc_check_pointer_assign): Allow use-associated procedure pointers as lvalue. * trans-decl.c (get_proc_pointer_decl,gfc_create_module_variable): Enable procedure pointers as module variables. 2009-01-16 Janus Weil PR fortran/38152 * gfortran.dg/proc_ptr_13.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_13.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug fortran/38152] [4.4 Regression] procedure pointers as module variables
--- Comment #11 from janus at gcc dot gnu dot org 2009-01-16 12:30 --- This PR can be closed, provided there are no remaining issues on darwin9 (see comment #4 and #5). I cannot check this myself (since I don't have access to a darwin system), but maybe Dominique can? -- janus at gcc dot gnu dot org changed: What|Removed |Added CC||dominiq at lps dot ens dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug fortran/39998] Procedure Pointer Assignments: Statement Functions & Internal Functions
-- 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||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2009-05-05 20:17:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39998
[Bug fortran/39996] Double typing of function results not detected
--- Comment #1 from janus at gcc dot gnu dot org 2009-05-05 20:35 --- Extended test case, including six similar cases, of which only the first three are detected (comment #0 corresponds to case 'E'): ! Detected: interface real function A () end function end interface real :: A ! Error: Symbol 'a' at (1) already has basic type of REAL ! Detected: real :: B interface real function B () ! Error: Function 'b' at (1) already has a type of REAL end function end interface ! Detected: interface function C () real :: C end function end interface real :: C ! Error: Symbol 'c' at (1) already has basic type of REAL ! Not Detected: real :: D interface function D () real :: D end function end interface ! Not Detected: interface function E () result (s) real ::s end function end interface real :: E ! Not Detected: real :: F interface function F () result (s) real ::s end function F end interface 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 |2009-05-05 20:35:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39996
[Bug fortran/39998] Procedure Pointer Assignments: Statement Functions & Internal Functions
--- Comment #1 from janus at gcc dot gnu dot org 2009-05-05 20:41 --- Subject: Bug 39998 Author: janus Date: Tue May 5 20:41:00 2009 New Revision: 147133 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147133 Log: 2009-05-05 Janus Weil PR fortran/39998 * expr.c (gfc_check_pointer_assign): Check for statement functions and internal procedures in procedure pointer assignments. 2009-05-05 Janus Weil PR fortran/39998 * gfortran.dg/proc_ptr_17.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_17.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39998
[Bug fortran/39998] Procedure Pointer Assignments: Statement Functions & Internal Functions
--- Comment #2 from janus at gcc dot gnu dot org 2009-05-05 20:47 --- Fixed in r147133. 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=39998
[Bug fortran/40039] New: Procedures as actual arguments: Check intent of arguments
Consider the following module:
module m
contains
subroutine a(x,f)
real :: x
interface
real function f(y)
real,intent(in) :: y
end function
end interface
print *,f(x)
end subroutine
real function func(z)
real,intent(inout) :: z
func = z**2
end function
subroutine caller
call a(4.3,func)
end subroutine
end module
ifort complains:
error #7061: The characteristics of dummy argument 1 of the associated actual
procedure differ from the characteristics of dummy argument 1 of the dummy
procedure. (12.2) [FUNC]
call a(4.3,func)
Although gfortran, g95 and sunf95 accept it, I think ifort is right to reject
it (but I haven't checked the standard yet). The same check should also be
applied to procedure pointer assignments.
Btw "gfortran -Wall -Wextra" produces this warning:
test.f90:5: warning: unused parameter f
This is bogus, because 'f' *is* used in the subroutine a.
--
Summary: Procedures as actual arguments: Check intent of
arguments
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: accepts-invalid
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=40039
[Bug fortran/40045] New: ICE with type extension and -fdump-parse-tree
Segfault with -fdump-parse-tree: type t end type type, extends(t) :: t2 end type t2 end -- Summary: ICE with type extension and -fdump-parse-tree Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-invalid-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=40045
[Bug fortran/40045] ICE with type extension and -fdump-parse-tree
--- Comment #3 from janus at gcc dot gnu dot org 2009-05-06 14:58 ---
(In reply to comment #2)
> and the interesting question is: Why is it called? There are no type-bound
> procedures (and also no components [except of t2%t].
If it's a regression it may be caused by Daniel's r146733 ("reworking
type-bound procedures")?!?
> Related problem: The following gives: show_code_node(): Bad statement code
I will handle this in my PPC patch before committing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
CC||domob at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40045
[Bug fortran/39630] Fortran 2003: Procedure Pointer Components
--- Comment #3 from janus at gcc dot gnu dot org 2009-05-06 21:17 --- Subject: Bug 39630 Author: janus Date: Wed May 6 21:17:16 2009 New Revision: 147206 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147206 Log: 2009-05-06 Janus Weil Paul Thomas PR fortran/39630 * decl.c (match_procedure_interface): New function to match the interface for a PROCEDURE statement. (match_procedure_decl): Call match_procedure_interface. (match_ppc_decl): New function to match the declaration of a procedure pointer component. (gfc_match_procedure): Call match_ppc_decl. (match_binding_attributes): Add new argument 'ppc' and handle the POINTER attribute for procedure pointer components. (match_procedure_in_type,gfc_match_generic): Added new argument to match_binding_attributes. * dump-parse-tree.c (show_expr,show_components,show_code_node): Handle procedure pointer components. * expr.c (free_expr0,gfc_copy_expr,gfc_simplify_expr): Handle EXPR_PPC. (gfc_check_pointer_assign): Handle procedure pointer components, but no full checking yet. (is_proc_ptr_comp): New function to determine if an expression is a procedure pointer component. * gfortran.h (expr_t): Add EXPR_PPC. (symbol_attribute): Add new member 'proc_pointer_comp'. (gfc_component): Add new member 'formal'. (gfc_exec_op): Add EXEC_CALL_PPC. (gfc_get_default_type): Changed first argument. (is_proc_ptr_comp): Add prototype. (gfc_match_varspec): Add new argument. * interface.c (compare_actual_formal): Handle procedure pointer components. * match.c (gfc_match_pointer_assignment,match_typebound_call): Handle procedure pointer components. * module.c (mio_expr): Handle EXPR_PPC. * parse.c (parse_derived): Handle procedure pointer components. * primary.c (gfc_match_varspec): Add new argument 'ppc_arg' and handle procedure pointer components. (gfc_variable_attr): Handle procedure pointer components. (gfc_match_rvalue): Added new argument to gfc_match_varspec and changed first argument of gfc_get_default_type. (match_variable): Added new argument to gfc_match_varspec. * resolve.c (resolve_entries,set_type,resolve_fl_parameter): Changed first argument of gfc_get_default_type. (resolve_structure_cons,resolve_actual_arglist): Handle procedure pointer components. (resolve_ppc_call): New function to resolve a call to a procedure pointer component (subroutine). (resolve_expr_ppc): New function to resolve a call to a procedure pointer component (function). (gfc_resolve_expr): Handle EXPR_PPC. (resolve_code): Handle EXEC_CALL_PPC. (resolve_fl_derived): Copy the interface for a procedure pointer component. (resolve_symbol): Fix overlong line. * st.c (gfc_free_statement): Handle EXEC_CALL_PPC. * symbol.c (gfc_get_default_type): Changed first argument. (gfc_set_default_type): Changed first argument of gfc_get_default_type. (gfc_add_component): Initialize ts.type to BT_UNKNOWN. * trans.h (gfc_conv_function_call): Renamed. * trans.c (gfc_trans_code): Handle EXEC_CALL_PPC. * trans-expr.c (gfc_conv_component_ref): Ditto. (gfc_conv_function_val): Rename to 'conv_function_val', add new argument 'expr' and handle procedure pointer components. (gfc_conv_operator_assign): Renamed gfc_conv_function_val. (gfc_apply_interface_mapping_to_expr): Handle EXPR_PPC. (gfc_conv_function_call): Rename to 'gfc_conv_procedure_call', add new argument 'expr' and handle procedure pointer components. (gfc_get_proc_ptr_comp): New function to get the backend decl for a procedure pointer component. (gfc_conv_function_expr): Renamed gfc_conv_function_call. (gfc_conv_structure): Handle procedure pointer components. * trans-intrinsic.c (gfc_conv_intrinsic_funcall, conv_generic_with_optional_char_arg): Renamed gfc_conv_function_call. * trans-stmt.h (gfc_get_proc_ptr_comp): Add prototype. * trans-stmt.c (gfc_trans_call): Renamed gfc_conv_function_call. * trans-types.h (gfc_get_ppc_type): Add prototype. * trans-types.c (gfc_get_ppc_type): New function to build a tree node for a procedure pointer component. (gfc_get_derived_type): Handle procedure pointer components. 2009-05-06 Janus Weil PR fortran/39630 * gfortran.dg/proc_decl_1.f90: Modified. * gfortran.dg/proc_ptr_comp_1.f90: New. * gfortran.dg/proc_ptr_comp_2.f90: New. * gfortran.dg/proc_ptr_comp_3.f90: New.
[Bug fortran/39630] Fortran 2003: Procedure Pointer Components
--- Comment #4 from janus at gcc dot gnu dot org 2009-05-06 21:23 --- Status: r147206 implements PPCs with NOPASS, but PASS is still missing ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39630
[Bug fortran/39876] module procedure name that collides with the GNU intrinsic
--- Comment #4 from janus at gcc dot gnu dot org 2009-05-06 22:07 ---
> From the little I understand 'external' should not be set to 1 for functions
> listed as intrinsics but not f95 intrinsics.
I don't see any reason why 'erfc' should get the EXTERNAL attribute here at
all. In any case this happens in gfc_is_intrinsic:
/* See if this intrinsic is allowed in the current standard. */
if (gfc_check_intrinsic_standard (isym, &symstd, false, loc) == FAILURE)
{
if (gfc_option.warn_intrinsics_std)
gfc_warning_now ("The intrinsic '%s' at %L is not included in the"
" selected standard but %s and '%s' will be treated
as"
" if declared EXTERNAL. Use an appropriate -std=*"
" option or define -fall-intrinsics to allow this"
" intrinsic.", sym->name, &loc, symstd, sym->name);
sym->attr.external = 1;
return false;
}
This code was committed as r138122 by Daniel K. as a fix for PR33141, but it
doesn't seem quite right to me. Either one should avoid setting the EXTERNAL
attribute here at all, or at least only do it if the symbol is not specified by
the user as a module procedure.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
----------------------------
CC||janus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39876
[Bug fortran/40054] New: Fortran 2008: Pointer functions as lvalue
See section 6.2 in ftp://ftp.nag.co.uk/sc22wg5/N1701-N1750/N1729.pdf. In principle functions which return a pointer work already (even with procedure pointers). AFAICS, the only thing missing is using these functions as lvalue, as in this example: real, dimension(1:100), target :: array real, pointer :: p array(5) = 0.7 print *,storage(5) p => storage(3) p = 0.5 print *,p storage(5) = 0.5 ! Error: 'storage' at (1) is not a variable contains function storage(key) result(loc) integer, intent(in) :: key real, pointer :: loc loc => array(key) end function end -- Summary: Fortran 2008: Pointer functions as lvalue Product: gcc Version: 4.5.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=40054
[Bug fortran/39876] module procedure name that collides with the GNU intrinsic
-- 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|2009-04-24 05:22:22 |2009-05-07 19:11:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39876
[Bug fortran/40039] Procedures as actual arguments: Check intent of arguments
--- Comment #2 from janus at gcc dot gnu dot org 2009-05-07 21:44 ---
Here is a preliminary patch which correctly rejects the code in comment #0:
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (revision 147246)
+++ gcc/fortran/interface.c (working copy)
@@ -873,23 +873,29 @@
which makes this test much easier than that for generic tests.
This subroutine is also used when comparing a formal and actual
- argument list when an actual parameter is a dummy procedure. At
- that point, two formal interfaces must be compared for equality
- which is what happens here. */
+ argument list when an actual parameter is a dummy procedure, and in
+ procedure pointer assignments. In these cases, two formal interfaces must
be
+ compared for equality which is what happens here. */
static int
operator_correspondence (gfc_formal_arglist *f1, gfc_formal_arglist *f2)
{
for (;;)
{
+ /* Check existence. */
if (f1 == NULL && f2 == NULL)
break;
if (f1 == NULL || f2 == NULL)
return 1;
+ /* Check type and rank. */
if (!compare_type_rank (f1->sym, f2->sym))
return 1;
+ /* Check intent. */
+ if (f1->sym->attr.intent != f2->sym->attr.intent)
+ return 1;
+
f1 = f1->next;
f2 = f2->next;
}
However, it produces three testsuite failures:
FAIL: gfortran.dg/defined_operators_1.f90 -O (test for errors, line 14)
FAIL: gfortran.dg/interface_19.f90 -O0 (test for excess errors)
FAIL: gfortran.dg/proc_ptr_result_1.f90 -O0 (test for excess errors)
The last of these three test cases is probably invalid, the second failure
seems to be a problem with intrinsics, and about the first one I'm not sure.
--
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 |2009-05-07 21:44:33
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40039
[Bug fortran/39876] module procedure name that collides with the GNU intrinsic
--- Comment #5 from janus at gcc dot gnu dot org 2009-05-08 09:08 --- Subject: Bug 39876 Author: janus Date: Fri May 8 09:08:13 2009 New Revision: 147279 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147279 Log: 2009-05-08 Janus Weil PR fortran/39876 * intrinsic.c (gfc_is_intrinsic): Do not add the EXTERNAL attribute if the symbol is a module procedure. 2009-05-08 Janus Weil PR fortran/39876 * gfortran.dg/intrinsic_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/intrinsic_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39876
[Bug fortran/39876] module procedure name that collides with the GNU intrinsic
--- Comment #6 from janus at gcc dot gnu dot org 2009-05-08 09:11 --- Fixed with r147279. 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=39876
[Bug fortran/39996] Double typing of function results not detected
-- 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|2009-05-05 20:35:34 |2009-05-09 20:53:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39996
[Bug fortran/40089] New: Public type with public component which has a private type
Please consider the following code:
module m
implicit none
private
public :: public_t
public :: public_sub
!public :: private_t (*)
type :: private_t
integer :: i
end type
type :: public_t
type(private_t), pointer :: public_comp_with_private_type !(#1)
procedure(ifc) , nopass, pointer :: ppc
end type
abstract interface
integer function ifc ()
end function
end interface
type(private_t), save, public :: public_var_with_private_type !(#2)
contains
subroutine public_sub(arg)!(#3)
type(private_t) :: arg
end subroutine
end module m
program test
use m
implicit none
type(public_t) :: x
integer :: j
print *,public_var_with_private_type%i
j = x%ppc() ! Error: Can't convert UNKNOWN to INTEGER(4)
end
With current trunk versions of gfortran, this produces the error indicated in
the last line of the program. Of course this error is bogus, since ppc has an
explicit interface (with an integer return type).
However, I believe this program is invalid for the following reason: The type
'public_t' is public in the module m, and it has a public component, indicated
by (#1), whose type is private in the module. So this component is accessible
outside of the module, but its type is not.
Up to now I was not able to find a rule in the F03 Standard, which explicitly
forbids this. But my common sense tells me that it should be invalid (hoping my
common sense works alright).
Following the same reasoning, the cases (#2) and (#3) should be invalid, too,
but none of them is detected by gfortran. Unfortunately, I could not find any
other compiler which rejects the program (ifort and g95 accept it). Still I
think it is invalid.
If the line indicated by (*) is uncommented, the error message goes away. With
this modification the program should be valid, and all is fine.
Thanks to Juergen Reuter for reporting this.
--
Summary: Public type with public component which has a private
type
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=40089
[Bug fortran/40089] Public type with public component which has a private type
--- Comment #2 from janus at gcc dot gnu dot org 2009-05-11 08:23 --- > Thus I would reason that g95, ifort and NAG (assuming Juergen Reuter is using > it) are correct in accepting it. NAG indeed accepts it with -f2003. With -f95 it reports Extension: c0.f90, line 32: Dummy ARG of PUBLIC_SUB exposes PRIVATE type PRIVATE_T detected at M@ Extension: c0.f90, line 32: Variable PUBLIC_VAR_WITH_PRIVATE_TYPE exposes PRIVATE type PRIVATE_T detected at M@ Extension: c0.f90, line 32: Component PUBLIC_COMP_WITH_PRIVATE_TYPE of type PUBLIC_T exposes PRIVATE type PRIVATE_T detected at M@ Probably it is really valid in F2003, and my common sense just failed. I will try to fix gfortran's bogus error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40089
[Bug fortran/40089] Public type with public component which has a private type
--- Comment #3 from janus at gcc dot gnu dot org 2009-05-11 09:55 ---
Actually gfortran even has the same check as NAG that rejects a private type as
component of a public type with -std=f95. And it happens that the bug which
leads to the bogus error message lies just in this check. Thus the fix is easy:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 147349)
+++ gcc/fortran/resolve.c (working copy)
@@ -9088,11 +9088,11 @@ resolve_fl_derived (gfc_symbol *sym)
&& !gfc_check_access (c->ts.derived->attr.access,
c->ts.derived->ns->default_access))
{
- gfc_notify_std (GFC_STD_F2003, "Fortran 2003: the component '%s' "
+ if (gfc_notify_std (GFC_STD_F2003, "Fortran 2003: the component '%s'
"
"is a PRIVATE type and cannot be a component of "
"'%s', which is PUBLIC at %L", c->name,
- sym->name, &sym->declared_at);
- return FAILURE;
+ sym->name, &sym->declared_at) == FAILURE)
+ return FAILURE;
}
if (sym->attr.sequence)
--
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 |2009-05-11 09:55:35
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40089
[Bug fortran/40089] Public type with public component which has a private type
--- Comment #5 from janus at gcc dot gnu dot org 2009-05-11 14:14 --- Subject: Bug 40089 Author: janus Date: Mon May 11 14:14:38 2009 New Revision: 147379 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147379 Log: 2009-05-11 Janus Weil PR fortran/40089 * resolve.c (resolve_fl_derived): Only return FAILURE if gfc_notify_std fails. 2009-05-11 Janus Weil PR fortran/40089 * gfortran.dg/proc_ptr_comp_7.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40089
[Bug fortran/40089] Public type with public component which has a private type
--- Comment #6 from janus at gcc dot gnu dot org 2009-05-11 14:19 --- Fixed with r147379. 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=40089
[Bug fortran/40039] Procedures as actual arguments: Check intent of arguments
--- Comment #3 from janus at gcc dot gnu dot org 2009-05-13 17:15 --- > FAIL: gfortran.dg/interface_19.f90 -O0 (test for excess errors) > FAIL: gfortran.dg/proc_ptr_result_1.f90 -O0 (test for excess errors) > > The last of these three test cases is probably invalid, the second failure > seems to be a problem with intrinsics, and about the first one I'm not sure. For intrinsics, the intent of the arguments is currently not considered at all. We need gfc_intrinsic_arg to have an 'intent' member. The F03 standard says: The dummy arguments of the specific intrinsic procedures in 13.6 have INTENT(IN). The dummy arguments of the generic intrinsic procedures in 13.7 have INTENT(IN) if the intent is not stated explicitly. The test case proc_ptr_result_1.f90 is invalid indeed. Relevant quote from the standard: Section 5.1.2.7: INTENT (INOUT) is not equivalent to omitting the INTENT attribute. The argument corresponding to an INTENT (INOUT) dummy argument always shall be definable, while an argument corresponding to a dummy argument without an INTENT attribute need be definable only if the dummy argument is actually redefined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40039
[Bug fortran/39996] Double typing of function results not detected
--- Comment #2 from janus at gcc dot gnu dot org 2009-05-14 09:42 --- Subject: Bug 39996 Author: janus Date: Thu May 14 09:41:41 2009 New Revision: 147528 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147528 Log: 2009-05-14 Janus Weil PR fortran/39996 * decl.c (gfc_match_function_decl): Use gfc_add_type. * symbol.c (gfc_add_type): Better checking for duplicate types in function declarations. And: Always give an error for duplicte types, not just a warning with -std=gnu. 2009-05-14 Janus Weil PR fortran/39996 * gfortran.dg/func_decl_2.f90: Modified (replacing warnings by errors). * gfortran.dg/duplicate_type_2.f90: Ditto. * gfortran.dg/duplicate_type_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/duplicate_type_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/duplicate_type_2.f90 trunk/gcc/testsuite/gfortran.dg/func_decl_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39996
[Bug fortran/39996] Double typing of function results not detected
--- Comment #3 from janus at gcc dot gnu dot org 2009-05-14 09:46 --- Fixed with r147528. 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=39996
[Bug fortran/40164] New: Fortran 2003: "Arrays of procedure pointers"
PROGRAM test_prog
TYPE ProcPointerArray
PROCEDURE(add), POINTER, NOPASS :: f
END TYPE ProcPointerArray
TYPE (ProcPointerArray) :: f_array(1)
PROCEDURE(add), POINTER :: f
f_array(1)%f => add
f => f_array(1)%f
PRINT*, f(2.,4.)
CONTAINS
FUNCTION add(a,b) RESULT(sum)
REAL, INTENT(in) :: a, b
REAL :: sum
sum = a + b
END FUNCTION add
END PROGRAM test_prog
This produces the error
f => f_array(1)%f
1
Error: VARIABLE attribute of 'f_array' conflicts with PROCEDURE attribute at
(1)
Reported by Barron Bichon.
--
Summary: Fortran 2003: "Arrays of procedure pointers"
Product: gcc
Version: 4.5.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=40164
[Bug fortran/40164] Fortran 2003: "Arrays of procedure pointers"
--- Comment #1 from janus at gcc dot gnu dot org 2009-05-15 21:51 ---
Here is a small patch which fixes the test case:
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c (revision 147527)
+++ gcc/fortran/primary.c (working copy)
@@ -2558,7 +2558,7 @@
if (gfc_matching_procptr_assignment)
{
gfc_gobble_whitespace ();
- if (gfc_peek_ascii_char () == '(')
+ if (!sym->attr.dimension && gfc_peek_ascii_char () == '(')
/* Parse functions returning a procptr. */
goto function0;
--
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 |2009-05-15 21:51:18
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40164
[Bug fortran/40164] Fortran 2003: "Arrays of procedure pointers" (using PPCs)
--- Comment #2 from janus at gcc dot gnu dot org 2009-05-16 14:09 --- Adding in the test case a line like print *, f_array(1)%f(3.,5.) produces a segfault in gfc_conv_scalarized_array_ref (trans-array.c, 2414). -- janus at gcc dot gnu dot org changed: What|Removed |Added Summary|Fortran 2003: "Arrays of|Fortran 2003: "Arrays of |procedure pointers" |procedure pointers" (using ||PPCs) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40164
[Bug fortran/40176] New: Fortran 2003: Procedure pointers with array return value
The following program compiles without errors, but gives a segfault at runtime: PROGRAM test_prog PROCEDURE(triple), POINTER :: f ! This works print *,triple(2.,4.) ! This creates a Segmentation Fault f => triple print *,f(2.,4.) CONTAINS FUNCTION triple(a,b) RESULT(tre) REAL, INTENT(in) :: a, b REAL :: tre(2) tre(1) = 3.*a tre(2) = 3.*b END FUNCTION triple END PROGRAM test_prog Reported by Barron Bichon. -- Summary: Fortran 2003: Procedure pointers with array return value 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=40176
[Bug fortran/40176] Fortran 2003: Procedure pointers with array return value
--- Comment #1 from janus at gcc dot gnu dot org 2009-05-17 14:13 ---
-fdump-parse-tree yields:
triple (struct array1_real(kind=4) & __result, real(kind=4) & a, real(kind=4) &
b)
{
...
}
real(kind=4) (*) (real(kind=4) &, real(kind=4) &) f;
f = (real(kind=4) (*) (real(kind=4) &, real(kind=4) &)) triple;
So it seems like something goes wrong in the declaration of 'f', (which should
be equal to 'triple')?!?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40176
[Bug fortran/36947] Attributes not fully checked comparing actual vs dummy procedure
--- Comment #6 from janus at gcc dot gnu dot org 2009-05-18 09:19 --- Subject: Bug 36947 Author: janus Date: Mon May 18 09:19:20 2009 New Revision: 147655 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147655 Log: 2009-05-18 Janus Weil PR fortran/36947 PR fortran/40039 * expr.c (gfc_check_pointer_assign): Check intents when comparing interfaces. * gfortran.h (typedef struct gfc_intrinsic_arg): Add 'intent' member. (gfc_compare_interfaces): Additional argument. * interface.c (operator_correspondence): Add check for equality of intents, and new argument 'intent_check'. (gfc_compare_interfaces): New argument 'intent_check', which is passed on to operator_correspondence. (check_interface1): Don't check intents when comparing interfaces. (compare_parameter): Do check intents when comparing interfaces. * intrinsic.c (add_sym): Add intents for arguments of intrinsic procedures. (add_sym_1,add_sym_1s,add_sym_1m,add_sym_2,add_sym_2s,add_sym_3, add_sym_3ml,add_sym_3red,add_sym_3s,add_sym_4): Use INTENT_IN by default. (add_sym_1_intent,add_sym_1s_intent,add_sym_2s_intent,add_sym_3s_intent) : New functions to add intrinsic symbols, specifying custom intents. (add_sym_4s,add_sym_5s): Add new arguments to specify intents. (add_functions,add_subroutines): Add intents for various intrinsics. * resolve.c (check_generic_tbp_ambiguity): Don't check intents when comparing interfaces. * symbol.c (gfc_copy_formal_args_intr): Copy intent. 2009-05-18 Janus Weil PR fortran/36947 PR fortran/40039 * gfortran.dg/interface_27.f90: New. * gfortran.dg/interface_28.f90: New. * gfortran.dg/proc_ptr_11.f90: Fixing invalid test case. * gfortran.dg/proc_ptr_result_1.f90: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/interface_27.f90 trunk/gcc/testsuite/gfortran.dg/interface_28.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/proc_ptr_11.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_result_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36947
[Bug fortran/40039] Procedures as actual arguments: Check intent of arguments
--- Comment #4 from janus at gcc dot gnu dot org 2009-05-18 09:19 --- Subject: Bug 40039 Author: janus Date: Mon May 18 09:19:20 2009 New Revision: 147655 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147655 Log: 2009-05-18 Janus Weil PR fortran/36947 PR fortran/40039 * expr.c (gfc_check_pointer_assign): Check intents when comparing interfaces. * gfortran.h (typedef struct gfc_intrinsic_arg): Add 'intent' member. (gfc_compare_interfaces): Additional argument. * interface.c (operator_correspondence): Add check for equality of intents, and new argument 'intent_check'. (gfc_compare_interfaces): New argument 'intent_check', which is passed on to operator_correspondence. (check_interface1): Don't check intents when comparing interfaces. (compare_parameter): Do check intents when comparing interfaces. * intrinsic.c (add_sym): Add intents for arguments of intrinsic procedures. (add_sym_1,add_sym_1s,add_sym_1m,add_sym_2,add_sym_2s,add_sym_3, add_sym_3ml,add_sym_3red,add_sym_3s,add_sym_4): Use INTENT_IN by default. (add_sym_1_intent,add_sym_1s_intent,add_sym_2s_intent,add_sym_3s_intent) : New functions to add intrinsic symbols, specifying custom intents. (add_sym_4s,add_sym_5s): Add new arguments to specify intents. (add_functions,add_subroutines): Add intents for various intrinsics. * resolve.c (check_generic_tbp_ambiguity): Don't check intents when comparing interfaces. * symbol.c (gfc_copy_formal_args_intr): Copy intent. 2009-05-18 Janus Weil PR fortran/36947 PR fortran/40039 * gfortran.dg/interface_27.f90: New. * gfortran.dg/interface_28.f90: New. * gfortran.dg/proc_ptr_11.f90: Fixing invalid test case. * gfortran.dg/proc_ptr_result_1.f90: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/interface_27.f90 trunk/gcc/testsuite/gfortran.dg/interface_28.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/proc_ptr_11.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_result_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40039
[Bug fortran/40039] Procedures as actual arguments: Check intent of arguments
--- Comment #5 from janus at gcc dot gnu dot org 2009-05-18 09:28 --- The commit in comment #4 implements the basic checking of the intents. ToDo: * Improve the error message, which is currently just "Type/rank mismatch in argument ...". Should specify exactly what is not matching, and in which argument. * Fix the intents of non-std intrinsics (which are currently all intent(in)). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40039
[Bug fortran/36947] Attributes not fully checked comparing actual vs dummy procedure
--- Comment #7 from janus at gcc dot gnu dot org 2009-05-18 09:36 --- The commit in comment #6 implements the checking for intents. ToDo: * check for OPTIONAL * better error messages * recursive check (see comment #2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36947
[Bug fortran/40176] Fortran 2003: Procedure pointers with array return value
--- Comment #2 from janus at gcc dot gnu dot org 2009-05-18 12:28 --- This test case with 'dynamic' array size produces a gimplification error: PROGRAM test_prog ABSTRACT INTERFACE FUNCTION fn_template(n,x) RESULT(y) INTEGER, INTENT(in) :: n REAL, INTENT(in) :: x(n) REAL :: y(n) END FUNCTION fn_template END INTERFACE TYPE ProcPointerArray PROCEDURE(fn_template), POINTER, NOPASS :: f END TYPE ProcPointerArray TYPE (ProcPointerArray) :: f_array(1) PROCEDURE(fn_template), POINTER :: f REAL :: tre(2) f_array(1)%f => triple ! gimplification error f => f_array(1)%f tre = f(2,[2.,4.]) PRINT*, tre CONTAINS FUNCTION triple(n,x) RESULT(tre) INTEGER, INTENT(in) :: n REAL, INTENT(in) :: x(n) REAL :: tre(n) tre = 3.*x END FUNCTION triple END PROGRAM test_prog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40176
[Bug fortran/40164] Fortran 2003: "Arrays of procedure pointers" (using PPCs)
--- Comment #3 from janus at gcc dot gnu dot org 2009-05-18 14:45 --- Subject: Bug 40164 Author: janus Date: Mon May 18 14:44:55 2009 New Revision: 147663 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147663 Log: 2009-05-18 Janus Weil PR fortran/40164 * primary.c (gfc_match_rvalue): Handle procedure pointer components in arrays. * resolve.c (resolve_ppc_call,resolve_expr_ppc): Resolve component and array references. (resolve_fl_derived): Procedure pointer components are not required to have constant array bounds in their return value. 2009-05-18 Janus Weil PR fortran/40164 * gfortran.dg/proc_ptr_comp_8.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40164
[Bug fortran/40164] Fortran 2003: "Arrays of procedure pointers" (using PPCs)
--- Comment #4 from janus at gcc dot gnu dot org 2009-05-18 14:47 --- Fixed with r147663. 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=40164
[Bug fortran/40176] Fortran 2003: Procedure pointers with array return value
--- Comment #3 from janus at gcc dot gnu dot org 2009-05-18 16:59 ---
Comment #0 is fixed by the following one-liner patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 147663)
+++ gcc/fortran/resolve.c (working copy)
@@ -9414,6 +9414,7 @@
|| sym->ts.interface->attr.intrinsic)
{
gfc_symbol *ifc = sym->ts.interface;
+ resolve_symbol (ifc);
if (ifc->attr.intrinsic)
resolve_intrinsic (ifc, &ifc->declared_at);
However this does nothing about the gimplification failure in comment #2.
--
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 |2009-05-18 16:59:25
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40176
[Bug fortran/40176] Fortran 2003: Procedure pointers with array return value
--- Comment #4 from janus at gcc dot gnu dot org 2009-05-25 14:48 --- Subject: Bug 40176 Author: janus Date: Mon May 25 14:48:24 2009 New Revision: 147850 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147850 Log: 2009-05-25 Janus Weil PR fortran/40176 * primary.c (gfc_match_varspec): Handle procedure pointer components with array return value. * resolve.c (resolve_expr_ppc): Ditto. (resolve_symbol): Make sure the interface of a procedure pointer has been resolved. * trans-array.c (gfc_walk_function_expr): Handle procedure pointer components with array return value. * trans-expr.c (gfc_conv_component_ref,gfc_conv_procedure_call, gfc_trans_arrayfunc_assign): Ditto. (gfc_trans_pointer_assignment): Handle procedure pointer assignments, where the rhs is a dummy argument. * trans-types.c (gfc_get_ppc_type,gfc_get_derived_type): Handle procedure pointer components with array return value. 2009-05-25 Janus Weil PR fortran/40176 * gfortran.dg/proc_ptr_18.f90: New. * gfortran.dg/proc_ptr_19.f90: New. * gfortran.dg/proc_ptr_comp_9.f90: New. * gfortran.dg/proc_ptr_comp_10.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_18.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_19.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_10.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40176
[Bug fortran/40427] New: [F03] Procedure Pointer Components with OPTIONAL arguments
The following was reported by John McFarland: PROGRAM prog ABSTRACT INTERFACE SUBROUTINE sub_template(i,j,o) INTEGER, INTENT(in) :: i INTEGER, INTENT(in), OPTIONAL :: j, o END SUBROUTINE sub_template END INTERFACE TYPE container PROCEDURE(sub_template), POINTER, NOPASS :: s END TYPE container PROCEDURE(sub_template), POINTER :: s TYPE (container) :: c c%s => sub s => sub CALL callf(s) CALL callfc(c) CONTAINS SUBROUTINE callfc(c) TYPE (container) :: c PRINT*, 'Calling with ppc' CALL c%s(1,o=3) END SUBROUTINE callfc SUBROUTINE callf(f) PROCEDURE(sub_template), OPTIONAL, POINTER :: f PRINT*, 'Calling pp argument' CALL f(1,o=5) END SUBROUTINE callf SUBROUTINE sub(i,arg2,arg3) INTEGER, INTENT(in) :: i INTEGER, INTENT(in), OPTIONAL :: arg2, arg3 PRINT*, 'i:', i PRINT*, 'Present:', PRESENT(arg2), PRESENT(arg3) IF (PRESENT(arg2)) PRINT*, 'arg2:', arg2 IF (PRESENT(arg3)) PRINT*, 'arg3:', arg3 END SUBROUTINE sub END PROGRAM prog This program compiles fine, but produces the output: Calling pp argument i: 1 Present: F T arg3: 5 Calling with ppc i: 1 Present: T T arg2: 3 arg3: -443987883 This means that there is a problem with calling PPCs with optional arguments. -- Summary: [F03] Procedure Pointer Components with OPTIONAL arguments 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=40427
[Bug fortran/40176] Fortran 2003: Procedure pointers with array return value
--- Comment #7 from janus at gcc dot gnu dot org 2009-06-12 20:39 --- Subject: Bug 40176 Author: janus Date: Fri Jun 12 20:39:39 2009 New Revision: 148440 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148440 Log: 2009-06-12 Janus Weil PR fortran/40176 * resolve.c (resolve_symbol): Additional error check, preventing an infinite loop. 2009-06-12 Janus Weil PR fortran/40176 * gfortran.dg/proc_decl_1.f90: Extended. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/proc_decl_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40176
[Bug fortran/40176] Fortran 2003: Procedure pointers with array return value
--- Comment #8 from janus at gcc dot gnu dot org 2009-06-12 20:45 --- The remaining issue from comment #5 has been fixed with the commit in comment #7. So this can be closed. -- 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=40176
[Bug fortran/36947] Attributes not fully checked comparing actual vs dummy 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|2009-03-29 08:26:27 |2009-06-12 20:50:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36947
[Bug fortran/40427] [F03] Procedure Pointer Components with OPTIONAL arguments
-- 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 |2009-06-13 11:33:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40427
[Bug fortran/40450] New: [F03] procedure pointer as actual argument
The following program gives a segfault at runtime:
MODULE m
ABSTRACT INTERFACE
SUBROUTINE sub()
END SUBROUTINE sub
END INTERFACE
CONTAINS
SUBROUTINE passf(f)
PROCEDURE(sub), POINTER:: f
CALL callf(f)
END SUBROUTINE passf
SUBROUTINE callf(f)
PROCEDURE(sub), POINTER :: f
PRINT*, 'calling f'
CALL f()
END SUBROUTINE callf
END MODULE m
PROGRAM prog
USE m
PROCEDURE(sub), POINTER :: f
f => s
CALL passf(f)
CONTAINS
SUBROUTINE s
PRINT*, 'sub'
END SUBROUTINE s
END PROGRAM prog
-fdump-tree-original shows that the problem lies in 'passf':
passf (void (*) (void) * f)
{
callf (&f);
}
--
Summary: [F03] procedure pointer as actual argument
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=40450
[Bug fortran/40039] Procedures as actual arguments: Check intent of arguments
--- Comment #6 from janus at gcc dot gnu dot org 2009-06-16 09:06 --- Subject: Bug 40039 Author: janus Date: Tue Jun 16 09:06:13 2009 New Revision: 148519 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148519 Log: 2009-06-16 Janus Weil PR fortran/36947 PR fortran/40039 * expr.c (gfc_check_pointer_assign): Call 'gfc_compare_interfaces' with error message. * gfortran.h (gfc_compare_interfaces): Additional argument. * interface.c (operator_correspondence): Removed. (gfc_compare_interfaces): Additional argument to return error message. Directly use the code from 'operator_correspondence' instead of calling the function. Check for OPTIONAL. Some rearrangements. (check_interface1): Call 'gfc_compare_interfaces' without error message. (compare_parameter): Call 'gfc_compare_interfaces' with error message. * resolve.c (check_generic_tbp_ambiguity): Call 'gfc_compare_interfaces' without error message. 2009-06-16 Janus Weil PR fortran/36947 PR fortran/40039 * gfortran.dg/dummy_procedure_1.f90: Extended test case. * gfortran.dg/interface_20.f90: Modified error messages. * gfortran.dg/interface_21.f90: Ditto. * gfortran.dg/interface_26.f90: Ditto. * gfortran.dg/interface_27.f90: Ditto. * gfortran.dg/interface_28.f90: Extended test case. * gfortran.dg/interface_29.f90: New. * gfortran.dg/proc_decl_7.f90: Modified error messages. * gfortran.dg/proc_decl_8.f90: Ditto. * gfortran.dg/proc_ptr_11.f90: Ditto. * gfortran.dg/proc_ptr_15.f90: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/interface_29.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/dummy_procedure_1.f90 trunk/gcc/testsuite/gfortran.dg/interface_20.f90 trunk/gcc/testsuite/gfortran.dg/interface_21.f90 trunk/gcc/testsuite/gfortran.dg/interface_26.f90 trunk/gcc/testsuite/gfortran.dg/interface_27.f90 trunk/gcc/testsuite/gfortran.dg/interface_28.f90 trunk/gcc/testsuite/gfortran.dg/proc_decl_7.f90 trunk/gcc/testsuite/gfortran.dg/proc_decl_8.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_11.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_15.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40039
[Bug fortran/36947] Attributes not fully checked comparing actual vs dummy procedure
--- Comment #9 from janus at gcc dot gnu dot org 2009-06-16 09:06 --- Subject: Bug 36947 Author: janus Date: Tue Jun 16 09:06:13 2009 New Revision: 148519 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148519 Log: 2009-06-16 Janus Weil PR fortran/36947 PR fortran/40039 * expr.c (gfc_check_pointer_assign): Call 'gfc_compare_interfaces' with error message. * gfortran.h (gfc_compare_interfaces): Additional argument. * interface.c (operator_correspondence): Removed. (gfc_compare_interfaces): Additional argument to return error message. Directly use the code from 'operator_correspondence' instead of calling the function. Check for OPTIONAL. Some rearrangements. (check_interface1): Call 'gfc_compare_interfaces' without error message. (compare_parameter): Call 'gfc_compare_interfaces' with error message. * resolve.c (check_generic_tbp_ambiguity): Call 'gfc_compare_interfaces' without error message. 2009-06-16 Janus Weil PR fortran/36947 PR fortran/40039 * gfortran.dg/dummy_procedure_1.f90: Extended test case. * gfortran.dg/interface_20.f90: Modified error messages. * gfortran.dg/interface_21.f90: Ditto. * gfortran.dg/interface_26.f90: Ditto. * gfortran.dg/interface_27.f90: Ditto. * gfortran.dg/interface_28.f90: Extended test case. * gfortran.dg/interface_29.f90: New. * gfortran.dg/proc_decl_7.f90: Modified error messages. * gfortran.dg/proc_decl_8.f90: Ditto. * gfortran.dg/proc_ptr_11.f90: Ditto. * gfortran.dg/proc_ptr_15.f90: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/interface_29.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/dummy_procedure_1.f90 trunk/gcc/testsuite/gfortran.dg/interface_20.f90 trunk/gcc/testsuite/gfortran.dg/interface_21.f90 trunk/gcc/testsuite/gfortran.dg/interface_26.f90 trunk/gcc/testsuite/gfortran.dg/interface_27.f90 trunk/gcc/testsuite/gfortran.dg/interface_28.f90 trunk/gcc/testsuite/gfortran.dg/proc_decl_7.f90 trunk/gcc/testsuite/gfortran.dg/proc_decl_8.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_11.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_15.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36947
[Bug fortran/36947] Attributes not fully checked comparing actual vs dummy procedure
--- Comment #10 from janus at gcc dot gnu dot org 2009-06-16 09:14 --- >From the ToDo items in comment #7, r148519 fixes the first two (check for optional and better error messages). The remaining item (recursive check) is tracked by PR 40453, so I think this PR can be closed. -- 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=36947
[Bug fortran/40039] Procedures as actual arguments: Check intent of arguments
--- Comment #7 from janus at gcc dot gnu dot org 2009-06-16 09:17 --- r148519 improves the error messages (besides adding a check for optional), so the remaining ToDo item for this PR is: Fixing the intents of non-std intrinsics (which are currently all intent(in)). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40039
[Bug fortran/40461] Interface mismatch in dummy procedure
--- Comment #2 from janus at gcc dot gnu dot org 2009-06-16 17:50 --- (In reply to comment #0) > This is presumably connected with PR 36947/40039 written by Janus Weil. Indeed. > I don't know whether the error message is valid. It surely is, since the interfaces of your subroutines 'Logistic4' and 'deriv' just don't match (their arguments should have the same intent). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40461
[Bug fortran/40451] procedure-pointer assignment rejected
--- Comment #2 from janus at gcc dot gnu dot org 2009-06-17 08:33 --- The test case is also rejected without being inside a module: contains function f() intrinsic :: sin procedure(sin), pointer :: f f => sin end function f end However, if the 'contains' is removed, it is accepted. -- 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 |2009-06-17 08:33:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40451
[Bug fortran/40451] [F03] procedure pointer assignment rejected
--- Comment #3 from janus at gcc dot gnu dot org 2009-06-17 08:54 --- The error also goes away if 'implicit none' is inserted. -- janus at gcc dot gnu dot org changed: What|Removed |Added Summary|procedure-pointer assignment|[F03] procedure pointer |rejected|assignment rejected http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40451
[Bug fortran/40451] [F03] procedure pointer assignment rejected
--- Comment #4 from janus at gcc dot gnu dot org 2009-06-17 09:26 ---
Mine. Here's a patch:
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 148518)
+++ gcc/fortran/symbol.c(working copy)
@@ -317,7 +317,7 @@ gfc_check_function_type (gfc_namespace *
if (!proc->attr.contained || proc->result->attr.implicit_type)
return;
- if (proc->result->ts.type == BT_UNKNOWN)
+ if (proc->result->ts.type == BT_UNKNOWN && proc->result->ts.interface ==
NULL)
{
if (gfc_set_default_type (proc->result, 0, gfc_current_ns)
== SUCCESS)
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 148519)
+++ gcc/fortran/resolve.c (working copy)
@@ -347,7 +347,7 @@ resolve_contained_fntype (gfc_symbol *sy
return;
/* Try to find out of what the return type is. */
- if (sym->result->ts.type == BT_UNKNOWN)
+ if (sym->result->ts.type == BT_UNKNOWN && sym->result->ts.interface == NULL)
{
t = gfc_set_default_type (sym->result, 0, ns);
--
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|2009-06-17 08:33:58 |2009-06-17 09:26:05
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40451
[Bug fortran/40451] [F03] procedure pointer assignment rejected
--- Comment #5 from janus at gcc dot gnu dot org 2009-06-18 08:09 --- Subject: Bug 40451 Author: janus Date: Thu Jun 18 08:09:40 2009 New Revision: 148652 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148652 Log: 2009-06-18 Janus Weil PR fortran/40451 * resolve.c (resolve_contained_fntype): Prevent implicit typing for procedures with explicit interface. * symbol.c (gfc_check_function_type): Ditto. 2009-06-18 Janus Weil PR fortran/40451 * gfortran.dg/proc_ptr_result_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_result_4.f90 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=40451
[Bug fortran/40451] [F03] procedure pointer assignment rejected
--- Comment #6 from janus at gcc dot gnu dot org 2009-06-18 08:13 --- Fixed with r148652. 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=40451
[Bug fortran/40450] [F03] procedure pointer as actual argument
--- Comment #1 from janus at gcc dot gnu dot org 2009-06-18 20:27 ---
Here is a preliminary patch which fixes the test case:
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 148651)
+++ gcc/fortran/trans-expr.c(working copy)
@@ -2646,7 +2646,9 @@ gfc_conv_procedure_call (gfc_se * se, gf
if (fsym && e->expr_type != EXPR_NULL
&& ((fsym->attr.pointer
&& fsym->attr.flavor != FL_PROCEDURE)
- || fsym->attr.proc_pointer))
+ || (fsym->attr.proc_pointer
+ && !(e->expr_type == EXPR_VARIABLE
+ && e->symtree->n.sym->attr.dummy
{
/* Scalar pointer dummy args require an extra level of
indirection. The null pointer already contains
--
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 |2009-06-18 20:27:30
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40450
[Bug fortran/40450] [F03] procedure pointer as actual argument
--- Comment #3 from janus at gcc dot gnu dot org 2009-06-19 08:11 --- Subject: Bug 40450 Author: janus Date: Fri Jun 19 08:11:21 2009 New Revision: 148690 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148690 Log: 2009-06-19 Janus Weil PR fortran/40450 * trans-expr.c (gfc_conv_procedure_call): Only add an extra addr_expr to a procedure pointer actual argument, if it is not itself a dummy arg. 2009-06-19 Janus Weil PR fortran/40450 * gfortran.dg/proc_ptr_20.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_20.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=40450
[Bug fortran/40450] [F03] procedure pointer as actual argument
--- Comment #4 from janus at gcc dot gnu dot org 2009-06-19 08:16 --- Fixed with r148690. 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=40450
[Bug fortran/40117] [F08] Type-bound procedure: allow list after PROCEDURE
-- janus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||39627 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-19 08:27:03 date|| Summary|F2008: Type-bound procedure:|[F08] Type-bound procedure: |allow list after PROCEDURE |allow list after PROCEDURE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40117
[Bug fortran/39850] Too strict checking for procedures as actual argument
--- Comment #1 from janus at gcc dot gnu dot org 2009-06-20 14:11 --- After the improvement of error messages, the test case gives: Error: Interface mismatch in dummy procedure 'a' at (1): 'func' is not a function 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|2009-04-22 16:55:59 |2009-06-20 14:11:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39850
[Bug fortran/39850] Too strict checking for procedures as actual argument
--- Comment #2 from janus at gcc dot gnu dot org 2009-06-20 14:41 --- Btw, if comment #0 is correct, then the test case 'interface_21.f90' is wrong (that is: the test case itself is legal, but the dg-error is wrong). It was added by Jerry DeLisle in r129799, in connection with PR33162. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39850
[Bug fortran/39850] Too strict checking for procedures as actual argument
--- Comment #3 from janus at gcc dot gnu dot org 2009-06-20 15:17 --- (In reply to comment #2) > Btw, if comment #0 is correct, then the test case 'interface_21.f90' is wrong Same goes for proc_decl_8.f90. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39850
[Bug fortran/39850] Too strict checking for procedures as actual argument
--- Comment #5 from janus at gcc dot gnu dot org 2009-06-21 19:05 --- Subject: Bug 39850 Author: janus Date: Sun Jun 21 19:05:35 2009 New Revision: 148767 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148767 Log: 2009-06-21 Janus Weil PR fortran/39850 * interface.c (gfc_compare_interfaces): Take care of implicit typing when checking the function attribute. Plus another bugfix. (compare_parameter): Set attr.function and attr.subroutine according to the usage of a procedure as actual argument. 2009-06-21 Janus Weil PR fortran/39850 * gfortran.dg/interface_19.f90: Add 'cleanup-modules'. * gfortran.dg/interface_20.f90: Ditto. * gfortran.dg/interface_21.f90: Ditto. * gfortran.dg/interface_22.f90: Ditto. * gfortran.dg/interface_30.f90: New. * gfortran.dg/proc_ptr_11.f90: Fix invalid test case. Added: trunk/gcc/testsuite/gfortran.dg/interface_30.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/interface_19.f90 trunk/gcc/testsuite/gfortran.dg/interface_20.f90 trunk/gcc/testsuite/gfortran.dg/interface_21.f90 trunk/gcc/testsuite/gfortran.dg/interface_22.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_11.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39850
[Bug fortran/39850] Too strict checking for procedures as actual argument
--- Comment #6 from janus at gcc dot gnu dot org 2009-06-21 19:16 --- Fixed with r148767. 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=39850
[Bug fortran/39850] Too strict checking for procedures as actual argument
--- Comment #8 from janus at gcc dot gnu dot org 2009-06-22 09:04 ---
> pr39850.f90:12:0: internal compiler error: in gfc_typenode_for_spec, at
> fortran/trans-types.c:995
Yeah, the same happens for the examples in PR37254. I didn't notice it before,
since I changed the test case slightly in my commit. Here is a patch which
fixes it:
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (revision 148778)
+++ gcc/fortran/interface.c (working copy)
@@ -1407,9 +1407,14 @@
}
if (formal->attr.function && !act_sym->attr.function)
- gfc_add_function (&act_sym->attr, act_sym->name,
&act_sym->declared_at);
-
- if (formal->attr.subroutine && !act_sym->attr.subroutine)
+ {
+ gfc_add_function (&act_sym->attr, act_sym->name,
+ &act_sym->declared_at);
+ if (act_sym->ts.type == BT_UNKNOWN
+ && gfc_set_default_type (act_sym, 1, act_sym->ns) == FAILURE)
+ return 0;
+ }
+ else if (formal->attr.subroutine && !act_sym->attr.subroutine)
gfc_add_subroutine (&act_sym->attr, act_sym->name,
&act_sym->declared_at);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39850
[Bug fortran/37254] Reject valid PROCEDURE statement with implicit interface
--- Comment #8 from janus at gcc dot gnu dot org 2009-06-22 21:02 ---
Subject: Bug 37254
Author: janus
Date: Mon Jun 22 21:02:19 2009
New Revision: 148816
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148816
Log:
2009-06-22 Janus Weil
PR fortran/37254
PR fortran/39850
* interface.c (compare_parameter): Set implicit type for function
actual arguments with BT_UNKNOWN.
2009-06-22 Janus Weil
PR fortran/37254
PR fortran/39850
* gfortran.dg/interface_30.f90: Modified error message.
* gfortran.dg/proc_decl_22.f90: New.
Added:
trunk/gcc/testsuite/gfortran.dg/proc_decl_22.f90 (with props)
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/interface_30.f90
Propchange: trunk/gcc/testsuite/gfortran.dg/proc_decl_22.f90
('svn:executable' added)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37254
[Bug fortran/39850] Too strict checking for procedures as actual argument
--- Comment #10 from janus at gcc dot gnu dot org 2009-06-22 21:02 ---
Subject: Bug 39850
Author: janus
Date: Mon Jun 22 21:02:19 2009
New Revision: 148816
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148816
Log:
2009-06-22 Janus Weil
PR fortran/37254
PR fortran/39850
* interface.c (compare_parameter): Set implicit type for function
actual arguments with BT_UNKNOWN.
2009-06-22 Janus Weil
PR fortran/37254
PR fortran/39850
* gfortran.dg/interface_30.f90: Modified error message.
* gfortran.dg/proc_decl_22.f90: New.
Added:
trunk/gcc/testsuite/gfortran.dg/proc_decl_22.f90 (with props)
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/interface_30.f90
Propchange: trunk/gcc/testsuite/gfortran.dg/proc_decl_22.f90
('svn:executable' added)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39850
[Bug fortran/37254] Reject valid PROCEDURE statement with implicit interface
--- Comment #9 from janus at gcc dot gnu dot org 2009-06-22 21:08 --- r148816 fixes comment #1 and #3. The errors in comment #4 are justified, since subroutines and functions are mixed. So I think this can be closed if there are no further problems. -- 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|2008-08-27 12:33:17 |2009-06-22 21:08:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37254
[Bug fortran/37254] Reject valid PROCEDURE statement with implicit interface
--- Comment #10 from janus at gcc dot gnu dot org 2009-06-22 21:28 ---
Subject: Bug 37254
Author: janus
Date: Mon Jun 22 21:28:34 2009
New Revision: 148817
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148817
Log:
2009-06-22 Janus Weil
PR fortran/37254
* gfortran.dg/proc_decl_22.f90: Delete property svn:executable
(wrongly introduced in last commit).
Modified:
trunk/gcc/testsuite/gfortran.dg/proc_decl_22.f90 (props changed)
Propchange: trunk/gcc/testsuite/gfortran.dg/proc_decl_22.f90
('svn:executable' removed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37254
[Bug fortran/38894] c_f_procpointer/c_f_pointer - add missing argument checking
--- Comment #2 from janus at gcc dot gnu dot org 2009-06-22 21:56 --- The missing checks are due to the following code in interface.c (compare_parameter): if (formal->ts.type == BT_DERIVED && formal->ts.derived && formal->ts.derived->ts.is_iso_c && actual->ts.type == BT_DERIVED && actual->ts.derived && actual->ts.derived->ts.is_iso_c) return 1; Either this should be removed altogether, or at least the derived types should be checked for equality. However, removing it causes iso_c_binding_rename_1.f03 to fail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38894
[Bug fortran/38894] c_f_procpointer/c_f_pointer - add missing argument checking
--- Comment #3 from janus at gcc dot gnu dot org 2009-06-22 22:21 --- This patch gives the correct error messages for comment #1, while avoiding the testsuite failure of iso_c_binding_rename_1.f03: Index: gcc/fortran/interface.c === --- gcc/fortran/interface.c (revision 148816) +++ gcc/fortran/interface.c (working copy) @@ -1382,7 +1382,9 @@ compare_parameter (gfc_symbol *formal, g if (formal->ts.type == BT_DERIVED && formal->ts.derived && formal->ts.derived->ts.is_iso_c && actual->ts.type == BT_DERIVED - && actual->ts.derived && actual->ts.derived->ts.is_iso_c) + && actual->ts.derived && actual->ts.derived->ts.is_iso_c + && (formal->ts.derived->attr.use_rename + || actual->ts.derived->attr.use_rename)) return 1; if (actual->ts.type == BT_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|2009-03-29 08:47:29 |2009-06-22 22:21:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38894
