Lionel Debroux (./8) :
The routines themselves went through Joey's extra-strong test suite, but I forgot that Joey's testcase contains its own C protoypes for the routines, and the code just happened to work with the compilation options of the TPR. Add -mregparm and the testcase starts failing.

That proves that your testing was inadequate. 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. And if the test passed, I don't need the testcase anymore, so I delete it.

You're making the case of what we have stated for several months: TIGCC's test suite is dauntingly and appallingly incomplete. Fact.

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.

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 and fixed mostly bugs nobody actually encountered in practical use (or they wouldn't have stayed unnoticed for years). Bugginess can't be measured by a bug count alone, you also have to take the impact of the bugs into account.

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.

This is exactly what the change you're suggesting would yield in the TPR, and I fail to see a good reason for that change: assembly blocks in C files work just fine, they have worked just fine for years, and it would be a bug if they stopped working.

The TIGCCLIB coding convention is that assembly functions go into assembly files (i.e. .s files, as A68k code is not allowed in TIGCCLIB), not C files. Just looking at the existing functions would have told you that. 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.

Even if you don't want to merge our bsearch.c as is for whatever reason, you still had better fix, sooner than later, the bsearch.c in TIGCC (which has been broken since before the TIGCC CVS repository was created), and credit PpHd for finding the bug while doing the job that yourself didn't do: testing
the routine (for PedroM)

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