Re: [Tinycc-devel] some symbole are defined twice when we call tcc_relocate twice

that. In principle it could be enabled, but there are some complications. For example symbols need to be converted to SHN_ABS, old code needs to be deleted, ... -- grischka tcc give me these errors: tcc: error: '_etext' defined twice tcc: error: '_edata' defined twice tcc: error: '__preinit_array_start

Re: [Tinycc-devel] x86_64 or x86-64

Christian JULLIEN wrote: Since we are very close to 0.9.27 I don't want to push changes that may break the release, Enclosed are the diffs to use only x86_64 (and no more x86-64). I let you decide to apply them or not Christian That would be economically extremely unpractical (you know

[Tinycc-devel] tccasm mov instruction

you look at this? Thanks, --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] x86_64 or x86-64

) De:"grischka" gris...@gmx.de À:"tinycc-devel@nongnu.org" tinycc-devel@nongnu.org Objet:Re: [Tinycc-devel] x86_64 or x86-64 Christian JULLIEN wrote: Since we are very close to 0.9.27 I don't want to push changes that may break the release, Enclosed are the diff

Re: [Tinycc-devel] x86_64 or x86-64

Christian JULLIEN wrote: 64bit Intel processor is used inconsistantly in different Makefile and configiration script. IMHO we should use only x86_64 everywhere which is a valid C identifier. Scripts are more complicated to write. Among others: Makefile:else ifeq ($(ARCH),x86-64)grep:

Re: [Tinycc-devel] Add support for Unicode entries 'wmain' and 'wWinMain' on Windows

commitdiff/096125d963400951e0f160ced86416ef8c9c98b0 Also, tiny_xxx tools are now integrated: http://repo.or.cz/tinycc.git/commitdiff/2d3b9559bf569f137cefb7f8386a0dc58e33c81f Also, new help screen for the advanced options: tcc -hh -- gr On Thursday, February 16, 2017 10:35 PM, grischka <gris...@gmx.de> wr

Re: [Tinycc-devel] --enable-cross and libtcc1.a

Ok, I added compilation of more libtcc1-xxx.a targets and a pseudo (hex-code) assembler for arm also. It's now even possible to configure really working cross-compilers. Ic you know how ;) -- gr avih wrote: 1. Immediate issue:On windows, when building using a native 64 bit compiler, e.g.

Re: [Tinycc-devel] Makefile added to build native tcc on Windows

Christian Jullien wrote: It looks many of you have troubles to build tcc 32/64 on Windows. There is a .bat that mostly does the job but not totally. Hi Christian, Hm, "mostly but not totally"? I can't help but I actually wonder what that could mean. ;) --- grischka Hop

Re: [Tinycc-devel] Fw: Ready for Release 0.9.27

avih wrote: > On the downside as a developer you need to delete the .expect file > manually if you want it to be rebuilt. I don't recall that to be the case. Do correct me if I'm wrong, but at least with out of tree builds, running "configure && make && make test" - does generate the expect

Re: [Tinycc-devel] Ready for Release 0.9.27

Christian Jullien wrote: *- Linux CentOS 6.x [KO]* ../tcc -B.. -I../include -I.. -I.. -DCONFIG_LDDIR="\"lib64\"" -DTCC_TARGET_X86_64 ../tcc.c libtcc2 -lm -ldl -Wl,-rpath=. -o tcc2 libtcc2:0: error: unrecognized character \x7f Strange, should be libtcc2.so Seems DLLEXT=.so was not set from

Re: [Tinycc-devel] Ready for Release 0.9.27

avih wrote: (I might be sending this exact same message again. Not sure if my first attempt got sent correctly) grischka, why does commit 5efa75d9 revert commit 9b3e4c58 ? (using gcc instead of $(CC) at the tests). This breaks self-hosting when gcc is not available. If gcc is available

Re: [Tinycc-devel] Ready for Release 0.9.27

Christian Jullien wrote: Hi Grischka, The culprit commit is "2016-12-20 grischka tests: OOT build fixes etc." Sorry Grischka :o) This is the first commit after which " Segmentation fault' appears. More specifically, the issue is with lib/Makefile, if I revert only this f

Re: [Tinycc-devel] Ready for Release 0.9.27

peoples' patches, this one looks a bit different but it does the same thing. --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] VS2015 / was Ready for Release 0.9.27

u get -m32/64 with it for free, too. --- grischka cheers, ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] VS2015 / was Ready for Release 0.9.27

Vladimir Vissoultchev wrote: The other main option is to scap the folder altogether and it will probably be the better decision. This way "entry to participation" in mob will be to at least install gcc on Windows :-)) Never mind, I did that. build-tcc.bat got an addition though to support

Re: [Tinycc-devel] Ready for Release 0.9.27

n fault I think we first need to find the cause of these crashes on ARM with -run. Can you investigate that, eventually ? Thanks, -- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ready for Release 0.9.27

f ((t1 & (VT_BTYPE | VT_UNSIGNED | VT_BITFIELD)) == Note that VT_BITFIELD set implies bit-field width < original type width. --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Fw: Ready for Release 0.9.27

ents-the-wrong-way/ Yep, but I really don't want to go that far for now. After all we still want to use spawnvp and not a total replacement with CreateProcess that ends up bigger than entire tcc.c. cheers, --- grischka cheers, ___ Tinycc-d

Re: [Tinycc-devel] Ready for Release 0.9.27

' field-width is supposed to define its own integral C type. --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Add support for Unicode entries 'wmain' and 'wWinMain' on Windows

YX Hao wrote: Dear grischka and group, Unicode entry support for windows platform is useful. Especially when developing programs which relays on the Unicode version APIs and takes Unicode arguments, it will help. Here is my patch for this feature. I have used it for about 1 year. It has

Re: [Tinycc-devel] Ready for Release 0.9.27

fi @diff -Nbu $(SRC)/$*.expect $*.output && rm -f $*.output $*.exe Any clue? I've no clue either. I would try to remove any @, 2>&1, $(FILTER), and rm ... and then run $ make -C tests/tests2 42_function_pointer.test and see what happens... --- grischka -

Re: [Tinycc-devel] Fw: Ready for Release 0.9.27

Vladimir Vissoultchev wrote: Basicly yes, it's only useful for someone who does not have gcc installed on Windows but is using MS toolchain. Let me try something as a last resort. I want to enhanced current build-tcc.bat with more parameters to 1. be able to produce config.h (for pre-build

Re: [Tinycc-devel] What is the exact Darwin port status? (i.e. macOS)

will not work on windows or arm or darwin. --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] What is the exact Darwin port status? (i.e. macOS)

inux. A Darwin -> Linux cross compiler if you want to. See 'make help' for how to configure cross compilers. --- grischka byas:tinycc jullien$ cat foo.c #include int main() { printf("Hello World\n"); } Compile only wit -c byas:tinycc jullien$ ./tcc -c foo.c In file included from

Re: [Tinycc-devel] Heap memory on windows

Anaël Seghezzi wrote: Is this correct ? : tcc_set_options(s, "-Wl,--stack=4194309"); Only if you're using libtcc to output to an executable file (with tcc_output_file). On the other hand, code run from memory will simply use the stack of your application continuously. -- gr On mer

Re: [Tinycc-devel] One of Grischka's recent cleanup break install - at least on ARM

_EABI) && !defined(TCC_ARM_VFP) #error "Currently TinyCC only supports float computation with VFP instructions" #endif Greetings, --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] cleanups

Carlos Montiers wrote: Why in win32/lib/crt1.c the code for check success of __getmainargs was removed? I think is important check the return of that function before call to main. There is no need to check if we assume that it cannot fail. Machines are all based on assumptions, not, say,

Re: [Tinycc-devel] cleanups (Incorrect function call code on ARMv6)

Daniel Glöckner wrote: On Mon, Oct 03, 2016 at 12:48:00PM +0200, grischka wrote: Ok, have seen it: crash in "make test". So it's long long *p, v; p = p[0]++; that is miscompiled without the save_regs. To load the upper half of p[0] 4 is added to th

Re: [Tinycc-devel] Tidying TCC's external API

Jean-Claude Beaudoin wrote: On Mon, Sep 26, 2016 at 1:04 AM, Christian Jullien wrote: In order to build tcc.c on Windows, I reverted pstrcpy back to a PUB_FUN. Hope it’s also Ok for you. I gather that this is for the case where ONE_SOURCE is "not" set, and under a

Re: [Tinycc-devel] partial cygwin support for mob

Chris Marshall wrote: Attached is a patch to the current mob which allows cygwin to be correctly recognized and tcc to be built. Unfortunately, the rest of the work is fixing the system includes for cygwin which I haven't been able to figure out. I request that this commit be reviewed and

[Tinycc-devel] asmtest problem

4d c8mov-0x38(%rbp),%ecx <-- bit number Here it shoud not use the '67' prefix 43: 67 0f ab 08 addr32 bts %ecx,(%eax) Please help, --- grischka ./tcc -B. -g -c test.c && objdump -S test.o test.o: file format elf64-x86-64 Disassembly of sectio

Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup"

nfusing. FYI: on my (old 8.10 from 2008) ubuntu 64, there is /usr/lib64, but it is a link to /usr/lib. There is also /usr/lib/x86_64-linux-gnu, but it is empty. I was under the impression that lib64 was an old misguided concept from the early 64 bit days. Maybe I was wrong.

Re: [Tinycc-devel] Crash report for [mob:3054a76]

Steffen Nurpmeso wrote: tccgen.c:6549:22: error: ‘tokstr_alloc’ undeclared (first use in this function) tal_free(tokstr_alloc, fn->func_str); Thanks, fixed. Reminds me to never push the same day. -- grischka Ciao (for today). --stef

Re: [Tinycc-devel] Status for 0.9.27

l, forever. For Apple it lacks a MACHO backend. So that is pretty much the same as you already noticed. At least we can say that it does more than last release. --- grischka For example, who knows the status of FreeBSD on Aarch64? It is generally admitted that tcc 'globally' works well on Linux a

Re: [Tinycc-devel] Linux port is broken with multi-arch

Please try again. -- gr Christian JULLIEN wrote: This is the first commit that breaks on multi-arch: configure: --triplet= option, Makefile: cleanup authorgrischka grischka Mon, 17 Oct 2016 23:22:21 +0200 (17 23:22 +0200) committergrischka grischka Mon, 17 Oct 2016 23:24:10 +0200 (17 23

Re: [Tinycc-devel] Problem with libtcc DLL + MEMORY output

Amaury Bouchard wrote: Hi all, So, nobody here ever tried to use TinyCC library to compile some code, then generate a .so/.dll file, then execute this code? Why would anyone want to do that? Just in case, there is a comment for tcc_set_output_type()" in both libtcc.h and the libtcc_test

Re: [Tinycc-devel] Crash report for [mob:3054a76]

Steffen Nurpmeso wrote: Yes it is, there is a double free in conjunction with the preprocessor end_macro() (imagine a smile here). end_macro() frees the macro and then that free_inline_functions or so tries to frees it again, which causes a crash. I think this was possible when you get a

Re: [Tinycc-devel] asmtest problem

Michael Matz wrote: Hello grischka, On Wed, 19 Oct 2016, grischka wrote: There seems to be a asm problem in tcctest.c with the bts instruction on x86-64, which crashes it under circumstances. __asm__("bts %1,%0" : "=m"(*pset) : "Ir"(_sig - 1) : "

Re: [Tinycc-devel] x86_64-win32-tcc.exe built with tcc (32) crashes. Works if built with gcc (32)

R s->data and long long r_offset which, for 32bit targets, didn't work well at all. --- grischka avih wrote: TL;DR:-- When using native tcc (32) to build tcc cross compilers, the resulting tcc cross compiler to windows x86_64 crashes when trying to create an executable. However, if using gcc (

Re: [Tinycc-devel] cleanups

elated). In general, often when I see people adding tests I think: "Well you just fixed that, what's the point? I'd rather see what's still broken." --- grischka Ciao, Michael. PS: and thanks for the additions to tcctest :) ___ Tinycc-d

Re: [Tinycc-devel] PATCH: Use R_AARCH64_MOVW_UABS_G* instead of R_AARCH64_CALL26.

Edmund Grimley Evans wrote: This is a work-around for TCC's linker not building a PLT when TCC is invoked with "-run". Hm, are you sure? See 9750d0b725d65296364c08451a985c717bf1890d Author: Michael Matz ... 2014-04-06 00:30:22 x86_64: Create proper PLT and GOT also for -run

Re: [Tinycc-devel] [FreeBSD support] __aligned(n) + __pure issues

Christian Jullien wrote: int sc_fpstate[128] __aligned(16); aligned is an attribute (also in gcc. You need #define __aligned(n) __attribute__((aligned(n))) Should be in the headers but often it is only for __GNUC__. pure also is an attribute, for optimization purposes and

Re: [Tinycc-devel] [FreeBSD support] __aligned(n) + __pure issues

(usually) commit other peoples' patches the less ones that I can't test ;) -- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] cleanups

s to make everything compatible with tcc) such that we could replace them with newer versions easily, eventually. I don't know whether this still make sense. Another though is that we could upload a more complete header pack as a separate download on savannah (provided that someone is willing to creat

Re: [Tinycc-devel] [FreeBSD support] __aligned(n) + __pure issues

Christian JULLIEN wrote: tcc: error: file 'crt1.o' not found Can you look where your file is? $ find /usr/lib -name crt1.o -- gr ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] [FreeBSD support] __aligned(n) + __pure issues

Christian Jullien wrote: Ok, The point is that it compiles ROOTB but then a single line program using only ISO include and std C library fails because of __aligned in a **system** header. I agree that __aligned is a probably a macro or a gcc FreeBSD specific extension, but no one wants to

Re: [Tinycc-devel] '__builtin_frame_address' warning about suspicious use of this call

ibrary which you get by commenting out the lines XCC = $(CC) near the top of lib/Makefile for i386/x86_84. Feel free to make such change to mob, if it works. Thanks, --- grischka Two questions here: Q1. Should we really call this function with one arg? Q2. If safe, we should make

Re: [Tinycc-devel] Largish mob update from me

ee the below working under all tests and everything except fire in the computer: ST_FUNC void g(int c) { int ind1; if (nocode_wanted) tcc_error("internal: code generated but nocode_wanted"); ind1 = i

Re: [Tinycc-devel] PATCH to fix arm64 regression caused by 6245db9

Edmund Grimley Evans wrote: 6245db9fca4046e568da41c6a1f8c51ee9e2f56c broke TCC on arm64. This patch seems to fix it again. Since it also affects x86_64, could someone else please take a look? Yes, makes sense. I'd suggest to #ifdef out the lexpand() function per se also, for these targets.

Re: [Tinycc-devel] Huge swings in cache performance

You might try larger "section alignment" for -run: in tccrun.c:208 instead of offset = (offset + 15) & ~15; for example offset = (offset + 63) & ~63; This would add more space between your "foo" data variable and the instructions in memory --- grisc

Re: [Tinycc-devel] Huge swings in cache performance

ures with benchmarks that might suggest different alignments for those? Thanks, --grischka Thanks! David ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Largish mob update from me

nderlying "TAL" manager. Sorry if I didn't fix it it was just to watch my new memtest at work ;) Vlad Vissoultchev's T(iny) AL(locater): http://repo.or.cz/tinycc.git/commitdiff/cdc16d428f32294 If someone wants to try the difference, commen

Re: [Tinycc-devel] Largish mob update from me

find out I needed a machinery that works ;) Details here: http://repo.or.cz/tinycc.git/commitdiff/f843cadb6bc07b3b3de6786233df4592d2d5f60d There aren't any if's with (nocode_wanted) in tccgen.c anywhere anymore, exept the 3 mentioned in the patch, and it I'll be happy if

Re: [Tinycc-devel] Various broken tests

thanks for testing. Please try again. -- grischka avih wrote: The memleak issue ("4. memtest failure when building using newly built tcc (32)" ) seems fixed with latest commit ( 4beb469 Fix pseudo leak ). I was testing previously while 2 commits behind. The three other iss

Re: [Tinycc-devel] Odd problem when using variables defined in header files for a .dll

(which in fact doesn't require any changes to pdcurses or TCC): tcc -I. pdcurses/*.c win32/*.c -ladvapi32 -luser32 -run demos/firework.c (pdcurses from: https://github.com/Bill-Gray/PDCurses/archive/master.zip) --- grischka Regards, Hales William Hales wrote: Hello, I have been having a p

Re: [Tinycc-devel] Libtcc and relative include paths

Joel Bodenmann wrote: Hello folks, I'm currently using libtcc inside a C++ application to compile, link and execute generated code. The generated code uses some smaller C library that gets compiled as part of the generated code (so basically C files which are being fed into libtcc Therefore,

Re: [Tinycc-devel] Odd problem when using variables defined in header files for a .dll

William Hales wrote: Hello, I have been having a problem with tcc when linking my project against a dll. The dll and my project share variables through a header file. This works fine with gcc, but when compiled with tcc my program and the dll end up with completely unique copies of the

Re: [Tinycc-devel] _Generic or __builtin_choose_expr

uso ewin wrote: I'm sorry but I don't have any arm machine, does someone have an idea how to fix, or debug this ? ARM defines CHAR_IS_UNSIGNED which sets tcc_state->char_is_unsigned. You can use "tcc -funsigned-char ... " to get the same on other platforms. -- gr I guess parse_btype or

Re: [Tinycc-devel] _Generic or __builtin_choose_expr

grischka wrote: uso ewin wrote: I'm sorry but I don't have any arm machine, does someone have an idea how to fix, or debug this ? ARM defines CHAR_IS_UNSIGNED which sets tcc_state->char_is_unsigned. Fixed in http://repo.or.cz/tinycc.git/commitdiff/9f79b62e here: @@ -4381,6 +438

Re: [Tinycc-devel] Please, please at least notify the list when you make big changes

David Mertens wrote: Case in point: I just tried to merge grischka's latest commit, described as "tccgen: nodata_wanted fix, default ONE_SOURCE, etc...". I have no idea why, but with the commit grischka decided to move a whole bunch of functionality out of libtcc.c's t

Re: [Tinycc-devel] build-tcc.bat is broken since recent changes

Christian JULLIEN wrote: Hi Grischka, Please read carefully! Hi Christian, please read carefully: from build-tcc.bat: @rem -- @rem batch file to build tcc using mingw, msvc or tcc itself @rem

Re: [Tinycc-devel] Many new errors on RPi because of ssize_t incompatible redefinition

Christian JULLIEN wrote: ‍One step forward, two steps backward, I don't know who is the culprit but today's update totally fails on RPi because of incompatible redefinition of 'ssize_t' In fact that is (partially) because of one of your own commits:

Re: [Tinycc-devel] Many new errors on RPi because of ssize_t incompatible redefinition

uso ewin wrote: I guess ptrdiff_t should indeed be a long int, but ssize_t should be an int, same for intptr_t and uintptr_t should be an unsigned int. gcc 6.3.0 on win32 (32bits): test.c:9:14: error: '_Generic' selector of type 'int' is not compatible with any association

[Tinycc-devel] too simple VT_LONG parsing

long long long lll = 0; gcc: test.c:9:15: error: 'long long long' is too long for GCC long long long lll = 0; ^~~~ tcc: -- gr ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org

Re: [Tinycc-devel] many test errors on RPi (incl. core dump) after recent changes

(int:0) in the struct. Just another detail anyway. As to static int counter; Michael, what can I do to convince you that static locals are most likely always not a good idea in (lib)tcc ;) --- grischka ___ Tinycc-devel mailing list Tinycc-devel

Re: [Tinycc-devel] build-tcc.bat is broken since recent changes

.\config.h #define CONFIG_TCCDIR "%CD:\=/%"* echo>> ..\config.h #ifdef TCC_TARGET_X86_64 *Le : *24 juillet 2017 à 18:39 (GMT +02:00) *De : *"grischka" <gris...@gmx.de> *À : *"Christian JULLIEN" <eli...@orange.fr>, "tinycc-devel@no

Re: [Tinycc-devel] build-tcc.bat is broken since recent changes

Christian JULLIEN wrote: Grischka‍ Trying to synchronize Cygwin Makefile with your recent reorg, 'make' stops because includes are now not found. There is a change to the default CONFIG_TCCDIR. You can define it in the config.h that you create or use tcc -B. ... The same issue exists with

Re: [Tinycc-devel] _Generic or __builtin_choose_expr

uso ewin wrote: Hi I've just push a lot of fixes on mob. Now long should be handle corretly. I'd suggest to remove this 'inside_generic' hack. tcc defines "__LP64__" (long/ptr=64) that you can use in stddef.h. Also you should make more tests. You have created bugs that were not present

Re: [Tinycc-devel] _Generic or __builtin_choose_expr

4x6 $ gcc -Wwrite-strings ... error: assignment of read-only location 'cc[1]' (mingw gcc 3.4.2 and 6.3.0) Also, now tcc doesn't warn with this one anymore: const char cc[] = "456"; char *p = cc; --- grischka ___ Tinycc-devel ma

Re: [Tinycc-devel] Bug: segfault when running empty file on tcc-0.9.26-win64

André Willik Valenti wrote: It happened using binaries from http://download.savannah.gnu.org/releases/tinycc/. 0,9,26 is rather old. You might want to try the 'mob' branch from http://repo.or.cz/w/tinycc.git which we'll use for next release -- hopefully soon ;) -- gr Tried also via libtcc

Re: [Tinycc-devel] Bug: segfault when running empty file on tcc-0.9.26-win64

André Willik Valenti wrote: Ok, thank you for the tip. I tried building it on Windows, but it apparently needs gcc. Is that so? You can use build-tcc.bat with gcc, msvc or tcc itself. Type $ build-tcc.bat ? to get some info. For example if you have the 0.9.26 tcc binaries in win32\0926:

Re: [Tinycc-devel] Bug: segfault when running empty file on tcc-0.9.26-win64

André Willik Valenti wrote: Didn't work for me. Indeed, the 0926 64bit tcc seems to have more than "some problems". However I found that using the 32bit version works well. With the tcc-0.9.26-win32-bin.zip from savannah extracted into the source tree into win32\0926-32: $ build-tcc.bat -c

Re: [Tinycc-devel] RUNTIME_PLTGOT question

Thomas Stalder wrote: Hello, I have made somes tests and the commit : http://repo.or.cz/tinycc.git/commitdiff/ca92bfc3c64128872793c167de3a58a78b9a1299 reintroduces the problem. Try this and commit if it works and the tests pass. Thanks, -- grischka

Re: [Tinycc-devel] configure file permission

Larry Doolittle wrote: Friends - commit 7acf9aa8 from earlier today took away the x (execute) permission bits on configure. Sorry, it was by accident. Don't know why or when but sometimes my git and/or msys or something does that. -- gr ___

Re: [Tinycc-devel] bug #50847: #line vs. #include "foo.h"

Larry Doolittle wrote: 3. I put together a brain-dead patch to tinycc mob HEAD, that touches three lines total and seems to do the job. It is arguably somewhat wasteful of scratch memory. Here it is, sorry if the mail pipeline mangles it: Push to mob if you want it in the release. (After

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

Marc Vertes wrote: Hello, 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 test, meaning that

Re: [Tinycc-devel] BUG: called function should pop the arguments when using fastcall

张博洋 wrote: Hello, I found that TCC implement 'fastcall' that the calling function pops arguments. However, according to MSDN (https://msdn.microsoft.com/en-us/library/6xa169sk.aspx), the called function should pop arguments when using fastcall. I provided a patch and I have already

Re: [Tinycc-devel] ARM64 PE32+ and UEFI support

Andrei E. Warkentin wrote: Dear tinycc-devel, A few more fixes for your review. - support for generating ARM64 PE32+ images - support for generating X64, ARM64, IA32 (untested) and ARM (untested) UEFI images. I don't think we want relocation entries by default in x86/x86-64 executables.

Re: [Tinycc-devel] tiny bit of lint

Larry Doolittle wrote: grischka - On Tue, May 09, 2017 at 05:44:28PM +0200, grischka wrote: If people are going to use clang more likely, can't you add something to configure for clang to turn off some silly warnings? That would be USEFUL, for example ;) The clang flag to turn off

Re: [Tinycc-devel] tiny bit of lint

Larry Doolittle wrote: Proof of concept, where dummy.c is something simple and correct like int dummy(void) { return 0; } CFLAGS="-Wall -g -O2" cc=clang W_OPTIONS="extra declaration-after-statement undef strict-prototypes write-strings lskdjfsldfkj bogus no-pointer-sign no-sign-compare

Re: [Tinycc-devel] tiny bit of lint

Larry Doolittle wrote: @@ -965,7 +965,7 @@ static void pe_build_exports(struct pe_info *pe) } else { fprintf(op, "LIBRARY %s\n\nEXPORTS\n", dllname); if (pe->s1->verbose) -printf("<- %s (%d symbol%s)\n", buf, sym_count, "s" + (sym_count < 2)); +

Re: [Tinycc-devel] New configure arguments?

ES in the Makefile. Type ./configure --config-no-ldoubles then look at config.mak. I guess it is not a problem to stuff the code with the related #ifdefs? How could I tell in advance ? --- grischka ___ Tinycc-devel mailing list Tinycc-devel@no

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

, moving include stdarg to the top, and modifying the #define, mpv builds with tcc cleanly and runs fine on alpine (with video, opengl, audio, etc). Doesn't sound too bad ;) --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] New configure arguments?

or DEFINES += -DCONFIG_LDOUBLES=0 (Hm, maybe a reason to rethink the name "config-cross.mak") --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tiny bit of lint

Larry Doolittle wrote: Friends - On Tue, May 09, 2017 at 11:49:23AM +0200, Christian Jullien wrote: Arf! You're right. That why I never fix warning in a code which is not mine. My fix proposal is definitively better. Sorry, everyone, testing should have caught my original mistake. I

Re: [Tinycc-devel] Annoying new warning

Christian Jullien wrote: Especially if " LDOUBLE_SIZE != 8 is not possible in any arm config" why is there such a test in arm-gen.c code? The "arm-fpa-ld" variant gets LDOUBLE_SIZE=12 passed from the Makefile. -- gr ___ Tinycc-devel mailing list

Re: [Tinycc-devel] Annoying new warning

ix. Nope. We will not waste more of anyone's time with this. http://repo.or.cz/tinycc.git/commitdiff/44abffe33a10ee2bdc0d66f87ffa5e178182d6e6 Please test. Thanks, --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.

Re: [Tinycc-devel] Annoying new warning

] On Behalf Of grischka Sent: dimanche 7 mai 2017 12:45 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] Annoying new warning Christian Jullien wrote: So, gentlemen, it seems that at least one ARM configuration/option requires the offending code having test on an uninitialized value

Re: [Tinycc-devel] Annoying new warning

Christian Jullien wrote: After doing a dichotomy search I found that: 2017-02-13 grischka mems & leaks commit was the last commit WITHOUT this warning Next commit also made by grischka, introduced this warning: 2017-02-13 grischka updates & cleanups (tcc-doc/Changelog/TODO ...

Re: [Tinycc-devel] bitfield handling

e attached, have fun ... (no hurry ;) --- grischka #include #include //# pragma pack(1) struct _s { int x: 12; char y: 6; long long z:63; char w:6; // total:87 } __attribute__((packed)) ; void dump_r(struct _s *s) { int i; for (i = sizeof *s; --i >= 0;) printf(&qu

Re: [Tinycc-devel] Annoying new warning

. What do you think should other people think if they see this? --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Annoying new warning

Christian JULLIEN wrote: Grischka, it was my first attempt with fprintf+exit(0) but I found that none was available in libtcc. I vote for _xxx_abort(const char* msg); Christian Nope. Just #ifdef out the entire function. --- grischka

Re: [Tinycc-devel] tiny bit of lint

of "tinycc avoids the unnecessary". Suggesting particular care that feels alien in contrast to what the code really cares about. --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] bitfield handling

least) equally great. --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] ARM64 PE32+ and UEFI support

st of the tinycc code. Thanks, --- grischka A On Sun, Sep 10, 2017 at 1:36 AM, Andrei Warkentin < andrey.warken...@gmail.com> wrote: Well, there could many reasons why someone might wish to build a EXE with base relocs, even in a non-UEFI scenario. This is equivalent to CL's /FIXED:

Re: [Tinycc-devel] One bug and one question

Gabriele Fulgaro wrote: 1 - Visual studio compiler (cl) don't recognize option -DONE_SOURCE=0 in build-tcc.bat. -DONE_SOURCE"=0" works. 2 - Is possible to show the value of variables with gdb? It not show any variables... No, debug info currently is only source-line numbers and function

Re: [Tinycc-devel] Apply to commit: Win: crt, initialize global variables __grgc, __targv and _tenviron of msvcrt

YX Hao wrote: Hi grischka and all, As said, this patch mainly initializes the suit of 3 variables, which is omitted. It doesn't cost much. And it's useful :) Secondly, based on this update, we can reduce the loops to get 'szCmd' in '_twinstart'. Please review if I made any mistake. Yes, szCmd

Re: [Tinycc-devel] Coding standards

better if it's somewhat readable. Btw. seems someone gave us a 'Codingstyle' file too. I'd think it's not bad (also in that it doesn't say too much about style really). --- grischka Charles ___ Tinycc-devel mailing list Tinycc-devel@no

Re: [Tinycc-devel] Introduce tcc_args

uso ewin wrote: Hello, I'm using tcc, as a JIT compiler for this project: https://github.com/cosmo-ray/yirl, on which I need to use -nostdlib but, libtcc.h doesn't allow to do that, only the command line does. tcc_set_options(s, "-nostdlib"); From 2/2013:

Re: [Tinycc-devel] plans to 0.9.27

Christian Jullien wrote: Chris, This is precisely why I wrote win32/Makefile which, with only Cygwin+native Cygwin gcc, was able to bootstrap a native Windows tcc for x86 and x86_64 and check that all tests work. Grischka disliked to have this Makefile and insisted to remove it. HIMO, we now

<    1   2   3   4   5   6   7   8   9   >