[Users] Another needed flag for GCC 10

[Roland Haas]

Hello Federico,

please see these tickets:

for -fcommon:
https://bitbucket.org/einsteintoolkit/tickets/issues/2406/cactus-fails-to-link-with-gcc-10-due-to

for fallow-argument-mismatch:
https://bitbucket.org/einsteintoolkit/tickets/issues/2403/compile-failure-with-gfortran-10-when

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


-- 
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://pgp.mit.edu .
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20200609/cb82bd78/attachment.bin