Modify

Opened 6 years ago

Last modified 6 years ago

#974 new defect

Compilation problem in LoopControl with xlc compiler

Reported by: wolfgang.kastaun@… Owned by: Erik Schnetter
Priority: major Milestone:
Component: Carpet Version: development version
Keywords: Cc:

Description

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

Attachments (0)

Change History (6)

comment:1 Changed 6 years ago by Erik Schnetter

Yes, please.

comment:2 Changed 6 years ago by 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 ?

comment:3 Changed 6 years ago by 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}.

comment:4 Changed 6 years ago by 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.

comment:5 Changed 6 years ago by 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.

comment:6 Changed 6 years ago by 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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain Erik Schnetter.
Next status will be 'review'.
as The resolution will be set.
to The owner will be changed from Erik Schnetter to the specified user.
Next status will be 'confirmed'.
The owner will be changed from Erik Schnetter to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.