breakage with GCC 10

[loveshack]

The build breaks with the defaults GCC 10 uses. (It's not released, but will be in Fedora 32, and has broken a load of builds, not just due to this issue...) It defaults to -fno-common (https://gcc.gnu.org/gcc-10/porting_to.html) which produces a bunch of link errors with libxsmm. They should be reproducible using -fno-common with earlier GCC, but I haven't tried that, and I couldn't immediately see how to fix them. The workaround is just to use -fcommon, of course, so it's not a big deal. The targets for which -fno-common produces better code don't seem to be documented, and I don't know if it's actually a win on x86_64.

[loveshack]

I should have thought to ask initially about the relevant targets, but there's info under https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/QCZ2NWKKNHEPUUIB7V3LM4AAX7YGJASC/ in case you don't already know and it's useful.

[hfp]

Thank you for the report and heads-up! I will try to fix this as quickly as possible plus planning for a release that puts it out.

I actually tried GCC 10 some time ago (curiosity about C2x), and found that C2x may break things quite a bit. I am confident about GCC 10, but not so much about supporting C2x.

[hfp]

The current master just needs to be released (v1.15) to get LIBXSMM going with GCC 10!
This issue is fully resolved.

Regarding GCC-10, I may double-check with another build as we get closer to the release of GCC-10 but at the moment I can get GCC/master ICEing in the following case:

make
cd tests
make MIX=1

( The default for GCC-10 is MIX=0 just to avoid the ICE )

The output looks like:

./headeronly_aux.cpp:36:1: error: Two symbols with same comdat_group are not linked by the same_comdat_group list.
   36 | }
      | ^
error_once/6852 (int error_once) @0x2b7e995c8400
  Type: variable definition analyzed
  Visibility: public weak comdat comdat_group:error_once one_only visibility:hidden
  previous sharing asm name: 6708
  References:
  Referring: libxsmm_get_tid/6853 (addr)
  Availability: not-ready
  Varpool flags: initialized
error_once/6708 (int error_once) @0x2b7e9ddeb000
  Type: variable definition analyzed
  Visibility: public weak comdat comdat_group:error_once one_only visibility:hidden
  next sharing asm name: 6852
  previous sharing asm name: 6706
  References:
  Referring: libxsmm_malloc_attrib/6709 (addr)libxsmm_malloc_attrib/6709 (addr)libxsmm_malloc_attrib/6709 (addr)libxsmm_malloc_attrib/6709 (addr)libxsmm_malloc_attrib/6709 (addr)
  Availability: not-ready
  Varpool flags: initialized
./headeronly_aux.cpp:36:1: internal compiler error: symtab_node::verify failed
0xbe3d2e symtab_node::verify_symtab_nodes()
        /nfs/home2/hpabst/home/gcc/gcc/symtab.c:1342
0xbfa41a symtab_node::checking_verify_symtab_nodes()
        /nfs/home2/hpabst/home/gcc/gcc/cgraph.h:667
0xbfa41a symbol_table::compile()
        /nfs/home2/hpabst/home/gcc/gcc/cgraphunit.c:2720
0xbfd274 symbol_table::finalize_compilation_unit()
        /nfs/home2/hpabst/home/gcc/gcc/cgraphunit.c:2984
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[loveshack]

You wrote:

The current master just needs to be released (v1.15) to get LIBXSMM going with GCC 10! This issue is fully resolved.

Good, but I'm sure there's no rush!

Regarding GCC-10, I may double-check with another build as we get closer to the release of GCC-10 but at the moment I can get GCC/master ICEing in the following case:

Did you report it to the GCC tracker? If not, what date is the gcc from, and is it with recent libxsmm head, so I can try to reproduce and report it?

[hfp]

Let me share the exact SHA for LIBXSMM (beside of saying "master"). Before sharing, I will rebuild GCC and note down the SHA as well. For the time being, it's present with LIBXSMM/master and GCC from February 7th. So it is very likely present with GCC/master. The steps about how to reproduce are shown above.

[hfp]

We are lucky, the problem (ICE) is gone between Feb. 7th and 16th!

I checked with LIBXSMM 81bb743, and prepended GNU Binutils 2.34 to PATH (outdated on my machine). The GNU Compiler from Feb. 7th fails with an ICE as shown above. In contrast, GCC from Feb. 16th works (SHA=9a3d019a74d8d49fb6e6d75a00bd79fdb936a2e1). There are quite some changes to GCC's source between 7th and 16th, and I saved myself bisecting the commits wrt the ICE.

Regarding your original report about LIBXSMM w/ GCC-10, the main breaking change in GCC-10 is a change in default compiler flags: GCC prior to 10 uses -fcommon and GCC-10 introduced -fno-common by default. Proper steps have been taken in LIBXSMM's source code (to be released in v1.15). Earlier versions of LIBXSMM incl. v1.14 can be likely fixed by adding ECFLAGS=-fcommon to the make-line, e.g., make ECFLAGS=-fcommon when using GCC-10.