Pages: 1 [2] 3   Go Down
Author Topic: Tool chain is ancient, and needs to be updated.  (Read 11761 times)
0 Members and 1 Guest are viewing this topic.
Global Moderator
Dallas
Online Online
Shannon Member
*****
Karma: 212
Posts: 13079
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Atmel uses avr-gcc-4.7.2

...is the compiler for AVR processors.

Quote
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
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".

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

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

Quote
Demand quality.

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

Offline Offline
Newbie
*
Karma: 1
Posts: 48
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Atmel uses avr-gcc-4.7.2

...is the compiler for AVR processors.

Quote
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?

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: http://www.nongnu.org/avr-libc/bugs.html

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.
« Last Edit: August 27, 2013, 04:05:19 pm by ajk_ » Logged

Global Moderator
Dallas
Online Online
Shannon Member
*****
Karma: 212
Posts: 13079
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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.

Code:
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 );
}


Code:
4
4
4
...

Works perfectly on my Micro.

Quote
Array allocation problem in that SAM post.

I still can't find your test case.

Quote
Passing three uint64_t arguments to function.

Code:
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 ); 
}

Code:
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.

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

Still can't find your test case.

Quote
register 18 and 19 corruption

Still no test case.
Logged

SF Bay Area (USA)
Offline Offline
Tesla Member
***
Karma: 137
Posts: 6805
Strongly opinionated, but not official!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

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.)

Quote
The entire bug list along with what revision they are fix in can be seen here: http://www.nongnu.org/avr-libc/bugs.html
that looks depressingly out-of-date.  Nothing "fixed" since 4.5.0, and we've already eliminated versions earlier than 4.7.2...\

Quote
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.)
Logged

Offline Offline
Newbie
*
Karma: 1
Posts: 48
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Well, here's a case:
https://github.com/xxxajk/generic_storage/commit/45c03e0628c663a32d6ad082e4fc11fa6343b7cd
Basically, you have to init manually...

This one works around the spill register screw up
https://github.com/xxxajk/generic_storage/commit/460e71c2810f57ba9764dd7828784a3fcaa40d5f#FAT/FatFS/src/ff.c
Basically, I had to reorganize code.

There's two examples for you.
Logged

Offline Offline
Sr. Member
****
Karma: 4
Posts: 327
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

westfw,
   are you saying there are no known errors in the existing tool chain that arn't fixed.

Logged

SF Bay Area (USA)
Offline Offline
Tesla Member
***
Karma: 137
Posts: 6805
Strongly opinionated, but not official!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
are you saying there are no known errors in the existing tool chain that arn't fixed.
No, of course not.

Are you saying "Upgrading the Arduino tool chain to "Atmel AVR Toolchain 3.4.2"  will certainly result in the average Arduino user experiencing fewer toolchain-related errors"?

Quote
The initializer bug filed against eclipse, that I've been claiming can't happen in Arduino.
I can't find this bug under gcc itself.  Is there
Are you using Eclipse to compile your Arduino code?  Do you have a small test case or a test framework for your filesystem code, that exhibits the bug when using the Arduino IDE (using your code without the patch?)  I've always assumed that the Eclipse/Arduino package had relatively vanilla avr-gcc underneath, but it could be otherwise.

Quote
That's exactly the sort of detail I'd like to see, but the gcc bug it points to is from 3.4.x, and is supposed to be fixed even in the "ancient" version of the tools that Arduino is currently using.  :-(

All of which goes to show how difficult and annoying it is to find, confirm, and track toolchain bugs.  Which is a major reason I would be hesitant to trade a pretty-well-understood version for something new...
"There are two kinds of fool. One says, 'This is old, and therefore good.' And one says, 'This is new, and therefore better.'"
(Dean Inge)
Logged

Offline Offline
Newbie
*
Karma: 1
Posts: 48
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Just ran in to yet another bug, and worked around it... this time in GCC.

In order for memory to not be stomped on, I had to align an initialized array.

https://github.com/xxxajk/generic_storage/commit/b37ac36037763cf71c60839f4faa7623f1af5490

I shouldn't have to do work arounds like this. I'll be reporting this as soon as I can, like I do all bugs.
Logged

Offline Offline
Sr. Member
****
Karma: 4
Posts: 327
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

westfw

the third type is based upon the three wise monkeys
 http://en.wikipedia.org/wiki/Three_wise_monkeys

there are many quotes around one can dig up.

at the end of the day, there are bugs in the system, some have been there for years, and they have not been fixed, so ajk_, sorry its very unlikely the arduino team will listen to little old us, they have enough problems trying to get the Due out and to work properly,
Logged

Offline Offline
Newbie
*
Karma: 1
Posts: 48
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

That is really too bad. I just posted another cool bug.
https://github.com/arduino/Arduino/issues/1557
So you are saying that these may never get fixed?
And in this particular case, I'll not be able to profile my code?
Logged

Offline Offline
Sr. Member
****
Karma: 4
Posts: 327
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

sorry ajk_ , IMHE , the probability of the arduino team listening to us users is 'low'.

if they can still sell, they are a commercial company,
    the DUE was apparently pushed along by the Rpi success.


     
Logged

SF Bay Area (USA)
Offline Offline
Tesla Member
***
Karma: 137
Posts: 6805
Strongly opinionated, but not official!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

You do realize that "profiling generic filesystem code built using Cclipse for an Arduino MEGA ADK board with extra external memory" is ... pretty far from the usual "arduino user" experience, right?

Arduino IS very much focused on the beginning user experience.  If you know what you're doing, your issues are less important.


-fprofile-generate  seems to have been disabled in the gcc test suite back in 2011, because "it wasn't implemented for AVR."  http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00333.html

I haven't seen any news that whatever needed to be implemented HAS been implemented, although both 4.6.2 and 4.7.2 no longer crash when given the switch.  They DO produce vastly different code, and both seem to have the effect of -O0 as well.  So the 4.7.2 Stream.o file is about 6x bigger than a normal compile, and the 4.6.2 code is about 2x bigger than that.  I'm not quite sure what I should have expected; I usually think of profiling as something that happens based on statistical sampling of the PC in a timer interrupt, with otherwise unmodified binaries.  I guess another technique would be to insert calls in all function prefix/postscript code, but that doesn't look like it is happening either.

Tell me again how a newer toolchain will fix all your problems?

(Meanwhile, I also checked to see if Mac's CrossPack package is up-to-date compared to the Atmel Toolchain.  Nope.  Crosspack is still back at 4.6.2...  Sigh.)
Logged

Offline Offline
Sr. Member
****
Karma: 4
Posts: 327
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hay westfw,

how about my students,

they 'just' run the standard code,

even a simple hello world generates various "warnings" in the debug window.
   
these come from the system,
   to them the system and the tool chain is the same.

As you say, these are who the Arduino is aimed at.

So imagine their worry when they get the first hello workd example ( well flashing led ) example on the arduino and it does not work.

SO first thing they are told to do, like IMHO all good coders, is to look at the warnings / error messages.

and they see warnings, and we say, of they are warnings, but to you they dont matter,

  so they come back and ask, how can they tell real warnings from false ones, and why has this great tool you are teaching us to use not been fixed..

    Dahhh   ,,  a great negative start ...

And if we tell them about the warnings that will happen before, then they get depressed at the tools even sooner.

OK, its part of debugging, learning the deep ins and out of the code, and 'what is relevant' , but please, not in the first few hours of coding,
 
Logged

IDF/SO
Offline Offline
Edison Member
*
Karma: 41
Posts: 2306
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Use IDE Arduino with latest avr-gcc-4.7.2 is easy :
- don't use Arduino IDE from Arduino
- use Debian Linux and IDE only from debian package repositery.

If Debian knows how to use the latest version of avr-gcc, it is the proof that this is possible.
If Debian did it, Arduino team should be able to do so. If necessary they can copy on Debian.
Logged

Offline Offline
Full Member
***
Karma: 12
Posts: 157
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

The Arduino library code generates warnings when compiled because of problems with the library code, not the compiler. Changing the compiler won't fix that. Compiling with 4.5.1, 4.6.2, 4.7.2 and 4.8.0 all generate warnings because the same code, with the same problems, is being compiled. In fact the 4.8.0 compiler generates more warnings than the 4.3.2 compiler.
Logged

Pages: 1 [2] 3   Go Up
Jump to: