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

Hi, $ find /usr/lib -name crt1.o /usr/lib/crt1.o -Original Message- From: grischka [mailto:gris...@gmx.de] Sent: lundi 17 octobre 2016 18:32 To: Christian JULLIEN; tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] [FreeBSD support] __aligned(n) + __pure issues Christian JULLIEN wrote

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

_(4, 0) cdefs.h:#if __GNUC_PREREQ__(4, 1) cdefs.h:#if __GNUC_PREREQ__(3, 1) cdefs.h:#if !__GNUC_PREREQ__(2, 7) !defined(__INTEL_COMPILER) cdefs.h:#if __GNUC_PREREQ__(4, 3) || __has_attribute(__artificial__) stdatomic.h:#elif __GNUC_PREREQ__(4, 7) - message d'origine - De : "Christ

[Tinycc-devel] #if defined(TCC_TARGET_ARM64) || defined(TCC_TARGET_X86_64) looks more releated to 64bit than to a specific architecture.

Having only a look at tccgen.c I see #if related to an architecture (which is of course Ok) but but more and more often #if defined(TCC_TARGET_ARM64) || defined(TCC_TARGET_X86_64) . #else #endif Which are used to generate code related to word / int / long / long long processor size. I

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

Thank you Michael, Trying your latest commit makes me able to compile and run all tests except those below. Even a very simple test fails to find stdlib: $ pwd /usr/home/jullien/tinycc $ cat foo.c #include int main() { printf("Hello World\n"); return 0; } $ ./tcc -B. foo.c -o hello

Re: [Tinycc-devel] Governance (Re: cleanups)

Well, I’m not sure savannah allows this, but one way to limit anarchical and gratuitous commits is to refuse (with help of a pre-commit hook, see https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) any commit that does not refer to a ticket. This way, when you want to do something you

[Tinycc-devel] [FreeBSD support] x86_64 this time.

Just to inform all of you that FreeBSD 11.0 on x86_64 I've just installed on a VM works as on i386. i.e. it runs all the tests except when -run is used. This is not too bad. It is very likely that when i386 is fixed, it will also fix x86_64 port. Let's tune.

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

inycc-devel@nongnu.org Subject: Re: [Tinycc-devel] [FreeBSD support] __aligned(n) + __pure issues Hi, On Sat, 15 Oct 2016, grischka wrote: > Christian Jullien wrote: >> Ok, >> The point is that it compiles ROOTB but then a single line program >> using only ISO incl

Re: [Tinycc-devel] tcc now displays the right system name with -v or -vv

the right system name with -v or -vv Shouldn't it be DragonFlyBSD ?? J From: Tinycc-devel [mailto:tinycc-devel-bounces+michael=theessentialexchange@nongnu.org] On Behalf Of Christian Jullien Sent: Saturday, October 15, 2016 3:53 AM To: tinycc-devel@nongnu.org Subject: [Tinycc-devel] tcc

Re: [Tinycc-devel] Governance (Re: cleanups)

Gentlemen, I will don’t blame anybody here, especially Grischka that does an amazing job. The real issue I see with most computer languages having ports on different systems and processors is that they lack of compressive test suite and tcc is not an exception. Here, I’m not talking about

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

cc compiled by itself fails. If I define __aligned(n), it compiles but linker does not find any std C library function (strcpy, malloc …) From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Christian Jullien Sent: samedi 15 octobre 2016 18:26 To: tinycc-devel@nongnu.

[Tinycc-devel] tcc now displays the right system name with -v or -vv

Please feel free to add your favorite system here : --- a/tcc.c +++ b/tcc.c @@

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

Just tested on: jullien@gcc113:~/tinycc$ uname -a Linux gcc113 3.13.0-92-generic #139-Ubuntu SMP Tue Jun 28 20:45:34 UTC 2016 aarch64 aarch64 aarch64 GNU/Linux Fully working, no error at all! Thanks Christian -Original Message- From: Tinycc-devel

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

and no specific options $ gcc foo.c $ It of course prevents me to use tcc to compile tcc and test. -Original Message- From: Michael Matz [mailto:matz@frakked.de] Sent: vendredi 14 octobre 2016 18:17 To: Christian JULLIEN; tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] [FreeBSD supp

Re: [Tinycc-devel] cleanups

IMHO, there are two different things to consider: - a non-regression tests suite which is only about regressions. It contains tests that once proved to be a BUG which are fixed and we don't want to see back again. It contains also complete and silly tests that are not expected to fail (1.0 == 1 is

Re: [Tinycc-devel] Windows test suite, why 24_math_library is removed?

2015 I fixed most of those issues. However, I wasn't aware that some tests were disabled on windows due to the missing functions. Good catch (I'd leave it to you to re-enable them). On Sunday, October 9, 2016 5:20 PM, Christian Jullien <eli...@orange.fr> wrote: Hi again, I see fro

[Tinycc-devel] could tcc -vv display last git commit date?

Configure change proposal : echo "#define TCC_RELEASE_DATE \"`git log -1 --format=%cd`\" >> $TMPH Then extend -vv to display release date. It will help determine if s.o. is up to date. F:\tinycc>win32\tcc -vv tcc version 0.9.26 (i386 Windows) - Wed Oct 12 06:18:38 2016 +0200 install:

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

] On Behalf Of Christian Jullien Sent: mardi 11 octobre 2016 06:47 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] PATCH: Use R_AARCH64_MOVW_UABS_G* instead of R_AARCH64_CALL26. Thank you Edmund, but it does not work (see below). Btw, do you know that can ask for an account on GCC Compile

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

Thank you Edmund, but it does not work (see below). Btw, do you know that can ask for an account on GCC Compile Farm Project (see: https://gcc.gnu.org/wiki/CompileFarm) Here you can have remote access on different machines for free. Among them you have: name port disk CPU

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

ib function is found. - message d'origine - De : "grischka" gris...@gmx.de date lun. 10/10/2016 12:35 (GMT +02:00) À : "Christian JULLIEN" eli...@orange.fr, "tinycc-devel@nongnu.org" tinycc-devel@nongnu.org Objet : Re: [Tinycc-devel] [FreeBSD support] __aligned(n) +

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

? Christian - message d'origine - De : "grischka" gris...@gmx.de date lun. 10/10/2016 11:09 (GMT +02:00) À : "tinycc-devel@nongnu.org" tinycc-devel@nongnu.org Objet : Re: [Tinycc-devel] [FreeBSD support] __aligned(n) + __pure issues Christian Jullien wrote: in

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

Hi, As FreeBSD is supported, I gave a try with FreeBSD 11.0 i386 released yesterday and I'm facing issue with __aligned(n) and _pure directives. ./configure; gmake Correctly produces a working tcc binary. gmake -k test proves that 'most' tests work except two: BUG1: ../tcc -B..

[Tinycc-devel] Windows test suite, why 24_math_library is removed?

Hi again, I see from test/test2/Makefile that 24_math_library is removed for Windows because of lack of round(). ifdef CONFIG_WIN32 SKIP += 24_math_library.test # don't have round() With mob compiled with a recent MinGW gcc compiler. This test is fully working. Can you reconsider to

[Tinycc-devel] [aarch64 maintainer] BUG: R_AARCH64_(JUMP|CALL)26 relocation failed

Hi all, I continue the QA on machines I have access on. Now, it is the turn of aarch64 Linux board: "8x2.4 GHz aarch64 / 32 GB RAM / APM X-Gene Mustang board / Ubuntu 14.04.3 LTS" Trying to compile mod I get: ... libtest ./libtcc_test -B.. -I../include -I.. -I..

Re: [Tinycc-devel] x86_64 maintainer, I remind you that long double is still not supported

, I remind you that long double is still not supported Christian Jullien <eli...@orange.fr>: > Part of 73_arm64 test (btw test name is odd), f11 and f21 work well > while f31 hangs because of: > x86_64-gen.c :1359 > // This program is designed to test some arm

[Tinycc-devel] x86_64 maintainer, I remind you that long double is still not supported

Hi, A quick note first: Because we want to release a new version, I'm trying to play the role of a kind of "release manager". I'm definitely NOT TinyCC release manager and I'm not sure I want to be, I'm just trying to help. I'm reviewing tests or features that are not working ATM. I'm able

Re: [Tinycc-devel] BUG for ARM (32) maintainers

evel] BUG for ARM (32) maintainers On Sat, Oct 08, 2016 at 07:33:03PM +0200, Christian Jullien wrote: > Now, the only two broken tests are related to unsupported vla: VLAs are now supported on ARM. Best regards, Daniel ___ Tinycc-devel mail

Re: [Tinycc-devel] BUG for ARM (32) maintainers

+0200, Christian Jullien wrote: > I don't know if you are aware, but for uncounted months, 73_arm64 is > broken on ARM (as with mi RPi which uses Hard floats). Try again. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nong

[Tinycc-devel] BUG for ARM (32) maintainers

Hi all, I don't know if you are aware, but for uncounted months, 73_arm64 is broken on ARM (as with mi RPi which uses Hard floats). 73_arm64.c is a test for some ARM64 specific things (as said in comments) but it should work on any architecture. I'm not sure it true because Makefile

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

for ARM by latest version... - message d'origine - De : "grischka" gris...@gmx.de date mer. 05/10/2016 08:53 (GMT +02:00) À : "tinycc-devel@nongnu.org" tinycc-devel@nongnu.org Objet : Re: [Tinycc-devel] One of Grischka's recent cleanup break install - at least on ARM Chr

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

On Behalf Of Christian Jullien Sent: lundi 3 octobre 2016 06:35 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] *** SPAM *** Re: One of Grischka's recent cleanup break install - at least on ARM Hi Grischka, With commit "test/pp: cleanup" It still works just fine with: jullien@sims3:~ $

Re: [Tinycc-devel] Include non-standard library

What about? tcc -I C:/foo prog.c -Original Message- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Chen, Xianwen Sent: mardi 4 octobre 2016 19:08 To: tinycc-devel@nongnu.org Subject: [Tinycc-devel] Include non-standard library Dear developers,

Re: [Tinycc-devel] PPTest13 issue on RPi

Hello Michael, Thank you for your time and your fix. Trying your patch (i.e. w.o. #if test) makes all PPtest work. You can commit it. C. -Original Message- From: Michael Matz [mailto:matz@frakked.de] Sent: lundi 3 octobre 2016 18:38 To: Christian JULLIEN; tinycc-devel Subject: Re

[Tinycc-devel] PPTest13 issue on RPi

On RPI, for monthes now, I have this error: jullien@sims3:~/tinycc/tests/pp $ ../../tcc -E -P 13.S 13.output 21 ; diff -Nu -b -B -I "^#" ../../tests/pp/13.expect 13.output --- ../../tests/pp/13.expect 2016-10-03 13:15:02.292455721 +0200 +++ 13.output 2016-10-03 13:22:36.991074604 +0200 @@ -1,6

Re: [Tinycc-devel] -fPIC anyone?

___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

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

Thank you Jean-Claude, I confirm that your last commit works on Windows for both 32/64bit backend. C. From: Jean-Claude Beaudoin [mailto:jean.claude.beaud...@gmail.com] Sent: mardi 27 septembre 2016 08:08 To: Christian JULLIEN; tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] Tidying

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

I'm using a rather recent mingw gcc 6.1 built for multi-arch (i.e. a single binary which works passing either -m32/-m64). C. - message d'origine - De : "Jean-Claude Beaudoin" jean.claude.beaud...@gmail.com date lun. 26/09/2016 09:22 (GMT +02:00) À : "Christian JULLIEN&qu

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

t;a.out"); I see it uses both pstrcpy and strcpy. - message d'origine - De : "Jean-Claude Beaudoin" jean.claude.beaud...@gmail.com date lun. 26/09/2016 07:48 (GMT +02:00) À : "tinycc-devel@nongnu.org" tinycc-devel@nongnu.org Objet : Re: [Tinycc-devel] Tidying TCC's

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

In order to build tcc.c on Windows, I reverted pstrcpy back to a PUB_FUN. Hope it’s also Ok for you. C. From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Jean-Claude Beaudoin Sent: lundi 26 septembre 2016 05:34 To: tinycc-devel@nongnu.org

Re: [Tinycc-devel] Why is __LP64__ defined for targets for 32bits targets?

Having no remarks, I pushed this change and added 86-memory-model.c that test __*LP*__ features on different systems. I'm unsure what the values should be for C67. Christian From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Christian Jullien Sent

Re: [Tinycc-devel] Why is __LP64__ defined for targets for 32bits targets?

ne_symbol(s, "__PTRDIFF_TYPE__", "long"); tcc_define_symbol(s, "__ILP32__", NULL); #endif mob looks good on Windows 32 and 64, Linux x86_64, Linux arm and arm64. Can you please review for other architectures/OS? From: Christian Jullien [mailto:eli...@o

Re: [Tinycc-devel] Why is __LP64__ defined for targets for 32bits targets?

symbol(s, "__SIZE_TYPE__", "unsigned long"); tcc_define_symbol(s, "__PTRDIFF_TYPE__", "long"); +tcc_define_symbol(s, "__LP64__", NULL); #endif From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of C

[Tinycc-devel] Why is __LP64__ defined for targets for 32bits targets?

/* TinyCC & gcc defines */ #if defined TCC_TARGET_PE && defined TCC_TARGET_X86_64 tcc_define_symbol(s, "__SIZE_TYPE__", "unsigned long long"); tcc_define_symbol(s, "__PTRDIFF_TYPE__", "long long"); tcc_define_symbol(s, "__LLP64__", NULL); #else tcc_define_symbol(s,

Re: [Tinycc-devel] tcc compilation on MSYS2

On windows you can use _fullpath https://msdn.microsoft.com/en-us/library/506720ff.aspx C. -Original Message- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Sergey Korshunoff Sent: samedi 21 mai 2016 11:19 To: avih; tinycc-devel@nongnu.org

Re: [Tinycc-devel] spawnvp V.S. _spawnvp on Windows

-devel@nongnu.org Subject: Re: [Tinycc-devel] spawnvp V.S. _spawnvp on Windows Hello Christian, That was an annoying warning. You patch works for me on my flavors of Windows on the toolchain provided by Strawberry Perl. Thanks! David On Tue, May 17, 2016 at 12:23 AM, Christian Jullien <

Re: [Tinycc-devel] spawnvp V.S. _spawnvp on Windows

; From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Christian Jullien Sent: lundi 16 mai 2016 10:12 To: tinycc-devel@nongnu.org Subject: [Tinycc-devel] spawnvp V.S. _spawnvp on Windows Hi, When I build tinycc on Windows (both 32/64 bit). I alway

[Tinycc-devel] spawnvp V.S. _spawnvp on Windows

Hi, When I build tinycc on Windows (both 32/64 bit). I always get this warning: ../tcc.c:136:39: warning: passing argument 3 of 'spawnvp' from incompatible pointer type [-Wincompatible-pointer-types] int ret = spawnvp(P_NOWAIT, prog, (const char *const*)argv); Looking a

[Tinycc-devel] Recent asm changes break Windows 64 built

F:\tinycc\win64>.\tcc -DTCC_TARGET_PE -DTCC_TARGET_X86_64 -c ../lib/alloca86_64.S ../lib/alloca86_64.S:15: error: bad operand with opcode 'and' F:\tinycc\win64>tiny_libmaker lib/libtcc1.a libtcc1.o alloca86_64.o crt1.o wincrt1.o dllcrt1.o dllmain.o chkstk.o Can't open file alloca86_64.o

[Tinycc-devel] 85-asm-outside-function.c on non Intel

Hi, TinyCC works on different architecture, among them is ARM I especially care about for my RPi. 85-asm-outside-function.c now includes test that fails on this architecture. Can you please check processor and adapt this test otherwise I get: Test: 85-asm-outside-function... ---

Re: [Tinycc-devel] tcc build on OSX

I also use __MACH__ which is for Darwin #if (defined(__MACH__) && defined(__APPLE__)) #define OLOSSYSTEMNAME "macosx" #endif For different compiler/architecture/os detection I suggest you have a look at: https://sourceforge.net/p/predef/wiki/Home/ For OS:

Re: [Tinycc-devel] gcc/tcc nested macros difference

Do you known that you can test C/C++ code using different gcc/clang version on http://gcc.godbolt.org/ As you type your code on left window it displays assembler code on the right. You can of course play with different options to see how it modifies generated code. You can even make a link to

Re: [Tinycc-devel] Preprocessor performance tuning

And "valgrind --leak-check=full " provides no help? -Original Message- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Sergey Korshunoff Sent: mardi 19 avril 2016 10:05 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] Preprocessor

[Tinycc-devel] First kcachegrind output

Hi, I just had time to see how tcc behaves with callgrind (a valgrind tool) on Fedora. 1) Install required tools $ sudo dnf install graphviz valgrind kcachegrind 2) run tcc on top of callgrind and collect results. $ valgrind --tool=callgrind ./tcc -c -I include tccgen.c 3) See

Re: [Tinycc-devel] Preprocessor performance tuning

I wonder if s.o ever tried to compile tcc with gcc and then use kcachegrind on some big project compiled with tcc to see what tcc areas can/must be optimized? I would love to do that but I've to time to investigate. C. -Original Message- From: Tinycc-devel

[Tinycc-devel] Time to make a 0.9.27 version?

Hi guys, These days, tcc seems to be very stable and I see no big dev/fix coming soon. Don't you think it's time to make a stable 0.9.27 as official 0.9.26 (http://download.savannah.gnu.org/releases/tinycc/) is quite old. Christian. ___

[Tinycc-devel] RE :Re: Nevermind my previous comments. I just made an error.

___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Tiny CC isn't working with floating point math

A toy compiler? I can’t let you say that given the fact that this ‘toy compiler’ is also able to compile a ‘toy os’ named Linux. It is also able to compile my ‘toy OpenLisp’ compiler with full float/double math support and many other yet VERY BIG and well know ‘toy’ projects. Christian

Re: [Tinycc-devel] Problem with reinterpret_cast

If you want to cast something in a program compiled by TCC (which is NOT a C++ compiler as Basile said), you must use C style cast that works perfectly well (including, but not recommended, if compiled by a C++ compiler which *must* accept this style of cast). X* x = ..; Y* y = (X*)x; Christian

Re: [Tinycc-devel] Nevermind my previous comments. I just made an error.

It makes sense :o) Thanks for the update. From: tinycc-devel-bounces+eligis=orange...@nongnu.org [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Ben Hutchinson Sent: dimanche 10 janvier 2016 11:37 To: tinycc-devel@nongnu.org Subject: [Tinycc-devel] Nevermind my

[Tinycc-devel] RE :Re: Speed of development of a compiler.

This exactly what I do with my Lisp compiler. See https://en.wikipedia.org/wiki/OpenLisp#Compiler The compiler targets a very small subset of C which is a peace of cake to compile by any decent C compiler. For example, on Rasberry Pi you can have a low footprint fast compile cycle. You may also

[Tinycc-devel] RE :Re: Speed of development of a compiler.

I fully second Basile, semantic is much more important than syntax. It took us more than 10 years to normalize ISO ISLISP semantic which consists in only 25 special forms which fully describe semantic of the language (C. Queinnec was convenor of this ISO group and a great help to define

[Tinycc-devel] RE : Speed of development of a compiler.

I depends on what you mean by "create a compiler supporting one simple language like C" It may take one month to have something that looks like C. It takes several years for team to develop a fully conforming ISO implementation (including standard library). Here I don't speak about backend

[Tinycc-devel] RE :Re: VLA implementation

Hi, as C11 allows VLA I don't see any reasons to warn when it is used. However, as some tcc backend (like ARM) don't currently support VLA, a C code working code on x86 will fail on ARM. It's more an issue with ARM backend than with VLA. It would be nice for tcc to behave the same for all

Re: [Tinycc-devel] "mormalize_inc_dirs"

Since you know you’re on Windows, you can call GetFullPathName on two dirs and compare results. It is available since XP and present in kernel32 DWORD WINAPI GetFullPathName( _In_ LPCTSTR lpFileName, _In_ DWORD nBufferLength, _Out_ LPTSTR lpBuffer, _Out_ LPTSTR *lpFilePart

Re: [Tinycc-devel] "mormalize_inc_dirs"

Hum! You can: fopen("dir-to-test/__deleteme__", "w"); If it succeeds, dir-to-test exists then call fclose and remove("dir-to-test/__deleteme__"). Use some random name instead of __deleteme__ It does not just test that directory exists but also it is writable. If you know that a file may exist

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

: Re: [Tinycc-devel] modern c++ compiler written in C (food forthought) Date: Sun, 1 Nov 2015 07:30:14 +0100 From: "Christian Jullien" eli...@orange.fr To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] modern c++ compiler written in C (food for thought) Message-ID:

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

This my last post about OpenLisp to not pollute tcc mailing Lisp. Yes, OpenLisp is probably the world fastest lisp interpreter. For example, it interprets lisp code faster than CLISP compiler. It has 3 modes interpreter (the default), compiled to LAP with interpreted by a VM (~ 2times

Re: [Tinycc-devel] AArch64 status?

Here is the complete log which is not too bad: jullien@gcc113:~/tinycc$ make -k tests make: Nothing to be done for `tests'. jullien@gcc113:~/tinycc$ make -k test > foo 2>&1 jullien@gcc113:~/tinycc$ more foo make -C tests test 'PROGS_CROSS=i386-linux-gnu-tcc x86_64-linux-gnu-tcc i386-win

Re: [Tinycc-devel] AArch64 status?

To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] AArch64 status? Christian Jullien: > Here is the complete log which is not too bad: Thanks. I've just pushed a fix for the VLA stuff. You might now find that libtest is the only failure. However, libtest isn't the only thing that's bro

[Tinycc-devel] AArch64 status?

Hi guys, The 'GCC Compile Farm Project' recently added 4 (four) '8x2.4 GHz aarch64 / 32 GB RAM / APM X-Gene Mustang board / Ubuntu 14.04.3 LTS' machines.' I can't resist any more to see how well tcc compiles and works on an AArch64 processor. He is my first attempt. It compiles well and first

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

Woah! Basile, we said about the same things at the same time. I of course fully agree with your post :o) Christian -Original Message- From: tinycc-devel-bounces+eligis=orange...@nongnu.org [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Basile Starynkevitch Sent:

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

-bounces+eligis=orange...@nongnu.org] On Behalf Of Sergey Korshunoff Sent: jeudi 29 octobre 2015 00:27 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] modern c++ compiler written in C (food for thought) Hi Christian Jullien! > I'm really afraid to see discussion on about to optim

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

Hi all, C++ is several orders of magnitude more complex than C. It has the reputation to be slower than C and, in some sense, it is true when used by non-highly experimented C++ programmers. (In real life, C++ can outperform C - I have code that run >2x as fast in C++ --thanks to templates-- than

Re: [Tinycc-devel] [RFC] tinycc and rock compiler

This is not a BUG but a feature that C compliers often propose (for example, VC++ has: /GF enable read-only string pooling) Strictly speaking, tcc is right with this behavior and no portable programs should rely on this feature. If you want a faster code when this feature exists you should write:

[Tinycc-devel] RE : CYGWIN support, Is __cdecl supported, esp. on linux?

;uc_mcontext.gregs[REG_RBP]; nbsp;#endif - message d'origine - De : Christian JULLIEN lt;eli...@orange.frgt; date jeu. 30/07/2015 10:22 (GMT +02:00) À : tinycc-devel lt;tinycc-devel@nongnu.orggt; Objet : [Tinycc-devel] CYGWIN support, Is __cdecl supported, esp. on linux? Hi All, I'm trying

[Tinycc-devel] CYGWIN support, Is __cdecl supported, esp. on linux?

Hi All, I'm trying to make tcc compile ROOTB on Cygwin and I already have tcc.exe running with very few patches (see below).The problem I'm facing is a parse error with __cdecl declarations from cygwin includes. Even on a standard Linux machine running mod tcc, the following code:void __cdecl

[Tinycc-devel] RE : [RFC] Moving source code to src

Hi Gus, This is a good idea. If you do so, I also suggest an arch directory that contains subdirectories for all supported archives arch/armarch/arm64arch/i386... I'm afraid this code refactory will take long until it works on all platforms (including Windows). Talking about Windows, who has a

[Tinycc-devel] RE :Re: RE : [RFC] Moving source code to src

- De : gus knight lt;waddlespl...@gmail.comgt; date lun. 27/07/2015 22:11 (GMT +02:00) À : tinycc-devel@nongnu.org lt;tinycc-devel@nongnu.orggt; Objet : Re: [Tinycc-devel] RE : [RFC] Moving source code to src On Mon, Jul 27, 2015 at 12:48 PM, Christian JULLIEN lt;eli...@orange.frgt; wrote: gt; Hi

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

Maddox lt;absinthdr...@gmail.comgt; date lun. 18/05/2015 08:34 (GMT +02:00) À : tinycc-devel@nongnu.org lt;tinycc-devel@nongnu.orggt; Objet : Re: [Tinycc-devel] OT (Re: modern c++ compiler written in C) gt; Date: Sat, 16 May 2015 13:07:24 +0200 gt; From: u-tcc-u...@aetey.se gt; To: Christian Jullien lt

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

Sorry to insist cfront showed us a usable C++ dialect and also a proof that such a dialect can be efficiently implemented by a translator to C. Nobody doubt it's true. Cfront has been the de facto standard for years so it is clearly usable and you can do reasonable code with it. However, I

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

] On Behalf Of u-tcc-u...@aetey.se Sent: samedi 16 mai 2015 11:14 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] OT (Re: modern c++ compiler written in C) On Sat, May 16, 2015 at 08:11:21AM +0200, Christian Jullien wrote: Sorry to insist :) nice to see your devotion to the topic cfront

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

If I write some my application with that g++ and then want to start it using today, a plenty of work is needed to rewrite that application. For sure! C++ is a language for those who want all bits from their processor. I work for a company that cares about nanoseconds. Everything we do in C++ is

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

at 08:50:44AM +0200, Christian Jullien wrote: Of course, I know C++ programs that satisfy themselves with 'basic' C++ features. The difficulty is to agree on 'basic' features. No two C++ users use the same 'basic' features. Some want only encapsulation + ctor and dtor. No more. Others want

Re: [Tinycc-devel] can't relocate value at 2058898, 1 on RPi with last commit!

But next cron one hour later does not show this bug. Strange! From: tinycc-devel-bounces+eligis=orange...@nongnu.org [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Christian Jullien Sent: samedi 18 avril 2015 10:07 To: tinycc-devel@nongnu.org Subject: [Tinycc-devel

[Tinycc-devel] can't relocate value at 2058898, 1 on RPi with last commit!

My TinyCC cron complains : hello-run ./tcc -B.. -I.. -I.. -I../include -run ../examples/ex1.c Hello World gcc -o libtcc_test libtcc_test.c ../libtcc.a -I.. -DCONFIG_MULTIARCHDIR=\arm-linux-gnueabihf\ -DTCC_TARGET_ARM -DTCC_ARM_EABI -DTCC_ARM_HARDFLOAT -DTCC_ARM_VFP

[Tinycc-devel] RE : #pragma push_macro(abort) #pragma pop_macro(abort)

IMHO if not implemented it should not warn. 6.10.6 Pragma directive Semantics A preprocessing directive of the form # pragma pp-tokensopt new-line where the preprocessing token STDC does not immediately follow pragma in the directive (prior to any macro replacement)174) causes the implementation

[Tinycc-devel] RE :Re: Dollar Sign in Identifiers Extension

___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Dollar Sign in Identifiers Extension

Good luck for nested function implementers that (as is Lisp :o) will want to make this code working! typedef int (*fp) (uint32_t i); int callback(fp fn, uint32_t i) fn(i);{ } uint32_t isEven(uint32_t i) { uint32_t odd(uint32_t i) { if (i == 0) return 0;

Re: [Tinycc-devel] Dollar Sign in Identifiers Extension

No need to search for a parent BP if you don't support recursive functions and function pointer return as with my example. In this case you 'only' have to implement currying on your local functions. It's a big change for the compiler. C. -Original Message- From:

[Tinycc-devel] RE :Re: Last commit [26-03-2015] breaks RPi build - conflicting types for 'section_ptr_add'

You'd better thanks my cron job that, every hours, checks tinycc changes and sends me email :o) The latest runs tells me it is (as I am) happy with your fix. Christian - message d'origine - De : Sergey Korshunoff lt;sey...@gmail.comgt; date jeu. 26/03/2015 09:34 (GMT +01:00) À :

[Tinycc-devel] Last commit [26-03-2015] breaks RPi build - conflicting types for 'section_ptr_add'

gcc -o tcc.o -c tcc.c -DCONFIG_MULTIARCHDIR=\arm-linux-gnueabihf\ -DTCC_TARGET_ARM -DTCC_ARM_EABI -DTCC_ARM_HARDFLOAT -DTCC_ARM_VFP -I. -Wall -g -O2 -Wno-deprecated-declarations -Wno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result -Wno-uninitialized -fno-strict-aliasing gcc

Re: [Tinycc-devel] some thoughts on the search path mess

Here native compiler values on arm (RPI). Tcc is configred with: ./configure --with-libgcc Binary directory /usr/local/bin TinyCC directory/usr/local/lib/tcc Library directory /usr/local/lib Include directory /usr/local/include Manual directory/usr/local/share/man Info directory

[Tinycc-devel] Windows build broken after 'A gcc preprocessor option -dD added' commit on March 3

Hi all, This commit: author http://repo.or.cz/w/tinycc.git/search/b7b9f9f51170bd1616ee56acfef9c6bf20b9c f3f?s=seyko;st=author seyko http://repo.or.cz/w/tinycc.git/search/b7b9f9f51170bd1616ee56acfef9c6bf20b9c f3f?s=sey...@gmail.com;st=author sey...@gmail.com Tue, 3 Mar

[Tinycc-devel] RE :Re: 1cbb4d322bc3c89a3b56d35c803a19f99f33ab65 broke tcc on arm (RPi) 6 days ago

) À : Christian JULLIEN lt;eli...@orange.frgt;, tinycc-devel@nongnu.org lt;tinycc-devel@nongnu.orggt; Objet : Re: [Tinycc-devel] 1cbb4d322bc3c89a3b56d35c803a19f99f33ab65 broke tcc on arm (RPi) 6 days ago Try to revert ifeq ($(ARCH),arm) TARGET = arm - XCC = $(CC) else and test PS: arm-tcc

[Tinycc-devel] 1cbb4d322bc3c89a3b56d35c803a19f99f33ab65 broke tcc on arm (RPi) 6 days ago

Hi all, nbsp; http://repo.or.cz/w/tinycc.git/blobdiff/7ed43415380ec6270e53c0ed3f42e5cb99df1f6e..1cbb4d322bc3c89a3b56d35c803a19f99f33ab65:/lib/Makefile nbsp; broke tcc on RPi. nbsp; tcc on arm is not able to compile assembler files On RPi, I use ./configure --with-libgc which used to select gcc to

[Tinycc-devel] RE :Re: 1cbb4d322bc3c89a3b56d35c803a19f99f33ab65 broke tcc on arm (RPi) 6 days ago

; date mar. 10/03/2015 11:07 (GMT +01:00) À : Christian JULLIEN lt;eli...@orange.frgt;, tinycc-devel@nongnu.org lt;tinycc-devel@nongnu.orggt; Objet : Re: [Tinycc-devel] 1cbb4d322bc3c89a3b56d35c803a19f99f33ab65 broke tcc on arm (RPi) 6 days ago --with-libgcc means (tcc.h): library to use

Re: [Tinycc-devel] RE :Re: New test 73_arm64 hangs if ran on RPi

Edmund, My cron script start with git pull, so I always test the latest commits. Anyway, I just checkout mob from scratch and still get (on RPi): Test: 73_arm64... Segmentation fault --- 73_arm64.expect 2015-02-27 06:17:47.245905760 +0100 +++ 73_arm64.output 2015-02-27

Re: [Tinycc-devel] RE :Re: New test 73_arm64 hangs if ran on RPi

Hi, Same issue with x86_64 and RPi arm32 C. -Original Message- From: tinycc-devel-bounces+eligis=orange...@nongnu.org [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Edmund Grimley Evans Sent: jeudi 26 février 2015 13:38 To: tinycc-devel@nongnu.org Subject: Re:

Re: [Tinycc-devel] [PATCH] cpu detection

Even on Windows x64 using x64 cl version, long is 4 bytes! This is by design to 'ease' porting from x86 to x64. #include stdio.h int main() { printf(%d\n, sizeof(long)); } Using Microsoft (R) C/C++ Optimizing Compiler Version 18.00.30723 for x64 = 4 size_t gives a better result

[Tinycc-devel] RE :Re: sinf/sin problems

___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] RE : How to use char \

Hi! You need two \\ =gt; strpbrk (file_name,\\*?) First '\' is an escape for next character which is the '\' you want to use. Christian - Message d'origine - De : JFC Morfin lt;jef...@jefsey.comgt; Date mar. 30/09/2014 12:31 (GMT +02:00) À : tinycc-devel@nongnu.org

<    2   3   4   5   6   7   8   9   >