This will affect anyone using the LLVM C++ API. It shouldn't affect clients of the C APIs.
-Chris
Chris Lattner <clattner@apple.com> writes:
One short term caveat: Windows is special.
s/Windows/Visual Studio.
MinGW has the latest and greatest gcc.
I don't see how it is special.
It is special, sadly, and I'm not talking about C++11 support only, but
about the policies MS follows which too often makes very inconvenient
(or even impossible) to upgrade to newer VS versions. The latest example
that comes to mind was the release of VS2012: they removed Windows XP
support, as if upgrading the OS is a non-issue if you ask for it to your
users on a polite tone. An uproar followed and they backpedaled on a
service pack some months later, but that not always happens.
I'm sorry, let me clarify. I'm saying that MSVC shouldn't be special from an LLVM policy perspective. We shouldn't have a general rule with an exception for MSVC: we should have a general rule that includes MSVC user's requirements as well.
This is why I don't like a general rule of "anything older than 2 years isn't supported".
Now for the carrot: if we go with this plan, then immediately after
branching for 3.4, we would be able to use the vast majority of
C++11 features, targeting the following as the oldest toolchains
supported through the 3.5 release timeframe:GCC 4.7
Clang 3.1
VS 2012This seems overly aggressive to me. Why not start by baselining at
VC++ 2010, and bump up everything else to match?IIRC the only significant difference among VS 2012 and VS 2010 is range
for loops.
Which is really sad, given how nice they are, but I think it would be huge progress to move LLVM 3.4 to require the VS 2010 feature set (and the corresponding GCC/clang/etc versions). We can move up to VS 2012 as a second step and second discussion.
-Chris
I may be remembering incorrectly, but I thought we already supported
only VS2010 and higher today. AFAIK, there are no 2008 build bots as
part of the process, and I've not seen a 2008-specific patch for
compatibility in ages.
~Aaron
Even better! Can we start adopting C++'11 features in LLVM 3.3 then?
-Chris
This could be one of the design guidelines: use any feature supported by
the last LLVM release.
Which could force some distros to compile Clang more than once, but it
could also mean people would migrate faster to more modern compilers.
cheers,
--renato
I’m not sure what you mean. Are your proposing that clang 3.4 use any features supported by clang 3.3? If so, that won’t work, because clang can’t self-host on all interesting architectures, e.g. it isn’t fully ABI compatible with Visual C++ (yet).
-Chris
No, not yet. Certainly not for 3.4!
My comment was more to the effect that we could use this as a target for
the future (and probably never achieve it), thus why "design guideline" and
not a developer policy.
We'll have to make sure we can do it on all "interesting" architectures
first (given all constraints).
--renato
wrote:> Concrete long term proposal:
>
> We support building with C++ toolchains which were released and widely
available on their respective target platforms at least 2 years prior to
the next 6-month-cycle release. Immediately after each branch of a release,
mainline can move the bar forward by 6 months. Thus, each release should
build with the four previous releases.I don't think it makes sense to have a hard policy like this. It is fine
to have a goal that allows us to continue picking up new features over
time, but I think each such change will have to be discussed (at length)
with the specifics of which interesting host configurations we would be
dropping.
I didn't really intend to indicate this would be a hard policy, more that
it would be the guideline. Part of the idea is that after each release
branch is cut we could evaluate what a reasonable baseline would look like.
I do think that 2 years is a good guideline, in part because two of the
three toolchains which impact us most already use time-driven release
cycles.
My hope is that we could *strive* for no more than two years of support for
older toolchains as a way to push ourselves to not let this slip.
An obvious other input to this decision would be exactly what Benjamin
brought up: we should look at what toolchain versions various OSes are
shipping with. However, I think the diversity of OS is too broad to be
easily explained in our getting started docs, etc. I would rather use the
OS situation to inform the particular versions of each toolchain that we
try to support, but to word the decision in terms of the toolchain versions.
One short term caveat: Windows is special.
I don't see how it is special. We should just look at all of the
compilers we need to support, and factor that set in. We should continue
to increment the baseline compilers over time, but a global "two year old
compilers only" policy doesn't make sense to me. I also think that windows
will be the lowest bar anyway.
See above. I'm not interested in a hard policy. I think MSVC will end up
being special because we may realistically want a *narrower* set of
toolchains supported there given both the rapid advances of MSVC in the
last year, and the rapid changes to Clang and LLVM's role on that platform.
(And note, I misspoke previously, clearly MinGW is just GCC, I'm talking
about MSVC here)
Now for the carrot: if we go with this plan, then immediately after
branching for 3.4, we would be able to use the vast majority of C++11
features, targeting the following as the oldest toolchains supported
through the 3.5 release timeframe:
>
> GCC 4.7
> Clang 3.1
> VS 2012This seems overly aggressive to me. Why not start by baselining at VC++
2010, and bump up everything else to match? That would give us some basic
C++'11 features for 3.4, then we could bump it up to VS 2012 in 3.5 if that
goes well.
As others have pointed out, our baseline is already VS 2010, but our C++11
features have been held back by concern over GCC. I think the time frame is
right to jump all the way to GCC 4.7 as the target for our 3.5 release, and
would like to bump VS to 2012 at the same time if at all possible.
This isn't just a bump either, it brings things that I think will be very
useful:
- Fixed semantics for r-value references that is relevant to using move
semantics broadly in LLVM
- Range-based for loops, because as much as people say it "just reduces
boiler plate", omg it is so much nicer
- better concurrency support, notably we may be able to use the standard
atomics library (with some testing and restrictions) which have compiler
assistance behind them.
Strong agreement. I think the most interesting would be the parts that need
compiler assistance, such as type traits and atomics. Even then, the nice
thing about the library is that we can easily test out the waters, and
supplement with our own libraries as needed. We have a harder time of that
with language features.
Yes, and I really do not think we should be hamstrung by RHEL/CentOS. They
can cross-compile or otherwise bootstrap via a locally installed Clang
released in the previous two years.
I think that just establishing a floor on the problem (a soft one, which
naturally has to be interpreted based on the realities at the time) is the
best first step. I *don't* want to lose the ability to host LLVM and Clang
with reasonably modern C++ toolchains that are not Clang-derived. I *do*
want to set expectations with clear guidelines for what we consider
"reasonably modern" to be.
I might be mistaken, but to compile for WinXP on VS 2012 you have to switch the Platform Toolset and AFAICT that means it will essentially be using the VS 2010 compiler and libraries. So when it comes to using newer C++ functionality you will still be stuck on the VS 2010 level even if you are using VS 2012 and if you are using any VS2012 improvements you will not be able to compile for XP.
Basically (again: AFAICT): if you want clang to be compiled for WinXP using VS, the C++ features of VS 2010 are a hard limit and that will not change.
Dix
XP mainstream support is already EOL and extended support is April 2014
http://windows.microsoft.com/en-us/windows/products/lifecycle
I can guess it may get extended, but imho it seems unreasonable to hold up clang based on a non-supported product. (Yes the reality is many many people will continue to use it, but....)
Wasn't VS 2012 express the 1st to ship a free 64bit C++ compiler?
I couldn't agree more.
My jump the gun moment was due to the fact that I always estimate
minimum/expected/maximum outcomes, to make sure they follow a nice linear
scale with respect to features/work/cost/time. Having the "previous
support" as standard would be a maximum, in a world where Clang/LLVM is the
de-facto standard on all platforms. It'll never happen, but it's a
direction that would bring nice surrounding improvements if pursued.
cheers,
--renato
Dix Lorenz <lists@dix-lorenz.de> writes:
I might be mistaken, but to compile for WinXP on VS 2012 you have to
switch the Platform Toolset and AFAICT that means it will essentially
be using the VS 2010 compiler and libraries.
That was how VS 2012 worked at release time. On Update 1 they added
support for building Windows XP applications with the VS 2012 compiler.
VS 2013 C++ compiler can build XP applications too.
[snip]
So this complexity highlights to me one important thing: whatever group of
MSVC tools are
selected as the baseline, it would be really helpful to have people
knowledgeable
about that contribute to the description of precisely which C++11
constructs are
allowed (and if there are any surprising cases which don't work), for those
of us
who have no idea precisely what will get past an MSVC compiler and no means
or desire to set up a Windows system just for testing. It's very
frustrating when
development turns in to a "I checked on all my systems, checked in and get
complaints from people on very different systems whose build broke"
experience.
(Yeah, I know there's any irony there...) Getting a clearly delimited
feature list
should help reduce that.
Cheers,
Dave
Fortunately, we have a bunch of really active contributors working closely
with Visual Studio. =] I'm very confident that between Reid, Warren, Hans,
Rui, Michael, Anton, and others we can figure out clear and well understood
guidelines.
Naturally, building with Visual Studio will be the final test. We have
build bots and a lot of active developers so I don't think we'll lose sight
of this.
Here is a table detailing C++11 features support for Visual C++ 2010, 2012, 2013
http://msdn.microsoft.com/en-us/library/vstudio/hh567368.aspx
Specifically, range-based for loops are supported in Visual C++ 2012, 2013 but not in 2010.
Yaron
Thanks, that table is very helpful, although I note that there are several rows whose entries are “Partial”, so I either those features need to be disallowed or some description of what partial means would seem to be required there.
David Tweed wrote:
So this complexity highlights to me one important thing: whatever group of
MSVC tools are
selected as the baseline, it would be really helpful to have people
knowledgeable
about that contribute to the description of precisely which C++11
constructs are
allowed
CMake 3.0.0 will have a features support where you specify the features you
require, and an error is reported at CMake time if the in-use compiler does
not support the feature (and CMake will add the required -std flag if
needed).
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6726/focus=7746
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6726/focus=7819
target_compiler_features(foo
# 'PUBLIC' means the foo target requires the following features in its
# implementation and its interface:
PUBLIC
cxx_variadic_templates
cxx_override_control
cxx_lambdas
)
The names of features are chosen correspond with clang features where it
makes sense:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/8115/focus=8277
Thanks,
Steve.