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

Post here first, or if you can't find a relevant section!
User avatar
RogerClark
Posts: 6692
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

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

Post by RogerClark » Tue Jul 12, 2016 11:50 pm

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.

Ollie
Posts: 183
Joined: Thu Feb 25, 2016 7:27 pm

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

Post by Ollie » Wed Jul 13, 2016 12:10 am

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

User avatar
Rick Kimball
Posts: 990
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

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

Post by Rick Kimball » Wed Jul 13, 2016 12:12 am

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.
Last edited by Rick Kimball on Wed Jul 13, 2016 12:27 am, edited 1 time in total.
-rick

User avatar
Slammer
Posts: 241
Joined: Tue Mar 01, 2016 10:35 pm
Location: Athens, Greece

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

Post by Slammer » Wed Jul 13, 2016 12:21 am

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)

User avatar
RogerClark
Posts: 6692
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

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

Post by RogerClark » Wed Jul 13, 2016 3:53 am

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.

User avatar
RogerClark
Posts: 6692
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

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

Post by RogerClark » Sun Mar 05, 2017 2:33 am

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

Code: Select all

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} 
I'm not sure about nano-lib.

I'd rather do that as a separate change, after everyone is happy with this one.

victor_pv
Posts: 1604
Joined: Mon Apr 27, 2015 12:12 pm

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

Post by victor_pv » Sun Mar 05, 2017 4:31 am

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

Code: Select all

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} 
I'm not sure about nano-lib.

I'd rather do that as a separate change, after everyone is happy with this one.
Thanks Roger, I'll add the flag to my file and start testing.
I vote for adding the nano-specs flag too, but separate from this one.

I also think it could be good to have separate branch for stable code, but rather than having the cutting edge as a separate, I would branch the stable one, and let the cutting edge as the default, then put a sticky post indicating there is a stable version for anyone wanting to use an old sketch, and in this link you can download it: xxxx

I think that will have 2 advantages. 1st, it's easy to find the version that stable, rather than have to dig in a bunch of commits to go back to a good tested one, and 2nd, it will force more people to use the cutting edge one, so if something doesn't work we find faster.

User avatar
RogerClark
Posts: 6692
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

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

Post by RogerClark » Sun Mar 05, 2017 5:09 am

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.

User avatar
BennehBoy
Posts: 420
Joined: Thu Jan 05, 2017 8:21 pm
Location: Yorkshire
Contact:

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

Post by BennehBoy » Sun Mar 05, 2017 11:51 am

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.
-------------------------------------
https://github.com/BennehBoy

zmemw16
Posts: 1370
Joined: Wed Jul 08, 2015 2:09 pm
Location: St Annes, Lancs,UK

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

Post by zmemw16 » Sun Mar 05, 2017 6:15 pm

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

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests