Compiler baselines

[Stephan Bergmann]

update:

* Building on CentOS 6 with DeveloperToolset (DTS) 7 (GCC 7.3.1) runs 
into a linker issue with an unresolved 
_ZN9__gnu_cxx32__throw_concurrence_unlock_errorEv when linking 
Library_unoexceptionprotector in an --enable-dbgutil (i.e., 
-D_GLIBCXX_DEBUG libstdc++ debug mode) build (see 
<https://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER&brief-log=1536396604.27182>). 
  Smells like a bug in DTS's libstdc++_nonshared.a, but I learned 
off-list that there is little hope that that would get fixed for DTS 7. 
A hack-around I found to get at least Library_unoexceptionprotector 
linked is to modify devtoolset-7-gcc-c++-7.3.1-5.10.el6.x86_64's 
/opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/libstdc++.so 
linker script, doubling the -lstdc++_nonshared entry on the INPUT line.

* Also saw that on CentOS 6 gperf-3.0.3-9.1.el6.x86_64 is too old, still 
emitting register keywords in C++ mode, so that our configure.ac falls 
back to using -std=gnu++14 instead of -std=gnu++17.  So the relevant 
machines would also need a newer gperf (e.g., built from 
gperf-3.1.tar.gz sources and passed into the LO build via a GPERF=... 
line in autogen.input).

* On Windows, found out that guaranteed copy elision support isn't good 
enough for our needs (see 
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=62bfe29f9045127d479c42376f599ddfb0fbb2ca> 
"Already set MSVC's -std:c++17 during the configure.ac feature checks") 
even in latest MSVC 2017 15.8, even though 
<https://en.cppreference.com/w/cpp/compiler_support#C.2B.2B17_features> 
advertises it as supported since MSVC 2017 15.6.  Apparently a reminder 
to treat the feature matrix at 
<https://en.cppreference.com/w/cpp/compiler_support> with a grain of salt...

* On macOS, our baseline is Xcode 8 according to 
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=1079893be5593268eff0867be87b0291546d88c7> 
"Document baselines".  According to 
<https://en.wikipedia.org/wiki/Xcode#Latest_versions> that means the 
oldest Apple Clang we need to support corresponds roughly to Clang 3.9. 
(Unfortunately, the information about what plain Clang the Apple Clang 
shipped with Xcode corresponds to ends with Xcode 8.2.1 at 
<https://en.wikipedia.org/wiki/Xcode#Latest_versions>, so it is not 
immediately clear what benefit any update of our Xcode baseline would 
bring us Clang-version wise.)

* Regarding Clang on Linux, I saw the other day that e.g. Jenkins tb75 
is still using Clang 3.8.  With macOS limiting us to 3.9, it would be 
great if Linux would not limit us even more severely.  Does anybody have 
a problem with upgrading the Clang-on-Linux baseline to at least 3.9 for 
LO master in the near future?

* A real-life example I came across today at 
<https://gerrit.libreoffice.org/#/c/60394/3..4/xmloff/source/draw/animexp.cxx> 
of a benefit we would get from a baseline bump is the current lack of 
support for inline variables with some compilers (necessitating those 
!HAVE_CPP_INLINE_VARIABLES extra variable definitions to be sprinkled 
throughout the code).  Per 
<https://en.cppreference.com/w/cpp/compiler_support#C.2B.2B17_features>, 
inline variables are supported by GCC 7, Clang 3.9, and MSVC 2017 15.5 
(and, I can confirm, are indeed supported fine for our needs with at 
least MSVC 2017 15.8).