Arg substitution leaves placeholder marker in the stream for
empty arguments. Those need to be skipped when searching for
a fnlike macro invocation in the replacement list itself. See
testcase.
Also, retain storage qualifiers in type_decl, in particular
also for function pointers. This allows to get rid of this
very early hack in decl()
type.t |= (btype.t & VT_STATIC); /* Retain "static". */
which was to fix the case of
int main() { static int (*foo)(); ...
Also:
- missing __declspec(dllimport) is an error now
- except if the symbol is "_imp__symbol"
- demonstrate export/import of data in the dll example (while
'extern' isn't strictly required with dllimport anymore)
- new function 'patch_storage()' replaces 'weaken_symbol()'
and 'apply_visibility()'
- new function 'update_storage()' applies storage attributes
to Elf symbols.
- put_extern_sym/2 accepts new pseudo section SECTION_COMMON
- add -Wl,-export-all-symbols as alias for -rdynamic
- add -Wl,-subsystem=windows for mingw compatibility
- redefinition of 'sym' error for initialized global data
Commit bb93064 changed the path seperator from ':' to ';', which was
likely accidental. While path seperator on Windows is generally ';', the
Makefile clearly expects a posix-y shell, and in such environments the
separator is ':'.
This fixes the test run in MSYS2 and MSYS(1) environments, which got
broken on bb93064 .
supports building cross compilers on the fly without need
for configure --enable-cross
$ make cross # all compilers
$ make cross-TARGET # only TARGET-compiler & its libtcc1.a
with TARGET one from
i386 x86_64 i386-win32 x86_64-win32 arm arm64 arm-wince c67
Type 'make help' for more information
since configure supports only native configuration
a file 'cross-tcc.mak' needs to be created manually.
It is included in the Makefile if present.
# ----------------------------------------------------
# Example config-cross.mak:
#
# windows -> i386-linux cross-compiler
# (it expects the linux files in <prefix>/i386-linux)
ROOT-i386 = {B}/i386-linux
CRT-i386 = $(ROOT-i386)/usr/lib
LIB-i386 = $(ROOT-i386)/lib:$(ROOT-i386)/usr/lib
INC-i386 = {B}/lib/include:$(ROOT-i386)/usr/include
DEF-i386 += -D__linux__
# ----------------------------------------------------
Also:
- use libtcc1-<target>.a instead of directories
- add dummy arm assembler
- remove include dependencies from armeabi.c/lib-arm64.c
- tccelf/ld_add_file: add SYSROOT (when defined) to absolute
filenames coming from ld-scripts
the avoidance of mov im32->reg64 wasn't working when reg64 was rax.
While fixing this also fix instructions which had the REX prefix
hardcoded in opcode and so didn't support extended registers which
would have added another REX prefix.
Forgot about it. It allows to compile several
sources (and other .o's) to one single .o file;
tcc -r -o all.o f1.c f2.c f3.S o4.o ...
Also:
- option -fold-struct-init-code removed, no effect anymore
- (tcc_)set_environment() moved to tcc.c
- win32/lib/(win)crt1 minor fix & add dependency
- debug line output for asm (tcc -c -g xxx.S) enabled
- configure/Makefiles: x86-64 -> x86_64 changes
- README: cleanup
usage:
tcc -ar [rcsv] lib files...
tcc -impdef lib.dll [-v] [-o lib.def]
also:
- support more files with -c: tcc -c f1.c f2.c ...
- fix a bug which caused tcc f1.c f2.S to produce no asm
- allow tcc -ar @listfile too
- change prototype: _void_ tcc_set_options(...)
- apply -Wl,-whole-archive when a librariy is given
as libxxx.a also (not just for -lxxx)
Today by accident i had to deal with linker problems of some
software and found an issue that mentioned DT_RUNPATH, which
mentioned that DT_RPATH is legacy and searched for
$LD_LIBRARY_PATH, whereas the newer DT_RUNPATH is searched
thereafter. Completely unencrypted! Well. For what's it worth,
i for one am astonished because of course i want to override
$LD_LIBRARY_PATH, but it surely has its merites, smart people came
to the conclusion, did they.
The attached diff below seems to be sufficient to support
DT_RUNPATH instead of DT_RPATH with tcc(1). But i have no insight
in what --enable-new-dtags is supposed to change in addition, so
i wonder.
Ciao!
--steffen
libtcc.c | 2 ++
tcc-doc.texi | 4 ++++
tcc.h | 1 +
tccelf.c | 3 ++-
4 files changed, 9 insertions(+), 1 deletion(-)
- lib/Makefile: add (win)crt1_w.o
- crt1.c/_runtmain: return to tcc & only use for UNICODE
(because it might be not 100% reliable with for example
wildcards (tcc *.c -run ...)
- tccrun.c/tccpe.c: load -run startup_code only if called
from tcc_run(). Otherwise main may not be defined. See
libtcc_test.c
- tests2/Makefile: pass extra options in FLAGS to allow
overriding TCC
Also:
- tccpe.c: support weak attribute. (I first tried to solve
the problem above by using it but then didn't)
'-run' suported. argvs are converted.
But don't use compliled Unicode CLI exe-file to get inputs interactively in other codepage!
Please add other compliling supports than 'build-tcc.bat' (Who is good at them).
- define_start: set above preprocess_start because now
preprocess_start is defining macros.
- free "cmd_include_files"
- free defines always (after error-longjmps)
- close all files (after error-longjmps)
- tccpe.c: free imports always
- libtcc.c: call tcc_memstats only after all states have
been deleted.
- tccgen.c/tcc.h: allow function declaration after use:
int f() { return g(); }
int g() { return 1; }
may be a warning but not an error
see also 76cb1144ef
- tccgen.c: redundant code related to inline functions removed
(functions used anywhere have sym->c set automatically)
- tccgen.c: make 32bit llop non-equal test portable
(probably not on C67)
- dynarray_add: change prototype to possibly avoid aliasing
problems or at least warnings
- lib/alloca*.S: ".section .note.GNU-stack,"",%progbits" removed
(has no effect)
- tccpe: set SizeOfCode field (for correct upx decompression)
- libtcc.c: fixed alternative -run invocation
tcc "-run -lxxx ..." file.c
(meant to load the library after file).
Also supported now:
tcc files ... options ... -run @ arguments ...
Some code in gen_opl was depending on a gvtst label
which in nocode_wanted mode is not set.
This was causing vstack leaks and crashes with for example
long long ll;
if (0)
return ll - 10 < 0;
Also:
- in tests: generate .expect files only if not yet present,
because
1) some files were adjusted manually
2) switching git branche might change timestamps and
cause unwanted update
In particular:
-c <compiler> : Allow using tcc to compile itself
-i <dir> : Create installation in dir
Summary:
usage: build-tcc.bat [ options ... ]
options:
-c prog use prog (gcc or tcc) to compile tcc
-c "prog options" use prog with options to compile tcc
-t 32/64 force 32/64 bit default target
-v "version" set tcc version
-i dir install tcc into dir
-d create tcc-doc.html too (needs makeinfo)
- we're now exporting tcc_prefixed symbols from libtcc only
- On windows, the msvcrt startup code would remove backslashes
from commandline arguments such as
-DFOO=\"foo\"
which would appear in argv as
-DFOO="foo"
Therefor before passing these to spawnvp, we need to restore
the backslashes.
Also:
- on windows i386 and x86-64, structures of size <= 8 are
NOT returned in registers if size is not one of 1,2,4,8.
- cleanup: put all tv-push/pop/swap/rot into one place
There seems nothing wrong. With
int t1 = 176401255;
float f = 0.25;
int t2 = t1 * f; // 176401255 * 0.25 = 44100313.75
according to the arithmetic conversion rules, the number
176401255 needs to be converted to float, and the compiler
can choose either the nearest higher or nearest lower
representable number "in an implementation-defined manner".
Which may be 176401248 or 176401264. So as result both
44100312 and 44100313 are correct.
This reverts commit 664c19ad5e.
In the previous implementation, the rx mapping was never
used. Therefor it is assumed that it is not needed.
With only one mapping there is no reason to use a real
/tmp/.xxxx file either as we can use an anonymous mapping.
Based on feedback from grischka, this commit
(1) updates the name of the alignment constant to be more specific
(2) aligns all sections, including the first (which previosly was
not aligned)
(3) reduces the x86-64 alignment from 512 to 64 bytes.
The original x86-64 alignment of 512 bytes was based on testing.
After ensuring that the initial section is also aligned, the same
tests indicated that 64 bytes is sufficient.
Tests found excessive cache thrashing on x86-64 architectures. The
problem was traced to the alignment of sections. This patch sets up
an architecture-specific alignment of 512 bytes for x86-64 and 16
bytes for all others. It uses preprocessor directives that, hopefully,
make it easy to tweak for other architectures.
