Tool chain is ancient, and needs to be updated.

Why is the Arduino using a tool chain from 2008 -- 5 years old, and full of some very nasty bugs?

I keep stumbling upon these horrible bugs left and right.

Atmel uses avr-gcc-4.7.2

I've been doing this:
http://forum.arduino.cc/index.php/topic,37965.msg281176.html#msg281176

we all know about the old tools,

its been a running problem since 2009,,,

but the team seem reluctant to change ,

maybe the Due will force things !

I can easily do the same with Linux-- I personally don't use the Arduino IDE, just the c++ stuff, and libs, which are handy.

The problem is that not everyone else can or will do it, and you have to fight nasty bugs with workarounds to support them in your libraries. It is really a pain in the neck, and there are many who whine about official this, and official that, which in reality is bologna, because all the tools are open source and free for you to not just use, but to modify...

What if I made an advanced fork using proper current tools on github? You can find my other stuff there too.

"you can change open source"

well personally, no I can't

I speak arduino, but the tool chain are way beyond what I could modify,

I could learn it,
but then I'd not want / need to use Arduino,

Were reliant upon the team ,

Yes, but would you use an alternative tool set (avr-gcc/g++ etc) if it was offered in a simplistic way?
i.e. it would replace the outdated tools. that is what I am asking.
8)

for myself,
I teach the Arduino with children,
so want to stay as near to off the shelf as possible,

Its just a shame that, all the work that many people have put into improving the chain , bring up to date, apparently ignored by the Arduino team.

drjiohnsmith:
for myself,
I teach the Arduino with children,
so want to stay as near to off the shelf as possible,

Its just a shame that, all the work that many people have put into improving the chain , bring up to date, apparently ignored by the Arduino team.

Tell everybody you know, and start complaining on github then! :grin:
Squeaky wheel gets the grease!

git hub ?

Github is where the Arduino issue list lives. And the source code.

However, it's not so simple. There are two problems:

  1. The Arduino doesn't use gcc directly. It uses packaged SETS of tools that include matched versions of avr-gcc, avr-libc, and avr-binutils, plus a bunch of other stuff (make, unix-like utilities commonly used by makefiles, avrdude, etc.) On Windows, Arduino uses WINAVR, and on Mac it uses CrossPack. For a while, Crosspack tracked WinAVR, and everything was great. But the last version of WINAVR was in 2010 and used avr-gcc 4.3.3 (Arduino seems to use a slightly earlier version.) The WinAVR maintainers have essentially said that they're not going to do it any more. The modern equivalent comesdirect from Atmel in the form of their "Atmel AVR Toolchain", which is available for Windows and Linux (as of relatively recently: this has avr-gcc 4.7.2, I think. In between 2010 and now there was ... not much, short of building your own package.) Note that there's no Mac package from Atmel, and it's not clear with the Atmel tools contain additional patches beyond stock gcc 4.7.2 or not.

  2. Nearly every version of avr-gcc in between 4.3.x and 4.7.2 has been broken WRT Arduino, for various reasons. (causing all sorts of trouble for the linux Arduino users that used to be instructed to install whatever version of avr-gcc/etc was packaged for their distribution.) Some of the bugs are documented in https://github.com/arduino/Arduino/issues/1208
    (avr-gcc 4.7.2 is sounding pretty good. The Atmel package is looking like a pretty adequate replacement for WinAVR. But it's only a couple of months old, and it has some incompatibilities with the current Arduino core code.)

Could you be more explicit about "I keep stumbling upon these horrible bugs left and right"? Every known bug in the current compiler is a motivator for upgrading, but ... I wasn't aware that there WERE any significant bugs. Descriptions would be good. Pointers to the gcc or avr-xxx issue trackers and actual patches would be better.

Its alittle off topic,
but if you want to know the list of bugs,
look on the extensive bug list on the arduino

As for "significant" , that is subjective,

what to you and me is a "known issue and you get around it be this"

the Arduino is aimed at new users, moving art et all,
and to thise users, a bug is a bug, they know not how serious it is,
every warning that comes up is a cause for concern, worry
then when you say "oh that one is not significant"
!!!!!!

Hi guys,

I've been wondering the same question. Why Arduino didn't update to the last avr-gcc version so as to solve all the compiler bug issues?

Has anyone achieved to update the toolchain to the last versions? (I guess they are avr-gcc 4.7.2 and avr-libc 1.8.0-3)

Cheers!

but if you want to know the list of bugs,
look on the extensive bug list on the arduino

I have looked at it.
The vast majority of those are NOT things that will be fixed by upgrading the compiler. There isn't even a "compiler" label (there hasn't needed to be.)
Searching through the bug list for keywords like "compiler" or "avr-gcc", I found ONE that might fit ("avr-gcc doesn't support Hebrew").
(There are several bugs related to having problems with getting (via linux) more recent compilers than 4.3.x)

I want a list of Arduino problems cause by bugs in the version of avr-gcc/etc being used, that are KNOWN FIXED in, say, "Atmel AVR Toolchain 3.4.2" (which is the current version that has avr-gcc 4.7.2)

tool chain is the title,

what fix's would happen by changing to the latest tool chain ?

your saying there is none ?

There's actually one very known bug, where you can't pre-init an array, gcc doesn't puth keep around the emitted code, and you get an unallocated symbol... which... points to memory that isn't allocated and gets over written by another variable.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=411544

This does not only affect arm, it affects many platforms.

westfw:
Github is where the Arduino issue list lives. And the source code.

However, it's not so simple. There are two problems:

Both easily solved with the correct effort.

Personally, I can't stand it when people tolerate a lower quality tool when something better is available. To me it is not only senseless, it is plain stupid. Demand quality. You paid for it when you bought the Arduino.

Atmel uses avr-gcc-4.7.2

...is the compiler for AVR processors.

C++ global object constructors do not get called in apps built for Cortex-A GNU targets

...is the compiler for SAM processors.

First you complain about the AVR compiler. Then you cite a bug report regarding the SAM compiler. Which compiler are you complaining about?

Personally, I can't stand it when people tolerate a lower quality tool when something better is available.

You have yet to make any case that the current toolset is "lower quality". You have yet to make any case that "something better is available".

To me it is not only senseless, it is plain stupid.

Upgrading for the sake of upgrading is just as senseless and stupid.

Demand quality.

I demand proof that one or both compilers should be upgraded.

[quote author=Coding Badly link=topic=184131.msg1368968#msg1368968 date=1377633612]

Atmel uses avr-gcc-4.7.2

...is the compiler for AVR processors.

C++ global object constructors do not get called in apps built for Cortex-A GNU targets

...is the compiler for SAM processors.

First you complain about the AVR compiler. Then you cite a bug report regarding the SAM compiler. Which compiler are you complaining about?[/quote]

Read again, it affects nearly ALL platforms. AVR, ARM, and SAM to name three of them. Try the test your self. It will fail just like in the bug report url I posted.

There is an entire laundry list of bugs, everything from not allocating arrays properly, to missed code optimizations.

The latter alone is worth an upgrade if it means more code space, and less RAM usage.
The entire bug list along with what revision they are fix in can be seen here: AVR Toolchain Bugs

Bugs I run into include:
Array allocation problem in that SAM post.
Passing three uint64_t arguments to function.
unable to find a register to spill in class `POINTER_REGS'
register 18 and 19 corruption

...to name a FEW.
I won't even get into all the missed optimizations.

ajk_:
Read again, it affects nearly ALL platforms. AVR, ARM, and SAM to name three of them. Try the test your self. It will fail just like in the bug report url I posted.

static uint16_t ConstructorCount;

class HasConstructor
{
public:
  HasConstructor( void )
  {
    ++ConstructorCount;
  }
};

HasConstructor hc1;
HasConstructor hc2;
HasConstructor hc3;
HasConstructor hc4;

void setup( void )
{
  Serial.begin( 115200 );
}

void loop( void )
{
  Serial.println( ConstructorCount );
  delay( 1000 );
}
4
4
4
...

Works perfectly on my Micro.

Array allocation problem in that SAM post.

I still can't find your test case.

Passing three uint64_t arguments to function.

static void ThreeBigOnes( uint64_t & a, uint64_t & b, uint64_t & c )
{
  a = b + c;
}

void setup( void )
{
  Serial.begin( 115200 );
}

void loop( void )
{
  uint64_t a;
  uint64_t b;
  uint64_t c;
  
  b = 0x1000000000000000ULL;
  c = 0x1000000000000000ULL;
  ThreeBigOnes( a, b, c );
  Serial.print( (unsigned long)(a >> 32), HEX );
  Serial.write( '\t' );
  Serial.print( (unsigned long)(b >> 32), HEX );
  Serial.write( '\t' );
  Serial.println( (unsigned long)(c >> 32), HEX );
  delay( 1000 );  
}
20000000	10000000	10000000
20000000	10000000	10000000
20000000	10000000	10000000
...

Works for me on my Micro. Maybe you should post your sketch(es) so we can help you.

unable to find a register to spill in class `POINTER_REGS'

Still can't find your test case.

register 18 and 19 corruption

Still no test case.

411544 – C++ global object constructors do not get called in apps built for Cortex-A GNU targets

Read again, it affects nearly ALL platforms. AVR, ARM, and SAM to name three of them. Try the test your self. It will fail just like in the bug report url I posted.

What are you talking about? the bug you linked is against Eclipse for ARM A8. It doesn't mention any other processors, and it doesn't include a test. I can't figure out how to see the associated patch, or what it was made to (perhaps I'm insufficiently conversant with bugzilla...)

I'm pretty sure that that particular bug does NOT happen on Arduino with 4.3.2, because a variation of it was the cause for the famous bugs on MEGA when using 4.5.3. And I have a pretty popular sketch out there that makes extensive use of initialized structures (and arrays), which works fine. Also, avr-gcc 4.3.2 doesn't use .init sections, and it sounds like a bug in Makefile/etc (not copying sections from object files into binaries; on avr that gets done by avr-objcopy when creating .hex file from .elf)

(hmm. I guess there could be a problem with very large programs and initialized data on MEGA. The 4.5.3 bug was a regression caused by adding extended flash addressing, which implies that earlier versions might not have handled initialization data beyond 64k at all.)

The entire bug list along with what revision they are fix in can be seen here: AVR Toolchain Bugs

that looks depressingly out-of-date. Nothing "fixed" since 4.5.0, and we've already eliminated versions earlier than 4.7.2...\

Bugs I run into include:
Passing three uint64_t arguments to function.
unable to find a register to spill in class `POINTER_REGS'
register 18 and 19 corruption

By all means feel free to submit issues on the Arduino github issue list. Be sure to include test cases and/or pointers to the gcc/whatever report showing the original reports and where they were fixed. (isn't the R18/19 corruption the cause of the global constructor issue in 4.5.3? When does it happen in 4.3?)

The third factor against "staying current" that I didn't mention before is that gcc is NOT a microcontroller project. That it works on something as small as an AVR at all is remarkable, and it's not uncommon for "improvements" made by the gcc team to break the avr implementation is odd ways. Most code produced got bigger between 4.3 and 4.5, for example, and the entire way that the prog_xxx types are implemented in avr-gcc is "wrong" and stops working in 4.5 or so, and I've seen several cases where in "obvious" optimization done at gcc level results in bigger, slower code on avr (because ... 8 bit moves, IIRC.)

Well, here's a case:

Basically, you have to init manually...

This one works around the spill register screw up

Basically, I had to reorganize code.

There's two examples for you.