Hello Federico,
please see these tickets:
for -fcommon: https://bitbucket.org/einsteintoolkit/tickets/issues/2406/cactus-fails-to-li...
for fallow-argument-mismatch: https://bitbucket.org/einsteintoolkit/tickets/issues/2403/compile-failure-wi...
The issue requiring -fcommon should already be fixed in the "master" branch. Are you still experiencing issues requiring it in the actual Cactus code when using the master branch?
The issue requiring -fallow-argument-mismatch is still under investigation as no solution that works on all supported clusters has been found yet.
Unfortunately a solution that requires setting compiler parameters is not generically usable for Cactus itself since for example the "generic.cfg" files in simfactory (have to) already set F90FLAGS and CFLAGS to enable Fortran functionality required by the ET but not Cactus itself. Thus Cactus would have modify the user (simfactory) provided F90FLAGS which generally is not something advisable (since it is confusing to a user setting a variable to "A" but the compilers sees 'B"). It certainly serves as a workaround for individuals who want to use gcc10 so, for now would seem a sufficient workaround that can be documented.
Once a solution that works without relying on command line options has been found and tested on all supported machines it will be backported to the release branch (ET_2020_05).
Concerning your issue to compile on your laptop, and on danger of asking you things you already thought about: you are doing a full recompile from scratch? Ideally doing a rm -rf configs/sim before? You are adding "-fallow-argument-mismatch" to F90FLAGS in your optionlist?
Yours, Roland
Hi everyone,
I'd like to report another small issue related to GCC 10, which is only partially related to the FORTRAN type mismatch issue from before.
In the past few days I have managed to install GCC 10 on the Goethe cluster in Frankfurt, and I could build the ET using gfortran's "-fallow-argument-mismatch" and "-fallow-invalid-boz" flags (for good measure I also used -std=legacy, but that might not be necessary). As mentioned by Roland in a previous email, the thing builds but then fails to link. In my case (but I strongly suspect this is not just a coincidence, and applies in general), the failure manifested as a few "multiple definition" errors (in my case, multiple definitions of RESTRICTED_IOASCII_STRUCT), followed by a landslide of memory alignment warnings. The two appear unrelated, but after researching a bit, it turns out these errors are also related to new defaults in GCC 10.
From GCC 10 release notes (https://gcc.gnu.org/gcc-10/changes.html): "GCC now defaults to -fno-common. As a result, global variable accesses are more efficient on various targets. In C, global variables with multiple tentative definitions now result in linker errors. With -fcommon such definitions are silently merged during linking."
From GCC 10 man page: "-fcommon In C code, this option controls the placement of global variables defined without an initializer, known as tentative definitions in the C standard. Tentative definitions are distinct from declarations of a variable with the "extern" keyword, which do not allocate storage.
The default is -fno-common, which specifies that the compiler places uninitialized global variables in the BSS section of the object file. This inhibits the merging of tentative definitions by the linker so you get a multiple-definition error if the same variable is accidentally defined in more than one compilation unit.
The -fcommon places uninitialized global variables in a common block. This allows the linker to resolve all tentative definitions of the same variable in different compilation units to the same object, or to a non-tentative definition. This behavior is inconsistent with C++, and on many targets implies a speed and code size penalty on global variable references. It is mainly useful to enable legacy code to link without errors."
It appears that the ET is exactly the kind of code the GCC developers are thinking about in the previous sentence. In any case, setting the -fcommon option of the C compiler (plus the Fortran flags above) did the trick, and the ET builds with GCC 10.
It would be nice if somehow the Cactus flesh could be updated to work without requiring this C flag. In contrast to the Fortran issue, this appears to be a backward compatible change (just some forgotten "extern" keywords??), although my knowledge of Cactus/ET internals is not extensive enough to make a definitive statement.
I have not created a ticket, as enabling the -fcommon flag suffices to get the desired outcome, but I'd be happy to if you deem it necessary.
Cheers,
Federico Guercilena
PS On my laptop, where I first encountered the issue, GCC 10 still stubbornly fails to compile LoopControl despite the -fallow-type-mismatch flag, but it is now clear that this is a quirk of my system, or maybe the Linux distribution I run, not a general issue.