Bug 47978 - [OOP] Invalid INTENT in overriding TBP not detected
[OOP] Invalid INTENT in overriding TBP not detected
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: fortran
4.6.0
: P3 normal
: ---
Assigned To: janus
: accepts-invalid
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-03 16:44 UTC by Salvatore Filippone
Modified: 2011-09-14 15:02 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2011-09-08 00:00:00


Attachments
test-case (716 bytes, text/plain)
2011-03-03 16:47 UTC, Salvatore Filippone
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Salvatore Filippone 2011-03-03 16:44:20 UTC
Hello,
The attached code looks invalid to me (and to the NAG and XLF compilers), but is accepted by gnu fortran. 

[sfilippo@localhost bug33]$ gfortran -v 
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GCC/BUILDS/gmp --with-mpfr=/home/travel/GCC/BUILDS/mpfr --with-mpc=/home/travel/GCC/BUILDS/mpc 
Thread model: posix
gcc version 4.6.0 20110225 (experimental) (GCC)

[sfilippo@localhost bug33]$ gfortran -c try_ext.f90 
[sfilippo@localhost bug33]$ 

----------------
[sfilippo@localhost bug33]$ nagfor -c try_ext.f90 -f2003
NAG Fortran Compiler Release 5.3(826),5.2(765)
Error: try_ext.f90, line 38: Argument J of overriding type-bound procedure BAR of type EXTFOO has a different INTENT
Errors in declarations, no further processing for EXTFOO_MOD
[NAG Fortran Compiler error termination, 1 error]

-------------------------------------------
bash-3.2$ xlf2003 -c try_ext.f90 
** foo_mod   === End of Compilation 1 ===
"try_ext.f90", line 25.27: 1514-593 (S) Dummy argument j of overridden binding bar was declared with the INTENT(IN) attribute.  The corresponding dummy argument of overriding binding bar must also be declared with the INTENT(IN) attribute.
** extfoo_mod   === End of Compilation 2 ===
1501-511  Compilation failed for file try_ext.f90.
Comment 1 Salvatore Filippone 2011-03-03 16:47:24 UTC
Created attachment 23534 [details]
test-case
Comment 3 janus 2011-09-08 14:47:09 UTC
Preliminary patch:

Index: gcc/fortran/interface.c
===================================================================
--- gcc/fortran/interface.c     (revision 178664)
+++ gcc/fortran/interface.c     (working copy)
@@ -3643,11 +3643,19 @@ gfc_check_typebound_override (gfc_symtree* proc, g
       if (proc_pass_arg != argpos && old_pass_arg != argpos
          && !gfc_compare_types (&proc_formal->sym->ts, &old_formal->sym->ts))
        {
-         gfc_error ("Types mismatch for dummy argument '%s' of '%s' %L "
-                    "in respect to the overridden procedure",
+         gfc_error ("Types mismatch for dummy argument '%s' of '%s' at %L "
+                    "with respect to the overridden procedure",
                     proc_formal->sym->name, proc->name, &where);
          return FAILURE;
        }
+      /* Check INTENT.  */
+      if (proc_formal->sym->attr.intent != old_formal->sym->attr.intent)
+       {
+         gfc_error ("INTENT mismatch in argument '%s' of '%s' at %L "
+                    "with respect to the overridden procedure",
+                    proc_formal->sym->name, proc->name, &where);
+         return FAILURE;
+       }
 
       ++argpos;
     }
Comment 4 janus 2011-09-10 11:30:21 UTC
Relevant F08 standard quote:

4.5.7.3 Type-bound procedure overriding

1 If a specific type-bound procedure specified in a type definition has the same binding name as a type-bound procedure from the parent type then the binding specified in the type definition overrides the one from the parent type.

2 The overriding and overridden type-bound procedures shall satisfy the following conditions.
 * Either both shall have a passed-object dummy argument or neither shall. If the overridden type-bound procedure is pure then the overriding one shall also be pure.
 * Either both shall be elemental or neither shall.
 * They shall have the same number of dummy arguments.
 * Passed-object dummy arguments, if any, shall correspond by name and position.
 * Dummy arguments that correspond by position shall have the same names and characteristics, except for the type of the passed-object dummy arguments.
 * Either both shall be subroutines or both shall be functions having the same result characteristics (12.3.3).
 * If the overridden type-bound procedure is PUBLIC then the overriding one shall not be PRIVATE.
Comment 5 janus 2011-09-11 20:12:31 UTC
Author: janus
Date: Sun Sep 11 20:12:24 2011
New Revision: 178767

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178767
Log:
2011-09-11  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/35831
	PR fortran/47978
	* interface.c (check_dummy_characteristics): New function to check the
	characteristics of dummy arguments.
	(gfc_compare_interfaces,gfc_check_typebound_override): Call it here.


2011-09-11  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/35831
	PR fortran/47978
	* gfortran.dg/dynamic_dispatch_5.f03: Fix invalid test case.
	* gfortran.dg/proc_decl_26.f90: New.
	* gfortran.dg/typebound_override_2.f90: New.
	* gfortran.dg/typebound_proc_6.f03: Changed wording in error message.

Added:
    trunk/gcc/testsuite/gfortran.dg/proc_decl_26.f90
    trunk/gcc/testsuite/gfortran.dg/typebound_override_2.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/interface.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_5.f03
    trunk/gcc/testsuite/gfortran.dg/typebound_proc_6.f03
Comment 6 janus 2011-09-11 20:24:16 UTC
Fixed with r178767. In fact we even check some more stuff now in addition to INTENT.

Thanks for reporting, Salvatore (and sorry that it took so long to fix). Closing.
Comment 7 Dominique d'Humieres 2011-09-14 13:31:15 UTC
Janus,

I am worried about your fix as it seems to break at least the original tests of pr41656 and pr41685:

pr41656.f90:68.13:

    procedure, pass(a) :: s_scal => s_coo_scal
             1
Error: Argument mismatch for the overriding procedure 's_scal' at (1): INTENT mismatch in argument 'a'
pr41656.f90:67.13:

    procedure, pass(a) :: s_scals => s_coo_scals
             1
Error: Argument mismatch for the overriding procedure 's_scals' at (1): INTENT mismatch in argument 'a'
pr41656.f90:174.6:

  use s_base_mat_mod
      1
Fatal Error: Can't open module file 's_base_mat_mod.mod' for reading at (1): No such file or directory

Could you double check with Salvatore that it is the intended behavior?
Comment 8 Salvatore Filippone 2011-09-14 13:45:13 UTC
Duh! 
My bad: all versions of scal are supposed to update the A dummy argument, which should be INTENT(INOUT).
The test case in my original post is wrong in this respect 
:( 

Salvatore
Comment 9 Salvatore Filippone 2011-09-14 13:46:00 UTC
(In reply to comment #8)
>
> The test case in my original post is wrong in this respect 
>
I mean: in the original post for pr41656.
Comment 10 janus 2011-09-14 13:49:04 UTC
Hi Dominique,

> I am worried about your fix as it seems to break at least the original tests of
> pr41656 and pr41685:

thanks for noticing. But, from a quick glance, I would say that you don't need to worry:

When committing the INTENT check, I had to modify 'dynamic_dispatch_5' in the testsuite, which is just the test case for PR41656. I checked that it is indeed invalid.

However, I would be even more relieved if Salvatore could tell us that his latest code still compiles with gfortran ...

Cheers,
Janus
Comment 11 janus 2011-09-14 13:49:24 UTC
Hi Dominique,

> I am worried about your fix as it seems to break at least the original tests of
> pr41656 and pr41685:

thanks for noticing. But, from a quick glance, I would say that you don't need to worry:

When committing the INTENT check, I had to modify 'dynamic_dispatch_5' in the testsuite, which is just the test case for PR41656. I checked that it is indeed invalid.

However, I would be even more relieved if Salvatore could tell us that his latest code still compiles with gfortran ...

Cheers,
Janus
Comment 12 Salvatore Filippone 2011-09-14 15:02:46 UTC
(In reply to comment #11)
> relieved if Salvatore could tell us that his
> latest code still compiles with gfortran ...
> 
> Cheers,
> Janus

Yes it does. 
No (new) worries here
Salvatore