Toolchain update - will need help testing

Status
Not open for further replies.
PaulStoffregen

PaulStoffregen

Well-known member
We've gone almost 2 years without a toolchain update. Then again, so has Arduino, so nearly all code in the Arduino world has been developed using gcc 4.8.

I'm considering making the jump to gcc 5.4, specifically this one:

https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update

On the plus side, this could bring nice improvements and hopefully fix the long-standing (but minor) issues where the compiler we have today misses optimization opportunities.

On the minus side, some well established libraries may break, and many are likely to start showing compiler warnings. I'm going to need help with lots of early beta testing.

My hope is to publish a beta soon with the new toolchain. Hopefully this will allow plenty of time for testing before Arduino makes a release or something else prompts the need for a new Teensyduino release. If too many things break, or if there's not much interesting in testing, I'll probably revert to our old but tried-and-true 4.8 toolchain.
 
I should be able to check and correct any of the few things (TouchScreen/Talkie/??) I've "touched" before at a minimum.
 
I'm only using cores/Teensy3, and no or few libraries, so I may be of little help, but I will follow this thread and, obviously, share any experience I get with 5_4_2016q3
 
Well, jumping to gcc 5.4 might not be as bad as I had feared. Just did some initial testing. Almost all libs compile. Many have warnings, but quite a lot of those were present even with gcc 4.8, especially warnings about possibly uninitialized vars in some of Adafruit's libs.

However, the new version is much larger. It nearly doubles the Teensyduino installer size, to approx 120 MB.

Next I'm going to try enabling LTO....
 
I use Ethernet, Eeprom, TimeLib and SDfat on a daily basis, if these need testing.
 
PaulStoffregen said:
Well, jumping to gcc 5.4 might not be as bad as I had feared. Just did some initial testing. Almost all libs compile. Many have warnings, but quite a lot of those were present even with gcc 4.8, especially warnings about possibly uninitialized vars in some of Adafruit's libs.

However, the new version is much larger. It nearly doubles the Teensyduino installer size, to approx 120 MB.

Next I'm going to try enabling LTO....
Click to expand...

Maybe provide toolchain as separate download/installer?
 
Epyon said:
I use Ethernet, Eeprom, TimeLib and SDfat on a daily basis, if these need testing.
Click to expand...

Yes! SdFat is on the short list of libraries making extensive use of C++ features. Almost all the others are pretty simple, without templates or much other C++ stuff than a class and maybe a little function overloading.
 
WMXZ said:
Maybe provide toolchain as separate download/installer?
Click to expand...

It might come to that, but already people have to download 2 things (plus udev rules if using Linux). With only 2, there's only so many permutation of versions, especially since the Teensyduino installer checks for only a small set of supported versions. But even then, we get questions daily that involve figuring out which version they really have. I fear going to 3 assets to download and install could make support much harder.
 
As an interim option is it possible to tie compiler to the CPU speed menu so we get '96mhz - experimental compiler' as an option? Logic is that CPU speed has little impact on actual compile process so we can start that way fixing the libraries and then transition to always using that but offering a '96mhz - fallback compiler' so that people having errors can be asked to test compile against it to find out if the errors in the random library from the internet are the compiler or the code.

Can see a lot of benefit if there is someway we can point people at a legacy option already on their system.

Though if I'm understanding this right we then get a mammoth installer since it's bringing both compilers with it.
 
PaulStoffregen said:
It might come to that, but already people have to download 2 things (plus udev rules if using Linux). With only 2, there's only so many permutation of versions, especially since the Teensyduino installer checks for only a small set of supported versions. But even then, we get questions daily that involve figuring out which version they really have. I fear going to 3 assets to download and install could make support much harder.
Click to expand...

One advantage though would be that downloading new fixes in Teensy code and libraries would not require download of toolchain. As you said the actual one has not been touched for a long while, but it was always downloaded for every beta, which on metered internet connection is becoming costly.
 
WMXZ said:
One advantage though would be that downloading new fixes in Teensy code and libraries would not require download of toolchain. As you said the actual one has not been touched for a long while, but it was always downloaded for every beta, which on metered internet connection is becoming costly.
Click to expand...

That could be handy. I just purged 7 old/beta Teensy installers on one machine and 4 on the other - and - with beta builds - probably downloaded on average 1 or 2 copies a month since I got here with IDE 1.6.0?

Question does the Board manager offer a solution for Current gcc_4.8 and gcc_5.4 Tools? Is there a common/compatible posted toolchain used by any other board?

Was weird when I was doing ESP-8266 and then put on the BOARDS for the Digistump Oak that doing the ESP-8266 (that used a pre-release newer rev of the ESP_Arduino) after that I saw" %appdata%\...\Digistump" as the tools path. It was fine as they were using the same toolchain and IDE just liked the idea for some reason. That would use the JSON based Arduino scheme for tools - as long as they install generically without caring about TeensyInstalle - and Teensy build can use and find them without change. And once those are ON a machine they are GLOBAL with one copy for any IDE that looks there in (Win) %appdata%
 
defragster said:
Question does the Board manager offer a solution for Current gcc_4.8 and gcc_5.4 Tools? Is there a common/compatible posted toolchain used by any other board?
Click to expand...

Only the ARM toolchain Arduino uses for Due & Zero. It's 6 months older than the one we've been using for Teensy LC & 3.x.

Toolchain update has come up a few times on Arduino's github issues. Seems they have little to no interest to upgrade anytime soon.
 
I'm working on trimming the fat. The new toolchain has a *lot* of copies of the C & C++ standard libs. We only need 3, for M0+ on Teensy LC, regular M4 on Teensy 3.0-3.2, and M4F on Teensy 3.5-3.6. At least I hope we only need those 3....
 
PaulStoffregen said:
I'm working on trimming the fat. The new toolchain has a *lot* of copies of the C & C++ standard libs. We only need 3, for M0+ on Teensy LC, regular M4 on Teensy 3.0-3.2, and M4F on Teensy 3.5-3.6. At least I hope we only need those 3....
Click to expand...

That might hit people who install a combo branch and then switch the IDE to the Due or other non-Teensy arm based systems. Back when I still programmed AVR systems I used to do this a few times. Since I have stopped doing anything but Teensy, it won't affect me, but perhaps it may affect other people.

Now what I do, is install Ardunio into a separate directly, and bring up the IDE enough until the prompt about updating libraries shows up, and I do all of the updates. Then I clone the directory and install Teensy in that directory, and I ignore any further prompts to update libraries in the combined Teensy+Arduino directory.
 
This shouldn't affect others. I'm installing the toolchain in a different location than Arduino uses. Teensyduino's platform.txt file also has a very different way of doing things that Arduino. So far, all the other boards I've seen have very closely copied Arduino's examples. If someone were to write their own platform.txt (or copy Teensyduino's) to use this toolchain, then yes, they could be in for quite a surprise if they're targeting any chips which need the other libraries.
 
PaulStoffregen said:
This shouldn't affect others. I'm installing the toolchain in a different location than Arduino uses. Teensyduino's platform.txt file also has a very different way of doing things that Arduino. So far, all the other boards I've seen have very closely copied Arduino's examples. If someone were to write their own platform.txt (or copy Teensyduino's) to use this toolchain, then yes, they could be in for quite a surprise if they're targeting any chips which need the other libraries.
Click to expand...

That minimizes the chance users could hose themselves.
 
Status
Not open for further replies.
Back
Top