Update avr toolchain to Atmel 3.5.3 and avrdude to 6.3

[cmaglie]

Updated tools:

• binutils-2.26
• gcc-4.9.2
• avr-libc-2.0.0
• gdb-7.8
• avrdude 6.3

[NicoHood]

Does it also enable LTO?

[cmaglie]

Does it also enable LTO?

aehm... I don't know :-)

is the LTO support compiled in the toolchain by default? or it needs some extra configuration parameter? In the latter case then, no, it must be enabled.

here the build scripts:
arduino/toolchain-avr#33

I remember that @facchinm did something with LTO maybe he can give some hints?

[Chris--A]

I'll give this a whirl soon.

Interesting to see what differences appear between gcc 4.8.1 and 4.9.2

[harryboo]

The new toolchain is working but has no LTO support.

Also there are some enhancements in the compiler so that some libs wont compile.
I got this to work with the additional switch -fpermissive.

The included avr-libc has buildin time support. This conflicts with other library time implementations.

The code is much smaller.

Is it possible to have more than 1 toolchain (like the custom toolchain with gcc6.1) and select them via the ui?

Thanx

[darrylp1per]

is it really wise to add this ?

Added -fpermissive flag.    16405a1 

the code in the libs should be fixed. the compiler warning us about bad code is agood thing.

[cmaglie]

It seems that gcc 4.9.2 has tightened the checks and some of the (former) warnings are now turned into errors, the result is that a number of libraries stopped working. This forces us to set the flag at least until we understand the impact of this change.

From the gcc manpage I see:

       -fpermissive
           Downgrade some diagnostics about nonconformant code from errors to warnings.
           Thus, using -fpermissive allows some nonconforming code to compile.

so -fpermissive does not remove the warnings, but turns some of the new errors back into warnings. Maybe not ideal, but at least allows for a soft transition period.

[harryboo]

@darrylp1per:

The compiler tells us about ill formed code not bad code.
If this flag is not there the team will get more and more requests why the old code doesnt work.

[harryboo]

Hi,

as i wrote LTO with only the changes in the platform.txt is not working.

You will get this error:
cc1.exe: error: -fno-fat-lto-objects are supported only with linker plugin

If you remove this entry you will get this error:
arduino-PR-5021-BUILD-563\hardware\tools\avr/bin/avr-gcc-ar: Cannot find plugin 'liblto_plugin-0.dll'

It seems that the toolchain is not build with LTO support.
Please remove this.

[cmaglie]

as i wrote LTO with only the changes in the platform.txt is not working.

I've replaced also the toolchain:
0290830

this one have LTO support compiled in. (here the changes to the build script arduino/toolchain-avr@cd131c7)

From our preliminar tests we see that LTO is working well, so I've made it the default for this build.
Let's see how it goes and if it's the case to remove it before merging.

[cmaglie]

You will get this error:
cc1.exe: error: -fno-fat-lto-objects are supported only with linker plugin

@harryboo I've tried the windows build and indeed it produces the error you reported, the other builds instead works as expected. There is still something to work on...

[ArduinoBot]

✅ Build completed.

Please test this code using one of the following:

⬇️ http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-5021-BUILD-566-linux32.tar.xz
⬇️ http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-5021-BUILD-566-linux64.tar.xz
⬇️ http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-5021-BUILD-566-windows.zip
⬇️ http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-5021-BUILD-566-macosx.zip
⬇️ http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-5021-BUILD-566-linuxarm.tar.xz

ℹ️ The linuxarm build is still experimental and may not be always available.

[harryboo]

Hi,

it seems it is working now also with windows builds. Let me check some more tonight.

Thanx

[arjenhiemstra]

Looks good on mac os x and also compiles again the code mentioned in bug #2752 now avr lib 2.0.0 is included

[PaoloP74]

Toolchain 3.5.3 available.

[cmaglie]

@PaoloP74
Thank for the nitification, I've updated the toolchain: https://github.com/arduino/toolchain-avr/commits/atmel-3.5.3

ArduinoBot should produce a build shortly.

[ArduinoBot]

✅ Build completed.

Please test this code using one of the following:

⬇️ http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-5021-BUILD-579-linux32.tar.xz
⬇️ http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-5021-BUILD-579-linux64.tar.xz
⬇️ http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-5021-BUILD-579-windows.zip
⬇️ http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-5021-BUILD-579-macosx.zip
⬇️ http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-5021-BUILD-579-linuxarm.tar.xz

ℹ️ The linuxarm build is still experimental and may not be always available.

[aethaniel]

Sorry coming late on this but I would like to know if the avrdude has been built against the 6.3 release tag or from trunk.
This release brought the support of mEDBG from Atmel AVR Xplained minis but wasn't working on Windows and OSX. This issue has been fixed in trunk meanwhile.

[cmaglie]

It's from 6.3, not trunk.

[cmaglie]

It seems that avrdude-6.3 is creating a lot of problems with the burn-bootloader command, here a bunch of issues that people are experiencing since the release of the IDE 1.6.10:

avrdude 6.3 issues

It seems that a proper fix is something that cannot be expected soon becuase it requires a fix in avrdude code and needs extensive testing with a lot of different AVR-programmers that may be not available at hand.

At this point we are wondering to revert to avrdude 6.0.1 for the coming IDE 1.6.11, and wait until avrdude has all the issues sorted out (hopefully with a 6.4 release).

The avrdude-6.3-arduino2 will continue to be available in the package_index.json for 3rd party to continue experimentation.

Please let me know your thoughts.

@per1234 @matthijskooijman @PaulStoffregen @descampsa @markaswift @awatterott @logicaprogrammabile @johbell @meoudon @PaoloP74 @Testato @NicoHood

[PaulStoffregen]

no opinion really since I don't use avrdude, but stable sounds good

[gh-megabit]

I came across this when I was playing with later avrdude builds some time ago. It looked like avrdude was moving closer to what the atmega datasheets say in terms of how unused/reserved efuse bits should be reported: 1.

Can we not send the efuse bits to avrdude in a more "correct" way? Logical OR 0xF8 (previously said 3E...not sure where that came from)

Lots of people who use this functionality are moving to ATMEL-ICE and it would be good to keep that supported.

[cmaglie]

Can we not send the fuse bits to avrdude in a more "correct" way? Logical OR 0x3E?

Unfortunately not, because that means putting a parsing logic into the IDE (read fuse from config files -> do AND with 0x3E (or other constants depending on the fuse?) -> replace value), we have removed almost all the "magic" from the IDE, in favor of configurations, and we don't want to go back on that.

[gh-megabit]

Ok I see why that is the case.

Is it just the efuse that's causing this?

I'm not convinced we'll see avrdude change this behaviour back so I'm keen to look at all options.

[matthijskooijman]

Can we not send the fuse bits to avrdude in a more "correct" way? Logical OR 0x3E?

Actually, changing it in avrdude like this (ignoring unused bits) is the "proper fix" @cmaglie was referring to. @facchinm created an avrdude patch for that, but it needs more work, testing and preferably review from people more involved with avrdude to consider applying it to the Arduino avrdude version already.

[matthijskooijman]

I came across this when I was playing with later avrdude builds some time ago. It looked like avrdude was moving closer to what the atmega datasheets say in terms of how unused/reserved efuse bits should be reported: 1.

This is indeed what avrdude is doing, which seems good. The obvious fix here seems to be to change boards.txt to use 1s for unused bits too, which would indeed work (for some programmers, a patch to avrdude is needed for some other programmers). However, this leaves third-party boards hanging, since they also need to update their fuse values which means that a lot of third-party boards will be broken for a while until they update, and once they update they'll be broken when used with older Arduino / avrdude versions. This problem disappears when avrdude is fixed in the proper way.

[per1234]

I don't fully understand the changes made between avrdude 6.0.1 and 6.3.0. Are these changes unintentional bugs or are they improvements that were thoroughly thought out and discussed? My limited understanding is they are the latter and are meant to improve consistency of how fuse bits are handled.

My testing indicated that the issues for Arduino AVR Boards were all solved by the original changes proposed in #5202, which were only edits to boards.txt and avrdude.conf.

avrdude 6.3.0-arduino2 does cause serious issues for many 3rd party AVR boards. The original changes proposed in #5202 even more so. The only solution for 3rd party boards I have come up with that maintains backwards compatibility is for them to add their own avrdude tool. This quite easy to do for Boards Manager installation but more difficult for manual installation.

So there is definitely a downside to staying with the new avrdude version but I hate to see Arduino take a step backwards. Whether avrdude 6.3.0 is actually a step forwards is the question. Can anyone with more knowledge on this give an opinion?

I was very happy to see the new versions of avr-gcc and avrdude added in Arduino AVR Boards 1.6.12, not because I was dissatisfied with the old versions but because it shows that Arduino is continuing to progress and stay relevant. If the community has to scramble a bit in exchange for modern tool versions with real improvements I think that's acceptable. It would be nice if we were given more time to prepare for these sorts of releases and maybe a beta release package_index.json file for upcoming Arduino AVR Boards versions. The hourly IDE build doesn't allow easy checking of how the new Arduino AVR Boards version will affect previous IDE versions.

I've already seen the new avrdude version fix two long standing issues(#2986 and https://github.com/arduino/Arduino/issues/388 for Arduino as ISP). I'm sure there are others.

[matthijskooijman]

As for the question at hand (downgrading avrdude or not): I think it depends on what upload problems avrdude 6.3 fixes. If significant "regular" upload problems are fixed, in exchange for new "burn bootloader"-only problems, that might be a worthwile tradeoff and we can consider keeping 6.3. If not, reverting is probably better.

[matthijskooijman]

@per1234, I think my previous comments answer most of what you write, but our comments crossed. In any case, I believe downgrading is intended as a temporary measure, buying some time for the proper fix to happen in avrdude (either in an upstream release, or if not in an Arduino-specific patch).

[facchinm]

@per1234 I find acceptable to delay the proper release of avrdude 6.3 (or 6.4 with mEDBG support) for a month or less, so we can workout all bugs which were discovered in this bunch of days (like #5173, which solution needs indeed an updated 6.3 build). It will help sorting out a proper .12 release with brand new tools working well for everyone

[logicaprogrammabile]

@cmaglie in my case I need to have more stability from the IDE. These problems lead me to lose more time to finish my projects. I think that new releases need to be more tested. your solution is good for me.
I await new release and i return to 1.6.9

[NicoHood]

If you revert, please make it Arch compatible (static libs).

[awatterott]

I would stay at avrdude 6.3, because the handling of unused fuse bits from the old avrdude version is not right. It is confusing if you look into the data sheet and find there other values.

[Testato]

Maybe this new Efuse management solve the most famous and old arduino bug ?
#2075

[awatterott]

@Testato No, it will not resolve #2075. The cause of the problem is that the ATmega8 has no extended fuse bits, but the IDE tells avrdude to write the extended fuse bits (parameter -Uefuse:w). A simple workaround for this can be, if you add a "efuse" with size 0 to the avrdude device description:
https://github.com/watterott/wattuino/blob/master/software/Arduino/hardware/watterott/avr/tools/avrdude.conf#L6540

[Testato]

But the team must solve this,
if it is simple solve it officialy, please do a PR, because the bug is open from many years