+1 for anything > 0.9.27, really!
C.
From: tinycc-devel-bounces+eligis=orange...@nongnu.org
[mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Detlef
Riekenberg
Sent: Saturday, February 18, 2023 22:02
To: tinycc-devel@nongnu.org
Cc: gris...@gmx.de
Subject: *** SPAM
This post does not solves missing types but be aware that more recent gcc
versions changed the names to [unsigned] __int128
Hence
__uint128_t => unsigned __int128
__int128_t => __int128
Old names remain for compatibility and are *strictly* equivalent.
For example, starting with gcc v11.x,
Maybe this helps?
https://risc-v-getting-started-guide.readthedocs.io/en/latest/linux-qemu.html
There are instructions for 32bit version.
-Original Message-
From: tinycc-devel-bounces+eligis=orange...@nongnu.org
[mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of
If it helps, I've just tried this patch which implement what you suggested, and
it works. Maybe maintainers will consider to add it (.. or not)
diff --git a/Makefile b/Makefile
index c220879..c718d7a 100644
--- a/Makefile
+++ b/Makefile
@@ -447,14 +447,16 @@ config.mak:
$(if $(wildcard
Hi,
As you may know, macOS can build a single file universal binary that is able
to run on different processors.
By default, it selects the CPU associated to the running machine but, with
standard arch command, you can select another CPU (like x86_64 when you're
running on an Apple Silicon -
It will help maintainers if you tell what tcc version you're using.
$ tcc -v
tcc version 0.9.27 mob:95e3951 2022-12-24T09:30:00+01:00 (AArch64 Darwin)
I daily compile a real and rather complex C file as big as 2835488 bytes wo. PB
on Windows 32/64, Linux X86/x64/arm/arm64 as well as few other
Hi,
You missed --config-codesign
Non signed applications immediately crashes on Ventura Mx processors
If you don't want to automatically sign your application, you need to call
codesign manually on generated binary (this is the effect of adding
--config-codesign)
$ codesign -s - -f -vv
Herman does a very impressive job to fully support Apple with both x64/M1.
He commits often and I communicate with him to nervously test all its changes
on different macOS configurations (he has even an account on my machine).
He already fixed all known issue including the one you reported.
The
the machine readable serial. For me the version is still
tcc version 0.9.27 (x86_64 Windows)
I thought you should be aware of it.
Regards
Antonio
Missatge de Christian Jullien del dia dc., 30 de nov. 2022 a
les 9:02:
Format has been lost, patch is in attachment this time
-Original
Format has been lost, patch is in attachment this time
-Original Message-
From: tinycc-devel-bounces+eligis=orange...@nongnu.org
[mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of
Christian Jullien
Sent: Wednesday, November 30, 2022 07:26
To: jull...@eligis.com
vel-bounces+eligis=orange...@nongnu.org
[mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of
Christian Jullien
Sent: Tuesday, November 29, 2022 12:10
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] tcc -v with mob date?
Hi,
Currently, tcc –v displays the (mob) githash wh
Hi,
Currently, tcc –v displays the (mob) githash which helps to identify which this
version comes from.
It is not however user friendly.
I would like to add last commit date as:
jullien@sims4:~/tinycc $ ./tcc -v
tcc version 0.9.27 mob:afcdaf1 on 2022-11-29T00:56:26-06:00 (ARM eabihf Linux)
Herman, you've done an incredible job to make this happen.
Thank you very much for your time and your patience.
Let me precise that, macOS arm64 still supports --cpu=x86_64 and runs
flawlessly the whole test suite.
Funny, on benchmarks made on my Ventura M1 machine, I see no significant
Hi
I already pushed a patch. It lets tcc pass the test comparing with clang
reference. Tell me if it's OK for you.
Christian Jullien
De : Michael Matz
Envoyé : jeudi 17 novembre 2022 15:12
À : jull...@eligis.com; tinycc-devel@nongnu.org
Objet : Re: [Tinycc-devel] clang
Hi team,
I recently updated one of my x64 Linux machine with Fedora 37 which comes
with clang 15.0.
'make test' raises this error when clang 15.0 is used:
./configure --with-selinux --cc=clang --prefix=/home/jullien/tinycc/static
Binary directory/home/jullien/tinycc/static/bin
: Saturday, November 05, 2022 17:22
To: jull...@eligis.com
Cc: psm...@gnu.org; jull...@eligis.com; make-...@gnu.org;
tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] GNUmake v4.4 port on Windows with tcc
> From: "Christian Jullien"
> Cc: ,
> ,
>
> Date: Sat,
\n", x, (int)sizeof(x));
x = (x >> 32);
printf("%llx %d\n", x, (int)sizeof(x));
}
Last but not least, it lets GNUmake compile ROOTB on Windows with this
version of tcc.
Christian
From: Tinycc-devel [mailto:tinycc-devel-boun...@nongnu.org] On Beha
As _strto[u]ll exists in msvcrt.dll and works well for either m32|-m64
tcc.h can just test for _WIN32.
I also define those macros in the win32§include/stdlib.h
jullien@sims4:~/tinycc $ git diff
diff --git a/tcc.h b/tcc.h
index aa04404..1756831 100644
--- a/tcc.h
+++ b/tcc.h
@@ -65,7
Please note that even VisualC++ uses defines (in mapping.h)
/**
* Map stroll to _strtoi64
*
* stroll does not properly map in Windows; this is needed to ensure calls to
* strtoll(const char *nptr, char **endptr, int base) will compile in Windows.
*/
#define strtoll _strtoi64
/**
* Map
Hi,
If you watched the recent posts about GNUmake tcc port on Windows, you've
seen that strtoll and strtoull C99 functions are missing
I tried to add strtoll and strtoull to msvcrt.def but fails when running
executable because they are not part of msvcrt.dll
c:\Windows\System32>strings
-devel@nongnu.org
Subject: Re: GNUmake v4.4 port on Windows with tcc
> From: "Christian Jullien"
> Cc: ,
>
> Date: Thu, 3 Nov 2022 15:29:47 +0100
>
> Of course it does.
Thanks. Paul, should I install this?
> As side note, compiling GNUmake with cl x
-devel@nongnu.org
Subject: Re: GNUmake v4.4 port on Windows with tcc
> From: Paul Smith
> Cc: tinycc-devel@nongnu.org, 'Eli Zaretskii'
> Date: Wed, 02 Nov 2022 11:50:45 -0400
>
> On Wed, 2022-11-02 at 16:40 +0100, Christian Jullien wrote:
> > It appears that tcc on
16:40 +0100, Christian Jullien wrote:
> It appears that tcc on Windows lacks strtoll and strtoull (something
> that
> needs to be fixed on tcc side of course).
> Meanwhile, it can easily be patched in build_w32.bat by adding
> -Dstrtoull=_strtoui64 -Dstrtoll=_strtoi64 at line 330
&
er
> From: "Christian Jullien"
> Date: Wed, 22 Jan 2020 18:44:25 +0100
> Cc: tinycc-devel@nongnu.org
>
> Thank you Eli, your help is really appreciated.
>
> >From the latest https://ftp.gnu.org/gnu/make/make-4.3.tar.gz I don't see
the
> src/config.h.W32.t
It has been proposed to replace this by:
test $(uname) = Linux && test $(uname -o) = Android && targetos=Android
Which works well also on macOS.
It has been neither accepted nor rejected.
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
.org" Objet : Re: [Tinycc-devel] uname -o is not valid on macOSthen how about this: test $(uname) = Linux && test $(uname -o) = Android && targetos=AndroidOn Fri, 12 Aug 2022, grischka wrote:> On 11.08.2022 11:02, Christian JULLIEN wrote:>>>> Here:>>>&g
Here:test "$(uname -o)" = "Android" && targetos=AndroidWhy not just "$(uname)" ?It shows an error but script continues
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocksOn 16.07.2022 18:11, Christian JULLIEN wrote:> Hi, with mod (having your last commit),> I get this error on macOS:> /bin/sh: line 1: 32935 Segmentation fault: 11./tcctest.gcc > test.ref>Hi Christian,seems you did use a tcc to
Hi, with mod (having your last commit),I get this error on macOS:/bin/sh: line 1: 32935 Segmentation fault: 11 ./tcctest.gcc > test.ref./configure --cpu=x86_64 --config-bcheck=no --config-backtrace=no --cc=tcc --prefix=/Users/jullien/tinycc/static=== /Users/jullien/local-tcc/bin/tccBinary
Ye please.
Christian Jullien
Le 08/07/2022, à 04:30, Ziyao a écrit :
I vote yes.It is the time for a new release.
On Fri, Jul 08, 2022 at 01:39:43AM +0200, Detlef Riekenberg wrote:
> The last tcc release is very old, and tcc has received
> many fixes and new features
Hello Michael,
=> http://download.savannah.gnu.org/releases/tinycc/
is really quite old, I doubt you’ll get any help from this list unless you use
mob https://repo.or.cz/w/tinycc.git
C.
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of
Just curious,
When you say "All failed..."
Is it the consequence of
Rpi32
tcc: error: Unknown relocation type for got: 107
Rpi64
tcc: error: Unknown relocation type for got: 313
On macOS, issue is different (and logic AFAIK)
tcc: error: library 'c' not found
tcc: error: undefined symbol
Hi all,
If it helps, on arm (RPi 32bit), I get a different error:
$ tcc -static test.c
tcc: error: Unknown relocation type for got: 107
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of Arthur Williams via Tinycc-devel
Sent:
Hi again,
Another thread for macOS:
jullien@mobley:~ $ tcc -gdwarf foo.c -o foo
tcc: error: ELF section 7 not mapped into Mach-O for symbol
As with Windows, -gdwarf should be either ignored or raise an error if used
on macOS.
C.
___
Hello (Herman)
Thank you for dwarf addition.
I've just tested mob on Windows (as well as on other few other systems).
It looks that dwarf is silently ignored on Windows and behaves as this
option was not supplied:
/cygdrive/f/tinycc/win32 $ ./tcc -g foo.c && ls -ls foo.exe
8
Hi,
Tcc on M1 only supports x86_64 which works with rosetta.
Here is how I compile tcc on my M1 machine:
./configure --cpu=x86_64 --config-bcheck=no --config-backtrace=no
It then works well with only two test suite failures. I use it almost daily
on my MakBook Air M1.
We are
Hello, you can have an insight from Apple code here
https://opensource.apple.com/source/Libm/Libm-47.1/
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of Christopher Choi
Sent: Thursday, April 14, 2022 12:04
To:
Hi,
As you need to update your Makefile to replace ar by 'tcc ar' you can as well
replace the command that produce an empty archive by:
echo '!' > libempty.a.
This works even in the case you use gcc.
Your patch is small and looks good too. Maybe maintainer will want to accept it.
It's a good
I don't know if your patch will reach mob or not but, if it does, IMHO, to be
useful, the output string should match what gcc/clang currently reports.
For example:
RPi 32bit reports:
$ gcc -dumpmachine
arm-linux-gnueabihf
RPi 64bit reports:
$ gcc -dumpmachine
aarch64-linux-gnu
Windows
It would be nice if tcc fully supports POSIX C driver specs.
As long as my voice counts I vote for! Maintainer(s) will decide, I can
perfectly leave without it.
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of John Scott
Sent:
Hi team,
I wonder if tests 108 and 114 are supposed to work on macOS.
It happens from several versions (don't know exactly when).
Whether I compile tcc on a pure x64 or using x64 emulation on Silicon cpu
(aka M1), I get
Test: 108_constructor...
--- 108_constructor.expect
I've got access on Linux M1 machine where macOS has been replaced by Linux.
It compiles ROOTB from mod and pass all tests.
$ uname -a
Linux gcc103.fsffrance.org
5.17.0-rc6-asahi-next-20220301-25570-gc09fe28af1d3 #1 SMP PREEMPT Thu Mar 10
09:33:48 CET 2022 aarch64 GNU/Linux
$ gcc -v
.
I omitted to say that, while it compiles with mod (as with gcc), both tcc and
gcc versions do a core dump when running the binary result.
Tcc is fully compatible with gcc on this point :o)
C.
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of ???
Hi, it looks it has been fixed on mod (tested on Fedora x64).
Official tcc versions are quite old and the is no sign that a new official
version will soon come out.
If you do serious work with tcc I strongly suggest you use mod.
From: Tinycc-devel
, 2022 10:50
To: jull...@eligis.com; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] NULL pointer dereference due to unchecked return
from fdopen()
Christian Jullien wrote:
> Thanks,
> This is unfortunately not the only case where returned value is not tested,
> just for fdopen, if ma
Interesting,
Googling a little bit, I've found that "Risc 64-bit architecture has the same
Instruction length (32bits) but the registers of the CPU are 64 bits wide
instead of being 32 bits wide as in risc 32-bit versions."
If they are close, I wonder if it is possible to have a single set of
Hi, if available on your system (linux and alt.) objdump -d is your friend:
cat foo.c && tcc -c foo.c && objdump -d foo.o
int
imax(int i, int j) {
return (i > j) ? i : j;
}
foo.o: file format elf32-littlearm
Disassembly of section .text:
:
0: e1a0c00dmov
Thanks,
This is unfortunately not the only case where returned value is not tested,
just for fdopen, if maintainers agree, we can probably apply:
Wdyt?
git diff tcc*.c
diff --git a/tccelf.c b/tccelf.c
index 507e83c..bd0a1d9 100644
--- a/tccelf.c
+++ b/tccelf.c
@@ -2428,6 +2428,9 @@ static int
No, riscv64 is for 64bit only.
I'm not aware of riscv32 32bit porting efforts but someone is perhaps busy
working on it.
C.
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of Sagar Acharya via Tinycc-devel
Sent: Sunday, February
Hello Yair,
I only speak for myself but I doubt we will accept an extension to support a
translator for a DLS that nobody knows.
As you write a translator to C, I'm sure that you can translate to something
that will implement your behavior (macro, lib, ...). Remember that all C++
version up to
Hi,
What happens if you configure as below?
./configure --config-musl --config-elfinterp=/lib/ld-musl-armhf.so.1
If it still fails, can you try this patch?
diff --git a/tcc.h b/tcc.h
index ef69ef5..bfe28b6 100644
--- a/tcc.h
+++ b/tcc.h
@@ -331,9 +331,11 @@ extern long double strtold (const
What happens if you patch:
tcc.h:# define CONFIG_TCC_ELFINTERP "/lib/ld-musl-arm.so.1"
Can you then correctly link and execute the generated executable?
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of raingloom
Sent:
I thing you can also specify --elfinterp=... specify elf interpreter
With configure script
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of arn...@skeeve.com
Sent: Tuesday, February 22, 2022 15:24
To:
Hello David,
Funny, I considered to try this port last year, unfortunately my Solaris VM is
broken I only have true Solaris 10 sparc machines (with of course No chances it
works on a sparc CPU).
What is the status of Solaris port after this patch?
Does it works, I think you have some ELF reloc
, but everywhere else. Might suggest uninitialized memory.
lør. 12. feb. 2022, 07:20 skrev Christian Jullien :
Important precision, I reproduce this issue with mob including on RPi arm32;
$ tcc foo.c
foo.c:8: error: internal compiler error
tccgen.c:7728: in init_assert(): initializer overflow
Sorry but it was supposed to be a private email.
I asked David if he thinks the latest FreeBSD patch is ready to be committed.
IMHO it clearly improves all FreeBSD ports.
Sorry again for this French message.
C.
-Original Message-
From: Christian Jullien [mailto:eli...@orange.fr]
Sent
Bonjour David,
Le dernier patch semble minimal et complet.
Comme tu en es à l'initiative, tu peux le pousser dans mob.
Si Grischka proteste, il n'avait qu'à réagir mais franchement, je ne vois pas
pourquoi il le ferait.
Bonne journée.
-Original Message-
From: Tinycc-devel
Important precision, I reproduce this issue with mob including on RPi arm32;
$ tcc foo.c
foo.c:8: error: internal compiler error
tccgen.c:7728: in init_assert(): initializer overflow
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
: [Tinycc-devel] Fwd: [PATCH] freebsd support update proposal
On 2/9/22 06:45, Christian Jullien wrote:
Hi Herman,
As just tested, your recent patch fixes the __Thread_local issue we have
otherwise with
I think, the two following patches proposed by David are also needed, wdyt?
diff
Hi Herman,
As just tested, your recent patch fixes the __Thread_local issue we have
otherwise with
I think, the two following patches proposed by David are also needed, wdyt?
diff --git a/include/tccdefs.h b/include/tccdefs.h
index 2d42bea..1bef382 100644
--- a/include/tccdefs.h
You can perhaps combine the best of the two world:
- compile with gcc and all optimizations (esp. avx512) the C module you want to
speedup
- compile all other modules with tcc and link them with tcc.
C.
-Original Message-
From: Tinycc-devel
An optimizer compiler need several pass to operate.
- constant folding
- register allocation
- peephole optimization
- branch prediction
...
When it knows the target it can reorganize code to keep as much as possible
data un L1 cache and have the longest series of instructions that can be
Hi, I speak only for myself.
I'm not sure tcc is the right target for you.
We all loved to have tcc generating fast code but the two main goals of tcc are
C compliance and FAST compilation code.
The price to pay its really fast compilation is that the generated code is poor
compared to gcc,
Thanks,
I like this one.
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of David CARLIER
Sent: Sunday, January 30, 2022 19:35
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] [PATCH] freebsd support update proposal
new
As a matter a style, I prefer to define BOUND_TID_TYPE and BOUND_GET_TIB for a
single system like:
diff --git a/lib/bcheck.c b/lib/bcheck.c
index 0379b6e..007b8c2 100644
--- a/lib/bcheck.c
+++ b/lib/bcheck.c
@@ -226,9 +226,12 @@ typedef struct alloca_list_struct {
#elif defined(__OpenBSD__)
Yes, that's the right page!
Back in 80's Tansputer had a big interest in community but a very limited
success.
There were efforts to port other languages (including Lisp, esp. Le-Lisp) but,
generally loosing parallelism.
Good luck porting tcc on it. IMHO, the main interest is working on
Hello David,
You should include only for FreeBSD (and possibly on other BSD*
like system if required).
Otherwise your patch looks good to me.
Please note that I'm not a tcc maintainer and I can't ask you to apply this
patch (or to NOT apply this patch).
The commit policy is far from clear to
I suggest you start with something simple:
A language that implement 4 arithmetic integer operations, has integer
variables, allows to define functions and includes print function as library
function.
Chose the syntax you like and start to write you own compiler that generate
intermediate
Hi David,
I think you can simplify your patch, using syscall as with other systems, with:
[jullien@freebsd64 ~/tinycc]$ git diff
diff --git a/lib/bcheck.c b/lib/bcheck.c
index 0379b6e..8dbb8be 100644
--- a/lib/bcheck.c
+++ b/lib/bcheck.c
@@ -226,9 +226,12 @@ typedef struct
Glad to know, thanks
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of Sandro
Sent: Monday, January 24, 2022 07:41
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Beginner issue when linking 7z LZMA SDK to dietlibc
Hello
Hum! What is precisely the issue?
First,
typedef double float_t;
is questionable, both VC++ and gcc protest with an error:
c:\usr\jullien\openlisp>cl test.c && test.exe
Microsoft (R) C/C++ Optimizing Compiler Version 19.30.30706 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
Hi are you using mob?
Tcc uses 0.9.27 for almost 4 years now, only mob is supported.
C
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of Sandro
Sent: Thursday, January 20, 2022 03:21
To: tinycc-devel@nongnu.org
Subject:
Hi, tcc port on Apple M1 is not too bad as long as you accept it generates code
for x86_64 which is then translated by rosetta.
That said, your problem is that tcc does not define __LITTLE_ENDIAN__ as gcc
does
jullien@mobley:~ $ tcc -dM -E - < /dev/null | grep END | sort
#define __BYTE_ORDER__
.
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of Steffen Nurpmeso
Sent: Tuesday, November 02, 2021 18:35
To: jull...@eligis.com
Cc: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] CFront for TinyCC?
Christian Jullien wrote
Hi Domingo,
This is very interesting but I wonder what it will be used for?
Stroustrup and others explicitly say that CFront should not be used for any
purpose except for historical research purpose:
http://www.softwarepreservation.org/projects/c_plus_plus/index.html#release_30
"The source code
So I'll probably not commit the patch.
From: Christian Jullien [mailto:eli...@orange.fr]
Sent: Friday, October 29, 2021 18:23
To: 'tinycc-devel@nongnu.org'
Subject: [macOS] Monterey patch
Hi,
Monterey/Xcode 13.1 changed the lib location
From
/Library/Developer/CommandLineTools/SDKs
Hi,
Monterey/Xcode 13.1 changed the lib location
From
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
To
/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/usr/lib
I think this patch allows to support any location SDKs/MacOSX*sdk
If it's Ok, I'll push it in few
/21 6:00, Christian Jullien wrote:
> Hi Domingo,
> Thank you for your attempt to make tcc better. However, please never commit
> huge changes like this without making a branch before **and** ask maintainers
> if they agree (I'm not a maintainer but an enthusiast user).
> So I stron
Hi Domingo,
Thank you for your attempt to make tcc better. However, please never commit
huge changes like this without making a branch before **and** ask maintainers
if they agree (I'm not a maintainer but an enthusiast user).
So I strongly suggest you revert your all changes as, among others,
instead. I haven't
looked at the proposal yet, though.
-tyge
On Sun, 17 Oct 2021 at 11:03, Christian Jullien wrote:
AFAIK, all stuff for complex is missing and the generic math macros are not
implemented
The type-generic macros are as follows:
fabs fabsf fabs fabsl
➢ I think any added C11 features should be welcome, C2X features are secondary,
imo unless it is low-hanging fruit and easy to implement.
I fully agree!!
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
posted it on this list I was met with
crickets, so I am not sure what else to do with it (aside from continuing to
use it for myself).
-E
On Thu, 14 Oct 2021, Christian Jullien wrote:
>
> I?m big fan of constexpr in C++ that allows compile time computations and
more code elimi
I'm big fan of constexpr in C++ that allows compile time computations and
more code elimination. I probably overuse constexpr in my code.
I'm not sure that the nature of tcc will find a big impact with constexpr
support.
There are many missing C11 features that should be handled before this one.
Hi,
I'm currently implementing Python called from OpenLisp.
When I detect Python link flags with ax_python_embed.m4 among other things,
it returns me "-Xlinker -export-dynamic" which tcc does not support.
As sed is my best friend, I can detect that I'm compiling with tcc and
remove them.
The nice thing with tcc is that it is fast . but also Tiny.
Once compiled it can be used on any Windows machine not bloated with
Gigabytes of memory like VC++, Cygwin or Mingw64.
A slow machine with limited hard disk memory becomes a very capable dev.
machine. I managed to port GNUmake with tcc
Outdated .def files
Christian Jullien wrote:
> Hi Grischka,
>
> I fact I processed differently. I was very disappointed to see that my
code
> compiled by tcc reported "Windows 10" on "Windows 11" because kernel32.def
> lacks the few API I recently added for this
ves more
choices.
C.
-Original Message-
From: grischka [mailto:gris...@gmx.de]
Sent: Saturday, September 18, 2021 14:06
To: jull...@eligis.com; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Outdated .def files
Christian Jullien wrote:
> Hi,
> If I regenerate a kernel32.def out of kernel32
need to be added, or at least considered.
- avih
On Saturday, September 18, 2021, 09:03:12 AM GMT+3, Christian Jullien
wrote:
Hi,
If I regenerate a kernel32.def out of kernel32.dll on my Windows 10 21H1
machine it is 3x times bigger that the one that currently comes with tcc. (see
Hi,
If I regenerate a kernel32.def out of kernel32.dll on my Windows 10 21H1
machine it is 3x times bigger that the one that currently comes with tcc.
(see enclosed)
It means many kernel32 API are not directly available for tcc.
It is probably the same with other .def files
What do
Hi,
On macOS, tcc has several limitations and it supports only x86_64 backend.
On M1, it works thanks to Rostetta translation.
You can compile tcc with a boostrapped tcc if you use –cpu=x86_64 ./configure
flag
I don’t think we are too far from a native arm64 backend as we have already
] 114_bound_signal error when tcc is compiled by tcc
on macOS M1, new -arch behavior
Christian Jullien wrote:
> Hi folks,
>
Hi Christian,
> gcc: error: this compiler does not support arm64 <= Sad
> Grischka, can you please reconsider this choice as it seems da
Hi,
Just tested on Debian riscv64,
./configure --cc=clang --prefix=/home/jullien/tinycc/static
Binary directory/home/jullien/tinycc/static/bin
TinyCC directory/home/jullien/tinycc/static/lib/tcc
Library directory /home/jullien/tinycc/static/lib
Include directory
Hi folks,
=1==
The last commit gives this error when tcc is bootstrapped with tcc on macOS
M1:
--- 114_bound_signal.expect 2021-08-04 07:25:22.0 +0200
+++ 114_bound_signal.output 2021-08-04 07:26:04.0 +0200
@@ -1,2 +1,3 @@
start
-end
+7fff2045b618 : at ???:
Same issue with Linux arm (RPi)
Le :01 août 2021 à 10:54 (GMT +02:00)
De :"Christian JULLIEN" eli...@orange.fr
À :"tinycc-devel@nongnu.org" tinycc-devel@nongnu.org
Objet :Re: [Tinycc-devel] -Werror=X (but ugly)
On macOS M1 (not yet fixed with long double), the latest c
On macOS M1 (not yet fixed with long double), the latest commit stalls on test
60
...60_errors_and_warnings ;; runs forever
Le :31 juillet 2021 à 22:45 (GMT +02:00)
De :"grischka" gris...@gmx.de
À :"tinycc-devel@nongnu.org" tinycc-devel@nongnu.org
Objet :Re: [Tinycc-devel] -Werror=X (but ugly)
Hi,
SushantPandurangi
Fix'unusedfunction'warningonnon-macOStargets
was the last commit that allowed to make a fully working tcc on macOS M1 (using
rosetta)
Next one "grischkamacos:yetanothertbdadjustment"
breaks the test suite (probably with double/long double)
It would be nice if someone
Hi,
In order to support tcc bootstrap with tcc on macOS, we'll need to add -arch
cpu option to tcc.It should at least support this option even if
nothing is implemented because -arch is now given on macOS because of this new
configure test:
Grischka, you last set of commits breaks macOS M1 port (see make -k test log in
attachment).
Do you test your macOS changes on a real M1 machine? If you like and if you
don't have a M1 machine, I'll be glad to test your patches before they go to
mob.Better if you create a macos-M1 branch to
Hi,
bt-exe now fails to compile on real M1 machine:
../tcc -c bt-exe.c -o ../bt-exe.o -B.. -I..bt-exe.c:15: error: ',' expected
(got "*")
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
-o bins?
On Thu, Jul 8, 2021 at 10:42 AM Christian Jullien eli...@orange.fr
wrote:
I’ve just pushed a patch so that configure now detects Darwin/arm64 and force a
x86_64 build on this platform.From: Tinycc-devel
[mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of
Christian Ju
1 - 100 of 824 matches
Mail list logo
