Re: [Tinycc-devel] recover commits on mob
On 05/01/2021 18:48, Herman ten Brugge wrote: > I reapplied the last 2 patches again. Oops, sorry did I mess-up? (I had the repo.or.cz website open and, just before pushing, checked that no new commits had come in - I also git a 'git fetch origin' just seconds before the push!). Sorry for the inconvenience! ATB, Ramsay Jones ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] recover commits on mob
Hi Herman, Danny, I just pushed a fix-up to the 'mob' branch to recover three commits which had been 'overwritten' somehow. (Danny, did you not see an error message when you tried to push?). ATB, Ramsay Jones ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tinycc test failure on 32-bit Linux
On 10/04/2019 23:39, Michael Matz wrote: > Hi, > > On Tue, 9 Apr 2019, Ramsay Jones wrote: > >> Test: 102_alignas... >> --- 102_alignas.expect 2019-04-09 16:15:35.069831581 +0100 >> +++ 102_alignas.output 2019-04-09 16:16:23.922614694 +0100 >> @@ -1 +1 @@ >> -16 8 4 16 >> +16 4 4 16 >> Makefile:69: recipe for target '102_alignas.test' failed >> >> I didn't look, but I am guessing that the 'expect' file has >> set expectations for a 64-bit platform. ;-) > > Um, ahem... right you are, that was careless. Fixed in mob. Thanks! I confirmed the fix last night. (No new failures! ;-) ). ATB, Ramsay Jones ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tinycc test failure on 32-bit Linux
On 07/04/2019 03:15, Michael Matz wrote: > Hello Ramsay, > > On Fri, 29 Mar 2019, Ramsay Jones wrote: > >> +98_al_ax_extend.c:20: error: conflicting types for '_us' >> >> The 98_al_ax_extend test does not run on x86_64. > > Which is also why I didn't notice the breakage, thanks for the report, fixed > in mob. Thanks! I confirmed the fix tonight on my 32-bit Linux platform. However, this showed a new test error ... Test: 102_alignas... --- 102_alignas.expect2019-04-09 16:15:35.069831581 +0100 +++ 102_alignas.output2019-04-09 16:16:23.922614694 +0100 @@ -1 +1 @@ -16 8 4 16 +16 4 4 16 Makefile:69: recipe for target '102_alignas.test' failed I didn't look, but I am guessing that the 'expect' file has set expectations for a 64-bit platform. ;-) ATB, Ramsay Jones ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] tinycc test failure on 32-bit Linux
Hi Michael,
I occasionally build/test tcc on 32-bit Linux. Recently, a test failed
which bisected to commit 1fd3709379 ("Fix local extern vardecl",
2019-03-18). Viz:
$ uname -a
Linux satellite-18-32bit 4.10.0-38-generic #42~16.04.1-Ubuntu SMP Tue Oct 10
16:30:51 UTC 2017 i686 i686 i686 GNU/Linux
$
$ git branch -v
master d348a9a final update for 0.9.27
* mob 1fd3709 Fix local extern vardecl
mob-fix 3e775ad tccgen.c: fix an [-Wstrict-prototypes] warning
$
$ make clean >/dev/null 2>&1
$ make >/dev/null 2>&1
$ ./tcc -v
tcc version 0.9.27 (i386 Linux)
$
$ make test
...
Test: 97_utf8_string_literal...
Test: 98_al_ax_extend...
--- 98_al_ax_extend.expect2017-09-13 02:09:57.497542999 +0100
+++ 98_al_ax_extend.output2019-03-28 16:34:54.211738554 +
@@ -1,9 +1 @@
-ABCE ABCE
-ABCE ABCE
-00CE 00CE
-FFCE FFCE
-
-ABCE ABCE
-ABCE ABCE
-00CE 00CE
-FFCE FFCE
+98_al_ax_extend.c:20: error: conflicting types for '_us'
Makefile:69: recipe for target '98_al_ax_extend.test' failed
make[3]: *** [98_al_ax_extend.test] Error 1
Test: 99_fastcall...
...
Makefile:353: recipe for target 'test' failed
make: *** [test] Error 2
$
The 98_al_ax_extend test does not run on x86_64.
Just an FYI. Thanks!
ATB,
Ramsay Jones
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] bug: #if-block bodies, when expanded as macro arguments, incorrect if #if argument has a macro in it
On 23/05/18 12:34, Petr Skočík wrote: > I don't know if the page is still relevant to this project but > I've posted a simpler and hopefully clearer report on this > bug at: https://savannah.nongnu.org/bugs/?group=tinycc > > I'm reposting here: > > #if-block bodies, when expanded as macro arguments, incorrect if #if argument > has a macro in it > > Example: > > #define PASTE_X(X) X > > PASTE_X( > BEFORE: > #if HAS_X //same for e.g.: 1*HAS_X+0+2 > int x; //this gets replaced by the value of HAS_X > #endif > AFTER: > ) > > (Compile with e.g., tcc -DHAS_X=42 c.c. The output is then `42` instead of > `BEFORE: int x; AFTER:` ) > > This bug only affects expanded #if-blocks -- if the block isn't passed to a > macro (variadic or not) > it expands OK. Hmm, I don't think this is a bug - its simply undefined behaviour. From the C99 standard, 6.10.3 Macro replacement, sub-paragraph 11: "The sequence of preprocessing tokens bounded by the outside-most matching parentheses forms the list of arguments for the function-like macro. The individual arguments within the list are separated by comma preprocessing tokens, but comma preprocessing tokens between matching inner parentheses do not separate arguments. If there are sequences of preprocessing tokens within the list of arguments that would otherwise act as preprocessing directives, the behavior is undefined." > If the macro inside the argument to the #if is preceeded by `defined` or > enclosed in `defined()`, > the expansion works OK again. Hmm, that may be a little odd, but is an allowed implementation. ATB, Ramsay Jones ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] _Generic or __builtin_choose_expr
On 08/07/17 05:39, Christian Jullien wrote: > Mattias, > The issue is that the 94_generic.c test expected results are machine > dependent. This modified version below is more neutral and works on RPI. > However it tests fewer cases. This also fails on 32-bit Linux: $ uname -a Linux satellite-18-32bit 4.4.0-53-generic #74-Ubuntu SMP Fri Dec 2 15:58:04 UTC 2016 i686 i686 i686 GNU/Linux $ $ make test ... Test: 94_generic... --- ../../tests/tests2/94_generic.expect 2017-07-08 12:36:44.056422769 +0100 +++ 94_generic.output 2017-07-08 12:37:28.921214574 +0100 @@ -1,9 +1 @@ -20 -20 -123 -2 -5 -1 -2 -3 -1 +94_generic.c:44: error: type march twice Makefile:47: recipe for target '94_generic.test' failed make[2]: *** [94_generic.test] Error 1 make[2]: Target 'all' not remade because of errors. make[2]: Leaving directory '/home/ramsay/tinycc/tests/tests2' Makefile:80: recipe for target 'tests2-dir' failed make[1]: *** [tests2-dir] Error 2 make[1]: Leaving directory '/home/ramsay/tinycc/tests' Makefile:350: recipe for target 'test' failed make: *** [test] Error 2 $ Also, note the typo in the error message 'type _march_ twice', rather than 'type match twice'. > You should think of a better tests that deals in a portable way with > const/non-const, signed/unsigned and different integer sizes you can meet on > different architectures. > That may be true, but I think tcc is also at fault. BTW, gcc does not have a problem with this test: $ gcc -o gcc-generic tests/tests2/94_generic.c $ ./gcc-generic >gcc-actual $ diff -u tests/tests2/94_generic.expect gcc-actual $ However, looking in the debugger, it seems that tcc can't tell that the constant '17L' has the 'long' type - it seems to think that it is an 'int'. Indeed, if you look at the end of parse_btype(), we find: /* long is never used as type */ if ((t & VT_BTYPE) == VT_LONG) #if PTR_SIZE == 8 && !defined TCC_TARGET_PE t = (t & ~VT_BTYPE) | VT_LLONG; #else t = (t & ~VT_BTYPE) | VT_INT; #endif ATB, Ramsay Jones ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Very sorry - newbie questions
On 12/03/17 18:35, Tony Robinson wrote: > Hello, > > Very sorry for newbie questions but I'm looking for C compiler for a > processor that I've been very slowly building as a hobby. The instruction > set is super simple (Rz = Rx op Ry for op in ADD, SUB, AND, OR, XOR, ASR plus > basic LOAD/STORE/PUSH/POP instructions) and as the clock rate is only about > 50kHz I'm not too worried about optimization. Portability is key - I will > port FORTH but would love C. > > But all that is background, I'm wondering if; > > a) tcc is the simplest C compiler for me to retarget and > b) assuming that it is, I did the standard: > > $ tar xvf tcc-0.9.26.tar.bz2 The 0.9.26 release was in Feb 2013 and a lot has changed since then (I can't recall if x86-64 and/or multilib systems were supported properly then). You may have better luck using the mob branch from the git repo directly (the 0.9.27 release _may_ happen soon-ish): $ git clone git://repo.or.cz/tinycc.git $ cd tinycc $ ./configure $ make $ make test HTH ATB, Ramsay Jones ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Linux port is broken with multi-arch
On 27/11/16 15:55, Christian Jullien wrote: > Hi, > > > > I just installed Linux Fedora 25 on x86_64 adding i386 support because I > maintain software mostly written in assembler and bound to i386 architecture. > > > > Trying to compile tcc from mob gives me a lot of errors probably related to > wrong path to gcc lib. > > > > Cloning into 'tinycc'... > > Binary directory /usr/local/bin > > TinyCC directory/usr/local/lib/tcc > > Library directory /usr/local/lib > > Include directory /usr/local/include > > Manual directory/usr/local/share/man > > Info directory /usr/local/share/info > > Doc directory /usr/local/share/doc > > Target root prefix - > > Source path /home/jullien/tinycc > > C compiler gcc > > Target OS Linux > > CPU x86-64 > > Big Endian no > > Profiling no > > Cross compilers no > > Use libgcc no > > Triplet - This looks odd. Did you run ./configure? You also don't appear to have CONFIG_TRIPLET set in your config.mak file. [I would expect Triplet to be reported as 'x86_64-linux-gnu' and your config.mak file to have a line similar to: NATIVE_DEFINES+=-DCONFIG_TRIPLET="\"x86_64-linux-gnu\"" somewhere.] ATB, Ramsay Jones ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Missing test for -fdollar-in-identifiers commit
Hi Sergey, Daniel, I just pushed a quick fix for the missing test files to the mob branch. Also, I noticed a slight difference between Daniel's patch and commit 5ce2154, which amounts to: diff --git a/tccasm.c b/tccasm.c index 3fa6f07..8f71846 100644 --- a/tccasm.c +++ b/tccasm.c @@ -853,6 +853,7 @@ static void tcc_assemble_inline(TCCState *s1, char *str, int len) memcpy(file-buffer, str, len); macro_ptr = NULL; +parse_flags |= PARSE_FLAG_ASM_FILE; tcc_assemble_internal(s1, 0); tcc_close(); $ I don't have time to investigate further, so I will leave the issue of the above difference for you to investigate. Thanks! ATB, Ramsay Jones ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Dollar Sign in Identifiers Extension
On 14/04/15 04:47, Sergey Korshunoff wrote: Hi! 2015-04-13 15:01 GMT, Daniel Holden s0822...@staffmail.ed.ac.uk: I've attached a new patch which tests for dollars in identifiers in C. I've added a new parsing flag `PARSE_FLAG_ASM` to block the use of dollar identifiers when parsing asm. This could probably be combined with the `PARSE_FLAG_ASM_COMMENTS` flag. In the mob branch there is a flag PARSE_FLAG_ASM_FILE (in tcc_add_file_internal) turned on before calling tcc_assmble. What is needed in tcc_assemble is to keep it when changing parse_flags. Then your patch must check PARSE_FLAG_ASM_FILE and not a PARSE_FLAG_ASM. PARSE_FLAG_ASM_FILE is introduced to solve problems of the preprocessor (different rules of the # parsing) First version of the your patch is pushed to mob by me (with you as the autor of the patch in comments). Only addons of the new patch must be pushed to the mob. Your patch contain a \r chars. Is this chars are removed by git? Ah, sorry Sergey, I hadn't noticed that you had already included an earlier version of the patch. [Daniel, look on the mob branch for commit dcb36587 (-fdollar-in-identifiers switch which enables '$' in identifiers, 12-04-2015)] I notice that the mob branch does not contain Daniel's test '56_dollars.c'. Since I had it laying around, I decided to hack the Makefile: $ git diff diff --git a/tests/tests2/Makefile b/tests/tests2/Makefile index 35ab3c1..4334e75 100644 --- a/tests/tests2/Makefile +++ b/tests/tests2/Makefile @@ -76,6 +76,7 @@ TESTS = \ 54_goto.test \ 55_lshift_type.test \ 56_btype_excess-1.test \ + 56_dollars.test \ 57_btype_excess-2.test \ 58_function_redefinition.test \ 59_function_array.test \ $ It should probably be called '76_dollars.c' by now! Now test: $ make test ... Test: 56_btype_excess-1... Test: 56_dollars... --- 56_dollars.expect 2015-04-13 17:39:08.787672483 +0100 +++ 56_dollars.output 2015-04-14 10:52:04.232805798 +0100 @@ -1,14 +1 @@ -fred=10 -joe=20 -henry=30 -fred2=10 -joe2=20 -henry2=30 -fred10=100 -joe_10=2 -local=10 -a100$=100 -a$$=1000 -a$c$b=2121 -$100=1 -$$$=money +56_dollars.c:3: error: invalid macro name '$' make[2]: *** [56_dollars.test] Error 1 make[2]: Leaving directory `/home/ramsay/tinycc/tests/tests2' make[1]: *** [moretests] Error 2 make[1]: Leaving directory `/home/ramsay/tinycc/tests' make: *** [test] Error 2 $ HTH ATB, Ramsay Jones ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Dollar Sign in Identifiers Extension
On 14/04/15 14:49, Daniel Holden wrote: Hi, Thanks Ramsay and Sergey, sorry for misunderstanding about the mob branch! Working with git makes everything a lot easier - I was building the patch by hand. I've attached a new patch for the mob branch which should work. The format of the attachment is not suitable for application by 'git am' (or 'git apply' for that matter), without some manual massaging of the file. However, I managed to whip it into enough shape to apply and test. You still have whitespace errors: $ git show --check commit c6a83478766fcde878219c2587978100c43b2a05 Author: Daniel Holden cont...@theorangeduck.com Date: Tue Apr 14 18:21:33 2015 +0100 Fixed Dollars in Identifiers Patch Added tests for dollars in identifiers flag and also fixed issue with compile flags not being ready at the time of preprocessor construction. Added fix for syntax conflict with asm where identifier with $ as first character has different meaning. tests/tests2/76_dollars_in_identifiers.c:20: trailing whitespace. + tests/tests2/76_dollars_in_identifiers.c:23: trailing whitespace. + tests/tests2/76_dollars_in_identifiers.c:24: trailing whitespace. + int $ = 10; tests/tests2/76_dollars_in_identifiers.c:30: trailing whitespace. + tests/tests2/76_dollars_in_identifiers.c:42: new blank line at EOF. $ (Note that I didn't manage to keep your commit date!) However, the patch builds and passes all tests. After the following: $ vim tests/tests2/76_dollars_in_identifiers.c # fixup whitespace $ git diff diff --git a/tests/tests2/76_dollars_in_identifiers.c b/tests/tests2/76_dollars_in_identifiers.c index 48c48fd..c5fcf99 100644 --- a/tests/tests2/76_dollars_in_identifiers.c +++ b/tests/tests2/76_dollars_in_identifiers.c @@ -17,17 +17,17 @@ int main() printf(fred2=%d\n, $($fred)); printf(joe2=%d\n, $(joe$)); printf(henry2=%d\n, $(hen$y)); - + printf(fred10=%d\n, $10($fred)); printf(joe_10=%d\n, _$10(joe$)); - - int $ = 10; + + int $ = 10; int a100$ = 100; int a$$ = 1000; int a$c$b = 2121; int $100 = 1; const char *$$$ = money; - + printf(local=%d\n, $); printf(a100$=%d\n, a100$); printf(a$$=%d\n, a$$); @@ -39,4 +39,3 @@ int main() } /* vim: set expandtab ts=4 sw=3 sts=3 tw=80 :*/ - $ git diff --check $ $ git add tests/tests2/76_dollars_in_identifiers.c $ git commit --amend [daniel e3f4b4e] Fixed Dollars in Identifiers Patch Author: Daniel Holden cont...@theorangeduck.com Date: Tue Apr 14 18:21:33 2015 +0100 6 files changed, 77 insertions(+), 13 deletions(-) create mode 100644 tests/tests2/76_dollars_in_identifiers.c create mode 100644 tests/tests2/76_dollars_in_identifiers.expect $ git show --check commit e3f4b4e3c115274b61efafa6bab7171c7d504352 Author: Daniel Holden cont...@theorangeduck.com Date: Tue Apr 14 18:21:33 2015 +0100 Fixed Dollars in Identifiers Patch Added tests for dollars in identifiers flag and also fixed issue with compile flags not being ready at the time of preprocessor construction. Added fix for syntax conflict with asm where identifier with $ as first character has different meaning. $ $ git format-patch -1 0001-Fixed-Dollars-in-Identifiers-Patch.patch $ The resulting patch file should (which I've attached) _should_ apply to the current mob branch (@ commit a13f183), thus: $ git checkout -b daniel mob Switched to a new branch 'daniel' $ git am 0001-Fixed-Dollars-in-Identifiers-Patch.patch Applying: Fixed Dollars in Identifiers Patch $ HTH ATB, Ramsay Jones From e3f4b4e3c115274b61efafa6bab7171c7d504352 Mon Sep 17 00:00:00 2001 From: Daniel Holden cont...@theorangeduck.com Date: Tue, 14 Apr 2015 18:21:33 +0100 Subject: [PATCH] Fixed Dollars in Identifiers Patch Added tests for dollars in identifiers flag and also fixed issue with compile flags not being ready at the time of preprocessor construction. Added fix for syntax conflict with asm where identifier with $ as first character has different meaning. --- tccasm.c | 3 +- tccpp.c | 18 +++- tests/Makefile| 2 +- tests/tests2/76_dollars_in_identifiers.c | 41 +++ tests/tests2/76_dollars_in_identifiers.expect | 14 + tests/tests2/Makefile | 12 +--- 6 files changed, 77 insertions(+), 13 deletions(-) create mode 100644 tests/tests2/76_dollars_in_identifiers.c create mode 100644 tests/tests2/76_dollars_in_identifiers.expect diff --git a/tccasm.c b/tccasm.c index d9c929c..25277fe 100644 --- a/tccasm.c +++ b/tccasm.c @@ -747,7 +747,7 @@ static int tcc_assemble_internal(TCCState *s1, int do_preprocess) ch = file-buf_ptr[0]; tok_flags
Re: [Tinycc-devel] Dollar Sign in Identifiers Extension
On 13/04/15 17:51, Daniel Holden wrote: Hi Ramsey, Thanks for trying it. The patch I made is from stable download here http://bellard.org/tcc/ Sorry if that is wrong. Where can I get the mob branch? Ah, OK. The current master branch is tagged as 'release_0_9_26'. The git repository for tinycc can be obtained from repo.or.zc: $ git clone git://repo.or.cz/tinycc.git Cloning into 'tinycc'... remote: Counting objects: 7112, done. remote: Compressing objects: 100% (2158/2158), done. Receiving objects: 100% (7112/7112), 3.00 MiB | 964.00 KiB/s, done. remote: Total 7112 (delta 4962), reused 7002 (delta 4890) Resolving deltas: 100% (4962/4962), done. Checking connectivity... done. $ cd tinycc $ git branch -v * mob a13f183 ability to compile multiple *.c files with -c switch $ git branch -rv origin/HEAD - origin/mob origin/masterd5e2210 Release TinyCC 0.9.26 origin/mob a13f183 ability to compile multiple *.c files with -c switch origin/mob-stuff bfa394d Move bounds-checking code to a bcheck.a origin/tcc-xref ab24b28 tcc xref experiment $ git branch master origin/master Branch master set up to track remote branch master from origin. $ git branch -v master d5e2210 Release TinyCC 0.9.26 * moba13f183 ability to compile multiple *.c files with -c switch $ BTW, I get identical results on a 32-bit system. Also, the asmtest looks like this: $ make -C tests asmtest ... asmtest ../tcc -B.. -c asmtest.S objdump -D asmtest.o asmtest.out --- asmtest.ref 2015-04-13 20:11:34.856115487 +0100 +++ asmtest.out 2015-04-13 20:26:28.668071775 +0100 @@ -57,7 +57,7 @@ 5d:90 nop 5e:90 nop 5f:90 nop - 60:a1 5c 00 00 00 mov0x5c,%eax + 60:a1 00 00 00 00 mov0x0,%eax 65:89 c3 mov%eax,%ebx 67:a1 00 00 01 00 mov0x1,%eax 6c:66 a1 00 00 01 00 mov0x1,%ax @@ -167,7 +167,7 @@ 1fe:f6 05 00 10 00 00 01testb $0x1,0x1000 205:66 f7 05 00 10 00 00testw $0x1,0x1000 20c:01 00 - 20e:85 c3 test %eax,%ebx + 20e:85 d8 test %ebx,%eax 210:85 05 00 10 00 00 test %eax,0x1000 216:85 15 00 10 00 00 test %edx,0x1000 21c:f7 d2 not%edx make: Leaving directory `/home/ramsay/tinycc/tests' $ HTH ATB, Ramsay Jones ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Dollar Sign in Identifiers Extension
On 13/04/15 16:01, Daniel Holden wrote:
Hi,
I've attached a new patch which tests for dollars in identifiers in C.
I've added a new parsing flag `PARSE_FLAG_ASM` to block the use of dollar
identifiers when parsing asm. This could probably be combined with the
`PARSE_FLAG_ASM_COMMENTS` flag.
Currently the flag only blocks identifiers in asm _starting_ with a dollar. I
think this is the only syntactically valid place in which dollars occurring
could conflict with gas asm, but they might appear inside identifiers if the
programmer is either referencing a symbol with a dollar in _or_ if they've
made a syntax error. I'll look into it more and do some more testing.
I'm on 64 bit and I have to hack the makefiles to run the assembly tests
because they are written in 32-bit x86. Does anyone have a 32-bit machine
they are testing tcc on?
Your patch does not apply to the mob branch:
$ git apply ../dollars-in-identifiers.patch
../dollars-in-identifiers.patch:36: trailing whitespace.
../dollars-in-identifiers.patch:40: trailing whitespace.
|| (parse_flags PARSE_FLAG_ASM)) goto parse_simple;
../dollars-in-identifiers.patch:41: trailing whitespace.
../dollars-in-identifiers.patch:135: trailing whitespace.
../dollars-in-identifiers.patch:138: trailing whitespace.
error: patch failed: tcc.h:528
error: tcc.h: patch does not apply
error: patch failed: libtcc.c:1423
error: libtcc.c: patch does not apply
error: patch failed: tccpp.c:2178
error: tccpp.c: patch does not apply
error: patch failed: ./tests/tests2/Makefile:67
error: ./tests/tests2/Makefile: patch does not apply
$
... but I'm guessing you already know that!
Applying your patch instead to the master branch:
$ git apply ../dollars-in-identifiers.patch
../dollars-in-identifiers.patch:36: trailing whitespace.
../dollars-in-identifiers.patch:40: trailing whitespace.
|| (parse_flags PARSE_FLAG_ASM)) goto parse_simple;
../dollars-in-identifiers.patch:41: trailing whitespace.
../dollars-in-identifiers.patch:135: trailing whitespace.
../dollars-in-identifiers.patch:138: trailing whitespace.
warning: squelched 3 whitespace errors
warning: 8 lines add whitespace errors.
$
... shows that you are introducing some whitespace errors
(although the number of lines doesn't seem to tally!).
After 'git apply'-ing your patch and staging ('git add'-ing)
your changes (including the new files), then:
$ git diff --cached --check
tccpp.c:2181: trailing whitespace.
+
tccpp.c:2185: trailing whitespace.
+|| (parse_flags PARSE_FLAG_ASM)) goto parse_simple;
tccpp.c:2186: trailing whitespace.
+
tests/tests2/56_dollars.c:20: trailing whitespace.
+
tests/tests2/56_dollars.c:23: trailing whitespace.
+
tests/tests2/56_dollars.c:24: trailing whitespace.
+ int $ = 10;
tests/tests2/56_dollars.c:30: trailing whitespace.
+
tests/tests2/56_dollars.c:42: new blank line at EOF.
$
(you can't see the red highlight on the trailing whitespace in
an email, of course! ;)
Note: so far this is on an 64-bit system, I was going to try on
a 32-bit system later.
After running:
$ make clean
...
$ ./configure
...
$ make
...
$ make test
...
Test: 56_dollars...
56_dollars.c:14: error: '$' undeclared
make[2]: *** [56_dollars.test] Error 1
make[2]: Leaving directory `/home/ramsay/tinycc/tests/tests2'
make[1]: *** [moretests] Error 2
make[1]: Leaving directory `/home/ramsay/tinycc/tests'
make: *** [test] Error 2
$
So, I'm obviously doing something wrong, sorry! :(
I suspect it's not worth trying on 32-bit, if I can't get it
to work on a 64-bit system.
ATB,
Ramsay Jones
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Dollar Sign in Identifiers Extension
On 13/04/15 18:16, Ramsay Jones wrote:
On 13/04/15 16:01, Daniel Holden wrote:
Hi,
I've attached a new patch which tests for dollars in identifiers in C.
I've added a new parsing flag `PARSE_FLAG_ASM` to block the use of dollar
identifiers when parsing asm. This could probably be combined with the
`PARSE_FLAG_ASM_COMMENTS` flag.
Currently the flag only blocks identifiers in asm _starting_ with a dollar.
I think this is the only syntactically valid place in which dollars
occurring could conflict with gas asm, but they might appear inside
identifiers if the programmer is either referencing a symbol with a dollar
in _or_ if they've made a syntax error. I'll look into it more and do some
more testing.
I'm on 64 bit and I have to hack the makefiles to run the assembly tests
because they are written in 32-bit x86. Does anyone have a 32-bit machine
they are testing tcc on?
Your patch does not apply to the mob branch:
$ git apply ../dollars-in-identifiers.patch
../dollars-in-identifiers.patch:36: trailing whitespace.
../dollars-in-identifiers.patch:40: trailing whitespace.
|| (parse_flags PARSE_FLAG_ASM)) goto parse_simple;
../dollars-in-identifiers.patch:41: trailing whitespace.
../dollars-in-identifiers.patch:135: trailing whitespace.
../dollars-in-identifiers.patch:138: trailing whitespace.
error: patch failed: tcc.h:528
error: tcc.h: patch does not apply
error: patch failed: libtcc.c:1423
error: libtcc.c: patch does not apply
error: patch failed: tccpp.c:2178
error: tccpp.c: patch does not apply
error: patch failed: ./tests/tests2/Makefile:67
error: ./tests/tests2/Makefile: patch does not apply
$
... but I'm guessing you already know that!
Applying your patch instead to the master branch:
$ git apply ../dollars-in-identifiers.patch
../dollars-in-identifiers.patch:36: trailing whitespace.
../dollars-in-identifiers.patch:40: trailing whitespace.
|| (parse_flags PARSE_FLAG_ASM)) goto parse_simple;
../dollars-in-identifiers.patch:41: trailing whitespace.
../dollars-in-identifiers.patch:135: trailing whitespace.
../dollars-in-identifiers.patch:138: trailing whitespace.
warning: squelched 3 whitespace errors
warning: 8 lines add whitespace errors.
$
... shows that you are introducing some whitespace errors
(although the number of lines doesn't seem to tally!).
After 'git apply'-ing your patch and staging ('git add'-ing)
your changes (including the new files), then:
$ git diff --cached --check
tccpp.c:2181: trailing whitespace.
+
tccpp.c:2185: trailing whitespace.
+|| (parse_flags PARSE_FLAG_ASM)) goto parse_simple;
tccpp.c:2186: trailing whitespace.
+
tests/tests2/56_dollars.c:20: trailing whitespace.
+
tests/tests2/56_dollars.c:23: trailing whitespace.
+
tests/tests2/56_dollars.c:24: trailing whitespace.
+ int $ = 10;
tests/tests2/56_dollars.c:30: trailing whitespace.
+
tests/tests2/56_dollars.c:42: new blank line at EOF.
$
(you can't see the red highlight on the trailing whitespace in
an email, of course! ;)
Note: so far this is on an 64-bit system, I was going to try on
a 32-bit system later.
Of course, I forgot that you said you had to hack the Makefile before
you could test on 64-bit systems ... sorry about that! :(
I will try it on a 32-bit system later ...
ATB,
Ramsay Jones
After running:
$ make clean
...
$ ./configure
...
$ make
...
$ make test
...
Test: 56_dollars...
56_dollars.c:14: error: '$' undeclared
make[2]: *** [56_dollars.test] Error 1
make[2]: Leaving directory `/home/ramsay/tinycc/tests/tests2'
make[1]: *** [moretests] Error 2
make[1]: Leaving directory `/home/ramsay/tinycc/tests'
make: *** [test] Error 2
$
So, I'm obviously doing something wrong, sorry! :(
I suspect it's not worth trying on 32-bit, if I can't get it
to work on a 64-bit system.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Predefined macro identifying TinyC?
On 16/03/15 14:07, Ben Bacarisse wrote: Martin Guy martinw...@gmail.com writes: snip The reason is to work round what looks like a bug in the 64-bit pointer handling, which is fairly easy to workaround: /* 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 */ #define NARGS 2 int ARG[NARGS]; int *ARGSPACE = ARG; int *ARGP = ARG - 1; As it happens, this is undefined behaviour by the C language standard -- you can't even construct (let alone use) a pointer that points before the start of an array. I don't know whether TinyC is using the permission this gives the implementation, but it is technically free to do whatever it likes in this situation. Yep, I was about to say exactly the same[1], and suggest the following: #define NARGS 2 int ARGV[NARGS+1]; int *ARG = ARGV + 1; int *ARGSPACE = ARG; int *ARGP = ARG - 1; ... or something like that. (warning: just typing into email client.) ATB, Ramsay Jones [1] In a draft of the C11 standard I have, this is discussed in '6.5.6 Additive Operators'. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] How to optimize compiling sizeof const?
On 31/07/14 07:51, Jared Maddox wrote:
Date: Tue, 29 Jul 2014 19:11:24 +0800
From: YX Hao lifenjoi...@163.com
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] How to optimize compiling sizeof const?
Message-ID: 1BB4CCF1522243D28E17C6C418FDB416@HYXPC
Content-Type: text/plain; charset=utf-8
Hi there,
We know that tcc generates bigger binary file than gcc for non-small
projects. But I'm not meaning the optimization options.
Here I find the titled issue when I compile an html5 library (Google's
gumbo). In the compiled object file and linked binary file, that of tcc
you can find the string to be calculated size of is stored, and you will see
it will not be used with a debugger, while gcc generates clean file with
smaller size. The attached file is a piece of code for testing.
Just to be certain that I'm understanding correctly, you're talking
about something like this:
size_t size_size()
{
return( sizeof( sizeof ) );
}
void arg_size( void (*func)( const char* ) )
{
if( func )
{
( *func )( sizeof );
}
}
And the behavior in question is that TWO copies of sizeof are
included in the resulting object file, correct? This is specifically a
I thought the OP was complaining that the expression:
sizeof(a string literal)
was causing an _unused_ copy of the string literal to be stored in
the data section. This expression is a compile-time constant and,
once it has been evaluated, the string literal is no longer required
(even at compile time).
However, I may have misunderstood. :-D
ATB,
Ramsay Jones
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] enum tccpp phase error
On 14/06/14 21:06, lifenjoi...@163.com wrote:
/* enum_err.c file */
#include stdio.h
enum hmode {
HTML_4_01 = 1, /* HTML-4.01 strict */
XHTML_1_0 = 2 /* XHTML-1.0 strict */
};
int main (int argc; char *argv[])
^
{
return 0;
}
/* enum_err.c end */
==
tcc version 0.9.26 (i386 Win32)
...
.../enum_err.c:8: error: ',' expected (got ;)
==
Found in source code:
tccpp.c:92:tcc_error('%c' expected (got \%s\), c,
get_tok_str(tok, tokc));
=== ST_FUNC void skip(int c)
==
When I put the enum definition into tcc's tests file, it was complied without
error!?
Is this a bug?
No, it's a syntax error. :P
ATB,
Ramsay Jones
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] mob broken; how to develop with mob and community
On 03/05/14 19:44, Michael Matz wrote: Hello, okay, are the last commits to mob from jiang meant as joke or vandalism? I would like to think it wasn't meant as vandalism, but it certainly looks like vandalism to me (at least to the i386 build, which currently doesn't even compile!). :( * 32bit code generation is hosed already in the testsuite, * gawk doesn't work anymore even for x86_64, * arm codegen is broken already in the testsuite (adding an internal compiler error) * they contain ugly white-space changes making review exceedingly hard * despite the unnecessarily hard review I think there are numerous problems in the actual implementation: + the new parse_number uses inexact floating point directly (e.g. 1.0L/b when b==10 isn't exactly representable, cumulating errors while parsing) + There's a new subtype VT_VLS meaning VLA plus STRUCT, which makes no sense at all (VLA is VL _array_) + TREG_MEM (also new) doesn't follow convention for type flags, and seems like a layering violation + It reverts a cleanup by Thomas (eda2c756edc4dca004ba217) without discussion + It renames libtcc1.a to libcrt.a, thereby trading a sensibly tcc-specific name for something tcc-specific with something generic (what if gcc had libcrt as well?) + It increases VT_STRUCT_SHIFT to 20, breaking bitfields larger than 31 bits (we needs 12 bits to encode bitfield position and size, so the maximum bit shift can be 19 + It changes gv2() so that VT_CMP/VT_JMP results aren't special-cased anymore, without obvious compensation in all its users to avoid the errors that the comment specifically mentioned + It implements some strange non-standard preprocessor extension push_macro/pop_macro (as pragmas) without discussion; it enlargens some heavily used internal data structures for this. + It adds some fix x86-64 vla commit, without testcase showing what's actually broken, and for that shuffles the internal code generations in large and unobvious ways (and removes the correct calls to alloca() on x86-64 PE) And that's just what I saw on a cursory read of the commits. Due to the white-space changes the more intricate parts are terrible to review and I've skipped them. When I wrote above without discussion, then this was just for the most controversial parts. It's true for all the patches. I've seen no messages at all from jiang to this mailing list. No discussion about implementation approaches, no discussions about bugs, no nothing. The commit messages are mostly non-informative as well. All in all I think this approach is pretty unacceptable, but others here might differ. If the patch series were a smaller then the problems in it could reasonably be fixed after the fact by others. But as it stands we now have something in which every single one of the 22 topmost patches (ignoring the white-space fixup patch from grischka) has issues. If it were just my project I'd be tempted to revert the whole mob state to be before your (jiangs) patches, and expect you to work with the community to fix what you actually wanted to fix or improve. (From the patch series I gather that one thing you wanted to fix was parameter passing on stack when memcpy is needed). It the very minimum you have to subscribe to this mailing list (that's even listed in the mob rules), and of course also take part in discussions. You also have to _review_ your patches before commiting (you would have seen the useless white-space changes) and write meaningful commit messages. Any opinions from others? If it were my project, I would have reverted all of those commits some time ago! (NOTE: I haven't made significant contributions to this project, so I don't get a vote on this). ATB, Ramsay Jones ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] mob broken; how to develop with mob and community
On 04/05/14 10:30, Ramsay Jones wrote: On 03/05/14 19:44, Michael Matz wrote: Hello, okay, are the last commits to mob from jiang meant as joke or vandalism? I would like to think it wasn't meant as vandalism, but it certainly looks like vandalism to me (at least to the i386 build, which currently doesn't even compile!). :( Of course, I wrote that just before fetching from git ... :-P The i386 build compiles again. Thanks! ATB, Ramsay Jones ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tcc i386 test failures after commit ea2805f
On 04/04/14 16:59, Michael Matz wrote: Hello Ramsay, On Thu, 3 Apr 2014, Ramsay Jones wrote: After commit ea2805f (shared libs: Build libtcc1.a with -fPIC, 02-04-2014), this now fails like so: Fixed with 2024c445. Indeed PIC input wasn't handled correctly in connection with -run (emitting a real ELF executable worked). So the testsuite is now back to the state before ea2805f, that is known VLA 5 fail in test1b and known bad pointer in strlen() in test3b. Yep, I can confirm that it now fails in the old familiar way! :-P Thanks! (that was a fast response!). ATB, Ramsay Jones ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] tcc i386 test failures after commit ea2805f
Hi Michael, tcc on i386 has been failing a couple of tests for a while. For example, commit 3e56584 (Allow local redefinition of enumerator, 31-03-2014), fails like so: $ make test ... test1b ../tcc -B.. -I.. -I.. -I../include -b -run tcctest.c test.out1 --- test.ref 2014-04-03 20:09:19.207429405 +0100 +++ test.out1 2014-04-03 20:09:19.879432730 +0100 @@ -538,7 +538,7 @@ Test C99 VLA 2 (ptrs substract): PASSED Test C99 VLA 3 (ptr add): PASSED Test C99 VLA 4 (ptr access): PASSED -Test C99 VLA 5 (bounds checking (might be disabled)): PASSED PASSED PASSED PASSED PASSED PASSED PASSED PASSED +Test C99 VLA 5 (bounds checking (might be disabled)): FAILED PASSED FAILED PASSED FAILED PASSED FAILED PASSED sizeof(int) = 4 sizeof(unsigned int) = 4 sizeof(long) = 4 make[1]: *** [test1b] Error 1 make[1]: Leaving directory `/home/ramsay/tinycc/tests' make: *** [test] Error 2 $ After commit ea2805f (shared libs: Build libtcc1.a with -fPIC, 02-04-2014), this now fails like so: $ make test ... test1b ../tcc -B.. -I.. -I.. -I../include -b -run tcctest.c test.out1 Runtime error: dereferencing invalid pointer at 0x9a6dc23 __bound_init() Segmentation fault make[1]: *** [test1b] Error 139 make[1]: Leaving directory `/home/ramsay/tinycc/tests' make: *** [test] Error 2 $ Also, running 'make -k test', show other (bounds) tests failing in a similar fashion (test3b and btest). I don't have time to investigate this myself (sorry!). HTH ATB, Ramsay Jones ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] [PATCH] tccelf.c: Fix the Linux-i386 build
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
---
Hi Thomas,
tcc currently fails to compile on Linux-i386; this patch fixes it
up for me. Unfortunately, the tests are also failing, but I don't
have time to look into fixing them. The failure looks like so:
test3
../tcc -B.. -I.. -I.. -I../include -DCONFIG_LDDIR=\lib\
-DCONFIG_MULTIARCHDIR=\i386-linux-gnu\ -DTCC_TARGET_I386 -DONE_SOURCE -run
../tcc.c -B.. -I.. -I.. -I../include -DCONFIG_LDDIR=\lib\
-DCONFIG_MULTIARCHDIR=\i386-linux-gnu\ -DTCC_TARGET_I386 -DONE_SOURCE -run
../tcc.c -B.. -I.. -I.. -I../include -DCONFIG_LDDIR=\lib\
-DCONFIG_MULTIARCHDIR=\i386-linux-gnu\ -DTCC_TARGET_I386 -DONE_SOURCE -run
../tcc.c -B.. -I.. -I.. -I../include -run tcctest.c test.out3
--- test.ref 2014-02-02 11:17:41.049081012 +
+++ test.out3 2014-02-02 11:17:41.601083749 +
@@ -346,7 +346,7 @@
itof: -1234.00
lltof: -2334.00
utof: 2166572288.00
-ulltof: 18446744073709551616.00
+ulltof: 2334.00
float: 42.12346
double: 42.123455
long double: 42.123455
@@ -385,7 +385,7 @@
itof: -1234.00
lltof: -2334.00
utof: 2166572288.00
-ulltof: 18446744073709549568.00
+ulltof: 2334.00
float: 42.12346
double: 42.123457
long double: 42.123457
@@ -424,7 +424,7 @@
itof: -1234.00
lltof: -2334.00
utof: 2166572288.00
-ulltof: 18446744073709549282.00
+ulltof: 2334.00
float: 42.12346
double: 42.123457
long double: 42.123457
make[1]: *** [test3] Error 1
make[1]: Leaving directory `/home/ramsay/tinycc/tests'
make: *** [test] Error 2
$
HTH
ATB,
Ramsay Jones
tccelf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tccelf.c b/tccelf.c
index e5fcfb0..9890829 100644
--- a/tccelf.c
+++ b/tccelf.c
@@ -511,7 +511,7 @@ static addr_t add_jmp_table(TCCState *s1, int val)
ST_FUNC void relocate_section(TCCState *s1, Section *s)
{
Section *sr;
-ElfW_Rel *rel;
+ElfW_Rel *rel, *qrel;
ElfW(Sym) *sym;
int type, sym_index;
unsigned char *ptr;
@@ -521,6 +521,7 @@ ST_FUNC void relocate_section(TCCState *s1, Section *s)
#endif
sr = s-reloc;
+qrel = (ElfW_Rel *)sr-data;
for_each_elem(sr, 0, rel, ElfW_Rel) {
ptr = s-data + rel-r_offset;
--
1.8.5
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] tcc.h: Fix CONFIG_TCC_SYSINCLUDEPATHS
On 02/10/13 20:44, Thomas Preud'homme wrote:
Le mercredi 2 octobre 2013 20:17:38 Ramsay Jones a écrit :
Commit 9382d6f1 (Fix lib, include, crt and libgcc search paths,
07-09-2013) inadvertently included an initial empty entry to the
CONFIG_TCC_SYSINCLUDEPATHS variable (for non win32 targets). In
addition to an empty line in the 'tcc -vv' display, this leads
to the preprocessor attempting to read an include file from the
root of the filesystem (i.e. '/header.h').
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
---
tcc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tcc.h b/tcc.h
index 5ed3e21..60f5f8c 100644
--- a/tcc.h
+++ b/tcc.h
@@ -185,7 +185,7 @@
# define CONFIG_TCC_SYSINCLUDEPATHS {B}/include;{B}/include/winapi
# else
# define CONFIG_TCC_SYSINCLUDEPATHS \
-: CONFIG_SYSROOT /usr/local/include/ CONFIG_MULTIARCHDIR \
+CONFIG_SYSROOT /usr/local/include/ CONFIG_MULTIARCHDIR \
: CONFIG_SYSROOT /usr/local/include \
: CONFIG_SYSROOT /usr/include/ CONFIG_MULTIARCHDIR \
: CONFIG_SYSROOT /usr/include \
Oh my. Please accept my apologies for having been absent minded.
No need, I've been plenty absent minded over the years. :-D
Should I push this to the mob branch?
ATB,
Ramsay Jones
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] i386 build of gawk with tcc now broken
On 09/09/13 22:59, Thomas Preud'homme wrote:
Le dimanche 8 septembre 2013 17:13:51 Ramsay Jones a écrit :
On 08/09/13 08:00, arn...@skeeve.com wrote:
[snip]
--- 8 ---
From: Ramsay Jones ram...@ramsay1.demon.co.uk
Date: Sat, 7 Sep 2013 22:48:02 +0100
Subject: [PATCH] libtcc1.c: Fix __asm__() in __tcc_fpinit and __tcc_cvt_ftol
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
---
lib/libtcc1.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/libtcc1.c b/lib/libtcc1.c
index a94a82d..a717701 100644
--- a/lib/libtcc1.c
+++ b/lib/libtcc1.c
@@ -482,7 +482,7 @@ long long __ashldi3(long long a, int b)
void __tcc_fpinit(void)
{
unsigned c = 0x137F;
-__asm__ __volatile__ (fldcw %0 : =m (c));
+__asm__ __volatile__ (fldcw %0 : : m (c));
}
#endif
long long __tcc_cvt_ftol(long double x)
@@ -491,9 +491,9 @@ long long __tcc_cvt_ftol(long double x)
long long ret;
__asm__ __volatile__ (fnstcw %0 : =m (c0));
c1 = c0 | 0x0C00;
-__asm__ __volatile__ (fldcw %0 : =m (c1));
+__asm__ __volatile__ (fldcw %0 : : m (c1));
__asm__ __volatile__ (fistpll %0 : =m (ret));
-__asm__ __volatile__ (fldcw %0 : =m (c0));
+__asm__ __volatile__ (fldcw %0 : : m (c0));
return ret;
}
#endif /* !__x86_64__ */
The patch looks sound. the memory location operand is indeed an input since
the output is in a x87 FPU control word. I thus applied the patch.
Thanks Ramsay.
Best regards,
Thomas
Heh, I just sent an improved patch to the mailing-list about
ten minutes ago. :-D (Well an improved commit message anyway.)
Luckily, I didn't attempt to push to the mob branch, since I
wanted to make sure there were no objections!
ATB,
Ramsay Jones
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] libtcc1.c: Fix 'Floating point exception' test failures
On 10/09/13 00:03, Thomas Preud'homme wrote: Le lundi 9 septembre 2013 23:49:16 Ramsay Jones a écrit : Since commit 73faaea2 (i386-gen: preserve fp control word in gen_cvt_ftoi, 28-08-2013) the tests have failed, like so: ramsay@ramsay-laptop $ make test I think this commit message is very well explained but too detailed. Something along the line correct operand constraint in __tcc_fpinit and __tcc_cvt_ftol would be better I think. It's obvious from the fact that the constraints are wrong that gcc is doing wrong optimization. Or maybe I'm wrong but anyway, I already applied your commit so it's too late to change it now, sorry. I agree I didn't pay enough attention to the commit message. Yeah, how much detail to put into the commit message can vary greatly from one project to the next ... However, the original patch I sent to Arnold didn't have a commit message. It was a WIP patch that I wanted him to try out, before I sent a real patch ... :-D Thanks a lot anyway. Happy to help, when I can. ATB, Ramsay Jones ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] i386 build of gawk with tcc now broken
On 08/09/13 08:00, arn...@skeeve.com wrote:
After pulling the latest on the mob branch, builds of gawk master using
tcc generate lots of test failures.
On an i386 linux system:
git clone git://git.savannah.gnu.org/gawk.git
cd gawk
./bootstrap.sh configure CC=tcc make
make check # watch lots of things go kablooey
This does not occur on x86-64.
Does this also happen with tcc 0.9.26 and tcc 0.9.25 or just with the mob
branch?
I'm pretty sure just the mob branch. I can double check tomorrow
when I'm at the machine. Almost all the errors are related to floating
point exceptions; I strongly suspect it has to do with the most recent
changes.
The recipe above will let you reproduce it a lot quicker than waiting
for me...
0.9.25 won't be worth checking as it's tool old, FWIW.
I have a patch to fix the tests, which fail for me with a Floating
point exception:
ramsay@ramsay-laptop $ make test
:
[snip]
:
test3
../tcc -B.. -I.. -I.. -I../include -DCONFIG_LDDIR=\lib/i386-linux-gnu\
-DCONFIG_MULTIARCHDIR=\i386-linux-gnu\ -DTCC_TARGET_I386 -DONE_SOURCE
-run
../tcc.c -B.. -I.. -I.. -I../include -DCONFIG_LDDIR=\lib/i386-linux-gnu\
-DCONFIG_MULTIARCHDIR=\i386-linux-gnu\ -DTCC_TARGET_I386 -DONE_SOURCE
-run
../tcc.c -B.. -I.. -I.. -I../include -DCONFIG_LDDIR=\lib/i386-linux-gnu\
-DCONFIG_MULTIARCHDIR=\i386-linux-gnu\ -DTCC_TARGET_I386 -DONE_SOURCE
-run
../tcc.c -B.. -I.. -I.. -I../include -run ../tests/tcctest.c test.out3
Floating point exception
make[1]: *** [test3] Error 136
make[1]: Leaving directory `/home/ramsay/tinycc/tests'
make: *** [test] Error 2
ramsay@ramsay-laptop $
If you run 'git bisect' you will find the culprit is commit 73faaea2
(i386-gen: preserve fp control word in gen_cvt_ftoi, 28-08-2013).
Try the following patch and let me know if it fixes it up for you.
ATB,
Ramsay Jones
--- 8 ---
From: Ramsay Jones ram...@ramsay1.demon.co.uk
Date: Sat, 7 Sep 2013 22:48:02 +0100
Subject: [PATCH] libtcc1.c: Fix __asm__() in __tcc_fpinit and __tcc_cvt_ftol
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
---
lib/libtcc1.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/libtcc1.c b/lib/libtcc1.c
index a94a82d..a717701 100644
--- a/lib/libtcc1.c
+++ b/lib/libtcc1.c
@@ -482,7 +482,7 @@ long long __ashldi3(long long a, int b)
void __tcc_fpinit(void)
{
unsigned c = 0x137F;
-__asm__ __volatile__ (fldcw %0 : =m (c));
+__asm__ __volatile__ (fldcw %0 : : m (c));
}
#endif
long long __tcc_cvt_ftol(long double x)
@@ -491,9 +491,9 @@ long long __tcc_cvt_ftol(long double x)
long long ret;
__asm__ __volatile__ (fnstcw %0 : =m (c0));
c1 = c0 | 0x0C00;
-__asm__ __volatile__ (fldcw %0 : =m (c1));
+__asm__ __volatile__ (fldcw %0 : : m (c1));
__asm__ __volatile__ (fistpll %0 : =m (ret));
-__asm__ __volatile__ (fldcw %0 : =m (c0));
+__asm__ __volatile__ (fldcw %0 : : m (c0));
return ret;
}
#endif /* !__x86_64__ */
--
1.8.4
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [+Last+] Call for testing
Thomas Preud'homme wrote: Greetings everybody, Hopefully I pushed the last change to support multiarch setup. Please check that tcc still builds correctly and that the resulting binary can create working programs. I already prepared locally the push for tagging 0.9.26 and changing the version. Since so far you've been great fast tester, I'll push tomorrow if nobody complains until tomorrow. I fetched commit b9f089fc (Don't search libgcc_s.so.1 on /lib64, 14-02-2013) this evening in order to test it. Everything works beautifully! ;-) [I also tested installation, compiled a medium sized project and ran it's testsuite - all without problem.] Thanks! ATB, Ramsay Jones ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] test failure on Linux
Ramsay Jones wrote: Thomas Preud'homme wrote: Le mercredi 13 février 2013 19:08:37, Thomas Preud'homme a écrit : Le mercredi 13 février 2013 17:16:28, Thomas Preud'homme a écrit : On Wed, 13 Feb 2013 08:30:14 -0700, arn...@skeeve.com wrote: Thomas Preud'homme robo...@celest.fr wrote: Why not but strike multiarch from that as I don't see how we could detect it by compiling a C program. Use the output of ldd to tell you where the C library is. Yep true, I thought about it last night and forgot about it in the morning. However I just pushed a commit using checking where is crti.o before reading your mail. It's a one line test so I think the solution is not too bad but you can prove me wrong of course. Thanks a lot for the suggestion. Thinking about it a bit I managed to come up with a much better patch. It's not totally done though but I have to leave. I'll push it tonight. Stay tuned. Pushed. And the diffstat from the original situation (before my 2 commits to reorganize) is also better. See for yourself: OK, despite what I said, I fetched commit e298f608 (Create config-print program to test $cc, 13-02-2013) last night in order to test it. [Sorry for not reporting the results last night, but I desperately needed to get some sleep!] Unfortunately, the news is not good! :( Using ldd has broken the build again and my x86 is apparently a bigendian machine! :-P So, having tested commit b9f089fc (Don't search libgcc_s.so.1 on /lib64, 14-02-2013), this is all fixed now. Thanks! ATB, Ramsay Jones ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] test failure on Linux
Thomas Preud'homme wrote: I'm working on a patch. Once finished, I'll ask for testing and then we'll release. Here is a first version of the patch. Granted, detecting multiarch at configure time and specifying the triplet in tcc.h is better but the result is quite ugly for now. The diffstat is as follows: Makefile | 10 +- configure | 12 tcc.h | 28 3 files changed, 41 insertions(+), 9 deletions(-) I tested commit af4b27f0 (Fix previous commit, 13-02-2013), which I believe is this patch plus one fixup. This fixes the regression for me (see display below). Thank you for your quick work on this. To be honest I'm tempted to delay the patch after the release since it's possible for you to just set crtprefix at configure time and everything should work. Thus still tempted. I tried to use ./configure --crtprefix=/usr/lib, but it didn't work. (I think I would have to specify the location of the libraries and includes as well ... but didn't try it; do you want me to try?) It would be a shame to release an new version of tcc (first in three years) without this fixed, but I know where you are coming from! ;-P Thanks! ATB, Ramsay Jones $ git log -1 commit af4b27f0fd7d1ee247bbd1a330dfbff9ed16bcae Author: Thomas Preud'homme robo...@celest.fr Date: Wed Feb 13 17:58:14 2013 +0100 Fix previous commit Fix commit f6cfaa6d2591b8931f8fde9aebf7822202b78810 $ make distclean /dev/null $ ./configure Binary directory /usr/local/bin TinyCC directory/usr/local/lib/tcc Library directory /usr/local/lib Include directory /usr/local/include Manual directory/usr/local/share/man Info directory /usr/local/share/info Doc directory /usr/local/share/doc/tcc Target root prefix Source path /home/ramsay/tinycc C compiler gcc Target OSLinux CPU x86 Big Endian no gprof enabledno cross compilers no use libgcc no Creating config.mak and config.h $ make out 21 $ make test make -C tests test make[1]: Entering directory `/home/ramsay/tinycc/tests' hello-exe ../tcc -B.. ../examples/ex1.c -o hello || (../tcc -vv; exit 1) ./hello Hello World hello-run ../tcc -B.. -run ../examples/ex1.c Hello World gcc -o libtcc_test libtcc_test.c ../libtcc.a -I.. -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -DTCC_TARGET_I386 -lm -ldl libtest ./libtcc_test lib_path=.. Hello World! fib(32) = 2178309 add(32, 64) = 96 cp ../include/tcclib.h . gcc -o tcctest.gcc tcctest.c -I. -I.. -w -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -DTCC_TARGET_I386 -std=gnu99 -O0 -fno-omit-frame-pointer ./tcctest.gcc test.ref test3 ../tcc -B.. -DTCC_TARGET_I386 -DONE_SOURCE -run ../tcc.c -B.. -DTCC_TARGET_I386 -DONE_SOURCE -run ../tcc.c -B.. -DTCC_TARGET_I386 -DONE_SOURCE -run ../tcc.c -B.. -run tcctest.c test.out3 Auto Test3 OK moretests make -C tests2 make[2]: Entering directory `/home/ramsay/tinycc/tests/tests2' Test: 00_assignment... Test: 01_comment... Test: 02_printf... Test: 03_struct... Test: 04_for... Test: 05_array... Test: 06_case... Test: 07_function... Test: 08_while... Test: 09_do_while... Test: 10_pointer... Test: 11_precedence... Test: 12_hashdefine... Test: 13_integer_literals... Test: 14_if... Test: 15_recursion... Test: 16_nesting... Test: 17_enum... Test: 18_include... Test: 19_pointer_arithmetic... Test: 20_pointer_comparison... Test: 21_char_array... Test: 22_floating_point... Test: 23_type_coercion... Test: 24_math_library... Test: 25_quicksort... Test: 26_character_constants... Test: 27_sizeof... Test: 28_strings... Test: 29_array_address... Test: 31_args... Test: 32_led... Test: 33_ternary_op... Test: 35_sizeof... Test: 36_array_initialisers... Test: 37_sprintf... Test: 38_multiple_array_index... Test: 39_typedef... Test: 40_stdio... Test: 41_hashif... Test: 42_function_pointer... Test: 43_void_param... Test: 44_scoped_declarations... Test: 45_empty_for... Test: 47_switch_return... Test: 48_nested_break... Test: 49_bracket_evaluation... Test: 50_logical_second_arg... Test: 51_static... Test: 52_unnamed_enum... Test: 54_goto... Test: 55_lshift_type... make[2]: Leaving directory `/home/ramsay/tinycc/tests/tests2' make[1]: Leaving directory `/home/ramsay/tinycc/tests' $ $ ./tcc -vv tcc version 0.9.25 (i386 Linux) install: /usr/local/lib/tcc/ crt: /usr/lib
Re: [Tinycc-devel] test failure on Linux
Thomas Preud'homme wrote: Le mercredi 13 février 2013 17:16:28, Thomas Preud'homme a écrit : On Wed, 13 Feb 2013 08:30:14 -0700, arn...@skeeve.com wrote: Thomas Preud'homme robo...@celest.fr wrote: Why not but strike multiarch from that as I don't see how we could detect it by compiling a C program. Use the output of ldd to tell you where the C library is. Yep true, I thought about it last night and forgot about it in the morning. However I just pushed a commit using checking where is crti.o before reading your mail. It's a one line test so I think the solution is not too bad but you can prove me wrong of course. Thanks a lot for the suggestion. Thinking about it a bit I managed to come up with a much better patch. It's not totally done though but I have to leave. I'll push it tonight. Stay tuned. I haven't seen this yet and I may not be able to test it until the weekend. :( The good news is that commit af4b27f0f works! (see other email). ATB, Ramsay Jones ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] test failure on Linux
Thomas Preud'homme wrote: Le samedi 9 février 2013 17:01:44, vous avez écrit : Hi Sorry for not testing earlier, but the current 'mob' branch does not pass the tests for me, viz: $ git --no-pager log --oneline -1 7a477d7 lib/Makefile: use CC, add bcheck to libtcc1.a $ make clean /dev/null $ make out 21 $ make test make -C tests test make[1]: Entering directory `/home/ramsay/tinycc/tests' hello ../tcc -B.. ../examples/ex1.c -o hello ./hello tcc: error: file 'crt1.o' not found tcc: error: file 'crti.o' not found tcc: error: file 'crtn.o' not found tcc: error: undefined symbol 'printf' make[1]: *** [hello] Error 1 make[1]: Leaving directory `/home/ramsay/tinycc/tests' make: *** [test] Error 2 $ This is on (a somewhat dated) Linux (ubuntu): $ uname -a Linux ramsay-laptop 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux $ Can you tell me what is in /lib/i386-linux-gnu? Ultimately nothing! ;-) [Quoting from the email you are replying to]: $ ls -l /lib/i386-linux-gnu lrwxrwxrwx 1 root root 19 2007-06-24 19:44 /lib/i386-linux-gnu - /lib/i486-linux-gnu/ $ ls -l /lib/i486-linux-gnu/ total 0 $ Also we see: $ ls -l /usr/lib/crt?.o -rw-r--r-- 1 root root 2459 2007-04-04 11:31 /usr/lib/crt1.o -rw-r--r-- 1 root root 2296 2007-04-04 11:31 /usr/lib/crti.o -rw-r--r-- 1 root root 1824 2007-04-04 11:31 /usr/lib/crtn.o $ Also, can you tell me what is the final destination of the symbolic link /lib/ld-linux.so.2? $ ls -l /lib/ld-linux.so.2 lrwxrwxrwx 1 root root 9 2007-06-24 19:44 /lib/ld-linux.so.2 - ld-2.5.so* $ ls -l /lib/ld-*.so -rwxr-xr-x 1 root root 109268 2007-04-04 11:48 /lib/ld-2.5.so* $ I've added some further information from gcc below. If you need more information about my environment, or for me to test some patches etc., just let me know. Thanks! ATB, Ramsay Jones $ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4) $ $ gcc -print-file-name=crt1.o /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib/crt1.o $ $ gcc -print-search-dirs install: /usr/lib/gcc/i486-linux-gnu/4.1.2/ programs: =/usr/lib/gcc/i486-linux-gnu/4.1.2/:/usr/lib/gcc/i486-linux-gnu/4.1.2/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.1.2/:/usr/lib/gcc/i486-linux-gnu/:/usr/libexec/gcc/i486-linux-gnu/4.1.2/:/usr/libexec/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.1.2/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../i486-linux-gnu/bin/i486-linux-gnu/4.1.2/:/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../i486-linux-gnu/bin/ libraries: =/usr/lib/gcc/i486-linux-gnu/4.1.2/:/usr/lib/gcc/i486-linux-gnu/4.1.2/:/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../i486-linux-gnu/lib/i486-linux-gnu/4.1.2/:/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../i486-linux-gnu/lib/:/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../i486-linux-gnu/4.1.2/:/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../:/lib/i486-linux-gnu/4.1.2/:/lib/:/usr/lib/i486-linux-gnu/4.1.2/:/usr/lib/ $ ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] test failure on Linux
Hi Sorry for not testing earlier, but the current 'mob' branch does not pass the tests for me, viz: $ git --no-pager log --oneline -1 7a477d7 lib/Makefile: use CC, add bcheck to libtcc1.a $ make clean /dev/null $ make out 21 $ make test make -C tests test make[1]: Entering directory `/home/ramsay/tinycc/tests' hello ../tcc -B.. ../examples/ex1.c -o hello ./hello tcc: error: file 'crt1.o' not found tcc: error: file 'crti.o' not found tcc: error: file 'crtn.o' not found tcc: error: undefined symbol 'printf' make[1]: *** [hello] Error 1 make[1]: Leaving directory `/home/ramsay/tinycc/tests' make: *** [test] Error 2 $ This is on (a somewhat dated) Linux (ubuntu): $ uname -a Linux ramsay-laptop 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux $ A quick trip to the debugger shows that CONFIG_MULTIARCHDIR has been set such that it searches for the crt?.o files in /lib/i386-linux-gnu, which does not work: $ ls -l /lib/i386-linux-gnu lrwxrwxrwx 1 root root 19 2007-06-24 19:44 /lib/i386-linux-gnu - /lib/i486-linux-gnu/ $ ls -l /lib/i486-linux-gnu/ total 0 $ ls -l /usr/lib/crt?.o -rw-r--r-- 1 root root 2459 2007-04-04 11:31 /usr/lib/crt1.o -rw-r--r-- 1 root root 2296 2007-04-04 11:31 /usr/lib/crti.o -rw-r--r-- 1 root root 1824 2007-04-04 11:31 /usr/lib/crtn.o $ As a quick fix, I applied the patch given at the end of this email. This patch simply checks for the existence of the /usr/lib/crt?.o files and supresses the assignment to CONFIG_MULTIARCHDIR if they do. This fixes the problem for me (but may not be the *correct* fix, of course): $ make clean /dev/null $ git checkout fix Switched to branch 'fix' $ make out 21 $ make test make -C tests test make[1]: Entering directory `/home/ramsay/tinycc/tests' hello ../tcc -B.. ../examples/ex1.c -o hello ./hello Hello World ../tcc -B.. -run ../examples/ex1.c Hello World gcc -o libtcc_test libtcc_test.c ../libtcc.a -I.. -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -DTCC_TARGET_I386 -lm -ldl libtest ./libtcc_test lib_path=.. Hello World! fib(32) = 2178309 add(32, 64) = 96 cp ../include/tcclib.h . gcc -o tcctest.gcc tcctest.c -I. -I.. -w -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -DTCC_TARGET_I386 -std=gnu99 -O0 -fno-omit-frame-pointer ./tcctest.gcc test.ref test3 ../tcc -B.. -DTCC_TARGET_I386 -DONE_SOURCE -run ../tcc.c -B.. -DTCC_TARGET_I386 -DONE_SOURCE -run ../tcc.c -B.. -DTCC_TARGET_I386 -DONE_SOURCE -run ../tcc.c -B.. -run tcctest.c test.out3 Auto Test3 OK moretests make -C tests2 make[2]: Entering directory `/home/ramsay/tinycc/tests/tests2' Test: 00_assignment... Test: 01_comment... Test: 02_printf... Test: 03_struct... Test: 04_for... Test: 05_array... Test: 06_case... Test: 07_function... Test: 08_while... Test: 09_do_while... Test: 10_pointer... Test: 11_precedence... Test: 12_hashdefine... Test: 13_integer_literals... Test: 14_if... Test: 15_recursion... Test: 16_nesting... Test: 17_enum... Test: 18_include... Test: 19_pointer_arithmetic... Test: 20_pointer_comparison... Test: 21_char_array... Test: 22_floating_point... Test: 23_type_coercion... Test: 24_math_library... Test: 25_quicksort... Test: 26_character_constants... Test: 27_sizeof... Test: 28_strings... Test: 29_array_address... Test: 31_args... Test: 32_led... Test: 33_ternary_op... Test: 35_sizeof... Test: 36_array_initialisers... Test: 37_sprintf... Test: 38_multiple_array_index... Test: 39_typedef... Test: 40_stdio... Test: 41_hashif... Test: 42_function_pointer... Test: 43_void_param... Test: 44_scoped_declarations... Test: 45_empty_for... Test: 47_switch_return... Test: 48_nested_break... Test: 49_bracket_evaluation... Test: 50_logical_second_arg... Test: 51_static... Test: 52_unnamed_enum... Test: 54_goto... Test: 55_lshift_type... make[2]: Leaving directory `/home/ramsay/tinycc/tests/tests2' make[1]: Leaving directory `/home/ramsay/tinycc/tests' $ HTH ATB, Ramsay Jones -- 8 -- Subject: [PATCH] Makefile: Don't add multiarch directory for i386 Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile b/Makefile index 23045eb..f3bc96d 100644 --- a/Makefile +++ b/Makefile @@ -35,10 +35,12 @@ endif ifeq ($(ARCH),i386) NATIVE_DEFINES=-DTCC_TARGET_I386 +ifeq (,$(wildcard /usr/lib/crt?.o)) NATIVE_DEFINES+=\ $(if $(wildcard /lib/i386-linux-gnu
[Tinycc-devel] [PATCH] Add __REDIRECT needed for Large File Support API on linux
Since commit 9b09fc3 (Add support of asm label for functions, 05-09-2010) tcc has had the capability to rename functions at the assembly level. This capability was subsequently used by commit 2596273 (Add support for __REDIRECT_NTH needed with eglibc, 11-09-2010) to redirect long double functions on platforms which did not support long double. Here we add the companion macro __REDIRECT which is used (along with __REDIRECT_NTH) in the glibc headers on Linux to support the Large File API (when _FILE_OFFSET_BITS is set to 64). Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- Hi, This patch allows me to use tcc to compile git without warnings. Without this patch, each use of readdir() or getrlimit() elicits an assignment from incompatible pointer type warning. [BTW, tcc builds git about 6x faster than gcc. The testsuite runs about 6% slower.] ATB, Ramsay Jones libtcc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/libtcc.c b/libtcc.c index 159e23b..5e497c9 100644 --- a/libtcc.c +++ b/libtcc.c @@ -980,6 +980,7 @@ LIBTCCAPI TCCState *tcc_new(void) #endif /* glibc defines */ +tcc_define_symbol(s, __REDIRECT(name, proto, alias), name proto __asm__ (#alias)); tcc_define_symbol(s, __REDIRECT_NTH(name, proto, alias), name proto __asm__ (#alias) __THROW); #ifndef TCC_TARGET_PE -- 1.7.9 ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
