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

[Richard Smith]

On Mon, Oct 28, 2013 at 7:58 PM, Richard Smith <richard at metafoo.co.uk>wrote:

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

I have a working stage3, and the stage2 and stage3 binaries are the same
size, but they're different. Looking through a few differing object files,
it looks like the x86_64 register allocator has made slightly different
choices. This is probably an order-of-evaluation bug or similar, and seems
likely to be benign (the code sequences were trivially equivalent in all
cases I inspected).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131029/2a5016f5/attachment.html>