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