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 8 November 2013 08:49, <dag at cray.com> wrote:
> This is a *serious* issue.  It doesn't seem like people really
> comprehend the challenges of upgrading toolchains in large software
> projects.  We're talking about millions and millions of lines of code
> spread out over many independent modules.  These all have to fit
> together to create a usable tool.
>
I think we got into two modal states where people believe one side want to
add all C++11 stuff tomorrow and the other never. This is not the case.

Chandler adding it to the release notes will say that, very likely, the
release 3.5 will have some C++11. It doesn't say that on the day after 3.4
is branched, we'll have a complete re-write of our algorithms.

If you're following trunk, you're already used to API changes. The main
difference is that the first C++11 new change will force you to change the
compiler for your project. It could not happen, if we have enough pressure
(I haven't moved my project yet!), but there will be back pressure (please
move! do you need help?!). Or it could happen quite quickly, if we all find
out that it wasn't that hard after all. I don't know.


What is so hard about waiting an extra month to give people a chance
to
> test the new toolchain?
>
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. Whenever you're ready, announce on the
list, and people can start sending patches. There will probably be corner
cases (cross-compilation of small embedded devices), and we can all help
with the migration, but chances are that Clang already supports it.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131108/dc09632c/attachment.html>

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.

                                 -David

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>