`!DEC$ attributes dllexport` is not standard Fortran

[zaikunzhang]

Hi @jschueller Julien and @amontoison Alexis,

!DEC$ attributes dllexport is not standard Fortran.

For example, with https://github.com/libprima/prima/commit/6e9b33401c6397be46c163fe3c4dca5371e664cb , running

cd fortran/examples/cobyla && make itest

we will get

../../common/debug.F90(38): warning #7025: This directive is not standard F2018.
!DEC$ attributes dllexport :: assert
------^
../../common/debug.F90(38): remark #7841: DLL IMPORT/EXPORT is not supported on this platform.   [DLLEXPORT]
!DEC$ attributes dllexport :: assert

How to fix this? Is there a standard-conforming way to do the same?

In general, PRIMA does not tolerate warnings --- each warning is considered a (future) bug. In addition, PRIMA uses only standard Fortran, conforming to F2008 as of September 2023.

Thanks.

Zaikun

[jschueller]

yes, fortran does not seem to have a standard way to export symbols for windows (which allows for shared libs) there is also .def files we could try

[vmagnin]

In gtk-fortran, we have similar directives for GFortran:

!GCC$ ATTRIBUTES DLLEXPORT :: destroy

I guess the standard says nothing about linking, which is a mechanism related to compilers and OS.

[zaikunzhang]

Thank you @vmagnin for your comments and for sharing your experiences.

@jschueller is proposing a fix with a .def file (thank you Julien). Your comments will be appreciated.

[arjenmarkus]

In the PLplot project on SourceForge (https://plplot.sourceforge.net/) we use .def files as well to control this. Compiler directives are by definition compiler-specific and the linking mechanism that is responsible is independent of what a language standard like Fortran's covers. Note that .def files themselves are also specific - for instance because they should contain the externally visible name of the routines, which includes the name of the module.

[zaikunzhang]

Thank you @arjenmarkus for your sharing! Welcome to give comments on the PR by Julien.

[vmagnin]

we use .def files as well to control this.

Thanks @arjenmarkus for pointing this functionality. I will read those docs: https://cmake.org/cmake/help/latest/prop_tgt/WINDOWS_EXPORT_ALL_SYMBOLS.html https://cmake.org/cmake/help/latest/variable/CMAKE_LINK_DEF_FILE_FLAG.html#variable:CMAKE_LINK_DEF_FILE_FLAG

[jschueller]

WINDOWS_EXPORT_ALL_SYMBOLS wont work def files can be passed directly to cmake sources

[FortranFan]

Hi @jschueller Julien and @amontoison Alexis,

!DEC$ attributes dllexport is not standard Fortran.

For example, with 6e9b334 , running

cd fortran/examples/cobyla && make itest

we will get

../../common/debug.F90(38): warning #7025: This directive is not standard F2018.
!DEC$ attributes dllexport :: assert
------^
../../common/debug.F90(38): remark #7841: DLL IMPORT/EXPORT is not supported on this platform.   [DLLEXPORT]
!DEC$ attributes dllexport :: assert

How to fix this? Is there a standard-conforming way to do the same?

In general, PRIMA does not tolerate warnings --- each warning is considered a (future) bug. In addition, PRIMA uses only standard Fortran, conforming to F2008 as of September 2023.

Thanks.

Zaikun

This team may want to follow up again with Intel Fortran support at their forum for their current thinking and feedback on this and decide on the best course of action.

My recommendation is to avoid cluttering Fortran code with preprocessor directives as much as possible. In the case of Windows OS and dynamic (shared) library exported symbols, I recommend the Microsoft module definition .DEF file solution as shown here.

Note the warning is issued by the Intel Fortran compiler when the compiler option -stand is in effect. Additionally, Intel provides an option to suppress this specific warning via the compiler option -Qdiag-disable:7025.

module m
contains
   subroutine sub()
   !dir$ attributes dllexport :: sub
   end subroutine 
end module 

• Note no warning when -stand is not applied:

  
  C:\temp>ifort /c /standard-semantics /free m.f
  Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.10.0 Build 20230609_000000
  Copyright (C) 1985-2023 Intel Corporation.  All rights reserved.

C:\temp>ifort /c /standard-semantics /free /stand m.f Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.10.0 Build 20230609_000000 Copyright (C) 1985-2023 Intel Corporation. All rights reserved.

m.f(4): warning #7025: This directive is not standard F2018. !dir$ attributes dllexport :: sub ---------^

C:\temp>

* And the warning can be suppressed using `-Qdiag-disable`

C:\temp>ifort /c /standard-semantics /free /stand /Qdiag-disable:7025 m.f Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.10.0 Build 20230609_000000 Copyright (C) 1985-2023 Intel Corporation. All rights reserved.

C:\temp>

[zaikunzhang]

This team may want to follow up again with Intel Fortran support at their forum for their current thinking and feedback on this and decide on the best course of action.

Hi @FortranFan , thank you for your comments and detailed instructions. According to Bogus standard conformance warning for compiler directives - Intel Community, where it reads that

We had an extensive discussion about this in the past, and decided that directives are “funny-looking statements” and not comments, and that the warnings were appropriate. [from Steven_L_Intel1, Employee]

the opinion of Intel seems quite clear to me. I am not sure re-posting the same question would change it a lot.

Thanks.

Zaikun

[FortranFan]

the opinion of Intel seems quite clear to me. I am not sure re-posting the same question would change it a lot.

No worries. In this context at least the PRIMA team has a couple of options for Windows OS so that's good.

The point with the Intel team is the opinion dates back more than a decade and perhaps the current team sees it differently now.

I always felt Intel's opinion and warning was rather lame in the context of standards checking, for the standard is clear the comment line has no interpretation from a standard point-of-view.