Re: [Tinycc-devel] codegen bug with tcc x86_64 ?

[Michael Matz]

Hi,

On Sun, 31 Dec 2017, foobar wrote:

> > please find attached code that exposes a codegen bug in tcc, resulting 
> > in an endless loop in libtom's embedded bigmath code on x86_64 musl 
> > linux.
> >
> > (note: the code in main() under #if 0 exposes another problem, no 
> > endless loop, but wrong result)
>
> it seems both problems are caused by this line: typedef unsigned long 
> mp_word __attribute__((mode(TI)));

Meh, 128bit integer types :-/

> when i remove the attribute, GCC exposes the exact same behaviour.

Due to the definition of DIGIT_BIT and MP_64BIT that rely on the 
128bit-ness of mp_word in the testcase.

> so if tcc doesnt support this attribute (from [1] TImode - "Tetra 
> Integer" (?) mode represents a sixteen-byte integer (128bit type)), 
> wouldn't it be better to err out during the compilation, than generating 
> unexpected code?

Actually TCC does warn, but only with -Wunsupported :-/  And the reason it 
warns is because of the unknown "mode" attribute.  If it had been __mode__ 
in the source it would have warned about the unknown TI mode used, even 
unconditionally:

% echo "typedef unsigned long int128 __attribute__((__mode__(TI)));" | tcc -c -
<stdin>:1: warning: __mode__(TI) not supported

vs.

% echo "typedef unsigned long int128 __attribute__((mode(TI)));" | tcc -c 
-Wunsupported -
<stdin>:1: warning: 'mode' attribute ignored

We should probably handle "mode" like "__mode__" in tcc (and hence always 
warn in this case).

Of course, proper support for QLONG (as TCC calls this), at least on 64bit 
architectures, would be nice.  The support is mostly there in TCC, as it's 
basically the same like supporting 64bit integers on 32bit architectures. 
Just the wiring is missing.


Ciao,
Michael.