Re: [Tinycc-devel] Some possible bugs in tcc

[grischka]

Bill Hart wrote:
> 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).
> ...
> 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)))

Can you show a testcase for such macro?

> 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

Maybe I fixed this on the "mob" branch.
http://repo.or.cz/w/tinycc.git/commitdiff/e500c911

> 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.

Hm.

> 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.

Hm.

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

Hm.

> 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.

Hm.

> 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.

Has nothing to do with tcc.  printf is from msvcrt and will flush
on newlines, but only in console windows (i.e. _isatty(stdout->file))

> 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++)

Hm. Is that C99?

> 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).

Cool, I hope you run it from time to time to check tcc for regressions.

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

64-bit windows it on master/mob.  Of course with windows calling
conventions, on windows.

> 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.

Well, becoming a perfect yasm replacement is maybe not the number one
goal for tinycc.  ;)

> Bill.

--- grischka