Re: [Tinycc-devel] '.' as code position in asm_expr_unary()

> But this label must be handled in a special way. My current solution: diff -urN tinycc.old/tccasm.c tinycc/tccasm.c --- tinycc.old/tccasm.c>2016-04-18 20:32:33.0 +0300 +++ tinycc/tccasm.c<--->2016-04-18 20:33:47.0 +0300 @@ -117,6 +117,11 @@ } else {

Re: [Tinycc-devel] '.' as code position in asm_expr_unary()

> It looks like '.' is not a label (current code position) for the > asm_expr_unary() After the patch "allow . in asm identifiers" '.' is a label. But this label must be handled in a special way. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org

[Tinycc-devel] '.' as code position in asm_expr_unary()

Hi! I'm trying to implement .rept macro for the following code: #define NR_syscalls 270 .globl sys_call_table sys_call_table: <--><-->.long 0 .rept NR_syscalls-(.-sys_call_table)/4 <--><-->.long 0 .endr It looks like '.' is not a label (current code position) for

Re: [Tinycc-devel] revert of "Identifiers can start and/or contain"

>#define PATHCMP stricmp >#if PATHCMP==stricmp >#error Michael is wrong >#else >#error Michael is right >#endif And then replace stricmp with something other. You will get the same result. As Michael say, we have #if 0 == 0 #error Michael is wrong #else #endif

Re: [Tinycc-devel] Development style

David Martens about exsymtab in 2015: http://lists.nongnu.org/archive/html/tinycc-devel/2015-05/msg00057.html Currently exsymtab development is done (I think) ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org

Re: [Tinycc-devel] Development style

> Gosh, and you even put the exsymtab stuff into [mob] now. Without discussion http://lists.nongnu.org/archive/html/tinycc-devel/2015-05/threads.html (David Martens) > don't think [mob] is working for you > Sigh. Will decide somewhen next week I guess. Very interesting. Who are deciders? >

Re: [Tinycc-devel] Preprocessor performance tuning

> improve hash performance A question: how to convert a exsymtab code related to define_pish() change. A snipped of the old code (before above patch) attached. define_push_old.snippet Description: Binary data ___ Tinycc-devel mailing list

Re: [Tinycc-devel] (OT) Re: using pcc to build tcc

> snapshots http://pcc.ludd.ltu.se/ftp/pub Thanks > Regrettably, pcc with disabled gcc compatibility does not compile tcc (breaks > on tcclib1.c). No problem with CC=pcc on [mob] and ARCH=i386 libtcc1.c is compiled by tcc even if CC="pcc -disable-gcc-compat" I can assume we speek about

Re: [Tinycc-devel] using pcc to build tcc

>> * pcc is a nice compiler: small, classic design, some optimizations >> and checks, some original >> ideas. > +1 u-tcc-uepj, Is there a git repository of the pcc? Comparing pcc and pcc 1.2.0.DEVEL 20141206: 1) pcc don't have __linux macro defined 2) a test program (with strays) #include int

Re: [Tinycc-devel] Preprocessor performance tuning

Hi! With the last patch: make test error: memory full I thinks the previous one can be commited. Improvements and tuning can be done later. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org

Re: [Tinycc-devel] Implementing gcc intrinsics

> IMO, the way to go w/ performance improvement is to vectorize the curent hash > implementation. Instead of computing the hash one character at a time, take > next 4 characters, process these in parallel and compute 4 hashes Why not 8? ___

Re: [Tinycc-devel] Implementing gcc intrinsics

> Tries for sym lookup IMO are a dead end Tries were used a year ago. Current version use a hash table. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Preprocessor performance tuning

> You can try increasing `TOKSTR_TAL_SIZE` to 32MB. Then 256MB? When usage drops below 100% on Limit=128 allocator then you can start decreasing it, if you have to fine tune the capacity. Can this be tuned by some new tcc option? Or some option to automatically increase limits (no limits)? PS:

Re: [Tinycc-devel] using pcc to build tcc

> 1. "addr_t vs int" looks hardly pcc-specific A warning is given by pcc (and not by gcc) about wrong arguments to the type_size() int type_size(CType *type, int *a); size = type_size(>type, ); > CC="pcc -D__linux" does the job There is no any failures in the compilation process of the tcc

Re: [Tinycc-devel] Preprocessor performance tuning

Suggestion: use -bench to output your stats when TAL_INFO=1 ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Preprocessor performance tuning

> With latest tweaks I get ~58MB/s compilation speed on average, up from > 46MB/s by latest mob before the patch. How to improve tccboot compilation? imit= 128, nb_peak= 5163, nb_total=36465, nb_missed=1900890, nb_failed=1497568, 100% limit= 256, nb_peak=37939, nb_total=37939, nb_missed=

Re: [Tinycc-devel] Implementing gcc intrinsics

> I hate code-bloat and can see the "scars" the mob branch has inflicted on > the codebase. Now I consider some of my earlier commits to be mistakes > (tcc's -dM option anyone?) but sometimes impl a new feature in 10 lines of > code look very tempting. It is OK with -dM. Nothing wrong or

Re: [Tinycc-devel] Implementing gcc intrinsics

> Looking changes in exsymtab branch of tcc (https://github.com/pipcet/tinycc) > since Sorry. exsymtab is developed by David Mertens His branch on github is https://github.com/run4flat/tinycc And my port of the exsymtab (posted) for the [mob] based on commit

Re: [Tinycc-devel] Implementing gcc intrinsics

> Can try to extract this Sorry, reading a comment: no op now (a patch attached) 001-builtin_expect.tgz Description: GNU Zip compressed data ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Implementing gcc intrinsics

> I see that in TODO there is a note about __builtin_expect in missing > features. Until this gets impl as codegen hint a simple macro is a working > alternative IMO. Looking changes in exsymtab branch of tcc (https://github.com/pipcet/tinycc) since may 2015 I found __builtin_expect realization.

Re: [Tinycc-devel] Implementing gcc intrinsics

>> I was thinking about a simple C subset parser that produces AST of the >> inline if sucessful. > tinycc has no AST. I don't think what you want is in scope for tcc. Can exsymtab patch for tcc help? A patch attached. It is a pipcet patch 2015-05 ported to the current [mob]. Since that pipcet

Re: [Tinycc-devel] .rept .endr for *.S. Any ideas?

> See begin_macro and it's uses. That can store token in a buffer, which > you then have to repeatedly reset macro_ptr from. E.g. the use in > tccgen.c for initializer parsing. Thanks. PS: > 2.4.26 was released 2004, 12 years ago https://www.kernel.org/pub/linux/kernel/v2.4/

Re: [Tinycc-devel] using pcc to build tcc

> (But why bother with pcc at all?) * pcc is a nice compiler: small, classic design, some optimizations and checks, some original ideas. * we don't use advanced features of the tcc/gcc in the code assuming we must be able compile tcc by average C compiler. pcc is the one of these compilers.

Re: [Tinycc-devel] Error in UUID *Uuid[1];

> I followed these instructions: ... > I need to update official release? I think this bundle is quite fresh. Did you include "winapi/guiddef.h"? ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org

Re: [Tinycc-devel] Preprocessor performance tuning

> Let me know what you all guys think and @seyko can you please test it again > w/ tccboot. tcc speed up on one big source (one tcc call with all files) is not improved: 4%. But speed up on many tcc calls with one file: yes, 7-15%. Nice result. ___

Re: [Tinycc-devel] Preprocessor performance tuning

> @seyko: Can you please test it with tccboot. I get a 7-8% better overall tcc > performance with the patch applied. Yes, this version is faster. But on tccboot there is only a 4% speedup: from 24.5 MiB/s to 25.5 MiB/s ___ Tinycc-devel mailing list

Re: [Tinycc-devel] __ARM_NR_cacheflush

> Both of these cross-compiling cases (arm and arm64) used to work, I > think. So it would be worth going back in history to see when they > broke, and why. Or there's the risk we could blunder forwards with a > sequence of quick fixes, each of which breaks an average of two other > things... I

[Tinycc-devel] ARM64 cross-compiling

./configure --enable-cross make cc -o arm64-tcc tcc.c -DONE_SOURCE -DTCC_TARGET_ARM64 -I. -Wall -g -O0 \ -Wdeclaration-after-statement -Wno-deprecated-decl arations -Wno-strict-aliasing \ -Wno-sign-compare -Wno-uninitialized -fno-strict-aliasing -lm -ldl lib/libtcc1.c lib/libtcc1.c:145:2: #error

Re: [Tinycc-devel] __ARM_NR_cacheflush

Proposed patch attached... 02-arm-cacheflush.patch Description: Binary data ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] __ARM_NR_cacheflush

Hi ./configure --enable-cross make gcc -o arm-linux-fpa-tcc tcc.c -DONE_SOURCE -DTCC_TARGET_ARM -I. -Wall -g -O0 -Wdeclaration-after-statement -Wno-deprecate lib/libtcc1.c: In function `__clear_cache': lib/libtcc1.c:740: error: `__ARM_NR_cacheflush' undeclared (first use in this function)

Re: [Tinycc-devel] using pcc to build tcc

More info: a tcc compiled by pcc don't have some defines: --- 111>2016-04-15 08:08:57.0 +0300 +++ 112>2016-04-15 08:09:36.0 +0300 @@ -4,6 +4,8 @@ // #define __WCHAR_TYPE__ int // #define __PTRDIFF_TYPE__ long // #define __SIZE_TYPE__ unsigned long -// #define __linux 1 -//

Re: [Tinycc-devel] Error in UUID *Uuid[1];

> May be anyone can give me a clue. Do you use version from the [mob] branch? There was error caused with incomplete headers (UUID must be defined) ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org

[Tinycc-devel] using pcc to build tcc

Hi ./configure --cc=pcc make pcc -o i386-tcc tcc.c -DONE_SOURCE -DTCC_TARGET_I386 -I. -Wall -g -O0 -lm -ldl /tmp/ctm.Uao6qA: In function `set_pages_executable': tccrun.c:238: undefined reference to `__clear_cache' error: ld terminated with status 1 But it is OK if we add lib/libtcc1.c A fast

Re: [Tinycc-devel] .rept .endr for *.S. Any ideas?

> Simply use GNU as for compiling your .S files from that old kernel. It is not so old. It boots fine on AMD v140 CPU 2.2Ghz notebook (2011) And this kernel is compiled in one pass, with all source files passed to the tcc. There are a few *.S files along *.c > Remember tokes between the

Re: [Tinycc-devel] revert of "Identifiers can start and/or contain"

> Probably a separate PATH_NOCASE and then #ifdef PATH_NOCASE? Yes, I agree with this. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] .rept .endr for *.S. Any ideas?

Hi Currently tcc don't implement .rept and .endr directives in *.S In tccboot kernel we have (arch/i386/kernel/entry.S) #if 0 .rept NR_syscalls-(.-sys_call_table)/4 <--><-->.long SYMBOL_NAME(sys_ni_syscall) <-->.endr #else .long SYMBOL_NAME(sys_ni_syscall)

Re: [Tinycc-devel] revert of "Identifiers can start and/or contain"

About `ppfp` being NULL, I saw most of the code has guards, obviously > missed > a few places that don't. Will impl these and keep `ppfp` NULL when no > preprocessor output is expected. > > cheers, > > > -Original Message- > From: Tinycc-devel > [mailto:tinyc

Re: [Tinycc-devel] Compile .c file to .pyd

> Weird. I cannot find such error message in sources. > There is "cannot find library 'lib%s'" in both tcc.c and libtcc.c Looks like old tcc 0.9.26 (release) was used. In old tcc a message was "cannot find library: %s". In the old tcc a file name reported like -lpython insteed of libpython PS:

Re: [Tinycc-devel] Implementing gcc intrinsics

> I can see that for inlines there is a separate `InlineFunc` struct that > keeps function body until end of generation when in `gen_inline_functions` > only the referenced inlines are generated as regular functions. Then we can search if a function to call is inline function and if so, parse

Re: [Tinycc-devel] Compile .c file to .pyd

> -L C:\Python34\libs -lpython34 > i get: > tcc: cannot find -lpython3.4 Is '.' was added by tcc? ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Implementing gcc intrinsics

> Actually, is there support for inlines in tcc? No, tcc don't inline functions. From tcc-doc.texi: inline keyword is ignored But I thinks it is not so difficult to implement this in preprocessor (like macro) ___ Tinycc-devel mailing list

Re: [Tinycc-devel] revert of "Identifiers can start and/or contain"

Hi! A correct version of the patch is pushed to the [mob] A problem was in TOK_ASMDIR_text: -sprintf(sname, ".%s", get_tok_str(tok1, NULL)); +sprintf(sname, "%s", get_tok_str(tok1, NULL)); When tok1 is '.text', then sname is '..text'

Re: [Tinycc-devel] revert of "Identifiers can start and/or contain"

> If replace L10 with .L10 and compile it by tcc with ident_patch No need to replace L10 with .L10. This version of the tcc (with ident_patch) don't produce a code in the *.o file. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org

[Tinycc-devel] revert of "Identifiers can start and/or contain"

Hi! I reverted "Identifiers can start and/or contain '.' in *.S" because tccboot kernel hangs when compiled with this patch. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] GAS symbols

> PS: what is the need to have '.' in asm idents? Looks like there is a need to have a switch like -fdots-in-asm-idents ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] GAS symbols

Jusy descovered. While a test is OK, tccboot hangs. It boots OK with current mob when patch for '.' in *.S is reversed. PS: what is the need to have '.' in asm idents? ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org

[Tinycc-devel] tccboot sources on github

Hi! https://github.com/seyko2/tccboot Using TinyCC to compile Linux kernels Testing tcc compilation speed and correctness. Studying Linux kernel internals.and Linux kernel development. Original author of the tccboot project is Fabrice Bellard: TCCBOOT: TinyCC Boot Loader

Re: [Tinycc-devel] GAS symbols

> but I don't see where do you restore its prev value for the rest of the input? No need to do this. There is additional explicit check for '.' parse_num: for(;;) { t = c; cstr_ccat(, c); PEEKC(c, p); if (!((isidnum_table[c - CH_EOF] &

Re: [Tinycc-devel] GAS symbols

> This is weird. Could be the second table introduces some cache misses but > probably someone else might chime in with better explanation and/or > suggestion how to improve this. A first version of the patch with speed optimization is pushed to the [mob]. A compilation speed is not changed by

Re: [Tinycc-devel] nocode_wanted does not work

Looks like the following patch solves the problem with for/while inside {()}. But I don't found solution for ({ return;}) when nocode_wanted. An tgz with patch and tests is attached. diff --git a/tccgen.c b/tccgen.c index 7be2f2f..c1d5cae 100644 --- a/tccgen.c +++ b/tccgen.c @@ -3848,7 +3848,8

Re: [Tinycc-devel] GAS symbols

> PS: (Nov 8, 2004) TCC version 0.9.22 is out (Changelog). Linux kernel > compilation is 30% faster (10 seconds on a 2.4 GHz Pentium 4). Looks like gcc-3.4.6 optimize better than one used in the above test. A current tcc compiled by itself is 2 times slower 37891 idents, 6652803 lines, 193678862

Re: [Tinycc-devel] GAS symbols

> Thanks. I will test a speed of two versions on tccboot It looks like a version of the patch with 2 tables is a bit slower 2 tables on AMD v140 2.2 GHz with 2 GiB of RAM 37918 idents, 6652803 lines, 193678862 bytes, 8.097 s, 821590 lines/s, 23.9 MB/s 37918 idents, 6652803 lines, 193678862

Re: [Tinycc-devel] nocode_wanted does not work

> Have you tried goto and switch, or return? No problem with goto and switch. return is performed. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] GAS symbols

bels). > > cheers, > > > -Original Message- > From: tinycc-devel-bounces+wqweto=gmail@nongnu.org > [mailto:tinycc-devel-bounces+wqweto=gmail@nongnu.org] On Behalf Of > Sergey Korshunoff > Sent: Wednesday, March 30, 2016 12:34 PM > To: tinycc-devel@nongn

Re: [Tinycc-devel] nocode_wanted does not work

do not accept break/continue inside as GCC does */ block(NULL, NULL, NULL, NULL, 0, 1); skip(')'); } else { gexpr(); skip(')'); } This is a save_regs(0) which generate a code when nocode_wanted=1 When if(!nocode_wanted) save_regs(0); then there is no error messages but a test

Re: [Tinycc-devel] nocode_wanted does not work

> Or at least fail with an explanatory > message if o() is called while nocode_wanted is set? I can not grock what is wrong (where is the error). But is starts in block.c: 5001 when ({}) is used. antoo # gdb tcc (gdb) set args vla_label_fix_problem.c (gdb) b check_nocode_wanted Breakpoint 1 at

Re: [Tinycc-devel] nocode_wanted does not work

> Or at least fail with an explanatory > message if o() is called while nocode_wanted is set? How to get backtrace from the o() in such case (w/o debugger)? 2016-04-03 12:13 GMT+03:00 Edmund Grimley Evans < edmund.grimley.ev...@gmail.com>: > > Hi! The following test hangs when compiled with tcc

[Tinycc-devel] vla_label_fix_problem

Hi! The following test hangs when compiled with tcc after 737f98421 tccgen.c: Bug fix for 992cbda and 3ff77a1: set nocode_wanted. tests/tests2/78_vla_label.*: Add test fantoo 222 # ./vla_label_fix_problem.sh begin timeout=2 extern int printf(const char *format, ...); static void

Re: [Tinycc-devel] GAS symbols

gt; cheers, > > > -Original Message- > From: tinycc-devel-bounces+wqweto=gmail@nongnu.org [mailto: > tinycc-devel-bounces+wqweto=gmail@nongnu.org] On Behalf Of Sergey > Korshunoff > Sent: Wednesday, March 30, 2016 11:54 PM > To: tinycc-devel@nongnu.org > Subjec

[Tinycc-devel] FIXME: handle reloc type 5 at

What this message means? There was no such message before. (linux i386) ./configure --cc=tcc --enable-cross make tcc -o i386-tcc tcc.c -DONE_SOURCE -DTCC_TARGET_I386 -I. -Wall -g -O0 -lm -ldl FIXME: handle reloc type 5 at 8088100 [0xa2a0] to 0 FIXME: handle reloc type 5 at 8088110 [0xa2b0] to

Re: [Tinycc-devel] more 'include_next' errors (with tcc, GNU Coreutils)

> Modify the build system to delete the repeated directories from: > Thanks, this worked (with the latest git revision): > However, I'm not sure how to reliably modify the makefiles of coreutils > (especially given that > gcc,clang handle this situation without a problem). A patch to delete the

Re: [Tinycc-devel] GAS symbols

> or switching PARSE_FLAG_ASM_FILE off for preprocessor directives in .S files Thia solution looks better (maybe only for #defune) because a test program preprocessed fine if we rename it to *.c ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org

Re: [Tinycc-devel] GAS symbols

Hi! Patch "Identifiers can start and/or contain '.' in PARSE_FLAG_ASM_FILE" breaks preprocessing on *.S A test program (from a linux-2.4.26) #define SRC(y...) \ : y;\ .section __ex_table, "a"; \ .long b, 6001f

Re: [Tinycc-devel] old nocode_wanted problem

>> I assume that test now works > No. I tried to restore a check and got an error message caused by first part (before ':') of the cond expr. I will try to reduce a test. A reduced test: int main() { int romfsb_size = 1; int nblocks_good_1 = __builtin_constant_p( 1 ) ? ({ 2; })

Re: [Tinycc-devel] Change order of built-in include paths?

> Does anyone, and in particular grischka, who last modified this code, object to the following patch? I like this change... Very logical. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] old nocode_wanted problem

>> A test program related to this issue: > I assume that test now works No. I tried to restore a check and got an error message caused by first part (before ':') of the cond expr. I will try to reduce a test. ___ Tinycc-devel mailing list

[Tinycc-devel] old nocode_wanted problem

Hi all There may be some other bugs in tcc related to nocode_wanted Check commit 78c076a70f5 The following check in tccgen.c is removed if (nocode_wanted) tcc_error("statement expression in global scope"); This check is introduced in commit 5bcc3eed7b93 and breaks

Re: [Tinycc-devel] last kernel compatible with TinyCC

> yes it's curently too weak but isn't it better to abstract the whole > toolchain for linux build system? I like a build method implemented in tccboot: a list of the source files compiled by one call to the tcc. A bad thing - a source files patching is needed for features not implemented in

Re: [Tinycc-devel] last kernel compatible with TinyCC

> Is there some work effort in order to modularize the linux build system for > different toolchains on recent kernels? It is related to the clang compiler. tcc is to weak. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org

Re: [Tinycc-devel] # .. in *.S files regression

> PS: ccompilation of the coreutils-8.24.51-8802e fails too after a patch "Replace pointer casts with calls to (read|write)(16" (i386 userland and kernel) ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org

[Tinycc-devel] # .. in *.S files regression

a last grishka patch reversed a '...' handling by reason "not a reliable way to lookahead". Now asm code in tccboot kernel can't be compiled by tcc. Very nice "reliable way" PS: ccompilation of the coreutils-8.24.51-8802e fails too: ./build-aux/depcomp: line 173: 26355 Segmentation fault

Re: [Tinycc-devel] # .. in *.S files regression

Problem with " # xx." comments in asm files: we eat spaces and xx is analyzed as preprocessor directive before we start think that this is comment in asm file ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org

Re: [Tinycc-devel] # .. in *.S files regression

> p[1] is not allowed because it can point after EOB Yes, it can. But what algo wanted: if there is only 2 '.', return tok='.', not the error message. It is a parser, not a syntax checker. Is this possiible? PS: about include_next: why not let be more gcc compatible with some switch?

Re: [Tinycc-devel] # .. in *.S files regression

> If you have a test case it should be possible to find the problem by > bisection: undo parts of the patch, starting off by undoing all the changes in tccelf.c, or all the changes in i386-gen.c, for example reverse for the i386-gen.c solved a problem. What next?

Re: [Tinycc-devel] # .. in *.S files regression

> reverse for the i386-gen.c solved a problem. What next? A last chunk of the i386-gen,c patch returned a problem ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] last kernel compatible with TinyCC

Hi clement rocher > I would like to know wich Linux kernel is last compilable with TinyCC on X86 > and X86-64. Only 2.4.26 (32 bit) patched. A future work is needed to use tcc for compiling 2.4.39 https://lists.gnu.org/archive/html/tinycc-devel/2015-04/msg00121.html

Re: [Tinycc-devel] RE :Re: VLA implementation

> You'll probably first have to insert a return at the start of tcc_normalize_inc_dirs to prevent the errors caused by that buggy function from confusing things. -for (j=0; i < num_sysinc; i++) { +for (j=0; j < num_sysinc; j++) { But your implementation looks better :-)

Re: [Tinycc-devel] RE :Re: VLA implementation

> Then everything would have to be tested with and without the pragma. Quite a maintenance burden for a feature that doesn't seem to be much in demand. declaring a VLA array at the start of the function (before any code) can be a replacement for the pragma (much more natural way). In thise case a

Re: [Tinycc-devel] RE :Re: VLA implementation

> declaring a VLA array at the start of the function (before any code) can be a replacement for the pragma (much more natural way). In thise case a stack restoring can be moved from jump point to the label point. Or we use an old algo for the stack restoring and issue a warning. It is a sulution

Re: [Tinycc-devel] RE :Re: VLA implementation

> the current implementation is not compatible with signal handlers, or anything similar, asynchronously using the same stack. > For example, when goto is translated, if there are VLAs in scope then gen_vla_sp_restore(vla_sp_root_loc) is called, which generates code to move the SP back to where

Re: [Tinycc-devel] RE :Re: VLA implementation

> It is hard to combine gen_vla_sp_restore(vla_sp_root_loc) and gen_vla_sp_restore(vla_sp_loc) For example: marking a function in advance as one with VLA by #pragma and don't lower stack usage by the jump/break/... ___ Tinycc-devel mailing list

Re: [Tinycc-devel] VLA implementation

> I don't know. Can you find out? You ask me to perform a tcc job. We have a 2.4.26 "tccboot" kernel. How one may be shure that there is no VLA? Only trust a rule? PS: tcc compiled kernel sometime hangs, a message about "freeing -4K" RAM don't let be optimistic PPS: 6 Mar 2013: there are VLA in

Re: [Tinycc-devel] VLA implementation

> Linux/FreeBSD kernel don't use VLA? Shure? How about kernel modules? More frequent case: signal handlers w/o different stack. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] VLA implementation

od for introducing VLA warnings? Where to insert it right? 2015-11-10 7:51 GMT+03:00, Sergey Korshunoff <sey...@gmail.com>: >> I don't know. Can you find out? > You ask me to perform a tcc job. We have a 2.4.26 "tccboot" kernel. > How one may be shure that there is no V

Re: [Tinycc-devel] VLA implementation

> Where to insert it right? http://www.spinics.net/lists/linux-sparse/msg03139.html Some USB code use this kind of the dynamic array. However, it does not allocate the struct in the stack, the struct is allocated via kmalloc using pointer ___

Re: [Tinycc-devel] "mormalize_inc_dirs"

> However, how come the old code did not need to compare such two dirs, and > still > worked correctly? If the old code was working correctly without needing to > compare > two actual dirs, despite it not being "n[m]ormalized", maybe it's still the > better > solution because it depends less on

Re: [Tinycc-devel] "mormalize_inc_dirs"

> A correction for Windows will be in near feature Sorry, ... in the near future. 2015-11-08 1:02 GMT+03:00, Sergey Korshunoff <sey...@gmail.com>: >> However, how come the old code did not need to compare such two dirs, and >> still >> worked correctly? If the old

Re: [Tinycc-devel] VLA implementation

> I don't know. Which software do you have that uses VLAs? VLA -- variable length arrays int a1[20]; // fixed length array int i = 20; int a2[i]; // variable length array But yes, I don't use a strange GNU rules like escaping VLA from inner block. Only as usual arrays with calculated at runtime

Re: [Tinycc-devel] "mormalize_inc_dirs"

> WinXP SP3 32bit, MinGW(tcc self compilation test) > Using the compiled tcc to recompile tcc itself fails with windows.h not found. > I have to reverting this commit to recover. Anyone know solution for stat? From Google: "stat" not working on Windows XP using v14_xp platform ... stat()

Re: [Tinycc-devel] Modified/broken resolution of include dirs

Hi avih > rior to this commit, when building tcc itself (configure and make), after > successfully > building the tcc executable (on windows for windows), it starts building > libtcc1.a using > the just-compiled tcc.exe, and succeeded. > This process now fails for me Thanks. I will check this.

Re: [Tinycc-devel] "mormalize_inc_dirs"

Hi! > mormalize This will be fixed. Thanks. > Could you please review your recent contributions? Valgrind reports > problems with them Yes., I will. May be I not found/corrected some other code outside of the include/include_next > BTW this commit breaks tcc compiling itself afterwards What

Re: [Tinycc-devel] VLA implementation

> Would it, perhaps, be easier to turn TCC into a correct C11 compiler than > into a correct > C99 compiler? No, please. Currently all try to break old software. Ability to compile VLA with interrupts is a must for me. Why we performed all work for VLA at all?

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 151, Issue 7

> I think your commit which replaced TOK_memcpy with TOK_memmove broke the > ARM builds, I'm fixed this on mob ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] VLA implementation

> Is this worth fixing? Or just document it as a limitation? I think this is very important. Don't using VLA and signal handler's at the same time is not acceptable. But what the ways? ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org

Re: [Tinycc-devel] How to make mingw-w64 header files work with tcc ?

Hi! May be CC="tcc -DULONG=unsigned" ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] RE :Re: modern c++ compiler written in C (food forthought)

http://www.andythomason.com/lecture_notes/euro_llvm/talk.html How to build LLVM in ten seconds - or die trying! - About 31½mins on decent machine @ -O0 - EDG (same size as Clang) builds in 1sec ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org

Re: [Tinycc-devel] RE :Re: modern c++ compiler written in C (food forthought)

> motivation-4) have a modern c++ compiler written in C. > - Cfront is definitely not a modern c++, it will take age to make it c++ > compliant, even with > C++98 I have a nice old C++ liibs which can not be compiled by modern compilers w/o mod's. Don't having a need to compile old gcc

Re: [Tinycc-devel] RFC [PATCH] win: libm: fix "unknown constraint 't'", missing fpclassify/round/etc

Hi avih! > To address these issues, code which used inline asm with 't' was replaced with > a C implementation, and the missing __fpclassify functions were added A patch attached for the "t" issue. It is much faster Don't throw an asm code away. A C implementation can be as an option Please test.

Re: [Tinycc-devel] modern c++ compiler written in C (food for thought)

> Microsoft C 18.0 Win32 (32 bits) | 1.865 > Microsoft C 18.0 Win32 (Compile) | 1.289 OpenLisp is so fast! Interpreted code runs as fast as LAP > Legend: (I)nterpreted, (L)ap, (C)ompiled, (H)alf-compiled. > TestOpenLispv7.9(L) TISLv4.0(H) > Fib 0.008 0.010 And

Re: [Tinycc-devel] modern c++ compiler written in C

2015-05-14 14:06 GMT+03:00, u-tcc-u...@aetey.se : > Btw openwatcom license seems to be no less a minefield than cfront. >From openwatcom/bld/ncurses/readme.txt This is a stripped down version of ncurses, only the components necessary to compile the Linux versions of

<    1   2   3   4   5   >