aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* tcc_add_dll is not used if TCC_TARGET_PEseyko2015-05-102-0/+6
| | | | after "tccpp: fix issues, add tests"
* define __OPTIMIZE__ if -ON (N != 0)seyko2015-05-101-0/+9
| | | | this is gcc behaviour
* warn if multile -o option is givenseyko2015-05-101-0/+4
|
* restore "./configure --enable-tcc32-mingw" on linuxseyko2015-05-101-0/+6
| | | | | | commit "tccpp: fix issues, add tests" also include - configure/Makefile : build on windows (MSYS) was broken which breaks a cross compilation on linux
* tccpp: fix issues, add testsgrischka2015-05-0949-985/+1057
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * fix some macro expansion issues * add some pp tests in tests/pp * improved tcc -E output for better diff'ability * remove -dD feature (quirky code, exotic feature, didn't work well) Based partially on ideas / researches from PipCet Some issues remain with VA_ARGS macros (if used in a rather tricky way). Also, to keep it simple, the pp doesn't automtically add any extra spaces to separate tokens which otherwise would form wrong tokens if re-read from tcc -E output (such as '+' '=') GCC does that, other compilers don't. * cleanups - #line 01 "file" / # 01 "file" processing - #pragma comment(lib,"foo") - tcc -E: forward some pragmas to output (pack, comment(lib)) - fix macro parameter list parsing mess from a3fc54345949535524d01319e1ca6378b7c2c201 a715d7143d9d17da17e67fec6af1c01409a71a31 (some coffee might help, next time ;) - introduce TOK_PPSTR - to have character constants as written in the file (similar to TOK_PPNUM) - allow '\' appear in macros - new functions begin/end_macro to: - fix switching macro levels during expansion - allow unget_tok to unget more than one tok - slight speedup by using bitflags in isidnum_table Also: - x86_64.c : fix decl after statements - i386-gen,c : fix a vstack leak with VLA on windows - configure/Makefile : build on windows (MSYS) was broken - tcc_warning: fflush stderr to keep output order (win32)
* VLA code: minor fixPhilip2015-05-041-1/+0
| | | | Don't try to call get_flags() on the mob branch, where it's not defined.
* VLA code minor fixseyko2015-05-041-1/+2
|
* a lot simpler VLA codeseyko2015-05-044-94/+33
| | | | | | | | 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
* -traditional and -iwithprefix optionsseyko2015-05-031-0/+27
|
* fix "tcc test.c -Wl,,--oformat,binary"seyko2015-05-032-4/+5
| | | | | set linker options only when "s->output_type == TCC_OUTPUT_EXE" otherwise tcc will produce a wrong object file
* fix "tcc test.c -UAAA -UBBB"seyko2015-05-031-1/+0
| | | | | no need to call tcc_free() inside tcc_undefine_symbol() Otherwise we get segmentation fault inside tcc_delete()
* Mostly revert "tccpp.c: minor fix I'd accidentally not committed"Philip2015-05-021-40/+17
| | | | | | | This reverts commit 27ec4f67a33a354c8f377dd4a5b42491c2b43beb. Sorry about that, I included changes which are still being tested, by accident.
* tccpp.c: minor fix I'd accidentally not committedPhilip2015-05-021-19/+43
| | | | Sorry about that. This should definitely fix Sergey's issue.
* minor fixPhilip2015-05-021-1/+2
| | | | | | | Fixes the issue reported by Sergey at http://lists.nongnu.org/archive/html/tinycc-devel/2015-05/msg00007.html I hope.
* tccpp.c: unterminated macro argument error messagePhilip2015-05-021-0/+2
| | | | | | | | #define a(x) x a(( would produce "error: , expected" when what's actually expected is a ')'.
* tccpp.c: fix GNU comma handlingPhilip2015-05-022-19/+35
| | | | | | | | | This requires moving TOK_PLCHLDR handling, but the new logic should make things easier even if (when?) GNU comma handling is removed. (Somewhat confusingly, GCC no longer supports GNU commas. See http://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html for a description of past and current GCC behaviour.)
* tccpp.c: restore whitespace after failed macroPhilip2015-05-021-12/+35
| | | | | | | | | This fixes test7 described in: http://lists.nongnu.org/archive/html/tinycc-devel/2015-05/msg00002.html Note that the current code still adds excessive forced blank characters to its output, so this patch might not change visible behaviour.
* tccpp.c: correct # stringificationPhilip2015-05-021-4/+23
| | | | | | | | | | | | | | | | | | Fix handling of escape characters, spaces, and line feeds in macros or macro arguments that might yet be subject to # stringification. Should this be an -f option? I think memory usage increases only very slightly (in particular, while line feeds, stray \s, and spaces are preserved, comments are not), so it's probably not worth it to make it one. Note that macro_subst now checks for stray \s which are still left in the input stream after macro substitution, if desired. This patch depends on the previous patch, so if you revert that, please revert this patch, too. See http://lists.nongnu.org/archive/html/tinycc-devel/2015-05/msg00002.html
* tccpp.c: parse flag to accept stray \Philip2015-05-022-2/+9
| | | | | | | | | | | | | | | | | | | This adds a PARSE_FLAG_ACCEPT_STRAYS parse flag to accept stray backslashes in the source code, and uses it for pure preprocessing. For absolutely correct behaviour of # stringification, we need to use this flag when parsing macro definitions and in macro arguments, as well; this patch does not yet do so. The test case for that is something like #define STRINGIFY2(x) #x #define STRINGIFY(x) STRINGIFY2(x) STRINGIFY(\n) which should produce "\n", not a parse error or "\\n". See http://lists.nongnu.org/archive/html/tinycc-devel/2015-05/msg00002.html
* tccpp.c: fix endless loopPhilip2015-05-021-2/+3
| | | | | | | | | | Perhaps a better fix would be to ensure tok is set to TOK_EOF rather than 0 at the end of a macro stream. This partially fixes test2 of the examples given in: http://lists.nongnu.org/archive/html/tinycc-devel/2015-05/msg00002.html It's still failing, but at least it's not running out of memory now.
* tccpp.c: reset spc after macro_subst_tok()Philip2015-05-021-0/+1
| | | | | | | This bug doesn't seem to affect anything currently, but does interfere with miscellaneous tccpp.c fixes for the test cases described here: http://lists.nongnu.org/archive/html/tinycc-devel/2015-05/msg00002.html
* tccpp.c: fix ##-in-macros logicPhilip2015-05-021-2/+2
| | | | | | | | | | | | | The old code had an inverted condition, so #define a(b)## b would be accepted while #define a(b,c) b ## ## c would be rejected with the confusing error message "'##' invalid at start of macro".
* tccpp.c: fix empty stringifyPhilip2015-05-011-1/+1
| | | | | | | | #define STRINGIFY2(x) #x #define STRINGIFY(x) STRINGIFY2(x) STRINGIFY() should produce "", not "\301".
* fix a potential end-of-buffer issue in tccelf.cPhilip2015-04-302-3/+6
| | | | | also read characters one at a time when PARSE_DEBUG is set; after this patch, things seem to work with that.
* fix end-of-buffer error in tccpp.cPhilip2015-04-301-1/+1
| | | | | | | | | | | | Quick fix for http://lists.nongnu.org/archive/html/tinycc-devel/2015-04/msg00160.html. I don't fully understand the intended semantics of when file->buf_ptr[0] is valid, but the rest of the code doesn't have any obvious spots with the same bug. Feel free to revert this if I'm mistaken or we need to discuss this change further.
* fix vstack leakPhilip2015-04-291-1/+2
| | | | | | | | I think this code only affects the ARM EABI target, and only when returning small structures that might be unaligned. However, it was both leaking vstack entries and failing to achieve what I think is its purpose, to ensure the sret argument would be aligned properly. Both issues fixed.
* VLA fix: save stack pointer right after modificationPhilip2015-04-284-9/+37
| | | | | | | | | | | | | | | | This patch disables the optimization of saving stack pointers lazily, which didn't fully take into account that control flow might not reach the stack-saving instructions. I've decided to leave in the extra calls to vla_sp_save() in case anyone wants to restore this optimization. Tests added and enabled. There are two remaining bugs: VLA variables can be modified, and jumping into the scope of a declared VLA will cause a segfault rather than a compiler error. Both of these do not affect correct C code, but should be fixed at some point. Once VLA variables have been made properly immutable, we can share them with the saved stack pointer and save stack and instructions.
* fix VLA/continue issuePhilip2015-04-274-2/+122
| | | | | | | | | | | | | | | | | | as reported in http://lists.nongnu.org/archive/html/tinycc-devel/2015-04/msg00131.html. Note that this is one of two separate VLA bugs: A. labels aren't reached by program execution, so the stack pointer is never saved B. continue doesn't restore the stack pointer as goto does This fixes only B. I'm not sure whether the same issue applies to break as well as continue. Add a test case, but disable tests #78 and #79 for now as they're not fully fixed until the issue described in http://lists.nongnu.org/archive/html/tinycc-devel/2015-04/msg00110.html is resolved.
* add test case for VLA segfaultsPhilip2015-04-273-1/+25
| | | | | | | | | This test obviously shouldn't segfault, but currently does so. The problem is in the VLA code, which fails to save the stack pointer before taking a conditional branch in some cases. See this thread: http://lists.nongnu.org/archive/html/tinycc-devel/2015-04/msg00130.html
* replace PARSE_FLAG_ASM_COMMENTS with PARSE_FLAG_ASM_FILEseyko2015-04-274-11/+10
| | | | | after "assign PARSE_FLAG_ASM_COMMENTS only for asm files" functions of this flags are identical
* warn about declarations after statements when compiling with gcc.Philip2015-04-271-0/+5
|
* fixes for "tcc -E -dD"seyko2015-04-271-2/+16
| | | | | | * print "// #pragma push_macro(XXX)" * keep output line numbers in sync with source (don't output \n in printf)
* preprocess: "assign PARSE_FLAG_ASM_COMMENTS only for asm files"seyko2015-04-272-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | resolve a problem with the following test.c program, tcc -E test.c #ifdef _XOPEN_SOURCE # define __USE_XOPEN 1 # if (_XOPEN_SOURCE - 0) >= 500 # define __USE_XOPEN_EXTENDED 1 # define __USE_UNIX98 1 # undef _LARGEFILE_SOURCE # define _LARGEFILE_SOURCE 1 # if (_XOPEN_SOURCE - 0) >= 600 # define __USE_XOPEN2K 1 # undef __USE_ISOC99 # define __USE_ISOC99 1 # endif # else # ifdef _XOPEN_SOURCE_EXTENDED # define __USE_XOPEN_EXTENDED 1 # endif # endif #endif int main() {} // # 17 "aaa.c" // aaa.c:17: error: #endif without matching #if
* fix another x86_64 ABI bugPhilip2015-04-262-2/+68
| | | | | | | | | | | The old code assumed that if an argument doesn't fit into the available registers, none of the subsequent arguments do, either. But that's wrong: passing 7 doubles, then a two-double struct, then another double should generate code that passes the 9th argument in the 8th register and the two-double struct on the stack. We now do so. However, this patch does not yet fix the function calling code to do the right thing in the same case.
* Fix zero-length struct/union test. Remove nonsensical test.Philip2015-04-251-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The comment suggests this was meant to detect unions, but in fact it compared f->c, the union/struct size, against f->next->c, the first element's offset. This affected only zero-length structs/unions with a first (zero-length) element, as in this code: struct u2 { }; struct u { struct u2 u2; } u; struct u f(struct u x) { return x; } However, such structures turned out to be broken anyway, as code like this was generated for the above f: 0000000000000000 <f>: 0: 55 push %rbp 1: 48 89 e5 mov %rsp,%rbp 4: 48 81 ec 10 00 00 00 sub $0x10,%rsp b: 66 0f d6 45 f8 movq %xmm0,-0x8(%rbp) 10: 66 0f 6e 45 f8 movd -0x8(%rbp),%xmm0 15: e9 00 00 00 00 jmpq 1a <f+0x1a> 1a: c9 leaveq 1b: c3 retq
* x86_64 ABI tests, which currently cause failuresPhilip2015-04-251-0/+86
| | | | | | | | | | | | | | With the x86_64 Linux ELF ABI, we're currently failing two of these three tests, which have been disabled for now. The problem is mixed structures such as struct { double x; char c; }, which the x86_64 ABI specifies are to be passed/returned in one integer register and one SSE register; our current approach, marking the structure as VT_QLONG or VT_QFLOAT, fails in this case. (It's possible to fix this by getting rid of VT_QLONG and VT_QFLOAT entirely as at https://github.com/pipcet/tinycc, but the changes aren't properly isolated at present. Anyway, there might be a less disruptive fix.)
* a test for the #pragma push/pop_macroseyko2015-04-253-1/+37
|
* tccpp: alternative #pragma push/pop_macrogrischka2015-04-232-11/+38
| | | | | | | using next_nomacro() so that for example #define push_macro foobar does not affect how the pragma works (same behavior as gcc, albeit not MS's cl).
* Revert "* and #pragma pop_macro("macro_name")"grischka2015-04-238-68/+2
| | | | | | | | | | | | - pop_macro incorrect with initially undefined macro - horrible implementation (tcc_open_bf) - crashes eventually (abuse of Sym->prev_tok) - the (unrelated) asm_label part is the opposite of a fix (Despite of its name this variable has nothing to do with the built-in assembler) This reverts commit 0c8447db7970813292a8be74ee50e49091be5d15.
* fix a subtle x86-64 calling bugPhilip2015-04-232-1/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I ran into an issue playing with tinycc, and tracked it down to a rather weird assumption in the function calling code. This breaks only when varargs and float/double arguments are combined, I think, and only when calling GCC-generated (or non-TinyCC, at least) code. The problem is we sometimes generate code like this: 804a468: 4c 89 d9 mov %r11,%rcx 804a46b: b8 01 00 00 00 mov $0x1,%eax 804a470: 48 8b 45 c0 mov -0x40(%rbp),%rax 804a474: 4c 8b 18 mov (%rax),%r11 804a477: 41 ff d3 callq *%r11 for a function call. Note how $eax is first set to the correct value, then clobbered when we try to load the function pointer into R11. With the patch, the code generated is: 804a468: 4c 89 d9 mov %r11,%rcx 804a46b: b8 01 00 00 00 mov $0x1,%eax 804a470: 4c 8b 5d c0 mov -0x40(%rbp),%r11 804a474: 4d 8b 1b mov (%r11),%r11 804a477: 41 ff d3 callq *%r11 which is correct. This becomes an issue when get_reg(RC_INT) is modified not always to return %rax after a save_regs(0), because then another register (%ecx, say) is clobbered, and the function passed an invalid argument. A rather convoluted test case that generates the above code is included. Please note that the test will not cause a failure because TinyCC code ignores the %rax argument, but it will cause incorrect behavior when combined with GCC code, which might wrongly fail to save XMM registers and cause data corruption.
* Bugfix: 32-bit vs 64-bit bug in x86_64-gen.c:gcall_or_jmpPhilip2015-04-231-1/+2
| | | | | | | | | | | | | Verify an immediate value fits into 32 bits before jumping to it/calling it with a 32-bit immediate operand. Without this fix, code along the lines of ((int (*)(const char *, ...))140244834372944LL)("hi\n"); will fail mysteriously, even if that decimal constant is the correct address for printf. See https://github.com/pipcet/tinycc/tree/bugfix-1
* "#pragma once" implementationseyko2015-04-212-1/+4
|
* * and #pragma pop_macro("macro_name")seyko2015-04-218-3/+71
| | | | | | | | | | * 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.
* add missing test from -fdollar-in-identifiers commitRamsay Jones2015-04-202-0/+55
| | | | | | | Commit 5ce2154c ("-fdollar-in-identifiers addon", 20-04-2015) forgot to include the test files from Daniel's patch. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
* -fdollar-in-identifiers addonseyko2015-04-204-13/+21
| | | | | | | * disable a -fdollar-in-identifiers option in assembler files * a test is added This is a patch addon from Daniel Holden.
* Fix program symbols exported in dynsym sectionThomas Preud'homme2015-04-181-12/+11
| | | | | | | | | | Prior to this commit TinyCC was exporting symbols defined in programs only when they resolve an undefined symbol of a library. However, the expected behavior (see --export-dynamic in GNU ld manpage) is that all symbols used by libraries and defined by a program should be exported in dynsym section. This is because symbol resolution search first in program and then in libraries, thus allowing program symbol to interpose symbol defined in a library.
* clarify error message when library not foundseyko2015-04-163-4/+3
| | | | | a prior error message: cannot find 'program_resolve_lib' after a patch: cannot find library 'libprogram_resolve_lib'
* implement #pragma comment(lib,...)Steven G. Messervey2015-04-154-1/+48
|
* Revert "implement #pragma comment(lib,...)"Steven G. Messervey2015-04-154-74/+15
| | | | | | This reverts commit 8615bb40fb39bf7435462ca54cbbc24aaecae502. Reverting as it breaks on MinGW targets
* implement #pragma comment(lib,...)Steven G. Messervey2015-04-154-15/+74
|