[llvm-dev] Using C++14 code in LLVM

UE US via llvm-dev llvm-dev at lists.llvm.org
Fri Nov 10 17:35:35 PST 2017


As long as the target is supported, I think the difficulty of rolling a
cross chain is overrated, but I've done lots of them and I remember when it
wasn't relatively easy.  I don't see their being harder at first as a
reason to impede progress with the language which, keep in mind, we're
actually writing the compiler in... as long as nobody suggests a total port
to Delphi.  ;-)

GNOMETOYS

On Wed, Nov 1, 2017 at 11:24 AM, Zachary Turner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Tue, Oct 31, 2017 at 11:23 PM Zachary Turner <zturner at google.com>
> wrote:
>
>> I’m ok with that, but the reason I’m pushing is because there is no clear
>> plan of action. Even if the plan of action is “When X happens, we can
>> enable C++14”, that’s fine too. I just want to know, concretely, what is X.
>>
>> We should either be able to say never or give a reasonable set of
>> conditions that would enable a switch. All I’ve seen though is “it’s hard”
>> which just means I’m going to ask again next year, and the year after, etc
>> due to lack of clear guidance.
>>
>> To address your point though , this isn’t really about building
>> everything with clang. You don’t need to bootstrap Clang to build a
>> hypothetical C++17 enabled LLVM, you could also bootstrap a more modern
>> version of GCC.
>>
>> This is really more fundamentally about “Can we have a clearly defined
>> policy about how often we can bump the minimum compiler version, like we
>> have for MSVC?”
>
>
> To make this even more concrete, let me offer a proposal:
>
> * We can bump the minimum required non-Microsoft toolchain version every 4
> years.
>
> Having something written like this allows us to have a schedule, and
> having a schedule allows downstream consumers to plan upgrades as needed so
> as to minimize disruption.
>
> 4 years is also a pretty reasonable amount of time IMO, but we can
> certainly discuss the exact value of N.
>
> I haven't said anything here about what it can be bumped *to*.  But in the
> interest of making progress, I'm separating the decisions out into smaller
> pieces so we can focus on one thing at a time.
>
> _______________________________________________
> 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/20171110/4168c186/attachment.html>


More information about the llvm-dev mailing list