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

Piotr Padlewski via llvm-dev llvm-dev at lists.llvm.org
Tue Aug 2 12:45:19 PDT 2016


2016-08-02 12:24 GMT-07:00 Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org
>:

>
> On Aug 2, 2016, at 10:24 AM, David Majnemer via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hello,
>
> Today we hit another VS 2013 breakage <
> http://lab.llvm.org:8011/builders/sanitizer-windows/builds/26666/steps/run%20tests/logs/stdio>
> which results us having to alter LLVM.
>
> While we have no documented policy of supporting two version of MSVC, we
> do have an informal agreement that we should support the last two versions.
>
> I suggest that we alter our informal policy to the following:
>
> "If a compiler version keeps getting in the way and a newer compiler is
> available, we should ask people to upgrade to that newer compiler."
>
> If we can support ten versions of MSVC with little burden, I don't see a
> reason why we shouldn't.
>
> 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.
>
> In this case, dropping VS2013 allows us to use more C++11 features with
> confidence.  Notably, move constructors will be synthesized instead of
> having to be manually written (and kept in sync with data members getting
> added).
>
> What do you all think?  Are folks still stuck on VS2013?
>
>
> I think in the end it comes down to a tradeoff between the added value of
> what features we gain by dropping an old compiler (MSVC, GCC, Clang…)
> compared to its user-based.
>
> For example I believe last time we dropped an MSVC release we had a fairly
> large list of features:
> http://lists.llvm.org/pipermail/llvm-dev/2014-August/075869.html
>
> What is the list of features for dropping VS2013?
>
>
https://msdn.microsoft.com/en-us/library/hh567368.aspx

I think the one that all people care about is default move constructors and
move assignment operators.
The path that David mentioned hits "Unrestricted unions
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2544.pdf>". The
other thing that would be nice to use in LLVM is noexcept (mostly in user
defined move ctors).
Other thing that I even hit (but then removed it) is "Magic statics
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2660.htm>" for
multithreaded code. This seems much more tricky, because the code will
compile, but you won't know that on clang compiled with MSVC would have
some data races.





> (I don’t know about how widely VS2013 is still used in the community to
> evaluate the other side of the balance).
>
>> Mehdi
>
>
> _______________________________________________
> 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/20160802/2cf8b249/attachment.html>


More information about the llvm-dev mailing list