[llvm-dev] Compiler support in libc++

[David Blaikie via llvm-dev]

On Wed, Mar 3, 2021 at 9:31 AM Mehdi AMINI via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi,
>
> It seems to me that this would require one extra stage of bootstrap in CI
> for many buildbots.
> For example, today I have a Linux bot with a clang-8 host compiler and
> libstdc++. The goal is to ensure that MLIR (but it is applicable to any
> project) builds with clang and libc++ at the top of the main branch.
> So the setup is:
> - stage1: build clang/libc++ with host clang-8/libstdc++
> - stage2: build test "anything" using stage1 (`ninja check-all` in the
> monorepo for example, but applicable to any other external project)
>
> With this proposal, the setup would be:
>
> - stage1: build just clang with host clang-8/libstdc++
> - stage2: build clang/libc++ with stage1 clang and host libstdc++
> - stage3: build test "anything" using stage2 (`ninja check-all` in the
> monorepo for example, but applicable to any other external project)
>

Would it be possible to change the build system so that libc++ can be built
like compiler-rt, using the just-built clang? That would then avoid the
need for the extra stage? (though it would bottleneck the usual build a bit
- not being able to start the libc++ build until after clang build)

& again, this isn't so much a proposal of change, but one of documenting
the current state of things - which reveals the current situations are sort
of unsupported? (though it also goes against the claim that they're
untested) - so I'll be curious to hear from the libc++ folks about this for
sure.


>
> The only way to avoid adding a stage in the bootstrap is to keep updating
> the bots with a very recent host clang (I'm not convinced that increasing
> the cost of maintenance for CI / infra is good in general).
>
> We should aim for a better balance: it is possible that clang-5 is too old
> (I don't know?), but there are people (like me, and possibly others) who
> are testing HEAD with older compiler (clang-8 here) and it does not seem
> broken at the moment (or the recent years), I feel there should be a strong
> motivation to break it.
> Could we find something more intermediate here? Like a time-based support
> (2 years?) or something based on the latest Ubuntu release or something
> like that. That would at least keep the cost of upgrading bots a bit more
> controlled (and avoid a costly extra stage of bootstrap).
>
> Thanks,
>
> --
> Mehdi
>
>
>
> On Tue, Mar 2, 2021 at 7:10 AM Louis Dionne via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>>
>> > On Mar 1, 2021, at 15:41, Joerg Sonnenberger via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>> >
>> > On Mon, Mar 01, 2021 at 12:40:36PM -0500, Louis Dionne via llvm-dev
>> wrote:
>> >> However, for a library like libc++, things are a bit different.
>> >
>> > So how does this prevent the libstdc++ mess that you need to lock step
>> > the RTL with the compiler and more importantly, get constantly screwed
>> > over when you need to upgrade or downgrade the compiler in a complex
>> > environment like an actual Operating System?
>>
>> Could you please elaborate on what issue you’re thinking about here? As
>> someone who ships libc++ as part of an operating system and SDK (which
>> isn’t necessarily in perfect lockstep with the compiler), I don’t see any
>> issues. The guarantee that you can still use a ~6 months old Clang is
>> specifically intended to allow for that use case, i.e. shipping libc++ as
>> part of an OS instead of a toolchain.
>>
>>
>> > I consider this proposal a major step backwards...
>>
>> To be clear, we only want to make official the level of support that we
>> already provide in reality. As I explained in my original email, if you’ve
>> been relying on libc++ working on much older compilers, I would suggest
>> that you stop doing so because nobody is testing that and we don’t really
>> support it, despite what the documentation says. So IMO this can’t be a
>> step backwards, since we already don’t support these compilers, we just
>> pretend that we do.
>>
>> Louis
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://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/20210303/8c032256/attachment.html>