[Bug fortran/38894] c_f_procpointer/c_f_pointer - add missing argument checking
--- Comment #5 from janus at gcc dot gnu dot org 2009-06-23 15:43 --- (In reply to comment #2) > 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; In my opinion this code is some kind of workaround for a lower-lying problem. It just turns off the type checking, which is definitely not the right thing to do (as this PR shows). The actual bug, which causes the failure of iso_c_binding_rename_1.f03, seems to be specific to ISO_C_BINDING with use-renaming. I tried to reproduce this by use-renaming ordinary derived types, but did not succeed. If you look at the error messages in iso_c_binding_rename_1.f03, something definitely goes wrong there: iso_c_binding_rename_1.f03:29.29: if(.not. my_c_associated(my_ptr)) then 1 Error: Type mismatch in argument 'c_ptr_1' at (1); passed TYPE(my_c_ptr) to TYPE(my_c_ptr_0) This error happens in the routine 'sub1', where the type 'my_c_ptr_0' is not even accessible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38894
[Bug fortran/37254] Reject valid PROCEDURE statement with implicit interface
--- Comment #11 from janus at gcc dot gnu dot org 2009-06-23 07:27 --- 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=37254
[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
[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/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/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/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 #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 #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/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 #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 #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 #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 #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/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/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/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 #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/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/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 #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 #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] 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/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/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/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/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/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/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/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/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/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/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/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 #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/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/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/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/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/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/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/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/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/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/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/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/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] 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/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/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/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/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/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 #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 #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] 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/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/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/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/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
-- 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/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
--- 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/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/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/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/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/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/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/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/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
-- 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/39998] New: Procedure Pointer Assignments: Statement Functions & Internal Functions
According to the following passage of the Fortran 2003 standard, statement functions and internal functions are forbidden in procedure pointer assignments: C727 (R742) A procedure-name shall be the name of an external, module, or dummy procedure, a specific intrinsic function listed in 13.6 and not marked with a bullet (â¢), or a procedure pointer. Test cases: f(x) = x**2 procedure(), pointer :: p p => f print *, p(4.0) end ** procedure(), pointer :: p p => sub contains subroutine sub end subroutine sub end ** Internal functions, however, are valid in Fortran 2008. Thanks to Tobias for reporting this. -- Summary: Procedure Pointer Assignments: Statement Functions & Internal Functions 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=39998
[Bug fortran/39946] PROCEDURE statements: interface with RESULT variable
--- Comment #3 from janus at gcc dot gnu dot org 2009-04-28 16:31 --- Fixed with r146905. 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=39946
[Bug fortran/39946] PROCEDURE statements: interface with RESULT variable
--- Comment #2 from janus at gcc dot gnu dot org 2009-04-28 16:27 --- Subject: Bug 39946 Author: janus Date: Tue Apr 28 16:27:27 2009 New Revision: 146905 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146905 Log: 2009-04-28 Janus Weil PR fortran/39946 * resolve.c (resolve_symbol): Correctly copy the interface of a PROCEDURE statement if the interface involves a RESULT variable. 2009-04-28 Janus Weil PR fortran/39946 * gfortran.dg/proc_ptr_16.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_16.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39946
[Bug fortran/39946] PROCEDURE statements: interface with RESULT variable
--- Comment #1 from janus at gcc dot gnu dot org 2009-04-28 14:52 ---
Here's a patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (Revision 146879)
+++ gcc/fortran/resolve.c (Arbeitskopie)
@@ -9244,7 +9244,10 @@ resolve_symbol (gfc_symbol *sym)
if (ifc->attr.intrinsic)
resolve_intrinsic (ifc, &ifc->declared_at);
- sym->ts = ifc->ts;
+ if (ifc->result)
+ sym->ts = ifc->result->ts;
+ else
+ sym->ts = ifc->ts;
sym->ts.interface = ifc;
sym->attr.function = ifc->attr.function;
sym->attr.subroutine = ifc->attr.subroutine;
--
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-04-28 14:52:49
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39946
[Bug fortran/39946] New: PROCEDURE statements: interface with RESULT variable
The following program procedure(prc_is_allowed), pointer :: fptr interface function prc_is_allowed (flv, hel, col) result (is_allowed) logical :: is_allowed integer, intent(in) :: flv, hel, col end function prc_is_allowed end interface fptr => prc_is_allowed end currently fails with fptr => prc_is_allowed 1 Error: Interfaces don't match in procedure pointer assignment at (1) which is nonsense, of course. This seems to be due to a bug in the implementation of PROCEDURE statements and was only discovered after PR39735 was fixed (checking of return values in procedure pointer assignments). The test case was provided by Juergen Reuter. -- Summary: PROCEDURE statements: interface with RESULT variable 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=39946
[Bug fortran/39931] ICE on invalid Fortran 95 code (bad pointer assignment), gimplify_expr at gimplify.c:6315
--- Comment #6 from janus at gcc dot gnu dot org 2009-04-28 10:52 --- Fixed with r146880. 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=39931
[Bug fortran/39930] Bogus error: ambiguous reference
--- Comment #3 from janus at gcc dot gnu dot org 2009-04-28 10:50 --- Fixed with r146880. 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=39930
[Bug fortran/39930] Bogus error: ambiguous reference
-- 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-04-28 09:46:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39930
[Bug fortran/39930] Bogus error: ambiguous reference
--- Comment #2 from janus at gcc dot gnu dot org 2009-04-28 09:44 --- Subject: Bug 39930 Author: janus Date: Tue Apr 28 09:44:36 2009 New Revision: 146880 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146880 Log: 2009-04-28 Janus Weil PR fortran/39930 PR fortran/39931 * expr.c (gfc_check_pointer_assign): Correctly detect if the left hand side is a pointer. * parse.c (gfc_fixup_sibling_symbols): Don't check for ambiguity. 2009-04-28 Janus Weil PR fortran/39930 PR fortran/39931 * gfortran.dg/ambiguous_reference_2.f90: New. * gfortran.dg/pointer_assign_7.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/ambiguous_reference_2.f90 trunk/gcc/testsuite/gfortran.dg/pointer_assign_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/parse.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39930
[Bug fortran/39931] ICE on invalid Fortran 95 code (bad pointer assignment), gimplify_expr at gimplify.c:6315
--- Comment #5 from janus at gcc dot gnu dot org 2009-04-28 09:44 --- Subject: Bug 39931 Author: janus Date: Tue Apr 28 09:44:36 2009 New Revision: 146880 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146880 Log: 2009-04-28 Janus Weil PR fortran/39930 PR fortran/39931 * expr.c (gfc_check_pointer_assign): Correctly detect if the left hand side is a pointer. * parse.c (gfc_fixup_sibling_symbols): Don't check for ambiguity. 2009-04-28 Janus Weil PR fortran/39930 PR fortran/39931 * gfortran.dg/ambiguous_reference_2.f90: New. * gfortran.dg/pointer_assign_7.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/ambiguous_reference_2.f90 trunk/gcc/testsuite/gfortran.dg/pointer_assign_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/parse.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39931
[Bug fortran/39931] ICE on invalid Fortran 95 code (bad pointer assignment), gimplify_expr at gimplify.c:6315
--- Comment #4 from janus at gcc dot gnu dot org 2009-04-27 19:09 ---
Patch:
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (Revision 146847)
+++ gcc/fortran/expr.c (Arbeitskopie)
@@ -3070,8 +3070,8 @@
if (pointer)
check_intent_in = 0;
- if (ref->type == REF_COMPONENT && ref->u.c.component->attr.pointer)
- pointer = 1;
+ if (ref->type == REF_COMPONENT)
+ pointer = ref->u.c.component->attr.pointer;
if (ref->type == REF_ARRAY && ref->next == NULL)
{
--
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-27 17:54:23 |2009-04-27 19:09:03
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39931
[Bug fortran/39931] ICE on invalid Fortran 95 code (bad pointer assignment), gimplify_expr at gimplify.c:6315
--- Comment #3 from janus at gcc dot gnu dot org 2009-04-27 18:04 --- An error message should be emitted already in the front end, probably in gfc_check_pointer_assign (expr.c). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39931
[Bug fortran/39931] ICE on invalid Fortran 95 code (bad pointer assignment), gimplify_expr at gimplify.c:6315
-- 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 |2009-04-27 17:54:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39931
[Bug fortran/39930] Bogus error: ambiguous reference
--- Comment #1 from janus at gcc dot gnu dot org 2009-04-27 16:54 ---
Something like this should do it:
Index: gcc/fortran/parse.c
===
--- gcc/fortran/parse.c (Revision 146826)
+++ gcc/fortran/parse.c (Arbeitskopie)
@@ -3310,7 +3310,7 @@ gfc_fixup_sibling_symbols (gfc_symbol *s
sym->attr.referenced = 1;
for (ns = siblings; ns; ns = ns->sibling)
{
- gfc_find_sym_tree (sym->name, ns, 0, &st);
+ st = gfc_find_symtree (ns->sym_root, sym->name);
if (!st || (st->n.sym->attr.dummy && ns == st->n.sym->ns))
goto fixup_contained;
It seems a bit unfortunate that we have two functions with almost the same name
(gfc_find_sym_tree and gfc_find_symtree), which do almost the same, but not
quite. The little difference is important here. Maybe one of these functions
should be renamed to make the usage clearer?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39930
[Bug fortran/39930] New: Bogus error: ambiguous reference
Consider the following set of modules: module a1 contains subroutine myRoutine end subroutine end module module a2 contains subroutine myRoutine end subroutine end module module b contains subroutine otherRoutine use a1 use a2 call myRoutine ! this is ambiguous ! end subroutine subroutine myRoutine end subroutine myRoutine ! this is not ambiguous ! end module Feeding this to gfortran gives two errors: all.f90:19.18: call myRoutine ! this is ambiguous ! 1 Error: Name 'myroutine' at (1) is an ambiguous reference to 'myroutine' from module 'a1' all.f90:23.52: end subroutine myRoutine ! this is not ambiguous ! 1 Error: Name 'myroutine' at (1) is an ambiguous reference to 'myroutine' from module 'a1' This first error is ok, the second is bogus. Same for all gfortran versions I tried (4.3.3, 4.4.0 and trunk). -- Summary: Bogus error: ambiguous reference 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 GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39930
[Bug fortran/39688] IMPORT of derived type fails
--- Comment #4 from janus at gcc dot gnu dot org 2009-04-25 08:13 --- Fixed in r146762. 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=39688
[Bug fortran/39688] IMPORT of derived type fails
--- Comment #3 from janus at gcc dot gnu dot org 2009-04-25 08:12 --- Subject: Bug 39688 Author: janus Date: Sat Apr 25 08:11:48 2009 New Revision: 146762 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146762 Log: 2009-04-25 Janus Weil PR fortran/39688 * decl.c (gfc_match_import): Use 'sym->name' instead of 'name'. They differ if the symbol has been use-renamed. 2009-04-25 Janus Weil PR fortran/39688 * gfortran.dg/import7.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/import7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39688
[Bug fortran/39688] IMPORT of derived type fails
--- Comment #2 from janus at gcc dot gnu dot org 2009-04-24 19:20 --- Mine. The fix is completely trivial: Index: gcc/fortran/decl.c === --- gcc/fortran/decl.c (Revision 146676) +++ gcc/fortran/decl.c (Arbeitskopie) @@ -2741,7 +2741,7 @@ goto next_item; } - st = gfc_new_symtree (&gfc_current_ns->sym_root, name); + st = gfc_new_symtree (&gfc_current_ns->sym_root, sym->name); st->n.sym = sym; sym->refs++; sym->attr.imported = 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|NEW |ASSIGNED Last reconfirmed|2009-04-24 17:59:23 |2009-04-24 19:20:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39688
[Bug fortran/39688] IMPORT of derived type fails
--- Comment #1 from janus at gcc dot gnu dot org 2009-04-24 17:59 --- Confirmed. Here is a reduced test case, which does not have the problem with T2 discussed in comment #0, but still fails with the same error message: MODULE MOD TYPE T1 TYPE(T1), POINTER :: P END TYPE END PROGRAM MAIN USE MOD, T3 => T1 INTERFACE SUBR SUBROUTINE SUBR1(X) IMPORT T3 TYPE(T3) X END SUBROUTINE END INTERFACE END The error only appears if the imported type is renamed in the USE statement. -- 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-04-24 17:59:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39688
[Bug fortran/39864] [4.5 Regression] INTRINSIC :: RESHAPE causes spurious error
--- Comment #4 from janus at gcc dot gnu dot org 2009-04-24 08:39 --- Fixed by r146677. 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=39864
[Bug fortran/39861] [4.5 Regression] ICE with INTRINSIC in module: write_symbol(): bad module symbol
--- Comment #5 from janus at gcc dot gnu dot org 2009-04-24 08:39 --- Fixed by r146677. 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=39861
[Bug fortran/39864] [4.5 Regression] INTRINSIC :: RESHAPE causes spurious error
--- Comment #3 from janus at gcc dot gnu dot org 2009-04-24 08:34 --- Subject: Bug 39864 Author: janus Date: Fri Apr 24 08:34:14 2009 New Revision: 146677 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146677 Log: 2009-04-24 Janus Weil PR fortran/39861 PR fortran/39864 * symbol.c (gfc_copy_formal_args_intr): Set attr.flavor and attr.dummy for the formal arguments. 2009-04-24 Janus Weil PR fortran/39861 PR fortran/39864 * gfortran.dg/intrinsic_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/intrinsic_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39864
[Bug fortran/39861] [4.5 Regression] ICE with INTRINSIC in module: write_symbol(): bad module symbol
--- Comment #4 from janus at gcc dot gnu dot org 2009-04-24 08:34 --- Subject: Bug 39861 Author: janus Date: Fri Apr 24 08:34:14 2009 New Revision: 146677 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146677 Log: 2009-04-24 Janus Weil PR fortran/39861 PR fortran/39864 * symbol.c (gfc_copy_formal_args_intr): Set attr.flavor and attr.dummy for the formal arguments. 2009-04-24 Janus Weil PR fortran/39861 PR fortran/39864 * gfortran.dg/intrinsic_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/intrinsic_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39861
[Bug fortran/39864] [4.5 Regression] INTRINSIC :: RESHAPE causes spurious error
--- Comment #2 from janus at gcc dot gnu dot org 2009-04-23 20:21 --- > Janus, can you have a look? It looks like another fallout of your patch. Indeed, it is. > If it is not fixable quickly, we should consider backing it out > until we have a working version. The fix is quite trivial, I'll post a patch for this and PR39861 in a minute. I really wonder why these things have not been caught by the testsuite. -- 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-23 12:49:54 |2009-04-23 20:21:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39864
[Bug fortran/39861] [4.5 Regression] ICE with INTRINSIC in module: write_symbol(): bad module symbol
--- Comment #3 from janus at gcc dot gnu dot org 2009-04-23 12:24 ---
> > write_symbol(): bad module symbol 'x'
>
> Where does the symbol 'x' come from?
The 'x' here apparently is the formal argument of the sqrt() function!
I think Dominique was right in suspecting my r146554, which had the effect that
formal arguments from intrinsic functions are now not only kept in the isym,
but are also copied to the gfc_symbol of the intrinsic function (see
'resolve_intrinsic').
The problem seems to be that for those formal args copied from isym the flavor
is not set:
if (sym->attr.flavor == FL_UNKNOWN || sym->attr.flavor == FL_LABEL)
gfc_internal_error ("write_symbol(): bad module symbol '%s'", sym->name);
I will take care of this soon. Thanks for the report.
--
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-23 09:30:47 |2009-04-23 12:24:16
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39861
[Bug fortran/39850] Too strict checking for procedures as actual argument
-- 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 |2009-04-22 16:55:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39850
[Bug fortran/39735] procedure pointer assignments: return value is not checked
--- Comment #2 from janus at gcc dot gnu dot org 2009-04-22 09:24 --- Fixed with r146554. 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=39735
[Bug fortran/39735] procedure pointer assignments: return value 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 |2009-04-22 09:23:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39735
