- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The following results in the compilation error:
error #6483: IMPORT-name must be the name of an entity in the host scoping unit. [SUBB]
program Main
contains
subroutine SubA
import, only: SubB
end subroutine SubA
subroutine SubB
end subroutine SubB
end program
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well, IMPORT is used to import types and kinds and such in an interface definition. The error message is a trifle misleading perhaps, but on the other hand, the definition of SUBB comes after SUBA. And I do not quite understand what the code should achieve, as the routines SUBA and SUBB are in the same scope and thus "see" each other already.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This was just a minimum reproducer to indicate the bug. The use of IMPORT in an internal procedure is a useful means of prescribing/indicating precisely which host associated objects are used. This bug prevents this use if one of the host associated objects is another internal procedure.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Gfortran does not allow this either. I do not think this is a valid use of import. The sibling subroutines in the contains can all see each other the import with the "only" would imply any other routines were excluded which I do not think is possible. The use without the only attribute would be pointless. The case where variables declared in the main program are excluded by and "import, only" is valid but only of use if the sub but that has wider use than your stared aim.
Having subB in a separate module and then the having a "USE ONLY" is a mores generally useful setup IMO.
The nitty gritty of what the standard might says on this I will leave to others that have more expertise, this one could be quite nuanced.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@mfinnis ,
For whatever it's worth, I think the Fortran standard permits the usage you have shown with IMPORT. The compiler is nonconforming in raising the error it does. If you have support subscription, please file a request at the Intel OSC. Otherwise you can expect an Intel team member to pick it up from here.
You can point to Intel the compiler appears to struggle with the so-called "forward reference" to 'SubB', a notion that is effectively absent in the Fortran standard at least in the context of internal and module procedures.
As a workaround - even if you think it to be silly - if you change the "order" of subprograms and place 'SubB' ahead of 'SubA' in the CONTAINS section, you will find the compiler processes it ok.
With respect to the other replies on this thread, note this is a Fortran 2018 standard extension with IMPORT that other compilers such as gfortran are yet to implement and thus other such compiler behavior are not informative relative to the semantics introduced starting Fortran 2018.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the clarification FF. Yes Gfortran gives the error that import can only be in an interface which is pre 2018 behaviour.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I agree that this is valid F2018 (but not F2008), and since ifort claims to support all of F2018, that's a bug. gfortran doesn't make that claim.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Since you all seem to concur that this reproducer is valid F2018 code, I filed a bug, CMPLRIL0-34753. I'll let you know when it's fixed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This erroneous error message is no more. The error message is not printed for either ifx or ifort with the compiler available in oneAPI HPC Toolkit 2023.0. It was released in December 2022.
Check it out!
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page