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.