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

[Bill Hart]

2009/12/6 grischka <address@hidden>:
> 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?

Unless I have done something silly, it doesn't assemble at all. Just
set unsigned long variables ah, al, bh, bl to random values and invoke
the macro and it won't assemble.

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

Ok.

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

Ok thanks, wasn't aware of that.

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

Yes. gcc, the Sun CC and numerous other compilers consider it part of
the standard. I don't have a copy of the standard itself, but there
are many references online which mention this, e.g. (without spending
too much time looking for something more canonical):

http://zone.ni.com/devzone/cda/tut/p/id/8764#toc2

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

Sure.

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

Ok.

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

Ok. But I'm not sure I understand. Do you mean that you don't like the
idea at all?

Yasm runs on linux and Windows and is becoming more popular. If tcc
also happens to assemble yasm code, then that is another way to
support both projects, no?

The main reason it would be useful to me is that the Windows 64
assembler code in MPIR is in yasm format.

Anyhow if it is only useful to me, I guess I won't bother with it.

Bill.