There were two errors in the arithmetic imm8 instruction. They accept
only REGW, and in case the user write a xxxb opcode that variant
needs to be rejected as well (it's not automatically rejected by REGW
in case the destination is memory).
BUGZILLA:
interfacing with other compilers
extend the return value to the whole register if necessary.
visual studio and gcc do not always set the whole eax register
when assigning the return value of a function.
We've encountered wrong execution results on i386 platforms with an
application that uses both code compiled with TCC and code compiled
with other compilers (namely: Visual Studio on Windows, and GCC on
Linux).
When calling a function that returns an integer value shorter than 32
bits, TCC reads the return value from the whole EAX register,
although the code generated by the other compilers can only sets AL
for 8 bit values or AX for 16 bits values, and the rest of EAX can be
anything.
We worked around this with the attached patch on i386 for the version
0.9.26, but we did not look at other platforms to find if there are
similar issues.
Two things: negative constants were rejected (e.g. "add $-15,%eax").
Second the insn order was such that the arithmetic IM8S forms
weren't used (always the IM32 ones). Switching them prefers those
but requires a fix for size calculation in case the opcodes were
OPC_ARITH and OPC_WLX (whose size starts with 1, not zero).
This may be used to preprocess Fabrice Bellards initial revision
in this repository to demonstrate its capability to compile and
run itself (on i386 32-bit linux or windows).
Initial revision: 27f6e16bae
Also needed:
* an empty stdio.h
* a wrapper named tc.c with
void expr(void);
void decl(int);
void next(void);
#include "tcc.c"
* an hello.c such as
int main()
{
printf("Hello World\n");
return 0;
}
All files with unix LF only lines. Then ...
* preprocess the source
$ tcc -E -P10 -I. tcc.c -o tc1.c
* compile the compiler
$ tcc -w -I. tc.c -o tc -ldl
* run it to compile and
run itself to compile and
run itself to compile and
run itself to compile and
run hello.c
$ ./tc tc1.c tc1.c tc1.c hello.c
--> Hello World!
------------------------------------------------------
* On i386 windows this may be added to the tc.c wrapper
#ifdef _WIN32
#include <windows.h>
void *dlsym(int x, const char *func)
{
if (0 == strcmp(func, "dlsym"))
return &dlsym;
return GetProcAddress(LoadLibrary("msvcrt"), func);
}
#endif
The check for structs was too late and on amd64 and aarch64 could
lead to accepting and then asserting with code like:
struct S {...} s;
char *c = (char*)0x10 - s;
Fix it to actually be able to parse 64bit immediates (enlarge
operand value type). Then, generally there's no need for accepting
IM64 anywhere, except in the 0xba+r mov opcodes, so OP_IM is
unnecessary, as is OPT_IMNO64. Improve the generated code a bit
by preferring the 0xc7 opcode for im32->reg64, instead of the
im64->reg64 form (which we therefore hardcode).
Traditional behaviour on x86-64 is to encode the relocation
addend in r_addend, not in the relocated field (after all,
that's the reason to use RELA relocs to begin with). Our
linker can deal with both, other linkers as well. But using
e.g. the GNU assembler one can detect differences (equivalent
code in the end, but still a difference).
Now there's only a trivial difference in tests/asmtest.S
(having to do with ordering of prefixes).
A bag of assembler fixes, to be either compatible with GAS
(e.g. order of 'test' operands), accept more instructions,
count correct foo{bwlq} variants on x86_64, fix modrm/sib bytes
on x86_64 to not use %rip relative addressing mode, to not use
invalid insns in tests/asmtest.S for x86_64.
Result is that now output of GAS and of tcc on tests/asmtest.S
is mostly the same.
Insert a space when it is required to prevent mistokenisation of
the output, and also in a few cases where it is not strictly
required, imitating GCC's behaviour.
... for fast redeclaration checks
Also, check function parameters too:
void foo(int a) { int a; ... }
Also, try to fix struct/union/enum's on different scopes:
{ struct xxx { int x; };
{ struct xxx { int y; }; ... }}
and some (probably not all) combination with incomplete
declarations "struct xxx;"
Replaces 2bfedb1867
and 07d896c8e5
Fixes cf95ac399c
A constant expression removed from the loop.
If subroutine have 50000+ local variables, then currently
compilation of such code takes obly 15 sec. Was 2 min.
gcc-4.1.2 compiles such code in 7 sec. pcc -- 3.44 min.
A test generator:
#include <stdio.h>
int main() {
puts("#include <stdio.h>"); puts("int main()"); puts("{");
for (int i = 0; i < 50000; ++i) printf("int X%d = 1;\n", i);
for (int i = 0; i < 50000; ++i) puts("scanf(\"%d\", &X0);");
puts("}");
return 0;
}
don't catch redefinition for local vars. With this option on
tcc accepts the following code:
int main()
{
int a = 0;
long a = 0;
}
But if you shure there is no problem with your local variables,
then a compilation speed can be improved if you have a lots of
the local variables (50000+)
Various x86 asm fixes: 64bit lcall/ljmp like 32bit a commit before,
xchgw accepted wrong operands on 32 and 64bit, and 64bit used
0x40/0x48+reg for incw/decw, but those are REX prefixes, not
instructions.
* correct -E output for the case ++ + ++ concatenation
do this only for expanded from macro string
and only when tcc_state->output_type == TCC_OUTPUT_PREPROCESS
- uses new `TinyAlloc`-ators for small `TokenSym`, `CString` and
`TokenString` instances
- conditional `TAL_DEBUG` for mem leaks and double frees detection
- on `TAL_DEBUG` collects allocation origin (file + line)
- conditional `TAL_INFO` for allocators stats (in release mode too)
- chain a new allocator twice current capacity on buffer exhaustion
parse_print_line_comment() and parse_print_comment() are
combined and made more simply:
* don't worry about speed with -E option
* don't handle straya in comments
Do we need to handle strays in regular
parse_line_comment() and
parse_comment() ?
seyko