GCC 6

Some notes on building LibreOffice master (towards LO 5.2) with recent GCC trunk (towards GCC 6.0):

• I ran into two open bugs with GCC that for now need workaround patches to be applied to LO:
  • PR69273 “internal compiler error: in assign_temp, at function.c:961” (a duplicate of PR69241 “[6 Regression] ICE: in assign_temp, at function.c:961”). Patch at “GCC 6 PR69273 workaround.”
  • PR69327 “constexpr leaves reference member var uninitialized”—that one took a long time to track down and reduce, because it hid in boost::fusion code called from boost::spirit code called from external libetonyek code. Patch at “GCC 6 PR69327 workaround.”
• (There was also another test breaker that took a while to track down as “Make sure desktop under LOK does not see osl_setCommandArgs CommandLineArgs.” But that one was not caused by any sort of mis-compilation, but rather by the fact that LO, when mistakenly asked to open a dynamic library as a document, happens to auto-detect an ELF library built by GCC 6 as a MacPaint document, while it auto-detected such libraries built with older GCC versions as plain text Writer documents.)
• All the other (minor) fixes and tweaks have gone into the LO code base by now, and make check succeeded for me for both an (implicitly) --disable-debug as well as an --enable-dbgutil build (on some random Fedora 22 Linux box).
• (With the caveat of having to --disable-firebird-sdbc in the --disable-debug case due to some error during building of that notorious external module,

  make -f ../gen/Makefile.refDatabases empty_db
  make[4]: Entering directory 'lo/core/workdir/UnpackedTarball/firebird/gen'
  make -f ../gen/Makefile.static.createdb
  make[5]: Entering directory 'lo/core/workdir/UnpackedTarball/firebird/gen'
  make[5]: Nothing to be done for 'all'.
  make[5]: Leaving directory 'lo/core/workdir/UnpackedTarball/firebird/gen'
  rm -f empty.fdb
  ../gen/firebird/bin/create_db empty.fdb
  invalid request BLR at offset 24
  -Too many Contexts of Relation/Procedure/Views. Maximum allowed is 255
  ../gen/Makefile.refDatabases:66: recipe for target 'empty.fdb' failed
  make[4]: *** [empty.fdb] Error 254
  make[4]: Leaving directory 'lo/core/workdir/UnpackedTarball/firebird/gen'
  Makefile:275: recipe for target 'empty_db' failed
  make[3]: *** [empty_db] Error 2
  make[3]: Leaving directory 'lo/core/workdir/UnpackedTarball/firebird/gen'
  Makefile:6: recipe for target 'firebird_embedded' failed
  make[2]: *** [firebird_embedded] Error 2
  make[2]: Leaving directory 'lo/core/workdir/UnpackedTarball/firebird'
  lo/core/external/firebird/ExternalProject_firebird.mk:29: recipe for target 'lo/core/workdir/ExternalProject/firebird/build' failed
  make[1]: *** [lo/core/workdir/ExternalProject/firebird/build] Error 1
  

  which I have not been able to track down yet.)

• The most common new warning encountered was -Werror=misleading-indentation. We already have a Clang loplugin:bodynotinblock (“compiler plugin check for if/while/true bodies with possibly {} missing”), so this new GCC warning did not find any more errors, but it does warn about cases where an additional statement follows a complete if statement on the same line, like in “-Werror=misleading-indentation (GCC 6).”
• The diagnostic information presented by the compiler when it finds an error in the code has improved still with GCC 6, but unfortunately the most dreaded

  lo/core/sw/source/core/text/txtfrm.cxx: In member function ‘virtual bool SwTextFrame::Prepare(PrepareHint, const void*, bool)’:
  lo/core/sw/source/core/text/txtfrm.cxx:689:0: error: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Werror=strict-overflow]
        if( nLen != COMPLETE_STRING && GetOfst() > nPos + nLen ) // the range preceded us
  

  emitted when building with optimizations enabled still leaves you completely clueless about what is going on, like in “Silence some odd -Werror=strict-overflow (GCC 6).”

• (And PR66460 “ICE using __func__ in constexpr function” is still open, so we still have the somewhat unfortunate situation that we detect HAVE_CXX14_CONSTEXPR=1 in the --disable-debug case, but HAVE_CXX14_CONSTEXPR=0 in the --enable-debug case—or its --enable-dbgutil superset, or its --enable-assert-always-abort subset.)