| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
A CString used to be copied into a token string, which is an int array.
On a 64-bit architecture the pointers were misaligned, so ASan gave
lots of warnings. On a 64-bit architecture that required memory
accesses to be correctly aligned it would not work at all.
The CString is now included in CValue instead.
|
| |
|
|
|
|
|
|
|
|
| |
for gas comments lonely on a line such as
# .. more stuff
where tcc would try to parse .. as a preprocessor directive
See also: 0b3612631f49ba0c008635aaa46ecf8be2eefcf7
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
tcc_normalize_inc_dirs: normally no problem to be absolutly
gcc compatible as long as it can be done the tiny way.
This reverts to the state before recent related commits and
reimplements a (small) part of it to fix the reported problem.
Also: Revert "parsing "..." sequence"
c3975cf27c792d493e76a2058a1eaf588324053e
&& p[1] == '.'
is not a reliable way to lookahead
|
| |
|
|
|
|
|
| |
- avoid memory allocation by using its (int) token number
- avoid additional function parameter by using Attribute
Also: fix some strange looking error messages
|
| | |
|
| |
|
|
| |
A case for the absolute path: prevent an error after openening
|
| |
|
|
| |
goto removed
|
| |
|
|
|
|
|
|
|
| |
include dirs are prepared as in gcc
- for each duplicate path keep just the first one
- remove each include_path that exists in sysinclude_paths
include_next streamlined by introducing inc_path_index
in the BufferedFile
|
| |
|
|
|
|
| |
Also, in tok_str_add2, use memcpy instead of the illegal cast.
Unfortunately, I can't see an easy way of fixing the bug.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This version looks rigth. Comparing to the original
algorithm:
1) Loop breaking. We remember a start point after wich
we can try next path. Do not search include stack after
this.
2) But compare next file patch with the start point.
Skip if it the same. Remove "./" before comparing.
PS: a problems with compaling a coreutils-8.24.51-8802e
remain. There are errors messages like:
src/chgrp
src/chown-core.c:42: multiple definition of `make_timespec'
src/chgrp.c:42: first defined here
A problem is in the lib/config.h
#define _GL_INLINE_ extern inline // gcc
#define _GL_INLINE_ inline // tcc
A long description from the lib/config.h
* suppress extern inline with HP-UX cc, as it appears to be broken
* suppress extern inline with Sun C in standards-conformance mode
* suppress extern inline on configurations that mistakenly use
'static inline' to implement functions or macros in standard
C headers like <ctype.h>.
GCC and Clang are excluded from this list. Why not tcc?
|
| |
|
|
|
|
|
|
|
|
| |
don't give an error and simply ingnore directive
if we detect a loop of the #include_next.
With this aproach coreutils-8.24.51-8802e
compiles, but with errors:
lib/libcoreutils.a: error: 'xnmalloc' defined twice
lib/libcoreutils.a: error: 'xnrealloc' defined twice
|
| |
|
|
|
|
|
|
|
| |
A more correct fix. This one don't break old logic.
But if include file is not found, we try to search
again with the new compare rule.
A description of the problem:
http://permalink.gmane.org/gmane.comp.compilers.tinycc.devel/2769
|
| |
|
|
| |
a next version of the patch will follow
|
| |
|
|
| |
skip include file only if include_file_name=current_file_name
|
| |
|
|
|
|
|
|
|
| |
don't panic with
error: '.' expected
if there is only two '.' chars. Return tok='.' in such case.
An asm code to test:
jz do_move0 # .. then we have a normal low
# .. or else we have a high
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
* Documentation is now in "docs".
* Source code is now in "src".
* Misc. fixes here and there so that everything still works.
I think I got everything in this commit, but I only tested this
on Linux (Make) and Windows (CMake), so I might've messed
something up on other platforms...
|
| |
|
|
|
|
| |
Still some more tabs to be taken care of. arm-gen.c and tcccoff.c
have so many style issues that I'm just going to throw clang-format
at them.
|
| | |
|
| |
|
|
|
|
|
|
| |
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"
|
| |
|
|
|
|
| |
* remove free_defines() from tcc_preprocess()
all cleanup will be done in tcc_delete
* move a preprocessor file closing to tcc_delete too
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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)
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
* 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.
|
| |
|
|
|
|
|
| |
* disable a -fdollar-in-identifiers option in assembler files
* a test is added
This is a patch addon from Daniel Holden.
|
| |
|
|
|
| |
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
|