Deferred TBPs: invalid code accepted

[jahern]

Hello,

I have found that ifort accepts the definition of non-abstract types that do not override deferred bindings contained in an abstract parent type. Here is an example that is accepted by the compiler:

[plain]PROGRAM test
   IMPLICIT NONE
   TYPE, ABSTRACT :: parent
   CONTAINS
      PROCEDURE(foo), DEFERRED :: bar
   END TYPE parent
   ABSTRACT INTERFACE
      INTEGER FUNCTION foo(a)
         IMPORT parent
         CLASS(parent), INTENT(IN) :: a
      END FUNCTION foo
   END INTERFACE
   TYPE, EXTENDS(parent) :: child
      INTEGER :: i
   END TYPE child
END PROGRAM test[/plain]

I believe that there must be a an actual "bar" TBP specified for "child" with interface "foo", see:

http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/dad1c8b49c0cc57e/eb5aa4f1b34d22af

This was on Fedora 11 (x86_64) with ifort11.1 20090511, froml_cprof_p_11.1.038. I did not happen to see an existing report of this, but I may well have missed it.

Regards,

Jared

[Steven_L_Intel1]

Thanks, we'll see if we can diagnose this. As indicated in the newsgroup, the compiler isn't required to give an error message in this case, but it would be nice if it did.

[jahern]

Quoting - Steve Lionel (Intel)

Thanks, we'll see if we can diagnose this. As indicated in the newsgroup, the compiler isn't required to give an error message in this case, but it would be nice if it did.

So I was informed. I was surprised that it was not required to be diagnosed (or that this situation with the standard could even occur), but so be it. It's always useful to get more warnings & error messages out of the compiler.

[Steven_L_Intel1]

There are many rules in the standard that are imposed on the programmer but not on the compiler. If it isn't a numberd syntax rule or a constraint, the compiler doesn't have to report violations. In some cases, it's very difficult for a compiler to detect the violation of a non-constraint rule, especially when it's that something is missing.