[LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

Chandler Carruth chandlerc at google.com
Tue Nov 12 10:41:35 PST 2013


On Tue, Nov 12, 2013 at 10:20 AM, <dag at cray.com> wrote:

> Chris Lattner <clattner at apple.com> writes:
>
> >> If we say we support 4.7.x, then I don't think we should use c++11
> >> features that aren't supported and working on all 4.7.x versions.
> >
> > Why not just explicitly say 4.7.1 and later?  Are there any buildbots
> > that build with 4.7.1 yet?  If not, that should be a prerequisite to
> > making the move.
>
> Does that statement include 4.8.x and beyond?
>
> My main concern, as outlined in another message I just sent, is what
> "4.7.1 and later" means in terms of support from upstream.  Do the
> inevitable problems discovered get worked around in the LLVM project
> sources or are problematic compilers simply noted as such in the
> documentation, potentially forcing users to upgrade their toolchain
> again?
>
> I can see tradeoffs with each strategy.  It's important to be clear so
> we have proper expectations.
>

I don't think we can predict this.

I think we clearly *want* to support all of the point releases that we can,
but I think we would have to look at the *specific* work arounds for any
toolchain bug discovered, as well as how widespread that toolchain was in
terms of deployment. I can imagine both cases where we would easily work
around the problem, and other cases where it would be completely
unmaintainable.

I'm pushing on this because although most toolchain upgrades are simple,
> when they go bad they go REALLY bad.  It's a risk that has to be
> managed.


While I understand that, the problem you're highlighting isn't new and
isn't related to C++11. Discussing it here isn't really productive.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131112/f492762f/attachment.html>


More information about the llvm-dev mailing list