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

[Lang Hames via llvm-dev]

> ...I think we should take a greedy approach here, and adopt as many
features as are beneficial as early as we can get away with given the host
compilers we support.

+1!

If we can move to C++14 I'd want it for the generalized lambda captures
alone.

Cheers,
Lang.


On Mon, Oct 3, 2016 at 12:43 AM, Chandler Carruth via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On the one hand, I like this proposal. But that is because every system I
> care about has or can easily acquire a GCC 4.9 baseline compiler. So when I
> imagine that you want to move to GCC 5 instead of GCC 4.9, I get extremely
> nervous.
>
> I *do* think we should be prepared to move the baseline forward though. We
> picked GCC 4.7 a *very* long time ago.
>
> I understand that there are systems without GCC 4.9 now, but there were
> systems without GCC 4.7 when we raised the minimum requirements to that
> version. For me, the question is more how easily users on those systems
> could update. If it is reasonably straight forward, I would be fine moving
> the baseline up. If there are reasons why installing a newer GCC would be
> very hard, that would be more concerning to me.
>
> I do think moving past GCC 4.9 presents a unique challenge due to the ABI
> break which took place between GCC 4.9 and GCC 5. For example, for me,
> "just installing" a newer version of GCC works great right up until GCC 5
> where it starts to break for ABI reasons.
>
>
> However, once all of that is settled and we know what the baseline
> compilers are, I'm 100% in favor of adopting essentially all of the
> features they support and that work reliably. If we can get most of C++14,
> great, let's do it. To Pete's point, I do think C++17 has more exciting
> features in the pipeline, but I think we should take a greedy approach
> here, and adopt as many features as are beneficial as early as we can get
> away with given the host compilers we support.
>
> Which means the primary question is about the host compilers IMO.
>
> -Chandler
>
> On Sat, Oct 1, 2016 at 10:33 PM Zachary Turner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> A thread was started over the summer to discuss the timeline for bumping
>> LLVM up to Visual Studio 2015 to enable the use of various new language
>> features.  Currently the ETA for this is sometime in mid-October, so within
>> 2-3 weeks.
>>
>> With this happening imminently, I thought it would be worth tossing this
>> out there and seeing what people think.
>>
>> With VS on 2015, the major lagging compiler is going to be GCC.  Our
>> minimum GCC requirement is 4.7, which is quite old (almost 4 years for
>> anyone keeping count).  What are the challenges with pushing this forward?
>>
>> With VS2015, the biggest remaining missing C++14 features are variable
>> templates, sized allocation, and extended constexpr.  But it gains generic
>> lambdas, init-captures, decltype(auto) return, and auto return without
>> requiring the trailing -> decltype syntax.
>>
>> While GCC doesn't claim to "fully" support C++14 until 5.2 (which is only
>> about 1 year old), you can get all of the above features with GCC 4.9
>>
>> So if we're willing to allow "partial" C++14 support in LLVM (i.e a
>> whitelisted set of features), we may be able to get many of the most useful
>> features by going to GCC 4.9, which is still a good 2.5 years old.
>>
>> One potentially added benefit of this is that GCC supports <regex> in
>> 4.9.  This might allow us to kill of llvm::Regex in favor of standardizing
>> on std::regex, as GCC is currently the only supported compiler without a
>> regex implementation.
>>
>> Thoughts?
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
> _______________________________________________
> 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/20161003/0323a9b5/attachment.html>