Re: [Tinycc-devel] _Generic or __builtin_choose_expr

Hi, On Fri, 30 Jun 2017, uso ewin wrote: > I'd like to do that, problem is with default: > if we encounter a default, > we need to remember that there is a default in the generic, > but we need to continue parsing generic expression to check > if there is a type that match, and with you

Re: [Tinycc-devel] _Generic or __builtin_choose_expr

Hi, On Tue, 4 Jul 2017, grischka wrote: > Michael Matz wrote: > > First string literals are now always const char, ... > > Hm... ;) > > Actually the behavior with -Wwrite-strings that we had is what > gcc has too: > > typeof("123") cc = "456

Re: [Tinycc-devel] _Generic or __builtin_choose_expr

Hi, On Tue, 4 Jul 2017, Michael Matz wrote: > Ugh, you're right. Indeed the standard doesn't mandate a const char[] > type for string literals (I was confused because it does say that > modification of string literals is undefined, i.e. that's an extension). > Let me work o

Re: [Tinycc-devel] _Generic or __builtin_choose_expr

Hi, On Mon, 3 Jul 2017, uso ewin wrote: > I've try to use skip_or_save_block but using this function would ask me to > completely refactor it, > so I've made a skip_or_save_block2 > (code here: > https://github.com/cosmo-ray/tcc/commit/48e16cb2e33ea39b5051992ab23b006523fd14b4 > ), > it work

Re: [Tinycc-devel] tinycc predefined macro

Hi, On Wed, 28 Jun 2017, Gabriele Fulgaro wrote: > Can tinycc implementing in future __COUNTER__ macro? Would be easy to do. Why do you need it specifically? It's non-standard. Even though a couple compilers provide it, it would be good to have some rationale for adding it. Ciao,

Re: [Tinycc-devel] _Generic or __builtin_choose_expr

Hi, On Wed, 28 Jun 2017, uso ewin wrote: > > Are there any plans for C11's _Generic or at least __builtin_choose_expr? > > > > > > Best regards, > > Petr Skocik > > > > ___ > > Tinycc-devel mailing list > > Tinycc-devel@nongnu.org > >

Re: [Tinycc-devel] _Generic or __builtin_choose_expr

Hi, On Tue, 4 Jul 2017, uso ewin wrote: > I've just force push the change on my github, so now it should have the > same behaviour as gcc Please move the tests to a new file in tests/tests2/94_generic.c . Then I think this can go into mob. Ciao, Michael.

Re: [Tinycc-devel] Annoying new warning

Hi, On Sat, 29 Apr 2017, Christian Jullien wrote: No one looking at it? What is the behavior of this test when lower is unitialized? As the comment above the structure clearly says, this is the layout for x86 only (the x87 80bit long double type). ARMs long double type simply is double

Re: [Tinycc-devel] bitfield handling

Hello, On Tue, 2 May 2017, grischka wrote: Michael Matz wrote: I chose to adjust field layout instead of field type; the latter can cause invalid mem accesses with packed structs/fields: Hi Michael, May I suggest something: It appears to me that it's the point of packed (pcc) bitfields

Re: [Tinycc-devel] bitfield handling

Hi, On Wed, 3 May 2017, grischka wrote: > However, suppose we have a field with bit_pos=5,bit_size=32. > In order to read it we need to read 40 bits, yes? How do we > do that on a 32-bit target, for example? Yep, we don't (i.e. we're buggy in these cases and always were). It's one example of

Re: [Tinycc-devel] _Generic or __builtin_choose_expr

Hi, On Fri, 16 Jun 2017, Petr Skočík wrote: > Are there any plans for C11's _Generic or at least > __builtin_choose_expr? __builtin_choose_expr is implemented since July last year. Ciao, Michael.___ Tinycc-devel mailing list Tinycc-devel@nongnu.org

Re: [Tinycc-devel] building older gcc with tcc?

Hi, On Sat, 27 May 2017, ra...@openmailbox.org wrote: I would like to build an older version of the gcc compiler using tcc (then use that to build newer gcc's). On this page it says that tcc was used to build gcc in the past. I did that

Re: [Tinycc-devel] building older gcc with tcc?

Hi, On Sat, 27 May 2017, Michael Matz wrote: Obviously all of the above requires non-trivial amounts of work :) Actually it was in stage1 and the problem was parameter passing on x86-64. I was sitting on a patch for a time that rewrites that and happens to fix the problem, so I've pushed

Re: [Tinycc-devel] Add support of musl-libc to tinycc

Hi, On Sat, 6 May 2017, Larry Doolittle wrote: Micheal, Marc, and tinycc lurkers - On Sun, May 07, 2017 at 04:54:38AM +0200, Michael Matz wrote: On Thu, 20 Apr 2017, Marc Vertes wrote: I just committed the patch to support musl-libc in the tcc compiler development branch: http://repo.or.cz

Re: [Tinycc-devel] Annoying new warning

Hi, On Sun, 7 May 2017, Christian Jullien wrote: Forget one moment what has been said so far and concentrate on my concern with narrowed info. Facts: Yes, all known and agreed upon. * Finally, arm-gen.c uses TOK___fixxfdi with yet another #if condition => LDOUBLE_SIZE != 8 #if

Re: [Tinycc-devel] tiny bit of lint

Hi, On Sun, 7 May 2017, Larry Doolittle wrote: Using gcc's -Wextra, I found 17 "unused parameter", which could be addressed by bloating the source code a bit (casting to void), and with no consequence on the binary. If anyone else thought that would be an improvement, I'd be happy to write

[Tinycc-devel] ll-bitfield test on i386-linux

Hello grischka, parts of your last patch: * tcctest.c: remove outdated limitation for ll-bitfield test It always worked, there is no reason why it should not work in future. That's not true. The comment I've put there tried to explain it: -#ifndef __i386__ -/* on i386 we

Re: [Tinycc-devel] bitfield handling

Hi, On Sun, 30 Apr 2017, Vicente Bergas wrote: struct{short x:12; char y:1;}s; s.y=1; Note that the above is tricky: char can be signed and unsigned if not explicitely specified, and if it's signed then a 1-bit bitfield of char only contains values -1 and 0, so storing a 1 into it actually

Re: [Tinycc-devel] bitfield handling

Hi, On Fri, 28 Apr 2017, Vicente Bergas wrote: For example the following does not work: struct{short x:12; char y:1;}s; s.y=1; Note that the above is tricky: char can be signed and unsigned if not explicitely specified, and if it's signed then a 1-bit bitfield of char only contains values

Re: [Tinycc-devel] This (incorrect) code crashes the compiler

Hi, On Thu, 4 May 2017, Tony Papadimitriou wrote: char xxx()[] {}   Specifically, it’s the (wrong) use of [] that causes the crash. Fixed in mob (the crash, not implementing full support for this extension of returning arrays from functions; it's regarded as returning a pointer to char).

Re: [Tinycc-devel] tiny bit of lint

Hi, On Mon, 8 May 2017, Christian Jullien wrote: > tcc.h: (in function is_space) > tcc.h:1244:12: Operands of == have incompatible types (int, char): ch == ' ' > A character constant is used as an int. Use +charintliteral to allow > character constants to be used as ints. (This is safe

Re: [Tinycc-devel] Annoying new warning

Hi, On Sat, 6 May 2017, Christian Jullien wrote: Using your advice, I added #if !defined(TCC_TARGET_ARM) around all code directly or indirectly using ldouble_long which solved warning. But you now also ifdefed out __fixunsdfdi and __fixdfdi. That can't work, they are called from the

Re: [Tinycc-devel] Annoying new warning

Hi, On Sat, 6 May 2017, Christian Jullien wrote: I'm a bit confused now. As documented and pointed out by grischka /* only for x86 */ union ldouble_long { long double ld; struct { unsigned long long lower; unsigned short upper; } l; }; ldouble_long should only be used

Re: [Tinycc-devel] Add support of musl-libc to tinycc

Hi, On Thu, 20 Apr 2017, Marc Vertes wrote: I just committed the patch to support musl-libc in the tcc compiler development branch: http://repo.or.cz/w/tinycc.git I tested the patch on alpine-linux x86_64. Beside disabled bound checking, everything works so far, except the dlltest target

Re: [Tinycc-devel] Annoying new warning

Hi, On Mon, 1 May 2017, Daniel Glöckner wrote: On Sat, Apr 29, 2017 at 07:55:18PM +0200, Michael Matz wrote: ARMs long double type simply is double itself, and hence these functions are unused on ARM. Well, they would be if there wouldn't be strange code in arm-gen.c that makes use of xfdi

Re: [Tinycc-devel] Argh! No PIE on musl libC (i give up)

Hi, On Thu, 5 Oct 2017, Steffen Nurpmeso wrote: > But so i tried a simple-minded approach which surprisingly simple > ends up as Yeah, that's not enough. You need to adjust relocation processing to be more like TCC_OUTPUT_DLL mode (which then eventually results in unoptimal but working

Re: [Tinycc-devel] Unify C and asm symbols (was: forward asm symbols vs static)

Hi, On Mon, 27 Nov 2017, Christian Jullien wrote: > Hi Michael, > > Using native Windows 32/64 builds from mob, I see no errors on tests suite. > My RPi 3 box installed with Debian 32bit is also very happy. > > Good job Cool, thanks for checking, I appreciate that. Ciao, Michael.

Re: [Tinycc-devel] forward asm symbols vs static

Hi, On Sat, 25 Nov 2017, grischka wrote: .def is created automatically if an "export table" with at least one symbol (with __attribute__((dllexport))) is created for the dll or exe. This is done so for convenience and corresponds to msvc behavior which creates .exp and .lib files

Re: [Tinycc-devel] forward asm symbols vs static

Hi, On Sat, 25 Nov 2017, avih wrote: You can reproduce it with Linux too. This is with Ubuntu 16.04 but I'm pretty sure it's not mandatory: Let's start from scratch after cloning and cd into the tinycc dir: Thanks for the receipt, I could reproduce it and have fixed it in mob. (At the

[Tinycc-devel] Unify C and asm symbols (was: forward asm symbols vs static)

Hi, On Sat, 25 Nov 2017, Michael Matz wrote: Hmm, let's see ... I'm fairly sure to have the .def file problem fixed later today. The symtab unification I don't know yet, perhaps end of the weekend or next week. Both in mob now. I've tested 32bit and 64bit linux; some proper Windows

Re: [Tinycc-devel] forward asm symbols vs static

Hi, On Thu, 23 Nov 2017, grischka wrote: Different calling convention on win64. I'd suggest the attached version which is more platform neutral. Yup, that's better. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org

Re: [Tinycc-devel] forward asm symbols vs static

Hi, On Fri, 24 Nov 2017, avih wrote: I noticed a change at e7c71e24 ("tccasm: synch C and asm symtab tighter") which I'm not sure is expected. On Windows, when I build tcc using tcc with one source, a file "tcc.def" is created at the same dir as the resulting tcc.exe, with this content:

Re: [Tinycc-devel] forward asm symbols vs static

t > ./asm-c-connect.exe > make[1]: *** [Makefile:240: asm-c-connect-test] Segmentation fault > make[1]: Leaving directory '/bld/tests' > make: *** [Makefile:346: test] Error 2 > > > On Wednesday, November 22, 2017 7:11 PM, Michael Matz > &l

Re: [Tinycc-devel] forward asm symbols vs static

Hi, On Mon, 20 Nov 2017, Michael Matz wrote: > > naively I'd think that it probably should more closely emulate the gcc > > situation where inline asm ends up just as embedded snippets in its C -> > > asm output. Which could mean for example that "free_asm_labels&q

Re: [Tinycc-devel] Unify C and asm symbols

Hi, On Mon, 4 Dec 2017, grischka wrote: > Michael Matz wrote: > >> Here 'x5' should have the g[lobal] binding from C. > > > > ... I have fixed this in mob with a one-liner instead :) > > Well, however this one line > > + if (esym && s->type.t =

Re: [Tinycc-devel] Unify C and asm symbols

Hi, On Mon, 4 Dec 2017, Michael Matz wrote: > Oh, shiny! :) I like it. It also works on my linux kernel sources, and > some other things, so it's a definite improvement. I'd say, apply. Bleh, I wanted to ask one thing about the no_asmstack patch, the hunk: @@ -390,7 +388,7 @@ ST_FU

Re: [Tinycc-devel] Unify C and asm symbols

Hi, On Tue, 12 Dec 2017, grischka wrote: OK, I just pushed the (if it were me) final commit for 0.9.27, so we could say that it is now in BETA stage, at least. http://repo.or.cz/tinycc.git/commitdiff/d348a9a51d32cece842b7885d27a411436d7887b Also there is one more alternative approach for

Re: [Tinycc-devel] debug info broken

Hi, On Sun, 17 Dec 2017, foobar wrote: > Hi list, > > First of all, thanks for the release! > I've built 0.9.27 for x86_64 and tried a see if debugging works, but: > > $ cat true.c > int main() { return 0; } > > $ tcc true.c -g -o true Above works for me (with 0.9.27 release and others).

[Tinycc-devel] forward asm symbols vs static

Hello grischka, I had to revert a small part of your da8c62 commit ("various stuff"): tccasm.c: - keep forward asm labels static, otherwise they will endup in dynsym eventually. A symbol which stays undefined until the end is implicitely STB_GLOBAL, even without a .globl

Re: [Tinycc-devel] forward asm symbols vs static

Hi, On Thu, 16 Nov 2017, grischka wrote: > Except ... there was one text relocation which at first I could not > explain where it comes from but then with some objdumps I found it > was a relocation to the 'p3' label in libtcc1.a:alloca86_64.s which > defeated my efforts to get rid of DT_TEXTREL

Re: [Tinycc-devel] forward asm symbols vs static

Hi, On Sun, 19 Nov 2017, grischka wrote: > I admit that tccasm.c is one of the white areas on my tcc map, but > naively I'd think that it probably should more closely emulate the gcc > situation where inline asm ends up just as embedded snippets in its C -> > asm output. Which could mean for

Re: [Tinycc-devel] forward asm symbols vs static

Hi, On Sun, 19 Nov 2017, Michael Matz wrote: Aha! Indeed, p3 should be STB_LOCAL, and now (after my revert or before your patch) isn't anymore. Okay, I'll work on this. Need to find a way to get both things working, hmm :) Fixed in mob. Gnah, what a rats hole :-/ I found another failure

Re: [Tinycc-devel] version d0db21757afc625a6299aec51cbc282f36abb85f

Hi, On Sun, 19 Nov 2017, Somchai Smythe wrote: gcc -o tcctest.gcc tcctest.c -DCONFIG_TRIPLET="\"x86_64-linux-gnu\"" -DTCC_TARGET_X86_64 -fno-strict-aliasing -I.. -I.. -w -O0 -std=gnu99 -fno-omit-frame-pointer ./tcctest.gcc > test.ref ./tcctest.gcc: Symbol `getenv' causes overflow in

Re: [Tinycc-devel] forward asm symbols vs static

Hi, On Fri, 17 Nov 2017, Michael Matz wrote: Aha! Indeed, p3 should be STB_LOCAL, and now (after my revert or before your patch) isn't anymore. Okay, I'll work on this. Need to find a way to get both things working, hmm :) Fixed in mob. Btw. my current 0.9.27 release plan is to do

Re: [Tinycc-devel] Unify C and asm symbols

On Tue, 28 Nov 2017, grischka wrote: I like it. More lines removed than added could mean that it is going in the right direction anyway ;) Hehe :) Question: I wonder whether now we could maybe get rid of the asm label "post-processing" (asm_free_labels) and the asm_label stack

Re: [Tinycc-devel] inline assembly problem with cmovcl/cmovbl

Hi, On Sat, 2 Dec 2017, Somchai Smythe wrote: I realize there are other ways to get this cpuid information, but if I wanted to use cmovcl in some other code I think the inline assembler really is broken. I tried the synonym cmovbl, but it didn't work either. Both cmovc and cmovb are listed

Re: [Tinycc-devel] Unify C and asm symbols

Hi, On Sun, 10 Dec 2017, grischka wrote: May I suggest however to keep doing the asm-label undef->non-static conversion on the sym-stack (per file) level, because for one it is more obvious at what we're doing and why, and also because otherwise is is not correct for static C symbols, which

Re: [Tinycc-devel] Unify C and asm symbols

n just your two) are a clear progression (and all three together even source line number neutral! ;) ) What do you think? Ciao, Michael. commit c47d42823da2bb2908ce6a60452a24ba58b1b273 Author: Michael Matz <m...@suse.de> Date: Sun Dec 10 06:18:27 2017 +0100 Fix some multi

Re: [Tinycc-devel] Inconsistency gcc/tcc on visibility hidden

Hi, On Sun, 6 May 2018, ag wrote: tcc -o liba-tcc.so alib.c -g -O2 -shared -fPIC -fvisibility="hidden" TCC doesn't support the -fvisibility= option at all. By default it silently accepts all -f options, if you want a warning then do: % tcc ... -Wunsupported ... -fvisibility=hidden tcc:

Re: [Tinycc-devel] Found an issue when compiling raylib with TCC

Hello, On Mon, 28 May 2018, Ray wrote: Just found an issue when compiling with TCC, it seems that TCC is not casting some int values correctly to float when dividing, I mean: Which version of TCC? (mob branch or anything else?) Following code fails on calculating correct float

Re: [Tinycc-devel] Found an issue when compiling raylib with TCC

Hi again, On Thu, 31 May 2018, Michael Matz wrote: I can't find a test which reproduces a problem with current mob branch. FWIW, I tried your raylib on x86-64 linux with the mob branch of TCC. The problem doesn't reproduce for examples/textures_rectangle, also not when going back

Re: [Tinycc-devel] Small bug: Uncalled null function pointer literal makes code unlinkable

Hi, On Tue, 26 Jun 2018, Petr Skočík wrote: Hi. I came across this little bug. It's not a showstopper for me but I thought I'd report it in case somebody knows a quick fix. example:c.c: void y(void); #define x ((void(*)(void))0) void call_x() { x?x():y(); } compiling and attempted

Re: [Tinycc-devel] Overflows in the dynamic linker on x86_64 when using a tcc-built shared library along with others

Hi, On Thu, 28 Jun 2018, Petr Skocik wrote: Symbol `__dso_handle' causes overflow in R_X86_64_PC32 relocation Symbol `fstatat' causes overflow in R_X86_64_PC32 relocation Symbol `fstat' causes overflow in R_X86_64_PC32 relocation Symbol `mknod' causes overflow in R_X86_64_PC32 relocation

Re: [Tinycc-devel] Bug: "mov -0x10(%rbp), %eax", but source is 8-bit signed type

Hi, On Fri, 22 Jun 2018, Steffen Nurpmeso wrote: if(use_shexp){ 27d7: 8b 45 f0mov-0x10(%rbp),%eax That should be movsbl i think. Yes. The x86-64 port didn't correctly set the VT_LVAL_xxx bits for arguments. Fixed in mob. Ciao, Michael.

Re: [Tinycc-devel] codegen bug with tcc x86_64 ?

Hi, On Sun, 31 Dec 2017, foobar wrote: please find attached code that exposes a codegen bug in tcc, resulting in an endless loop in libtom's embedded bigmath code on x86_64 musl linux. (note: the code in main() under #if 0 exposes another problem, no endless loop, but wrong result) it

Re: [Tinycc-devel] Werror-implicit-function-declaration

Hi, On Thu, 28 Dec 2017, foobar wrote: $ cat test.c int t(int x) { return f(x)+1; } $ tcc test.c -c -Werror || echo error test.c:1: warning: implicit declaration of function 'f' error $ tcc test.c -c -Werror-implicit-function-declaration || echo error test.c:1: warning: implicit declaration

Re: [Tinycc-devel] C99 static array indices in function args

Hi, On Tue, 26 Dec 2017, Michael B. Smith wrote: No. Warnings are never required diagnostics (and even if, what specifically would you want to warn about in this case?). The only require diagnostics are from constraint violations. Most other undefined behaviours don't need to be diagnosed

Re: [Tinycc-devel] debug info broken

Hi, On Thu, 28 Dec 2017, grischka wrote: Ok, I was able to reproduce the original problem on an suse 10.2 from 2007. He :) It is that in debug mode, tcc includes all sections in the image, that is also reloc sections that already have been applied. Hah, finally a reason to fix this long

Re: [Tinycc-devel] C99 static array indices in function args

Hi, On Wed, 20 Dec 2017, Michael B. Smith wrote: It's in 6.7.5.3/7 in C99 for 'static'. It's in 6.7.3/5 in C99 for 'const'. Using 'static' seems to have two implied contracts: [1] don't allow NULL parameters [2] verify, when possible, that the passed array has AT LEAST the number of

Re: [Tinycc-devel] TCC version 0.9.27 is out

Hi, On Mon, 18 Dec 2017, Michael B. Smith wrote: [1] Other than _Complex/_Imaginary (which C11 now identifies as "optional") does anyone have a clear view of what is missing to be c99 compliant? (I've read the standard and I can build a basic test suite, but I just wondered if someone

Re: [Tinycc-devel] "error: undefined symbol main" with -pthread on linux

Hi, On Sat, 23 Dec 2017, avih wrote: I think maybe, instead of saying and doing: -pthread   same as -D_REENTRANT and -lpthread It should say and do something along these lines: -pthread   same as -D_REENTRANT while compiling and -lpthread while linking I decided to keep the help message as

Re: [Tinycc-devel] NAN and INFINITY break in different ways

Hi, On Sat, 23 Dec 2017, avih wrote: Alpine: $ tcc test.c testinfs.c:2: error: division by zero in constant $ tcc test.c -E ... static const double infs[] = { (0.0f/0.0f), 1e5000f }; ... So clearly tcc doesn't like musl's fallback definition (if not gcc) for NAN in a constant, but tcc is

Re: [Tinycc-devel] NAN and INFINITY break in different ways

Hi, On Sun, 24 Dec 2017, Vincent Lefevre wrote: I think we could make an exception for 0.0/0.0 and always fold this into NaN (normally division by zero is indeed not allowable in constant expressions in c99). AFAIK, the standard just implies that 0.0/0.0 is not specified as a constant

Re: [Tinycc-devel] [PATCH] tcc: remove buggy nodata_wanted optimization

Hi, On Thu, 22 Feb 2018, grischka wrote: However NODATA_WANTED does more than that, for example it also suppresses the "hello" with if (0) puts("hello"); Therefor I'd suggest a less radical change, such as: @@ -6916,7 +6916,7 @@ static void decl_initializer_alloc(CType *type,

Re: [Tinycc-devel] Get addr2line working with TinyCC

Hi, On Sat, 24 Feb 2018, Yakov wrote: I cannot addr2line get working with tcc, here is what I am trying: --- $ tcc -o exec main.c -lm -g -rdynamic $ ./exec exec(show_trace+0x24) [0x407690] exec(obj_ctx_find+0xeb) [0x413733] exec(dic_forEach+0xe9) [0x40758e]

Re: [Tinycc-devel] [PATCH] tcc: remove buggy nodata_wanted optimization

Hi, On Thu, 22 Feb 2018, Mikulas Patocka wrote: > I think that that nodata_wanted misoptimization should be removed at all > - in the C language, you can jump to any location in the function with > goto or switch-case statement - thus reasoning such as "all the > variables behind if (0) are

Re: [Tinycc-devel] Mis-parse in some situations involving a function pointer with attributes (breaks SQLite build)

Hello, On Sun, 22 Jul 2018, Jonathan Newman wrote: Hi;I happened across this issue while trying to build SQLite. I've attached a test case. To summarise: * Start off with a function pointer, correctly assigned to a function that has attributes, but cast to a void* (or indeed anything except

Re: [Tinycc-devel] Small tcc bugs brought to you by american fuzzy lop

H, On Mon, 30 Jul 2018, John Scott wrote: I fuzzed tcc for several hours and found some issues. I'm not familiar with tcc's code and can't be of much help in resolving these, but they do affect both 0.9.27 and the latest Git version, so I hope to bring awareness to these bugs. Well, in

Re: [Tinycc-devel] preprocessor makes attributes disappear

Hi, On Fri, 6 Apr 2018, ra...@airmail.cc wrote: I tried modifying my test program to use __attribute instead, in that case the code line 3345: case TOK_ALIGNED2: is being executed which is good. but again the output is not zeros. Perhaps a.aligned is being ignored for functions during

Re: [Tinycc-devel] preprocessor makes attributes disappear

Hi, On Thu, 5 Apr 2018, ra...@airmail.cc wrote: I made this test program which I expect to print all 0's, but it doesn't. I noticed that after tcc -E the attributes have all disappeared. Any idea what is stopping this from working? the attribute is documented and code gen seems to respect

Re: [Tinycc-devel] The built-in memory and bounds checker cannot handle mmap'd memory and judges errno wrong

Hi, On Fri, 6 Apr 2018, George Gaarder wrote: I just tried -b to see whether I forgot to free something, and I found that the memory and bounds checker will alert when I use the memory I mmap'd. Whi le I was writing a demo for report, I found that the checker also reported o ut of region when

Re: [Tinycc-devel] preprocessor makes attributes disappear

Hi, On Sat, 7 Apr 2018, ra...@airmail.cc wrote: Thank you very much! Where may I find this patch? It has yet not shown up on http://repo.or.cz/tinycc.git/tree Ahem. I forgot to push the changes, they are there now. Ciao, Michael. ___

Re: [Tinycc-devel] Integer promotion issue?

Hi, On Sat, 31 Mar 2018, Patrick Pelissier wrote: when compiled with TCC GIT c41caac02d53373b296ccb179b730ada62137cc0 produces the result on an linux/x86-64 platform: N=9223372036854775810 whereas I was expecting N=2 Indeed. Thanks for the report. Fixed in mob (f0a25ca). Ciao,

Re: [Tinycc-devel] Some patches

Hi, On Sat, 31 Mar 2018, Petr Skocik wrote: The first takes symlinks into account with header file caching (I need it with my build setup which uses a symlink in a weird way -- gcc and clang don't have problems with it but tcc did). Can you clarify what the problem is exactly? Thing is:

Re: [Tinycc-devel] TCC segfault on Fedora 29

Hi, On Sat, 3 Nov 2018, Christian Jullien wrote: BTW, I already reported this BUG in the past: http://lists.nongnu.org/archive/html/tinycc-devel/2017-10/msg00033.html I fixed this but that doesn't help the original bug report. It's something specific to Fedora 29' /usr/lib64/crt1.o, so

Re: [Tinycc-devel] Fixes to bugs in `type_to_str` and `compare_types`; patches to CLI options

Hello, On Mon, 12 Nov 2018, Petr Skočík wrote: > My shot at the fixes is at https://github.com/pskocik/tinycc. It's > separated into addition of failing tests and fixes to those tests. The fixes seem sensible, but I have some stylistic nits: * please add testcases and fixes for them in the

Re: [Tinycc-devel] Function pointers declared in a particular way result in a miscompilation

Hello, On Sat, 29 Dec 2018, Jonathan Newman wrote: Hi,This seems to be the issue causing SQLite compilation to fail (or at least part of it/related to it). When a function pointer is declared in a particular way, it seems that __stdcall (and presumably other attributes?) are ignored. As a

Re: [Tinycc-devel] Add gcc cleanup attribute support

Hi, On Wed, 2 Jan 2019, uso ewin wrote: I've try to add support to cleanup attribute to TCC: https://github.com/cosmo-ray/tcc/tree/cleanup Are you interested in having this feature merge in mob ? If yes it would be nice if someone could review my code As you found out the one-pass nature of

Re: [Tinycc-devel] TCC-0.9.27 Static linking with uClibc-0.9.30 workabout

Hi, On Sat, 5 Jan 2019, Kurt Nalty wrote: For the specific environment of uClibc-0.9.30, to enable static linking, I reverted the ELF_START_ADDR to 0x08048000 and ELF_PAGE_SIZE to 0x1000, as was done in TCC-0.9.26, and found success. However, this fix does not work for the musl libraries,

Re: [Tinycc-devel] Add max_align_t to stddef.h and C11

Hi, On Sun, 13 Jan 2019, Christian Jullien wrote: > I don't agree with you for c11 flag. > I participate to C++ standardization committee (which includes links to C). > We really take care of visible names and available features. That's why C > now includes more and more __STDC_xxx to detect

Re: [Tinycc-devel] Segfault with .skip

Hi, On Fri, 18 Jan 2019, Giovanni Mascellani wrote: > while trying to compile some Linux kernel code, I found that tcc crashes > when given the following .s file: > > > .skip 2f-1f,0x90 > 1: > 2: > > > It works correctly with backward

Re: [Tinycc-devel] TinyCC for bootstrapping (with patches)

Hi, On Sun, 13 Jan 2019, Giovanni Mascellani wrote: > 2) I patched TinyCC so that it can be built by a compiler that does not > support floating point numbers (as is the case for the C compiler in > asmc that builds TinyCC). Basically I import in the TinyCC repository > the code from the

Re: [Tinycc-devel] Missing C99 standard headers in win32

Hi, On Sun, 13 Jan 2019, Christian Jullien wrote: > ISO/IEC 9899 :1999 (E) specifies that (Section 7.1.2 p. 165), Standard > headers are: > > Those already in win32 lack > > complex (and imaginary) support > restricted character set support via digraphs > type-generic math macros > >

Re: [Tinycc-devel] not an issue, surely a mistake

Hi, On Sat, 24 Nov 2018, ian wrote: None of my habits, but I'd like an advice. I didn't code in C for many many years. But... I did a few years ago correctly install tcc on my windows 7, but unfortunately it went down (winscrap), and I only have my debian 8 x32 other PC (kinda server for

Re: [Tinycc-devel] x86_64, musl: generation of mixed C/C++ fails: undefined reference to `__va_start'

Hello, On Thu, 3 Jan 2019, Steffen Nurpmeso wrote: Regardless of whether i use the AlpineLinux default tcc package, or my version with the little path-resistancy patch, i cannot create a binary from several C files which become compiled with tcc -static and linked to an -ar chive, and some C++

Re: [Tinycc-devel] Add gcc cleanup attribute support

Hi, On Thu, 3 Jan 2019, uso ewin wrote: * your way of dealing with the "goto forward" problem is to read and remember all tokens after the goto until you find the label (and if so do the cleanups), rereading all these tokens afterwards. This feels ugly and against the one-pass nature

Re: [Tinycc-devel] Add max_align_t to stddef.h and C11

Hi, On Fri, 11 Jan 2019, Petr Skočík wrote: Having __STDC_VERSION__ reflect the -std= command option is great. However, I think that disallowing _Generic and _Alignof at lower versions is unnecessarily pedantic (as in a behavior more suitable for compiler runs invoked with `-pedantic`). Unlike

Re: [Tinycc-devel] x86_64 static link fix

Hi, On Wed, 9 Jan 2019, Kurt Nalty wrote: After firing up gdb, and tracing through a few combinations of static and dynamically linked object files, I have determined that the segfaults were due to usage of procedure linking tables (.plt) with the statically linked process. The plt addresses

Re: [Tinycc-devel] Implementing .macro gas syntax

Hi, On Sat, 26 Jan 2019, Giovanni Mascellani wrote: as part of my bootstrapping project that I have already mentioned a few emails ago, I would like to be able to compile Linux with tcc, trying to patch Linux as little as possible. Btw, I still owe you an answer. I've finally pushed my

Re: [Tinycc-devel] tcc fails UBSan and ASan

Hi, On Sat, 26 Jan 2019, Giovanni Mascellani wrote: This already prints lots of errors when tcc compiles libtcc1.a, mostly about unaligned struct access. An example: tcctools.c:189:21: runtime error: member access within misaligned address 0x564f628c4d3c for type 'struct Elf64_Shdr', which

Re: [Tinycc-devel] Implementing .macro gas syntax

Hi, On Sun, 27 Jan 2019, Giovanni Mascellani wrote: 16bit code gen, and certain other assembler constructs are still missing as well (e.g. the easier .incbin), but yes, .macro is a large part of what's still missing. For my project I might be in a slightly easier situation: I already have

Re: [Tinycc-devel] TCC segfault on Fedora 29

b backtrace look like for the coredump (to make that easier, build tcc with '-O0 -g', not the default -O2, i.e. change CFLAGS in config.mak). Ciao, Michael. > > -Original Message- > From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] > On Behalf O

Re: [Tinycc-devel] TCC segfault on Fedora 29

Hi, On Fri, 1 Mar 2019, Klaus Ebbe Grue wrote: > Is there news on the Fedora 29 segfault problem? No, as nobody provided the breaking crt*.o files ... > > some time. Alternatively: somebody can send me their /usr/lib64/crt*.o > > files from a system where the segfault reproduces. It's some

Re: [Tinycc-devel] Undefined symbol '__ashldi3'

lways compile libtcc1 with TCC itself (except if using a non-default explicit make target), so this should be specific to the old TCC version used by tcc4tcl. Cute hack^Wwork-around with objcopy :) Ciao, Michael. > > See also: http://wiki.tcl.tk/tcc4tcl > > On Wed, Mar 13, 2019, 08:

Re: [Tinycc-devel] TCC crash with incorrect syntax in compound literal

Hello, On Sun, 17 Mar 2019, Pascal Cuoq wrote: The attached patch makes the program above rejected without crash, does not seem to break “make test” (I think I know what it looks like when the tests are broken because my first fix did break them), and it makes the following program accepted

Re: [Tinycc-devel] Undefined symbol '__ashldi3'

instead. > > > > > > > > I tried hard to use gdb to debug dynamic loading, but it's proving to be a > > nightmare in Windows. gdb is not showing me my arguments, it's claiming all > > functions are defined in some unrelated C++ header file, and I had to find >

Re: [Tinycc-devel] TCC segfault on Fedora 29 Klaus Ebbe Grue

Hello, On Mon, 4 Mar 2019, Connor Nolan wrote: > It seems to be fixed now, but when running the created executable it > errors: "./test": error: Android 5.0 and later only support > position-independent executables (-fPIE). Does tinycc not support PIE, Right now TCC can't create position

Re: [Tinycc-devel] Undefined symbol '__ashldi3'

Hi, On Fri, 8 Mar 2019, Andy Goth wrote: > On Fri, Mar 8, 2019, 00:46 Andy Goth wrote: > > > With tcc4tcl 0.30 (tcc 0.9.26) compiled with MXE GCC 5.4.0, I get the > > following error: > > > > I left out a critical detail. This is 32-bit Windows MXE GCC. I haven't > tried 64-bit Windows yet,

Re: [Tinycc-devel] Use of uninitalized automatic variable in TCC when parsing “int f ( int ( )”

Hello Pascal, On Fri, 8 Mar 2019, Pascal Cuoq wrote: > the simplest way to make this problem visible is to instrument the > functions type_decl and post_type: Thanks for the report, fixed in mob. Ciao, Michael. > > diff --git a/tccgen.c b/tccgen.c > index 87ec798..7fa6c72 100644 > ---

Re: [Tinycc-devel] Compiling to Bare Metal and to Unusual Targets ?

Hi, On Mon, 11 Mar 2019, Patrick wrote: > I have a couple of experiments I want to run. I would like to compile a self > hosted executable to run on a BeagleBone or Raspberry Pi without an OS. > > I built with --enable-cross so I have a Linux to Arm tcc compiler installed. > > Could I confirm, 

<    1   2   3   4   5   6   >