James Molloy via llvm-dev
2016-Oct-07 19:14 UTC
[llvm-dev] [cfe-dev] Revisiting our informal policy to support two versions of MSVC
Hi Mehdi, Yes, all on track and thank you all for your kind patience! Cheers, James On Fri, 7 Oct 2016 at 20:13, Mehdi Amini <mehdi.amini at apple.com> wrote:> Hi James, > > Are you still on track for pulling the plug on MSVC 2013 at the end next > week? > > As another data point, other than new features or build failures, I just > had to debug (with the help of Intel folks) a runtime failure because of a > bug with zero-initialization in MSVC 2013 (see > https://connect.microsoft.com/VisualStudio/feedback/details/802160 ). > > — > Mehdi > > > On Sep 8, 2016, at 8:38 AM, James Molloy via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Thank you both, we appreciate it a lot! > On Thu, 8 Sep 2016 at 16:37, Aaron Ballman via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > On Thu, Sep 8, 2016 at 11:24 AM, Reid Kleckner via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I can't say I'm excited to support MSVC 2013 for another month, but I'm > more > > concerned about the burden on other developers. People I talked to at > the SF > > bay area social last Thursday were really excited to drop 2013 support. I > > guess I'll leave my buildbots on another month and see how it goes. > > I'm happy to help carry the burden as well, so if you run into > anything you'd like to punt over to me, please let me know. I'm happy > to handle it in addition to the things I usually pick up on. > > ~Aaron > > > > > On Thu, Sep 8, 2016 at 7:03 AM, Robinson, Paul via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > >> > >> 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. > >> > >> > >> > >> I had originally proposed 15 September mostly because nobody had > proposed > >> a specific date, and it has been kind of dragging on for a while. The > >> primary cost of deferring to 15 October seems to be that the community > (Hi > >> Reid!) will have to keep fixing VS2013 related problems for another > month, > >> which isn't ideal but hopefully we can tolerate it. > >> > >> (In fact at Sony we're only throwing the internal switch today, and > we'll > >> have to see what happens.) > >> > >> --paulr > >> > >> > >> > >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > >> Craig, Ben via llvm-dev > >> Sent: Wednesday, September 07, 2016 2:42 PM > >> To: Zachary Turner; James Molloy; llvm-dev at lists.llvm.org > >> Subject: Re: [llvm-dev] [cfe-dev] Revisiting our informal policy to > >> support two versions of MSVC > >> > >> > >> > >> I'll need to dig up the references for that... but I'm pretty sure the > >> universal CRT that debuted in MSVC 2015 only covers the C parts, and > not the > >> C++ parts. > >> > >> > >> > >> On 9/7/2016 4:28 PM, Zachary Turner wrote: > >> > >> It's worth pointing out that from 2015 and on, they claim to support > full > >> forwards compatibility of the standard libraries, so this should (in > theory) > >> never be an issue again. > >> > >> > >> > >> On Wed, Sep 7, 2016 at 1:12 PM James Molloy via llvm-dev > >> <llvm-dev at lists.llvm.org> wrote: > >> > >> Hi, > >> > >> As I understand it the specific issue we're seeing is related to what > >> Martin described. But due to numerous bugs found when mixing objects > >> compiled with different versions of MSVC in the past, we now are shy of > >> doing it even if it seems to work superficially - that's no guarantee > bugs > >> won't be found down the line. We'd much prefer to stay within the > realms of > >> what Microsoft support. > >> > >> Cheers, > >> > >> James > >> > >> On Wed, 7 Sep 2016 at 20:53, Craig, Ben via llvm-dev > >> <llvm-dev at lists.llvm.org> wrote: > >> > >> 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. > >> > https://randomascii.wordpress.com/2013/12/01/vc-2013-class-layout-change-and-wasted-space/ > >> > >> 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> 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> 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> wrote: > >> > >> On Sep 1, 2016, at 1:05 PM, Reid Kleckner <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> 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 > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > >> > >> _______________________________________________ > >> cfe-dev mailing list > >> cfe-dev at lists.llvm.org > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > >> > >> > >> _______________________________________________ > >> 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 > >> > >> > >> > >> -- > >> > >> Employee of Qualcomm Innovation Center, Inc. > >> > >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux > >> Foundation Collaborative Project > >> > >> _______________________________________________ > >> 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 > >> > >> > >> > >> -- > >> > >> Employee of Qualcomm Innovation Center, Inc. > >> > >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux > >> Foundation Collaborative Project > >> > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > 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/20161007/553fb829/attachment.html>
Reid Kleckner via llvm-dev
2016-Oct-12 23:03 UTC
[llvm-dev] [cfe-dev] Revisiting our informal policy to support two versions of MSVC
I migrated the sanitizer-windows builder to VS 2015, and it went green here: http://lab.llvm.org:8011/builders/sanitizer-windows/builds/30342 That leaves two remaining builders using VS 2013: http://lab.llvm.org:8011/builders/clang-x86-win2008-selfhost/ http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/ I'm going to be on vacation Fri-Tues this weekend, so I won't be around on Oct 15 to decomission any remaining VS 2013 bots. I know someone at Intel is installing VS 2015 on clang-x64-ninja-win7, so I assume that's going to switch soon. The clang-x86-win2008-selfhost builder is completely redundant with clang-x86-windows-msvc2015. If someone can take responsibility for deleting the builder and slave from the buildbot config and pinging Galina for the master restart on Monday, that would be great. I can delete the VM when I get back. On Fri, Oct 7, 2016 at 12:14 PM, James Molloy <james at jamesmolloy.co.uk> wrote:> Hi Mehdi, > > Yes, all on track and thank you all for your kind patience! > > Cheers, > > James > On Fri, 7 Oct 2016 at 20:13, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> Hi James, >> >> Are you still on track for pulling the plug on MSVC 2013 at the end next >> week? >> >> As another data point, other than new features or build failures, I just >> had to debug (with the help of Intel folks) a runtime failure because of a >> bug with zero-initialization in MSVC 2013 (see >> https://connect.microsoft.com/VisualStudio/feedback/details/802160 ). >> >> — >> Mehdi >> >> >> On Sep 8, 2016, at 8:38 AM, James Molloy via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> Thank you both, we appreciate it a lot! >> On Thu, 8 Sep 2016 at 16:37, Aaron Ballman via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> On Thu, Sep 8, 2016 at 11:24 AM, Reid Kleckner via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > I can't say I'm excited to support MSVC 2013 for another month, but I'm >> more >> > concerned about the burden on other developers. People I talked to at >> the SF >> > bay area social last Thursday were really excited to drop 2013 support. >> I >> > guess I'll leave my buildbots on another month and see how it goes. >> >> I'm happy to help carry the burden as well, so if you run into >> anything you'd like to punt over to me, please let me know. I'm happy >> to handle it in addition to the things I usually pick up on. >> >> ~Aaron >> >> > >> > On Thu, Sep 8, 2016 at 7:03 AM, Robinson, Paul via llvm-dev >> > <llvm-dev at lists.llvm.org> wrote: >> >> >> >> 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. >> >> >> >> >> >> >> >> I had originally proposed 15 September mostly because nobody had >> proposed >> >> a specific date, and it has been kind of dragging on for a while. The >> >> primary cost of deferring to 15 October seems to be that the community >> (Hi >> >> Reid!) will have to keep fixing VS2013 related problems for another >> month, >> >> which isn't ideal but hopefully we can tolerate it. >> >> >> >> (In fact at Sony we're only throwing the internal switch today, and >> we'll >> >> have to see what happens.) >> >> >> >> --paulr >> >> >> >> >> >> >> >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of >> >> Craig, Ben via llvm-dev >> >> Sent: Wednesday, September 07, 2016 2:42 PM >> >> To: Zachary Turner; James Molloy; llvm-dev at lists.llvm.org >> >> Subject: Re: [llvm-dev] [cfe-dev] Revisiting our informal policy to >> >> support two versions of MSVC >> >> >> >> >> >> >> >> I'll need to dig up the references for that... but I'm pretty sure the >> >> universal CRT that debuted in MSVC 2015 only covers the C parts, and >> not the >> >> C++ parts. >> >> >> >> >> >> >> >> On 9/7/2016 4:28 PM, Zachary Turner wrote: >> >> >> >> It's worth pointing out that from 2015 and on, they claim to support >> full >> >> forwards compatibility of the standard libraries, so this should (in >> theory) >> >> never be an issue again. >> >> >> >> >> >> >> >> On Wed, Sep 7, 2016 at 1:12 PM James Molloy via llvm-dev >> >> <llvm-dev at lists.llvm.org> wrote: >> >> >> >> Hi, >> >> >> >> As I understand it the specific issue we're seeing is related to what >> >> Martin described. But due to numerous bugs found when mixing objects >> >> compiled with different versions of MSVC in the past, we now are shy of >> >> doing it even if it seems to work superficially - that's no guarantee >> bugs >> >> won't be found down the line. We'd much prefer to stay within the >> realms of >> >> what Microsoft support. >> >> >> >> Cheers, >> >> >> >> James >> >> >> >> On Wed, 7 Sep 2016 at 20:53, Craig, Ben via llvm-dev >> >> <llvm-dev at lists.llvm.org> wrote: >> >> >> >> 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. >> >> https://randomascii.wordpress.com/2013/12/01/vc-2013-class- >> layout-change-and-wasted-space/ >> >> >> >> 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> 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> 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> wrote: >> >> >> >> On Sep 1, 2016, at 1:05 PM, Reid Kleckner <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> 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 >> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >> >> >> >> _______________________________________________ >> >> cfe-dev mailing list >> >> cfe-dev at lists.llvm.org >> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >> >> >> >> >> >> _______________________________________________ >> >> 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 >> >> >> >> >> >> >> >> -- >> >> >> >> Employee of Qualcomm Innovation Center, Inc. >> >> >> >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a >> Linux >> >> Foundation Collaborative Project >> >> >> >> _______________________________________________ >> >> 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 >> >> >> >> >> >> >> >> -- >> >> >> >> Employee of Qualcomm Innovation Center, Inc. >> >> >> >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a >> Linux >> >> Foundation Collaborative Project >> >> >> >> >> >> _______________________________________________ >> >> 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 >> > >> _______________________________________________ >> 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/20161012/25c207ca/attachment.html>
Mehdi Amini via llvm-dev
2016-Oct-17 23:18 UTC
[llvm-dev] [cfe-dev] Revisiting our informal policy to support two versions of MSVC
Hi, If there is no blocker (James?), we should be able to move on, so I filed as a starter: https://reviews.llvm.org/D25710 <https://reviews.llvm.org/D25710>: [Doc] Drop MSVC2013 support — Mehdi> On Oct 12, 2016, at 4:03 PM, Reid Kleckner <rnk at google.com> wrote: > > I migrated the sanitizer-windows builder to VS 2015, and it went green here: > http://lab.llvm.org:8011/builders/sanitizer-windows/builds/30342 <http://lab.llvm.org:8011/builders/sanitizer-windows/builds/30342> > > That leaves two remaining builders using VS 2013: > http://lab.llvm.org:8011/builders/clang-x86-win2008-selfhost/ <http://lab.llvm.org:8011/builders/clang-x86-win2008-selfhost/> > http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/ <http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/> > > I'm going to be on vacation Fri-Tues this weekend, so I won't be around on Oct 15 to decomission any remaining VS 2013 bots. > > I know someone at Intel is installing VS 2015 on clang-x64-ninja-win7, so I assume that's going to switch soon. > > The clang-x86-win2008-selfhost builder is completely redundant with clang-x86-windows-msvc2015. If someone can take responsibility for deleting the builder and slave from the buildbot config and pinging Galina for the master restart on Monday, that would be great. I can delete the VM when I get back. > > On Fri, Oct 7, 2016 at 12:14 PM, James Molloy <james at jamesmolloy.co.uk <mailto:james at jamesmolloy.co.uk>> wrote: > Hi Mehdi, > > Yes, all on track and thank you all for your kind patience! > > Cheers, > > James > On Fri, 7 Oct 2016 at 20:13, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > Hi James, > > Are you still on track for pulling the plug on MSVC 2013 at the end next week? > > As another data point, other than new features or build failures, I just had to debug (with the help of Intel folks) a runtime failure because of a bug with zero-initialization in MSVC 2013 (see https://connect.microsoft.com/VisualStudio/feedback/details/802160 <https://connect.microsoft.com/VisualStudio/feedback/details/802160> ). > > — > Mehdi > > >> On Sep 8, 2016, at 8:38 AM, James Molloy via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Thank you both, we appreciate it a lot! >> On Thu, 8 Sep 2016 at 16:37, Aaron Ballman via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> On Thu, Sep 8, 2016 at 11:24 AM, Reid Kleckner via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> > I can't say I'm excited to support MSVC 2013 for another month, but I'm more >> > concerned about the burden on other developers. People I talked to at the SF >> > bay area social last Thursday were really excited to drop 2013 support. I >> > guess I'll leave my buildbots on another month and see how it goes. >> >> I'm happy to help carry the burden as well, so if you run into >> anything you'd like to punt over to me, please let me know. I'm happy >> to handle it in addition to the things I usually pick up on. >> >> ~Aaron >> >> > >> > On Thu, Sep 8, 2016 at 7:03 AM, Robinson, Paul via llvm-dev >> > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >> >> 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. >> >> >> >> >> >> >> >> I had originally proposed 15 September mostly because nobody had proposed >> >> a specific date, and it has been kind of dragging on for a while. The >> >> primary cost of deferring to 15 October seems to be that the community (Hi >> >> Reid!) will have to keep fixing VS2013 related problems for another month, >> >> which isn't ideal but hopefully we can tolerate it. >> >> >> >> (In fact at Sony we're only throwing the internal switch today, and we'll >> >> have to see what happens.) >> >> >> >> --paulr >> >> >> >> >> >> >> >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org <mailto:llvm-dev-bounces at lists.llvm.org>] On Behalf Of >> >> Craig, Ben via llvm-dev >> >> Sent: Wednesday, September 07, 2016 2:42 PM >> >> To: Zachary Turner; James Molloy; llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> >> Subject: Re: [llvm-dev] [cfe-dev] Revisiting our informal policy to >> >> support two versions of MSVC >> >> >> >> >> >> >> >> I'll need to dig up the references for that... but I'm pretty sure the >> >> universal CRT that debuted in MSVC 2015 only covers the C parts, and not the >> >> C++ parts. >> >> >> >> >> >> >> >> On 9/7/2016 4:28 PM, Zachary Turner wrote: >> >> >> >> It's worth pointing out that from 2015 and on, they claim to support full >> >> forwards compatibility of the standard libraries, so this should (in theory) >> >> never be an issue again. >> >> >> >> >> >> >> >> On Wed, Sep 7, 2016 at 1:12 PM James Molloy via llvm-dev >> >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >> >> Hi, >> >> >> >> As I understand it the specific issue we're seeing is related to what >> >> Martin described. But due to numerous bugs found when mixing objects >> >> compiled with different versions of MSVC in the past, we now are shy of >> >> doing it even if it seems to work superficially - that's no guarantee bugs >> >> won't be found down the line. We'd much prefer to stay within the realms of >> >> what Microsoft support. >> >> >> >> Cheers, >> >> >> >> James >> >> >> >> On Wed, 7 Sep 2016 at 20:53, Craig, Ben via llvm-dev >> >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >> >> 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. >> >> https://randomascii.wordpress.com/2013/12/01/vc-2013-class-layout-change-and-wasted-space/ <https://randomascii.wordpress.com/2013/12/01/vc-2013-class-layout-change-and-wasted-space/> >> >> >> >> 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 <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> >> >> >> >> >> >> >> >> -- >> >> >> >> Employee of Qualcomm Innovation Center, Inc. >> >> >> >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux >> >> Foundation Collaborative Project >> >> >> >> _______________________________________________ >> >> 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 <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> >> >> >> >> >> >> >> >> -- >> >> >> >> Employee of Qualcomm Innovation Center, Inc. >> >> >> >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux >> >> Foundation Collaborative Project >> >> >> >> >> >> _______________________________________________ >> >> 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 <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 <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 <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> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161017/18b03f7e/attachment.html>