[Bug fortran/36325] specific or generic INTERFACE implies the EXTERNAL attribute
--- Comment #12 from janus at gcc dot gnu dot org 2008-05-28 21:28 --- Subject: Bug 36325 Author: janus Date: Wed May 28 21:27:56 2008 New Revision: 136130 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136130 Log: 2008-05-28 Janus Weil [EMAIL PROTECTED] PR fortran/36325 PR fortran/35830 * interface.c (gfc_procedure_use): Enable argument checking for external procedures with explicit interface. * symbol.c (check_conflict): Fix conflict checking for externals. (copy_formal_args): Fix handling of arrays. * resolve.c (resolve_specific_f0, resolve_specific_s0): Fix handling of intrinsics. * parse.c (parse_interface): Non-abstract INTERFACE statement implies EXTERNAL attribute. 2008-05-28 Janus Weil [EMAIL PROTECTED] PR fortran/36325 PR fortran/35830 * gfortran.dg/interface_23.f90: New. * gfortran.dg/gomp/reduction3.f90: Fixed invalid code. * gfortran.dg/proc_decl_12.f90: New: * gfortran.dg/external_procedures_1.f90: Fixed error message. Added: trunk/gcc/testsuite/gfortran.dg/interface_23.f90 trunk/gcc/testsuite/gfortran.dg/proc_decl_12.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/external_procedures_1.f90 trunk/gcc/testsuite/gfortran.dg/gomp/reduction3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36325
[Bug fortran/36325] specific or generic INTERFACE implies the EXTERNAL attribute
--- Comment #13 from janus at gcc dot gnu dot org 2008-05-28 21:37 --- Fixed with r136130. 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=36325
[Bug fortran/36325] specific or generic INTERFACE implies the EXTERNAL attribute
--- Comment #1 from jaydub66 at gmail dot com 2008-05-25 14:02 ---
Here is a first patch:
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 135859)
+++ gcc/fortran/symbol.c(working copy)
@@ -439,7 +439,7 @@ check_conflict (symbol_attribute *attr,
conf (external, intrinsic);
conf (entry, intrinsic);
- if ((attr-if_source !attr-procedure) || attr-contained)
+ if ((attr-if_source == IFSRC_DECL !attr-procedure) || attr-contained)
{
conf (external, subroutine);
conf (external, function);
Index: gcc/fortran/parse.c
===
--- gcc/fortran/parse.c (revision 135859)
+++ gcc/fortran/parse.c (working copy)
@@ -1917,12 +1917,26 @@ loop:
new_state = COMP_SUBROUTINE;
gfc_add_explicit_interface (gfc_new_block, IFSRC_IFBODY,
gfc_new_block-formal, NULL);
+ if (current_interface.type != INTERFACE_ABSTRACT
+gfc_add_external (gfc_new_block-attr, gfc_current_locus) ==
FAILURE)
+ {
+ reject_statement ();
+ gfc_free_namespace (gfc_current_ns);
+ goto loop;
+ }
break;
case ST_FUNCTION:
new_state = COMP_FUNCTION;
gfc_add_explicit_interface (gfc_new_block, IFSRC_IFBODY,
gfc_new_block-formal, NULL);
+ if (current_interface.type != INTERFACE_ABSTRACT
+gfc_add_external (gfc_new_block-attr, gfc_current_locus) ==
FAILURE)
+ {
+ reject_statement ();
+ gfc_free_namespace (gfc_current_ns);
+ goto loop;
+ }
break;
case ST_PROCEDURE:
This removes the conflict between EXTERNAL and SUBROUTINE for this case, and
adds the EXTERNAL attribute for a non-abstract INTERFACE statement.
Checking for regressions ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36325
[Bug fortran/36325] specific or generic INTERFACE implies the EXTERNAL attribute
--- Comment #2 from jaydub66 at gmail dot com 2008-05-25 14:45 --- Ok, this produces an impressive list of regressions. Many of those (e.g. actual_procedure_1.f90) seem to be related to conf (external, dimension); /* See Fortran 95's R504. */ I'm not sure if the constraint from R504 is implemented correctly here, or if it constrains too much. Others testcases (like argument_checking_3.f90) fail because they define lots of specific interfaces, but no external implementation for those. So I guess they are actually invalid? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36325
[Bug fortran/36325] specific or generic INTERFACE implies the EXTERNAL attribute
--- Comment #3 from burnus at gcc dot gnu dot org 2008-05-25 15:36 --- Ok, this produces an impressive list of regressions. Many of those (e.g. actual_procedure_1.f90) seem to be related to conf (external, dimension); /* See Fortran 95's R504. */ I'm not sure if the constraint from R504 is implemented correctly here, or if it constrains too much. As written, I believe that R504 entity-decl is object-name [( array-spec )] [ * char-length ] [initialization ] or function-name [ * char-length ] only restricts the use of: REAL, EXTERNAL :: func(10) - array-spec, invalid for function names but not (a) REAL, EXTERNAL, DIMENSION(10) :: func nor (b) the dimension of function results. Despite my failure to find anything in the standard which rejects (a) all my compilers reject it whereas all my compilers allow (b). See also: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/bb371413b5cbe3d7 Others testcases (like argument_checking_3.f90) fail because they define lots of specific interfaces, but no external implementation for those. So I guess they are actually invalid? As I did not apply your patch, I fail to understand this problem. Ignoring the problems with the rank mismatches and too few arguments, the program is valid from the Fortran side. External means that the user somehow needs to provide the foo,bar,foobar procedures, but that is outside of the scope of the Fortran standard (except that also Fortran procedures can be external procedures). In case of gfortran the linker would complain - but it should never reach that point because of the compile-time errors. By the way: The the rank mismatch dg-error and not dg-warning should be used in argument_checking_3.f90. (However, dejagnu does not distingish.) -- burnus 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-05-25 15:36:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36325
[Bug fortran/36325] specific or generic INTERFACE implies the EXTERNAL attribute
--- Comment #4 from janus at gcc dot gnu dot org 2008-05-25 16:37 --- (In reply to comment #2) Others testcases (like argument_checking_3.f90) fail because they define lots of specific interfaces, but no external implementation for those. Obviously I got this wrong. The actual reason for these tests failing is that with my patch all the interfaces acquire the EXTERNAL attribute (which they didn't have before), and apparently there is no argument checking done for external procedures. Which leads me to think we should probably implement this (for the case that the interface is explicit). Or is there any good reason that this is not done? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36325
[Bug fortran/36325] specific or generic INTERFACE implies the EXTERNAL attribute
--- Comment #5 from burnus at gcc dot gnu dot org 2008-05-25 17:11 --- Which leads me to think we should probably implement this (for the case that the interface is explicit). Or is there any good reason that this is not done? Well, regarding the reason: Before interfaces had no EXTERNAL attribute and those procedures with EXTERNAL attribute had no explicit interface. That interfaces have the EXTERNAL attribute only needed for procedure pointers. One could think of not giving the EXTERNAL attribute to procedures declared in interface bodies and modifying POINTER / the pointer resolution only. I'm not sure what is cleaner and simpler. Regarding our questions, Richard Maine (mostly) answered them. See URL in comment #3. conf2(external,dimension) is in any case wrong. It should be: conflict(external with implicit interface, dimension) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36325
[Bug fortran/36325] specific or generic INTERFACE implies the EXTERNAL attribute
--- Comment #6 from janus at gcc dot gnu dot org 2008-05-25 19:08 --- Created an attachment (id=15684) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15684action=view) patch Ok, I extended the patch, and got the regression count down from a few million to exactly two: FAIL: gfortran.dg/proc_decl_9.f90 FAIL: gfortran.dg/gomp/reduction3.f90 What I did was e.g. following Tobi's suggestion about the dimension problem: conf2(external,dimension) is in any case wrong. It should be: conflict(external with implicit interface, dimension) Also I made sure not to interfere with dummy procedures, turned on argument checking for (explicit-interfaced) external procedures and fixed an error message for a test case. I haven't looked at the two remaining regressions in detail, but both seem to be related to intrinsics. And I'm sure I can convince those two little fuckers to disappear soon. Patch is attached. -- 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=36325
[Bug fortran/36325] specific or generic INTERFACE implies the EXTERNAL attribute
--- Comment #7 from burnus at gcc dot gnu dot org 2008-05-25 19:58 --- Patch is attached. You need also to reject the following, which violates R504. interface real function bar() end function bar end interface dimension :: bar(4) end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36325
[Bug fortran/36325] specific or generic INTERFACE implies the EXTERNAL attribute
--- Comment #8 from janus at gcc dot gnu dot org 2008-05-25 22:33 --- The failure of proc_decl_9.f90 was actually due to a bug that slipped in with my procedure declaration update patch from May 1st, which I have fixed now. So we're left with gomp/reduction3.f90, which contains this piece of code: interface function ior (a, b) integer :: ior, a, b end function end interface intrinsic ior This produces: intrinsic ior 1 Error: EXTERNAL attribute conflicts with INTRINSIC attribute at (1) I haven't checked the standard on this, but I bet the code is illegal. And after all: Why should one declare an explicit interface for an intrinsic (whose interface is known anyway) ...? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36325
