[llvm-dev] Upgrading to MSVC 2015

Sat Jul 30 19:10:29 PDT 2016

There is also a chance that someone gonna extend clang-tidy check
"modernize-use-default" to handle move constructors.
Then at least this problem, which I think is the most frequent, could be
solved easily after moving to MSVC2015

2016-07-30 17:53 GMT-07:00 Robinson, Paul <paul.robinson at sony.com>:

> > -----Original Message-----
> > From: aaron.ballman at gmail.com [mailto:aaron.ballman at gmail.com] On Behalf
> > Of Aaron Ballman
> > Sent: Saturday, July 30, 2016 12:41 PM
> > To: Robinson, Paul
> > Cc: Zachary Turner; Sean Silva; Piotr Padlewski; llvm-dev at lists.llvm.org
> > Subject: Re: [llvm-dev] Upgrading to MSVC 2015
> >
> > On Sat, Jul 30, 2016 at 1:58 PM, Robinson, Paul <paul.robinson at sony.com>
> > wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: aaron.ballman at gmail.com [mailto:aaron.ballman at gmail.com] On
> > Behalf
> > >> Of Aaron Ballman
> > >> Sent: Friday, July 29, 2016 2:19 PM
> > >> To: Zachary Turner
> > >> Cc: Sean Silva; Robinson, Paul; Piotr Padlewski; llvm-
> > dev at lists.llvm.org
> > >> Subject: Re: [llvm-dev] Upgrading to MSVC 2015
> > >>
> > >> There are not that many people making commits to working around MSVC
> > >> 2013 as I think are claimed
> > >
> > > CGOpenMPRuntime.cpp had 4 patches this week trying to make VS2013
> happy.
> > > I can tell they were because of VS2013 because the public PS4 bot has
> > > VS2015 and it didn't seem to have the same problems.
> >
> > Hmmm, I don't see any mention in the code itself about changes to
> > appease MSVC 2013, so that's why it didn't come up in my searches. We
> > usually ask people working around buggy compilers to leave a FIXME in
> > there so we can remove compiler hacks (but obviously, we don't manage
> > to catch all of them), so if you run into anything like this again,
> > please try to put in a FIXME if it's appropriate.
>
> Ah, okay, was not aware of that policy.  I'll try to keep that in mind
> if it comes up again.  It looks like other people with a more vested
> interest in that module have also been working on it, so I'm not sure
> exactly what its current state is; if my hacks are still there Monday
> then I'll look at adding FIXME comments.
> Thanks,
> --paulr
>
> >
> > > Maybe it was just bad luck that we put up an internal VS2013 bot when
> it
> > > happened, but it has been an incredible time-sink for me this week.
> >
> > I'm sorry it's been a time sink for you!
> >
> > > Note I do not want to advance the timetable, I just want to make sure
> > > that the actual problems aren't dismissed too readily.
> >
> > Agreed -- if we have compiler problems that are causing a lot of pain,
> > I think it's a good idea to discuss bumping the time table. However,
> > we have problems with *every* compiler from time to time. For
> > comparison, when we dropped MSVC 2012 early we had frequent
> > (weekly-ish?) issues that we would run up against that 2013 had
> > already fixed, the workarounds were cumbersome, and 2013 had a looming
> > release date. We do run into issues with 2013 (I helped someone work
> > around one yesterday, in fact), so it's good for us to keep track of
> > those situations to help make informed decisions, but whether we're at
> > the point of deviating from our compiler support policy or not is less
> > clear to me.
> >
> > ~Aaron
> >
> > > --paulr
> > >
> > >> (there are certainly a lot of commits for
> > >> working around MSVC in general, however). A quick search through the
> > >> code base shows there are 8 instances where we've worked around MSVC
> > >> 2013 issues (there may be more that someone worked around in an ad hoc
> > >> manner and did not mark). We definitely had *a lot* more when we
> > >> dropped MSVC 2012 early. The primary issues people are working around
> > >> are constexpr support, which is important but certainly not critical,
> > >> and still some occasional issues with move constructors not being
> > >> synthesized as expected, which is also pretty simple to work around
> > >> (and is usually an optimization loss more than a functionality loss).
> > >>
> > >> As MSVC 15 starts getting closer to the RTM stages, I think we should
> > >> definitely consider the switch more strongly, but with it still in
> > >> Preview mode, I think it's premature to drop support for MSVC 2013 at
> > >> this time.
> > >>
> > >> ~Aaron
> > >>
> > >> On Fri, Jul 29, 2016 at 5:02 PM, Zachary Turner <zturner at google.com>
> > >> wrote:
> > >> > FWIW, no objections from me, after all I proposed this 3 months ago
> > :)
> > >> >
> > >> > Probably Aaron Ballman should comment though since the primary
> > objection
> > >> > last time was his.
> > >> >
> > >> > On Fri, Jul 29, 2016 at 2:00 PM Sean Silva <chisophugis at gmail.com>
> > >> wrote:
> > >> >>
> > >> >> On Fri, Jul 29, 2016 at 1:23 PM, Robinson, Paul via llvm-dev
> > >> >> <llvm-dev at lists.llvm.org> wrote:
> > >> >>>
> > >> >>> There are certainly enough people making commits that work with
> > VS2015
> > >> >>> but not VS2013 that the "would it be useful" question is pretty
> > well
> > >> >>> answered.  I've already brought up the idea on my team, as it's
> > >> obviously
> > >> >>> coming and we need time to coordinate with internal consumers of
> > the
> > >> >>> toolchain.
> > >> >>
> > >> >>
> > >> >> Also, we have an increasing number of parts of the codebase that
> are
> > >> >> working around VS2013's inability to generate move constructors.
> > >> >> This is all over the new PM code and the passes ported to the new
> > PM.
> > >> >> It has caused me personally hours of lost time and generally
> > penalizes
> > >> >> good coding practices (exporting lifetime management to RAII is
> only
> > so
> > >> >> convenient if you can't have a move-only type like a unique_ptr
> > without
> > >> >> manually writing out move constructor/assign; and the diagnostics
> > when
> > >> this
> > >> >> VS2013 deficiency raises its head are.... confusing).
> > >> >>
> > >> >> -- Sean Silva
> > >> >>
> > >> >>
> > >> >>>
> > >> >>> --paulr
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf
> > Of
> > >> >>> Zachary Turner via llvm-dev
> > >> >>> Sent: Friday, July 29, 2016 11:35 AM
> > >> >>> To: Piotr Padlewski; Aaron Ballman
> > >> >>> Cc: llvm-dev
> > >> >>> Subject: Re: [llvm-dev] Upgrading to MSVC 2015
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>> Probably not.  It's very confusing because they are transitioning
> > to a
> > >> >>> new versioning scheme.  The current version if Visual Studio 2015.
> > >> The next
> > >> >>> version is Visual Studio 15.  The link you posted was for the RTM
> > of
> > >> 2015,
> > >> >>> just over a year ago.  But 15 is still in Preview.  When 15 goes
> to
> > >> RTM,
> > >> >>> then we can revisit the question of making 2015 the minimum
> > required
> > >> >>> version.
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>> On Fri, Jul 29, 2016 at 11:29 AM Piotr Padlewski
> > >> >>> <piotr.padlewski at gmail.com> wrote:
> > >> >>>
> > >> >>> https://www.visualstudio.com/en-us/news/vs2015-vs.aspx
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>> Is it time?
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>> 2016-03-31 12:03 GMT-07:00 Aaron Ballman via llvm-dev
> > >> >>> <llvm-dev at lists.llvm.org>:
> > >> >>>
> > >> >>> On Thu, Mar 31, 2016 at 2:57 PM, Zachary Turner
> > <zturner at google.com>
> > >> >>> wrote:
> > >> >>> >
> > >> >>> >
> > >> >>> > On Tue, Mar 29, 2016 at 10:42 AM Aaron Ballman
> > >> <aaron at aaronballman.com>
> > >> >>> > wrote:
> > >> >>> >>
> > >> >>> >>
> > >> >>> >> Not everyone can upgrade to the latest version of the
> toolchain,
> > >> even
> > >> >>> >> if it has been released for a while. We did drop MSVC 2012
> > support
> > >> >>> >> early, but MSVC 2015 was in RC or RTM stages by that point, and
> > we
> > >> had
> > >> >>> >> some pretty big incentive to upgrade early (without function
> > >> templates
> > >> >>> >> supporting default arguments, the AST matcher DSL made for
> > really
> > >> slow
> > >> >>> >> compiles of Clang itself, and resulted in a larger executable
> > size
> > >> >>> >> among other things, IIRC).
> > >> >>> >
> > >> >>> >
> > >> >>> > I know you mentioned that one of the reasons we upgraded to 2013
> > was
> > >> >>> > because
> > >> >>> > 2015 was in RC or RTM.  Ironically, the day after I posted this
> > MS
> > >> >>> > announced
> > >> >>> > Visual Studio 15 preview  (which is confusingly the version
> > *after*
> > >> >>> > Visual
> > >> >>> > Studio 2015).
> > >> >>>
> > >> >>> Hah, that is confusing!
> > >> >>>
> > >> >>> > In any case, it's not an RC, and it's certainly not an RTM,
> > >> >>> > but it is on the horizon.  So hopefully we can revisit this
> > question
> > >> >>> > when 15
> > >> >>> > is in RC / RTM
> > >> >>>
> > >> >>> I think that's a great time to revisit the question (transitioning
> > >> >>> sometimes takes a bit of time since we want to ask people with out
> > of
> > >> >>> tree needs if they're ready before dropping support for major
> > >> >>> releases).
> > >> >>>
> > >> >>>
> > >> >>> ~Aaron
> > >> >>>
> > >> >>>
> > >> >>> _______________________________________________
> > >> >>> 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/20160730/280e6196/attachment.html>