Submit a patch seems like the best way forward on the short term.
Ok, the authors of the targetted code need to proceed to a re-design of their
code regarding the use of c++ features.
The git log tells me:
- Peter Collingbourne <pcc@google.com>
- Teresa Johnson <tejohnson@google.com>
On the medium term, we should have a discussion in the community about adding
bots for our minimum version.
Those bots should have been the first to be set up. Hope you can fix this soon.
We had 4.7 bots for a long time, but migrations happen, and we
probably (separately) didn't expect to be the last 4.7 ones. This was
a coordination problem.
Now, there are talks to upgrade the GCC version from 4.7, but we can't
do 4.9 because many stable distributions still 4.8, but we can do 4.8,
which has enough buildbots (and will for the long term).
I'm not saying this is a "fix" for your problem, but your problem
would happen any time soon when we move the GCC version up anyway.
Why is it more important to be backward compatible with ancient versions of GCC than relatively more recent versions of Visual Studio? We are removing support for VS2013 because of defects in that product, yet GCC v4.7.x is more ancient than VS2013, so why should the answer be any different?
To the best of my understanding - because we want to be able to bootstrap clang with the system compiler that ships with various linux and BSD distributions.
Windows has no equivalent concept.
(This is probably not a good enough reason to keep GCC 4.7 support, but it apparently is for GCC 4.8).
+1 for calling 4.8 the minimum version. It appears that the last time 4.7 (at least, the one in ubuntu, “gcc-4.7 (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3”) could actually compile clang was July 8th – about 3 months ago.
Besides this reported error, it also doesn’t like “<::”, which have been introduced in various places, it has some issue with the lambda in clang/lib/StaticAnalyzer/Checkers/MallocOverflowSecurityChecker.cpp (even after the commit which says it fixes it), and possibly more issues besides (I didn’t attempt to comprehensively catalog the errors).
4.8 is the oldest shipped version on many stable LTS Linux and BSD
releases. Simple as that.
Upgrading to 4.9 or later will not be possible any time soon, due to
multiple bugs we're finding and fixing on newer versions of libstdc++,
glibc, binutils that is bundled with them.
So I am, and will be relying on 4.8 for the next year or so, and so
will many other people in the community (some more than a year).
Also, as of January 1 2017 FreeBSD will have Clang 3.4.1 or newer as
the system compiler on all supported tier-1 architectures. I'm not
sure what other open source operating systems or distributions are
using Clang as their system compiler, but I suspect the same argument
for GCC 4.8 can be made for Clang 3.4 as a minimum.
To elaborate on this: if you want to produce binaries compatible with
old Linux systems, it is pretty much necessary to build on such an old
Linux system, because otherwise you'll get bitten by glibc ABI issues
(not to mention libstdc++, but at least you can link libstdc++
statically).
Windows has no such problem: you can redistribute a recent MSVCRT DLL
on an old Windows system.
Then, on the medium term it would be to see if gcc 4.7.4 (the last C
bootstrap-able c++-ish compiler in one step) is phased out from llvm support in
favor of gcc 4.8.
But the short term solution would be to fix current llvm against gcc 4.7.4.
As I said earlier, with the options detailed earlier in this thread, the LTO
cache and some tools have some troubles with gcc 4.7.4.
> > To the best of my understanding - because we want to be able to
bootstrap
> > clang with the system compiler that ships with various linux and BSD
> > distributions.
> > Windows has no equivalent concept.
>
> To elaborate on this: if you want to produce binaries compatible with
> old Linux systems, it is pretty much necessary to build on such an old
> Linux system, because otherwise you'll get bitten by glibc ABI issues
> (not to mention libstdc++, but at least you can link libstdc++
> statically).
Then, on the medium term it would be to see if gcc 4.7.4 (the last C
bootstrap-able c++-ish compiler in one step) is phased out from llvm
support in
favor of gcc 4.8.
But the short term solution would be to fix current llvm against gcc 4.7.4.
As I said earlier, with the options detailed earlier in this thread, the
LTO
cache and some tools have some troubles with gcc 4.7.4.
I can send a patch to workaround the gcc 4.7.4 bug hitting the LTO compile.
But according to James in an earlier response, there are other places where
gcc 4.7 doesn't compile the current clang toolchain.
So I'd first like to understand whether we still want to keep gcc 4.7 as a
supported version, or move to 4.8 as was suggested. What is the process for
making that change? If we stick with 4.7 we should have a bot otherwise it
will likely stop working again pretty quickly.
So I'd first like to understand whether we still want to keep gcc 4.7 as a
supported version, or move to 4.8 as was suggested. What is the process for
making that change?
Same as usual: propose on the list, and hope that no one has any blocking
issues. Going to 4.9 failed because many people had reservations, but IIRC,
none of those people had reservations against 4.8.
If we stick with 4.7 we should have a bot otherwise it will likely stop
working again pretty quickly.
Yes, same for Clang. I suggest we also move to Clang 3.4 as the minimum and
install a quick bot with that.
