"to SDCC where after finding a bug I have two options: a) wait for someone, that has no obligation to me whatsoever, to fix it or b) spend two months getting familiar with the SDCC code and fix it myself some choice."

c) actually you might have a third one (which presumably is not widely known or available elsewhere) using the peephole optimizer.

Without changing the source of the compiler itself you can on the command line (option --peep-file) specify a file which contains expressions like:

replace {
  mov %1,a
  mov a,%1
} by {
  mov %1,a
} if notVolatile %1

The syntax is rather straigthforward and this could also be used to exchange a problematic piece of code. (8.1.13 "Peephole Optimizer" in http://sdcc.sourceforge.net/doc/sdccman.pdf . Eventually see file sdcc/src/mcs51/peeph.def within the source)


d) Integration of inline assembly within SDCC is rather seamless. This means if someone has spotted a bug in the generated assembly file he/she can pretty much try a cut'n paste of (a corrected version of) this assembly code into the C source (section 3.12 Inline Assembler)


e) For SDCC there is no separate "in-house-debugging-enabled" and "externally-shipped-debugging-disabled" version. So SDCC probably provides unusually detailled information about its inner state. (comments in lst file, --i-code-in-asm, --dumpall). This can be used when trying to change your C source (not SDCC's source) in order to avoid triggering the bug.


f) if SDCC development ceased and you have deep pockets you could hire a third party programmer to address your needs.


Of course I do not claim (or even imply) that all bugs can addressed with either options a,b or options c,d,e,f.