Enable C++14 on all platforms

[ekiwi]

C++14 has been out for more than half a year now, and provides some handy features like Relaxed constexpr restrictions.

GCC 5 has (at least for our purposes) full C++14 support. Unfortunately it is not easily available for all available platforms right now. I suggest we use this issue to track on what platforms GCC 5 is missing.

Hosted (gcc)

• Fedora 22 and up comes with at least gcc 5.1.1
• Ubuntu 15.04?
• Homebrew?
• Travic-CI?

ARM (arm-none-eabi-gcc)

• The prebuilt arm-none-eabi toolchain that we use on all platforms will release arm-none-eabi-gcc 5.0 in December 2015

AVR (avr-gcc)

• Fedora 23 (which hasn't been released) will feature avr-gcc 5.1.0
• Ubuntu?
• Homebrew?
• What about the atmel packages that we use on travis-ci?

[dergraaf]

Debian 8 has gcc 4.9.2, avr-gcc 4.8.1 and arm-none-eabi-gcc 4.8.4.

[salkinium]

For avr-gcc on travis-ci, we download the latest toolchain from Atmel, since it is not available on the old Ubuntu that travis-ci uses.

[ekiwi]

For avr-gcc on travis-ci, we download the latest toolchain from Atmel, since it is not available on the old Ubuntu that travis-ci uses.

I just added some commands to our .travis.yml to display the gcc version. Apparently, the Atmel build that we use is a gcc 4.8.1.

[dergraaf]

On a similar note: What version of gcc is required to build the current development branch? The arm-none-eabi-gcc 4.8.2 I am using seems to be to old.

[salkinium]

4.9+, due to constructor inheritance in this Register class.

[ekiwi]

4.9+, due to constructor inheritance in this Register class.

Good to know! I thought the blocker was only the colorful error messages commit (c4321260bce306ad54478a6b890d0a6a394c4201).

[ekiwi]

Is the Register class mentioned above not used for avr? I'm wondering how avr builds on travis with a gcc 4.8.

[salkinium]

Hm, good point. According to the Support Page of GCC, Constructor inheritance is supported from 4.8+.

Not sure where I got the 4.9 from.

[ekiwi]

Ok. So it's probably only the -fdiagnostics-color=auto argument, that gcc 4.8 chokes on.

[salkinium]

arm-none-eabi-gcc from launchpad now comes in version 5.3, which definitely supports C++14. What is your opinion? Would it be ok to enable (and require) C++14 for xpcc?

[ekiwi]

Would it be ok to enable (and require) C++14 for xpcc?

I would be all for that.

If people use a modern distribution, they can always get at least gcc 5.2 from their repositories and if they do not have that option they are free to use the "officially supported" toolchain from the arm-none-eabi launchpad.

Since the season is over, this would also be a good time for us at the robotics club to make sure that everyone is running a recent gcc version. (I guess we are still the largest part of the xpcc user base ;-) )

[ekiwi]

But how about avr support? Does Atmel already provide a gcc 5.2+ build?

[salkinium]

But how about avr support? Does Atmel already provide a gcc 5.2+ build?

Sadly no. The latest official toolchain 3.5.3 uses GCC 4.9.2. That's disappointing.

Linux distributions already have avr-gcc 5.x natively, and for OS X I guess, I'd have to update the homebrew package to 5.2.

[ekiwi]

We need a plausible replacement for distributions that distribute old software, i.e., Debian, Mint and Ubuntu LTS. Those people are normally fine with installing a 3rd party repo or a binary as that is the way to get up to date software on these distributions. But without such a source for AVR we are still stuck with C++11, because imho we do not want to fragment the xpcc code base.

[Sh4rK]

Sadly no. The latest official toolchain 3.5.3 uses GCC 4.9.2. That's disappointing.

Some distros have a much newer version, for example Arch Linux has 5.3.0 at the moment. Other than that, people can definitely install avr-gcc from source (which probably nobody will do), or we could provide binary packages for the few biggest distros + Windows.

[ekiwi]

Some distros have a much newer version, for example Arch Linux has 5.3.0 at the moment.

Yes. However, Arch might be the only one. Fedora messed up big time with their avr-gcc 5.1 release and now they are back at 4.9 with no update in sight. The latest Ubuntu (16.10) is also still on 4.9.

In addition to that I could not find any reputable source for Windows binaries except for Atmel.

or we could provide binary packages for the few biggest distros + Windows.

At least for the core xpcc team, we do not see ourselves in the business of building and distributing avr-gcc packages. We would rather add new cool features to xpcc.

[Sh4rK]

At least for the core xpcc team, we do not see ourselves in the business of building and distributing avr-gcc packages. We would rather add new cool features to xpcc.

You are right, this would involve a nontrivial amount of time and work.

Anyway, seeing this trend, C++14 won't be enabled for some time :/

[salkinium]

Anyway, seeing this trend, C++14 won't be enabled for some time :/

With C++17 and LLVM support for ARMv7-M on the doorstep, let's not be blinded from the truth: AVRs will certainly not be part of that future.

AVRs block us from using the standard library, which is really terrible on it's own. Add to this the limited hardware (hello non-linear address space) and lack of toolchain support.

I've been harbouring the uncomfortable feeling that AVR support is holding xpcc back for some time now. I've also personally outgrown them and seek new challenges elsewhere.

I suggest enabling C++14 at least for the HAL of all ARM Cortex-M targets. We will not introduce C++14 features into the HAL interfaces for the next year or so to let avr-gcc with C++11 support catch up with modern times.

I'm undecided yet about the xpcc library (ie. the non-HAL part). Ideally we'd use C++14 features in a way that is compatible with avr-gcc's lack thereof. In practice this could mean:

• do not actively introduce C++14 features in code that exists. It works, and it's fine.
• backport single libc++ features to avr-gcc as for example done with initializer_list.
• only enable certain xpcc features on ARM Cortex-M. Basically anything that requires higher computing resources, like color displays, math functions.

After a year we'll evaluate the avr-gcc toolchain support.

Or… we could spend some effort on figuring out how to compile avr-gcc from source for 5.x 😜

[salkinium]

Looking at the GCC C++14 support page, avr-gcc 4.9 is "only" missing:

• "Variable templates" 😐
• "Relaxing requirements on constexpr functions": 😢
• "Member initializers and aggregates" 😢
• "Sized deallocation" 😐

[ekiwi]

AVRs will certainly not be part of that future.

It's all gcc so as long as there are people who build the latest version (like the Arch folks) it should not be too much of a problem.

In general I like that we support AVRs because it shows how well our abstractions work. Remember: Arduino still has a huge array of legacy drivers for external chips that only work on their AVR based boards. In xpcc on the other hand, we have a lot of different drivers for such chips that work as well on AVR as they do on ARM. If people just want a pure ARM library, there are other alternatives (e.g. mbed).

AVRs block us from using the standard library, which is really terrible on it's own.

Isn't there a good implementation of the stdc++ lib for AVR around? Instead of reinventing the wheel within the xpcc codebase it would make more sense to have an external avr std lib project that implements the missing interfaces.

[salkinium]

Isn't there a good implementation of the stdc++ lib for AVR around?

Tracked in #20.

[cajt]

Most people don't like to build cross-compilers. Forcing everybody to do so for more or less unknown benefits is a real step backwards in usability of xpcc. BTW, what about some kind of release cycle, tracking the develop branch feels tiring after some time.

[salkinium]

Most people don't like to build cross-compilers.

Niemand hat die Absicht einen Compiler zu kompilieren. 😇

The way I see it is we support the official toolchains only. These are avr-gcc from Atmel, and arm-none-eabi-gcc from ARM. We're not going to make people compile avr-gcc from source, that's just asking for non-reproducible issues.

Note that PR #128 tests several versions of the ARM toolchain, however, I'm scared of merging it, since it takes >3h (!) to complete on Travis CI.

what about some kind of release cycle

Tracked in #160.

[ekiwi]

Fedora has just updated their gcc, avr-gcc and arm-none-eabi-gcc to version 6.2. So when the other distributions follow, we should be fine with using C++14.

[daniel-k]

Archlinux already has it, just for the record :P

[salkinium]

Meanwhile Atmel updated their official avr-gcc toolchain to 4.9.2. Yay.

[salkinium]

Homebrew for OS X has avr-gcc 6.2 via the osx-cross/avr tap. It's not pre-compiled, but installation works nonetheless (even if it takes a while). I was able to compile all AVRs with it (and I mean ALL of them).

Niemand hat die Absicht einen Compiler zu kompilieren. 😇

The way I see it is we support the official toolchains only. These are avr-gcc from Atmel, and arm-none-eabi-gcc from ARM. We're not going to make people compile avr-gcc from source, that's just asking for non-reproducible issues.

BWAHAHA. Great one, Niklas.

How about a compromise: We're gonna make C++11 a requirement for xpcc and C++14 a requirement for modm. Maybe Atmel gets their shit together within this year and releases an official gcc 5 port.

[dergraaf]

How about a compromise: We create an additional future namespace (similar to std::tr1) with its own folder structure. All the stuff which requires C++14/17 goes there. This allows to test out new features and implementations. The main part of the code is kept with the current C++11 constraint. All new code is put in the structure with the lowest language requirements (that part is very important!). If we decide that a language version is sufficiently supported we increase the requirements and move code to the lower level.

The would mean, that for targets with newer toolchains you have more/newer/better code available, but we are still able to support targets with an older toolchain.

What do you think?

[salkinium]

What do you think?

I don't want to maintain a library with two language versions, that's just cruel. I think we should upgrade all of xpcc to C++14 instead of just for modm, so that we can collect some experience in the RCA about this switch.

(Also see above where I briefly considered building only ARM targets with C++14).

[salkinium]

As a side note: We should also update to C11. It requires gcc v4.9, so it should work just fine with avr-gcc.

[salkinium]

Oh, Atmel updated it's GCC to 5.4.0. It's a miracle! We can now do C++14 on AVRs. \o/ http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/3.6.0/