Bump AVR c++ standard to 2014 from 2011

[xloem]

No description provided.

[matthijskooijman]

Even though I would very much like to see C++14 support, I'm not sure how complete and correct the implementation in the avr-gcc version we use (which is not too recent) is. Do you have any info on that?

[xloem]

You guys use gcc 4.9 right now. If https://gcc.gnu.org/projects/cxx-status.html#cxx14 is to be trusted, this gcc is missing variable templates, relaxed constexpr functions, member initializers, and sized deallocation, but has many other c++14 features.

I took the time to review the behavior of this release of avr-g++ with regard to c++11 to c++14 breaking changes (mentioned in stm32duino/Arduino_Core_STM32#191). The behavior matched what the official website advertised:

1. avr-gcc 4.9 supports digit separators. passing --std=gnu++14 will identify incompatible uses
2. avr-gcc 4.9 does not support sized deallocation. code which does not define a sized deallocator, but does define an unsized deallocator, will (incorrectly) compile. This shouldn't be too much of an issue on arduino because the use of dynamic memory routines with this core is incredibly rare.
3. avr-gcc 4.9 will (incorrectly) mark all constexpr member functions as const
4. avr-gcc 4.9 has no stdin, so it doesn't matter that std::gets has been removed

The third item in this list is the only significant concern I see here. It is possible to write c++14 code using avr-gcc 4.9 which will then break on a future compiler release when relaxed constexpr functions are implemented (they will no longer be callable on const objects unless marked const). This is unfortunate; I'd like to see c++14 become the norm.

So

1. There are rare situations where this upgrade would break code right now (weird uses of the single-quote character will be interpreted differently because it is now a digit separator).
2. Code using constexpr member functions will likely break in the future if the release of avr-g++ is upgraded.

I personally suspect these situations are rare enough to warrant implementing this change (does any arduino code use the constexpr keyword on a member function? this keyword didn't even exist before c++11). These two concerns could be dealt with at the same time if avr-g++ were additionally upgraded to at least version 5, when requirements on constexpr functions are relaxed.

[facchinm]

@xloem the next version of avr core is likely to be shipped with gcc 5.4 (Atmel toolchain 3.6.0 or 3.6.1).
A staging json to test this toolchain can be downloaded here arduino/toolchain-avr#47 .
It would be cool if you could check if the compatibility with some issues like the constexpr one using that toolchain 😉

[xloem]

I checked with the new toolchain 3.6.0, gcc 5.4:

1. digit separators still supported. code containing a single quote character between 2 digits with no whitespace may (correctly) break (very poor style)
2. not yet strict regarding sized deallocation (incorrect), but arduino has no heap anyway
3. constexpr has correct behavior now. use of constexpr member functions may (correctly) fail to compile without change. A grep of the arduino release shows no use of this keyword.
4. gets() is not removed yet (incorrect), but arduino has no stdin anyway

I think it would be great if the c++ compilation standard were bumped for this next toolchain!

[PaulStoffregen]

I made a switch to C++14 and gcc 5.4 on ARM-based Teensy about a year ago. It's worked quite well. I can't speak to all usage of constexpr, but I can say it works very well for constructors.

[harryboo]

I can confirm that the new toolchain works without any problems. Tested today with 1.6.205..
constexpr works now as expected.
Hope the new toolchain will find their way in the nightly build as soon as possible....

[matthijskooijman]

@harryboo, great!

If we're going to bump to C++14, we should probably do the same for the SAM and SAMD cores. Anyone who wants to prepare a pullrequest for that (https://github.com/arduino/ArduinoCore-samd and https://github.com/arduino/ArduinoCore-sam) and/or test if bumping to C++14 there runs into any issues?

[facchinm]

The CMISIS we are shipping with SAMD produces a million warnings when compiled with gcc 7.2.0 . I believe that a full refresh of all companion tools could be needed before adopting a newer toolchain

[matthijskooijman]

Ah, and I see we're currently on gcc 4.8 for SAM/SAMD, I thought those were already using newer versions. Ok, so that's a bit more work. Shouldn't block enabling C++14 for AVR, though?

[facchinm]

It would be better to enable it on all platforms at once 😉 It's not blocking, though

[neu-rah]

It would be better to enable it on all platforms at once It's not blocking, though

any timeline for this?

[facchinm]

I'm closing this issue here; if we are still interested (probably C++17 would be a nicer target for the whole platform due the the increased constexpr capabilities, so we can do a lot of calculation at compile time) it will necessarily need to be ported to all cores.

[AgainPsychoX]

constexpr, especially C++20 would allow great improvement for IO. Many people use predefined IO for digitalRead, digitalWrite, pinMode and soon, however those fancy functions come with overhead - including looking up pins to ports/bitmasks. With std::is_constant_evaluated we could optimize each of this basic operation function. In small projects it would be meaningless, but larger projects or external devices that require custom protocols it makes huge differences.

Just look a this pseudocode:

constexpr inline uint8_t digitalPinToPort(uint8_t pin) {
    static constexpr uint8_t PROGMEM digital_pin_to_port[] = {/*...*/};

    if (std::is_constant_evaluated())
        return digital_pin_to_port_PGM[pin];

    return pgm_read_byte(digital_pin_to_port + pin);
}

For each digitalRead/digitalWrite call its looking up 3x uint8_t and 1x uint16_t. It's about 30 cycles of overhead, that could be just avoided if we had constexpr (which just load intermediate value in 1-2 cycles, so it would be 6-10 cycles).

Apart from faster execution, if there were no usage for this lookup tables while in runtime, those could be just skipped, in a result saving program memory for other things (sometimes those 30-200 bytes really save the ass). Anyway, its only one of possible usages inside Arduino core alone..

[matthijskooijman]

With std::is_constant_evaluated we could optimize each of this basic operation function

I don't think this is dependent on newer C++ versions, gcc already has __builtin_constant_p which I thin is essentially the same thing, available already. For the I/O optimizations you mention, see also previous discussion in arduino/ArduinoCore-avr#264 (but note that one challenge here is that the conversion tables are variant-specific, so a local static variable will not work, and when changes to the variants are needed, this might cause problems with variants in third-party cores if not done carefully. If you want to discuss this further, probably head over the linked issue. If you want to provide a PR that implements this, keeping compatibility with existing third-party variants, I would be happy to review it (and be happy if it got merged, I agree that this would be a great improvement to have).