Revisiting our informal policy to support two versions of MSVC

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?

Thanks,
David

Totally agree

Hello,

Today we hit another VS 2013 breakage
<http://lab.llvm.org:8011/builders/sanitizer-windows/builds/26666/steps/run%20tests/logs/stdio&gt;
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."

I think that's reasonable, but I also think this is no different than
what we already do today, which is unfortunate. The lack of
predictability of when we drop support for MSVC is something I would
hope we can address. That's what the "last two versions" was hoping to
achieve, but hasn't in practice since we've never actually adhered to
that policy due to finding pain points to justify dropping early.
Since this proposal is basically preserving the status quo, I don't
think predictability needs to be solved in order to move forward with
the proposal of dropping support for 2013.

To me, the goal of having some degree of predictability with compiler
versions is for people with out-of-tree projects to have a chance of
knowing when support for a compiler may be dropped and plan
accordingly. This isn't traditionally a problem with GCC (e.g.)
because the stability of features and functionality is usually a bit
higher than with MSVC, where major upgrades can be challenging and
labor-intensive for some projects. Maybe we can bring back the notion
of "last two versions" sometime in the future if MSVC functionality
stabilizes a bit more.

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.

Totally agreed.

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?

Assuming that we don't have any major barriers to dropping MSVC 2013,
I am okay with it. Additional request: can we also informally require
the latest Update to be installed for whatever versions of MSVC we
support (if we don't already)? I don't see a whole lot of value to
keeping support for Update 1 & 2 when Update 3 is out.

~Aaron

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?

(I don’t know about how widely VS2013 is still used in the community to evaluate the other side of the balance).

Dropping it would not be a problem for us.

Jim Rowan
jmr@codeaurora.org
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation

Hello,

Today we hit another VS 2013 breakage <
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/26666/steps/run%20tests/logs/stdio&gt;
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?

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&gt;&quot;\. 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&gt;&quot; 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.

From: cfe-dev [mailto:cfe-dev-bounces@lists.llvm.org] On Behalf Of Aaron
Ballman via cfe-dev
Sent: Tuesday, August 02, 2016 12:06 PM
To: David Majnemer
Cc: llvm-dev; cfe-dev
Subject: Re: [cfe-dev] [llvm-dev] Revisiting our informal policy to
support two versions of MSVC

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

I think that's reasonable, but I also think this is no different than
what we already do today, which is unfortunate. The lack of
predictability of when we drop support for MSVC is something I would
hope we can address. That's what the "last two versions" was hoping to
achieve, but hasn't in practice since we've never actually adhered to
that policy due to finding pain points to justify dropping early.
Since this proposal is basically preserving the status quo, I don't
think predictability needs to be solved in order to move forward with
the proposal of dropping support for 2013.

To me, the goal of having some degree of predictability with compiler
versions is for people with out-of-tree projects to have a chance of
knowing when support for a compiler may be dropped and plan
accordingly. This isn't traditionally a problem with GCC (e.g.)
because the stability of features and functionality is usually a bit
higher than with MSVC, where major upgrades can be challenging and
labor-intensive for some projects.

For my project, timing is everything. We (and I could easily imagine,
for many downstream projects) lead time is important. We've just had
a release branch, so making a *decision* right now that we *implement*
in 2-3 months is something we should find tolerable. (We'd need to do
a bunch of internal validation, then deploy 2015 to all the developers
and all the bots... these things take time.) I have already brought
this up with my management and we'll need to assign some resources to
it in order to start that evaluation.

Maybe we can bring back the notion
of "last two versions" sometime in the future if MSVC functionality
stabilizes a bit more.

You'd have to get the C++ committee to stabilize the language first. :slight_smile:
Seriously, MSVC 2013 would be distinctly less of a problem if people
weren't trying to use defaulted move constructors. I think that's a
fine feature to want to be using, but it wasn't on the list back when
we decided to make 2013 the minimum version. The developer community's
desired feature set has increased, so it's reasonable to debate moving
the minimum bar on that basis.

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

Totally agreed.

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

Assuming that we don't have any major barriers to dropping MSVC 2013,
I am okay with it.

Same here. We will need to do our internal validation first, and
I'd bet we aren't the only ones.
--paulr

In Chromium land, we've so far been able to use the same compiler we use to
build Chrome to build clang. Currently that's MSVS2015 update 2, and it
took quite a while to update from 2013 to 2015 due bugs in 2015 and
whatnot. So I agree that it's useful to support older MSVS versions for
some time. For this reason, requiring update 3 would be inconvenient for
us, but 2015u2 would be no problem by now. It would've been a problem if
2015 had been required shortly after it was released.

Nico

Hi,

This sounds like a decent idea to me. However we use 2013 for all our windows builds at the moment and it will take around 2 weeks to upgrade the installations on our cluster. We’re pushing this hard to get it done soon so we don’t get caught short, but a grace period would be much appreciated.

Cheers,

James

I’ve heard from another group within Sony that they had “a number of problems” with VS2015 update 2, and strongly recommend going straight to update 3. My immediate team has initiated a request but it hasn’t gone through yet.

–paulr

I’d like to revisit this. As a person who spends a fair amount of time monitoring our VS 2013 buildbots, I would say that I am ready to throw in the towel on MSVC 2013. Since this discussion, I have committed five (!) workarounds for MSVC 2013:

in llvm

$ git log --author=rnk --grep=2013 --after=‘Aug 4 2016’ --oneline

21a8ade Fix the MSVC 2013 build by using Elf_Word instead of making a local typedef
27e101d Revert “Add an optional parameter with a list of undefs to extendToIndices”
e8beddd Make vec_fabs.ll pass with MSVC 2013
ca77873 [AMDGPU] Give enum an explicit 64-bit type to fix MSVC 2013 failures

in clang

$ git log --author=rnk --grep=2013 --after=‘Aug 4 2016’ --oneline
18235a5 Try to work around an MSVC 2013 bug around defaulted default ctors

I’m pretty sure I’m missing instances where I helped others commit workarounds as well. So, I’d really like to drop 2013, probably sometime next month.

That said, I’d also like to echo Paul’s sentiment that it’d help if people were less adventurous in their uses of C++11. New language features may look nice, but ultimately you may end up wasting my time and yours when I come and revert your change.

Hi Reid, first off thanks very much for all your help fixing 2013-related problems. We really appreciate it.

Let me propose a target date of September 15 for advancing the minimum MS compiler to VS2015 Update 3. Certainly my team should be ready by then. If anybody else needs a later date, in particular people who own Windows bots still using VS2013, please speak up.

–paulr

I'd like to revisit this. As a person who spends a fair amount of time
monitoring our VS 2013 buildbots, I would say that I am ready to throw in
the towel on MSVC 2013. Since this discussion, I have committed five (!)
workarounds for MSVC 2013:

# in llvm
$ git log --author=rnk --grep=2013 --after='Aug 4 2016' --oneline
21a8ade Fix the MSVC 2013 build by using Elf_Word instead of making a local
typedef
27e101d Revert "Add an optional parameter with a list of undefs to
extendToIndices"
e8beddd Make vec_fabs.ll pass with MSVC 2013
ca77873 [AMDGPU] Give enum an explicit 64-bit type to fix MSVC 2013 failures

# in clang
$ git log --author=rnk --grep=2013 --after='Aug 4 2016' --oneline
18235a5 Try to work around an MSVC 2013 bug around defaulted default ctors

I'm pretty sure I'm missing instances where I helped others commit
workarounds as well. So, I'd really like to drop 2013, probably sometime
next month.

I agree, I think it's time. I think a month is reasonable, assuming
that it doesn't cause massive problems for anyone (which it doesn't
sound like it will).

That said, I'd also like to echo Paul's sentiment that it'd help if people
were less adventurous in their uses of C++11. New language features may look
nice, but ultimately you may end up wasting my time and yours when I come
and revert your change.

I also agree with this.

~Aaron

As mentioned upthread, we’re still on update 2 for various reasons.

As mentioned upthread, we're still on update 2 for various reasons.

Do you mind elaborating on those reasons? I think we should require
the latest updates to MSVC due to the number of issues the updates fix
(esp regarding the newer language features that people keep using so
frequently), but I've also not heard a concrete use case as to why we
shouldn't.

~Aaron

> As mentioned upthread, we're still on update 2 for various reasons.

Do you mind elaborating on those reasons?

Off the top of my head, clang-cl couldn't handle the code generated by the
midl compiler in that version until fairly recently, and we've been seeing
link.exe /INCREMENTAL failing intermittently (no reliable repro case
though).

I think we should require
the latest updates to MSVC due to the number of issues the updates fix
(esp regarding the newer language features that people keep using so
frequently), but I've also not heard a concrete use case as to why we
shouldn't.

Do you mean "require latest updates" in general, or just in this case?
Updating immediately every time a new MSVS release comes out would
definitely be tricky for us.

> As mentioned upthread, we're still on update 2 for various reasons.

Do you mind elaborating on those reasons?

Off the top of my head, clang-cl couldn't handle the code generated by the
midl compiler in that version until fairly recently, and we've been seeing
link.exe /INCREMENTAL failing intermittently (no reliable repro case
though).

Thank you for the extra information.

I think we should require
the latest updates to MSVC due to the number of issues the updates fix
(esp regarding the newer language features that people keep using so
frequently), but I've also not heard a concrete use case as to why we
shouldn't.

Do you mean "require latest updates" in general, or just in this case?
Updating immediately every time a new MSVS release comes out would
definitely be tricky for us.

I mean in general, but "immediate" wasn't what I had in mind. More
like "within some reasonable time frame", for whatever definition of
reasonable works for people. Given how often Microsoft fixes critical
language bugs with newer features during an Update release, I'm hoping
we can avoid sticking to older Updates if we are able to do so.

~Aaron

I frequently see mention of how upgrading is problematic, is there anyone here for whom upgrading msvc versions is problematic? It seems like we keep talking in hypotheticals, but I’d like to hear from someone for whom it is actually a problem, and why.

Vs community is permissive enough now that licensing isn’t an issue. And every time this comes up it seems like we’re saying “well it could be hard for people…” but nobody ever says it actually is hard for them specifically

I frequently see mention of how upgrading is problematic, is there anyone
here for whom upgrading msvc versions is problematic? It seems like we keep
talking in hypotheticals, but I'd like to hear from someone for whom it is
*actually* a problem, and why.

Vs community is permissive enough now that licensing isn't an issue. And
every time this comes up it seems like we're saying "well it could be hard
for people..." but nobody ever says it actually is hard for them
specifically

I just said that in the mail you're replying to (?) Having to update our
~20 Windows bots so that they use a different MSVC than what's on there
already for Chromium is going to be actually hard for us.

I don’t see how the policy of supporting 2 versions is related to that difficulty though. Whether we support 1 versions or 2 versions, 1 version is still going to be deprecated every time a new version is released. So this burden on upgrading buildbots doesn’t seem to be much different.

As long as chromium compiler version is not tied to llvm compiler version (and if it did, that would be a chromium decision not an llvm one) this is always going to be a problem whether llvm supports newest compiler or newest 2 compilers