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

Sun Oct 2 12:31:50 PDT 2016

On Sun, Oct 2, 2016 at 10:07 AM, Pete Cooper via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I haven't been following C++14 closely, but from hallway conversations at
> work it seems like 17 is the bigger win in terms of features.
>
> Is it worth waiting for 17 instead? Or, as we will only get a subset of 14
> features anyway, just instead take a subset of 17 features?
>
> My only worry with 14 is that it's always going to be code churn in terms
> of using the new features. If they are worth it then no problem, but we
> should make sure they are. I'd prefer we have the update bots and code
> churn once instead of twice in the near future.
>
> Finally, I think we have clang 3.1 as the min version. Anyone know what
> that minimum will move to for the 14 support needed? I don't think it's as
> much of an issue as most distros are gcc based, but still good to know.
>
> Cheers
> Pete
>
> Sent from my iPhone
>
>

I am compiling a large number of packages with their make files .

One important problem is the missing features from compilers .

For example : A program is using C++14 which is compilable with GCC . When
it is tried to be compiled with CLang , it is failing because CLang does
not have C++14 features .

This means , if C++14 is skipped from the CLang compiler , a lot of
packages will not be compilable with CLang .

Then a more easy way to compile a large number of packages , a more
convenient compiler will be GCC and Clang will be eliminated naturally .

My opinion is that during decision of what to include or exclude may make
it necessary to consider coverability of possible compilable ports/packages
and what users can do for them .

Thank you very much .

Mehmet Erol Sanliturk

> > On Oct 2, 2016, at 9:49 AM, C Bergström via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > On Mon, Oct 3, 2016 at 12:37 AM, Zachary Turner via llvm-dev
> > <llvm-dev at lists.llvm.org> wrote:
> >>
> >>
> >> On Sat, Oct 1, 2016 at 11:46 PM Joerg Sonnenberger via llvm-dev
> >> <llvm-dev at lists.llvm.org> wrote:
> >>>
> >>> On Sun, Oct 02, 2016 at 05:33:40AM +0000, Zachary Turner via llvm-dev
> >>> wrote:
> >>>> 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
> >>>
> >>> I do care quite a bit about GCC 4.8 support, since that's what is
> >>> shipped with NetBSD 7.
> >>>
> >>>> 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.
> >>>
> >>> If that is the only argument, we should be able to reuse the libc++
> >>> implementation without too much trouble?
> >>
> >>
> >> That wasn't even the main argument :)  The main argument was the
> ability to
> >> use C++14 in the upstream.  I suspect that we won't want to be tied to
> C++11
> >> indefinitely though.  LLVM already has a section called "Getting a
> modern
> >> host C++ toolchain" for distros with older GCC's.  In theory this could
> just
> >> be bumped from "older than GCC 4.7" to "older than GCC 4.9".  I admit I
> >> don't know much (i.e. anything) about NetBSD.  But a quick look at the
> >> release history says that even NetBSD 8 (which isn't even stable yet),
> is
> >> still only going to have GCC 4.8.  So if we're going to be held back by
> >> this, we're looking at 2-4 years before we can use C++14 upstream.  Just
> >> food for thought.
> >
> > Jörg, other than just time and energy - what's the (big?) technical
> > challenge or bug list which prevents NetBSD from doing something
> > radical like going to a really modern version of gcc? (I realize
> > NetBSD tends to be very conservative, which isn't a bad thing) I've
> > never had access to NetBSD 1st hand, but is very modern gcc available
> > in "ports"?
> > _______________________________________________
> > 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/20161002/b01fe0fb/attachment.html>