llvm dev - Oct 2013 - [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

On 10/29/13 07:01 AM, Richard Smith wrote:
>
> [As an aside: I use libc++ for my Clang development (on Ubuntu Linux), 
> and it works for me (tm). This is with libstdc++ providing the ABI 
> pieces, rather than libc++abi or libcxxrt, though.]
libc++ "works" for us as well, but it can't self host. I don't
know if
your "works" and my definition of works is 1:1. Can your clang+libc++ 
build itself multiple levels deep?

I believe both ABI alternatives are drop-in replacements and I hope not 
the root cause of what we observed. (We are only testing with libcxxrt 
though)
--------------
I could totally be wrong about libc++ and it's "our" fault in the 
testing we've done. I apologize if this is a non-issue and I hope during 
the "heads up" phase we have time to actually interject if there are 
potentially fatal issues. Forcing a dependency on gnu runtime/libs/STL 
is a serious regression imho.

On Mon, Oct 28, 2013 at 5:13 PM, "C. Bergström" <cbergstrom at
pathscale.com>wrote:
> On 10/29/13 07:01 AM, Richard Smith wrote:
>
>>
>> [As an aside: I use libc++ for my Clang development (on Ubuntu Linux),
>> and it works for me (tm). This is with libstdc++ providing the ABI
pieces,
>> rather than libc++abi or libcxxrt, though.]
>>
> libc++ "works" for us as well, but it can't self host. I
don't know if
> your "works" and my definition of works is 1:1. Can your
clang+libc++ build
> itself multiple levels deep?
>
Yes. I use my system g++ for my stage1, I use that compiler to build my
stage2, and I use my stage2 bootstrapped compiler for all my development
work. I rebuild my stage2 every few months.

I don't think I've ever explicitly checked that I get stage2 == stage3,
but
stage2 produces working compilers, but I'm doing a full bootstap now and
I'll let you know when it's done.

> I believe both ABI alternatives are drop-in replacements and I hope not
> the root cause of what we observed. (We are only testing with libcxxrt
> though)
> --------------
> I could totally be wrong about libc++ and it's "our" fault in
the testing
> we've done. I apologize if this is a non-issue and I hope during the
"heads
> up" phase we have time to actually interject if there are potentially
fatal
> issues. Forcing a dependency on gnu runtime/libs/STL is a serious
> regression imho.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131028/102440bc/attachment.html>

On Mon, Oct 28, 2013 at 5:53 PM, Richard Smith <richard at
metafoo.co.uk>wrote:
> On Mon, Oct 28, 2013 at 5:13 PM, "C. Bergström" <cbergstrom at
pathscale.com>wrote:
>
>> On 10/29/13 07:01 AM, Richard Smith wrote:
>>
>>>
>>> [As an aside: I use libc++ for my Clang development (on Ubuntu
Linux),
>>> and it works for me (tm). This is with libstdc++ providing the ABI
pieces,
>>> rather than libc++abi or libcxxrt, though.]
>>>
>> libc++ "works" for us as well, but it can't self host. I
don't know if
>> your "works" and my definition of works is 1:1. Can your
clang+libc++ build
>> itself multiple levels deep?
>>
>
> Yes. I use my system g++ for my stage1, I use that compiler to build my
> stage2, and I use my stage2 bootstrapped compiler for all my development
> work. I rebuild my stage2 every few months.
>
> I don't think I've ever explicitly checked that I get stage2 ==
stage3,
> but stage2 produces working compilers, but I'm doing a full bootstap
now
> and I'll let you know when it's done.
>
Just for fun, I used libc++ and libc++abi instead of libc++ and libstdc++.
Bootstrap success, with:

$ ldd ./bin/clang
        linux-vdso.so.1 =>  (0x00007fffbbf3c000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fc42f456000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc42f252000)
        libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5
(0x00007fc42f02a000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007fc42ee0d000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc42ebf6000)
        libc++.so.1 => /usr/lib/libc++.so.1 (0x00007fc42e90c000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc42e610000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007fc42e3fa000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc42e039000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc42f684000)

I'll do a stage2 / stage3 compare tomorrow, but I'm not expecting any
surprises. (I'm also mildly interested in trying to replace libgcc_s with
compiler_rt and using lld to link, but again, that's for another day...)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131028/9d6c3bbf/attachment.html>