Upgrade to newer avr toolchain: avr-gcc, avr-binutils, etc.

[GoogleCodeExporter]

What change would like to see?

The avr-gcc in the new 1.0 beta is still at 4.3.2 - while gcc now has had 
releases 4.5.3 and 4.6.1 for several months.

Why?

The upcoming 1.0 release already introduces lots of changes, this could be a 
rare opportunity to make a big step forward with avr-gcc as well. Improved 
optimizations can matter greatly on an embedded platform.

Would this cause any incompatibilities with previous versions?  If so, how
can these be mitigated?

I doubt there will be any incompatibilities, gcc is pretty mature by now.

Original issue reported on code.google.com by jc@wippler.nl on 29 Aug 2011 at 3:09

[GoogleCodeExporter]

I've heard lots of reports from users of new versions (eg, typically on Fedora) 
that are broken.  While gcc itself is very mature, avr-gcc often breaks in new 
versions.  Please test carefully!

Original comment by paul.sto...@gmail.com on 29 Aug 2011 at 6:32

[GoogleCodeExporter]

Also, while there's a new avr-gcc, I don't think that either WINAVR or 
CrossPack-avr has been updated, and the Arduino distribution uses those.  I 
think.

Original comment by wes...@gmail.com on 2 Sep 2011 at 12:10

[GoogleCodeExporter]

I think there's a new version of WinAVR in the works.  When that happens, we 
should switch over to it (but after 1.0).

Original comment by dmel...@gmail.com on 27 Sep 2011 at 9:42

• Changed title: Upgrade to newer avr-gcc, avr-binutils, etc.
• Added labels: Component-Build

[GoogleCodeExporter]

Issue 491 has been merged into this issue.

Original comment by dmel...@gmail.com on 30 Dec 2011 at 11:21

[GoogleCodeExporter]

Original comment by dmel...@gmail.com on 30 Dec 2011 at 11:21

• Changed title: Upgrade to newer avr toolchain: avr-gcc, avr-binutils, etc.

[GoogleCodeExporter]

Any plans on the upgrade? I have been using gcc-avr 4.6 and 4.7 (from the 
Debian repositories), which generates much smaller code than the version 
supplied with the standard Arduino distribution; while the former generate a 
firmware image of 27k, ye olde Arduino gcc makes it grows to 31k, making it 
impossible to flash on an ATMega328.

Original comment by stefan-g...@datenbruch.de on 11 Jun 2012 at 9:23

[GoogleCodeExporter]

No plans yet.  It's a big testing headache and so far there hasn't been a 
compelling reason to upgrade.  We've tended to follow the lead of WinAVR and 
Crosspack, so if they update, there's a good chance we would too.

Original comment by dmel...@gmail.com on 14 Jun 2012 at 2:56

[GoogleCodeExporter]

I would argue that the fix for the bogus "relocation truncated" errors on 
attiny would be a good reason to upgrade, but of course attiny hacking is 
somewhat a niche activity.

http://arduino.cc/forum/index.php?action=printpage;topic=60649.0

Original comment by microthe...@gmail.com on 20 Aug 2012 at 11:33

[GoogleCodeExporter]

FWIW - Crosspack has now had gcc 4.6.2 since November 2012

Original comment by ptelf...@gmail.com on 20 Sep 2013 at 2:02

[GoogleCodeExporter]

Teeny 3 has also had gcc version 4.7.2 for 6+ months now.  Can you please 
upgrade to at least 4.6?  Why?  For lambdas. 

Is there anything I can do to help?

Original comment by cjma...@gmail.com on 17 Oct 2013 at 3:25

[GoogleCodeExporter]

@cjmason

this issue is about AVR gcc.
I've opened an issue specifically for the ARM gcc here:

https://github.com/arduino/Arduino/issues/1630

let's continue the discussion there.
C

Original comment by c.mag...@arduino.cc on 17 Oct 2013 at 6:13