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

On Mon, Nov 11, 2013 at 02:14:57PM -0600, dag at cray.com
wrote:
> Chandler Carruth <chandlerc at google.com> writes:
> 
> >     As far as I know no decision on specific versions has been made.
> >
> > To quote my summary email: "This will at least include Visual
Studio
> > 2012 on Windows, and Clang 3.1 or GCC 4.7.x on Mac and Linux."
> 
> 4.7.x is not a specific version.
> 
> > The biggest debate has been around 2010 vs. 2012 (we decided 2012 was
> > viable and desirable), and on which value of 'x' to use in GCC
4.7.x.
> > My suggestion would be "whatever version of 'x' is on
your distro",
> > and if other distributions come with other versions, we'll test
them
> > and try to make them work. 4.7.0 was fairly broken, but 4.7.1 seems to
> > have been quite stable and to have gotten into essentially all of the
> > recent releases I've checked. I've not heard any objections to
these
> > versions with specific problems they present.
> 
> I don't care about specific versions, just that we have one.
> 
I think that if we are committed to supporting gcc 4.7.x in LLVM, then
we need to be prepared to not use c++11 features that may be broken in
earlier 4.7.x releases.

This means that whatever 4.7.x users choose should be 'safe' as long
as they are committed to testing it on their platform and reporting
bugs upstream.

-Tom

> I think that if we are committed to supporting gcc 4.7.x in LLVM, then
> we need to be prepared to not use c++11 features that may be broken in
> earlier 4.7.x releases.
We've got precedent for "broken compilers" documentation. Dodgy
versions of 4.7.x could easily come under that heading (depending on
how widely deployed they actually are: only time will tell).

Tim.

On Mon, Nov 11, 2013 at 06:32:17PM -0800, Tim Northover
wrote:
> > I think that if we are committed to supporting gcc 4.7.x in LLVM, then
> > we need to be prepared to not use c++11 features that may be broken in
> > earlier 4.7.x releases.
> 
> We've got precedent for "broken compilers" documentation.
Dodgy
> versions of 4.7.x could easily come under that heading (depending on
> how widely deployed they actually are: only time will tell).
> 
My point is that we can't tell users we support 4.7.x and then expect
them to just change their compiler if someone adds a c++11 feature that
is broken on whatever 4.7.x version of gcc they have chosen.

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.

-Tom