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 10:54 AM, <dag at cray.com> wrote:
> Renato Golin <renato.golin at linaro.org> writes:
>
> > Nothing. And adding a note to the release won't make it come
faster
> > "just because". I think it's perfectly reasonable to
wait a few month
> > in 3.5 trunk for every one to accommodate.
>
> Just to be clear, that should be a few months from the time the new
> required toolchain versions are posted on the web site.  An e-mail is
> good too but those are easy to miss.  This is important enough to have
> a permanent announcement somewhere.
>
> 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."

These versions were in my original email and in the release notes update.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131111/64d53f7d/attachment.html>

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.

                        -David

On Mon, Nov 11, 2013 at 3:14 PM,  <dag at cray.com>
wrote:
> Chandler Carruth <chandlerc at google.com> writes:
>>
>> 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.
Yes, it is.

It indicates any sub-release in the GCC 4.7 series. For all intents
and purposes, all the sub-sub-versions in an X.Y GCC release are
identical.


Diego.

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