AVR Freaks

Hmm... the execute file attributes aren't preserved in the .zip:

$ find -type f -executable
$

Comparing against Atmel's 3.6.2 toolchain:

$ find -type f -executable
./x86_64-pc-linux-gnu/avr/lib/libopcodes.la
./x86_64-pc-linux-gnu/avr/lib/libbfd.la
./libexec/gcc/avr/5.4.0/install-tools/fixincl
./libexec/gcc/avr/5.4.0/install-tools/mkheaders
./libexec/gcc/avr/5.4.0/install-tools/mkinstalldirs
./libexec/gcc/avr/5.4.0/install-tools/fixinc.sh
./libexec/gcc/avr/5.4.0/cc1
./libexec/gcc/avr/5.4.0/plugin/gengtype
./libexec/gcc/avr/5.4.0/collect2
./libexec/gcc/avr/5.4.0/liblto_plugin.so.0.0.0
./libexec/gcc/avr/5.4.0/cc1plus
./libexec/gcc/avr/5.4.0/liblto_plugin.la
./libexec/gcc/avr/5.4.0/lto-wrapper
./libexec/gcc/avr/5.4.0/lto1
./avr/bin/ld.bfd
./avr/bin/objcopy
./avr/bin/strip
./avr/bin/as
./avr/bin/ld
./avr/bin/objdump
./avr/bin/ar
./avr/bin/nm
./avr/bin/readelf
./avr/bin/ranlib
./bin/avr-g++
./bin/avr-objdump
./bin/avr-strings
./bin/avr-strip
./bin/avr-ranlib
./bin/avr-c++
./bin/avr-gcov-tool
./bin/avr-cpp
./bin/avr-gcc-nm
./bin/avr-ld.bfd
./bin/avr-gdb
./bin/avr-gcc
./bin/avr-gcc-ar
./bin/avr-gcc-5.4.0
./bin/avr-c++filt
./bin/avr-gdb-py
./bin/avr-gcc-ranlib
./bin/avr-gprof
./bin/avr-nm
./bin/avr-man
./bin/avr-ld
./bin/avr-size
./bin/avr-as
./bin/avr-objcopy
./bin/avr-ar
./bin/avr-gcov
./bin/avr-addr2line
./bin/avr-elfedit
./bin/avr-readelf
./lib64/libcc1.so.0.0.0
./lib64/libcc1.la
./lib/gcc/avr/5.4.0/plugin/libcc1plugin.la
./lib/gcc/avr/5.4.0/plugin/libcc1plugin.so.0.0.0
$

Just to be sure I wasn't driving my unzipper incorrectly:

$ zipinfo avr-gcc-10.0.0_2020-01-14_x86-linux64.zip | grep ^.rw. | head
-rw----     1.0 fat        0 bx stor 20-Jan-14 16:51 gcc-10-strip/
-rw----     1.0 fat        0 b- stor 20-Jan-14 16:51 gcc-10-strip/include/
-rw----     1.0 fat        0 b- stor 20-Jan-14 16:51 gcc-10-strip/libexec/
-rw----     1.0 fat        0 b- stor 20-Jan-14 16:51 gcc-10-strip/libexec/gcc/
-rw----     1.0 fat        0 b- stor 20-Jan-14 16:51 gcc-10-strip/libexec/gcc/avr/
-rw----     1.0 fat        0 b- stor 20-Jan-14 16:53 gcc-10-strip/libexec/gcc/avr/10.0.0/
-rw----     2.0 fat   104080 bl defN 20-Jan-14 16:53 gcc-10-strip/libexec/gcc/avr/10.0.0/liblto_plugin.so
-rw----     2.0 fat 18781992 bl defN 20-Jan-14 16:53 gcc-10-strip/libexec/gcc/avr/10.0.0/lto1
-rw----     2.0 fat   104080 bl defN 20-Jan-14 16:53 gcc-10-strip/libexec/gcc/avr/10.0.0/liblto_plugin.so.0.0.0
-rw----     2.0 fat  1107376 bl defN 20-Jan-14 16:53 gcc-10-strip/libexec/gcc/avr/10.0.0/lto-wrapper
$

$ zipinfo avr-gcc-10.0.0_2020-01-14_x86-linux64.zip | grep ^...x
$

I could manually re-instate via chmod based on 3.6.2, but that would be tedious.

Is't possible to re-zip (or tarball) your Linux build?

Thanks.

I've grabbed it, and tried it out on some test code for a current project.  Although FP isn't necessary for the test code, it simplifies some things for now.  Certainly 64-bit doubles are not necessary, but I tried out your build as a drop-in replacement for 3.6.2.  No obvious issues.  I had to add -Wno-error=implicit-fallthrough to allow a build (I have a case which deliberately falls through to the next case), but that was it.  For the below tests I changed the case to avoid the fallthrough.

Code size is quite a bit larger, even with the default FP behaviour (double = 32 bit):

-O3

3.6.2: 8,430 bytes

10.0.0: 10,122 bytes

-Os

3.6.2: 7,538 bytes

10.0.0: 8,138 bytes

Switching to long double on 10.0.0, of course, yields even larger code:

-O3: 13,376 bytes

-Os: 11,432 bytes

I realise some of the increase in code size will be due to bug fixes and now-correct behaviour, and the increase for -O3 might be justified based on cycles (I didn't check), but I would have expected an overall improvement for -Os, not an 8% fattening.

Of course this is just one piece of test code, and a piece not very carefully crafted, so this is not a very meaningful result.  However, it does seem to fit the trend I've noticed over the last several releases of the Atmel toolchain.  No doubt some of this is due to changes in the compiler make to benefit other targets, but which have the side effect of negatively affecting the AVR backend.  After all, it is apparently not long for this world...

In any event, my untargetted test of 64-bit FP seems to work as expected.