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

Craig, Ben via llvm-dev llvm-dev at lists.llvm.org
Wed Sep 7 12:52:36 PDT 2016

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. 

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
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160907/66fb5f44/attachment.html>

More information about the llvm-dev mailing list