So in your normal desktop space you have GCC or LLVM in widespread usage and it's unheard of to ever use anything else.
Now in the embedded space, things are a different story.
You see...we have these...."compilers". We do have the choice of gcc for most micros but when it comes to companies they want enterprise! So there is proprietary trash that you have to license. And generally most of the time they are ok. Except for one....whose terror none of you know.
Microchip's XC8.
It is the compiler for PIC16 and PIC18 microcontrollers. In fact, there is a deeper fundamental issue with these micros. Their internal architecture is so broken, NOBODY can easily make a compiler nor really wants to bother. Because you would have to write a custom assembler for every single fucking micro of the family because of how bad things are.
But to describe XC8 is like to describe a person in a mental institution.50% of the time, code compiles fine. 25% of the time it can't compile code correctly but it obviously doesn't work, the other 25% of the time...the code works but the assembly is wrong in some subtle way which is terrifying.
So this goes down the path of realizing that XC8 is not a deterministic compiler at all. In fact I am absolutely terrified about any of my company's products built using it failing in some weird edge case where a bug got compiled in by the compiler itself.
List of fun bugs:
It flipped the padding word endianness in the output hex file. Their tech support at first acknowledged the word value was wrong and then proceeded to argue with me on the compiler was doing it right. Their fix ETA was 1 year from the conversation in the next release.
The list of bugs they fix is more terrifying than the bugs I counter, here are some:
Incorrectly initialized structures (XC8-1057) For PIC18 devices, when initializing structures
that contained a char array with a string less than the size of the array, the initialization
may have caused structure members following the array to be corrupted.
Yes, somebody actually broke their compiler to the point it wasn't using the struct declaration as the structure declaration
Bad short long addition result (XC8-1052, XC8-1064) For PIC18 devices, the result of short
long additions when the operands were in different banks may have been incorrect.
Yes, in this compiler 1+1 does equal 3
Wrong bank selected with complement (XC8-1035) In some cases for PIC18 targets the copiler was selecting the wrong bank when performing a bitwise complement of a word-sizedobject in banked memory
Yes it couldn't complement correctly.
Program resets (XC8-970) Under some circumstances inlining nested functions calls might
have resulted in a call to reset and program failure
Yes, doing an inline fucking function somehow caused the compiler to insert RESET op codes. How does this happen? Fucking wonderland.
Incorrectly merged code (XC8-924) When a statement in the true part of an if statement and a
statement in the false (else) part was the same except for a conversion (cast) of a symbol,
the compiler might incorrectly consider these statements identical and merge the generated
code.
So that's why my code was break pointing oddly(I'm serious)
Bad right shift (XC8-938) For all devices, some expressions involving a right shift of an unsigned object that was cast to be a signed object, might have produced an incorrect result.
Yes, it couldn't keep up with typecasts and failed to do shifts properly.
Another one that also made me rage extremely hard and loudly. If I inserted two levels inside a function explicitly labeled as inline, the inner most if statement never got compiled into the assembly. I visibly saw it was missing from the assembly list. If I removed the inline attribute, it got compiled in.
I could go on for fucking PAGES about this trash.
The wonderful part is this is supposed to be a production quality tool. I can't believe we continue to use this trash brand of micros and their tools.