A VLA is not really an array, it's a pointer-to-an-array.
Making this explicit allows us to back out a few parts
of the original VLA patch and paves the way for the next
part of the fix, where a VLA will be stored on the runtime
stack as a pointer-to-an-array, rather than on the compile-
time stack as a Sym*.
test target in Makefile does not depend on tcc.
i'm not sure why, but i can think of at least one
good reason. in my local tree I have it modified
to do so, but somehow inadvertently reverted that
so when i did "make test" before committing, it
didn't actually test my changes. sorry.
previously, tcc would accept a prototype of a function returning
an array, but not giving those functions bodies nor calling them.
it seems that gcc has never supported them, so we should probably
just error out... but it's possible that someone already using
tcc includes some header that contains an unused prototype for
one, so let's continue to support that.
- fix my prev commit:
put declaration above statements to stay c89 compatible
- replace commit by a blank
#define con(a, b) a/**/b
this should yield a b, not ab
We need a ' ' after subst of m in the following case
#define m(name,r) name ## r
#define m0(a,b,c) int m(a,b) c
#define m1(a,b,c) int m(a,b)c
m0(a, b, c);
m1(a, b, c);
To make this the default, enable this line in libtcc.c:tcc_new:
#if defined(TCC_TARGET_PE) && 0
s->leading_underscore = 1;
and then recompile tcc and also libtcc1.a
Add support for asm labels for variables, that is the ability to rename
a variable at assembly level with __asm__ ("newname") appended in
its declaration.
See http://gcc.gnu.org/onlinedocs/gcc-4.4.4/gcc/Asm-Labels.html for more
details.
- Fix function assembly label mechanism introduced in commit
9b09fc376e to only accept alternative
name for function declaration.
- merge the code with the one introduced in commit
264a103610.
- Don't memorize token for asm label but directly the asm label.
Error out on static function without file scope and give an explaination
to the user
This is a rewrite of e9406c09a3 but
considering problems raised about static local function pointers in
632ee5a540.
