llvm dev - Oct 2016 - Using C++14 code in LLVM

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

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>

On Sun, Oct 02, 2016 at 12:31:50PM -0700, Mehmet Erol Sanliturk via llvm-dev
wrote:
> 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 .
Given that clang and libc++ have supported C++14 quite early and faster
than GCC, I find that a strange statement without qualification. Note
that clang is often used with gcc as runtime and that can break various
things.

Joerg

On 2 October 2016 at 18:07, 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?
I believe C++14 has enough C++11 bug fixes to be worth moving to.

> 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.
We'd have to bump it, but as Zach said, Clang 3.4 has all the
features, so that should be fine.

According to DistroWatch, these are the distros that have 4.9 or higher:

Mint 18 [2016-06]
Ubuntu Utopic [2014-10] (14.10, current 16.04 LTS)
Debian Jessie [2015-04] (8.0 stable, current)
Fedora 21 [2014-12] (current stable: 24)
Slackware 14.2 [2016-07]

And these are the ones that dont:

RedHat (latest is 4.8.5)
OpenSUSE (latest stable is 4.8)
SLES (latest stable is 4.8.5)
CentOS (latest stable is 4.8.5)

So, it's pretty clear that, even if the compiler is 2 or 4 years old,
the distributions are only picking up now and commercially-focused
distributions haven't got there yet.

Based on those numbers, I'd say 4.8 is a good minimum for now. The
BSDs seem to be in a similar conundrum, so it would be pretty bad to
move the requirement to 4.9 and forcing large swaths of people to
manually download / compile their toolchains.

Clang may work natively, but it definitely doesn't work cross-compiled
our of the box, and sometimes not at all. It also needs binutils and
glibc support, which we're not even considering here.

On Linux, GNU compatibility is important, and even if we had a full
toolchain (using rt, libc++, lld, musl/newlib, etc), we'd still need
to be compatible with GNU objects, shared libraries, etc.

I like using new C++14 features just as much as the next guy, but I
prefer to have a stable and usable environment more.

cheers,
--renato

The BSDs don't seem as much of an issue.  FreeBSD 10 and 11 both have LLVM
3.9 and GCC 4.9.  NetBSD 6.1.5 and 7.0 both have GCC 5.3 and LLVM 3.8.
Open BSD has a very old GCC, but distrowatch claims that it also has LLVM
3.8.

Going back to what Joerg said earlier.
http://distrowatch.com/table.php?distribution=netbsd says NetBSD 7 ships
with GCC 5.3, but Joerg said 4.8.  Which is it?  And even if it's 4.8, the
same page also says NetBSD has LLVM 3.8.  Is that not sufficient?

BTW, CentOS and OpenSUSE have pre-built binaries for LLVM in the installer,
so that won't require a full bootstrap if someone wanted to get a modern
toolchain capable of building LLVM.

On Sun, Oct 2, 2016 at 1:48 PM Renato Golin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 2 October 2016 at 18:07, 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?
>
> I believe C++14 has enough C++11 bug fixes to be worth moving to.
>
>
> > 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.
>
> We'd have to bump it, but as Zach said, Clang 3.4 has all the
> features, so that should be fine.
>
> According to DistroWatch, these are the distros that have 4.9 or higher:
>
> Mint 18 [2016-06]
> Ubuntu Utopic [2014-10] (14.10, current 16.04 LTS)
> Debian Jessie [2015-04] (8.0 stable, current)
> Fedora 21 [2014-12] (current stable: 24)
> Slackware 14.2 [2016-07]
>
> And these are the ones that dont:
>
> RedHat (latest is 4.8.5)
> OpenSUSE (latest stable is 4.8)
> SLES (latest stable is 4.8.5)
> CentOS (latest stable is 4.8.5)
>
> So, it's pretty clear that, even if the compiler is 2 or 4 years old,
> the distributions are only picking up now and commercially-focused
> distributions haven't got there yet.
>
> Based on those numbers, I'd say 4.8 is a good minimum for now. The
> BSDs seem to be in a similar conundrum, so it would be pretty bad to
> move the requirement to 4.9 and forcing large swaths of people to
> manually download / compile their toolchains.
>
> Clang may work natively, but it definitely doesn't work cross-compiled
> our of the box, and sometimes not at all. It also needs binutils and
> glibc support, which we're not even considering here.
>
> On Linux, GNU compatibility is important, and even if we had a full
> toolchain (using rt, libc++, lld, musl/newlib, etc), we'd still need
> to be compatible with GNU objects, shared libraries, etc.
>
> I like using new C++14 features just as much as the next guy, but I
> prefer to have a stable and usable environment more.
>
> cheers,
> --renato
> _______________________________________________
> 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/b8252952/attachment.html>