[Tinycc-devel] Some possible bugs in tcc

[Bill Hart]

Hi all,

I've recently been playing with TCC, specifically to build MPIR and
FLINT on Windows (see http://www.flintlib.org and
http://www.mpir.org). The latter is a fork of the GNU GMP project, the
former a number theory library.

Along the way I have discovered what I think are some bugs in tcc and
I also want to report my experiences (which have been very positive).

Firstly, may I say I am mightily impressed with TCC. It's been very
easy for me to port my projects to use it! Well done, keep up the good
work.

Anyhow, to the bugs and other difficulties:

1) In the MPIR file longlong.h (which is derived from original GMP
code - copyright belongs to FSF blah, blah, blah), the following
inline assembly macros do not assemble with tcc (though they do with
gas):

#define add_limbs(sh, sl, ah, al, bh, bl) \
  __asm__ ("addl %5,%k1\n\tadcl %3,%k0"                                 \
           : "=r" (sh), "=&r" (sl)                                      \
           : "0"  ((unsigned long)(ah)), "g" ((unsigned long)(bh)),             
        \
             "%1" ((unsigned long)(al)), "g" ((unsigned long)(bl)))

#define sub_limbs(sh, sl, ah, al, bh, bl) \
  __asm__ ("subl %5,%k1\n\tsbbl %3,%k0"                                 \
           : "=r" (sh), "=&r" (sl)                                      \
           : "0" ((unsigned long)(ah)), "g" ((unsigned long)(bh)),              
        \
             "1" ((unsigned long)(al)), "g" ((unsigned long)(bl)))

2) In the file mpn/x86/k7 in MPIR, the line:

imull   0xAAAAAAAB, %eax, %edx

assembles as

imull   0xAAAAAAAB, %eax, %eax

The correct opcodes should be

69 d0 ab aa aa aa

The following are not bugs as such, but issues I have noted along the way:

3) When building a dll from multiple object files coming from assembly
files assembled with tcc, if the same name is used for labels in
different assembly files, tcc see these as duplicate labels, gcc does
not.

4) In some instances tcc assembles jumps (probably forward jumps) as
long jumps when a short jump is used by gcc. Actually I am not 100%
sure if this may be due to number 5 below bloating code, making a
short jump no longer appropriate.

5) tcc encodes the constant $-1 as FFFFFFFF whereas gas uses FF and
makes use of automatic sign extension.

6) tcc object files (ELF-32) don't disassemble by default with objdump
(i.e. without the -D option). It's as though everything has been put
in a data section or something, so it doesn't recognise it as code.
gas object files disassemble by default.

7) Loops which contain print statements sometimes do not print
anything until the entire loop has completed. This may have something
to do with timing code. I had something like:

for (i = 0; i < 100; i++)
{
   t = clock();
   // do something which takes a long time
   printf("time taken for iteration %d was %ld\n", i, clock()-t);
}

Nothing printed until the entire 100 iterations was complete.

8) The most difficult issue to workaround when porting FLINT was the
fact that tcc does not support:

for (unsigned long i = 0; i < count; i++)

I wrote a sed script which automatically replaced this with:

unsigned long i;
for (i = 0; i < count; i++)

But of course this doesn't work in the following situations, which
then have to be modified by hand per instance

a) When the for loop follows an if statement or another control
statement, such as another for loop, without a block, e.g.

for (long i = 0; i < 100; i++)
   for (long j = 0; j < 100; j++)

b) It also causes problems when multiple for statements in the same
block use the same variable

 for (long i = 0; i < 100; i++)
     blah

blah blah

for (long i = 0; i < 100; i++)
   blah blah blah

c) Case where more than one variable is used in a for loop initialisation, e.g.

for (long i = 0, j = 0; i < 100; i++, j += 20)

Anyhow, after just about a week's work, I now have the entire FLINT
test suite passing and MPIR working (the test suite is not ported
yet).

Some final questions. When 64 bit windows is finally supported by tcc,
do you plan to support linux or windows calling conventions?

Also, is there any plan to support other assembly formats, e.g. intel
syntax, or yasm code? I had vaguely thought I might add support for
the latter to tcc some time this year if I found the time and if there
was interest.

Bill.