2016-08-20 1:13 GMT+08:00 C Bergström :
> I finally got it to build and here's the size numbers
> 952K./lib/libc++abi.a
> 616K./lib/libc++abi.so.1.0
>
> If the above isn't enough motivation and you really want benchmarks
> which prove it's a pig... I'll try to figure something else
>
> Not
On Sat, Aug 20, 2016 at 5:41 AM, james wrote:
> On 08/19/2016 05:05 PM, C Bergström wrote:
>>
>> On Sat, Aug 20, 2016 at 4:52 AM, james wrote:
>>
>>
>>
>
> You removed your rude remark:::
> " Sorry to be the party crasher, but..."
>
> So let's put it back, just for clarity.
I'll forgive you bec
On 08/19/2016 05:05 PM, C Bergström wrote:
On Sat, Aug 20, 2016 at 4:52 AM, james wrote:
You removed your rude remark:::
" Sorry to be the party crasher, but..."
So let's put it back, just for clarity.
Back to my own glass house.. It will take a few years, but I am trying
to make it eas
On Sat, Aug 20, 2016 at 4:52 AM, james wrote:
>> Back to my own glass house.. It will take a few years, but I am trying
>> to make it easier (internally) to expose in some clear way all the
>> pieces which compose a fine tuning per-processor. If this was "just"
>> scheduling models it would be
On 08/19/2016 02:20 PM, C Bergström wrote:
Sorry to be the party crasher, but...
I'd love to have optimizations for everything out there, but it takes
a lot of work to fine tune for something specific.
Agreed. Right now on Armv8 alone, there are dozens of teams working on
the identical concep
Sorry to be the party crasher, but...
I'd love to have optimizations for everything out there, but it takes
a lot of work to fine tune for something specific.
Right now I see a few variants of ARMv8
ARM reference stuff - A57 cores and the newer bits.. The scheduling
and stuff seems m
On 08/19/2016 11:15 AM, C Bergström wrote:
On Fri, Aug 19, 2016 at 11:01 PM, Luca Barbato wrote:
BTW is pathscale ready to be used as system compiler as well?
I wish, but no. We have known issues when building grub2, glibc and
the Linux kernel at the very least. Someone* did report a long tim
On 19/08/16 17:15, C Bergström wrote:
> On Fri, Aug 19, 2016 at 11:01 PM, Luca Barbato wrote:
>> BTW is pathscale ready to be used as system compiler as well?
>
> I wish, but no. We have known issues when building grub2, glibc and
> the Linux kernel at the very least. Someone* did report a long t
On 19/08/16 19:13, C Bergström wrote:
> I finally got it to build and here's the size numbers
> 952K./lib/libc++abi.a
> 616K./lib/libc++abi.so.1.0
>
> If the above isn't enough motivation and you really want benchmarks
> which prove it's a pig... I'll try to figure something else
>
> Not
I finally got it to build and here's the size numbers
952K./lib/libc++abi.a
616K./lib/libc++abi.so.1.0
If the above isn't enough motivation and you really want benchmarks
which prove it's a pig... I'll try to figure something else
Not exactly a 1:1 comparison because I think other things
2016-08-19 11:11 GMT+08:00 C Bergström :
> I think you're getting a bit confused
>
> libsupc++ is the default now, from GNU
>
> libcxxabi is the bloated runtime from Apple
>
> libcxxrt is the faster c++ runtime, PathScale+David Chisnall, which
> PathScale and FreeBSD use by default. We don't need a
On Fri, Aug 19, 2016 at 11:01 PM, Luca Barbato wrote:
> BTW is pathscale ready to be used as system compiler as well?
I wish, but no. We have known issues when building grub2, glibc and
the Linux kernel at the very least. Someone* did report a long time
ago that with their unofficial port, were a
On 19/08/16 05:11, C Bergström wrote:
> I think you're getting a bit confused
>
> libsupc++ is the default now, from GNU
>
> libcxxabi is the bloated runtime from Apple
>
> libcxxrt is the faster c++ runtime, PathScale+David Chisnall, which
> PathScale and FreeBSD use by default. We don't need a
I think you're getting a bit confused
libsupc++ is the default now, from GNU
libcxxabi is the bloated runtime from Apple
libcxxrt is the faster c++ runtime, PathScale+David Chisnall, which
PathScale and FreeBSD use by default. We don't need a version number
because it's pretty much rock solid st
2016-08-19 10:07 GMT+08:00 :
> That seems a lot like what we've already done. I guess a GSOC student is
> working on the libcxxabi piece.
I am that GSoC student :)
I'm currently trying to push libc++abi to replace libcxxrt as the
default runtime: https://github.com/gentoo/gentoo/pull/2048
The
o.org
Reply To: gentoo-dev@lists.gentoo.org
Cc: gentoo-dev-annou...@lists.gentoo.org
Subject: Re: [gentoo-dev] New project: LLVM
2016-08-18 21:56 GMT+08:00 C Bergström :
> @mgorny may be able to help with some of this and has quite a bit of
> experience building clang/llvm. Where I work we use
2016-08-18 21:56 GMT+08:00 C Bergström :
> @mgorny may be able to help with some of this and has quite a bit of
> experience building clang/llvm. Where I work we use a "wrapper" that
> helps coordinate a lot of the moving pieces.
>
> https://github.com/pathscale/llvm-suite/
>
> This may not be the
@mgorny may be able to help with some of this and has quite a bit of
experience building clang/llvm. Where I work we use a "wrapper" that
helps coordinate a lot of the moving pieces.
https://github.com/pathscale/llvm-suite/
This may not be the perfect "gentoo" way to handle it, but the
approach
Woot! Don't tell Stallman lol.
On Tue, Aug 16, 2016, 09:22 Michał Górny wrote:
> Hello, everyone.
>
> I have the pleasure of announcing that after the long period of split
> maintenance, we are forming an united LLVM project [1] to maintain all
> of LLVM packages in Gentoo and work on establishi
Hello, everyone.
I have the pleasure of announcing that after the long period of split
maintenance, we are forming an united LLVM project [1] to maintain all
of LLVM packages in Gentoo and work on establishing improved support for
a healthy, gcc-free ecosystem.
[1]:https://wiki.gentoo.org/wiki/Pr
20 matches
Mail list logo
