1. Einstein Toolkit Avatar Einstein Toolkit
  2. Einstein Toolkit
  3. tickets
  4. Issues

Compilation problem in LoopControl with xlc compiler

Issue #974 resolved
Wolfgang Kastaun created an issue

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:

Comments (15)

  2. Wolfgang Kastaun reporter
    • removed comment

    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 ?

  3. Erik Schnetter
    • removed comment

    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}.

  4. Wolfgang Kastaun reporter
    • removed comment

    -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.

  5. Erik Schnetter
    • removed comment

    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.

  6. Roland Haas
    • removed comment

    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.

  7. 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).

  9. Wolfgang Kastaun reporter

    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.

  10. 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).

  16. Log in to comment
Assignee
Type
bug
Priority
minor
Status
resolved
Component
Carpet
Milestone
–
Version
development version
Votes
0
Watchers
0
Jira Software: the preferred issue tracker for Bitbucket. Join the team!