Re: [Tinycc-devel] Bug in _Bool return values

[Michael Matz]

Hi,

On Mon, 4 Feb 2019, Louis Botha wrote:

> The scenario that broke for me was calling a function that only set the AL
> register on return, leaving the rest of EAX undefined, yet TCC checked the
> whole of EAX for the _Bool return value (true came out correct, but false
> tested as true when the undefined-bits were non-0)

Yeah, TCC currently doesn't correctly implement the i386/x86-64 psABIs 
regarding when to extend sub-int return values.  It's consistent with 
itself, but not with the official psABI and other compilers.  For i386 and 
x86-64-win only handling _Bool was wrong, for x86-64-elf all sub-int types 
were wrong.

Unfortunately TCCs code generator currently always requires int (or 
larger) types in intermediate registers, which naturally only leads to 
extensions on the callee side.  Adding the extension on the caller 
side (as mandated by the psABI) introduces a double-extension.  If we want 
to fix the compatibility bug we can't easily avoid this generally.

Too bad, let's bite the bullet and fix the bug anyway, at the expense of 
some useless extensions within code purely compiled by TCC.  That's done 
in mob now.


Ciao,
Michael.


>  
>
> Assigning the _Bool return value to a _Bool variable and then checking that
> variable instead of the return value is one confirmed workaround (the
> emitted TCC code then uses just AL to generate a full EAX before checking
> EAX), but I think I have found the proper fix:
>
>  
>
> Add “case VT_BOOL:” as shown here, just after line 365 of i386-gen.c:
>
>  
>
> switch (rt & VT_BTYPE) {
>
>     case VT_BYTE:
>
>     case VT_BOOL:
>
>  
>
> This modification fixed the problem I was having, I *think* the line in
> x86_64-gen.c that needs to change for the equivalent there is this (@ line
> 934):
>
>  
>
> else if (bt == VT_BYTE || bt == VT_BOOL)
>
>  
>
> Sorry, I don’t know the other architectures or TCC in general well enough to
> comment on other places that may also need this fix.
>
>  
>
> Best regards,
>
> Louis
>
>