Compilation problem in LoopControl with xlc compiler

[Wolfgang Kastaun]

I was trying to compile ET on MareNostrum (BSC) using the xlc/xlC/xlf compiler suite version 10.01 and failed. The first relevant error reads:

"/gpfs/home/uv08/uv08986/source/Cactus/configs/z4pisky_std/build/LoopControl/loopcontrol.c", line 1371.1: 1506-343 (S) Redeclaration of lc_statmap_init differs from previous declaration on line 631 of "/gpfs/home/uv08/uv08986/source/Cactus/configs/z4pisky_std/build/LoopControl/loopcontrol.c". "/gpfs/home/uv08/uv08986/source/Cactus/configs/z4pisky_std/build/LoopControl/loopcontrol.c", line 1371.1: 1506-376 (I) Redeclaration of lc_statmap_init has a different number of fixed parameters than the previous declaration. "/gpfs/home/uv08/uv08986/source/Cactus/configs/z4pisky_std/build/LoopControl/loopcontrol.c", line 1371.1: 1506-377 (I) The type "char" of parameter 3 differs from the previous type "const char restrict const".

The fist declaration reads:

630 void
631 lc_statmap_init (int * restrict const initialised,
632                  lc_statmap_t * restrict const lm,
633                  char const * restrict const name)
634 {

while the second is

1374 CCTK_FCALL 1375 void 1376 lc_statmap_init (int * restrict const initialised, 1377 lc_statmap_t * restrict const lm, 1378 ONE_FORTSTRING_ARG) 1379 {

From the compiler message, I guess ONE_FORTSTRING_ARG expanded to something of type char*

It seems the idea here is to provide a version of a C function callable from Fortran. However, it ends up having the same name and argument types (apart from const-ness), which is forbidden. From the Cactus manual I would guess one needs to wrap the second declaration inside a CCTK_FNAME macro, like

void CCTK_FCALL CCTK_FNAME(lc_statmap_init)(int * restrict const initialised, lc_statmap_t * restrict const lm, ONE_FORTSTRING_ARG) {

Keyword:

[Erik Schnetter]

Yes, please.

[Wolfgang Kastaun]

Oops, I just noticed I was accidently looking at the file in the build directory, not the source. In the actual loopcontrol.c the CCTK_FNAME is already there, it just expands to identity. However, that doesn't solve my problem. Has anyone successfully compiled ET with xlc compiler recently ? For example, by adding options to make it use underscores so CCTK_FNAME macro is not identity ?

[Erik Schnetter]

You need to use the respective xlf option (-qextname) to ensure that it appends an underscore when compiling Fortran code. This will (obviously) require a complete rebuild. See lib/make/known-architectures/{aix,linux}.

[Wolfgang Kastaun]

-qextname solved this problem, but introduced another one: xlc is then also adding underscores to Fortran functions using the BIND(C) mechanism to be interfaced from C. Therefore, I had to use the -qnobindcextname option as well, which only exists for versions > 12.

My problem is thus solved for the time being. It would however be nice if Cactus/Carpet would not depend on certain compiler behaviour regarding the name mangling. I remember now that I posted the very same issue a year ago and then completely forgot, and I bet I'm not the last one stumbling over that.

[Erik Schnetter]

Without this option, xlc uses the same name space for C and Fortran, requiring people to choose different names for C and Fortran routines. Most people won't expect this. C/Fortran interoperability is only a vaguely defined topic, and having to use a particular compiler option should not be much of an issue.

In particular, since C/Fortran interoperability is rather new, Cactus defined its own mechanism for this.

[Roland Haas]

There is one more way around this, by using routine names that are mixed case. The Cactus build in functions use this convention (if only because they are usually called CCTK_SomethingOrTheOther). Since C cares about capitalization but Fortran does not this tends to give differing capitalization for the two flavors of the routine. Eg. CCTK_FNAME(LC_do_init) is likely lc_do_init or LC_DO_INIT while the C version has to be LC_do_init (or lc_DO_INIT is also allowed but that would be really odd). The problem with introducing this into LoopControl right now would that it changes the C visible routine names as well.

[Roland Haas]

Pull request https://bitbucket.org/eschnett/carpet/pull-requests/44/loopcontrol-use-mixed-case-in-fortran proposes a solution by changing the linker names of the C function to LC_xxx as is the required to work with Fortran (and documented to be required for this reason in https://einsteintoolkit.org/usersguide/UsersGuide.html#x1-131000C1.9.4). It uses preprocessor defines to to allow current code to continue using the old lc_ names. Currently I use the (internal) THORN_IS_LoopControl macro as part of this, but this could easily be avoided by having loopcontrol.cc define its own macro indicating that loopcontrol.h is included from loopcontrol.cc (in which case the compatibility defines must not be done).

[Roland Haas]

@Wolfgang Kastaun . Please review.

[Wolfgang Kastaun]

Wow, this is ancient, I barely remember this ticket. Sorry but I wont review this because I have no XLC compiler, decided long ago that any cluster that requires to use xlc compilers is probably broken beyond repair, did not save the configuration this ticket refers to, and don’t have the time.

I note however that I did not run into this linking problem in ages, using intel, gcc, and clang compilers. Up to 2 around years ago one of my thorns was also using the BIND(C) mechanism to directly interface between C and Fortran, and I don’t remember having to do anything special with non-xlc compilers.

[Roland Haas]

well yes, tickets don’t age out of existence Turns out that the proposed fix could have been applied 8 years ago. The IBM compiler still behaves the same way. The most likely system to encounter it today would be Summit though we use gcc to compile there right now (xl is Oak Ridge’s default though).

[Roland Haas]

Unless objected I will apply this after 2021-08-24

[Roland Haas]

Applied as git hash 977eda4d "LoopControl: use mixed case in Fortran routines" of carpet