Adding flang-specific header files to clang

C and C++ code can call Fortran. When flang builds it creates several header files in the install directory:

  • ISO_Fortran_binding.h
  • Runtime/api-attrs.h
  • Runtime/derived-api.h
  • Runtime/io-api.h

Presumably, when we build clang and flang together, we want these (and perhaps other) header files produced by flang to be put into clang’s install area where they’ll be found by default when clang is invoked.

Where should they be put?

Presumably, we can just add a define to the cmake invocation to trigger this action. Is there a better way?

1 Like

Should this be posted/cross-posted in the Clang project’s discourse?

Thanks, Kiran. I added the “Building Clang” topic. Let me know if this doesn’t do the trick.

The runtime API headers are of interest only to lowering, not to applications, and I am surprised to read that they are installed anywhere. Only ISO_Fortran_binding.h should be exposed to C/C++ users. That header is static text, not a dynamically generated file.

(EDIT: The runtime API headers are probably exposed for use in runtime unit tests, come to think of it. There’s probably other ways to package them for that purpose that don’t lead to their exposure to the world.)

Thanks, Peter.

ISO_Fortran_binding.h includes Runtime/api-attrs.h, which is why I listed it. I (incorrectly, apparently) assumed that the other api files in the Runtime directory should be included, too.

It would be best if the ISO_Fortran_binding.h file that we expose to C/C++ compilation be self-contained. Maybe the dependence on api-attrs.h can be made conditional and off by default. Or the inclusion of api-attrs.h moved to a wrapper header that appears only in the library, with the exposed ISO_Fortran_binding.h file containing only some empty #defines for the API macros that get activated when the wrapper hasn’t defined them. Please check with Slava, he made this change.

Thanks, Peter.

@szakharin, do you have any input here?

Hi @psteinfeld, let me rework it via the wrapper, the way Peter described.

Regarding the installation location of ISO_Fortran_binding.h, lib/clang/<VERSION>/include/fortran/ looks reasonable to me.

Will C programer need to include
if the header is located in

Is that expected and the common usage?

GCC puts the file in the same directory as intrinsics (mmintrin.h) and other compiler dependent header files, like varargs and omp.h.


A good place is:

> clang --print-runtime-dir

a hand over ownership to Clang. This is the lib directory. The include is a few steps up.

Take care to ensure that the C programmer has a reliable means to override the include directory for ISO_Fortran_binding.h, and that the header is available even where clang is not installed. Each Fortran compiler has this include file, and we need to ensure both that clang can be easily used to build C/C++ code meant to be interoperable with other Fortran compilers, and that other C/C++ compilers can be easily used to interoperate with f18.

There is now:

Could you add a test that Flang and Clang are interoperable?

<fortran/ISO_Fortran_binding.h> is going to be required, unless fortran subdirectory is added into include paths by clang driver automatically. I suggested using fortran subdirectory to “bundle” all Fortran files in one place and do not mix them with other headers. Maybe it does not make much sense if ISO_Fortran_binding.h is going to be the only file, especially, since the file name has Fortran part already.

Will existing C source code using the ISO_Fortran_binding.h headers of other Fortran compilers need to be modified to use #include <fortran/ISO_Fortran_binding.h> to work with f18? Will such modified source code still work when interoperating with other Fortran compilers?

The existing C source code using ISO_Fortran_binding.h does not need to be modified to work with clang compiler, if clang driver has default include path pointing to wherever ISO_Fortran_binding.h is located in the clang installation. It may be the current clang’s default include location or a new one with fortran subdirectory.

You can probably put the header file here:

CMakeLists.txt updates.

I’m trying to ensure that existing C code that uses #include <ISO_Fortran_binding.h> won’t have to be modified if it works today with some C+Fortran compiler combination in order to be used with clang+(any Fortran) or (any C)+flang interoperable combination. If #include <fortran/ISO_Fortran_binding.h> is required in C source for some combination of interoperable compilers, it would be bad. If all existing code that is using #include <ISO_Fortran_binding.h> will port without change to clang &/or flang, then we’re good.

1 Like

ISO_Fortran_binding.h is being developed (and used in the Fortran compiler/runtime) as part of flang sub-project, so I think it should stay under the source control of flang directory. The installation of the file may follow the logic from clang/lib/Headers.

1 Like

It’s staying in flang/. This header defines one of the most important data structures in the project!

The ownership/development can stay in flang/, but if you keep a ~current copy in Clang. It will take care of distribution for you.