Sigh Mine was in response to Mehdi, who says he mis-typed his post, and so my last is (by construction) completely irrelevant to the policy and the CMake implementation of the warning/error. Go for it.
Regarding bot protection from people being too ambitious with their feature set, there’s already a separate thread:
“Buildbot for minimum supported GCC version? (seeing local build failures)”
http://lists.llvm.org/pipermail/llvm-dev/2019-January/129381.html
Follow up there, please.
–paulr
Right, my bad for derailing this thread, sorry! 
I don't know how well requiring newer versions upon discovery of a problem is going to work in practice. Given the cost that upgrading a production compiler can have, this may be met with resistance (although would be the best option from our point of view).
My question remains:
What level of confidence do we have that the C++14 support in the proposed compilers is actually sufficient for clang/llvm? Do we have any anecdotal evidence that they have been used in actual projects with success?
-Krzysztof
I'd expect that either we'll either workaround the issues (e.g. not start using the broken feature), or else propose to require even newer versions. And as now, discuss the expected tradeoff between new features and requiring new compiler versions.
I don't know how well requiring newer versions upon discovery of a problem is going to work in practice. Given the cost that upgrading a production compiler can have, this may be met with resistance (although would be the best option from our point of view).
My question remains:
What level of confidence do we have that the C++14 support in the proposed compilers is actually sufficient for clang/llvm? Do we have any anecdotal evidence that they have been used in actual projects with success?
I have 100% confidence that whichever compiler version we choose will have codegen bugs which require workarounds. Not just for C++14, but for pretty much anything. You can find specific bugs on the WebKit / Firefox / Chromium discussions, but there’s a ton of them and it's pretty much impossible to decide which compiler bug is important to us and which isn’t.
I may have missed it, but I don’t see mentions of the minimum C++ library implementation levels (in case Clang is used with an older libstdc++).
– HT
I may have missed it, but I don’t see mentions of the minimum C++ library implementation levels (in case Clang is used with an older libstdc++).
libstdc++ is tied to a GCC version, so the documentation we have today is already sufficient.
The discussion seems to have died down and gotten good consensus. I’ve therefore create a patch which applies the proposed soft-errors:
We’ll only migrate to hard-error (and start using new features) when we get consensus to do so, at the earliest end of March 2019. The patch will allow us to start warning developers, especially those who only compile branches (in this case, LLVM 8).
+1, thanks again for driving this.
The patch is about ready to land, which means any older compiler will soft-error (which you can turn off with LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN). I think we should then cherry-pick the patch to the LLVM 8 branch.
The last remaining issue are the buildbots. I audited all bots in http://lab.llvm.org:8011/buildslaves (there’s so many!). Some of them are down, I therefore have no idea what they run. Here are the bots that will definitely break, with their maintainers:
Galina Kistanova <gkistanova@gmail.com>
am1i-slv1 – gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
as-bldslv4 – Microsoft (R) Visual Studio (R) 2015 (14.0)
ps4-buildslave2 – Microsoft (R) Visual Studio (R) 2015 (14.0)Hexagon QA <llvm.buildmaster@quicinc.com>
hexagon-build-02 – gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2
hexagon-build-03 – gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2Vitaly Buka <vitalybuka@google.com>
sanitizer-buildbot6 – gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4Reid Kleckner <rnk@google.com>
sanitizer-windows – Microsoft (R) Visual Studio (R) 2015 (14.0)Ilia Taraban <mstester.llvm@gmail.com>
windows7-buildbot – Microsoft (R) Visual Studio (R) 2015 (14.0)
The maintainers have 3 options:
I’ve emailed the maintainers and some have already responded. Once all bots are in a good state I’ll commit the patch (unless someone else chimes in with new information).
Release
|
Distro
|
Compiler
|
C++14 lang
|
- | - | - | - |
2003-10
|
RHEL 3
|
GCC 3.2
|
|
2005-02
|
RHEL 4
|
GCC 3.4
|
|
2007-03
|
RHEL 5
|
GCC 4.1
|
|
2010-11
|
RHEL 6
|
GCC 4.4
|
|
2013-12
|
RHEL 7
|
GCC 4.8
|
|For RHEL’s sake, note that one can get newer GCC here:
https://developers.redhat.com/products/developertoolset/overview/
It seems that the “newer GCC” made available there uses the pre-C++11 ABI: https://bugzilla.redhat.com/show_bug.cgi?id=1546704. So, the current proposal could be ambiguous about whether the toolchain from the Red Hat Developer Toolset for RHEL 7 would be a supported toolchain going forward (assuming the GCC version number is new enough).
All the bots should now be updated, thanks to the maintainers for their fast turnaround! Unless there are new comments I’ll commit the patch tomorrow.
The hexagon bots use either clang 6 or clang 3.7 (depending on the builder). Both of these compilers are installed in non-standard locations and are not system compilers. I think this is the reason why the bot page shows gcc, but gcc is not used for building clang.
-Krzysztof
Hello Krzysztof,
The bot description comes from your bot, that’s what in the info/host file.
Please update the description of those bots to avoid any confusions.
Thanks
Galina
Did anyone pick option 1)? If I understand correctly, we probably want
to ensure that at least some bots do this, so we can ensure an old
compiler + LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN build actually remains
functional up until the point support for the old compiler is actually
removed.
Best,
Alex
The patch is about ready to land, which means any older compiler will soft-error (which you can turn off with LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN). I think we should then cherry-pick the patch to the LLVM 8 branch.
The last remaining issue are the buildbots. I audited all bots in http://lab.llvm.org:8011/buildslaves (there’s so many!). Some of them are down, I therefore have no idea what they run. Here are the bots that will definitely break, with their maintainers:
Galina Kistanova <gkistanova@gmail.com>
am1i-slv1 – gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
as-bldslv4 – Microsoft (R) Visual Studio (R) 2015 (14.0)
ps4-buildslave2 – Microsoft (R) Visual Studio (R) 2015 (14.0)Hexagon QA <llvm.buildmaster@quicinc.com>
hexagon-build-02 – gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2
hexagon-build-03 – gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2Vitaly Buka <vitalybuka@google.com>
sanitizer-buildbot6 – gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4Reid Kleckner <rnk@google.com>
sanitizer-windows – Microsoft (R) Visual Studio (R) 2015 (14.0)Ilia Taraban <mstester.llvm@gmail.com>
windows7-buildbot – Microsoft (R) Visual Studio (R) 2015 (14.0)The maintainers have 3 options:
- Pass LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN to their bot, suffer breakage later.
- Update the bot to a newer compiler version.
- Entirely turn down the bot.
I’ve emailed the maintainers and some have already responded. Once all bots are in a good state I’ll commit the patch (unless someone else chimes in with new information).
Did anyone pick option 1)? If I understand correctly, we probably want
to ensure that at least some bots do this, so we can ensure an old
compiler + LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN build actually remains
functional up until the point support for the old compiler is actually
removed.
Reid asked me to do so for sanitizer-windows:
Ideally yes we’d have bots covering all eventualities, but this is but one of many holes in our coverage. On the upside, that hole is disappearing in a few months
After a few attempts I think we’re in sight of success: we only have the two following bots remaining with old versions of libstdc++ and new versions of clang:
polly-amd64-linux
polly-arm-linux
Once fixed the toolchain bump should stick.
It seems the CMake changes have landed; but the docs are still a bit out of date?
CMake.html talks about LLVM_FORCE_USE_OLD_TOOLCHAIN but not LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN.
Also, it looks like LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN is not propagated down to the NATIVE configuration when you set LLVM_OPTIMIZED_TABLEGEN. If that’s going to be a permanent deficiency, it should be mentioned in the docs as well.
Thanks,
–paulr
Indeed this has finally stuck, with just clang-with-lto-ubuntu broken at the moment. I’m inclined to leave it checked in, and try to get it into the LLVM 8 branch as well.
It seems the CMake changes have landed; but the docs are still a bit out of date?
CMake.html talks about LLVM_FORCE_USE_OLD_TOOLCHAIN but not LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN.
I’m. Not sure how one updates the website’s docs, I had assumed the RST files would automatically get rebuilt and pushed? Agreed we want it fixed, but I don’t think it’s good reason to revert since the error message is pretty clear.
Also, it looks like LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN is not propagated down to the NATIVE configuration when you set LLVM_OPTIMIZED_TABLEGEN. If that's going to be a permanent deficiency, it should be mentioned in the docs as well.
Someone mentioned MSVC was having issues that way? rG388cefa78d4d
That seems like general badness in the way that configuration is set up, no? It should probably get fixed separately.
It seems the CMake changes have landed; but the docs are still a bit out of date?
CMake.html talks about LLVM_FORCE_USE_OLD_TOOLCHAIN but not LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN.
I’m. Not sure how one updates the website’s docs, I had assumed the RST files would automatically get rebuilt and pushed? Agreed we want it fixed, but I don’t think it’s good reason to revert since the error message is pretty clear.
Huh. I also thought the website was kept up to date automagically, which is why I looked at the website not the source; but the source does have the new option. Never mind…
Also, it looks like LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN is not propagated down to the NATIVE configuration when you set LLVM_OPTIMIZED_TABLEGEN. If that’s going to be a permanent deficiency, it should be mentioned in the docs as well.
Someone mentioned MSVC was having issues that way? https://reviews.llvm.org/rL353374#624722
That seems like general badness in the way that configuration is set up, no? It should probably get fixed separately
“Somebody else ought to get around to fixing that someday so why bother documenting something that might eventually change” does not seem like a very robust argument. I’ve answered a pile of questions from newcomers lately, I would prefer that people not add new reasons for the documentation to lie about how things work currently. Or more accurately, don’t work, because you can’t currently use both those options at once.
If someone does change how the optimized-tablegen feature works (or eliminates it entirely), surely they would be able to update the documentation accordingly?
So, please fix.
–paulr
Can you clarify what you’re asking for exactly, and who you’re asking it from?
