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.
There are probably still issues on x86-64 I've missed.
I've added a few new tests to abitest, which fail (2x long long and 2x double
in a struct should be passed in registers).
abitest now passes; however test1-3 fail in init_test. All other tests
pass. I need to re-test Win32 and Linux-x86.
I've added a dummy implementation of gfunc_sret to c67-gen.c so it
should now compile, and I think it should behave as before I created
gfunc_sret.
I expect that Linux-x86 is probably fine. All other architectures
except ARM are definitely broken since I haven't yet implemented
gfunc_sret for these, although replicating the current behaviour
should be straightforward.
Only one test so far, which fails on Windows (with MinGW as the native
compiler - I've tested the MinGW output against MSVC and it appears the
two are compatible).
I've also had to modify tcc.h so that tcc_set_lib_path can point to the
directory containing libtcc1.a on Windows to make the libtcc dependent
tests work. I'm not sure this is the right way to fix this problem.
Modified tcctest.c so that it uses 'double' in place of 'long double'
with MinGW since this is what TCC does, and what Visual C++ does. Added
an option -norunsrc to tcc to allow argv[0] to be set independently of
the compiled source when using tcc -run, which allows tests that rely on
the value of argv[0] to work in out-of-tree builds.
Also added Makefile rules to automatically update out-of-tree build
Makefiles when in-tree Makefiles have changed.
Some files installed are not generated so need to be copied from the
source tree rather than the build tree.
I also switched texi2html for makeinfo --html since texi2html is
apparently unmaintained.
On some architectures, ARM for instance, the data and instruction caches
are not coherent with each other. This is a problem for the -run feature
since instructions are written in memory, and are thus written in the
data cache first and then later flushed to the main memory. If the
instructions are executed before they are pushed out of the cache, then
the processor will fetch the old content from the memory and not the
newly generated code. The solution is to flush from the data cache all
the data in the memory region containing the instructions and to
invalidate the same region in the instruction cache.
Thomas Preud'homme