just for testing. Is it needed? I'm not a MSYS citizen.
run4flat is a tcc fork by David Mertens that knows how to work with
multiple symbol tables. Excelent work. A good descriptions of the
tcc internals inside a code comments.
functionality was broken some time ago and was removed
by the "tccpp: fix issues, add tests"
fix: LINE_MACRO_OUTPUT_FORMAT_NONE in pp_line()
means: output '\n' and not "don't output at all"
In the linux kernel sources:
#ifdef __STDC__
#define SYMBOL_NAME_LABEL(X) X##:
#else
#define SYMBOL_NAME_LABEL(X) X/**/:
#endif
tcc is a STDC compiler and must handle 'X##:' case.
A new version of the MEM_DEBUG will be submitted next. This version is
not depend on the malloc_usable_size() presense in the libc and
print a places where a leaked chunks of memory was allocated.
Author: Philip <pipcet@gmail.com>
Our VLA code can be made a lot simpler (simple enough for
even me to understand it) by giving up on the optimization idea, which
is very tempting. There's a patch to do that attached, feel free to
test and commit it if you like. (It passes all the tests, at least
* give warning if pragma is unknown for tcc
* don't free asm_label in sym_free(),
it's a job of the asm_free_labels().
The above pragmas are used in the mingw headers.
Thise pragmas are implemented in gcc-4.5+ and current
clang.
Usage example: tcc -xc ex5.cgi
From a gcc docs:
You can specify the input language explicitly with the -x option:
-x language
Specify explicitly the language for the following input files
(rather than letting the compiler choose a default based on the file
name suffix). This option applies to all following input files until
the next -x option. Possible values for language are:
c c-header c-cpp-output
c++ c++-header c++-cpp-output
objective-c objective-c-header objective-c-cpp-output
objective-c++ objective-c++-header objective-c++-cpp-output
assembler assembler-with-cpp
ada
f77 f77-cpp-input f95 f95-cpp-input
java
-x none
Turn off any specification of a language, so that subsequent files
are handled according to their file name suffixes (as they are if -x
has not been used at all)
library Cello: http://libcello.org/ which uses `$` and several
variations of as macros.
There is also RayLanguage which also uses it as a macro for a kind of
ObjC style message passing: https://github.com/kojiba/RayLanguage
This is a patch from Daniel Holden.
* define __bound_init as external_global_sym insteed of the compiling
a tiny program
* remove warning about buf[] when CONFIG_TCC_BCHECK is not defined
This is for a case when no '{' is used in the initialization code.
An option name is -fold-struct-init-code. A linux 2.4.26 can't
find initrd when compiled with a new algorithm.
Lets assume that in *.S files a preprocessor directive
follow '#' char w/o spaces between. Otherwise there is
too many problems with the content of the comments.
* tell a right line number in error message
if a #line directive is wrong
* don't print an error message if we preprocess a .S file
and #line directive is wrong. This is the case of
the
# 4026 bytes
comment in *.S file.
* preprocess_skip: skip a line with
if (parse_flags & PARSE_FLAG_ASM_COMMENTS)
p = parse_line_comment(p);
if line starts with # and a preprocessor command not found.
A test program:
#if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
# This repeats until either a device doesn't exist, or until
#endif
* remove a second definition of the TOK_FLAG_* and PARSE_FLAG_*
from the tccpp.c
* define targetos=Windows when --enable-tcc32-mingw, --enable-cygwin, ...
* use TARGETOS insteed HOST_OS when selecting PROGS
* use "$(tccdir)" insteed $(tccdir) on install (spaces in path)
* install tcc.exe too
* produce bcheck.o when cross-compiling too (lib/Makefile)
* force bcheck.o linking by compiling inside tcc_set_output_type()
a dummy program with local array. Otherwise bcheck.o may be not linked.
* replace %xz format specifier with %p in bcheck (don't supported on
Windows)
* call a __bound_init when __bound_ptr_add, __bound_ptr_indir,
__bound_new_region, __bound_delete_region called.
This is because a __bound_init inside ".init" section is not called
on Windows for unknown reason.
* print on stderr a message when an illegal pointer is returned:
there is no segmentation violation on Windows for a program
compiled with "tcc -b"
* remove "C:" subdir on clean if $HOST_OS = "Linux"
* default CFLAGS="-Wall -g -O0" insteed CFLAGS="-Wall -g -O2"
to speed up compilation and more precise debugging.
tcc w/o -g option generate an executable file which format
is not recognized by binutils. It is like stripped one but
binutils don't think so. Solution: generate not stripped
file which can be correctly stripped by external utils.
may be there is a need to handle a -s option and call
a sstrip/strip program to do a job.
------------ libtest ------------
./libtcc_test lib_path=..
<string>:11: warning: implicit declaration of function 'printf'
<string>:13: warning: implicit declaration of function 'add'
------------ test3 ------------
tcctest.c:1982: warning: implicit declaration of function 'putchar'
tcctest.c:2133: warning: implicit declaration of function 'strlen'
- a warning: unnamed struct/union that defines no instances
- allow a nested named struct declaration w/o identifier
only when option -fms-extensions is used
- care about __attribute__ redefinition in the system headers
- an invalid pointer must be returned when (addr >= e->size),
and not (addr > e->size)
A test program:
#include <stdio.h>
#include <stdlib.h>
int main ()
{
int v[10];
fprintf(stderr, "&v[0] = %p\n", &v[0]);
fprintf(stderr, "&v[10] = %p\n", &v[10]);
exit(1);
return 0;
}
// tcc -b test.c
The output before a patch:
&v[0] = 0xbf929d8c
&v[10] = 0xbf929db4
The output after a patch:
&v[0] = 0xbff6e33c
&v[10] = 0xfffffffe
On Linux 32: sizeof(long)=32 == sizeof(void *)=32
on Linux 64: sizeof(long)=64 == sizeof(void *)=64
on Windows 64: sizeof(long)=32 != sizeof(void *)=64
The following program (errno.c) reports errno=2 when run
using "tcc -run errno.c"
#include <errno.h>
#include <stdio.h>
int main(void) { printf("errno=%d\n", errno); return 0; }
A test program (must be compiled by the above version of the tcc):
/* Tickle a bug in TinyC on 64-bit systems:
* the LSB of the top word or ARGP gets set
* for no obvious reason.
*
* Source: a legacy language interpreter which
* has a little stack / stack pointer for arguments.
*
* Output is: 0x8049620 0x10804961c
* Should be: 0x8049620 0x804961c
*/
#include <stdio.h>
#define NARGS 20000
int ARG[NARGS];
int *ARGSPACE = ARG;
int *ARGP = ARG - 1;
main() { printf("%p %p\n", ARGSPACE, ARGP); }
Force to use a NATIVE_DEFINES insteed of the DEFINES for the
native tcc. After this change we have on debian/ubuntu
# ./x86_64-tcc -vv
tcc version 0.9.26 (x86-64, Linux)
install: /usr/local/lib/tcc
crt:
/usr/lib/x86_64-linux-gnu
libraries:
/usr/lib/x86_64-linux-gnu
/usr/lib
/lib/x86_64-linux-gnu
/lib
/usr/local/lib/x86_64-linux-gnu
/usr/local/lib
include:
/usr/local/include/x86_64-linux-gnu
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
/usr/local/lib/tcc/include
elfinterp:
/lib64/ld-linux-x86-64.so.2
Before this change the output was
# ./x86_64-tcc -vv
tcc version 0.9.26 (x86-64, Linux)
install: /usr/local/lib/tcc
crt:
/usr/lib
libraries:
/usr/lib
/lib
/usr/local/lib
include:
/usr/local/include
/usr/include
/usr/local/lib/tcc/include
elfinterp:
/lib64/ld-linux-x86-64.so.2
This change don't fix a cross compilers
The following check in tccgen.c is removed
if (nocode_wanted)
tcc_error("statement expression in global scope");
This check is introduced in commit 5bcc3eed7b and breaks compilation
of the linux 2.4.26 kernel.
i386-tcc.exe is a compiler for i386 Linux. A HOST_OS variable in Makefile is
introduced and used to select a native compiler (which one to name as tcc.exe)
a test program:
struct {
int a[2], b[2];
} cases[] = {
{ ((int)0), (((int)0)) },
((int)0), (((int)0)) /* error: ',' expected (got ")") */
};
int main() { return 0; }
This commit allow to skip ')' in the decl_initializer() and to see ','
A test program:
/* result of the new version inroduced in 4ad186c5ef: t2a = 44100312 */
#include<stdio.h>
int main() {
int t1 = 176401255;
float f = 0.25f;
int t2a = (int)(t1 * f); // must be 44100313
int t2b = (int)(t1 * (float)0.25f);
printf("t2a=%d t2b=%d \n",t2a,t2b);
return 0;
}
* Don't use /usr/local/lib/tcc/libtcc1.a for i386 and x86_64
A $(tccdir)/i386 directory was used to install a libtcc1.a
but only when cross compiling. And no x86_64 directory.
* Build/install i386-tcc/x86_64-tcc and not a tcc
* Build/install i386-win-tcc/x86_64-win-tcc and not a i386-win-mingw32-tcc/...
* DEFINES = -DTCC_TARGET_I386... also for i386-tcc and i386-win-tcc
* Make a symlink tcc to the i386-tcc/x86_64-tcc for a "make test"
* Build a $(ARCH) directory with a symlink to the libtcc1.a for a "make test"
* Remove a /usr/local/lib/tcc directory on uninstall
* Remove a /usr/local/share/doc/tcc directory on uninstall
* Remove a $(ARCH) directory on "make clean"
* Remove a *-tcc files on "make clean"
produce a
i386-win-mingw32-tcc
i386-win-tcc
x86_64-win-mingw32-tcc
x86_64-win-tcc
arm-win-mingw32ce-tcc
arm-win-tcc
instead of the
i386-w64-mingw32-tcc
i386-win32-tcc
x86_64-w64-mingw32-tcc
x86_64-win32-tcc
arm-wince-mingw32ce-tcc
arm-win32-tcc
Replacing a *-win32 directory names with a *-win names
because this names are based on the names of the tcc
x86_64-win32-tcc, i386-win32-tcc
* x86_64-tcc: use /usr/lib64,.. instead of /usr/lib,..
* don't set tcc_lddir="lib64" if cpu="x86"
* put a definition of the CONFIG_LDDIR into config.h instead
of the config.mak Otherwise a "lib" string may be used by default.
This is a usual case when building a x86_64-tcc (there was
no -DCONFIG_LDDIR building this binary).
* suppress -Wdeprecated-declarations for gcc which complain on malloc hooks
in bcheck.c if glibc is quite new.
Set CONFIG_MULTIARCHDIR for cross compilers.
Chances a cross-compiler will find a working crt*.o
in /usr/lib are more or less 0.
This commit breaks x86 / x86_64 compilres for linux. A solution for the crt*.o
must be discussed.
must be:
# ./x86_64-tcc -vv
tcc version 0.9.26 (x86-64, Linux)
install: /usr/local/lib/tcc
crt:
/usr/lib64
libraries:
/usr/lib64
/lib64
/usr/local/lib64
include:
/usr/local/include
/usr/include
/usr/local/lib/tcc/include
elfinterp:
/lib64/ld-linux-x86-64.so.2
and with MULTIARCH we have:
# ./x86_64-tcc -vv
tcc version 0.9.26 (x86-64 Linux)
install: /usr/local/lib/tcc/
crt:
/usr/lib/x86_64-linux-gnu ???????????????????
libraries:
/usr/lib/x86_64-linux-gnu
/usr/lib ???????????????????
/lib/x86_64-linux-gnu
/lib ???????????????????
/usr/local/lib/x86_64-linux-gnu
/usr/local/lib ???????????????????
include:
/usr/local/include/x86_64-linux-gnu
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
/usr/local/lib/tcc/include
elfinterp:
/lib64/ld-linux-x86-64.so.2
And CONFIG_MULTIARCHDIR don't handle C67.
On Linux x86 we have:
# ./c67-tcc -vv
tcc version 0.9.26 (C67, Linux)
install: /usr/local/lib/tcc
crt:
/usr/lib
libraries:
/usr/lib
/lib
/usr/local/lib
include:
/usr/local/include
/usr/include
/usr/local/lib/tcc/include
elfinterp:
/lib/ld-linux.so.2
* don't setup a cpu before scanning for --cpu=
* --cpu= option sets a 'cpu' variable, not a 'build_cpu', 'build_cpu' was not used anywhere.
* if cpu="" and ARCH != "" then cpu=$ARCH else cpu=`uname -m`
* replace "Build CPU" with "Target CPU" in the output of the configure script.
output this value only when not builing a cross compilers.
* remove a HOST_I386, ... defines from a config.h file.
thise defines are not used anywhere and cpu is now used to define a target cpu
From: Matteo Cypriani <mcy@lm7.fr>
Date: Fri, 5 Sep 2014 23:22:56 -0400
Subject: Disable floating-point test for ARM soft-float
tcc is not yet capable of doing softfloat floating-point operations on
ARM, therefore we disable this test for these platforms. Note that tcc
displays a warning to warn ARM users about this limitation
(debian)
Win32, Win64, WinCE when executing "tcc -v". Example
$ ./i386-win-tcc -v
tcc version 0.9.26 (i386, mingw)
instead of the
tcc version 0.9.26 (i386, Win32)
There is a cpu info already about bits of the excution environment
And display C67 for the TCC_TARGET_C67
Don't use /usr/local/lib/tcc/libtcc1.a for i386 and x86_64
A $(tccdir)/i386 directory was used to install a libtcc1.a
but only when cross compiling. And no x86_64 directory.
And this directory location was unknown inside tccelf.c
From: Matteo Cypriani <mcy@lm7.fr>
Date: Fri, 5 Sep 2014 23:22:56 -0400
Subject: Disable floating-point test for ARM soft-float
tcc is not yet capable of doing softfloat floating-point operations on
ARM, therefore we disable this test for these platforms. Note that tcc
displays a warning to warn ARM users about this limitation
(debian)
arm-gen.c: In function `gfunc_call':
arm-gen.c:1202: warning: unused variable `variadic'
arm-gen.c: In function `gfunc_prolog':
arm-gen.c:1258: warning: unused variable `avregs'
arm-gen.c:1340: warning: label `from_stack' defined but not used
arm-gen.c:222: warning: 'default_elfinterp' defined but not used
A non declared function leads to a seriuos problems. And while
gcc don't turn this warning on lets tcc do it. This warning
can be turned off by -Wno-implicit-function-declaration option.
And autor must explicitly do this if program must be compiled
with this warning off.
seyko