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 Fri, Nov 8, 2013 at 8:49 AM, <dag at cray.com> wrote:
> Chandler Carruth <chandlerc at google.com> writes:
>
> > The overwhelming majority of contributors and users of trunk seem to
> > be fine with this, so while I'm interested in anything we can do
to
> > make it easier for you, unless we see significantly more concerns
> > about this plan, I think we should move forward.
> >
> > Fundamentally, we aren't going to be able to make everyone happy.
Some
> > people will be seriously inconvenienced by this, but thus far the
> > benefit seems to significantly outweigh the cost.
>
> But the benefit is still there even if it takes a month or two longer.
>
> 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.
>
> What is so hard about waiting an extra month to give people a chance to
> test the new toolchain?

The options we're discussing seem to be:

1) Switch trunk to C++11 at time T. People whose toolchains aren't ready
stop integrating from LLVM trunk until they are ready.
2) Switch trunk to C++11 at time T + an extra month. Again, people whose
toolchains aren't ready stop integrating from LLVM trunk until they are
ready.

For people who are paying attention to this thread, or to the release
notes, or otherwise being engaged in the community, there seems to be very
little difference. If they do (say) weekly integrates, that's *at most*
three extra integrates they miss. That's unfortunate, but not huge.

For people who are *not* paying attention, this makes no difference at all:
they're not going to start switching their toolchain until they notice a
problem.

So I don't see that waiting is a significant win. Conversely, it gives us
less time to get the C++11-enabled code tested across relevant toolchains
(including perhaps rolling back the change if we find a fatal issue) before
we release 3.5 next year.

Setting T = 3.4 release has another advantage: people who stop integrating
then are stopped at a stable, well-tested revision, not after the
inevitable post-release churn.
> That said, while I'm about to commit the change to the release notes
> > and send a summary email to the dev lists, we should continue
> > discussing this. Nothing is going to be set in stone until the 3.4
> > release goes out, and maybe not even then. Especially if you or others
> > want to discuss this with me in person (or others in person) at the
> > dev meeting, I'm writing this email from the hacking session. =]
Happy
> > to chat.
>
> I'm not going to be at the dev meeting.
>
>                          -David
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131108/5559af28/attachment.html>

On 8 November 2013 11:29, Richard Smith <richard at metafoo.co.uk> wrote:
> So I don't see that waiting is a significant win. Conversely, it gives
us
> less time to get the C++11-enabled code tested across relevant toolchains
> (including perhaps rolling back the change if we find a fatal issue) before
> we release 3.5 next year.
>
That's a good point. Still, I think waiting a month for introducing new
C++11 code wouldn't hurt either.

I'm guessing people reading this thread have already accepted that we're
moving, so they should have be doing all the work to move since last week,
which gives us a nice round December frame for new stuff.

David, is that a comfortable window?

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

Is the plan to have autoconf and cmake check for the appropriate C++11 features
and fail if the chosen compiler doesn't support them?  Or do we just have to
wait for some obscure error during the build process some time later?

If autoconf and cmake do the feature checks - they could also tell the user
which was the last safe pre-C++11 revision they should go back to.  Also, based
on what I've read, it seems that even non-conforming compilers might still
support a subset of C++11 features, so a scheduled rollout of new features could
make it a little less painful for some users.

Btw, as long as I can build with either an old version of clang or a recent
version of gcc (linux), I have no problems going to C++11 or beyond.

thanks...
don

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Renato Golin
Sent: Friday, November 08, 2013 11:51 AM
To: Richard Smith
Cc: David Greene; clang-dev Developers; LLVM Developers Mailing List
Subject: Re: [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 11:29, Richard Smith <richard at
metafoo.co.uk<mailto:richard at metafoo.co.uk>> wrote:
So I don't see that waiting is a significant win. Conversely, it gives us
less time to get the C++11-enabled code tested across relevant toolchains
(including perhaps rolling back the change if we find a fatal issue) before we
release 3.5 next year.

That's a good point. Still, I think waiting a month for introducing new
C++11 code wouldn't hurt either.

I'm guessing people reading this thread have already accepted that we're
moving, so they should have be doing all the work to move since last week, which
gives us a nice round December frame for new stuff.

David, is that a comfortable window?

cheers,
--renato

This message contains confidential information and is intended only for the
individual named. If you are not the named addressee, you should not
disseminate, distribute, alter or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system. E-mail transmissions cannot be guaranteed to be
secure or without error as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender, therefore,
does not accept liability for any errors or omissions in the contents of this
message which arise during or as a result of e-mail transmission. If
verification is required, please request a hard-copy version. This message is
provided for information purposes and should not be construed as a solicitation
or offer to buy or sell any securities or related financial instruments in any
jurisdiction.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131108/0f262369/attachment.html>

Richard Smith <richard at metafoo.co.uk> writes:
> Setting T = 3.4 release has another advantage: people who stop
> integrating then are stopped at a stable, well-tested revision, not
> after the inevitable post-release churn.
So what happens if the chosen toolchain versions are discovered to be
buggy, not with LLVM or Clang but by external projects?  Is there a
way to get a new "blessed" toolchain version?

                            -David

Richard Smith <richard at metafoo.co.uk> writes:
> 1) Switch trunk to C++11 at time T. People whose toolchains aren't
> ready stop integrating from LLVM trunk until they are ready.
> 2) Switch trunk to C++11 at time T + an extra month. Again, people
> whose toolchains aren't ready stop integrating from LLVM trunk until
> they are ready.
This flies completely in the face of the development model pushed by the
LLVM leadership.  We've been told over and over, "follow trunk and keep
up to date."  I have in fact been moving us in that direction.  It's a
massive undertaking and it has taken years to get the pieces in place.

I feel like I'm being pulled in two directions: one group says work off
trunk and another says work off major releases.  Which is it?

                               -David

Renato Golin <renato.golin at linaro.org> writes:
> That's a good point. Still, I think waiting a month for introducing
> new C++11 code wouldn't hurt either.
C++11 is orthogonal.  It's the toolchain update that's the issue I'm
worried about.  We have this problem any time we need an upgrade, which
we will in the future to fully support C++11.
> I'm guessing people reading this thread have already accepted that
we're
> moving, so they should have be doing all the work to move since last
> week, which gives us a nice round December frame for new stuff.
>
> David, is that a comfortable window?
No it is not because we don't yet know which specific versions of
toolchains we're going to use.  In our case we need to know the exact
point release of gcc recommended for LLVM.  4.7.x is too vague.  We want
to make sure we're using the same compiler as the rest of the LLVM
community.

The clock has wait to start once we know specific versions.

                                  -David

On Mon, Nov 11, 2013 at 11:04 AM, <dag at cray.com> wrote:
> Richard Smith <richard at metafoo.co.uk> writes:
>
> > 1) Switch trunk to C++11 at time T. People whose toolchains aren't
> > ready stop integrating from LLVM trunk until they are ready.
> > 2) Switch trunk to C++11 at time T + an extra month. Again, people
> > whose toolchains aren't ready stop integrating from LLVM trunk
until
> > they are ready.
>
> This flies completely in the face of the development model pushed by the
> LLVM leadership.  We've been told over and over, "follow trunk and
keep
> up to date."  I have in fact been moving us in that direction. 
It's a
> massive undertaking and it has taken years to get the pieces in place.
>
> I feel like I'm being pulled in two directions: one group says work off
> trunk and another says work off major releases.  Which is it?

Neither. The rule is and remains "follow trunk and keep up to date".

Further, we prioritize what is *right* for trunk and the open-source
project long-term. Sometimes this means a few users of trunk are
inconvenienced or have to pay a higher cost. When this happens, the burden
is on them to pay it (both pulling away from trunk for a few weeks while
they pay the change cost, and pay the cost of catching back up to trunk
afterward).

Are the goal posts moving? Yes. They have to. The project has to be able to
keep moving forward even if it inconveniences one project. The goal is to
not inconvenience *everyone*, especially not contributors.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131111/24f8c4b0/attachment.html>