| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
| |
set linker options only when "s->output_type == TCC_OUTPUT_EXE"
otherwise tcc will produce a wrong object file
|
| |
|
|
|
| |
no need to call tcc_free() inside tcc_undefine_symbol()
Otherwise we get segmentation fault inside tcc_delete()
|
| |
|
|
|
|
|
| |
This reverts commit 27ec4f67a33a354c8f377dd4a5b42491c2b43beb.
Sorry about that, I included changes which are still being tested, by
accident.
|
| |
|
|
| |
Sorry about that. This should definitely fix Sergey's issue.
|
| |
|
|
|
|
|
| |
Fixes the issue reported by Sergey at
http://lists.nongnu.org/archive/html/tinycc-devel/2015-05/msg00007.html
I hope.
|
| |
|
|
|
|
|
|
| |
#define a(x) x
a((
would produce "error: , expected" when what's actually expected is a
')'.
|
| |
|
|
|
|
|
|
|
| |
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.)
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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".
|
| |
|
|
|
|
|
|
| |
#define STRINGIFY2(x) #x
#define STRINGIFY(x) STRINGIFY2(x)
STRINGIFY()
should produce "", not "\301".
|
| |
|
|
|
| |
also read characters one at a time when PARSE_DEBUG is set; after this
patch, things seem to work with that.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
after "assign PARSE_FLAG_ASM_COMMENTS only for asm files"
functions of this flags are identical
|
| | |
|
| |
|
|
|
|
| |
* print "// #pragma push_macro(XXX)"
* keep output line numbers in sync with source
(don't output \n in printf)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
| | |
|
| |
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
* 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.
|
| |
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
| |
* disable a -fdollar-in-identifiers option in assembler files
* a test is added
This is a patch addon from Daniel Holden.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
a prior error message: cannot find 'program_resolve_lib'
after a patch: cannot find library 'libprogram_resolve_lib'
|
| | |
|
| |
|
|
|
|
| |
This reverts commit 8615bb40fb39bf7435462ca54cbbc24aaecae502.
Reverting as it breaks on MinGW targets
|
| | |
|
| |
|
|
| |
Usage example: tcc -c -xc ex5.cgi -xn ex2.c ex7.c ex6.cgi
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
Correction for the commit db08122d31a681e593c6679140d2df0cc63c8784
As pointed Thomas Preud'homme buf[] may be used outside of the block
whit code:
name = block;
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
for targets which don't support variable length arrays.
|
| |
|
|
|
|
| |
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.
|