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

David Tweed <david.tweed at gmail.com> writes:
> A personal question: is there any way we could modify some part of the
> build to do some of the "non-fatal but difficult to ignore"
> announcement if the building compiler can't handle the upcoming
> constructs? Eg, just thinking off the top of my head here, could we
> abuse the make check/lit mechanism to get a file with C++11 features
> that are going to be used in X months compiled with the building
> compiler, so that people running projects following ToT and who run
> "make check" regularly will get a new failure if they'll be
facing
> problems ahead?
This wouldn't address the main issue as I see it.  I am not worried at
all about LLVM and whether I'll be able to build it with a new toolchain
on our machines.  I'm worried about everything *else* we have integrated
with LLVM that will also need to be built with the new toolchain.  It's
all that other stuff that we need to be able to test before LLVM forces
us to use a new toolchain.

When the LLVM 3.4 release is cut, I'm simply asking that we don't start
using stuff that requires a new toolchain right away.  If we could wait
3-4 months that would allow time for testing.  We can still require a
new toolchain for the 3.5 release, allow C++-11, etc..  We just
shouldn't require it on ToT right away.

                            -David

<dag at cray.com> writes:
> I'm worried about everything *else* we have integrated with LLVM that
> will also need to be built with the new toolchain.  It's all that
> other stuff that we need to be able to test before LLVM forces us to
> use a new toolchain.
To be specific, in the past upgrades to toolchains have caused
hard-to-debug incorrect code generation in our tools.  Sometimes that's
because someone wrote non-conforming code but almost as often it's
because of a bug in gcc that we then have to find a workaround for.  In
either case, we have to do a lot of debugging, analysis and come up with
a fix.  That's why we need a lot of lead time.  We can't have things
just break on developers in the middle of a development cycle.  We have
to schedule time for testing the new toolchain, debugging problems and
fixing them BEFORE we move all of our code to the new toolchain.

                         -David

Hi,

On Wed, Nov 6, 2013 at 6:20 PM, <dag at cray.com> wrote:
> David Tweed <david.tweed at gmail.com> writes:
>
> > A personal question: is there any way we could modify some part of the
> > build to do some of the "non-fatal but difficult to ignore"
> > announcement if the building compiler can't handle the upcoming
> > constructs? Eg, just thinking off the top of my head here, could we
> > abuse the make check/lit mechanism to get a file with C++11 features
> > that are going to be used in X months compiled with the building
> > compiler, so that people running projects following ToT and who run
> > "make check" regularly will get a new failure if they'll
be facing
> > problems ahead?
>
> This wouldn't address the main issue as I see it.  I am not worried at
> all about LLVM and whether I'll be able to build it with a new
toolchain
> on our machines.  I'm worried about everything *else* we have
integrated
> with LLVM that will also need to be built with the new toolchain.  It's
> all that other stuff that we need to be able to test before LLVM forces
> us to use a new toolchain.
>
> When the LLVM 3.4 release is cut, I'm simply asking that we don't
start
> using stuff that requires a new toolchain right away.  If we could wait
> 3-4 months that would allow time for testing.  We can still require a
> new toolchain for the 3.5 release, allow C++-11, etc..  We just
> shouldn't require it on ToT right away.
>
> Fair enough: my concern was that we haven't heard much from other
people
who are following ToT but aren't primarily LLVM developers in this
discussion, yet I talk to a lot of people who say they pull in ToT quite
regularly. So the thing that was concerning me was that an email gets sent
to the dev mailing list announcing this. Maybe the affected people will
read it, maybe they won't (I know I don't have the time to do more than
skim the mailing lists). At least with some big smoking gun in the code
it's easier to persuade management this is a serious issue that needs time
budgetting for investigation NOW.

But I entirely appreciate that the problem may be that everyone knows but
still needs time to do due diligence on a new toolchain.
-- 
cheers, dave tweed__________________________
high-performance computing and machine vision expert: david.tweed at gmail.com
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131107/aa89fc22/attachment.html>

David Tweed <david.tweed at gmail.com> writes:
> Fair enough: my concern was that we haven't heard much from other
> people who are following ToT but aren't primarily LLVM developers in
> this discussion, yet I talk to a lot of people who say they pull in
> ToT quite regularly. So the thing that was concerning me was that an
> email gets sent to the dev mailing list announcing this. Maybe the
> affected people will read it, maybe they won't (I know I don't have
> the time to do more than skim the mailing lists). At least with some
> big smoking gun in the code it's easier to persuade management this is
> a serious issue that needs time budgetting for investigation NOW.
I agree this is an important issue to address.  I can't more than skim
the e-mail lists either.
> But I entirely appreciate that the problem may be that everyone knows
> but still needs time to do due diligence on a new toolchain.
I think it's both.  People might not know and they have lots of code to
test.

                          -David