avr-gcc with AVRxt and newer GCC version

[MX682X]

Because I was cuirous I've spent some time in getting the avr-toolchain script to run. Here are some versions. Since I'm working with Windows, the most Versions are for Windows. As I was building in a Linux VM, there are also some Linux Versions, but not all because I was running low on space in the VM and forgot to back them up. Also, no Apple version, since I can't test it. And everything is 64-bit because the 32bit mingw compiler didn't want to run correctly in the 64-bit VM.
For some reason the optimization got kinda dumb from 8 on onwards, but there supposedly were improvements to small interrupts (gas-isr). Codesize behaves weirdly. Can't describe it in general. Oh, and I had to get rid of "bit addressable I/O register" flags, in 12 since it didn't want to compile otherwise. So what I'm saying is, Not safe to work with.
In order to try it out, just put the contents of the "avr" folder into the toolchain folder of the Core, e.g "7.3.0-atmel3.6.1-azduino6" right now. There is also no 11 since there were no changes in the avr part of gcc, so I left it out.
Oh, and I was using old Device packs, so the news DDs aren't supported. Have fun experimenting! (Using Dropbox because the files are too big otherwise)

https://www.dropbox.com/s/ob0gs26ty3ylk1s/avr-gcc-7.5.0-atmel3.6.1-mxduino1-x86_64-w64-mingw32.zip?dl=0
https://www.dropbox.com/s/tpt5s9bpcym2tal/avr-gcc-8.5.0-atmel3.6.1-mxduino1-x86_64-pc-linux-gnu.tar.bz2?dl=0
https://www.dropbox.com/s/x5so8wlj98fxv7n/avr-gcc-8.5.0-atmel3.6.1-mxduino1-x86_64-w64-mingw32.zip?dl=0
https://www.dropbox.com/s/o170gq784i42pxa/avr-gcc-9.5.0-atmel3.6.1-mxduino1-x86_64-pc-linux-gnu.tar.bz2?dl=0
https://www.dropbox.com/s/29sjisvcoite6ao/avr-gcc-9.5.0-atmel3.6.1-mxduino1-x86_64-w64-mingw32.zip?dl=0
https://www.dropbox.com/s/h6uffrdc32ux9b3/avr-gcc-10.4.0-atmel3.6.1-mxduino1-x86_64-pc-linux-gnu.tar.bz2?dl=0
https://www.dropbox.com/s/jmq0huq5em2n2qc/avr-gcc-10.4.0-atmel3.6.1-mxduino1-x86_64-w64-mingw32.zip?dl=0
https://www.dropbox.com/s/kv1q5mqnxmvvmtt/avr-gcc-12.2.0-atmel3.6.1-mxduino1-x86_64-pc-linux-gnu.tar.bz2?dl=0
https://www.dropbox.com/s/vjmbk9ghoxlildd/avr-gcc-12.2.0-atmel3.6.1-mxduino1-x86_64-w64-mingw32.zip?dl=0

[SpenceKonde]

I'd also heard that the optimization for AVR-GCC started sucking ass around version 8, which is why I wasn't pursuing this. My understanding was that Microchip uses 7.3.0, and that's the latest version that's even had a Microchip person try it so they could fall out of their chair in shock at the moronic things it did. Even 7.3.0 does some REALLY dumb shit. And I recall hearing that on 10 and later, you get warnings like nobodys business for doing normal things because it doesn't know that things other architectures don't like are normal and correct on avr.

How the bloody hell did you get those to build working binaries? I can get the build process to make the toolchain working on x64 linux.... except that something is wrong with the linker, and i have no clue what, so I am still just stealing the binaries I ship from the last Arduino package.....

In any event, this is largely academic - without a way to build for mingw, x64 linux x86 linux, macos, ARM 32-bit, and ARM 64-bit, it's not like I could use it in the core. This is also why I hate avrdude - they're maintaining it now, but who knows when there will be another multiyear hiatus? And in that time, if I needed to update it, I couldn't. Because I do not know how to set up a build system that can crosscompile for 6 fucking platforms. Every single time I have depended on someone else maintaining something, if they ever followed through at all, they had renegged within 6 months, so I do not like depending on things that I cannot rebuild if the maintainer vanishes, which they always do.

[MX682X]

There is also 7.5.0 - has some bugfixes I think - but code generation is the same as 7.3.0.

I didn't see any warnings in 10, but I had one in 12 about a while loop and a guard - it probably didn't knew it was a peripheral register (ADC)

The linker is build with binutils. The avr-binutils that are mentioned in the original avr-toolchain are outdated. GCC 8+ requires binutils v2.29 at least, because of the change how interrupts are handled (gas-isr). I've build GCC 7.5.0 with binutils v2.39 without problems, so there shouldn't be a problem.

In any event, this is largely academic - without a way to build for mingw, x64 linux x86 linux, macos, ARM 32-bit, and ARM 64-bit, it's not like I could use it in the core

Considering that every build takes about an hour to compile, And due the non-statisfing results of GCC 8+ I decided not to pursue other platforms for now. I will try to make a new github repository with the modified build-scripts, but I'm telling you now - They are kinda unreliable. They get the job done, but it requires a restart or uncomenting a line from time to time.

[MX682X]

https://github.com/MX682X/avr-toolchain-updated-buildscript

[SpenceKonde]

The ill tidings coming from v8 and later have largely prompted me to shelve plans do use newer versions of avr-gcc.

I think what is happening is that layers get added to cater to x64 and arm, and they need to be tuned or turned off on AVR. But that doesn't happen because not enough AVR people are working on it,.
adiw r26, a; st X, r10; sbiw r26, a; adiw r26 b, st x, r11, sbiw r26 b etc. I suspect that that's an example of this compiler rot phenomenon - new compiler layers were added after the layer that would elide redundant mathematical operations (even if there isn't a way to avoid some of this thrash, at least the sbiw of one and the adiw of the next can be combined! Regressions that don't seem to get fixed have been cropping up already. Notice how wiring_pulse has an asm implementation (generated with the compiler because nobody there knows how to hand-write asm). That was done using 4.3 after they switched to 5 or something and realized the loop it made was many times slower, so pulsein didn't work. The comments in the .S explain the story. And the official implementation only times correctly after the pulse starts - if it times out, that happens faster than you ask it to.

Re: warnings
Try compiling uhhh.... pinModeFast(PIN_PAn,OUTPUT); where n is a number between 0 and 7 which exists on the parts. IIRC some of the latest versions of avr-gcc squawk because that writes to a memory address - 0x0000 (VPORTA.DIR) - while 0 is invalid on 90+% of ISAs. But it's totally legit on AVR, and there's an easy way to turn that off, but nobody was even watching

Re build time
When I run the build for just the one (linux x64) platform, I rent an AWS xl instance, with the build script tweaked to use every core the VM has. Still slow as fuck, but IIRC that gets it under half an hr even auto-pulling all latest ATpacks (when I build, I build with every AVR ATpack).

But I think I agree with you, it just doesn't seem worthwhile to update the avr-gcc versions, since the optimization tends to get worse rather than better, and there don't seem to be any particularly exciting features on the roadmap. So why "upgrade"?

[WestfW]

Note that doing anything with versions older than 10.0 is probably pointless because of MODE_CC change to the handling of status bits (or something like that.) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

[MX682X]

I know. It was actually only ported in GCC12, but the problem is that this version is not really good in terms of codesize as it does many unneccessary operations: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706 . Someone said they will look into that this month, so we'll see if that gonna be an intresting option.
But, I just found out about the wiki and found something interesting, that I do not think was part of the changes in the avr backend: https://gcc.gnu.org/wiki/LRAIsDefault . It is intresting, because it can only be enabled if the new CC mode is being used, and I think I've compiled it with the old sheme. I will try to compile it with the new LRA today

[MX682X]

quick update: I was able to compile with GCC12 and LRA support.... but it has a bug that has a problem somewhere with the inline assembly without saying where exactly the problem is, thus making it virtually unusable. In other words: GCC7 it is for now.