wait… no, that’s not it.
When I remove the other 43 presets, the preset that I’m testing with suddenly starts working. (And when I didn’t use “smallest” I had to do that, which made things work…)
Definitely a compiler bug. Removing one preset shouldn’t break/unbreak another.
Ok, time to start the very long and painful process of creating a gcc bug report.
Basically, I need to cut away as much as possible form ProffieOS while keeping the bug. Ideally the result is a single, short file that shows the problem, but that can take a while to get to…
you are a genius and super patience , you can make it !
thank you so much !
Thought I’d give an update on this.
I figured out that using clang instead of gcc should be possible, so I’m now trying to create an arduino-proffieboard module that uses clang. (If you don’t know, clang is an alternative C/C++ compiler, and it’s generally what the big boys, like google, use.)
clang is pickier than gcc, so there are several pieces of code that has to be fixed to make it work with clang, ProffieOS will not compile without these fixes. However, if this turns out to work out well, I will definitely release a ProffieOS 7.15 which compiles with clang.
My understanding is that clang generates slightly less efficient code than gcc for arm, I’m not sure if that is still true or not, we’ll have to evaluate it and see. If it does end up having less bugs, that’s probably a worthwhile tradeoff…
I don’t profess to fully understand it, but it sounds like quite a big step.
Would this not be something for OS-8 rather than an incremental 7.15 update?
Going from OS7 from OS8 is also a big step.
By making it possible to use OS7 with clang, it gives people the option of taking one step at a time, rather than two big steps at the same time. Changing one thing at a time makes it easier to find and fix problems.
From my experience using clang for embedded (and in general) it’s much more likely to generate better results, and more reliable/repeatable results. It generates less space efficient code across the board compared to gcc, but it generally runs more efficiently/quickly. Generally speaking at least I prefer using clang.
The fact clang is known for having a cleaner code base probably helps… I guess making it support new architectures is probably easier and so relatively less likely to have the kinds of bugs gcc always seems to have.
But yeah to your point about being more strict, clang has always felt more “by the book” to me, whereas gcc would let a lot more garbage through.
Well, I got it to compile.
However, with the same settings as gcc, clang generates code that is twice as big as gcc! I don’t think that’s going to work…
Guess I’ll have to go back to creating a gcc bug report…
Sorry to read. Best of luck.
So… what is the goal here, the slightly more efficient code?
It’s my understanding that 3.6.0 still is the version that creates the smallest code and works fine?
Unfortunately, 3.6.0 also has bugs.
I encountered some of them while working on the color display code, and using the new compiler that is in 4.1 fixed it.
The goal is no bugs, hopefully with only marginal impact on space and time efficiency.
Another update…
Today I wrote a script which comments out a single line of code, then compiles ProffieOS with 4.1 and 3.6 and makes sure that the bug is present when compiling with 4.1 and not present when compiling with 3.6. If everything works out, the new file is kept and the script runs again. If not, the modified file is discarded, the previous file restored, and then it runs again.
The progress is slow, but it should eventually be able to grind down the test program into something small that I can then hopefully submit as a bug report to gcc…
so I just checked the board manager, 4.1 is still not available, I’m running 2.2.3 arduino ide
I removed it, because it seems to be causing some fairly bad bugs.
If you do want to try it, it’s available on the experimental and beta channels.
This feels very relevant to what I’m doing right now:
Getting close to the finish line.
All of ProffieOS has now been reduced to one file with ~4 thousand lines.
Another day or two of grinding it down, and it will hopefully be small enough.
Curses, it looks like delete-one-line at a time script has managed to obfuscate the problem rather than illuminate it. Basically, it has optimized away lots of variable initializations, which opens up lots of ways for the program to not work as intended.
I thank my linter for always being aggressive about wanting explicit initialization.
The weird bugs that come from things of that nature…
I’m going to explore a little this evening to see if I can save anything from all this code-grinding.
If not, I might have to re-run the grinding script but with -Wununinitialized -Werror or something like that.
Looks like there is a new gcc (14.2)
I’m going to try it and see if it fixes any of these bugs…