Addition of -std=gnu++11 and -std=gnu11 compile flags

Guys

I have a PR which among other things adds -std=gnu++11 or -std=gnu11 to the compiler flags; which is what Arduino.cc use for the compile flags on their ARM boards

Making such a change appears to be high risk, so I’d like feedback from the forum, about whether such a change is necessary or beneficial.

In practice, I think that the major choices are
1. Go with the new stuff, such as Gcc 5.x, and take what comes with that
– such as C11 is now default since Gcc 5.0
2. Create a mechanism to allow compiler and linker parameters to control the tool flags

Cheers, Ollie

I tried a few of sketches with that and it doesn’t seem to do anything negative. As far as I can see it enables some features some people might think are good. If you are entertaining flags changes how about adding this compiler flags (c and c++):
-mslow-flash-data

and this linker flag:
specs=nano.specs

Those two flags both work towards making a smaller executable that runs faster.

These flags are enabled in official arduino sam3 and samd building systems.
While these flags are considered safe I dont know the impact in generated code, compiling a rather old code like libmaple.
Here is the list of features of gnu++11 standard: https://gcc.gnu.org/projects/cxx-status.html#cxx11
Most of them are related with extensions of C++ and other technical matters for advanced features of the language itself.

The specs=nano.specs flag on the linker has very strong impact in binary size, if C++ constructors, or some functions of std libs are used. This flag is also used in arduino sam3/samd versions.

As for gcc V5, I still have some problems with USB operation (do you remember the problem with gcc 4.9? something like this is happening)

Thanks guys

This sort of change is not something that can be done without a lot of testing, but as we know most people just download the Master version of the repo once, and never update.

Re: GCC 5

I’m not sure if thats used by SAM or SAMD board yet, is it?

Like slammer says, GCC 5 seems to optimise harder, and some things no longer work if the core is compiled using it.

The problems normally relate to variables pointing to hardware registers, which should be declared as volatile, but which aren’t and for some reason seem to work at the moment.

I recall someone posting a fix for the some optimisation issues with the USB (several months ago), which I think I pulled into the code, but there are probably a load of other places where optimisation changes will break the code.

Re: -mslow-flash-data and pecs=nano.specs

It would be good if the binaries were smaller, but again, this would need to be extensively tested

The only way I can see that this stuff would ever really be tested is to move to the ESP8266 release method, where the Master repo becomes the cutting edge which people use at their own risk, and there is a separate stable release.

Well, we need to encourage people to use the less stable code, but that may be hard, as most people just want to get their specific project working and are not necessarily interested in testing the latest core code, or working with a less than stable core.

Guys

The gnu++11 topic has cropped up again in another thread.

So I think perhaps its time to at least add this to the cpp recipe in Platform.txt
e.g.

add -std=gnu++11 after the warning flags

compiler.cpp.flags=-c -g -Os {compiler.warning_flags} -std=gnu++11 -MMD -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_{build.variant} -D{build.vect} -DERROR_LED_PORT={build.error_led_port} -DERROR_LED_PIN={build.error_led_pin}

RogerClark wrote:Guys

The gnu++11 topic has cropped up again in another thread.

So I think perhaps its time to at least add this to the cpp recipe in Platform.txt
e.g.

add -std=gnu++11 after the warning flags

compiler.cpp.flags=-c -g -Os {compiler.warning_flags} -std=gnu++11 -MMD -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_{build.variant} -D{build.vect} -DERROR_LED_PORT={build.error_led_port} -DERROR_LED_PIN={build.error_led_pin}

Hi VIctor

I agree.

Keep the main branch as the cutting edge, as generally I don’t change anything which would break a lot of functionality.

I’m also happy to do nano lib but we’d all need to do some testing with it.

Sounds good.

For anyone wanting to experiment with nano specs, where does that need setting?

–specs=nano.specs as option on gcc?

Tried it and it makes no difference at all to compile size.

quick search gives http://distribute.atmel.no/tools/openso … readme.txt

it says its a linker option

* C Libraries usage *

This toolchain is released with two prebuilt C libraries based on newlib:
one is the standard newlib and the other is newlib-nano for code size.
To distinguish them, we rename the size optimized libraries as:

libc.a –> libc_s.a
libg.a –> libg_s.a

To use newlib-nano, users should provide additional gcc link time option:
–specs=nano.specs

Nano.specs also handles two additional gcc libraries: libstdc++_s.a and
libsupc++_s.a, which are optimized for code size.

For example:
$ arm-none-eabi-gcc src.c –specs=nano.specs $(OTHER_OPTIONS)

This option can also work together with other specs options like
–specs=rdimon.specs

Please be noticed that –specs=nano.specs is a linker option. Be sure
to include in linker option if compiling and linking are separated.

** additional newlib-nano libraries usage

Newlib-nano is different from newlib in addition to the libraries’ name.
Formatted input/output of floating-point number are implemented as weak symbol.
If you want to use %f, you have to pull in the symbol by explicitly specifying
“-u” command option.

-u _scanf_float

stephen

OK, so when I put it in the correct place -> http://www.stm32duino.com/viewtopic.php?p=20627#p20627

This makes quite a difference:

Before – 84136 Program, 7904 Dynamic
After – 76772 Program, 5856 Dynamic

With the added benefit of my project still working

BennehBoy wrote:OK, so when I put it in the correct place -> http://www.stm32duino.com/viewtopic.php?p=20627#p20627

This makes quite a difference:

Before – 84136 Program, 7904 Dynamic
After – 76772 Program, 5856 Dynamic

With the added benefit of my project still working

I just tested the -std=gnu++11 and -std=gnu11 compile flags, made no difference in code size, and the bin just runs normally.

Have you also tested the linker option “–specs=nano.specs” ? This should do the size trick.
danieleff wrote:This is the same as viewtopic.php?f=14&t=1502 , and basically the usage of new/malloc in code.

Could you try something: put this
--specs=nano.specs

I like nano.specs .. however most here are probably going to be surprised that printf functions that use %f will silently display nothing .. Just wanted people to be aware and not freak out. If you are using the arduino stream methods, floats print fine. However, it seems many people like the printf style approach. Me, I prefer streaming style that uses compile time formatting.

stevestrong wrote:Have you also tested the linker option “–specs=nano.specs” ? This should do the size trick.
danieleff wrote:This is the same as viewtopic.php?f=14&t=1502 , and basically the usage of new/malloc in code.

Could you try something: put this
--specs=nano.specs

I thought there were already problems with printing floating point even with the current configs

I dont know printf %f works on AVR either

Guys

I think adding these files will not cause any problems, as a lot of people have tested them with no ill effects

There has also been a discussion about keeping the Master / Head of the repo the “cutting edge” and having separate branches for the stable versions
I’m OK with this, but I think rather than branches, that we can use the GitHub “releases” system, which I think just tags a specific commit as a “release”

The only thing I’m not sure about is what we call the current release version before I make these changes.

I don’t think we can use a version numbering system because if we called the current version 1.0 it would imply that its functionality complete / with all the current Arduino API; and its not.

We could use V 0.9 etc, but I think its been suggested before, that we use something like “Stable_$DATE” where $DATE is in the format YYYYMMDD

e.g. Stable_20170310

I think this is likely to be our best option at the moment, but I’m open to other suggestions

Dears, I was playing with the compiler/linker options (latest Maple F1 core) and it happened to me that appending “–specs=nano.specs” to the linker, of course reduced a bit the sketch size but also broke the automatic board reset on a blue pill: since that addition I had to manually reset the board in order to complete the upload..
Removing the option restored the automatic board reset feature.
Couldn’t test on other boards..

Best, E.

ps: compiler version: arm-none-eabi-gcc\4.8.3-2014q1

Those compiler flags have now been added for the F1 and F4 repos

See

https://github.com/rogerclarkmelbourne/ … 75b95126d8

Re: nano-specs

I think more testing would need to be done before I included nano-spec in the compile arguments, as it sounds like it potentially causes some serious issues

[Rick Kimball – Wed Mar 08, 2017 3:22 pm] –
I like nano.specs .. however most here are probably going to be surprised that printf functions that use %f will silently display nothing .. Just wanted people to be aware and not freak out.

I noticed that the size of our code just seems to be ever expanding. I was trying out someones test example that used sprintf and floats and its resulting compiled size was ~36k for a bluepill. This seems excessive. I did some more digging around and came across this post.

http://www.openstm32.org/forumthread2108#threadId2999

Basically the author suggests using ‘-specs=nosys.specs -specs=nano.specs -u _printf_float’ specifically in that order. The intent was to use most of the nano.specs library but revert back to the normal printf floating point behavior. I gave it a try by modifying my board setting:

$ git diff
diff –git a/STM32F1/boards.txt b/STM32F1/boards.txt
index 49c1293..029aecf 100644
— a/STM32F1/boards.txt
+++ b/STM32F1/boards.txt
@@ -410,7 +410,8 @@ genericSTM32F103C.menu.cpu_speed.speed_128mhz.build.f_cpu=128000000L
#– Optimizations
genericSTM32F103C.menu.opt.osstd=Smallest (default)
genericSTM32F103C.menu.opt.osstd.build.flags.optimize=-Os
-genericSTM32F103C.menu.opt.osstd.build.flags.ldspecs=
+genericSTM32F103C.menu.opt.osstd.build.flags.ldspecs=-specs=nosys.specs -specs=nano.specs -u _printf_float
genericSTM32F103C.menu.opt.oslto=Smallest Code with LTO
genericSTM32F103C.menu.opt.oslto.build.flags.optimize=-Os -flto
genericSTM32F103C.menu.opt.oslto.build.flags.ldspecs=-flto

I went from ~36k to ~25k .. and floating point was still working with sprintf.

This might be something to try if you are annoyed by the ever expanding flash waistline.

I just tried Rick’s ld.specs with a modified version of RTC lib, using sprintf, went down from ~36k to ~18k, sprintf working fine.

+5

So what’s the word on backward compability with c++98?
Do we need to litter our new code with #if __cplusplus >= 201103L tests?

I’d prefer if C++11 (or higher) was a hard requirement. That would make new code so much cleaner and easier to test.
Maybe it is required already…

Hi all!
I would like to make a proposal: why not introduce the -specs=nosys.specs -specs=nano.specs -u _printf_float directive when using “Smallest code (Default)” in Optimization option?
Alternatively could it be a good idea adding another optimization option with -Os -flto together with specs=nosys.specs -specs=nano.specs -u _printf_float directive?

What do you think about?

Best regards.
Luca