Re: size of exception handling (Was: performance of exception handling)

[Freddie Chopin]

On Tue, 2020-05-12 at 12:07 +0100, Jonathan Wakely wrote:
> You're talking about C++ exceptions in general, but the problems you
> mention seems to be issues with specific implementation properties.

Possibly true, but this argument - that all the problems are related to
specific implementation and thus can be easily fixed - is the same for
years and yet the problem is still there (; I guess that if this could
be easily fixed, then it would be done years ago. Along with the
performance and non-deterministic execution issues...

> If the comments above are referring to the libstdc++ verbose
> terminate
> handler, that's configurable. Configuring GCC with
> --disable-libstdcxx-verbose will disable that, and so will building
> libstdc++ with -fno-exceptions. That was fixed years ago.

True, sorry for the confusion, indeed I was talking about verbose
terminate handler. I check the state of C++ exceptions for MCUs only
once every few years, so that's why I got that mixed with
std::terminate(). I use my custom compilation with disabled exceptions
(toolchain & libstdc++ built with -fno-exceptions -fno-rtti) and this
works perfectly fine.

Anyway... If you have to recompile the toolchain, the problem is still
there. Most of the people (like 99,666%) will not do that for various
reasons. Some don't know how, some use only Windows, some don't have
time to deal with the compilation (the whole toolchain takes around an
hour here, but this excludes the time to prepare the script that builds
it), some other consider the toolchain provided by MCU vendor (or by
ARM) as "tested to work correctly" so they don't want to replace that
with their custom built solution, and so on, and so on...

Regards,
FCh

Re: size of exception handling

[Freddie Chopin]

On Tue, 2020-05-12 at 11:16 +0200, Florian Weimer wrote:
> That can only happen if the embedded people do not bother to show up
> in
> numbers.  Of course the tools will move in different directions.

True (;

> > That's why the proposal by Herb is a real surprise and I really
> > hope
> > it could be implemented someday.
> 
> Would you use it if switching from -fno-exceptions to this new
> approach
> resulted in an immediate 20% code size increase, without actually
> using
> the new error handling feature at all?  What about 10%?

As I understand the proposal, it would basically boil down to returning
something like std::pair where XXX is what you return
explicitly in the code. Or sth like returning std::variant<> or
std::optional<>. I use these approaches in my own code all the time
(mostly std::pair, as it's the simplest one). The rest of the
proposal seems to be syntax sugar for catching this "HerbCeption" and
so on. As my code basically does the same now, I guess the increase for
me would be ~0%.

I perfectly understand that error handling has some non-zero cost and
the only way to avoid it is to completely ignore the errors (; But it
seems to me that what is proposed there is really very cheap and very
fast. As long as the committee will drop std::string and such from
std::error_code (;

With current C++ exceptions the increase is not very proportional to
the size of the rest of the application. It's more like a one-time ~60
kB increase, even if the application without it would be 5 kB total. In
a huge application the increase may be less noticeable, as parts of the
pulled code may be used anyway by the app (things like dynamic
allocation, fprintf() and so on), but this is still ~25% of total
available ROM size.

To summarize. Current C++ exceptions have very huge, mostly "one-time"
kind, cost on the size, even if not used at all by the user, mosly due
to std::terminate() and all the string handling code inside it, as well
as the unwind tables. The proposal by Herb seems to be more reasonable
in this regard - the amount of extra code generated under the hood will
probably be proportional to the amount of code involved and actually
similar to what C programmers do manually for decades.

Regards,
FCh

Re: size of exception handling (Was: performance of exception handling)

[Freddie Chopin]

On Mon, 2020-05-11 at 17:14 +0200, Moritz Strübe wrote:
> I just wanted to point out that Herbceptions do not only fix
> performance 
> issues, but also code-size problems. While anything below 4GB of RAM
> is 
> considered under-powered for a PC, typical deep embedded
> environments 
> have something around 32k of program memory and 2K of ram. And even 
> those running Linux often have around 32MB program memory and 8MB of 
> RAM. Also most of these systems are very cost sensitive, so each
> byte 
> matters. Therefore RTTI and exceptions are one of the main reasons
> why 
> parts of the embedded community consider C++ unusable: They do some 
> experiments using C++ and the code size explodes.  And even if you
> know 
> what you are doing and turn interrupts and RTTI off, adding a 
> std::nothrow to every "new" to do decent error handling is pretty 
> annoying. Not mentioning the parts of the C++ library that don't
> provide 
> exception-free error-handling.
> 
> So yes, improving the performance is nice, but ISO C++ will still be 
> unusable for most computer systems: There are way more emdedded
> systems 
> with less than 32MB program memory out there than PCs, Servers and 
> mobile phones together.

Very nice that Moritz finally mentioned it (; The world of deep
embedded is usually forgotten by all the language committees and people
who are in charge. That's why the proposal by Herb is a real surprise
and I really hope it could be implemented someday.

The numbers above are maybe a bit too strict. A typical ARM Cortex-M
chip can have up to 2 MB of ROM and 512 kB of RAM, but I would say that
usually it has around 128-256 kB of ROM and somewhere around 16-64 kB
of RAM. The problem with C++ exceptions is that even in the most
trivial of the programs and even if you don't explicitly
use/catch/throw them, they instantly eat around 60 kB of ROM and quite
a lot of RAM. With some hacking you can get down to about 20 kB of ROM
(by overriding a lot of string formatting code and overriding
std::terminate()), but this is still too much for a feature you
actually don't use.

I actually have to build my own toolchain instead of the one provided
by ARM, because to really NOT use C++ exceptions, you have to recompile
the whole libstdc++ with `-fno-exceptions -fno-rtti` (yes, I know they
provide the "nano" libraries, but I the options they used for newlib
don't suit my needs - this is "too minimized"). If you pass these two
flags during compilation and linking of your own application, this
disables these features only in your code. As libstdc++ is compiled
with exceptions and RTTI enabled, they get pulled during link anyway,
bloating the binary size with a functionality you don't use and can't
use - every throw from the library ends up as std::teminate() anyway.
That's why the statement by Herb that C++ exceptions are never zero-
cost when not used is perfectly true.

The performance is also an issue. Article I've read sometime ago
mentioned that a trivial throw out of a single function takes about
7000-1 clock cycles until it is catched, which is unacceptable for
any real-time solution (normal return with error handling would take at
most a few dozen). But the size issue is a blocker for deep embedded,
then the performance and deterministic behaviour are only secondary
issues in such environment.

Regards,
FCh

Re: LTO vs GCC 8

[Freddie Chopin]

On Tue, 2018-05-15 at 21:39 +0200, Freddie Chopin wrote:
> On Fri, 2018-05-11 at 18:51 +0200, Richard Biener wrote:
> > As to a workaround for the ld bug you can try keeping all .debug_*
> > sections. IIRC 2.30 has the bug fixed (on the branch). 
> 
> Indeed - "keeping" all the debug sections is a viable alternative.
> I've
> found out that it is enough to "keep" just these:
> 
>   /* DWARF 2 */
>   .debug_info 0 : { KEEP(*(.debug_info .gnu.linkonce.wi.*)); }
>...
>   .debug_frame 0 : { KEEP(*(.debug_frame)); }
> 
> I have to check whether debugging something like that is actually
> possible (; Thanks for the workaround!

Nope, sent it too fast... With these two (three) sections "kept" --gc-
sections stops working and the executable I get is almost identical to
the case when I have no --gc-sections at all:
- lto + --gc-sections, sections "kept" - 133504 ROM + 4196 RAM
- lto + --gc-sections, sections not "kept" (causes previously mentioned
errors) - 120288 ROM + 3676 RAM
- lto, sections not "kept" - 133812 ROM + 4220 RAM

So it seems I have to patiently wait for new binutils if I would like
to use LTO (;

Regards,
FCh

Re: LTO vs GCC 8

[Freddie Chopin]

On Mon, 2018-05-14 at 16:34 +0200, David Brown wrote:
> Interesting.  Making these sections and then using gc-sections should
> only remove code that is not used - LTO should do that anyway.

My guess - expressed in the other e-mail to the list - is that the
things LTO cannot remove but --gc-sections can are objects from
toolchain library.

> Have you tried with -ffunction-sections and not -fdata-sections?  It
> is
> the -fdata-sections that ruins -fsection-anchors - the
> -ffunction-sections doesn't have the same kind of cost.

Results:
- -ffunction-sections + -fdata-sections = 124396 ROM + 3484 RAM
- -ffunction-sections = 125168 ROM + 3676 RAM
- -ffunction-sections + -fsection-anchors = 125168 ROM + 3676 RAM
- -ffunction-sections + -fsection-anchors + -fno-common = 125168 ROM +
3676 RAM 

Generated executables for the second, third and fourth case are
identical - assembly listings for these three cases have no differences
at all.

I've also tried with -fno-section-anchors, and this makes a minor
(negative) difference - 125352 ROM + 3676 RAM.

> No, -fsection-anchors has plenty of use for fixed-position eabi code.
> ...
> The code is clearly bigger and slower, and uses more anchors in the
> code
> section.
> 
> Note that to get similar improvements with non-static data, you need
> "-fno-common" - a flag that I believe should be the default for the
> compiler.

I cannot reproduce this here ); Don't get me wrong - if there's a
"free" way to improve code size/speed with some compiler flags which I
did not use previously, then I'm very much interested, however in my
particular case the best result (size-wise) I get is with just
-ffunction-sections + -fdata-sections. The difference is not huge, but
it's also not negligible. Maybe this has to do with different compiler
versions we are comparing (4.8 vs 8.1)? I guess this is not LTO (which
I did not enable for these measurements), as you did not mention it in
your flags...

Regards,
FCh

Re: LTO vs GCC 8

[Freddie Chopin]

On Fri, 2018-05-11 at 18:51 +0200, Richard Biener wrote:
> That's an interesting result. Do you have any non-LTO objects?
> Basically I'm curious what ld eliminates that gcc with LTO doesn't. 

Whole project is compiled with LTO, part of the project is provided as
a library (which is archived with arm-none-eabi-gcc-ar). Only non-LTO
stuff in the final executable are objects from standard toolchain
libraries and I suppose they are the culprit here - the toolchain is
compiled with -ffunction-sections -fdata-sections, but without -flto.
Maybe I should actually compile the whole toolchain with -flto -ffat-
lto-objects? Is this a sane idea?

> As to a workaround for the ld bug you can try keeping all .debug_*
> sections. IIRC 2.30 has the bug fixed (on the branch). 

Indeed - "keeping" all the debug sections is a viable alternative. I've
found out that it is enough to "keep" just these:

/* DWARF 2 */
.debug_info 0 : { KEEP(*(.debug_info .gnu.linkonce.wi.*)); }
 ...
.debug_frame 0 : { KEEP(*(.debug_frame)); }

I have to check whether debugging something like that is actually
possible (; Thanks for the workaround!

Regards,
FCh

Re: LTO vs GCC 8

[Freddie Chopin]

On Fri, 2018-05-11 at 13:06 +0200, David Brown wrote:
> For the Cortex-M devices (and probably many other RISC targets),
> -fdata-sections comes at a big cost - it effectively blocks
> -fsection-anchors and makes access to file-static data a lot bigger.
> People often use -fdata-sections and -ffunction-sections along with
> -Wl,--gc-sections with the aim of removing unused code and data (and
> thus saving space, useful on small devices) - I would expect LTO
> would
> manage that anyway.  The other purpose of these is to improve
> locality
> of reference - again LTO should do that for you.  But even without
> LTO,
> I find the cost of -fdata-sections high compared to -fsection-
> anchors.

Unfortunatelly having LTO doesn't make -ffunction-sections + -fdata-
sections + --gc-sections useless.

My test project compiled:
- without LTO and without these attributes - 150824 B ROM + 4240 B RAM
- with LTO and without these attributes - 133812 B ROM + 4208 B RAM
- without LTO and with these attributes - 124456 B ROM + 3484 B RAM
- with LTO and with these attributes - 120280 B ROM + 3680 B RAM

As you see these attributes give much more than LTO in terms of size.

As for the -fsection-anchors I guess this has no use for non-PIC code
for arm-none-eabi. Whether I use it or not, the sizes are identical.

Regards,
FCh

Re: LTO vs GCC 8

[Freddie Chopin]

On Fri, 2018-05-11 at 11:19 +0200, Richard Biener wrote:
> Hmm, can you try without --gc-sections?  "Old" GNU ld versions have
> a bug that wrecks debug info (sourceware PR20882).

Yes - you are right. Without --gc-sections the errors are gone. The bug
was marked as resolved and fixed a year ago, however from the comments
I presume that it was only a partial fix, so possibly 2.31 will be
working fine for arm-none-abi, right?

What is also interesting is that there was no problem for gcc 7.3 with
binutils 2.29.1 and for gcc 6.3 with binutils 2.28 - only 8.1 + 2.30
behave like this.

Is there a workaround for the problem? Maybe I could mark some sections
as KEEP() in the linker script while waiting for binutils 2.31?

Regards,
FCh

LTO vs GCC 8

[Freddie Chopin]

Hi!

In one of my embedded projects I have an option to enable LTO. This was
working more or less fine for GCC 6 and GCC 7, however for GCC 8.1.0
(and binutils 2.30) - with the same set of options - I see something
like this

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

$ arm-none-eabi-g++ -Wall -Wextra -Wshadow -std=gnu++11 -mcpu=cortex-m4 
-mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -g -ggdb3 -O2 -flto -ffat-
lto-objects -fno-use-cxa-atexit -ffunction-sections -fdata-sections
-fno-rtti -fno-exceptions ... [include paths] ... -MD -MP -c
test/TestCase.cpp -o output/test/TestCase.o

$ arm-none-eabi-g++  -mcpu=cortex-m4 -mthumb -mfloat-abi=hard
-mfpu=fpv4-sp-d16 -g -O2 -flto -fuse-linker-plugin -Wl,-
Map=output/test/distortosTest.map,--cref,--gc-sections
-Toutput/ST_STM32F4DISCOVERY.preprocessed.ld ... [a lot of objects] ...
-Wl,--whole-archive -l:output/libdistortos.a -Wl,--no-whole-archive -o
output/test/distortosTest.elf

$ arm-none-eabi-objdump --demangle -S output/test/distortosTest.elf >
output/test/distortosTest.lss
arm-none-eabi-objdump: Dwarf Error: Could not find abbrev number 167.
arm-none-eabi-objdump: Dwarf Error: found dwarf version '37', this
reader only handles version 2, 3, 4 and 5 information.
arm-none-eabi-objdump: Dwarf Error: found dwarf version '6144', this
reader only handles version 2, 3, 4 and 5 information.
arm-none-eabi-objdump: Dwarf Error: found dwarf version '4864', this
reader only handles version 2, 3, 4 and 5 information.
...
... (a lot more)
...

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

As you see, the errors apear only when I try to generate an assembly
dump. I'm not sure whether the problem is in GCC or in objdump, but
when I have an .elf file produced (with the same options) by gcc 7.3.0,
then this new version of objdump doesn't produce any errors. What is
also interesting is that the errors are not fatal - the exit code of
the process is 0.

What is also interesing is that this problem doesn't appear in a
trivial test case, so I suspect this is something more subtle. I did
not try to narrow it down into a shareable test case, but if you have
no hints then maybe I'll try to do that.

Any ideas what may be the problem here? Especially do you know whether
I should be asking this question here or maybe on binutils mailing
list?

Thanks in advance!

Regards,
FCh

Re: Second GCC 8.1 Release Candidate available from gcc.gnu.org

[Freddie Chopin]

On Fri, 2018-04-27 at 23:39 +0200, Jakub Jelinek wrote:
> The second release candidate for GCC 8.1 is available from
> 
>  ftp://gcc.gnu.org/pub/gcc/snapshots/8.0.1-RC-20180427
> 
> and shortly its mirrors.  It has been generated from SVN revision
> 259731.
> 
> I have so far bootstrapped and tested the release candidate on
> x86_64-linux and i686-linux.  Please test it and report any issues to
> bugzilla.
> 
> If all goes well, I'd like to release 8.1 on Wednesday, May 2nd.

Hello!

I would like to bring this strange issue to your attention too.

https://sourceware.org/bugzilla/show_bug.cgi?id=23126#c3

This is not (at least not entirely) a GCC problem, but with previous
versions (back to GCC 5 at least) it was working fine, because GCC did
not explicitly set `.arch` directive in assembly files - just `.cpu`.

Regards,
FCh

Re: Bug or feature - merging linkage declarations from static forced-inline functions

[Freddie Chopin]

On Mon, 2018-04-30 at 15:38 -0400, Nathan Sidwell wrote:
> On 04/30/2018 03:21 PM, Jonathan Wakely wrote:
> > Nathan, is this a regression for this testcase? IIUC the local
> > types
> > and the local variables should have no linkage, and not conflict.
> > 
> 
> that does seem plausible.  Freddie, please file a bug

Here it is:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85580

Regards,
FCh

Re: Bug or feature - merging linkage declarations from static forced-inline functions

[Freddie Chopin]

Here's a minimal test case:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

$ cat test.cpp

extern "C"
{

void f1()
{
  union some_type{
char a[2];
int b;
  } variable;
}

void f2()
{
  union some_type{
char a[2];
int b;
  } variable;
}

}

$ arm-none-eabi-gcc test.cpp -c
test.cpp: In function 'void f2()':
test.cpp:17:5: warning: conflicting C language linkage declaration
'f2()::some_type variable'
   } variable;
 ^~~~
test.cpp:9:5: note: previous declaration 'f1()::some_type variable'
   } variable;
 ^~~~

$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (bleeding-edge-toolchain) 8.0.1 20180427 (prerelease)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

For the problem to appear:
- functions with the types and variables have to be extern "C"
- the file must be C++
- there has to be both a type and a variable
- the variables must have identical names

Any idea whether GCC is correct in this case or maybe the error is in
the headers?

Regards,
FCh

Bug or feature - merging linkage declarations from static forced-inline functions

[Freddie Chopin]

Hi!

I've compiled gcc 8.0.1-RC-20180427 to test it with my projects.
There's one new warning for which I cannot tell whether this is a bug
in headers or a bug in gcc.

I have a header from ARM that looks like this (there are more such
functions than these two):

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

#define __STATIC_FORCEINLINE   __attribute__((always_inline)) 
static inline
...
__STATIC_FORCEINLINE uint64_t __SMLALD (uint32_t op1, uint32_t op2, uint64_t 
acc)
{
  union llreg_u{
uint32_t w32[2];
uint64_t w64;
  } llr;
  llr.w64 = acc;

#ifndef __ARMEB__   /* Little endian */
  __ASM volatile ("smlald %0, %1, %2, %3" : "=r" (llr.w32[0]), "=r" 
(llr.w32[1]): "r" (op1), "r" (op2) , "0" (llr.w32[0]), "1" (llr.w32[1]) );
#else   /* Big endian */
  __ASM volatile ("smlald %0, %1, %2, %3" : "=r" (llr.w32[1]), "=r" 
(llr.w32[0]): "r" (op1), "r" (op2) , "0" (llr.w32[1]), "1" (llr.w32[0]) );
#endif

  return(llr.w64);
}

__STATIC_FORCEINLINE uint64_t __SMLALDX (uint32_t op1, uint32_t op2, uint64_t 
acc)
{
  union llreg_u{
uint32_t w32[2];
uint64_t w64;
  } llr;
  llr.w64 = acc;

#ifndef __ARMEB__   /* Little endian */
  __ASM volatile ("smlaldx %0, %1, %2, %3" : "=r" (llr.w32[0]), "=r" 
(llr.w32[1]): "r" (op1), "r" (op2) , "0" (llr.w32[0]), "1" (llr.w32[1]) );
#else   /* Big endian */
  __ASM volatile ("smlaldx %0, %1, %2, %3" : "=r" (llr.w32[1]), "=r" 
(llr.w32[0]): "r" (op1), "r" (op2) , "0" (llr.w32[1]), "1" (llr.w32[0]) );
#endif

  return(llr.w64);
}

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
https://github.com/ARM-software/CMSIS_5/blob/develop/CMSIS/Core/Include/cmsis_gcc.h#L1929

Important thing here is that I do _NOT_ use any of these functions in
the code - they are just in the headers.

However GCC behaves as if it would merge all these functions into one
code block (via copy & paste), so it sees all the
definitions/declarations of llr as conflicting:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

In file included from 
source/architecture/ARM/ARMv6-M-ARMv7-M/external/CMSIS/cmsis_compiler.h:48,
 from 
source/architecture/ARM/ARMv6-M-ARMv7-M/external/CMSIS/core_cm4.h:162,
 from 
source/chip/STM32/STM32F4/external/CMSIS-STM32F4/stm32f407xx.h:183,
 from 
source/chip/STM32/STM32F4/external/CMSIS-STM32F4/stm32f4xx.h:151,
 from 
source/chip/STM32/STM32F4/include/distortos/chip/CMSIS-proxy.h:69,
 from 
source/architecture/ARM/ARMv6-M-ARMv7-M/ARMv6-M-ARMv7-M-requestFunctionExecution.cpp:16:
source/architecture/ARM/ARMv6-M-ARMv7-M/external/CMSIS/cmsis_gcc.h: In function 
'uint64_t __SMLALDX(uint32_t, uint32_t, uint64_t)':
source/architecture/ARM/ARMv6-M-ARMv7-M/external/CMSIS/cmsis_gcc.h:1947:5: 
warning: conflicting C language linkage declaration '__SMLALDX(uint32_t, 
uint32_t, uint64_t)::llreg_u llr'
   } llr;
 ^~~
In file included from 
source/architecture/ARM/ARMv6-M-ARMv7-M/external/CMSIS/cmsis_compiler.h:48,
 from 
source/architecture/ARM/ARMv6-M-ARMv7-M/external/CMSIS/core_cm4.h:162,
 from 
source/chip/STM32/STM32F4/external/CMSIS-STM32F4/stm32f407xx.h:183,
 from 
source/chip/STM32/STM32F4/external/CMSIS-STM32F4/stm32f4xx.h:151,
 from 
source/chip/STM32/STM32F4/include/distortos/chip/CMSIS-proxy.h:69,
 from 
source/architecture/ARM/ARMv6-M-ARMv7-M/ARMv6-M-ARMv7-M-requestFunctionExecution.cpp:16:
source/architecture/ARM/ARMv6-M-ARMv7-M/external/CMSIS/cmsis_gcc.h:1930:5: 
note: previous declaration '__SMLALD(uint32_t, uint32_t, uint64_t)::llreg_u llr'
   } llr;
 ^~~

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

Now my question is - who is right here: are the headers correct nad gcc
 wrong, or are the headers wrong and gcc right? This code was warning
free for previous versions of gcc. I'm asking because I'm not sure
where should I file the bug - in ARM CMSIS or in gcc's bugzilla.

Regards and thanks for info,
FCh

Re: gcc Bugzilla corrupt again?

[Freddie Chopin]

On Thu, 2017-11-23 at 06:51 +, Andrew Roberts wrote:
> But I've never seen it take me to a different bug after adding a
> comment 
> before.

>From my experience, this is normal - after you perform any operation on
particular bug, it then takes you to the next bug on your "my bugs"
list. Probably it did not happen to you in the past, as you had only
one bug on that list.

But I agree that this is extremely confusing behaviour...

Regards,
FCh

Re: C++ xgcc for arm-none-eabi fails in 7.1, 7.2 due to undefined identifiers

[Freddie Chopin]

On Fri, 2017-08-18 at 11:17 -0500, R0b0t1 wrote:
> Just to check, this is actually an
> arm-none-eabi toolchain? I looked over the compilation flags and it
> looks like it supports all Cortex-M processor features like such a
> toolchain should. Most instructions I could find seemed to build a
> more restricted toolchain.

The toolchain you get from this script supports - in case of GCC 7 -
following multilibs:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

$ arm-none-eabi-gcc -print-multi-lib
.;
thumb;@mthumb
hard;@mfloat-abi=hard
thumb/v6-m;@mthumb@march=armv6s-m
thumb/v7-m;@mthumb@march=armv7-m
thumb/v7e-m;@mthumb@march=armv7e-m
thumb/v7-ar;@mthumb@march=armv7
thumb/v8-m.base;@mthumb@march=armv8-m.base
thumb/v8-m.main;@mthumb@march=armv8-m.main
thumb/v7e-m/fpv4-sp/softfp;@mthumb@march=armv7e-m@mfpu=fpv4-sp-d16@mfloat-abi=softfp
thumb/v7e-m/fpv4-sp/hard;@mthumb@march=armv7e-m@mfpu=fpv4-sp-d16@mfloat-abi=hard
thumb/v7e-m/fpv5-sp/softfp;@mthumb@march=armv7e-m@mfpu=fpv5-sp-d16@mfloat-abi=softfp
thumb/v7e-m/fpv5-sp/hard;@mthumb@march=armv7e-m@mfpu=fpv5-sp-d16@mfloat-abi=hard
thumb/v7e-m/fpv5/softfp;@mthumb@march=armv7e-m@mfpu=fpv5-d16@mfloat-abi=softfp
thumb/v7e-m/fpv5/hard;@mthumb@march=armv7e-m@mfpu=fpv5-d16@mfloat-abi=hard
thumb/v7-ar/fpv3/softfp;@mthumb@march=armv7@mfpu=vfpv3-d16@mfloat-abi=softfp
thumb/v7-ar/fpv3/hard;@mthumb@march=armv7@mfpu=vfpv3-d16@mfloat-abi=hard
thumb/v8-m.main/fpv5-sp/softfp;@mthumb@march=armv8-m.main@mfpu=fpv5-sp-d16@mfloat-abi=softfp
thumb/v8-m.main/fpv5-sp/hard;@mthumb@march=armv8-m.main@mfpu=fpv5-sp-d16@mfloat-abi=hard
thumb/v8-m.main/fpv5/softfp;@mthumb@march=armv8-m.main@mfpu=fpv5-d16@mfloat-abi=softfp
thumb/v8-m.main/fpv5/hard;@mthumb@march=armv8-m.main@mfpu=fpv5-d16@mfloat-abi=hard

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

That means you can use all ARM Cortex-M chips, with or without FPU, 32-
bit or 64-bit. You can also use ARM Cortex-R and "classic" ARM7TDMI.

This is the same set of architectures you get from the toolchain
provided by ARM.

> I have looked at the supporting blog posts and read the documentation
> available.

The blog post is really old and the part about performance is mostly
obsolte (;

> I still do not understand why the specific binutils, gcc,
> newlib, and gdb configurations were chosen, and why what is
> ostensibly
> the same configuration failed when I tried it Would you please take
> the time to document them, or point me towards a place that describes
> what I should be looking for and why? I don't mind reading but I do
> not know why the choices made are the correct ones and have been
> unable to find anywhere that starts to offer any explanation.

Generally I used the most recent components which are available for
download.

In the past - up to and including GCC 6 - the only exception were the
cases of supporting libraries (stuff like isl, mpfr, ...), where
_sometimes_ gcc docs say you must use a release from range x-y, not the
most recent one. In that case the most recent package from the range is
chosen. However the file gcc-7.2.0/gcc/doc/install.texi always says
"version x (or later)" so... I use the most recent one (; After all,
this is a "bleeding-edge" toolchain (;

Sometimes the version may be a bit older than the most recent one
either because I forgot to check, or because the most recent one has
some problems. This is the case for the most recent newlib snapshot
which fails to build for ARM - that's why I had to use a previous one.

Regards,
FCh

Re: C++ xgcc for arm-none-eabi fails in 7.1, 7.2 due to undefined identifiers

[Freddie Chopin]

I forgot to say, that the procedure and resulting toolchain is closely
modeled after the one provided by ARM on:

https://developer.arm.com/open-source/gnu-toolchain/gnu-rm

It just has couple of tweaks like slightly different options for
newlib, completely disabled C++ exceptions and uses the most recent
versions of components.

Regards,
FCh

Re: C++ xgcc for arm-none-eabi fails in 7.1, 7.2 due to undefined identifiers

[Freddie Chopin]

On Thu, 2017-08-17 at 22:27 -0500, R0b0t1 wrote:
> On Thu, Aug 17, 2017 at 4:44 PM, R0b0t1  wrote:
> > When compiling libssp, ssp.c, function __guard_setup:
> > O_RDONLY is undeclared (ssp.c:93:34),
> > ssize_t is an unknown type name (ssp.c:96:7), and
> > size_t is an unknown type name (ssp.c:113:25).
> > 
> > ../../src/gcc-7.2.0/configure --target=$TARGET --prefix=$PREFIX
> > --with-cpu=cortex-m4 --with-fpu=fpv4-sp-d16 --with-float=hard
> > --with-mode=thumb --enable-multilib --enable-interwork
> > --enable-languages=c,c++ --with-system-zlib --with-newlib
> > --disable-shared --disable-nls --with-gnu-as --with-gnu-ld
> > 
> > A bootstrap C compiler is generated properly when passing --
> > without-headers.
> > 
> > I can provide more details and command output. Recently I was able
> > to
> > get 6.3.0 as close to working with Newlib 2.5 as I can tell, so
> > this
> > is not extremely urgent. Unfortunately I may have other questions
> > about earlier GCC versions.
> > 
> 
> I attempted to reproduce my build of GCC 6.3 and it's no longer
> working. Both builds on Kubuntu 17.04.
> 
> I'm kind of lost. Should I be filing bugs?
> 
> > Any suggestions related to generating cross toolchains,
> > specifically
> > generating a toolchain close to the one found at
> > https://developer.arm.com/open-source/gnu-toolchain/gnu-rm, would
> > be
> > extremely helpful. Any help provided will be used to better support
> > for generating toolchains with the crossdev project.
> > 
> > I am very confused and what I want to do seems to be poorly
> > documented.
> > 
> > Thanks in advance,
> >  R0b0t1.

Here you may find a complete script which builds the most recent
versions of the toolchain for arm-none-eabi. If you browse git history
you will also find a version for GCC 6.3.

https://github.com/FreddieChopin/bleeding-edge-toolchain

Regards,
FCh

note: parameter passing for argument of type '...' changed in GCC 7.1?

[Freddie Chopin]

Hello!

I've got a project which - when compiled with "arm-none-eabi" GCC 7.1
without optimizations - produces quite a lot of such messages:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

In file included from 
../../include/distortos/internal/scheduler/SoftwareTimerList.hpp:17:0,
 from 
../../include/distortos/internal/scheduler/SoftwareTimerSupervisor.hpp:15,
 from SoftwareTimerSupervisor.cpp:12:
../../include/estd/SortedIntrusiveList.hpp: In static member function 'static 
estd::SortedIntrusiveList::iterator 
estd::SortedIntrusiveList::erase(estd::SortedIntrusiveList::iterator) 
[with Compare = distortos::internal::SoftwareTimerAscendingTimePoint; T = 
distortos::internal::SoftwareTimerListNode; estd::IntrusiveListNode T::* 
NodePointer = ::internal::SoftwareTimerListNode::node; U = 
distortos::internal::SoftwareTimerControlBlock]':
../../include/estd/SortedIntrusiveList.hpp:257:18: note: parameter passing for 
argument of type 'const iterator {aka const 
estd::IntrusiveListIterator}' changed in GCC 7.1
  static iterator erase(const iterator position)
  ^
...
In file included from 
/home/freddie/arm-none-eabi-gcc-7.1.0-170503/arm-none-eabi/include/c++/7.1.0/bits/stl_algobase.h:71:0,
 from 
/home/freddie/arm-none-eabi-gcc-7.1.0-170503/arm-none-eabi/include/c++/7.1.0/bits/char_traits.h:39,
 from 
/home/freddie/arm-none-eabi-gcc-7.1.0-170503/arm-none-eabi/include/c++/7.1.0/ios:40,
 from 
/home/freddie/arm-none-eabi-gcc-7.1.0-170503/arm-none-eabi/include/c++/7.1.0/ostream:38,
 from 
/home/freddie/arm-none-eabi-gcc-7.1.0-170503/arm-none-eabi/include/c++/7.1.0/iterator:64,
 from ../../include/estd/IntrusiveList.hpp:15,
 from 
../../include/distortos/internal/scheduler/SoftwareTimerListNode.hpp:17,
 from 
../../include/distortos/internal/scheduler/SoftwareTimerList.hpp:15,
 from 
../../include/distortos/internal/scheduler/SoftwareTimerSupervisor.hpp:15,
 from SoftwareTimerSupervisor.cpp:12:
/home/freddie/arm-none-eabi-gcc-7.1.0-170503/arm-none-eabi/include/c++/7.1.0/bits/predefined_ops.h:
 In member function 'bool 
__gnu_cxx::__ops::_Iter_pred<_Predicate>::operator()(_Iterator) [with _Iterator 
= estd::IntrusiveListIterator; _Predicate = 
estd::SortedIntrusiveList::Implementation::findInsertPosition(estd::SortedIntrusiveList::const_reference) [with Compare = 
distortos::internal::SoftwareTimerAscendingTimePoint; T = 
distortos::internal::SoftwareTimerListNode; estd::IntrusiveListNode T::* 
NodePointer = ::internal::SoftwareTimerListNode::node; U = 
distortos::internal::SoftwareTimerControlBlock]::]':
/home/freddie/arm-none-eabi-gcc-7.1.0-170503/arm-none-eabi/include/c++/7.1.0/bits/predefined_ops.h:282:2:
 note: parameter passing for argument of type 
'estd::IntrusiveListIterator' changed in GCC 7.1
  operator()(_Iterator __it)
  ^~~~

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

Some of the messages (like the first one above) are triggered by my
code, but some of them (like the second one above) are coming from
within libstdc++ headers.

As I mentioned earlier, the messages appear only if -O0 is selected -
for any other optimization level the messages are gone.

The problem here is that I have absolutely no idea what this message is
supposed to mean (; Should I somehow fix/change/improve the code? If
possible, I would like to change my code so that it doesn't trigger any
such notes, as this is very confusing for the users...

I tried searching for some more info, but just found a thread on this
mailing list with a patch that introduces these messages, however I did
not really understand how it relates to my code...

Thanks in advance for any info!

Regards,
FCh

Re: add GCC 7.1 to Bugzilla?

[Freddie Chopin]

On Thu, 2017-05-04 at 15:01 -0600, Martin Sebor wrote:
> Now that GCC 7.1 has been released, should 7.1 be added
> to the versions in Bugzilla so that bugs can be assigned
> the right version?  (I'm using 7.0 in the meantime.)
> 
> Or is there someone not on this list I might need to bug
> with this request?

There already is 7.1.0 and 7.1.1 in the list.

Regards,
FCh

Re: GCC 7, aligned_storage and “dereferencing type-punned pointer will break strict-aliasing rules”

[Freddie Chopin]

On Tue, 2017-05-02 at 12:17 +0200, Richard Biener wrote:
> But this shows
> an issue with GCC 7 so please open a bugreport.

Here it is - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80593

Regards,
FCh

GCC 7, aligned_storage and “dereferencing type-punned pointer will break strict-aliasing rules”

[Freddie Chopin]

Hello!

A code that I wrote was warning-free in GCC 4.9, GCC 5 and GCC 6. It
was also warning-free with some older GCC 7 experimental snapshots (for
example 7-20170409). But in the most recent snapshot (including the
first RC), it started to produce a warning about aliasing. The code
basically boils down to this:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

#include 

std::aligned_storage::type storage;

int main()
{
*reinterpret_cast() = 42;
}

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

Compilation with latest GCC 7 RC:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

$ g++ -Wall -O2 -c main.cpp
main.cpp: In function 'int main()':
main.cpp:7:34: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
  *reinterpret_cast() = 42;

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

(interesting observation is that the warning is not produced when
optimizations are disabled)

Compilation with GCC 6 gives no warnings at all.

Now I'm wondering, the code above definitely HAS type-punning, no
question about that, but isn't std::aligned_storage meant to be used
that way?

For instance the example code given here on cppreference generally
produces no warning with GCC 7 but only because:
- std::string somehow is not affected,
- std::aligned_storage is accessed with an offset.

http://en.cppreference.com/w/cpp/types/aligned_storage

By changing std::string into int, removing offset access to
std::aligned_storage and removing irrelevant parts you get this:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

#include 
#include 
#include 

template
class static_vector
{
// properly aligned uninitialized storage for N T's
typename std::aligned_storage::type data[N];
std::size_t m_size = 0;

public:

// Access an object in aligned storage
const T& operator[](std::size_t pos) const
{
return *reinterpret_cast(data/*+pos*/); // <- note
here, offset access disabled
}
};

int main()
{
static_vector v1;
std::cout << v1[0] << '\n' << v1[1] << '\n';
}

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

And this produces exactly the same warning:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

main.cpp: In instantiation of 'const T& static_vector::operator[](std::size_t) const [with T = int; unsigned int N = 10;
std::size_t = unsigned int]':
main.cpp:24:22:   required from here
main.cpp:17:16: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
 return *reinterpret_cast(data/*+pos*/);
^

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

So my question is - is this a bug or a feature?

Thanks in advance!

Regards,
FCh

BTW - I've also posted this question on stackoverflow
http://stackoverflow.com/questions/43711567/gcc-7-aligned-storage-and-dereferencing-type-punned-pointer-will-break-strict