llvm dev - Oct 2016 - [cfe-dev] Revisiting our informal policy to support two versions of MSVC

Thank you both, we appreciate it a lot!
On Thu, 8 Sep 2016 at 16:37, Aaron Ballman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Thu, Sep 8, 2016 at 11:24 AM, Reid Kleckner via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > I can't say I'm excited to support MSVC 2013 for another
month, but I'm
> more
> > concerned about the burden on other developers. People I talked to at
> the SF
> > bay area social last Thursday were really excited to drop 2013
support. I
> > guess I'll leave my buildbots on another month and see how it
goes.
>
> I'm happy to help carry the burden as well, so if you run into
> anything you'd like to punt over to me, please let me know. I'm
happy
> to handle it in addition to the things I usually pick up on.
>
> ~Aaron
>
> >
> > On Thu, Sep 8, 2016 at 7:03 AM, Robinson, Paul via llvm-dev
> > <llvm-dev at lists.llvm.org> wrote:
> >>
> >> As this is an ABI-incompatible upgrade, and it's changing the
informal
> >> policy on upgrades, could we please have some more grace time?
Ideally
> >> another month, so the 15th October. If we haven't sorted it by
then,
> it's
> >> our problem.
> >>
> >>
> >>
> >> I had originally proposed 15 September mostly because nobody had
> proposed
> >> a specific date, and it has been kind of dragging on for a while. 
The
> >> primary cost of deferring to 15 October seems to be that the
community
> (Hi
> >> Reid!) will have to keep fixing VS2013 related problems for
another
> month,
> >> which isn't ideal but hopefully we can tolerate it.
> >>
> >> (In fact at Sony we're only throwing the internal switch
today, and
> we'll
> >> have to see what happens.)
> >>
> >> --paulr
> >>
> >>
> >>
> >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On
Behalf Of
> >> Craig, Ben via llvm-dev
> >> Sent: Wednesday, September 07, 2016 2:42 PM
> >> To: Zachary Turner; James Molloy; llvm-dev at lists.llvm.org
> >> Subject: Re: [llvm-dev] [cfe-dev] Revisiting our informal policy
to
> >> support two versions of MSVC
> >>
> >>
> >>
> >> I'll need to dig up the references for that... but I'm
pretty sure the
> >> universal CRT that debuted in MSVC 2015 only covers the C parts,
and
> not the
> >> C++ parts.
> >>
> >>
> >>
> >> On 9/7/2016 4:28 PM, Zachary Turner wrote:
> >>
> >> It's worth pointing out that from 2015 and on, they claim to
support
> full
> >> forwards compatibility of the standard libraries, so this should
(in
> theory)
> >> never be an issue again.
> >>
> >>
> >>
> >> On Wed, Sep 7, 2016 at 1:12 PM James Molloy via llvm-dev
> >> <llvm-dev at lists.llvm.org> wrote:
> >>
> >> Hi,
> >>
> >> As I understand it the specific issue we're seeing is related
to what
> >> Martin described. But due to numerous bugs found when mixing
objects
> >> compiled with different versions of MSVC in the past, we now are
shy of
> >> doing it even if it seems to work superficially - that's no
guarantee
> bugs
> >> won't be found down the line. We'd much prefer to stay
within the
> realms of
> >> what Microsoft support.
> >>
> >> Cheers,
> >>
> >> James
> >>
> >> On Wed, 7 Sep 2016 at 20:53, Craig, Ben via llvm-dev
> >> <llvm-dev at lists.llvm.org> wrote:
> >>
> >> Note that this is intentional from the MSVC C++ library
implementation
> >> side of things.  For major versions, no attempt is made to
preserve
> library
> >> ABI compatibility.
> >>
> >> I am aware of a language ABI break in VC++ 2013.
> >>
>
https://randomascii.wordpress.com/2013/12/01/vc-2013-class-layout-change-and-wasted-space/
> >>
> >> I'm not currently aware of any on the VC++ 2015 side of
things, but that
> >> doesn't mean much.
> >>
> >>
> >>
> >> On 9/7/2016 2:34 PM, Martin O'Riordan via llvm-dev wrote:
> >>
> >> Apart from the obvious licencing issues, each time I have moved
from one
> >> version of VC++ to another, the big problem I have had is not
> specifically
> >> the ABI at the register passing, stack organisation level, but
rather
> the
> >> implementation details of the Standard C++ libraries, and in
particular
> the
> >> STL containers.
> >>
> >> While the compiler team puts considerable effort into maintaining
the
> ABI,
> >> the C++ library implementation usually changes a lot.
> >>
> >> Since this is largely in the form of very complex headers defining
> >> templates which in turn cause other helper templates to be used,
it is
> here
> >> that I find things go awry.
> >>
> >> So for C++, a function like:
> >>
> >> std::list<int> foo();
> >>
> >>
> >>
> >> seems simple enough, but if the caller and the callee are compiled
with
> >> different versions, it usually won't work because of some
artefact of
> the
> >> STL implementation tuning that occurs between versions.  In
particular,
> this
> >> impacts things like using C++ interfaces across DLLs and in
pre-compiled
> >> libraries.
> >>
> >> I think that the ABI maintenance in this case tends to be for C
and POD
> >> compatability, but not for the higher level C++ compatability
which is
> >> unfortunate and restricts how we can use C++.
> >>
> >> Is it possible that it is this aspect of the version change that
is
> >> causing your ABI difficulties?
> >>
> >> MartinO
> >>
> >>
> >>
> >>
> >>
> >> On 7 September 2016 at 20:18, Zachary Turner via llvm-dev
> >> <llvm-dev at lists.llvm.org> wrote:
> >>
> >> Can you elaborate on the abi incompatibility? I thought there were
no
> >> breaks
> >>
> >> On Wed, Sep 7, 2016 at 7:59 AM James Molloy via cfe-dev
> >> <cfe-dev at lists.llvm.org> wrote:
> >>
> >> Hi all,
> >>
> >>
> >>
> >> Firstly sorry I'm a bit late responding on this one.
Internally to ARM
> we
> >> build LLVM for Windows. Our current build cluster has only VS2013
> installed
> >> and as a result of this thread we've been working on getting
VS2015
> >> installed. This involves a certain amount of IT-wrangling as the
> cluster we
> >> use is company-wide. There have been some hiccups regarding
licensing of
> >> MSVC professional (we can't use the community edition for the
same
> reasons
> >> mentioned by Paul previously) but we hoped to be ready in time for
the
> 15th
> >> September switchover date.
> >>
> >>
> >>
> >> It's recently been realised that VS2013 and VS2015 are not ABI
> compatible
> >> (something that really surprised me), and this means we have to
> synchronize
> >> moving LLVM's build to VS2015 as well as upgrading a third
party library
> >> that we receive from the vendor in compiled library form. This is
not
> >> something we're capable of doing by September 15th.
> >>
> >>
> >>
> >> We try really hard at ARM to hide our internal processes because
we
> >> believe that they're on the whole irrelevant to the community,
however
> in
> >> this case we'd be really stuck, unable to get production
builds.
> >>
> >>
> >>
> >> As this is an ABI-incompatible upgrade, and it's changing the
informal
> >> policy on upgrades, could we please have some more grace time?
Ideally
> >> another month, so the 15th October. If we haven't sorted it by
then,
> it's
> >> our problem.
> >>
> >>
> >>
> >> Cheers,
> >>
> >>
> >>
> >> James
> >>
> >>
> >>
> >> On Thu, 1 Sep 2016 at 21:06 Mehdi Amini via cfe-dev
> >> <cfe-dev at lists.llvm.org> wrote:
> >>
> >> On Sep 1, 2016, at 1:05 PM, Reid Kleckner <rnk at
google.com> wrote:
> >>
> >>
> >>
> >> On Thu, Sep 1, 2016 at 12:53 PM, Mehdi Amini via cfe-dev
> >> <cfe-dev at lists.llvm.org> wrote:
> >>
> >> Isn’t a big (the most) reason for supporting “old” toolchains to
allow
> >> downstream users to upgrade with some flexibility?
> >>
> >> If I have a large codebase that is using LLVM (let say a few
custom
> >> backends), and is validated with “MSVC 2013”, I can upgrade to
“2015”
> but I
> >> will need some qualification/validation: this is not free and take
some
> >> time. If you drop aggressively supports for “old” toolchain it
means
> that
> >> I’m either stuck with an “old” LLVM or that I have to update
earlier
> than
> >> expected.
> >>
> >>
> >>
> >> Isn’t this usually balanced in upstream LLVM to upgrade when there
is a
> >> real *benefit* to it?
> >>
> >> I’m mentioning it because it seems to conflict with the
"always upgrade
> to
> >> the newest one unless there are serious issues with it” you
mentioned
> above.
> >>
> >>
> >>
> >> I agree, we should raise the minimum VS version requirement when
the
> >> benefits to the LLVM community outweigh the costs of switching for
major
> >> LLVM contributors and users. I think we'll always make that
decision in
> the
> >> same way: by raising it on the mailing lists and discussing the
pros and
> >> cons. That's basically what David said when he kicked this
whole
> discussion
> >> off, anyway:
> >>
> >>
> >>
> >> """But if we find ourselves in a situation where
asking folks to upgrade
> >> to a compiler which has been widely deployed soothes development
for the
> >> greater LLVM community, we should consider dropping support for
the
> older
> >> versions of that compiler."""
> >>
> >>
> >>
> >> I think everything is working as intended here.
> >>
> >>
> >>
> >> Right, to be clear there is no misunderstanding: I was absolutely
not
> >> suggesting the opposite when answering Zach..
> >>
> >>
> >>
> >> —
> >>
> >> Mehdi
> >>
> >>
> >>
> >>
> >>
> >> We raised the VS 2013 upgrade issue, discussed it, determined that
it
> was
> >> holding us back, and now we're doing the upgrade. If VS
"15" brings
> major
> >> language compatibility improvements, I imagine we'll be having
this same
> >> discussion again next year. If it doesn't, and supporting 2015
and "15"
> at
> >> the same time has the same cost, then we won't bother raising
the floor
> for
> >> a while.
> >>
> >>
> >>
> >> _______________________________________________
> >> cfe-dev mailing list
> >> cfe-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >>
> >> _______________________________________________
> >> cfe-dev mailing list
> >> cfe-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >>
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >>
> >> LLVM Developers mailing list
> >>
> >> llvm-dev at lists.llvm.org
> >>
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> >>
> >>
> >> --
> >>
> >> Employee of Qualcomm Innovation Center, Inc.
> >>
> >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a
> Linux
> >> Foundation Collaborative Project
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> >>
> >>
> >> --
> >>
> >> Employee of Qualcomm Innovation Center, Inc.
> >>
> >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a
> Linux
> >> Foundation Collaborative Project
> >>
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160908/aa8cc152/attachment-0001.html>

Hi James,

Are you still on track for pulling the plug on MSVC 2013 at the end next week?

As another data point, other than new features or build failures, I just had to
debug (with the help of Intel folks) a runtime failure because of a bug with
zero-initialization in MSVC 2013 (see
https://connect.microsoft.com/VisualStudio/feedback/details/802160 ).

— 
Mehdi

> On Sep 8, 2016, at 8:38 AM, James Molloy via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Thank you both, we appreciate it a lot!
> On Thu, 8 Sep 2016 at 16:37, Aaron Ballman via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> On Thu, Sep 8, 2016 at 11:24 AM, Reid Kleckner via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
> > I can't say I'm excited to support MSVC 2013 for another
month, but I'm more
> > concerned about the burden on other developers. People I talked to at
the SF
> > bay area social last Thursday were really excited to drop 2013
support. I
> > guess I'll leave my buildbots on another month and see how it
goes.
> 
> I'm happy to help carry the burden as well, so if you run into
> anything you'd like to punt over to me, please let me know. I'm
happy
> to handle it in addition to the things I usually pick up on.
> 
> ~Aaron
> 
> >
> > On Thu, Sep 8, 2016 at 7:03 AM, Robinson, Paul via llvm-dev
> > <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
> >>
> >> As this is an ABI-incompatible upgrade, and it's changing the
informal
> >> policy on upgrades, could we please have some more grace time?
Ideally
> >> another month, so the 15th October. If we haven't sorted it by
then, it's
> >> our problem.
> >>
> >>
> >>
> >> I had originally proposed 15 September mostly because nobody had
proposed
> >> a specific date, and it has been kind of dragging on for a while. 
The
> >> primary cost of deferring to 15 October seems to be that the
community (Hi
> >> Reid!) will have to keep fixing VS2013 related problems for
another month,
> >> which isn't ideal but hopefully we can tolerate it.
> >>
> >> (In fact at Sony we're only throwing the internal switch
today, and we'll
> >> have to see what happens.)
> >>
> >> --paulr
> >>
> >>
> >>
> >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org
<mailto:llvm-dev-bounces at lists.llvm.org>] On Behalf Of
> >> Craig, Ben via llvm-dev
> >> Sent: Wednesday, September 07, 2016 2:42 PM
> >> To: Zachary Turner; James Molloy; llvm-dev at lists.llvm.org
<mailto:llvm-dev at lists.llvm.org>
> >> Subject: Re: [llvm-dev] [cfe-dev] Revisiting our informal policy
to
> >> support two versions of MSVC
> >>
> >>
> >>
> >> I'll need to dig up the references for that... but I'm
pretty sure the
> >> universal CRT that debuted in MSVC 2015 only covers the C parts,
and not the
> >> C++ parts.
> >>
> >>
> >>
> >> On 9/7/2016 4:28 PM, Zachary Turner wrote:
> >>
> >> It's worth pointing out that from 2015 and on, they claim to
support full
> >> forwards compatibility of the standard libraries, so this should
(in theory)
> >> never be an issue again.
> >>
> >>
> >>
> >> On Wed, Sep 7, 2016 at 1:12 PM James Molloy via llvm-dev
> >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
> >>
> >> Hi,
> >>
> >> As I understand it the specific issue we're seeing is related
to what
> >> Martin described. But due to numerous bugs found when mixing
objects
> >> compiled with different versions of MSVC in the past, we now are
shy of
> >> doing it even if it seems to work superficially - that's no
guarantee bugs
> >> won't be found down the line. We'd much prefer to stay
within the realms of
> >> what Microsoft support.
> >>
> >> Cheers,
> >>
> >> James
> >>
> >> On Wed, 7 Sep 2016 at 20:53, Craig, Ben via llvm-dev
> >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
> >>
> >> Note that this is intentional from the MSVC C++ library
implementation
> >> side of things.  For major versions, no attempt is made to
preserve library
> >> ABI compatibility.
> >>
> >> I am aware of a language ABI break in VC++ 2013.
> >>
https://randomascii.wordpress.com/2013/12/01/vc-2013-class-layout-change-and-wasted-space/
<https://randomascii.wordpress.com/2013/12/01/vc-2013-class-layout-change-and-wasted-space/>
> >>
> >> I'm not currently aware of any on the VC++ 2015 side of
things, but that
> >> doesn't mean much.
> >>
> >>
> >>
> >> On 9/7/2016 2:34 PM, Martin O'Riordan via llvm-dev wrote:
> >>
> >> Apart from the obvious licencing issues, each time I have moved
from one
> >> version of VC++ to another, the big problem I have had is not
specifically
> >> the ABI at the register passing, stack organisation level, but
rather the
> >> implementation details of the Standard C++ libraries, and in
particular the
> >> STL containers.
> >>
> >> While the compiler team puts considerable effort into maintaining
the ABI,
> >> the C++ library implementation usually changes a lot.
> >>
> >> Since this is largely in the form of very complex headers defining
> >> templates which in turn cause other helper templates to be used,
it is here
> >> that I find things go awry.
> >>
> >> So for C++, a function like:
> >>
> >> std::list<int> foo();
> >>
> >>
> >>
> >> seems simple enough, but if the caller and the callee are compiled
with
> >> different versions, it usually won't work because of some
artefact of the
> >> STL implementation tuning that occurs between versions.  In
particular, this
> >> impacts things like using C++ interfaces across DLLs and in
pre-compiled
> >> libraries.
> >>
> >> I think that the ABI maintenance in this case tends to be for C
and POD
> >> compatability, but not for the higher level C++ compatability
which is
> >> unfortunate and restricts how we can use C++.
> >>
> >> Is it possible that it is this aspect of the version change that
is
> >> causing your ABI difficulties?
> >>
> >> MartinO
> >>
> >>
> >>
> >>
> >>
> >> On 7 September 2016 at 20:18, Zachary Turner via llvm-dev
> >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
> >>
> >> Can you elaborate on the abi incompatibility? I thought there were
no
> >> breaks
> >>
> >> On Wed, Sep 7, 2016 at 7:59 AM James Molloy via cfe-dev
> >> <cfe-dev at lists.llvm.org <mailto:cfe-dev at
lists.llvm.org>> wrote:
> >>
> >> Hi all,
> >>
> >>
> >>
> >> Firstly sorry I'm a bit late responding on this one.
Internally to ARM we
> >> build LLVM for Windows. Our current build cluster has only VS2013
installed
> >> and as a result of this thread we've been working on getting
VS2015
> >> installed. This involves a certain amount of IT-wrangling as the
cluster we
> >> use is company-wide. There have been some hiccups regarding
licensing of
> >> MSVC professional (we can't use the community edition for the
same reasons
> >> mentioned by Paul previously) but we hoped to be ready in time for
the 15th
> >> September switchover date.
> >>
> >>
> >>
> >> It's recently been realised that VS2013 and VS2015 are not ABI
compatible
> >> (something that really surprised me), and this means we have to
synchronize
> >> moving LLVM's build to VS2015 as well as upgrading a third
party library
> >> that we receive from the vendor in compiled library form. This is
not
> >> something we're capable of doing by September 15th.
> >>
> >>
> >>
> >> We try really hard at ARM to hide our internal processes because
we
> >> believe that they're on the whole irrelevant to the community,
however in
> >> this case we'd be really stuck, unable to get production
builds.
> >>
> >>
> >>
> >> As this is an ABI-incompatible upgrade, and it's changing the
informal
> >> policy on upgrades, could we please have some more grace time?
Ideally
> >> another month, so the 15th October. If we haven't sorted it by
then, it's
> >> our problem.
> >>
> >>
> >>
> >> Cheers,
> >>
> >>
> >>
> >> James
> >>
> >>
> >>
> >> On Thu, 1 Sep 2016 at 21:06 Mehdi Amini via cfe-dev
> >> <cfe-dev at lists.llvm.org <mailto:cfe-dev at
lists.llvm.org>> wrote:
> >>
> >> On Sep 1, 2016, at 1:05 PM, Reid Kleckner <rnk at google.com
<mailto:rnk at google.com>> wrote:
> >>
> >>
> >>
> >> On Thu, Sep 1, 2016 at 12:53 PM, Mehdi Amini via cfe-dev
> >> <cfe-dev at lists.llvm.org <mailto:cfe-dev at
lists.llvm.org>> wrote:
> >>
> >> Isn’t a big (the most) reason for supporting “old” toolchains to
allow
> >> downstream users to upgrade with some flexibility?
> >>
> >> If I have a large codebase that is using LLVM (let say a few
custom
> >> backends), and is validated with “MSVC 2013”, I can upgrade to
“2015” but I
> >> will need some qualification/validation: this is not free and take
some
> >> time. If you drop aggressively supports for “old” toolchain it
means that
> >> I’m either stuck with an “old” LLVM or that I have to update
earlier than
> >> expected.
> >>
> >>
> >>
> >> Isn’t this usually balanced in upstream LLVM to upgrade when there
is a
> >> real *benefit* to it?
> >>
> >> I’m mentioning it because it seems to conflict with the
"always upgrade to
> >> the newest one unless there are serious issues with it” you
mentioned above.
> >>
> >>
> >>
> >> I agree, we should raise the minimum VS version requirement when
the
> >> benefits to the LLVM community outweigh the costs of switching for
major
> >> LLVM contributors and users. I think we'll always make that
decision in the
> >> same way: by raising it on the mailing lists and discussing the
pros and
> >> cons. That's basically what David said when he kicked this
whole discussion
> >> off, anyway:
> >>
> >>
> >>
> >> """But if we find ourselves in a situation where
asking folks to upgrade
> >> to a compiler which has been widely deployed soothes development
for the
> >> greater LLVM community, we should consider dropping support for
the older
> >> versions of that compiler."""
> >>
> >>
> >>
> >> I think everything is working as intended here.
> >>
> >>
> >>
> >> Right, to be clear there is no misunderstanding: I was absolutely
not
> >> suggesting the opposite when answering Zach..
> >>
> >>
> >>
> >> —
> >>
> >> Mehdi
> >>
> >>
> >>
> >>
> >>
> >> We raised the VS 2013 upgrade issue, discussed it, determined that
it was
> >> holding us back, and now we're doing the upgrade. If VS
"15" brings major
> >> language compatibility improvements, I imagine we'll be having
this same
> >> discussion again next year. If it doesn't, and supporting 2015
and "15" at
> >> the same time has the same cost, then we won't bother raising
the floor for
> >> a while.
> >>
> >>
> >>
> >> _______________________________________________
> >> cfe-dev mailing list
> >> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> >>
> >> _______________________________________________
> >> cfe-dev mailing list
> >> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> >>
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >>
> >> LLVM Developers mailing list
> >>
> >> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
> >>
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> >>
> >>
> >>
> >> --
> >>
> >> Employee of Qualcomm Innovation Center, Inc.
> >>
> >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux
> >> Foundation Collaborative Project
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> >>
> >>
> >>
> >> --
> >>
> >> Employee of Qualcomm Innovation Center, Inc.
> >>
> >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux
> >> Foundation Collaborative Project
> >>
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> >>
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> >
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161007/49b93e89/attachment.html>

Hi Mehdi,

Yes, all on track and thank you all for your kind patience!

Cheers,

James
On Fri, 7 Oct 2016 at 20:13, Mehdi Amini <mehdi.amini at apple.com> wrote:
> Hi James,
>
> Are you still on track for pulling the plug on MSVC 2013 at the end next
> week?
>
> As another data point, other than new features or build failures, I just
> had to debug (with the help of Intel folks) a runtime failure because of a
> bug with zero-initialization in MSVC 2013 (see
> https://connect.microsoft.com/VisualStudio/feedback/details/802160 ).
>
> —
> Mehdi
>
>
> On Sep 8, 2016, at 8:38 AM, James Molloy via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Thank you both, we appreciate it a lot!
> On Thu, 8 Sep 2016 at 16:37, Aaron Ballman via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> On Thu, Sep 8, 2016 at 11:24 AM, Reid Kleckner via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > I can't say I'm excited to support MSVC 2013 for another
month, but I'm
> more
> > concerned about the burden on other developers. People I talked to at
> the SF
> > bay area social last Thursday were really excited to drop 2013
support. I
> > guess I'll leave my buildbots on another month and see how it
goes.
>
> I'm happy to help carry the burden as well, so if you run into
> anything you'd like to punt over to me, please let me know. I'm
happy
> to handle it in addition to the things I usually pick up on.
>
> ~Aaron
>
> >
> > On Thu, Sep 8, 2016 at 7:03 AM, Robinson, Paul via llvm-dev
> > <llvm-dev at lists.llvm.org> wrote:
> >>
> >> As this is an ABI-incompatible upgrade, and it's changing the
informal
> >> policy on upgrades, could we please have some more grace time?
Ideally
> >> another month, so the 15th October. If we haven't sorted it by
then,
> it's
> >> our problem.
> >>
> >>
> >>
> >> I had originally proposed 15 September mostly because nobody had
> proposed
> >> a specific date, and it has been kind of dragging on for a while. 
The
> >> primary cost of deferring to 15 October seems to be that the
community
> (Hi
> >> Reid!) will have to keep fixing VS2013 related problems for
another
> month,
> >> which isn't ideal but hopefully we can tolerate it.
> >>
> >> (In fact at Sony we're only throwing the internal switch
today, and
> we'll
> >> have to see what happens.)
> >>
> >> --paulr
> >>
> >>
> >>
> >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On
Behalf Of
> >> Craig, Ben via llvm-dev
> >> Sent: Wednesday, September 07, 2016 2:42 PM
> >> To: Zachary Turner; James Molloy; llvm-dev at lists.llvm.org
> >> Subject: Re: [llvm-dev] [cfe-dev] Revisiting our informal policy
to
> >> support two versions of MSVC
> >>
> >>
> >>
> >> I'll need to dig up the references for that... but I'm
pretty sure the
> >> universal CRT that debuted in MSVC 2015 only covers the C parts,
and
> not the
> >> C++ parts.
> >>
> >>
> >>
> >> On 9/7/2016 4:28 PM, Zachary Turner wrote:
> >>
> >> It's worth pointing out that from 2015 and on, they claim to
support
> full
> >> forwards compatibility of the standard libraries, so this should
(in
> theory)
> >> never be an issue again.
> >>
> >>
> >>
> >> On Wed, Sep 7, 2016 at 1:12 PM James Molloy via llvm-dev
> >> <llvm-dev at lists.llvm.org> wrote:
> >>
> >> Hi,
> >>
> >> As I understand it the specific issue we're seeing is related
to what
> >> Martin described. But due to numerous bugs found when mixing
objects
> >> compiled with different versions of MSVC in the past, we now are
shy of
> >> doing it even if it seems to work superficially - that's no
guarantee
> bugs
> >> won't be found down the line. We'd much prefer to stay
within the
> realms of
> >> what Microsoft support.
> >>
> >> Cheers,
> >>
> >> James
> >>
> >> On Wed, 7 Sep 2016 at 20:53, Craig, Ben via llvm-dev
> >> <llvm-dev at lists.llvm.org> wrote:
> >>
> >> Note that this is intentional from the MSVC C++ library
implementation
> >> side of things.  For major versions, no attempt is made to
preserve
> library
> >> ABI compatibility.
> >>
> >> I am aware of a language ABI break in VC++ 2013.
> >>
>
https://randomascii.wordpress.com/2013/12/01/vc-2013-class-layout-change-and-wasted-space/
> >>
> >> I'm not currently aware of any on the VC++ 2015 side of
things, but that
> >> doesn't mean much.
> >>
> >>
> >>
> >> On 9/7/2016 2:34 PM, Martin O'Riordan via llvm-dev wrote:
> >>
> >> Apart from the obvious licencing issues, each time I have moved
from one
> >> version of VC++ to another, the big problem I have had is not
> specifically
> >> the ABI at the register passing, stack organisation level, but
rather
> the
> >> implementation details of the Standard C++ libraries, and in
particular
> the
> >> STL containers.
> >>
> >> While the compiler team puts considerable effort into maintaining
the
> ABI,
> >> the C++ library implementation usually changes a lot.
> >>
> >> Since this is largely in the form of very complex headers defining
> >> templates which in turn cause other helper templates to be used,
it is
> here
> >> that I find things go awry.
> >>
> >> So for C++, a function like:
> >>
> >> std::list<int> foo();
> >>
> >>
> >>
> >> seems simple enough, but if the caller and the callee are compiled
with
> >> different versions, it usually won't work because of some
artefact of
> the
> >> STL implementation tuning that occurs between versions.  In
particular,
> this
> >> impacts things like using C++ interfaces across DLLs and in
pre-compiled
> >> libraries.
> >>
> >> I think that the ABI maintenance in this case tends to be for C
and POD
> >> compatability, but not for the higher level C++ compatability
which is
> >> unfortunate and restricts how we can use C++.
> >>
> >> Is it possible that it is this aspect of the version change that
is
> >> causing your ABI difficulties?
> >>
> >> MartinO
> >>
> >>
> >>
> >>
> >>
> >> On 7 September 2016 at 20:18, Zachary Turner via llvm-dev
> >> <llvm-dev at lists.llvm.org> wrote:
> >>
> >> Can you elaborate on the abi incompatibility? I thought there were
no
> >> breaks
> >>
> >> On Wed, Sep 7, 2016 at 7:59 AM James Molloy via cfe-dev
> >> <cfe-dev at lists.llvm.org> wrote:
> >>
> >> Hi all,
> >>
> >>
> >>
> >> Firstly sorry I'm a bit late responding on this one.
Internally to ARM
> we
> >> build LLVM for Windows. Our current build cluster has only VS2013
> installed
> >> and as a result of this thread we've been working on getting
VS2015
> >> installed. This involves a certain amount of IT-wrangling as the
> cluster we
> >> use is company-wide. There have been some hiccups regarding
licensing of
> >> MSVC professional (we can't use the community edition for the
same
> reasons
> >> mentioned by Paul previously) but we hoped to be ready in time for
the
> 15th
> >> September switchover date.
> >>
> >>
> >>
> >> It's recently been realised that VS2013 and VS2015 are not ABI
> compatible
> >> (something that really surprised me), and this means we have to
> synchronize
> >> moving LLVM's build to VS2015 as well as upgrading a third
party library
> >> that we receive from the vendor in compiled library form. This is
not
> >> something we're capable of doing by September 15th.
> >>
> >>
> >>
> >> We try really hard at ARM to hide our internal processes because
we
> >> believe that they're on the whole irrelevant to the community,
however
> in
> >> this case we'd be really stuck, unable to get production
builds.
> >>
> >>
> >>
> >> As this is an ABI-incompatible upgrade, and it's changing the
informal
> >> policy on upgrades, could we please have some more grace time?
Ideally
> >> another month, so the 15th October. If we haven't sorted it by
then,
> it's
> >> our problem.
> >>
> >>
> >>
> >> Cheers,
> >>
> >>
> >>
> >> James
> >>
> >>
> >>
> >> On Thu, 1 Sep 2016 at 21:06 Mehdi Amini via cfe-dev
> >> <cfe-dev at lists.llvm.org> wrote:
> >>
> >> On Sep 1, 2016, at 1:05 PM, Reid Kleckner <rnk at
google.com> wrote:
> >>
> >>
> >>
> >> On Thu, Sep 1, 2016 at 12:53 PM, Mehdi Amini via cfe-dev
> >> <cfe-dev at lists.llvm.org> wrote:
> >>
> >> Isn’t a big (the most) reason for supporting “old” toolchains to
allow
> >> downstream users to upgrade with some flexibility?
> >>
> >> If I have a large codebase that is using LLVM (let say a few
custom
> >> backends), and is validated with “MSVC 2013”, I can upgrade to
“2015”
> but I
> >> will need some qualification/validation: this is not free and take
some
> >> time. If you drop aggressively supports for “old” toolchain it
means
> that
> >> I’m either stuck with an “old” LLVM or that I have to update
earlier
> than
> >> expected.
> >>
> >>
> >>
> >> Isn’t this usually balanced in upstream LLVM to upgrade when there
is a
> >> real *benefit* to it?
> >>
> >> I’m mentioning it because it seems to conflict with the
"always upgrade
> to
> >> the newest one unless there are serious issues with it” you
mentioned
> above.
> >>
> >>
> >>
> >> I agree, we should raise the minimum VS version requirement when
the
> >> benefits to the LLVM community outweigh the costs of switching for
major
> >> LLVM contributors and users. I think we'll always make that
decision in
> the
> >> same way: by raising it on the mailing lists and discussing the
pros and
> >> cons. That's basically what David said when he kicked this
whole
> discussion
> >> off, anyway:
> >>
> >>
> >>
> >> """But if we find ourselves in a situation where
asking folks to upgrade
> >> to a compiler which has been widely deployed soothes development
for the
> >> greater LLVM community, we should consider dropping support for
the
> older
> >> versions of that compiler."""
> >>
> >>
> >>
> >> I think everything is working as intended here.
> >>
> >>
> >>
> >> Right, to be clear there is no misunderstanding: I was absolutely
not
> >> suggesting the opposite when answering Zach..
> >>
> >>
> >>
> >> —
> >>
> >> Mehdi
> >>
> >>
> >>
> >>
> >>
> >> We raised the VS 2013 upgrade issue, discussed it, determined that
it
> was
> >> holding us back, and now we're doing the upgrade. If VS
"15" brings
> major
> >> language compatibility improvements, I imagine we'll be having
this same
> >> discussion again next year. If it doesn't, and supporting 2015
and "15"
> at
> >> the same time has the same cost, then we won't bother raising
the floor
> for
> >> a while.
> >>
> >>
> >>
> >> _______________________________________________
> >> cfe-dev mailing list
> >> cfe-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >>
> >> _______________________________________________
> >> cfe-dev mailing list
> >> cfe-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >>
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >>
> >> LLVM Developers mailing list
> >>
> >> llvm-dev at lists.llvm.org
> >>
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> >>
> >>
> >> --
> >>
> >> Employee of Qualcomm Innovation Center, Inc.
> >>
> >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a
> Linux
> >> Foundation Collaborative Project
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> >>
> >>
> >> --
> >>
> >> Employee of Qualcomm Innovation Center, Inc.
> >>
> >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a
> Linux
> >> Foundation Collaborative Project
> >>
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161007/553fb829/attachment.html>