And it's also why I don't trust automated testsuites, the only reliable way to test is write a trivial program inside KTIGCC which includes <tigcclib.h> and calls the function, build it and run it.

I assume "build it" is a multiple step process, for testing multiple compilation option sets ? If not, the way you're describing is too simple-minded to catch calling convention mismatches (and possibly other errors, too)
Remember, this is the issue here, which also bit me on one or two TICT programs when switching from __stkparm__ mode to __regparm__ mode.

And if the test passed, I don't need the testcase anymore, so I delete it.

Well, that's your way of doing things. Other people may want to do differently

No, the fact is that TIGCC doesn't have a testsuite (what you call a "testsuite" is just a set of examples documenting some function, it's designed to be documentation, not a testsuite, and the examples are selected to illustrate certain points to a human reader, not to test TIGCCLIB) and there are no plans to add one.

I have already understood your point that the examples are meant as documentation, but you still haven't understood that the examples can be used to test TIGCCLIB, even without any code modifications (though modifications might be desirable on some examples if they're really too simple-minded), by varying startup code options.

But it will take a lot of effort to raise GCC4TI up from the low-quality code base inherited from TIGCC.

So far, you've added several bad regressions in frequently-used code due to poorly tested (note that I didn't write "untested", as you obviously tried to test the stuff, but failed) changes

Mistakes can, and do, happen, when doing something productive such as optimizing and adding features. Those who seldom do anything productive have little risk to make mistakes.

You didn't _spend_ the time for Joey's routines so far. That's very different

I can't spend time I don't have.

You spend lots of time trolling and finding excuses for not doing your maintainership work, so you do have time. You choose to spend it on improductive things... it's your call, but such statements as "I can't spend time I don't have" are plain lies, and repeating them doesn't make them true, sorry.

I want to know from a directory listing or from the file tree of the tigcc.tpr project in KTIGCC which functions are in C and which are in assembly.

I don't see the urge for that, but it can be argued to be a valid reason.

I agree the bug needs to be fixed, but replacing the whole function is a poor way of fixing bugs.

We didn't plan to replace the whole code of bsearch and qsort just for the sake of it, you know
* the code of the buggy bsearch() was simply compared with other, known-correct implementations. A better algorithm was found among those. Later, the assembly generated by the compiler was hand-edited because GCC did a crappy job.
* qsort() was reported to be slow, and a quick examination of the shellsort algorithm used in qsort() showed that it used Shell's original algorithm, which exhibits O(n^2) behaviour. It has been known for years (and documented on WP) that very minor tweaks to the algorithm make its worst case behaviour much better. So we went for tweaking the algorithm, using a better (= smaller AND faster !) algorithm. And since the compiler was doing a crappy job, I resorted to tweaking the assembly code, yielding a savings of 34 bytes in 7 steps.