Arch Linux

How to reproduce the issue? Do you have a simple *.c that shows the problem with current avr-gcc?

I currently have no simple c file, but you can reproduce this with the arduino ide.

* Install the current arduino AUR package.
* Set this line of platform.txt to /usr/bin/ https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/platform.txt#L21
* Compile a sketch and test if that works in general
* You can then try the software serial example which throws the error. It can be found in file>examples>softwareserial>softwareserialexample

To debug this issue you should also remove all flags that contain "lto" in platform.txt then you do not get the segmentation fault, but the real error instead. You also want to turn on verbose output and compiler warnings in the preferences to see which compiler is used.

I once got a working avr-gcc build with the following settings:
${srcdir}/${_basedir}/configure \
--disable-install-libiberty \
--disable-libssp \
--disable-libstdcxx-pch \
--disable-libunwind-exceptions \
--disable-linker-build-id \
--disable-nls \
--disable-werror \
--disable-__cxa_atexit \
--enable-checking=release \
--enable-clocale=gnu \
--enable-gnu-unique-object \
--enable-gold \
--enable-languages=c,c++ \
--enable-lto \
--infodir=/usr/share/info \
--libdir=/usr/lib \
--libexecdir=/usr/lib \
--mandir=/usr/share/man \
--prefix=/usr \
--target=avr \
--with-as=/usr/bin/avr-as \
--with-gnu-as \
--with-gnu-ld \
--with-ld=/usr/bin/avr-ld \
--with-plugin-ld=ld.gold \
--with-system-zlib \
--with-isl

But you always need to do a clean build. Remove the whole "src" folder and then recompile. Otherwise the normal build worked for me afterwards. I also had some warnings that my package links to my src directory. I do not know why, I have not debugged this further. You should have a working avr-gcc and a not working setting now. One of the settings I left out should cause the problem. As you've possibly seen on the mailing list I am offline for a few weeks, otherwise I'd try this myself.

I hope that was enough information in the short time. If not I can debug this when I am back.

@anatolik I could solve the issue partly. Details can be found here:
https://github.com/arduino/Arduino/issues/660#issuecomment-251142922

I need you to rebuild the package with `--disable-__cxa_atexit` as a compile option. It would be nice if you know why this was enabled. If not we should possibly just disable it, as it causes the mentioned problem and no other distribution has it enabled as i've seen this so far.

The LTO bug is possibly an gcc 6.x problem and not the configuration. I've no idea to debug this yet, but the workaround for the cpp flags would make arduino work for now. Maybe we should report this upstream at the gcc bugtracker. But I have very few compiler compilation knowledge, so I cannot really tell whats going on.

> It would be nice if you know why this was enabled.
AFAIK This flag is enabled by default.


Here is a bit more info http://www.avrfreaks.net/comment/302231#comment-302231

[quote]
This is due to that the default option for _cxa_atexit has changed in gcc 4.2.1. _cxa_atexit is dependent on implementation of the _cxa_atexit function in the C-library that is used.
In GCC 4.2.x release notes it says:
"The configure variable enable-__cxa_atexit is now enabled by default for more targets. Enabling this variable is necessary in order for static destructors to be executed in the correct order, but it depends upon the presence of a non-standard C library in the target library in order to work. The variable is now enabled for more targets which are known to have suitable C libraries."
uClibc 0.9.28 does not have _cxa_atexit, but 0.9.29 does have it. Newlib has _cxa_atexit.
Solution is to explicit enable or disable _cxa_atexit when configuring gcc for the actual target and C-library.
[/quote]

It might be that avr-libc does not have __cxa_atexit function.

Also, what do you see if you try to compile your code using original gcc package with -fno-use-cxa-atexit option.

If I add -fno-use-cxa-atexit as cpp flag the code compiles fine (without lto). With LTO I still need the extra flag. So the compile time switch does the same as if I'd rebuild avr-gcc. Maybe the avr-libc is outdated?

Edit: also found the issue here: https://github.com/amperka/ino/issues/180

avr-libc uptodate but it just dot implement _cxa_atexit. I guess I need to use --disable-__cxa_atexit to avoid the issue.

But the LTO issue is still there (which is caused by disabling the cxa exit it seems). We should possibly file a bug at avr-libc?

Yeah, avr-libc maillist is a great starting point for this issue discussing.

avr-gcc-6.2.0-2 has been pushed to [testing]. Please check it.

Is there also a configure option for the -fno-devirtualize flag which we also could include?

The "download from mirror" link is not available here and I've not setup a vm with testing yet where arduino would built like this.
https://www.archlinux.org/packages/community-testing/x86_64/avr-gcc/

The new avr-gcc works as expected equal to the flag `-fno-use-cxa-atexit`. However I still need `-fno-devirtualize` which misses some optimization I think. I've reported this at the avr-libc mailing list, but joerg also has no idea how to fix it. He would add a missing cxa_exit() if someone tells him how to. I think the best idea is to file a bug at gcc?

What I'd like is to enable it again, but fix the issue we have with LTO.

Hi folks, what is the current state of this issue?

That is a good question, its been a long time now. I've tried to investigate again:

"--disable-__cxa_atexit" Seems to solve the first part of the issue.
`-fno-devirtualize` seems to be not required anymore. Any problematic code is compiling now without the patch. I do not exactly know why it works now, but I will remove the patch from the avr-core and we can close this issue.