[Users] Another needed flag for GCC 10

[Federico Maria Guercilena]

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.



-- 
Dr. Federico Maria Guercilena

Technische Universität Darmstadt

Institut für Kernphysik
Theoriezentrum
S2|11
Schlossgartenstraße 12
64289 Darmstadt
Room 302

+49 6151 16 21562

fguercilena at theorie.ikp.physik.tu-darmstadt.de