[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Michael Matz
Subject: Re: [Tinycc-devel] Bug in _Bool return values
Date: Sun, 10 Feb 2019 18:38:17 +0100 (CET)
User-agent: Alpine 2.21 (LSU 202 2017-01-01)


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.



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


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,



reply via email to

[Prev in Thread] Current Thread [Next in Thread]