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

Hi,

“clang-x64-ninja-win7” was switched to VS2015.

It is red now due to a few PDB tests and one sanitizer test.

Failing Tests (10):
    LLVM :: DebugInfo/PDB/DIA/pdbdump-flags.test
    LLVM :: DebugInfo/PDB/DIA/pdbdump-linenumbers.test
    LLVM :: DebugInfo/PDB/DIA/pdbdump-symbol-format.test
    LLVM :: tools/llvm-pdbdump/class-layout.test
    LLVM :: tools/llvm-pdbdump/enum-layout.test
    LLVM :: tools/llvm-pdbdump/load-address.test
    LLVM :: tools/llvm-pdbdump/regex-filter.test
    LLVM :: tools/llvm-symbolizer/pdb/missing_pdb.test
    LLVM :: tools/llvm-symbolizer/pdb/pdb.test
    UBSan-Standalone-x86_64 :: TestCases/Integer/suppressions.cpp

http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/

Regards,
Denis


From: James Molloy [mailto:james at jamesmolloy.co.uk]
Sent: Tuesday, October 18, 2016 10:13
To: Mehdi Amini <mehdi.amini at apple.com>; Reid Kleckner <rnk at
google.com>
Cc: Aaron Ballman <aaron at aaronballman.com>; llvm-dev at lists.llvm.org;
Briltz, Denis <Denis.Briltz at intel.com>
Subject: Re: [llvm-dev] [cfe-dev] Revisiting our informal policy to support two
versions of MSVC

No blocker from me! Thanks for your patience!
On Tue, 18 Oct 2016 at 00:18, Mehdi Amini <mehdi.amini at
apple.com<mailto:mehdi.amini at apple.com>> wrote:
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: [Doc] Drop MSVC2013 support

—
Mehdi



On Oct 12, 2016, at 4:03 PM, Reid Kleckner <rnk at google.com<mailto: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

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

—
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/
>>
>> 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
>>
>> _______________________________________________
>> 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
>>
>>
>> _______________________________________________
>> 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
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> 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
>>
>>
>>
>> --
>>
>> 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
>>
>> _______________________________________________
>> 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
>>
>>
>>
>> --
>>
>> 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
>>
>
>
> _______________________________________________
> 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
>
_______________________________________________
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
_______________________________________________
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



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

I filed https://llvm.org/bugs/show_bug.cgi?id=30736 to get that fixed.

On Wed, Oct 19, 2016 at 3:52 AM, Briltz, Denis <Denis.Briltz at intel.com>
wrote:
> Hi,
>
>
>
> “clang-x64-ninja-win7” was switched to VS2015.
>
>
>
> It is red now due to a few PDB tests and one sanitizer test.
>
>
>
> Failing Tests (10):
>
>     LLVM :: DebugInfo/PDB/DIA/pdbdump-flags.test
>
>     LLVM :: DebugInfo/PDB/DIA/pdbdump-linenumbers.test
>
>     LLVM :: DebugInfo/PDB/DIA/pdbdump-symbol-format.test
>
>     LLVM :: tools/llvm-pdbdump/class-layout.test
>
>     LLVM :: tools/llvm-pdbdump/enum-layout.test
>
>     LLVM :: tools/llvm-pdbdump/load-address.test
>
>     LLVM :: tools/llvm-pdbdump/regex-filter.test
>
>     LLVM :: tools/llvm-symbolizer/pdb/missing_pdb.test
>
>     LLVM :: tools/llvm-symbolizer/pdb/pdb.test
>
>     UBSan-Standalone-x86_64 :: TestCases/Integer/suppressions.cpp
>
>
>
> http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/
>
>
>
> Regards,
>
> Denis
>
>
>
>
>
> *From:* James Molloy [mailto:james at jamesmolloy.co.uk]
> *Sent:* Tuesday, October 18, 2016 10:13
> *To:* Mehdi Amini <mehdi.amini at apple.com>; Reid Kleckner <rnk
at google.com>
> *Cc:* Aaron Ballman <aaron at aaronballman.com>; llvm-dev at
lists.llvm.org;
> Briltz, Denis <Denis.Briltz at intel.com>
>
> *Subject:* Re: [llvm-dev] [cfe-dev] Revisiting our informal policy to
> support two versions of MSVC
>
>
>
> No blocker from me! Thanks for your patience!
>
> On Tue, 18 Oct 2016 at 00:18, Mehdi Amini <mehdi.amini at apple.com>
wrote:
>
> 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: [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
>
>
>
> 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/20161019/5e247a7c/attachment.html>

We can try to print a better error message here, but it looks like
regardless someone will need physical access to the bot to determine what
the problem is with DIA.

On Wed, Oct 19, 2016 at 8:51 AM Reid Kleckner <rnk at google.com> wrote:
> I filed https://llvm.org/bugs/show_bug.cgi?id=30736 to get that fixed.
>
> On Wed, Oct 19, 2016 at 3:52 AM, Briltz, Denis <Denis.Briltz at
intel.com>
> wrote:
>
> Hi,
>
>
>
> “clang-x64-ninja-win7” was switched to VS2015.
>
>
>
> It is red now due to a few PDB tests and one sanitizer test.
>
>
>
> Failing Tests (10):
>
>     LLVM :: DebugInfo/PDB/DIA/pdbdump-flags.test
>
>     LLVM :: DebugInfo/PDB/DIA/pdbdump-linenumbers.test
>
>     LLVM :: DebugInfo/PDB/DIA/pdbdump-symbol-format.test
>
>     LLVM :: tools/llvm-pdbdump/class-layout.test
>
>     LLVM :: tools/llvm-pdbdump/enum-layout.test
>
>     LLVM :: tools/llvm-pdbdump/load-address.test
>
>     LLVM :: tools/llvm-pdbdump/regex-filter.test
>
>     LLVM :: tools/llvm-symbolizer/pdb/missing_pdb.test
>
>     LLVM :: tools/llvm-symbolizer/pdb/pdb.test
>
>     UBSan-Standalone-x86_64 :: TestCases/Integer/suppressions.cpp
>
>
>
> http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/
>
>
>
> Regards,
>
> Denis
>
>
>
>
>
> *From:* James Molloy [mailto:james at jamesmolloy.co.uk]
> *Sent:* Tuesday, October 18, 2016 10:13
> *To:* Mehdi Amini <mehdi.amini at apple.com>; Reid Kleckner <rnk
at google.com>
> *Cc:* Aaron Ballman <aaron at aaronballman.com>; llvm-dev at
lists.llvm.org;
> Briltz, Denis <Denis.Briltz at intel.com>
>
> *Subject:* Re: [llvm-dev] [cfe-dev] Revisiting our informal policy to
> support two versions of MSVC
>
>
>
> No blocker from me! Thanks for your patience!
>
> On Tue, 18 Oct 2016 at 00:18, Mehdi Amini <mehdi.amini at apple.com>
wrote:
>
> 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: [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
>
>
>
> 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/20161019/514e694f/attachment.html>