llvm dev - Aug 2016 - [cfe-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."

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160802/4db59f74/attachment.html>

Totally agree

2016-08-02 10:24 GMT-07:00 David Majnemer via llvm-dev <
llvm-dev at lists.llvm.org>:
> 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
>
> _______________________________________________
> 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/f2499df9/attachment-0001.html>

On Tue, Aug 2, 2016 at 1:24 PM, 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."
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
>
> Thanks,
> David
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

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

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

— 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160802/21953b03/attachment.html>

On Aug 2, 2016, at 12:24 PM, David Majnemer via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 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?
Dropping it would not be a problem for us.


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



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

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>

-----Original Message-----
> From: cfe-dev [mailto:cfe-dev-bounces at 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
> 
> On Tue, Aug 2, 2016 at 1:24 PM, 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."
> 
> 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. :-)
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
> 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
> 
> >
> > Thanks,
> > David
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

Hi,

I’ve noted some change in wording on the current (4.0) developer policy[1],
compared to the 3.9 developer policy[2]. Specifically the part about IR
Backwards Compatibility.

The change from 3.9 to 4.0 is the following:

  - The textual format is not backwards compatible. We don’t change it too
often, but there are no specific promises.
  - Additions and changes to the IR should be reflected in
test/Bitcode/compatibility.ll.
- - The bitcode format produced by a X.Y release will be readable by all
following X.Z releases and the (X+1).0 release.
+ - The current LLVM version supports loading any bitcode since version 3.0.
  - After each X.Y release, compatibility.ll must be copied to
compatibility-X.Y.ll. The corresponding bitcode file should be assembled using
the X.Y build and committed as compatibility-X.Y.ll.bc.
  - Newer releases can ignore features from older releases, but they cannot
miscompile them. For example, if nsw is ever replaced with something else,
dropping it would be a valid way to upgrade the IR.
  - Debug metadata is special in that it is currently dropped during upgrades.
  - Non-debug metadata is defined to be safe to drop, so a valid way to upgrade
it is to drop it. That is not very user friendly and a bit more effort is
expected, but no promises are made.

This raises the following question for me: does this imply that bitcode
generated by 4.X won’t necessarily be as
stable as it was for the 3.X series, specifically that the backwards
compatability guarantee will be scraped in
LLVM 4.0+?

Cheers,
 Moritz

--
[1]: http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility
[2]:
http://llvm.org/releases/3.9.0/docs/DeveloperPolicy.html#ir-backwards-compatibility