implicit none(type, external) discussion

[andrew_4619]

Prompted by another thread I installed XE2020 update 1 (from XE2019 U4). I seem very disappointed by the new attributes on IMPLICIT NONE.  I was expecting a compile error because of no explicit interface for subroutine fred but that is not the case, I only get the linker error at the end of the build. So I can't really see any real benefit for this feature other than if you declare a function but don't give it the EXTERNAL attribute which in itself isn't very useful. Am I missing something?

module fred
    implicit none
    contains
    subroutine blogs(istat)
        integer, intent(out) :: istat
        istat = 42
    end subroutine blogs
end module fred

program main
    !use fred, only: blogs
    implicit none(type, external)
    integer         :: istat
    call blogs( istat )
    print *, istat
end

[Steve_Lionel]

I don't think you're missing anything. It's a bug - please report it. At first I wondered if there was some symbol table side-effects of having BLOGS declared in the module, even though the USE was commented out. The compiler has had issues before with symbol table entries not being fully cleaned out. But some testing showed that was not the case here.

The issue seems to be if you use (EXTERNAL, TYPE) or (TYPE, EXTERNAL). When both keywords appear, EXTERNAL is ignored. If you just have (EXTERNAL), it works.

t.f90(14): error #8889: Explicit declaration of the EXTERNAL attribute is required.   [BLOGS]
    call blogs( istat )
---------^

[andrew_4619]

OK thanks that is useful then as the type attribute is default anyway. I will file a ticket.

[Steve_Lionel]

IMPLICIT NONE (TYPE) is not the default (unless you compile with /warn:declarations.) You can't repeat IMPLICIT NONE, either.

[andrew_4619]

By default I meant that IMPLICIT NONE (TYPE) statement is the same as an IMPLICIT NONE statement.

[andrew_4619]

FYI "Hello, An update was made to service request on July 17, 2020: I have reproduced this bug and escalated to be corrected (CMPLRIL0-33125). Thank you for reporting it."

[andrew_4619]

This is fixed in the "latest compiler" I am informed, not tested as yet.