Prior to this commit, params could use some registers that do not appear
in the value stack. Therefore when generating function call, one of such
register could be reused, leading to wrong parameter content. This
happens when a structure is passed via core register, as only the first
register would appear in the value stack.
* Correctly align stack in case of structure split between core
registers and stack
* Correctly reclaim stack space after function call in the case where
the stack needed padding to be aligned at function call.
Wrap runtime_main as per its declaration in tcc.h.
Fix preprocessor check for TCC_ARM_EABI macro definition.
Signed-off-by: Joseph Poirier <jdpoirier@gmail.com>
Allocation of struct in core and/or VFP registers on ARM is made by
manipulating the value stack to create 3 distinct zones: parameters
allocated on stack, parameters of type struct allocated in core
registers and parameters of type struct allocated in VFP registers.
Parameters of primitive type can be in any zone. This commit change the
order of the zones from stack, VFP, core to stack, core, VFP (from
highest addresses to lowest ones) in order to correctly deal the
situation when structures are allocated both in core and VFP registers.
TLS support in tinyCC is absolutely not ready:
- segment register not select in load and store
- no relocation added for computing offset of per-thread symbol
- no support for TLS-specific relocations
- no program header added as per Drepper document about TLS
This reverts commit 1c4afd1350.
Commit 9382d6f1 ("Fix lib, include, crt and libgcc search paths",
07-09-2013) inadvertently included an initial empty entry to the
CONFIG_TCC_SYSINCLUDEPATHS variable (for non win32 targets). In
addition to an empty line in the 'tcc -vv' display, this leads
to the preprocessor attempting to read an include file from the
root of the filesystem (i.e. '/header.h').
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Prevent the following code from compiling:
enum color {RED, GREEN, BLUE};
enum color {R, G, B};
int main()
{
return R;
}
Reported-by: John Haque <j.eh@mchsi.com>
tcc.c:
process.h:177:20: note: expected 'char * const*' but argument is of type 'char const*const*'
tccpe.c:
Add the possibility to use noname functions by ordinal.
use def file: "AliasName @n"
build-tcc.bat:
1. Enable 32 bits mode on 64 bits OS.
2. build doc.
_parseLibs.bat:
Convenient to use "*.def + *.c" instead of *.a, just use -l*
_tcc.bat:
a practice of _parseLibs.bat
Signed-off-by: YX Hao <lifenjoiner@163.com>
Use one more bit in AttributeDef to differenciate between declared
function (only its prototype is known) and defined function (its body is
also known). This allows to generate an error in cases like:
int f(){return 0;}
int f(){return 1;}
For "tcc -run file.c", I was trying to initialize the FP control
in a function in libtcc1.a (_runmain) before calling main.
Unfortunately that turned out to cause problems with for example
libtcc_test since such usage doesn't necessarily define a 'main'
function.
So for tcc -run we're back to relying on the FP control word
that is set in the startup code of tcc.exe rsp. libtcc.dll.
This fixes part of commit 73faaea227
- Use runtime function for conversion
- Also initialize fp with tcc -run on windows
This fixes a bug where
double x = 1.0;
double y = 1.0000000000000001;
double z = x < y ? 0 : sqrt (x*x - y*y);
caused a bad sqrt because rounding precision for the x < y comparison
was different to the one used within the sqrt function.
This also fixes a bug where
printf("%d, %d", (int)pow(10, 2), (int)pow(10, 2));
would print
100, 99
Unrelated:
win32: document relative include & lib lookup
win32: normalize_slashes: do not mirror silly gcc behavior
This reverts part of commit 8a81f9e103
winapi: add missing WINAPI decl. for some functions
It has been discussed on the list whether it would be good
to relicense TinyCC under a more permissive BSD-like license.
The discussion started here:
http://lists.gnu.org/archive/html/tinycc-devel/2013-04/msg00052.html
Opinions varied but mostly were positive so it appears to
be worth to start the process and see how far we can get.
For that purpose I've committed a new file RELICENSING with the
suggested new license clause and a list for people to confirm
their agreement (or disagreement).
If you have contributed to TinyCC in the past, in particular if
you are one of the copyright owners for an entire file, please
add yourself to that file (rsp. replace the question mark) and
commit the change to the "mob" brancn with log message:
Relicensing TinyCC
Thanks.
VLA storage is now freed when it goes out of scope. This makes it
possible to use a VLA inside a loop without consuming an unlimited
amount of memory.
Combining VLAs with alloca() should work as in GCC - when a VLA is
freed, memory allocated by alloca() after the VLA was created is also
freed. There are some exceptions to this rule when using goto: if a VLA
is in scope at the goto, jumping to a label will reset the stack pointer
to where it was immediately after the last VLA was created prior to the
label, or to what it was before the first VLA was created if the label
is outside the scope of any VLA. This means that in some cases combining
alloca() and VLAs will free alloca() memory where GCC would not.
long double arguments require 16-byte alignment on the stack, which
requires adjustment when the the stack offset is not an evven number of
8-byte words.
I really should do this when less tired; I keep breaking one platform
while fixing another. I've also fixed some Windows issues with tcctest
since Windows printf() uses different format flags to those on Linux,
and removed some conditional compilation tests in tcctest since they
now should work.
I removed the XMM6/7 registers from the register list because they are not used
on Win64 however they are necessary for parameter passing on x86-64. I have now
restored them but not marked them with RC_FLOAT so they will not be used except
for parameter passing.
Also made XMM0-7 available for use as temporary registers, since they
are not used by the ABI. I'd like to do the same with RSI and RDI but
that's trickier since they can be used by gv() as temporary registers
and there isn't a way to disable that.
All tests pass. I think I've caught all the cases assuming only XMM0 is
used. I expect that Win64 is horribly broken by this point though,
because I haven't altered it to cope with XMM1.
I've had to introduce the XMM1 register to get the calling convention
to work properly, unfortunately this has broken a fair bit of code
which assumes that only XMM0 is used.
