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

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>

I migrated the sanitizer-windows builder to VS 2015, and it went green here:
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/30342

That leaves two remaining builders using VS 2013:
http://lab.llvm.org:8011/builders/clang-x86-win2008-selfhost/
http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/

I'm going to be on vacation Fri-Tues this weekend, so I won't be around
on
Oct 15 to decomission any remaining VS 2013 bots.

I know someone at Intel is installing VS 2015 on clang-x64-ninja-win7, so I
assume that's going to switch soon.

The clang-x86-win2008-selfhost builder is completely redundant
with clang-x86-windows-msvc2015. If someone can take responsibility for
deleting the builder and slave from the buildbot config and pinging Galina
for the master restart on Monday, that would be great. I can delete the VM
when I get back.

On Fri, Oct 7, 2016 at 12:14 PM, James Molloy <james at jamesmolloy.co.uk>
wrote:
> 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/20161012/25c207ca/attachment.html>

Hi,

If there is no blocker (James?), we should be able to move on, so I filed as a
starter: https://reviews.llvm.org/D25710
<https://reviews.llvm.org/D25710>: [Doc] Drop MSVC2013 support

— 
Mehdi


> On Oct 12, 2016, at 4:03 PM, Reid Kleckner <rnk at google.com> wrote:
> 
> I migrated the sanitizer-windows builder to VS 2015, and it went green
here:
> http://lab.llvm.org:8011/builders/sanitizer-windows/builds/30342
<http://lab.llvm.org:8011/builders/sanitizer-windows/builds/30342>
> 
> That leaves two remaining builders using VS 2013:
> http://lab.llvm.org:8011/builders/clang-x86-win2008-selfhost/
<http://lab.llvm.org:8011/builders/clang-x86-win2008-selfhost/>
> http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/
<http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/>
> 
> I'm going to be on vacation Fri-Tues this weekend, so I won't be
around on Oct 15 to decomission any remaining VS 2013 bots.
> 
> I know someone at Intel is installing VS 2015 on clang-x64-ninja-win7, so I
assume that's going to switch soon.
> 
> The clang-x86-win2008-selfhost builder is completely redundant with
clang-x86-windows-msvc2015. If someone can take responsibility for deleting the
builder and slave from the buildbot config and pinging Galina for the master
restart on Monday, that would be great. I can delete the VM when I get back.
> 
> On Fri, Oct 7, 2016 at 12:14 PM, James Molloy <james at
jamesmolloy.co.uk <mailto:james at jamesmolloy.co.uk>> wrote:
> 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
<mailto: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
<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 <mailto: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 <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>
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161017/18b03f7e/attachment.html>