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.