mirror of
https://github.com/frida/tinycc
synced 2025-01-03 02:24:24 +03:00
c8ca64d28b
this is a bit complicated: for i386 and x86-64 we really need to extend return values ourself, as the common code now does. For arm64 this at least preserves old behaviour. For riscv64 we don't have to extend ourself but can expect things to be extended up to int (this matters for var-args tests, when the sign-extension to int64 needs to happen explicitely). As the extensions are useless, don't do them. And for arm32 we actually can't express GCC behaviour: the callee side expects the return value to be correctly extended to int32, but remembers the original type. In case the ultimate target type for the call result is only int, no further extension is done. But in case the target type is e.g. int64 an extension happens, but not from int32 but from the original type. We don't know the ultimate target type, so we have to choose a type to put into vtop: * original type (plus VT_MUSTCAST) - this looses when the ultimate target is int (GCC: no cast, TCC: a cast) * int (without MUSTCAST) - this looses when the ultimate target is int64 (GCC: cast from original type, TCC: cast from int) This difference can only be seen with undefined sources, like the testcases, so it doesn't seem worthwhile to try an make it work, just disable the test on arm and choose the second variant as that generates less code. |
||
---|---|---|
examples | ||
include | ||
lib | ||
tests | ||
win32 | ||
.gitignore | ||
arm64-gen.c | ||
arm64-link.c | ||
arm-asm.c | ||
arm-gen.c | ||
arm-link.c | ||
c67-gen.c | ||
c67-link.c | ||
Changelog | ||
CodingStyle | ||
coff.h | ||
configure | ||
conftest.c | ||
COPYING | ||
elf.h | ||
i386-asm.c | ||
i386-asm.h | ||
i386-gen.c | ||
i386-link.c | ||
i386-tok.h | ||
il-gen.c | ||
il-opcodes.h | ||
libtcc.c | ||
libtcc.h | ||
Makefile | ||
README | ||
RELICENSING | ||
riscv64-gen.c | ||
riscv64-link.c | ||
stab.def | ||
stab.h | ||
tcc-doc.texi | ||
tcc.c | ||
tcc.h | ||
tccasm.c | ||
tcccoff.c | ||
tccelf.c | ||
tccgen.c | ||
tcclib.h | ||
tccpe.c | ||
tccpp.c | ||
tccrun.c | ||
tcctok.h | ||
tcctools.c | ||
texi2pod.pl | ||
TODO | ||
VERSION | ||
x86_64-asm.h | ||
x86_64-gen.c | ||
x86_64-link.c |
Tiny C Compiler - C Scripting Everywhere - The Smallest ANSI C compiler ----------------------------------------------------------------------- Features: -------- - SMALL! You can compile and execute C code everywhere, for example on rescue disks. - FAST! tcc generates optimized x86 code. No byte code overhead. Compile, assemble and link about 7 times faster than 'gcc -O0'. - UNLIMITED! Any C dynamic library can be used directly. TCC is heading toward full ISOC99 compliance. TCC can of course compile itself. - SAFE! tcc includes an optional memory and bound checker. Bound checked code can be mixed freely with standard code. - Compile and execute C source directly. No linking or assembly necessary. Full C preprocessor included. - C script supported : just add '#!/usr/local/bin/tcc -run' at the first line of your C source, and execute it directly from the command line. Documentation: ------------- 1) Installation on a i386/x86_64/arm Linux/OSX/FreeBSD host ./configure make make test make install Notes: For OSX and FreeBSD, gmake should be used instead of make. For Windows read tcc-win32.txt. makeinfo must be installed to compile the doc. By default, tcc is installed in /usr/local/bin. ./configure --help shows configuration options. 2) Introduction We assume here that you know ANSI C. Look at the example ex1.c to know what the programs look like. The include file <tcclib.h> can be used if you want a small basic libc include support (especially useful for floppy disks). Of course, you can also use standard headers, although they are slower to compile. You can begin your C script with '#!/usr/local/bin/tcc -run' on the first line and set its execute bits (chmod a+x your_script). Then, you can launch the C code as a shell or perl script :-) The command line arguments are put in 'argc' and 'argv' of the main functions, as in ANSI C. 3) Examples ex1.c: simplest example (hello world). Can also be launched directly as a script: './ex1.c'. ex2.c: more complicated example: find a number with the four operations given a list of numbers (benchmark). ex3.c: compute fibonacci numbers (benchmark). ex4.c: more complicated: X11 program. Very complicated test in fact because standard headers are being used ! As for ex1.c, can also be launched directly as a script: './ex4.c'. ex5.c: 'hello world' with standard glibc headers. tcc.c: TCC can of course compile itself. Used to check the code generator. tcctest.c: auto test for TCC which tests many subtle possible bugs. Used when doing 'make test'. 4) Full Documentation Please read tcc-doc.html to have all the features of TCC. Additional information is available for the Windows port in tcc-win32.txt. License: ------- TCC is distributed under the GNU Lesser General Public License (see COPYING file). Fabrice Bellard.