Re: [Tinycc-devel] tcc latest version and new glibc

[Christian Jullien]

+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 *** Re: [Tinycc-devel] tcc latest version and new glibc
Importance: High

 


Hi grischka.


Another case, where the latest release makes problems,
but current mob works.


You said and did nothing about releasing a 0.9.28 from current mob and prepare 
for a 1.0 release.

I already asked some month ago for a release.


You also said and did nothing to fix the link issue for i386-tcc on a 64 bit 
linux machine, which you introduced by reverting my patches.
(I did a fresh install of xubuntu 23.04, and the 32bit files are installed 
in /usr/i686-linux-gnu/include and /usr/i686-linux-gnu/lib,
but i have no idea, if there are still systems, 
which use /usr/i386-linux-gnu/* )


When you need some help, please let us know.


-- 
bye bye ... Detlef

Am 07.02.23, 01:41 schrieb Ziyao via Tinycc-devel :

On 2023-02-07 07:37, Fausto Saporito wrote: 
> Hello, 
> 
> I’m trying to build the latest version of TCC with glibc 2.34 and 
> __malloc_hook is not present anymore. 

> make[1]: Entering directory '/home/fausap/TC/tcc-0.9.27/lib' 

It seems that you are working on 0.9.27, which is a quite old version. 

You may try the latest commit on branch mob, which works fine for me. 

(I remember there used to be a plan for 1.0.0, btw) 

-- 
Ziyao 

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

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

Re: [Tinycc-devel] FWD: Can't build for riscv64 or arm64

[Christian Jullien]

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, sdt::numeric_limits and typeinfo (C++) 
return the same exact values for old and new names and are totally 
interchangeable.

IMHO, if tcc implements one day 128 bits, it should be with new name (+ a 
typedef for older names).

C. 

-Original Message-
From: tinycc-devel-bounces+eligis=orange...@nongnu.org 
[mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Detlef 
Riekenberg
Sent: Friday, February 03, 2023 19:11
To: tinycc-devel@nongnu.org
Subject: *** SPAM *** Re: [Tinycc-devel] FWD: Can't build for riscv64 or arm64

Hi Sagar

tcc has no support for 128bit int types.
__uint128_t
__int128_t


You might try with a replacement (typedef struct with 2x uint64)
This should be at least enough for the structsize for the typedef in signal.h,
but acessing the elements in the code you try to compile will propably fail

-- 
Bye bye ... Detlef


> When building lib/bt-exe.c , it imports ../tccrun.c
> Which throws error
> 
> /usr/include/bits/signal.h:14: error ';' expected (got "__uint128_t"
> 
> /usr/include/bits/signal.h is as follows:
> 
> typedef struct {
> __uint128_t vregs[32];
> unsigned int fpsr;
> unsigned int fpcr;



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


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

Re: [Tinycc-devel] Building for rv32

[Christian Jullien]

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 Herman 
ten Brugge via Tinycc-devel
Sent: Monday, January 16, 2023 08:51
To: tinycc-devel@nongnu.org
Cc: Herman ten Brugge
Subject: Re: [Tinycc-devel] Building for rv32

On 1/14/23 18:04, Sagar Acharya wrote:
> I do see rv64 code in tcc's repo.
>
> Can tcc also be built for rv32. There seem to be some variables pointing to 
> 32 bit within tcc files?
> Thanking you
> Sagar Acharya
>
Search the list for riscv32. I remember someone is working on this.

I also found:
https://www.reddit.com/r/RISCV/comments/o8vvuy/linux_for_riscv32/

I cannot find a linux/debian/bsd distribution that supports riscv32.
This makes it a little more difficult to support this.

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


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

Re: [Tinycc-devel] randomly failing tests

[Christian Jullien]

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 $@),,@echo "Please run ./configure." && exit 1)

 # run all tests
+SERIALIZE = -j1
+
 test:
-   @$(MAKE) -C tests
+   @$(MAKE) $(SERIALIZE) -C tests
 # run test(s) from tests2 subdir (see make help)
 tests2.%:
-   @$(MAKE) -C tests/tests2 $@
+   @$(MAKE) $(SERIALIZE) -C tests/tests2 $@

 testspp.%:
-   @$(MAKE) -C tests/pp $@
+   @$(MAKE) $(SERIALIZE) -C tests/pp $@

 clean:
@rm -f tcc$(EXESUF) tcc_p$(EXESUF) *-tcc$(EXESUF) tags ETAGS *.pod

-Original Message-
From: tinycc-devel-bounces+eligis=orange...@nongnu.org 
[mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Vincent 
Lefevre
Sent: Tuesday, December 27, 2022 12:29
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] randomly failing tests

On 2022-12-27 08:30:52 +0100, Herman ten Brugge via Tinycc-devel wrote:
> Are you using parallel build?

Yes, I have a shell function "make" that uses the -j option
(with the number of available cores).

> This does not work for the testsuite .

If this doesn't work for the testsuite, why not disabling the parallel
build of the testsuite?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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


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

[Tinycc-devel] Proposed new script to build universal tcc binary on macOS

[Christian Jullien]

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 - M1, M2...)

 

I would like to push this script named tcc-universal.sh that builds a
universal binary.

The main benefit is that it allows you to generate x86_64 from a Silicon
machine.

Other benefit is that the same tcc file can run on different architectures.

 

Running this script gives:

jullien@mobley:~/tinycc $ ../tcc-universal.sh

Building universal binary for x86_64 processor

./configure --cpu=x86_64 --config-codesign

Building universal binary for arm64 processor

./configure --cpu=arm64 --config-codesign

 

tcc universal binary has been built for x86_64 arm64

On Silicon CPU use:

  $ arch -x86_64 tcc ...   ## to generate code for x86_64

  $ arch -arm64  tcc ...   ## to generate code for arm64

  $ tcc ...## to generate code for default processor

 

Without arch prefix, it selects the CPU you're running on

tcc version 0.9.27 mob:676755f 2022-12-26T01:48:54+01:00 (x86_64 Darwin)

tcc version 0.9.27 mob:676755f 2022-12-26T01:48:54+01:00 (AArch64 Darwin)

 

Here is the proposed script, is it Ok to push?

 

#! /bin/sh

 

set -e

 

if test "`uname`-`uname -m`" != "Darwin-arm64"

then

  echo Making a universal binary is macOS feature only available on Silicon
processor>&2

  exit 1

fi

 

ARGS=$*

 

build() {

  echo Building universal binary for $1 processor

  make clean 2>&1

  echo ./configure --cpu=$1 --config-codesign $ARGS

  ./configure --cpu=$1 --config-codesign $ARGS > tcc-universal.log

 

  make -j $(sysctl -n hw.ncpu) >> tcc-universal.log 2>&1

  if test $? != 0

  then

cat tcc-universal.log

exit $?

  fi

  mv tcc tcc-universal-$1

}

 

build x86_64

build arm64

 

# Create universal build.

lipo -create -output tcc tcc-universal-x86_64 tcc-universal-arm64

rm -rf tcc-universal-x86_64 tcc-universal-arm64 tcc-universal.log

# verify

echo

echo tcc universal binary has been built for `lipo -archs tcc` CPU

echo "On Silicon CPU use:"

echo "  $ arch -x86_64 tcc ...   ## to generate code for x86_64"

echo "  $ arch -arm64  tcc ...   ## to generate code for arm64"

echo "  $ tcc ...## to generate code for default processor"

echo

echo "Without arch prefix, it selects the CPU you're running on"

 

arch -x86_64 ./tcc -v

arch -arm64 ./tcc -v

 

C.

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

Re: [Tinycc-devel] Do any flags avoid internal error: relocation failed?

[Christian Jullien]

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 *BSD platforms.


C.

-Original Message-
From: tinycc-devel-bounces+eligis=orange...@nongnu.org 
[mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Levo D
Sent: Saturday, December 24, 2022 06:38
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] Do any flags avoid internal error: relocation failed?

I'm playing around with tcc and seeing how many lines it can run per second

I tried a silly 2 million lined c file and it failed with "tcc: error: internal 
error: relocation failed". I tried using -c thinking I should run a tcc process 
for each of my cores however that doesn't increase the amount of code I can 
compile. Writing "tcc -nostdlib *.o" I get the same internal error. I was 
trying to find how much work I'll need to provide it to actually use a full 
second.

I really don't need a solution, I'm just fooling around. If there's a flag I 
can use to avoid this error I'll want to try it. I tried looking through 
https://man.cx/tcc(1) and didn't see anything obvious



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


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

Re: [Tinycc-devel] tcc binary instantly crashes on mac osx venture m2

[Christian Jullien]

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 a.out

Or passing codesign options more relevant for your needs

C.

-Original Message-
From: tinycc-devel-bounces+eligis=orange...@nongnu.org 
[mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Levo D
Sent: Monday, December 12, 2022 00:58
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] tcc binary instantly crashes on mac osx venture m2

Hi all. I'm on mac osx 13 ventura on an M2. Is there something I need to do 
besides the classic `./configure; make; make install`? Below is my hello world 
which runs if I execute with -run but instantly crashes if I run from a binary. 
I'm using the latest git which is 079692016ded4eed1119eb9b8b7996629d2179f5. I 
looked into release_0_9_27 but that from 2017 which is several years before the 
M1 let alone M2 and ventura

a.c

#include 
int main() {
puts("Hello");
return 0;
}


In bash

$ ./tcc a.c -run
Hello

$ ./tcc a.c; ./a.out; echo $?
Killed: 9
137

$ tcc a.c; ./a.out; echo $?
Killed: 9
137


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


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

Re: [Tinycc-devel] apple support

[Christian Jullien]

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 mod should be fine now.

It's a very good thing to have a CI for this project. Thanks.

Christian

-Original Message-
From: tinycc-devel-bounces+eligis=orange...@nongnu.org 
[mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Vlad 
Vissoultchev
Sent: Friday, December 02, 2022 13:54
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] apple support

Can you check out why github CI is failing osx/amd64 tests

https://github.com/TinyCC/tinycc/actions/runs/3587141614/jobs/6037151088

The tests are running under  macOS  11.7.1  20G918 (not latest)

This happened after commit Add debug support to macos

https://github.com/TinyCC/tinycc/commit/62096265ed62eb07144bed0dd9c038e03abdf30f

cheers,



-Original Message-
From: tinycc-devel-bounces+wqweto=gmail@nongnu.org 
[mailto:tinycc-devel-bounces+wqweto=gmail@nongnu.org] On Behalf Of Herman 
ten Brugge via Tinycc-devel
Sent: Friday, November 25, 2022 3:08 PM
To: tinycc-devel 
Cc: Herman ten Brugge 
Subject: [Tinycc-devel] apple support

I recently added code to allow the apple m1 to work.

First I implemented the older apple code with position independent 
executables(pie).
After that I implemented the newer macos code.

The old code is the default.
The new code can be selected with configure option '--config-new_macho'.
I suspect that after some time the old code is not needed any more because 
every one has swicthed to the new code and then the old code and this option 
can be removed.

For support of apple 13.0 (Ventura) I needed to add another option 
'--config-codesign'.
This was needed because on this target executables needs to be signed.
This is done by running 'codesign -f -s - executeble' after it is created.

The code now runs fine at least on x86_64(10.6, 13.0) and arm64(12.3,13.0).





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


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


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

Re: [Tinycc-devel] tcc -v with mob date?

[Christian Jullien]

Hi, there are many ways to compile tcc on Windows.

Personally, I use Cygwin and gcc with this Makefile I wrote

http://svn.code.sf.net/p/wintcc/svn/cygwin/Makefile

 

It is more a shell script than a true Makefile (a mix of) but what I like with 
this way to build tcc is that it builds –m32/-m64 using 3 stages.

 

/cygdrive/f/tinycc/win32 $ make

# Stage 1

stage1: Bootstrapping 32bits and 64bits tools with gcc -m64

stage1: Building lib32 with tcc -m32

stage1: Building lib64 with tcc -m64

# Stage 2

stage2: Rebuild using tcc itself - default 64bits

stage2: Building lib32 with tcc -m32

stage2: Building lib64 with tcc -m64

# Stage 3

stage3: Rebuild using tcc itself - default 64bits

stage3: Building lib32 with tcc -m32

stage3: Building lib64 with tcc -m64

# Build is OK: stage2 == stage3

/cygdrive/f/tinycc/win32 $ ./tcc -v

tcc version 0.9.27 mob:702b802 2022-12-01T10:03:56+01:00 (x86_64 Windows)

 

I don’t know how you build tcc with BusyBox but you’ll probably have to add a 
patch similar to mine (somewhere)

 

Note that I only proposed a patch to maintainers but I’m glad someone took the 
responsibility to push it on mob (even if it is not the last and more accurate 
version of my patch).

 

IMHO, as tcc seems to be stuck forever to 0.9.27, having mod hash and date is 
not an option.

 

C.

 

From: tinycc-devel-bounces+eligis=orange...@nongnu.org 
[mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Antoni 
Gual Via
Sent: Thursday, December 01, 2022 21:43
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] tcc -v with mob date?

 

I think the patch is a great idea but...

I have just compiled tcc for Windows from the last snapshot, using Dimitri's 
BusyBox. Tcc's file date has updated to today's and I have tried the asm 
instruction popcnt and the strtoull function . Both work correctly. But to my 
surprise tcc -v does'nt give a clue about the snapshot version. 

I know Christian's patch is not yet included in the snapshot (it's too soon..) 
and i can't have yet the user readable version format. What i see is not even 
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 Message-
From: tinycc-devel-bounces+eligis=orange...@nongnu.org 
[mailto:tinycc-devel-bounces+eligis <mailto:tinycc-devel-bounces%2Beligis> 
=orange...@nongnu.org] On Behalf Of Christian Jullien
Sent: Wednesday, November 30, 2022 07:26
To: jull...@eligis.com; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] tcc -v with mob date?

This one is simpler and gives better info

jullien@mobley:~/tinycc $ git diff
diff --git a/Makefile b/Makefile
index efe0885..7543962 100644
--- a/Makefile
+++ b/Makefile
@@ -241,9 +241,12 @@ $(TCC_FILES) : DEFINES += -DONE_SOURCE=0
 $(X)tccpp.o : $(TCCDEFS_H)
 endif

-GITHASH := $(shell git rev-parse >/dev/null 2>&1 && git rev-parse --short HEAD 
|| echo no)
-ifneq ($(GITHASH),no)
-DEF_GITHASH := -DTCC_GITHASH="\"$(shell git rev-parse --abbrev-ref 
HEAD):$(GITHASH)$(shell git diff --quiet || echo '-mod')\""
+FROM_GIT := $(shell git rev-parse >/dev/null 2>&1 && echo yes || echo no)
+
+ifeq ($(FROM_GIT),yes)
+GITHASH:=$(shell git rev-parse --abbrev-ref HEAD):$(shell git rev-parse 
--short HEAD) $(shell git log -1 --pretty='format:%cI')
+GITHASH+=$(shell git diff --quiet || echo locally modified)
+DEF_GITHASH := -DTCC_GITHASH="\"$(GITHASH)\""
 endif

 ifeq ($(CONFIG_debug),yes)


For example, with this uncommitted patch, it gives:

jullien@mobley:~/tinycc $ ./tcc -v
tcc version 0.9.27 mob:ac0604a 2022-11-29T21:13:20+01:00 locally modified 
(AArch64 Darwin)

C.

-Original Message-
From: tinycc-devel-bounces+eligis=orange...@nongnu.org 
[mailto:tinycc-devel-bounces+eligis <mailto:tinycc-devel-bounces%2Beligis> 
=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 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)

Maintainers, can you please apply a patch similar to this one?

jullien@sims4:~/tinycc $ git diff
diff --git a/Makefile b/Makefile
index efe0885..6377570 100644
--- a/Makefile
+++ b/Makefile
@@ -243,7 +243,12 @@ endif

 GITHASH := $(shell git rev-parse >/dev/null 2>&1 && git rev-parse --short HEAD 
|| echo no)
 ifneq ($(GITHASH),no)
-DEF_GITHASH := -DTCC_GITHASH="\"$(shell git rev-parse --abbrev-ref 
HEAD):$(GITHASH)$(shell git diff --quiet

Re: [Tinycc-devel] tcc -v with mob date?

[Christian Jullien]

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; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] tcc -v with mob date?

This one is simpler and gives better info

jullien@mobley:~/tinycc $ git diff
diff --git a/Makefile b/Makefile
index efe0885..7543962 100644
--- a/Makefile
+++ b/Makefile
@@ -241,9 +241,12 @@ $(TCC_FILES) : DEFINES += -DONE_SOURCE=0
 $(X)tccpp.o : $(TCCDEFS_H)
 endif

-GITHASH := $(shell git rev-parse >/dev/null 2>&1 && git rev-parse --short HEAD 
|| echo no)
-ifneq ($(GITHASH),no)
-DEF_GITHASH := -DTCC_GITHASH="\"$(shell git rev-parse --abbrev-ref 
HEAD):$(GITHASH)$(shell git diff --quiet || echo '-mod')\""
+FROM_GIT := $(shell git rev-parse >/dev/null 2>&1 && echo yes || echo no)
+
+ifeq ($(FROM_GIT),yes)
+GITHASH:=$(shell git rev-parse --abbrev-ref HEAD):$(shell git rev-parse 
--short HEAD) $(shell git log -1 --pretty='format:%cI')
+GITHASH+=$(shell git diff --quiet || echo locally modified)
+DEF_GITHASH := -DTCC_GITHASH="\"$(GITHASH)\""
 endif

 ifeq ($(CONFIG_debug),yes)


For example, with this uncommitted patch, it gives:

jullien@mobley:~/tinycc $ ./tcc -v
tcc version 0.9.27 mob:ac0604a 2022-11-29T21:13:20+01:00 locally modified 
(AArch64 Darwin)

C.

-Original Message-
From: tinycc-devel-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 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)

Maintainers, can you please apply a patch similar to this one?

jullien@sims4:~/tinycc $ git diff
diff --git a/Makefile b/Makefile
index efe0885..6377570 100644
--- a/Makefile
+++ b/Makefile
@@ -243,7 +243,12 @@ endif

 GITHASH := $(shell git rev-parse >/dev/null 2>&1 && git rev-parse --short HEAD 
|| echo no)
 ifneq ($(GITHASH),no)
-DEF_GITHASH := -DTCC_GITHASH="\"$(shell git rev-parse --abbrev-ref 
HEAD):$(GITHASH)$(shell git diff --quiet || echo '-mod')\""
+DEF_GITHASH := -DTCC_GITHASH="\"$(shell git rev-parse --abbrev-ref 
HEAD):$(GITHASH)$(shell git diff --quiet || echo '-modified')\""
+endif
+
+GITDATE := $(shell git log -1 >/dev/null 2>&1 && git log -1 
--pretty='format:%cI' || echo no)
+ifneq ($(GITDATE),no)
+DEF_GITDATE := -DTCC_GITDATE="\"$(shell git log -1 --pretty='format:%cI')\""
 endif

 ifeq ($(CONFIG_debug),yes)
@@ -265,7 +270,7 @@ $(X)%.o : %.c $(LIBTCC_INC)

 # additional dependencies
 $(X)tcc.o : tcctools.c
-$(X)tcc.o : DEFINES += $(DEF_GITHASH)
+$(X)tcc.o : DEFINES += $(DEF_GITHASH) $(DEF_GITDATE)

 # Host Tiny C Compiler
 tcc$(EXESUF): tcc.o $(LIBTCC)
diff --git a/tcc.c b/tcc.c
index beef6fb..da460cf 100644
--- a/tcc.c
+++ b/tcc.c
@@ -155,6 +155,9 @@ static const char version[] =
 "tcc version "TCC_VERSION
 #ifdef TCC_GITHASH
 " "TCC_GITHASH
+#endif
+#ifdef TCC_GITDATE
+" on "TCC_GITDATE
 #endif
 " ("
 #ifdef TCC_TARGET_I386


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


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
diff --git a/Makefile b/Makefile
index efe0885..7543962 100644
--- a/Makefile
+++ b/Makefile
@@ -241,9 +241,12 @@ $(TCC_FILES) : DEFINES += -DONE_SOURCE=0
 $(X)tccpp.o : $(TCCDEFS_H)
 endif
 
-GITHASH := $(shell git rev-parse >/dev/null 2>&1 && git rev-parse --short HEAD 
|| echo no)
-ifneq ($(GITHASH),no)
-DEF_GITHASH := -DTCC_GITHASH="\"$(shell git rev-parse --abbrev-ref 
HEAD):$(GITHASH)$(shell git diff --quiet || echo '-mod')\""
+FROM_GIT := $(shell git rev-parse >/dev/null 2>&1 && echo yes || echo no)
+
+ifeq ($(FROM_GIT),yes)
+GITHASH:=$(shell git rev-parse --abbrev-ref HEAD):$(shell git rev-parse 
--short HEAD) $(shell git log -1 --pretty='format:%cI')
+GITHASH+=$(shell git diff --quiet || echo locally modified)
+DEF_GITHASH := -DTCC_GITHASH="\"$(GITHASH)\""
 endif
 
 ifeq ($(CONFIG_debug),yes)
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tcc -v with mob date?

[Christian Jullien]

This one is simpler and gives better info

jullien@mobley:~/tinycc $ git diff
diff --git a/Makefile b/Makefile
index efe0885..7543962 100644
--- a/Makefile
+++ b/Makefile
@@ -241,9 +241,12 @@ $(TCC_FILES) : DEFINES += -DONE_SOURCE=0
 $(X)tccpp.o : $(TCCDEFS_H)
 endif

-GITHASH := $(shell git rev-parse >/dev/null 2>&1 && git rev-parse --short HEAD 
|| echo no)
-ifneq ($(GITHASH),no)
-DEF_GITHASH := -DTCC_GITHASH="\"$(shell git rev-parse --abbrev-ref 
HEAD):$(GITHASH)$(shell git diff --quiet || echo '-mod')\""
+FROM_GIT := $(shell git rev-parse >/dev/null 2>&1 && echo yes || echo no)
+
+ifeq ($(FROM_GIT),yes)
+GITHASH:=$(shell git rev-parse --abbrev-ref HEAD):$(shell git rev-parse 
--short HEAD) $(shell git log -1 --pretty='format:%cI')
+GITHASH+=$(shell git diff --quiet || echo locally modified)
+DEF_GITHASH := -DTCC_GITHASH="\"$(GITHASH)\""
 endif

 ifeq ($(CONFIG_debug),yes)


For example, with this uncommitted patch, it gives:

jullien@mobley:~/tinycc $ ./tcc -v
tcc version 0.9.27 mob:ac0604a 2022-11-29T21:13:20+01:00 locally modified 
(AArch64 Darwin)

C.

-Original Message-
From: tinycc-devel-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 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)

Maintainers, can you please apply a patch similar to this one?

jullien@sims4:~/tinycc $ git diff
diff --git a/Makefile b/Makefile
index efe0885..6377570 100644
--- a/Makefile
+++ b/Makefile
@@ -243,7 +243,12 @@ endif

 GITHASH := $(shell git rev-parse >/dev/null 2>&1 && git rev-parse --short HEAD 
|| echo no)
 ifneq ($(GITHASH),no)
-DEF_GITHASH := -DTCC_GITHASH="\"$(shell git rev-parse --abbrev-ref 
HEAD):$(GITHASH)$(shell git diff --quiet || echo '-mod')\""
+DEF_GITHASH := -DTCC_GITHASH="\"$(shell git rev-parse --abbrev-ref 
HEAD):$(GITHASH)$(shell git diff --quiet || echo '-modified')\""
+endif
+
+GITDATE := $(shell git log -1 >/dev/null 2>&1 && git log -1 
--pretty='format:%cI' || echo no)
+ifneq ($(GITDATE),no)
+DEF_GITDATE := -DTCC_GITDATE="\"$(shell git log -1 --pretty='format:%cI')\""
 endif

 ifeq ($(CONFIG_debug),yes)
@@ -265,7 +270,7 @@ $(X)%.o : %.c $(LIBTCC_INC)

 # additional dependencies
 $(X)tcc.o : tcctools.c
-$(X)tcc.o : DEFINES += $(DEF_GITHASH)
+$(X)tcc.o : DEFINES += $(DEF_GITHASH) $(DEF_GITDATE)

 # Host Tiny C Compiler
 tcc$(EXESUF): tcc.o $(LIBTCC)
diff --git a/tcc.c b/tcc.c
index beef6fb..da460cf 100644
--- a/tcc.c
+++ b/tcc.c
@@ -155,6 +155,9 @@ static const char version[] =
 "tcc version "TCC_VERSION
 #ifdef TCC_GITHASH
 " "TCC_GITHASH
+#endif
+#ifdef TCC_GITDATE
+" on "TCC_GITDATE
 #endif
 " ("
 #ifdef TCC_TARGET_I386


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


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

[Tinycc-devel] tcc -v with mob date?

[Christian Jullien]

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)

Maintainers, can you please apply a patch similar to this one?

jullien@sims4:~/tinycc $ git diff
diff --git a/Makefile b/Makefile
index efe0885..6377570 100644
--- a/Makefile
+++ b/Makefile
@@ -243,7 +243,12 @@ endif

 GITHASH := $(shell git rev-parse >/dev/null 2>&1 && git rev-parse --short HEAD 
|| echo no)
 ifneq ($(GITHASH),no)
-DEF_GITHASH := -DTCC_GITHASH="\"$(shell git rev-parse --abbrev-ref 
HEAD):$(GITHASH)$(shell git diff --quiet || echo '-mod')\""
+DEF_GITHASH := -DTCC_GITHASH="\"$(shell git rev-parse --abbrev-ref 
HEAD):$(GITHASH)$(shell git diff --quiet || echo '-modified')\""
+endif
+
+GITDATE := $(shell git log -1 >/dev/null 2>&1 && git log -1 
--pretty='format:%cI' || echo no)
+ifneq ($(GITDATE),no)
+DEF_GITDATE := -DTCC_GITDATE="\"$(shell git log -1 --pretty='format:%cI')\""
 endif

 ifeq ($(CONFIG_debug),yes)
@@ -265,7 +270,7 @@ $(X)%.o : %.c $(LIBTCC_INC)

 # additional dependencies
 $(X)tcc.o : tcctools.c
-$(X)tcc.o : DEFINES += $(DEF_GITHASH)
+$(X)tcc.o : DEFINES += $(DEF_GITHASH) $(DEF_GITDATE)

 # Host Tiny C Compiler
 tcc$(EXESUF): tcc.o $(LIBTCC)
diff --git a/tcc.c b/tcc.c
index beef6fb..da460cf 100644
--- a/tcc.c
+++ b/tcc.c
@@ -155,6 +155,9 @@ static const char version[] =
 "tcc version "TCC_VERSION
 #ifdef TCC_GITHASH
 " "TCC_GITHASH
+#endif
+#ifdef TCC_GITDATE
+" on "TCC_GITDATE
 #endif
 " ("
 #ifdef TCC_TARGET_I386


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

Re: [Tinycc-devel] apple support

[Christian Jullien]

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 
differences between x86_64+Rosetta or native arm64.

I tested Herman's commit with the 5 following config on my Ventura M1, no error 
at all running the test suite!! This is rock solid

./configure --cpu=x86_64 --dwarf=5 --config-new_macho --config-codesign 
--cc=clang --prefix=/usr/local
./configure --cpu=x86_64 --dwarf=5 --config-new_macho --config-codesign 
--cc=clang --disable-static --prefix=/Users/jullien/tinycc/shared
./configure --dwarf=5 --config-new_macho --config-codesign --cc=clang 
--prefix=/usr/local
./configure --dwarf=5 --config-new_macho --config-codesign --cc=clang 
--disable-static --prefix=/Users/jullien/tinycc/shared
./configure --dwarf=5 --config-new_macho --config-codesign --cc=tcc 
--prefix=/Users/jullien/tinycc/static

I would like to give * (five starts) to Herman.

Christian

-Original Message-
From: tinycc-devel-bounces+eligis=orange...@nongnu.org 
[mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Herman 
ten Brugge via Tinycc-devel
Sent: Friday, November 25, 2022 14:08
To: tinycc-devel
Cc: Herman ten Brugge
Subject: [Tinycc-devel] apple support

I recently added code to allow the apple m1 to work.

First I implemented the older apple code with position independent 
executables(pie).
After that I implemented the newer macos code.

The old code is the default.
The new code can be selected with configure option '--config-new_macho'.
I suspect that after some time the old code is not needed any more because
every one has swicthed to the new code and then the old code and this
option can be removed.

For support of apple 13.0 (Ventura) I needed to add another option 
'--config-codesign'.
This was needed because on this target executables needs to be signed.
This is done by running 'codesign -f -s - executeble' after it is created.

The code now runs fine at least on x86_64(10.6, 13.0) and arm64(12.3,13.0).





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


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

Re: [Tinycc-devel] clang 15.0 issue with tcctest.c

[Christian JULLIEN]

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 15.0 issue with tcctest.c

Hello,


On Thu, 17 Nov 2022, Christian Jullien wrote:

> Test later fails with
> 
> tcctest.c:2903:17: error: incompatible pointer to integer conversion passing
> 'void *' to parameter of type 'int' [-Wint-conversion]
> 
>     old_style_f((void *)1, 2, 3.0);
> 
>     ^

So, this is a warning promoted to an error with recent clang.  We try to 
avoid such compatibility warnings explicitely (by compiling with -w), but 
clang doesn't heed this request anymore.

The warning here is a bit on the border because this is an old style 
function definition, and parameter types are not compared for calls to 
such functions (though the call will be undefined behaviour if the types 
aren't compatible, which is indeed the case here, so a warning is somewhat 
justified).

Can clang15 at least be convinced to not warn (and hence error out) here 
with -Wno-int-conversion?  If so that would be the solution.  If not, we 
have a problem, because tcc _wants_ to support exactly this situation 
(until we decide that we don't, then we need to adjust the testcase).


Ciao,
Michael.

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

[Tinycc-devel] clang 15.0 issue with tcctest.c

[Christian Jullien]

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

TinyCC directory/home/jullien/tinycc/static/lib/tcc

Library directory   /home/jullien/tinycc/static/lib

Include directory   /home/jullien/tinycc/static/include

Manual directory/home/jullien/tinycc/static/share/man

Info directory  /home/jullien/tinycc/static/share/info

Doc directory   /home/jullien/tinycc/static/share/doc

Source path /home/jullien/tinycc

C compiler  clang (15.0)

Target OS   Linux

CPU x86_64

Config  selinux

Creating config.mak and config.h

 

Test later fails with

 

tcctest.c:2903:17: error: incompatible pointer to integer conversion passing
'void *' to parameter of type 'int' [-Wint-conversion]

old_style_f((void *)1, 2, 3.0);

^

1 error generated.

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

Re: [Tinycc-devel] GNUmake v4.4 port on Windows with tcc

[Christian Jullien]

Hi, I've pushed strto[u]ll patch for Windows on tcc mob.
With no surprises, the official v4.4 version builds now ROOTB with tcc mob.

Thank you for your support.

Christian

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-boun...@nongnu.org] On Behalf Of Eli 
Zaretskii
Sent: 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, 5 Nov 2022 17:03:44 +0100
> 
> 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 strtoull to _strtoui64
>  *
>  * strtoull does not properly map in Windows; this is needed to ensure calls 
> to
>  * strtoull(const char *nptr, char **endptr, int base) will compile in 
> Windows.
>  */
> #define strtoull _strtoui64
> 
> So, probably we'll do the same for tcc.

When you do, please tell, and we will fix config.h at that time.

Thanks.

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


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

Re: [Tinycc-devel] strto[u]ll: Do you allow me to apply this patch?

[Christian Jullien]

As no one protested, accepted or even commented, I pushed a patch. Hope it’s
Ok

 

See:
https://repo.or.cz/tinycc.git/commitdiff/40f01478d82a3dc225c3299062741fc36cb
e2b56

 

Now, whether it is compiled with –m32 or -m64 on Windows, this sample gives
the same expected result:

 

c:\tmp>tcc -m32 foo.c -o foo.exe && foo

1 8

1 8

 

c:\tmp>tcc -m64 foo.c -o foo.exe && foo

1 8

1 8

 

c:\tmp>more foo.c

#include 

#include 

#include 

 

int

main() {

long long x = strtoll("0x1", NULL, 0);

printf("%llx %d\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 Behalf Of
Christian Jullien
Sent: Sunday, November 06, 2022 09:43
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] strto[u]ll: Do you allow me to apply this patch?

 

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 +65,7 @@ extern long double strtold (const char *__nptr, char
**__endptr);

# ifndef __GNUC__

#  define strtold (long double)strtod

#  define strtof (float)strtod

-#  ifdef _WIN64

+#  ifdef _WIN32

#   define strtoll _strtoi64

#   define strtoull _strtoui64

#  else

diff --git a/win32/include/stdlib.h b/win32/include/stdlib.h

index 033c0fd..671772c 100644

--- a/win32/include/stdlib.h

+++ b/win32/include/stdlib.h

@@ -544,8 +544,18 @@ extern "C" {

 

   __CRT_INLINE long long __cdecl llabs(long long _j) { return (_j >= 0 ? _j
: -_j); }

 

+  /* stro[u]ll do not properly map in Windows; use macros as with VC++ does
*/

+#if !defined(strtoll)

+#define strtoll _strtoi64

+#endif

+#if !defined(strtoull)

+#define strtoull _strtoui64

+#endif

+

+/*

   long long  __cdecl strtoll(const char* __restrict__, char** __restrict,
int);

   unsigned long long  __cdecl strtoull(const char* __restrict__, char**
__restrict__, int);

+*/

 

   /* these are stubs for MS _i64 versions */

   long long  __cdecl atoll (const char *);

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

[Tinycc-devel] strto[u]ll: Do you allow me to apply this patch?

[Christian Jullien]

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 +65,7 @@ extern long double strtold (const char *__nptr, char
**__endptr);

# ifndef __GNUC__

#  define strtold (long double)strtod

#  define strtof (float)strtod

-#  ifdef _WIN64

+#  ifdef _WIN32

#   define strtoll _strtoi64

#   define strtoull _strtoui64

#  else

diff --git a/win32/include/stdlib.h b/win32/include/stdlib.h

index 033c0fd..671772c 100644

--- a/win32/include/stdlib.h

+++ b/win32/include/stdlib.h

@@ -544,8 +544,18 @@ extern "C" {

 

   __CRT_INLINE long long __cdecl llabs(long long _j) { return (_j >= 0 ? _j
: -_j); }

 

+  /* stro[u]ll do not properly map in Windows; use macros as with VC++ does
*/

+#if !defined(strtoll)

+#define strtoll _strtoi64

+#endif

+#if !defined(strtoull)

+#define strtoull _strtoui64

+#endif

+

+/*

   long long  __cdecl strtoll(const char* __restrict__, char** __restrict,
int);

   unsigned long long  __cdecl strtoull(const char* __restrict__, char**
__restrict__, int);

+*/

 

   /* these are stubs for MS _i64 versions */

   long long  __cdecl atoll (const char *);

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

Re: [Tinycc-devel] GNUmake v4.4 port on Windows with tcc

[Christian Jullien]

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 strtoull to _strtoui64
 *
 * strtoull does not properly map in Windows; this is needed to ensure calls to
 * strtoull(const char *nptr, char **endptr, int base) will compile in Windows.
 */
#define strtoull _strtoui64

So, probably we'll do the same for tcc.

I suggest you check if those macros are not already defined as I hope they'll 
soon be defined that way in tcc stdlib.h

#ifdef __TINYC__
#if !defined(strtoll)
#define strtoll _strtoi64
#endif
#if !defined(strtoull)
#define strtoull _strtoui64
#endif
#endif

C.

-Original Message-
From: Eli Zaretskii [mailto:e...@gnu.org] 
Sent: Saturday, November 05, 2022 15:49
To: psm...@gnu.org
Cc: jull...@eligis.com; make-...@gnu.org; tinycc-devel@nongnu.org
Subject: Re: GNUmake v4.4 port on Windows with tcc

> From: Paul Smith 
> Cc: make-...@gnu.org, tinycc-devel@nongnu.org
> Date: Sat, 05 Nov 2022 10:18:55 -0400
> 
> On Thu, 2022-11-03 at 16:45 +0200, Eli Zaretskii wrote:
> > > Of course it does.
> > 
> > Thanks.  Paul, should I install this?
> 
> Yes please thanks!

Done.


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

[Tinycc-devel] Windows C99 missing functions: strtoll and strtoull

[Christian Jullien]

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 msvcrt.dll | grep strto | grep -v _

strtod

strtok

strtok_s

strtol

strtoul

 

It is however found in ucrtbase.dll which exists since Windows 10

 

c:\Windows\System32>strings ucrtbase.dll | grep strto | grep -v _

strtod

strtof

strtoimax

strtok

strtol

strtold

strtoll

strtoul

strtoull

strtoumax

 

What is the correct way to support strtoll and strtoull C99 functions on
Windows?

 

#define strtoll stroi64

#define strtoull stroui64

 

Or perhaps a static inline definitions in stdlib.h like:

static long long  __cdecl strtoll(const char* __restrict__ str, char**
__restrict endptr, int base) {

return strtoi64(str, endptr, base);

}

 

would do for x64 port

 

I still can't understand how VisualC++ can find strtoll as it uses the same
dll (with missing strto[u]ll definitions)

c:\usr\jullien\openlisp>ldd foo.exe

ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff8c65f)

KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
(0x7ff8c4c3)

KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
(0x7ff8c3e2)

 

Probably because mapping.h defines:

 

/**

* 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 strtoull to _strtoui64

*

* strtoull does not properly map in Windows; this is needed to ensure calls
to

* strtoull(const char *nptr, char **endptr, int base) will compile in
Windows.

*/

#define strtoull _strtoui64

 

 

Fix is welcome.

 

 

 

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

Re: [Tinycc-devel] GNUmake v4.4 port on Windows with tcc

[Christian Jullien]

Hi Eli, you've read too fast, the warnings are with cl (Visual C++ if you
prefer), esp. when compiled with 64bit mode.

-Original Message-
From: Eli Zaretskii [mailto:e...@gnu.org] 
Sent: Thursday, November 03, 2022 15:45
To: jull...@eligis.com
Cc: psm...@gnu.org; make-...@gnu.org; tinycc-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 x64 gives the following warnings

The "size_t to int" warnings are about EINTRLOOP, so I'll let Paul
worry about that, since there could be no loops on Windows.

The other warnings are in places where there are too many
system-dependent ifdef's for messing with them without a compiler
available for testing.  So either you suggest more ifdef's to take
care of those warnings, or Tiny C users will have to live with them.


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

Re: [Tinycc-devel] GNUmake v4.4 port on Windows with tcc

[Christian Jullien]

Of course it does.
I considered this solution but I was reluctant to ask you to change the
source because tcc currently lacks C99 strto[u]ll
That's why I moved the patch to build_w32.bat script
I let you decide what is the best for GNUmake. Both patches work equally
well

As side note, compiling GNUmake with cl x64 gives the following warnings

- Compiling src/ar.c
ar.c
- Compiling src/arscan.c
arscan.c
- Compiling src/commands.c
commands.c
- Compiling src/default.c
default.c
- Compiling src/dir.c
dir.c
- Compiling src/expand.c
expand.c
- Compiling src/file.c
file.c
- Compiling src/function.c
function.c
src/function.c(1959): warning C4267: 'function': conversion from 'size_t' to
'unsigned int', possible loss of data
- Compiling src/getopt.c
getopt.c
- Compiling src/getopt1.c
getopt1.c
- Compiling src/guile.c
guile.c
- Compiling src/hash.c
hash.c
- Compiling src/implicit.c
implicit.c
- Compiling src/job.c
job.c
F:\wintcc\make-4.4\src\job.c(898) : warning C4701: potentially uninitialized
local variable 'exit_sig' used
F:\wintcc\make-4.4\src\job.c(993) : warning C4701: potentially uninitialized
local variable 'coredump' used
F:\wintcc\make-4.4\src\job.c(898) : warning C4701: potentially uninitialized
local variable 'exit_code' used
- Compiling src/load.c
load.c
- Compiling src/loadapi.c
loadapi.c
- Compiling src/main.c
main.c
- Compiling src/misc.c
misc.c
src/misc.c(431): warning C4267: 'function': conversion from 'size_t' to
'unsigned int', possible loss of data
src/misc.c(453): warning C4267: 'function': conversion from 'size_t' to
'unsigned int', possible loss of data
src/misc.c(737): warning C4101: 'err': unreferenced local variable
F:\wintcc\make-4.4\src\misc.c(594) : warning C4706: assignment within
conditional expression
- Compiling src/output.c
output.c
- Compiling src/read.c
read.c
F:\wintcc\make-4.4\src\read.c(2134) : warning C4701: potentially
uninitialized local variable 'cmds' used
F:\wintcc\make-4.4\src\read.c(2134) : warning C4703: potentially
uninitialized local pointer variable 'cmds' used
- Compiling src/remake.c
remake.c
- Compiling src/remote-stub.c
remote-stub.c
- Compiling src/rule.c
rule.c
- Compiling src/shuffle.c
shuffle.c
- Compiling src/signame.c
signame.c
- Compiling src/strcache.c
strcache.c
- Compiling src/variable.c
variable.c
F:\wintcc\make-4.4\src\variable.c(1810) : warning C4701: potentially
uninitialized local variable 'origin' used
F:\wintcc\make-4.4\src\variable.c(1810) : warning C4703: potentially
uninitialized local pointer variable 'origin' used
- Compiling src/version.c
version.c
- Compiling src/vpath.c
vpath.c
- Compiling src/w32/pathstuff.c
pathstuff.c
- Compiling src/w32/w32os.c
w32os.c
- Compiling src/w32/compat/posixfcn.c
posixfcn.c
- Compiling src/w32/subproc/misc.c
misc.c
- Compiling src/w32/subproc/sub_proc.c
sub_proc.c


-Original Message-
From: Eli Zaretskii [mailto:e...@gnu.org] 
Sent: Thursday, November 03, 2022 14:50
To: jull...@eligis.com; psm...@gnu.org
Cc: make-...@gnu.org; tinycc-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 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
> > 
> > call %COMPILER% -mthreads -Wall -std=c11 %OPTS% -I%OUTDIR%/src -
> > I./src
> > -I%OUTDIR%/lib -I./lib -I./src/w32/include -D_cdecl= -
> > Dstrtoull=_strtoui64
> > -Dstrtoll=_strtoi64 -D_MSC_VER -DHAVE_CONFIG_H %EXTRAS% -o
> > %OUTDIR%/%1.%O%
> > -c %1.c
> > 
> > Hope it helps.
> 
> Thanks for that note.  We will choose a different way to address this I
> expect but it's good to know there's a problem.

Christian, does the below fix the problem?

--- src/config.h.W32~0  2022-10-23 17:52:32.0 +0300
+++ src/config.h.W322022-11-03 15:47:14.46850 +0200
@@ -343,6 +343,10 @@ this program.  If not, see <https://www.
 /* #undef HAVE_STRSIGNAL */
 
 /* Define to 1 if you have the `strtoll' function. */
+#ifdef __TINYC__
+#define strtoll _strtoi64
+#define strtoull _strtoui64
+#endif
 #define HAVE_STRTOLL 1
 
 /* Define to 1 if `d_type' is a member of `struct dirent'. */


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

Re: [Tinycc-devel] GNUmake v4.4 port on Windows with tcc

[Christian Jullien]

I subscribe both lists and tried to build make 3.3.91 two weeks ago but it 
failed because some configuration files were missing.

F:\wintcc\make-7c71df5695720dcf5947a7eba1682452ee497288>build_w32.bat tcc

Creating GNU Make for Windows 9X/NT/2K/XP/Vista/7/8/10

- Building with TinyC
- Enabling maintainer mode

tcc version 0.9.27 mob:aea2b53-mob (x86_64 Windows)
- pkg-config not found, building without Guile

Compiling .\TccRel version
1 file(s) copied.
The system cannot find the path specified.
The system cannot find the path specified.
- Compiling src/ar.c
In file included from src/ar.c:18:
In file included from src/makeint.h:20:
./TccRel/src/config.h:18: error: include file 'mkconfig.h' not found

Which now exists in 4.4.

Next time, I'll try to give you more feedback with intermediate versions. You 
can also ping me if you think a version is stable enough to be tested on 
Windows with tcc.

Christian

-Original Message-
From: Paul Smith [mailto:psm...@gnu.org] 
Sent: Wednesday, November 02, 2022 16:51
To: jull...@eligis.com; make-...@gnu.org
Cc: tinycc-devel@nongnu.org; 'Eli Zaretskii'
Subject: Re: GNUmake v4.4 port on Windows with tcc

On Wed, 2022-11-02 at 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
> 
> call %COMPILER% -mthreads -Wall -std=c11 %OPTS% -I%OUTDIR%/src -
> I./src
> -I%OUTDIR%/lib -I./lib -I./src/w32/include -D_cdecl= -
> Dstrtoull=_strtoui64
> -Dstrtoll=_strtoi64 -D_MSC_VER -DHAVE_CONFIG_H %EXTRAS% -o
> %OUTDIR%/%1.%O%
> -c %1.c
> 
> Hope it helps.

Thanks for that note.  We will choose a different way to address this I
expect but it's good to know there's a problem.

It would be very helpful if someone from tinycc-devel subscribed to one
of the make mailing lists, and could volunteer to build the release
candidates with tcc to ensure that they work properly: we had 3 release
candidates published over 4 weeks before the 4.4 release was made and
issues like this are just the kind of thing we hope to catch during
that period.

Cheers!


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

[Tinycc-devel] GNUmake v4.4 port on Windows with tcc

[Christian Jullien]

Hi team,

Many thanks for your efforts for make 4.4.
Trying to compile this versions with tcc on Windows "nearly" works out the
box.
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

call %COMPILER% -mthreads -Wall -std=c11 %OPTS% -I%OUTDIR%/src -I./src
-I%OUTDIR%/lib -I./lib -I./src/w32/include -D_cdecl= -Dstrtoull=_strtoui64
-Dstrtoll=_strtoi64 -D_MSC_VER -DHAVE_CONFIG_H %EXTRAS% -o %OUTDIR%/%1.%O%
-c %1.c

Hope it helps.

Christian

-Original Message-
From: Eli Zaretskii [mailto:e...@gnu.org] 
Sent: Wednesday, January 22, 2020 19:19
To: jull...@eligis.com
Cc: make-...@gnu.org; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] I want to port make on Windows using tcc
compiler

> 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.template you're referring to.

The template file is not in the tarball, it is in the GNU Make Git
repository.  See https://savannah.gnu.org/git/?group=make.


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

Re: [Tinycc-devel] uname -o was not portable

[Christian Jullien]

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] On 
Behalf Of Moritz Messner
Sent: Sunday, September 04, 2022 22:08
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] uname -o was not portable

This came up a couple weeks ago and was rejected, because uname -s return Linux 
when executed on Android, while -o return Android.

But best check the mailing list archives as I'm not completely sure what the 
consensus was 


 Original Message 
From: Niklas Rosencrantz 
Sent: September 4, 2022 9:14:14 PM GMT+02:00
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] uname -o was not portable

make failed on macOS (Apple M1) seemingly because uname -o is not working
with Apple/macOS. But uname -s did work so I committed a small edit for
that. I checked it with a native Linux system that it didn't break the
Linux build. I hope it's alright?
https://repo.or.cz/tinycc.git/commit/4410dbdd7fcb1ab5133ece7d77a523189c4996e8

Cheers \n

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


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

Re: [Tinycc-devel] uname -o is not valid on macOS

[Christian JULLIEN]

Yes!test $(uname) = Linux && test $(uname -o) = Android && targetos=AndroidPrevents macOS to display an errorGrischka, can you please make this change or do a similar fix?Christian Le : 12 août 2022 à 07:56 (GMT +02:00)De : "Elijah Stone" À : "tinycc-devel@nongnu.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:>>>> test "$(uname -o)" = "Android" && targetos=Android>>>> Why not just "$(uname)" ?>> Well, because on Android just uname gives "Linux".>>>>> 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 mailing listTinycc-devel@nongnu.orghttps://lists.nongnu.org/mailman/listinfo/tinycc-devel

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

[Tinycc-devel] uname -o is not valid on macOS

[Christian JULLIEN]

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

Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocks

[Christian JULLIEN]

Hi Grishka,macOS is not very friendly for tcc on M1, it works as x64 with Rosetta conversion.When boostrapped with clang it 'globally' works.Only the tcc bootstrap failsMany things are yet unavailable on macOS like backtrace.I'm also unable to use gdb. I would say that, tcc on M1 works at 99% with known limitations.When I'll return home next week, I'll try to find what makes tcc fail I currently use the clang bootstrapped version with works good for my needs.Thanks Le : 19 juillet 2022 à 14:27 (GMT +02:00)De : "grischka" À : "tinycc-devel@nongnu.org" Objet : Re: [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 compile tests/tcctest.c to a MACHO x86_64executable and the executable did crash.The tcc (I assume) you did build and install previously also from thatlatest commit and probably also did run the tests on that without havingseen the problem.If that is so then it seems that compiled executable vs. tcc -run makesa difference.  I have no idea what it could be though.You could try to see where tcctest crashes like so:$ tcc -g -I. tests/tcctest.c$ gdb a.out   r   btor using tcc's builtin stack trace:$ tcc -bt -I. tests/tcctest.c$ ./a.outthanks,-- grischka>>> ./configure --cpu=x86_64 --config-bcheck=no --config-backtrace=no --cc=tcc --prefix=/Users/jullien/tinycc/static>> === /Users/jullien/local-tcc/bin/tcc>> Binary directory/Users/jullien/tinycc/static/bin>> TinyCC directory/Users/jullien/tinycc/static/lib/tcc>> Library directory /Users/jullien/tinycc/static/lib>> Include directory /Users/jullien/tinycc/static/include>> Manual directory/Users/jullien/tinycc/static/share/man>> Info directory/Users/jullien/tinycc/static/share/info>> Doc directory /Users/jullien/tinycc/static/share/doc>> /usr/include dir/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include>> Source path /Users/jullien/tinycc>> C compilertcc (0.927)>> Target OS Darwin>> CPU x86_64>> ConfigOSX dll=no bcheck=no backtrace=no>> Creating config.mak and config.h>> tcc -o tcc.o -c tcc.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0 -DONE_SOURCE=0 -DTCC_GITHASH="\"mob:af1abf1\"" -Wall -O2 -arch x86_64 -I.>> tcc -o libtcc.o -c libtcc.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0 -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I.>> tcc -DC2STR conftest.c -o c2str.exe && ./c2str.exe include/tccdefs.h tccdefs_.h>> tcc -o tccpp.o -c tccpp.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0 -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I.>> tcc -o tccgen.o -c tccgen.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0 -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I.>> tcc -o tccdbg.o -c tccdbg.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0 -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I.>> tcc -o tccelf.o -c tccelf.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0 -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I.>> tcc -o tccasm.o -c tccasm.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0 -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I.>> tcc -o tccrun.o -c tccrun.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TC

Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocks

[Christian JULLIEN]

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 directory    /Users/jullien/tinycc/static/binTinyCC directory    /Users/jullien/tinycc/static/lib/tccLibrary directory   /Users/jullien/tinycc/static/libInclude directory   /Users/jullien/tinycc/static/includeManual directory    /Users/jullien/tinycc/static/share/manInfo directory      /Users/jullien/tinycc/static/share/infoDoc directory       /Users/jullien/tinycc/static/share/doc/usr/include dir    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/includeSource path         /Users/jullien/tinyccC compiler          tcc (0.927)Target OS           DarwinCPU                 x86_64Config              OSX dll=no bcheck=no backtrace=noCreating config.mak and config.htcc -o tcc.o -c tcc.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0       -DONE_SOURCE=0 -DTCC_GITHASH="\"mob:af1abf1\"" -Wall -O2 -arch x86_64 -I. tcc -o libtcc.o -c libtcc.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0       -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I. tcc -DC2STR conftest.c -o c2str.exe && ./c2str.exe include/tccdefs.h tccdefs_.htcc -o tccpp.o -c tccpp.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0       -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I. tcc -o tccgen.o -c tccgen.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0       -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I. tcc -o tccdbg.o -c tccdbg.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0       -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I. tcc -o tccelf.o -c tccelf.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0       -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I. tcc -o tccasm.o -c tccasm.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0       -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I. tcc -o tccrun.o -c tccrun.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0       -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I. tcc -o x86_64-gen.o -c x86_64-gen.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0       -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I. tcc -o x86_64-link.o -c x86_64-link.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0       -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I. tcc -o i386-asm.o -c i386-asm.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0       -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I. tcc -o tccmacho.o -c tccmacho.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0       -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I. tcc -ar rcs libtcc.a libtcc.o tccpp.o tccgen.o tccdbg.o tccelf.o tccasm.o tccrun.o x86_64-gen.o x86_64-link.o i386-asm.o tccmacho.otcc -o tcc tcc.o libtcc.a -lm -lpthread -ldl -arch x86_64 ../tcc -c libtcc1.c -o libtcc1.o -B.. -I/tcc -c alloca.S -o alloca.o -B.. -I/tcc -c alloca-bt.S -o 

Re: [Tinycc-devel] new tcc release

[Christian JULLIEN]

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 since then.What are the plans for 
> a new release?I vote for a 0.9.28 rc with the current 
> features, see, what simple fixes are possible and then make a 
> release in the next weeks.(Would help distros to include a recent 
> tcc)Afterwarde prepare for tcc 1.0 later this year.That would 
> make it possible for distros to addtcc 1.0 in there spring/LTS 
> releases.Unfortunately, we missed the 20. anniversary for tcc 
> 1.0(first commit: 27. Oct. 2001),but releasing at the  21. 
> anniversary is still possible.For 1.0, i vote for fixing more 
> bugs and verified C99 support, either excluding Complex math or 
> with optional Complex math (enable during configure, but defaults 
> off)tcc already understand some C11 featuresand 
> newer extensions (example: __has_include)but the related implementation 
> is missing or buggy (_Atomic)I would see fixes for C11 things 
> as cool, when working, but optional for tcc 1.0.What 
> are you think?-- Regards, 
> Detlef


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

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

Re: [Tinycc-devel] Help with tcc_add_symbol // pe_find_import in 0.9.27

[Christian Jullien]

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 Michael Richter
Sent: Tuesday, June 21, 2022 12:38
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] Help with tcc_add_symbol // pe_find_import in 0.9.27

 

Hello,

I'm actually trying to port tcc4tcl from 0.9.26 to 0.9.27. (See 
https://wiki.tcl-lang.org/page/tcc4tcl)

To integrate tcc into tcl there are some changes to be made, especially to the 
Read/Seek part of the loading routines etc., add tcl.h/tclint.h

So far, it seems like I got tcc working, except for one missing link. To 
compile into memory and run the resulting code, wich is why tcc is used in this 
context, you need to transfer the adress of tclStubsPtr (and tclIntStubsPtr) 
into the symboltable with tcc_add_symbol. Under 0.9.26 this worked as expected, 
tcc4tcl added the symbols, the linker resolved them and the resulting code 
executed and found the tclstubs table. Symbols are added in the form 
tcc_add_symbol (s,"tclStubsPtr", tclStubsPtr) where  refers to the 
adress of the internal pointer from the active Tcl Interpreter. the stubstable 
is organized as a list of functionpointers, that are called relative to 
tclStubsPtr (https://wiki.tcl-lang.org/page/Stubs for further info)

 

With 0.9.27 this fails, wether with unkonwn symbol or, if I force tccpe to find 
the symbol, the adress gets resolved in the wrong way and coredumps.

Intersting enough, if I don't compile into memory but use tcc_output_file and 
link against tclStubs86.a all works, so it's not a general problem with linking.

Further Info:

- I used the last 0.9.27 stable from Fabrice Bellard 
http://download.savannah.gnu.org/releases/tinycc/

- I compile and test it under windows (ok, wine to be exact), but use -m32 
WIN32 model to build the tcc4tcl.dll

- Tcl version is 8.6.6

 

Dumping the symboltable shows, that tclStubsPtr and tclIntStubsptr are in 
dynsymtable.

 

pe_find_import refuses to find the symbol, though sym_index >0, because the 
tested conditions are true.

(...)

   sym_index = find_elf_sym(s1->dynsymtab_section, s);
if (sym_index
&& ELFW(ST_TYPE)(sym->st_info) == STT_OBJECT // was stt_object
&& 0 == (sym->st_other & ST_PE_IMPORT)
&& 0 == a
) err = -1, sym_index = 0;

 

(...)

 

 

If I hack this to return the sym_index, the linker will link and the linked 
adress "looks" like it did in 0.9.26, but the resulting code coredumps, so 
something is terribly wrong with this.

 

I can't say, why the symbol gets sorted out. I don't kno, if the coredump comes 
from a false conversion of the pointer adress or if the generated asm is 
handling it wrongly. I'm stuck

 

Is anyone here able to point me in the right direction? Is there a patch im 
missing?

I can put up the modified code on github as a zip if anyone interested in 
getting into the details :-)

Is my problem clear enough or is there any helpful information missing?

 

Michael

 

 

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

Re: [Tinycc-devel] Segfault when using '-static'

[Christian Jullien]

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 '_free'
tcc: error: undefined symbol '_longjmp'
tcc: error: undefined symbol '_malloc'
tcc: error: undefined symbol '_printf'
tcc: error: undefined symbol '_setjmp'

?


-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Herman ten Brugge via Tinycc-devel
Sent: Thursday, May 26, 2022 16:04
To: tinycc-devel@nongnu.org
Cc: Herman ten Brugge
Subject: Re: [Tinycc-devel] Segfault when using '-static'

I fixed the core dump problem but still cannot use -static on any platform.
The problem is that TLS support is needed that is not implemented.

I tried x86-64, i386, rasperry pi 32 and 64, riscv64 and macos, freebsd, 
netbsd.

All failed for me because of missing TLS support.

I only got this working on openbsd 7.1 (only tried x86_64).

 Herman


On 5/26/22 07:21, Arthur Williams wrote:
> So noticed that I can no longer build static packages with tcc.
>
> ```
> $ cat test.c
> int main(){return 0;}
> $./tcc -static test.c
> Segmentation fault
> ```
>
> I ran through git-bisect and concluded the regression was introduced in
> 4c82b003420fabbb95e077866784badc1a49189b: Update for elflint problems.
>
> Simply reverting the commit allows the above example to not error. Any
> objection to just reverting the offending commit.
>
> - Arthur
>


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


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

Re: [Tinycc-devel] Segfault when using '-static'

[Christian Jullien]

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: Thursday, May 26, 2022 07:22
To: tinycc-devel@nongnu.org
Cc: Arthur Williams
Subject: [Tinycc-devel] Segfault when using '-static'

So noticed that I can no longer build static packages with tcc.

```
$ cat test.c
int main(){return 0;}
$./tcc -static test.c
Segmentation fault
```

I ran through git-bisect and concluded the regression was introduced in
4c82b003420fabbb95e077866784badc1a49189b: Update for elflint problems.

Simply reverting the commit allows the above example to not error. Any
objection to just reverting the offending commit.

- Arthur

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


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

[Tinycc-devel] [macOS] gdwarf

[Christian Jullien]

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.

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

[Tinycc-devel] dwarf is silently ignored on Windows

[Christian Jullien]

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 -rwxr-xr-x 1 jullien None 6144 May  5 10:23 foo.exe

 

/cygdrive/f/tinycc/win32 $ ./tcc -gdwarf foo.c && ls -ls foo.exe

4 -rwxr-xr-x 1 jullien None 3072 May  5 10:23 foo.exe

 

/cygdrive/f/tinycc/win32 $ ./tcc foo.c && ls -ls foo.exe

4 -rwxr-xr-x 1 jullien None 3072 May  5 10:23 foo.exe.

 

IMHO, this option should not be displayed on Windows help.

 

It is more questionable if tcc should protest if still try to use it.

 

"tcc: this version does not support dwarf"

 

Alternatively, -gdwarf can behave as if -g was supplied.

 

M2c

 

 

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

Re: [Tinycc-devel] Tinycc on Apple M1 is creating x64 binaries

[Christian Jullien]

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 probably not too far from true aarch64 support as it detects two
reloc issues (as far I understand) but I've no idea on how to implement
them, esp because I unable to find info on those reloc types anywhere.

 

C.

 

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of Antoine Champion
Sent: Tuesday, April 19, 2022 20:53
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] Tinycc on Apple M1 is creating x64 binaries

 

Hi list,

 

I've installed tinycc from mob branch without configure options.

 

When I try to compile any piece of code, the produced output is for x86_64
architecture :

 

% echo "int main(int argc, char** argv) { return 0 ; }" > test.c

% tcc test.c

% lipo -info a.out

Non-fat file: a.out is architecture: x86_64

% ./a.out

illegal hardware instruction: ./a.out

 

Alternatively, I can't either compile a dynamic library with -shared, with
the compilation error "tcc: error: _main not defined".

 

Am I missing something or is tcc not yet ready for Apple M1?

 

Best,

Antoine

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

Re: [Tinycc-devel] Compilation error while including LAPACKE

[Christian Jullien]

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: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Compilation error while including LAPACKE

Just curious, if I do need complex how hard is it to implement it? I
presume if the user wants to use LAPACKE or similar numerical library
they will run into similar problems

Any pointers would be much appreciated.
Many thanks
Chris

On Sat, 9 Apr 2022 at 17:45, Domingo Alvarez Duarte  wrote:
>
> After your last message I've tried defining "_Complex" to empty and for
> the simple test it compiled, probably if you are not using complex this
> trick could work:
>
> =
>
> #include 
> #define _Complex  //make it e noop
> #include 
>
> int main() {
>printf("Hello World!\n");
>return 0;
> }
>
> 
>
> Output:
>
> 
>
> ../tcc  cmath.c
>  >Exit code: 0
> ./a.out
>  >./a.out
> Hello World!
>  >Exit code: 0
>
> 
>
> On 9/4/22 18:14, Christopher Choi wrote:
> > Sorry I guess I'm not familiar with TCC, but I suppose this is
> > something TCC hasn't implemented yet? having dug into the archives a
> > little more the only other mention of complex type support with TCC
> > was in 2015.
> >
> > https://www.mail-archive.com/tinycc-devel@nongnu.org/msg06428.html
> >
> > If complex types are not supported are there known work-arounds other
> > than "dont use them"?
> >
> > Thanks
> > Chris
> >
> > On Sat, 9 Apr 2022 at 09:03, Domingo Alvarez Duarte  
> > wrote:
> >> The problem seem to be related with "Complex" rather than "lapacke":
> >>
> >> 
> >>
> >> #include 
> >> #include 
> >>
> >> int main() {
> >> printf("Hello World!\n");
> >> return 0;
> >> }
> >>
> >> 
> >>
> >> Output:
> >>
> >> 
> >>
> >> tcc -c cmath.c
> >> In file included from cmath.c:2:
> >> In file included from /usr/include/complex.h:106:
> >> /usr/include/x86_64-linux-gnu/bits/cmathcalls.h:55: error: ';' expected
> >> (got "cacos")
> >>
> >> 
> >>
> >> Output of preprocessing:
> >>
> >> 
> >>
> >> /tcc -E cmath.c
> >>
> >> ...
> >>
> >> # 106 "/usr/include/complex.h"
> >> # 1 "/usr/include/x86_64-linux-gnu/bits/cmathcalls.h" 1
> >> # 55 "/usr/include/x86_64-linux-gnu/bits/cmathcalls.h"
> >> extern double _Complex cacos (double _Complex __z) ; extern double
> >> _Complex __cacos (double _Complex __z) ;
> >>
> >> ...
> >>
> >> 
> >>
> >> On 9/4/22 2:03, Christopher Choi wrote:
> >>> #include 
> >>> #include 
> >>>
> >>> int main() {
> >>> printf("Hello World!\n");
> >>> return 0;
> >>> }
> >> ___
> >> Tinycc-devel mailing list
> >> Tinycc-devel@nongnu.org
> >> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
> > ___
> > Tinycc-devel mailing list
> > Tinycc-devel@nongnu.org
> > https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel

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


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

Re: [Tinycc-devel] Enabling TinyCC to Create Empty Archives

[Christian Jullien]

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 thing for tcc to mimic gcc/ar/... behaviors

M2c 

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Ziyao
Sent: Monday, April 04, 2022 05:03
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] Enabling TinyCC to Create Empty Archives

Hi list,

On my machine (x86_64 Ubuntu 18.04LTS,GNU ar 2.30),it is OK to create an
empty archive with
ar rc libempty.a
This will create libempty.a which only contains an ar archive header.

But TinyCC refuses to do that:
tcc -ar rc libempty.a   # This will print the usage
I made a patch for that.

musl libc uses this feature to create dummy libraries(it combines all
libraries into a single file,rather than many libraries like libc.a,libm.a
etc.Dummy libraries are used to avoid linking errors when using common
linking flags like -lm).

I do not know whether there are other projects using this feature.But I
think it is a good idea to keep compatible with GNU ar.

Best wishes,
Ziyao

-

diff --git a/tcctools.c b/tcctools.c
index 4567b81..7c643dc 100644
--- a/tcctools.c
+++ b/tcctools.c
@@ -61,7 +61,7 @@ static int contains_any(const char *s, const char *list) {
 }

 static int ar_usage(int ret) {
-fprintf(stderr, "usage: tcc -ar [rcsv] lib file...\n");
+fprintf(stderr, "usage: tcc -ar [rcsv] lib [file...]\n");
 fprintf(stderr, "create library ([abdioptxN] not supported).\n");
 return ret;
 }
@@ -115,8 +115,9 @@ ST_FUNC int tcc_tool_ar(TCCState *s1, int argc, char **argv)
 }
 }

-if (!i_obj)  // i_obj implies also i_lib. we require both.
+if (!i_lib)  // i_obj implies also i_lib.
 ret = 1;
+i_obj = i_obj ? i_obj : argc;  // An empty archive will be generated if no 
input file is given

 if (ret == 1)
 return ar_usage(ret);
@@ -242,6 +243,9 @@ ST_FUNC int tcc_tool_ar(TCCState *s1, int argc, char **argv)
 hofs++, fpos = 1;
 // write header
 fwrite("!\n", 8, 1, fh);
+// create an empty archive
+if (!funccnt)
+goto the_end;
 sprintf(stmp, "%-10d", (int)(strpos + (funccnt+1) * sizeof(int)));
 memcpy(_size, stmp, 10);
 fwrite(, sizeof(arhdr), 1, fh);


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


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

Re: [Tinycc-devel] A Patch for -dumpmachine Option

[Christian Jullien]

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 reports:
gcc -dumpmachine
x86_64-pc-cygwin

or

clang -dumpmachine
x86_64-pc-windows-msvc

macOS:
jullien@mobley:~ $ clang -dumpmachine
arm64-apple-darwin21.4.0
jullien@mobley:~ $ clang -arch x86_64 -dumpmachine
x86_64-apple-darwin21.4.0

etc...

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Ziyao
Sent: Thursday, March 24, 2022 11:36
To: Tinycc-devel@nongnu.org
Subject: [Tinycc-devel] A Patch for -dumpmachine Option

Hi list,

I have made a small patch which adds option "-dumpmachine" support to
TinyCC.This option is widely supported by both gcc and clang.Some configure
scripts detect the platform information by passing this option to the
C compiler,such as musl libc.

And by the way,what is the proper way to contribute? Just send patches to
this maillist or what?Should I send a normal patch or formatted patch?
Thanks for answering.

(To avoid messing the plaintext mail readers up,I add my patch to the bottom
of this mail.)

Cheers,
Ziyao

--

diff --git a/libtcc.c b/libtcc.c
index b6dbb01..6e5cf17 100644
--- a/libtcc.c
+++ b/libtcc.c
@@ -1456,6 +1456,7 @@ enum {
 TCC_OPTION_g,
 TCC_OPTION_c,
 TCC_OPTION_dumpversion,
+TCC_OPTION_DUMPMACHINE,
 TCC_OPTION_d,
 TCC_OPTION_static,
 TCC_OPTION_std,
@@ -1488,7 +1489,7 @@ enum {
 TCC_OPTION_MMD,
 TCC_OPTION_x,
 TCC_OPTION_ar,
-TCC_OPTION_impdef,
+TCC_OPTION_impdef
 };
 
 #define TCC_OPTION_HAS_ARG 0x0001
@@ -1518,6 +1519,7 @@ static const TCCOption tcc_options[] = {
 { "g", TCC_OPTION_g, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
 { "c", TCC_OPTION_c, 0 },
 { "dumpversion", TCC_OPTION_dumpversion, 0},
+{ "dumpmachine", TCC_OPTION_DUMPMACHINE , 0 },
 { "d", TCC_OPTION_d, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
 { "static", TCC_OPTION_static, 0 },
 { "std", TCC_OPTION_std, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
@@ -1952,6 +1954,8 @@ reparse:
 printf ("%s\n", TCC_VERSION);
 exit(0);
 break;
+case TCC_OPTION_DUMPMACHINE:
+return OPT_DUMPMACHINE;
 case TCC_OPTION_x:
 x = 0;
 if (*optarg == 'c')
diff --git a/tcc.c b/tcc.c
index 42a251b..ed9c143 100644
--- a/tcc.c
+++ b/tcc.c
@@ -95,6 +95,7 @@ static const char help2[] =
 "  -isystem dir  add 'dir' to system include path\n"
 "  -static   link to static libraries (not 
recommended)\n"
 "  -dumpversion  print version\n"
+"  -dumpmachine  print platform information\n"
 "  -print-search-dirsprint search paths\n"
 "  -dt   with -run/-E: auto-define 'test_...' 
macros\n"
 "Ignored options:\n"
@@ -289,6 +290,47 @@ redo:
 return 0;
 ++opt;
 }
+
+if (opt == OPT_DUMPMACHINE) {
+fputs(
+#ifdef TCC_TARGET_I386
+"i386"
+#elif defined TCC_TARGET_X86_64
+"x86_64"
+#elif defined TCC_TARGET_C67
+"c67"
+#elif defined TCC_TARGET_ARM
+"arm"
+# ifdef TCC_ARM_EABI
+" eabi"
+#  ifdef TCC_ARM_HARDFLOAT
+"hf"
+#  endif
+# endif
+#elif defined TCC_TARGET_ARM64
+"aarch64"
+#elif defined TCC_TARGET_RISCV64
+"riscv64"
+#endif
+   "-"
+#ifdef TCC_TARGET_PE
+"windows"
+#elif defined(TCC_TARGET_MACHO)
+"darwin"
+#elif TARGETOS_FreeBSD || TARGETOS_FreeBSD_kernel
+"freebsd"
+#elif TARGETOS_OpenBSD
+"openbsd"
+#elif TARGETOS_NetBSD
+"netbsd"
+#else
+"linux"
+#endif
+"-tcc\n",stdout);
+return 0;
+
+}
+
 if (opt == OPT_HELP2) {
 fputs(help2, stdout);
 return 0;
diff --git a/tcc.h b/tcc.h
index 9724848..3812241 100644
--- a/tcc.h
+++ b/tcc.h
@@ -1279,6 +1279,7 @@ ST_FUNC char *tcc_load_text(int fd);
 #define OPT_PRINT_DIRS 4
 #define OPT_AR 5
 #define OPT_IMPDEF 6
+#define OPT_DUMPMACHINE 7
 #define OPT_M32 32
 #define OPT_M64 64


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


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

Re: [Tinycc-devel] [PATCH] Support -G as an alias to -shared

[Christian Jullien]

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: Saturday, March 19, 2022 08:17
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] [PATCH] Support -G as an alias to -shared

Hi,

It's a small change, but as my commits have justifiably been reverted in the 
past, I'd like to run this by the list and leave it to someone else to apply it.

The POSIX Issue 8 drafts specify -G as a portable way to specify building a 
shared library, and I think TinyCC should support this. On the other hand, if 
you think it's premature to add this, that's fair.

From bde9e15d13d31557b30e8f34de16195361e3d2e5 Mon Sep 17 00:00:00 2001
From: John Scott 
Date: Sat, 19 Mar 2022 03:10:59 -0400
Subject: [PATCH] Support -G as an alias for -shared.

This is slated for specification in POSIX Issue 8:
https://austingroupbugs.net/view.php?id=1294
---
 libtcc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libtcc.c b/libtcc.c
index b6dbb01..1126a3f 100644
--- a/libtcc.c
+++ b/libtcc.c
@@ -1522,6 +1522,7 @@ static const TCCOption tcc_options[] = {
 { "static", TCC_OPTION_static, 0 },
 { "std", TCC_OPTION_std, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
 { "shared", TCC_OPTION_shared, 0 },
+{ "G", TCC_OPTION_shared, 0 },
 { "soname", TCC_OPTION_soname, TCC_OPTION_HAS_ARG },
 { "o", TCC_OPTION_o, TCC_OPTION_HAS_ARG },
 { "pthread", TCC_OPTION_pthread, 0},
--
2.34.1



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

[Tinycc-devel] Tests 108 and 114 constantly fail on macOS

[Christian Jullien]

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  2022-03-17 10:55:09.0 +0100

+++ 108_constructor.output  2022-03-17 10:55:20.0 +0100

@@ -1,3 +1,2 @@

constructor

main

-destructor

make[3]: *** [108_constructor.test] Error 1

 

 

Test: 114_bound_signal...

--- 114_bound_signal.expect 2022-03-17 10:55:09.0 +0100

+++ 114_bound_signal.output 2022-03-17 10:55:21.0 +0100

@@ -1,2 +0,0 @@

-start

-end

make[3]: *** [114_bound_signal.test] Error 1

 

It happens when I bootstrap tcc with clang or with tcc

So I wonder if macOS has specificities that prevent 108/114 to work. I
suspect more a macOS limitation than an issue with tcc.

 

If it requires features (__attribute__ constructor/destructor not supported
by macOS , or macOS deprecated sem_xx calls), I suggest to no longer launch
108/114 tests for macOS.

 

Wdyt?

 

C

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

[Tinycc-devel] Announce: tcc works ROOTB as aarch64 on Linux M1

[Christian Jullien]

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

.

gcc version 11.2.0 (Debian 11.2.0-16)

 

C.

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

Re: [Tinycc-devel] tcc assertion fail at x86_64-gen.c:441

[Christian Jullien]

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 ???
Sent: Monday, March 07, 2022 03:14
To: tinycc-devel
Subject: [Tinycc-devel] tcc assertion fail at x86_64-gen.c:441

 

Reproducer:

 

$ cat new.c # can be found in attachment

void abort(void);
int ii;
typedef struct {
} raw_spinlock_t;
typedef struct {
  raw_spinlock_t raw_lock;
} spinlock_t;
raw_spinlock_t one_raw_spinlock(void) {
  raw_spinlock_t raw_lock;
  ii++;
  return raw_lock;
}
int main(void) {
  spinlock_t lock =
  (spinlock_t){.raw_lock = one_raw_spinlock()};
  int ctf0_idx;
  ctf0_idx = (int)0x;
  int ctf0_constval;
  ctf0_constval = (int)0x;
  int *ctf0_arr[] = {_constval};
  int ctf1_idx;
  ctf1_idx = (int)0x;
  int ctf1_constval;
  ctf1_constval = (int)0x;
  int *ctf1_arr[] = {_constval};
  if (((*ctf0_arr[ctf0_idx]) | (*ctf1_arr[ctf1_idx])) != 1)
abort();
  return 0;
}

 

$ tcc -O0 new.c

tcc: x86_64-gen.c:441: load: Assertion `((ft & VT_BTYPE) == VT_INT) || ((ft & 
VT_BTYPE) == VT_LLONG) || ((ft & VT_BTYPE) == VT_PTR) || ((ft & VT_BTYPE) == 
VT_FUNC)' failed.

[1]115530 abort (core dumped)  tcc -O0 new.c

 

my tcc version is (ubuntu 18.04)

$ tcc -v

tcc version 0.9.27 (x86_64 Linux)

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

Re: [Tinycc-devel] tcc assertion fail at x86_64-gen.c:441

[Christian Jullien]

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 [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of ???
Sent: Monday, March 07, 2022 03:14
To: tinycc-devel
Subject: [Tinycc-devel] tcc assertion fail at x86_64-gen.c:441

 

Reproducer:

 

$ cat new.c # can be found in attachment

void abort(void);
int ii;
typedef struct {
} raw_spinlock_t;
typedef struct {
  raw_spinlock_t raw_lock;
} spinlock_t;
raw_spinlock_t one_raw_spinlock(void) {
  raw_spinlock_t raw_lock;
  ii++;
  return raw_lock;
}
int main(void) {
  spinlock_t lock =
  (spinlock_t){.raw_lock = one_raw_spinlock()};
  int ctf0_idx;
  ctf0_idx = (int)0x;
  int ctf0_constval;
  ctf0_constval = (int)0x;
  int *ctf0_arr[] = {_constval};
  int ctf1_idx;
  ctf1_idx = (int)0x;
  int ctf1_constval;
  ctf1_constval = (int)0x;
  int *ctf1_arr[] = {_constval};
  if (((*ctf0_arr[ctf0_idx]) | (*ctf1_arr[ctf1_idx])) != 1)
abort();
  return 0;
}

 

$ tcc -O0 new.c

tcc: x86_64-gen.c:441: load: Assertion `((ft & VT_BTYPE) == VT_INT) || ((ft & 
VT_BTYPE) == VT_LLONG) || ((ft & VT_BTYPE) == VT_PTR) || ((ft & VT_BTYPE) == 
VT_FUNC)' failed.

[1]115530 abort (core dumped)  tcc -O0 new.c

 

my tcc version is (ubuntu 18.04)

$ tcc -v

tcc version 0.9.27 (x86_64 Linux)

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

Re: [Tinycc-devel] NULL pointer dereference due to unchecked return from fdopen()

[Christian Jullien]

Hi,

I'm really sorry to hurt you. It looks John had an issue because of unchecked 
returned value, I was just trying to help.
IMHO, if fdopen really fails, as first approach, it's better to have an error 
message than a core dump but you're the maintainer and I respect all your 
decisions, you have probably something better to propose when fdopen fails.
I suppose that, from John point of view, the problem is not non-existent.

M2c.

C. 

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of grischka
Sent: Monday, February 28, 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 maintainers agree, we can probably apply:
> Wdyt?

The rule is, as always:  don't write code that you cannot test.

Can you?

Otherwise, can we stop suggesting sloppily crafted quick patches
addressing non-existent problems?

Is that possible, then?

-- gr

> 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 tcc_write_elf_file(TCCState *s1, const char 
> *filename, int phnum,
>  return -1;
>  }
>  f = fdopen(fd, "wb");
> +if (f == NULL) {
> +tcc_error("Unable to fdopen %s for output", filename);
> +}
>  if (s1->verbose)
>  printf("<- %s\n", filename);
>
> diff --git a/tccmacho.c b/tccmacho.c
> index 57c62c3..f94f976 100644
> --- a/tccmacho.c
> +++ b/tccmacho.c
> @@ -800,6 +800,9 @@ ST_FUNC int macho_output_file(TCCState *s1, const char 
> *filename)
>  return -1;
>  }
>  fp = fdopen(fd, "wb");
> +if (fp == NULL) {
> +tcc_error("Unable to fdopen %s for output", filename);
> +}
>  if (s1->verbose)
>  printf("<- %s\n", filename);
>
>
>
>
> -Original Message-
> From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] 
> On Behalf Of John Scott
> Sent: Monday, February 28, 2022 05:18
> To: tinycc-devel@nongnu.org
> Subject: [Tinycc-devel] NULL pointer dereference due to unchecked return from 
> fdopen()
>
> Hi all,
>
> I found this bug using the oomify tool at https://github.com/tavianator/oomify
>
> The problem can be seen at tccelf.c around line 2430 (f has type FILE*):
>   f = fdopen(fd, "wb");
>   if (s1->verbose)
>   printf("<- %s\n", filename);
>
> #ifdef TCC_TARGET_COFF
>   if (s1->output_format == TCC_OUTPUT_FORMAT_COFF)
>   tcc_output_coff(s1, f);
>   else
> #endif
>   if (s1->output_format == TCC_OUTPUT_FORMAT_ELF)
>   tcc_output_elf(s1, f, phnum, phdr, file_offset, sec_order);
>
> Note that the return value from fdopen() is not checked if it is NULL.
> If the output format is ELF, then tcc_output_elf() expects that f is a valid 
> FILE* variable and passes it to fwrite(), which causes undefined behavior.
>
> I don't know how to fix this, but hope that maybe one of you folks will 
> appreciate this report.
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel


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


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

Re: [Tinycc-devel] rv32 support in tcc

[Christian Jullien]

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 riscv 
files that handle 32/64 using a command line flag -m32/-64 to handle the (few?) 
cases where code generation differs?
I would say if 90% of the generated code is common, it may be interesting to 
handle 32/64 in the same files.

M2c

Christian.

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Sam Ellicott
Sent: Sunday, February 27, 2022 20:23
To: tinycc-devel@nongnu.org
Cc: Sagar Acharya
Subject: Re: [Tinycc-devel] rv32 support in tcc

> I'm not aware of riscv32 32bit porting efforts but someone is perhaps busy 
> working on it.

I am currently (slowly) working on a port for riscv32. I haven't had
much free time lately, so progress has sort of stagnated, but the code
is here
https://github.com/sellicott/tcc-riscv32/

Thanks,
-Sam Ellicott
Soli Deo Gloria

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


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

Re: [Tinycc-devel] emulate tcc -S - was (no subject)

[Christian Jullien]

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 ip, sp
   4:   e92d0003push{r0, r1}
   8:   e92d5800push{fp, ip, lr}
   c:   e1a0b00dmov fp, sp
  10:   e1a0nop ; (mov r0, r0)
  14:   e59b000cldr r0, [fp, #12]
  18:   e59b1010ldr r1, [fp, #16]
  1c:   e151cmp r0, r1
  20:   da00ble 28 
  24:   ea01b   30 
  28:   e59b0010ldr r0, [fp, #16]
  2c:   ea00b   34 
  30:   e59b000cldr r0, [fp, #12]
  34:   e89ba800ldm fp, {fp, sp, pc}



-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Ivo van Poorten
Sent: Sunday, February 27, 2022 18:49
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] (no subject)

TCC generates object code directly. There is no assembly intermediate
step, hence tcc -S does not work.

On Sat, 26 Feb 2022 21:14:49 -0500 Yair Lenga
 wrote: 
> I'm interested in understanding the code generation logic of tcc.
> 
> Is there away to see the intermediate representation that tcc
> generates between the "C" source code, and the object file.
> documentation indicates there tcc can compile assembly source code to
> object, but I could not not find the equivalent of "gcc -S", which
> should convert the "C" code into assembly.
> 
> Yair

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


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

Re: [Tinycc-devel] NULL pointer dereference due to unchecked return from fdopen()

[Christian Jullien]

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 tcc_write_elf_file(TCCState *s1, const char 
*filename, int phnum,
 return -1;
 }
 f = fdopen(fd, "wb");
+if (f == NULL) {
+tcc_error("Unable to fdopen %s for output", filename);
+}
 if (s1->verbose)
 printf("<- %s\n", filename);

diff --git a/tccmacho.c b/tccmacho.c
index 57c62c3..f94f976 100644
--- a/tccmacho.c
+++ b/tccmacho.c
@@ -800,6 +800,9 @@ ST_FUNC int macho_output_file(TCCState *s1, const char 
*filename)
 return -1;
 }
 fp = fdopen(fd, "wb");
+if (fp == NULL) {
+tcc_error("Unable to fdopen %s for output", filename);
+}
 if (s1->verbose)
 printf("<- %s\n", filename);




-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of John Scott
Sent: Monday, February 28, 2022 05:18
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] NULL pointer dereference due to unchecked return from 
fdopen()

Hi all,

I found this bug using the oomify tool at https://github.com/tavianator/oomify

The problem can be seen at tccelf.c around line 2430 (f has type FILE*):
f = fdopen(fd, "wb");
if (s1->verbose)
printf("<- %s\n", filename);

#ifdef TCC_TARGET_COFF
if (s1->output_format == TCC_OUTPUT_FORMAT_COFF)
tcc_output_coff(s1, f);
else
#endif
if (s1->output_format == TCC_OUTPUT_FORMAT_ELF)
tcc_output_elf(s1, f, phnum, phdr, file_offset, sec_order);

Note that the return value from fdopen() is not checked if it is NULL.
If the output format is ELF, then tcc_output_elf() expects that f is a valid 
FILE* variable and passes it to fwrite(), which causes undefined behavior.

I don't know how to fix this, but hope that maybe one of you folks will 
appreciate this report.


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

Re: [Tinycc-devel] rv32 support in tcc

[Christian Jullien]

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 27, 2022 11:59
To: tinycc-devel@nongnu.org
Cc: Sagar Acharya
Subject: [Tinycc-devel] rv32 support in tcc

Hello folks,
I saw tcc and there are a few riscv64 files in the project. README states that 
they would be used for compiling on a riscv64 system. I need a compiler that 
could compile for riscv32. Can tinycc do that currently?

If not, are there any plans to introduce rv32 compilation?

Thanks for the fantastic project

Sagar Acharya

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


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

Re: [Tinycc-devel] Extend tcc to use viable.

[Christian Jullien]

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 CFront 3.0 where all C++ => C translators.
I don't think your DLS could be half as much complex as C++ 3.0 was.
A translator has not to be human readable. For example, my OpenLisp compiler, 
which can viewed as OpenLisp to C translator, resembles more to an assembler 
than to a C program. It compiles the complex ISLISP OOP language to a series of 
very basic C instructions and internal lib calls.

Writing a translator/compiler takes time, it took me around 3 months until I 
can translate 80% of OpenLisp and another 3 months to reach 95%. The next 5% 
took me 6 months (not full time). So around one year to be close to 100%. Ten 
years later I still have few bugs with obscure and very uncommon uses. 

M2c

Christian

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Yair Lenga
Sent: Thursday, February 24, 2022 19:39
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] Extend tcc to use viable.

Hi,

I am working on a project to convert a proprietary DSL language into standard 
one. The proprietary language is executed by interpreter engine from intermedia 
representation. The challenge is maintaining the language and the runtime.

I am exploring an option to use compile-on-the-fly approach by translating the 
DSL to c, compile/execute in memory. Language is Fortran/c style, and is “safe” 
(no pointers, atomic strings, and bound-checked arrays) - most statements can 
be converted to c.

One challenge is methods. Language allow simple OO calls obj->method. The 
challenge is how to tell obj->prop (value), vs obj->method (function call). The 
translator can do it, if it will build parse tree, symbol tables. This is much 
more work than a statement by statement translator.

I was hoping it will be possible to make a small change to tcc, introduce a new 
operator (e.g. obj@func), which will be equivalent to obj->method() (function 
call) or obj->prop (member value), based on the type of the member (function 
pointers). Can anyone comment on readability of making such a change to tcc ?

Thanks, yair

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


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

Re: [Tinycc-devel] wrong interpreter on armhf

[Christian Jullien]

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 char *__nptr, char 
**__endptr);
 #  if defined(TCC_MUSL)
 #   if defined(TCC_TARGET_I386)
 # define CONFIG_TCC_ELFINTERP "/lib/ld-musl-i386.so.1"
-#else
+#   elif defined(TCC_ARM_HARDFLOAT)
+# define CONFIG_TCC_ELFINTERP "/lib/ld-musl-armhf.so.1"
+#   else
 # define CONFIG_TCC_ELFINTERP "/lib/ld-musl-arm.so.1"
-#endif
+#   endif
 #  else
 #   define CONFIG_TCC_ELFINTERP "/lib/ld-linux.so.2"
 #  endif


C
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of raingloom
Sent: Wednesday, February 23, 2022 00:07
To: arn...@skeeve.com
Cc: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] wrong interpreter on armhf

On Tue, 22 Feb 2022 07:23:44 -0700
arn...@skeeve.com wrote:

> Try symlinking the existing file to what tcc wants. Sometimes
> we get lucky... :-)
> 
> Arnold
> 
> raingloom  wrote:
> 
> > Hi! I recently tried tcc on a postmarketOS (Alpine) device. It
> > seems to generate the correct binary for hello world and even -run
> > worked, but the resulting binary can't be run directly.
> > It expects /lib/ld-musl-arm.so.1, but only /lib/ld-musl-armhf.so.1
> > exists.
> >
> > ___
> > Tinycc-devel mailing list
> > Tinycc-devel@nongnu.org
> > https://lists.nongnu.org/mailman/listinfo/tinycc-devel  

That would work but would be kind of ugly, I'd prefer a proper fix.

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


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

Re: [Tinycc-devel] wrong interpreter on armhf

[Christian Jullien]

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: Tuesday, February 22, 2022 00:45
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] wrong interpreter on armhf

Hi! I recently tried tcc on a postmarketOS (Alpine) device. It seems to
generate the correct binary for hello world and even -run worked, but
the resulting binary can't be run directly.
It expects /lib/ld-musl-arm.so.1, but only /lib/ld-musl-armhf.so.1
exists.

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


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

Re: [Tinycc-devel] wrong interpreter on armhf

[Christian Jullien]

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: tinycc-devel@nongnu.org
Cc: raingl...@riseup.net
Subject: Re: [Tinycc-devel] wrong interpreter on armhf

Try symlinking the existing file to what tcc wants. Sometimes
we get lucky... :-)

Arnold

raingloom  wrote:

> Hi! I recently tried tcc on a postmarketOS (Alpine) device. It seems to
> generate the correct binary for hello world and even -run worked, but
> the resulting binary can't be run directly.
> It expects /lib/ld-musl-arm.so.1, but only /lib/ld-musl-armhf.so.1
> exists.
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel

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


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

Re: [Tinycc-devel] [PATCH] improving solaris/illumos support

[Christian Jullien]

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 issues (a big classic for a new 
port), do you?

You missed the correct values for:
#elif defined(__sun)
+#define BOUND_TID_TYPE   pid_t
+#define BOUND_GET_TIDsyscall (SYS_)

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of David CARLIER
Sent: Sunday, February 20, 2022 20:00
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] [PATCH] improving solaris/illumos support

Hi, here a patch to add this platform as a new target.


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

Re: [Tinycc-devel] initializer overflow with arrays on implicit size

[Christian Jullien]

If it helps maintainers, changing the code to

 

struct A a[] = { {1}, {2}, };

 

Compiles and works. As does:

 

struct A b[2] = { (struct A){1}, (struct A){2}, };

 

Maybe the cast adds extra alignment

 

From: Tyge Løvset [mailto:tylov...@gmail.com] 
Sent: Sunday, February 20, 2022 16:23
To: jull...@eligis.com; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] initializer overflow with arrays on implicit size

 

I have reported this before and tried a bit to debug without success. Very 
annoying. Only useful info I can give is that is does not happen on GCC 
compiled on windows, 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


-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis 
<mailto:tinycc-devel-bounces%2Beligis> =orange...@nongnu.org] On Behalf Of 
Arthur Williams via Tinycc-devel
Sent: Saturday, February 12, 2022 03:33
To: tinycc-devel@nongnu.org
Cc: Arthur Williams
Subject: [Tinycc-devel] initializer overflow with arrays on implicit size

Greetings,

Found a strange error when trying to build a program with tcc.
The error is
```
test.c:8: error: internal compiler error
tccgen.c:7728: in init_assert(): initializer overflow
```
And here is a minimal example of how to repro it.

```
#include 
struct A {
char a;
char b;
};

int main() {
struct A a[] = { (struct A){1}, (struct A){2}, };
printf("%d %d\n", a[0].a, a[0].b);
printf("%d %d\n", a[1].a, a[1].b);
return 0;
}
```
(printing isn't need to repro the problem)

Took a glance at the code that was generating the error message:
`init_assert`. The commit message for that function seems to imply that
is was temporary and removing this function avoid the error and allows
the code to compile. Tests pass and the output is also as expected.
Is there a reason to keep this function around?

Playing around with the function removed and while the code compiles
find, running with `tcc -run` segfaults. So I imagine the real fix is a
bit less trivial that what I had thought.


Arthur

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


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

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

Re: [Tinycc-devel] Fwd: [PATCH] freebsd support update proposal

[Christian Jullien]

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: Tuesday, February 15, 2022 10:52
To: 'tinycc-devel@nongnu.org'
Subject: RE: [Tinycc-devel] Fwd: [PATCH] freebsd support update proposal

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 [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of David CARLIER
Sent: Wednesday, February 02, 2022 18:13
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] Fwd: [PATCH] freebsd support update proposal

Hi if nobody objects, I may apply the last aforementioned patch
sometime next week.

Kind regards.
-- Forwarded message -
From: David CARLIER 
Date: Sun, 30 Jan 2022 at 18:35
Subject: Re: [PATCH] freebsd support update proposal
To: 


> new version considering feedbacks. Cheers.

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


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

Re: [Tinycc-devel] Fwd: [PATCH] freebsd support update proposal

[Christian Jullien]

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 [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of David CARLIER
Sent: Wednesday, February 02, 2022 18:13
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] Fwd: [PATCH] freebsd support update proposal

Hi if nobody objects, I may apply the last aforementioned patch
sometime next week.

Kind regards.
-- Forwarded message -
From: David CARLIER 
Date: Sun, 30 Jan 2022 at 18:35
Subject: Re: [PATCH] freebsd support update proposal
To: 


> new version considering feedbacks. Cheers.

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


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

Re: [Tinycc-devel] initializer overflow with arrays on implicit size

[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


-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Arthur Williams via Tinycc-devel
Sent: Saturday, February 12, 2022 03:33
To: tinycc-devel@nongnu.org
Cc: Arthur Williams
Subject: [Tinycc-devel] initializer overflow with arrays on implicit size

Greetings,

Found a strange error when trying to build a program with tcc.
The error is
```
test.c:8: error: internal compiler error
tccgen.c:7728: in init_assert(): initializer overflow
```
And here is a minimal example of how to repro it.

```
#include 
struct A {
char a;
char b;
};

int main() {
struct A a[] = { (struct A){1}, (struct A){2}, };
printf("%d %d\n", a[0].a, a[0].b);
printf("%d %d\n", a[1].a, a[1].b);
return 0;
}
```
(printing isn't need to repro the problem)

Took a glance at the code that was generating the error message:
`init_assert`. The commit message for that function seems to imply that
is was temporary and removing this function avoid the error and allows
the code to compile. Tests pass and the output is also as expected.
Is there a reason to keep this function around?

Playing around with the function removed and while the code compiles
find, running with `tcc -run` segfaults. So I imagine the real fix is a
bit less trivial that what I had thought.


Arthur

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


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

Re: [Tinycc-devel] Fwd: [PATCH] freebsd support update proposal

[Christian Jullien]

I think this one is good.

 

Thanks for your review.

 

C.

 

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Herman ten Brugge via Tinycc-devel
Sent: Wednesday, February 09, 2022 08:14
To: tinycc-devel@nongnu.org
Cc: Herman ten Brugge
Subject: Re: [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 --git a/include/tccdefs.h b/include/tccdefs.h

index 2d42bea..1bef382 100644

--- a/include/tccdefs.h

+++ b/include/tccdefs.h

@@ -91,6 +91,11 @@

# if __SIZEOF_POINTER__ == 8

 /* FIXME, __int128_t is used by setjump */

 #define __int128_t struct { unsigned char _dummy[16] 
__attribute((aligned(16))); }

+#define __SIZEOF_SIZE_T__ 8

+#define __SIZEOF_PTRDIFF_T__ 8

+#else

+#define __SIZEOF_SIZE_T__ 4

+#define __SIZEOF_PTRDIFF_T__ 4

# endif

 #elif defined __FreeBSD_kernel__

diff --git a/lib/bcheck.c b/lib/bcheck.c

index 0379b6e..3f66b1c 100644

--- a/lib/bcheck.c

+++ b/lib/bcheck.c

@@ -226,10 +226,13 @@ typedef struct alloca_list_struct {

#elif defined(__OpenBSD__)

#define BOUND_TID_TYPE   pid_t

#define BOUND_GET_TIDsyscall (SYS_getthrid)

-#elif defined(__FreeBSD__) || defined(__NetBSD__)

+#elif defined(__FreeBSD__)

#define BOUND_TID_TYPE   pid_t

-#define BOUND_GET_TID0

-#elif defined(__i386__) || defined(__x86_64__) || defined(__arm__) || 
defined(__aarch64__) || defined(__riscv)

+#define BOUND_GET_TIDsyscall (SYS_thr_self)

+#elif defined(__NetBSD__)

+#define BOUND_TID_TYPE   pid_t

+#define BOUND_GET_TIDsyscall (SYS_lwp_self)

+#elif defined(__linux__)

#define BOUND_TID_TYPE   pid_t

#define BOUND_GET_TIDsyscall (SYS_gettid)

#else

 

There is a typo in the netbsd part. See attached corrected patch.
The other parts are ok.

Herman



 

 

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Herman ten Brugge via Tinycc-devel
Sent: Tuesday, February 08, 2022 19:03
To: tinycc-devel@nongnu.org
Cc: Herman ten Brugge
Subject: Re: [Tinycc-devel] Fwd: [PATCH] freebsd support update proposal

 

On 2/7/22 10:54, grischka wrote:

David CARLIER wrote: 




Hi if nobody objects, I may apply the last aforementioned patch 
sometime next week. 


Since you asked: 





--- a/tests/tests2/46_grep.c 
+++ b/tests/tests2/46_grep.c 
@@ -14,6 +14,9 @@ 
  * included and reference made to  the  fact  that  reproduction 
  * privileges were granted by DECUS. 
  */ 
+#if defined(__FreeBSD__) 
+#include  
+#endif 
 #include  
 #include  
 #include // tolower() 


- what is this (nobody will know without a comment) 
- sys/cdefs.h is not that a user file should include 
- 46_grep.c looks really "innocent" enough that it should compile 
  OOTB on any C and platform 
- in general, when tests fail, we want the problem be fixed, not the test 

Maybe you can find a better solution, or maybe someone else can... 

-- gr 


I checked the stdio.h file on freebsd 12.2 and 13.0 and see:

.
#ifndef _STDIO_H_ 
#define _STDIO_H_ 

#include 
.

So the file is included in stdio.h for freebsd.
What version of freebsd are you using?

Herman

PS:
I just added a fix for freebsd 13.0 in mob.











Kind regards. 

 

 

 

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

Re: [Tinycc-devel] Fwd: [PATCH] freebsd support update proposal

[Christian Jullien]

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

+++ b/include/tccdefs.h

@@ -91,6 +91,11 @@

# if __SIZEOF_POINTER__ == 8

 /* FIXME, __int128_t is used by setjump */

 #define __int128_t struct { unsigned char _dummy[16] 
__attribute((aligned(16))); }

+#define __SIZEOF_SIZE_T__ 8

+#define __SIZEOF_PTRDIFF_T__ 8

+#else

+#define __SIZEOF_SIZE_T__ 4

+#define __SIZEOF_PTRDIFF_T__ 4

# endif

 #elif defined __FreeBSD_kernel__

diff --git a/lib/bcheck.c b/lib/bcheck.c

index 0379b6e..3f66b1c 100644

--- a/lib/bcheck.c

+++ b/lib/bcheck.c

@@ -226,10 +226,13 @@ typedef struct alloca_list_struct {

#elif defined(__OpenBSD__)

#define BOUND_TID_TYPE   pid_t

#define BOUND_GET_TIDsyscall (SYS_getthrid)

-#elif defined(__FreeBSD__) || defined(__NetBSD__)

+#elif defined(__FreeBSD__)

#define BOUND_TID_TYPE   pid_t

-#define BOUND_GET_TID0

-#elif defined(__i386__) || defined(__x86_64__) || defined(__arm__) || 
defined(__aarch64__) || defined(__riscv)

+#define BOUND_GET_TIDsyscall (SYS_thr_self)

+#elif defined(__NetBSD__)

+#define BOUND_TID_TYPE   pid_t

+#define BOUND_GET_TIDsyscall (SYS_lwp_self)

+#elif defined(__linux__)

#define BOUND_TID_TYPE   pid_t

#define BOUND_GET_TIDsyscall (SYS_gettid)

#else

 

 

 

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Herman ten Brugge via Tinycc-devel
Sent: Tuesday, February 08, 2022 19:03
To: tinycc-devel@nongnu.org
Cc: Herman ten Brugge
Subject: Re: [Tinycc-devel] Fwd: [PATCH] freebsd support update proposal

 

On 2/7/22 10:54, grischka wrote:

David CARLIER wrote: 



Hi if nobody objects, I may apply the last aforementioned patch 
sometime next week. 


Since you asked: 




--- a/tests/tests2/46_grep.c 
+++ b/tests/tests2/46_grep.c 
@@ -14,6 +14,9 @@ 
  * included and reference made to  the  fact  that  reproduction 
  * privileges were granted by DECUS. 
  */ 
+#if defined(__FreeBSD__) 
+#include  
+#endif 
 #include  
 #include  
 #include // tolower() 


- what is this (nobody will know without a comment) 
- sys/cdefs.h is not that a user file should include 
- 46_grep.c looks really "innocent" enough that it should compile 
  OOTB on any C and platform 
- in general, when tests fail, we want the problem be fixed, not the test 

Maybe you can find a better solution, or maybe someone else can... 

-- gr 


I checked the stdio.h file on freebsd 12.2 and 13.0 and see:

.
#ifndef _STDIO_H_ 
#define _STDIO_H_ 

#include 
.

So the file is included in stdio.h for freebsd.
What version of freebsd are you using?

Herman

PS:
I just added a fix for freebsd 13.0 in mob.









Kind regards. 

 

 

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

Re: [Tinycc-devel] Optimizing for avx512

[Christian Jullien]

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 [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Yair Lenga
Sent: Sunday, February 06, 2022 08:59
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Optimizing for avx512

Thank you for feedback. I understand what are the limits of tcc. In my specific 
problem, I am trying to speed up user-provided expression in a simulation of 
100 paths. Can I use the avx512 build-in - e.g. work on 8 double precision 
values with one operation - practically reducing the 100 evaluations to 13 
(100/8) ?

User expressions are all in the form that can be handle by AVX SIMD 
instructions: add, multiple, … 

Thanks, yair. 

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


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

Re: [Tinycc-devel] Optimizing for avx512

[Christian Jullien]

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 
executed without breaking the pipeline. i.e. instructions nearly run in //

Tcc, which is one pass compiler, definitely loses on this point. On the other 
end, one pass makes it damn fast and that's why we love it.

We can't have the butter and the money for the butter

-Original Message-
From: rem...@tutanota.com [mailto:rem...@tutanota.com] 
Sent: Saturday, February 05, 2022 16:10
To: Jullien; Tinycc Devel
Cc: Tinycc Devel
Subject: Re: [Tinycc-devel] Optimizing for avx512

5 Φεβ 2022, 11:01 Από eli...@orange.fr:

> The price to pay its really fast compilation is that the generated code is 
> poor compared to gcc, clang or vc++ (among others). Depending on your 
> program, consider it is roughly 2 to 4x slower.
>
I would say that this is not always the case. And correct me if I'm wrong but 
aren't optimization (except few of them) mostly because the programmer wrote 
bad code and the compiler found a better instructions to do the same thing? 
Inline assembly exists in the end so if you really really care about 
performance, you should probably use inline assembly in the most critical 
algorithms/functions. I've seen some code running the same on TCC and GCC so I 
suppose optimization doesn't always makes magic. Or you may have a 5% increase 
or even less. In any case, I would suggest using both TCC and then GCC/Clang 
for the critical parts that will be hugely favored by the optimizations these 
compilers can do.

But of course just my opinion on the topic.


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

Re: [Tinycc-devel] Optimizing for avx512

[Christian Jullien]

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, clang or vc++ (among others). Depending on your program, 
consider it is roughly 2 to 4x slower.

If you want a fast executable, use a C compiler that generates fast code (read 
gcc/clang).

You can combine tcc and gcc as I do: compile and test your code with tcc and, 
when it works, switch to gcc/clang with all possible optimization. Hint PGO, is 
a valuable way to make your gcc optimized code even faster. I would say between 
10 and 20%.

C.

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Yair Lenga
Sent: Saturday, February 05, 2022 09:52
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] Optimizing for avx512

I have a project which is running a user simulation - time consuming - user 
defined code. I hope that performance can be improved using SIMD instructions.

What is the optimization level supported by libtcc ? Can it generate optimized 
code for AVX512 ? See 4.x. Documentation indicate optimization done at 
statement level - possible to use SIMD functions directly ?

Thanks, yair

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


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

Re: [Tinycc-devel] [PATCH] freebsd support update proposal

[Christian Jullien]

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 version considering feedbacks. Cheers.

On Sun, 30 Jan 2022 at 13:43, David CARLIER  wrote:
>
> Hi here a revised version.
>
> Cheers.
>
> On Sat, 29 Jan 2022 at 17:38, David CARLIER  wrote:
> >
> > fair enough. thanks.
> >
> > On Sat, 29 Jan 2022 at 17:09, David CARLIER  wrote:
> > >
> > > Hi and thanks here a new version of the patchset.
> > >
> > > On Sat, 29 Jan 2022 at 00:18, David CARLIER  wrote:
> > > >
> > > > adding few constants for compile time and fetching thread id for bound 
> > > > check.


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

Re: [Tinycc-devel] [PATCH] freebsd support update proposal

[Christian Jullien]

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__)
 #define BOUND_TID_TYPE   pid_t
 #define BOUND_GET_TIDsyscall (SYS_getthrid)
-#elif defined(__FreeBSD__) || defined(__NetBSD__)
+#elif defined(__FreeBSD__)
 #define BOUND_TID_TYPE   pid_t
-#define BOUND_GET_TID0
+#define BOUND_GET_TIDsyscall (SYS_thr_self)
+#elif defined(__NetBSD__)
+#define BOUND_TID_TYPE   pid_t
+#define BOUND_GET_TIDsyscall (SYS_lwp_self)
 #elif defined(__i386__) || defined(__x86_64__) || defined(__arm__) || 
defined(__aarch64__) || defined(__riscv)
 #define BOUND_TID_TYPE   pid_t
 #define BOUND_GET_TIDsyscall (SYS_gettid)

But this is your patch not mine.

Grischka, I also think that the last #elif should be relate to __linux__ not 
for specific CPU, so complete patch for bcheck should be

diff --git a/lib/bcheck.c b/lib/bcheck.c
index 0379b6e..3f66b1c 100644
--- a/lib/bcheck.c
+++ b/lib/bcheck.c
@@ -226,10 +226,13 @@ typedef struct alloca_list_struct {
 #elif defined(__OpenBSD__)
 #define BOUND_TID_TYPE   pid_t
 #define BOUND_GET_TIDsyscall (SYS_getthrid)
-#elif defined(__FreeBSD__) || defined(__NetBSD__)
+#elif defined(__FreeBSD__)
 #define BOUND_TID_TYPE   pid_t
-#define BOUND_GET_TID0
-#elif defined(__i386__) || defined(__x86_64__) || defined(__arm__) || 
defined(__aarch64__) || defined(__riscv)
+#define BOUND_GET_TIDsyscall (SYS_thr_self)
+#elif defined(__NetBSD__)
+#define BOUND_TID_TYPE   pid_t
+#define BOUND_GET_TIDsyscall (SYS_lwp_self)
+#elif defined(__linux__)
 #define BOUND_TID_TYPE   pid_t
 #define BOUND_GET_TIDsyscall (SYS_gettid)
 #else

Wdyt?

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of David CARLIER
Sent: Sunday, January 30, 2022 14:44
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] [PATCH] freebsd support update proposal

Hi here a revised version.

Cheers.

On Sat, 29 Jan 2022 at 17:38, David CARLIER  wrote:
>
> fair enough. thanks.
>
> On Sat, 29 Jan 2022 at 17:09, David CARLIER  wrote:
> >
> > Hi and thanks here a new version of the patchset.
> >
> > On Sat, 29 Jan 2022 at 00:18, David CARLIER  wrote:
> > >
> > > adding few constants for compile time and fetching thread id for bound 
> > > check.


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

Re: [Tinycc-devel] Transputer Target

[Christian Jullien]

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 parallelism 
C extensions in tcc kernel.

I suppose this port effort targets T8 series? Which boards/OS?

C.

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of rempas via Tinycc-devel
Sent: Saturday, January 29, 2022 21:01
To: David Smith via Tinycc-devel
Cc: rem...@tutanota.com; Tinycc Devel; David Smith
Subject: Re: [Tinycc-devel] Transputer Target

29 Ιαν 2022, 17:39 Από tinycc-devel@nongnu.org:

> Hi!
>
> Back in 2020 I made a concerted effort to add Transputer.
>
> https://github.com/agentdavo/tinycc-transputer
>
> I soon ran into a brick wall where my knowledge wavered. Any TinyCC experts 
> out there that could help?
>
> Sent from my iPhone
>
What is a "Transputer"? I searched it and the only thing I was able to find was:

https://en.wikipedia.org/wiki/Transputer

Also did you really sent it from your iPhone?

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


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

Re: [Tinycc-devel] [PATCH] freebsd support update proposal

[Christian Jullien]

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 me. I let you decide to do with this 
patch if official maintainer(s) don't react to your patch.

My experience is that small patches used to better support specific ports are 
generally accepted.

Christian


-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of David CARLIER
Sent: Saturday, January 29, 2022 18:09
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] [PATCH] freebsd support update proposal

Hi and thanks here a new version of the patchset.

On Sat, 29 Jan 2022 at 00:18, David CARLIER  wrote:
>
> adding few constants for compile time and fetching thread id for bound check.


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

Re: [Tinycc-devel] Can a biggener (and idiot) like me read and understand TCC's backend so I can create my own frontend with it?

[Christian Jullien]

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 internal code, then choose a backend (for example C) that 
generates code corresponding to your intermediate code.

 

You’ll learn of lot of things and you’ll get 80% of the knowledge you’ll need 
to write serious things.

 

This globally how works my Lisp compiler from Lisp files up to standalone 
executable.

 

See https://en.wikipedia.org/wiki/OpenLisp#Compiler 

 

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of ian
Sent: Saturday, January 29, 2022 10:43
To: rempas via Tinycc-devel
Subject: Re: [Tinycc-devel] Can a biggener (and idiot) like me read and 
understand TCC's backend so I can create my own frontend with it?

 

Hi

One thing or the other :

- you wanna learn asm or algorithmics, and it's not the best place; but you 
obviously need to have to know them a "few",

- or, you already know how to code something in ASM, and then the suggested 
book about how to make an interpreter is the good starting point for you.

Rgds

Le 29/01/2022 à 10:08, rempas via Tinycc-devel a écrit :

29 Ιαν 2022, 03:20 Από s...@conman.org:
 

It was thus said that the Great rempas via Tinycc-devel once stated:
 

I would advice you to start with this 
https://craftinginterpreters.com/contents.html first.
 
The rest will follow before you know it.

 
Thanks! However, I don't understand how this will help me. I mean, I don't
even want to create an intepreter to begin with. So this has nothing to do
with what I want to make. Unless you are referring to the frontend so in
this case, It will probably be a good idea to read this book. Or maybe I
should make an intepreter in the end? Hm
 

 
It's interpreters all the way down (what do you think CPUs do with machine
code?  They interpret it).  Also, if you have parsed code into a form you
can interpret, you have enough information to generate machine code.
 
 -spc
 
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
 

I don't know if I'm that stupid but I really don't understand. I know that the 
CPU interprets the instructions but an interpreter will use a programming 
language to interpret. For example, the following statement:
 
`println("Hello from my lang: {}", "BestLang")`
 
will be translated to (suppose the interpreted is written in C) and then be 
executed:
 
`printf("Hello from my lang: %s", "BestLang);`
 
So how is this going to teach my assembly and how the instructions are 
represented in binary? The book specifically says that it won't work with 
teaching assembly. The interpreted is a binary that takes source code and 
executes it. It doesn't create a binary. So I really don't understand what's 
going on here...
 
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

-- 
-- sibian0...@gmail.com
-- Développeur compulsif

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

Re: [Tinycc-devel] [PATCH] freebsd support update proposal

[Christian Jullien]

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 alloca_list_struct {

#elif defined(__OpenBSD__)

#define BOUND_TID_TYPE   pid_t

#define BOUND_GET_TIDsyscall (SYS_getthrid)

-#elif defined(__FreeBSD__) || defined(__NetBSD__)

+#elif defined(__FreeBSD__)

#define BOUND_TID_TYPE   pid_t

-#define BOUND_GET_TID0

+#define BOUND_GET_TIDsyscall (SYS_thr_self)

+#elif  defined(__NetBSD__)

+#define BOUND_TID_TYPE   pid_t

+#define BOUND_GET_TIDsyscall (SYS_lwp_self)

#elif defined(__i386__) || defined(__x86_64__) || defined(__arm__) || 
defined(__aarch64__) || defined(__riscv)

#define BOUND_TID_TYPE   pid_t

#define BOUND_GET_TIDsyscall (SYS_gettid)

diff --git a/tccpp.c b/tccpp.c

index 6b828c9..0a1b0fd 100644

--- a/tccpp.c

+++ b/tccpp.c

@@ -3743,6 +3743,10 @@ static void tcc_predefs(TCCState *s1, CString *cs, int 
is_asm)

#endif

 cstr_printf(cs, "#define __SIZEOF_POINTER__ %d\n", PTR_SIZE);

 cstr_printf(cs, "#define __SIZEOF_LONG__ %d\n", LONG_SIZE);

+#ifdef TARGETOS_FreeBSD

+cstr_printf(cs, "#define __SIZEOF_SIZE_T__ %d\n", LONG_SIZE);

+cstr_printf(cs, "#define __SIZEOF_PTRDIFF_T__ %d\n", PTR_SIZE);

+#endif

 if (!is_asm) {

   putdef(cs, "__STDC__");

   cstr_printf(cs, "#define __STDC_VERSION__ %dL\n", s1->cversion);

 

 

I see that the test suite on latest FreeBSD 13.x (using this patch) raises 
errors like:

 

--- 97_utf8_string_literal.expect   2022-01-29 06:29:33.110372000 +0100

+++ 97_utf8_string_literal.output   2022-01-29 06:57:36.509445000 +0100

@@ -1 +1,4 @@

-0068 0065 006C 006C 006F 0024 0024 4F60 597D 00A2 00A2 4E16 754C 20AC 20AC 
0077 006F 0072 006C 0064

+In file included from 97_utf8_string_literal.c:3:

+In file included from /usr/include/wchar.h:69:

+In file included from /usr/include/_ctype.h:97:

+/usr/include/runetype.h:94: error: ';' expected (got "const")

gmake[3]: *** [Makefile:133: 97_utf8_string_literal.test] Error 1

 

Which are related to TLS declaration on runetype.h

 

extern _Thread_local const _RuneLocale *_ThreadRuneLocale;

 

 

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of David CARLIER
Sent: Saturday, January 29, 2022 01:19
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] [PATCH] freebsd support update proposal

 

adding few constants for compile time and fetching thread id for bound check.

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

Re: [Tinycc-devel] Beginner issue when linking 7z LZMA SDK to dietlibc

[Christian Jullien]

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 Christian

Solved. Dietlibc's start.o is calling stackgap before entering main
for x86_64 by default. Everything goes well if I remove stackgap in
dietfeatures.h.

BR Sandro

Am Fr., 21. Jan. 2022 um 10:59 Uhr schrieb Sandro :
>
> Hello Christian
>
> Thanks for the reply! I checked the latest mob tinycc-4e0e9b8.tar.gz.
> The result is the same. :(
>
> What are the differences between gnu ld and tcc linker?
>
> BR Sandro
>
> 
> 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: [Tinycc-devel] Beginner issue when linking 7z LZMA SDK to dietlibc
>
> Hello Everyone
>
> I'm using tcc on sabotage. I use below to link LZMA to dietlibc (the
> start.o and libc.a from dietlibc are in current path):
>
> tcc -nostdlib start.o LzmaUtil.o Alloc.o LzFind.o LzmaEnc.o LzmaDec.o
> 7zFind.o 7zStream.o -L. -lc
>
> Linking succeeds without any error but always segfault when run the a.out.
>
> If I use ld from binutils, a.out can run without any problems.
>
> If adding linker flag -static, there will be the same situation.
>
> Anyone could advise on how to fix this? Thank you very much!
>
> Versions:
> tcc-0.9.27.tar.bz2
> dietlibc-0.34.tar.xz
> lzma1900.7z
> sabotage-1.1.24-x86_64-desktop-1f74666.img.xz
>
> Best regards
> Sandro Yang

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


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

Re: [Tinycc-devel] Error when manipulating doubles in stack win64

[Christian Jullien]

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.

test.c
test.c(4): error C2371: 'float_t': redefinition; different basic types
C:\Program Files (x86)\Windows 
Kits\10\include\10.0.22000.0\ucrt\corecrt_math.h(59): note: see declaration of 
'float_t'

c:\usr\jullien\openlisp>gcc test.c -o test.exe && test.exe
test.c:4:16: error: conflicting types for ‘float_t’; have ‘double’
4 | typedef double float_t;
  |^~~
In file included from test.c:1:
/usr/include/math.h:160:20: note: previous declaration of ‘float_t’ with type 
‘float_t’ {aka ‘float’}
  160 | typedef float  float_t;
  |^~~

I renamed float_t to FLOAT_T and this time cl, gcc and tcc all produce the same 
result

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.

test.c
Microsoft (R) Incremental Linker Version 14.30.30706.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:test.exe
test.obj
> bb=8790 aa=8790
> err - =0
> err / =1

c:\usr\jullien\openlisp>gcc test.c -o test.exe && test.exe
> bb=8790 aa=8790
> err - =0
> err / =1

c:\usr\jullien\openlisp>tcc -m64 test.c -o test.exe && test.exe
> bb=8790 aa=8790
> err - =0
> err / =1

I'm using mob on Windows:
c:\usr\jullien\openlisp>tcc -v
tcc version 0.9.27 mob:4e0e9b8 (x86_64 Windows)

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Clement Franchini
Sent: Thursday, January 20, 2022 11:27
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] Error when manipulating doubles in stack win64

Hi,
we encountered an issue when manipulating doubles in the last version (0.9.27) 
of tcc. It looks like the stack is not correctly managed for that type.

The joined test file compute the same values in two different ways. The results 
should be the same, but they're different.

On GNU/Linux, it works perfectly (I only tested 64 bits)

On Windows 10 (64 bits):

32bits: If I compile using -m32, it works.

64bits: if I don't specify or use -m64 it failed. I also did the test by using 
float instead of double and it works. So the problem only occurs for double on 
64 bits Windows.

Cordialement/Regards.
--
Clément Franchini


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

Re: [Tinycc-devel] Beginner issue when linking 7z LZMA SDK to dietlibc

[Christian Jullien]

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: [Tinycc-devel] Beginner issue when linking 7z LZMA SDK to dietlibc

Hello Everyone

I'm using tcc on sabotage. I use below to link LZMA to dietlibc (the
start.o and libc.a from dietlibc are in current path):

tcc -nostdlib start.o LzmaUtil.o Alloc.o LzFind.o LzmaEnc.o LzmaDec.o
7zFind.o 7zStream.o -L. -lc

Linking succeeds without any error but always segfault when run the a.out.

If I use ld from binutils, a.out can run without any problems.

If adding linker flag -static, there will be the same situation.

Anyone could advise on how to fix this? Thank you very much!

Versions:
tcc-0.9.27.tar.bz2
dietlibc-0.34.tar.xz
lzma1900.7z
sabotage-1.1.24-x86_64-desktop-1f74666.img.xz

Best regards
Sandro Yang

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


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

Re: [Tinycc-devel] Re : Compile Libbtc for Apple M1 with tcc

[Christian Jullien]

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__ __ORDER_LITTLE_ENDIAN__
#define __ORDER_BIG_ENDIAN__ 4321
#define __ORDER_LITTLE_ENDIAN__ 1234

jullien@mobley:~ $ gcc -dM -E - < /dev/null | grep END | sort
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __LITTLE_ENDIAN__ 1
#define __ORDER_BIG_ENDIAN__ 4321
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __ORDER_PDP_ENDIAN__ 3412

You can see that __LITTLE_ENDIAN__ is missing for tcc

I've just added this missing definition on mod, you can test it right now.

C.

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of david.k...@libertysurf.fr
Sent: Tuesday, January 11, 2022 03:48
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] Re : Compile Libbtc for Apple M1 with tcc

Hi, the M1 chip is an ARM64 processor, not a x86_64 one.

Perhaps the ARM support of TCC is not up to par with its x86 counterpart.

Good luck anyway.

Regards.

- Mail d'origine -
De: Niklas Rosencrantz 
À: tinycc-devel@nongnu.org
Envoyé: Mon, 10 Jan 2022 23:49:04 +0100 (CET)
Objet: [Tinycc-devel] Compile Libbtc for Apple M1 with tcc

Hello,

Trying to compile Libbtc for Apple M1 with tcc. It worked with an Apple
Intel machine and setting CC=tcc. Since tcc can build it on the Intel with
macOS I try ask here if you might know the cause of the failure. With the
Apple M1 the following message comes from make

In file included from ./include/btc/serialize.h:34:
In file included from ./include/btc/portable_endian.h:22:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/libkern/OSByteOrder.h:314:
error: #error Unknown endianess.
make[1]: *** [src/tools/bitcointool-bitcointool.o] Error 1


Build Options:
  with ecmult precomp = yes
  with external callbacks = no
  with benchmarks = yes
  with tests  = yes
  with openssl tests  = no
  with coverage   = no
  module ecdh = no
  module recovery = yes
  module extrakeys= no
  module schnorrsig   = no

  asm = no
  ecmult window size  = 15
  ecmult gen prec. bits   = 4

  valgrind= no
  CC  = tcc
  CFLAGS  = -O2 -fvisibility=hidden -std=c89 -pedantic
-Wall -Wextra -Wcast-align -Wnested-externs -Wshadow -Wstrict-prototypes
-Wundef -Wno-unused-function -Wno-long-long -Wno-overlength-strings -W -g
  CPPFLAGS= -I/opt/homebrew/opt/valgrind/include
  LDFLAGS =

  CC_FOR_BUILD= tcc
  CFLAGS_FOR_BUILD= -O2 -fvisibility=hidden -std=c89 -pedantic
-Wall -Wextra -Wcast-align -Wnested-externs -Wshadow -Wstrict-prototypes
-Wundef -Wno-unused-function -Wno-long-long -Wno-overlength-strings -W -g
  CPPFLAGS_FOR_BUILD  = -I/opt/homebrew/opt/valgrind/include
  LDFLAGS_FOR_BUILD   =

Options used to compile and link:
  with wallet   = yes
  with tools= yes
  with net  = yes

  target os = darwin

  CC= tcc
  CFLAGS= -g -O2 -W -std=gnu99 -pedantic -Wno-unused-function
-Wno-long-long -Wno-overlength-strings -Werror=return-type
  CXX   =
  CXXFLAGS  =
  LDFLAGS   =


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


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

Re: [Tinycc-devel] CFront for TinyCC?

[Christian Jullien]

The main problem is that you're not supposed to use it but just study it.  
You can for example write few lines of pre-iso C++ and see how an
implementation (the CFront) translates it to pure C.
It may be useful to see a possible implementation of vtbl and virtual
function calls for example. The ARM from Stroustrup is a very valuable
source to understand possible internal representation of C++ in C.

Don't expect to write real C++ code which, except for simple example, will
not run on any other implementations.

If you write anything with CFront, you'll have to rewrite your code for any
modern C++ compiler.

We don't have the permission to extend Cfront, for the best, we are just
allowed to make few patches to let it work on the target C compiler. No
more!!

We are not allowed to fix bugs or implement missing things from any of the
C++ standards.

So, Cfront interest is very limited.


-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 in
 <000c01d7cff0$b9c009b0$2d401d10$@orange.fr>:
 |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#rele\
 |ase_30
 |"The source code in this section is posted with the permission of the \
 |copyright owner for historical research purposes only."
 |
 |It's fine if you use it within this scope otherwise you should not \
 |promote this dev. as a way to have a "kind of" C++ on top of tcc.

Oh i _always_ hated that thing one had to read after egcs ended in
g++ saying "generates real object code"!
I love languages like Nim (never used it but i think it really
rocks programmers) who provide a syntax and hints that rock
programmers, but preprocesses the outcome to plain C that can be
build with basic compilers!  Isn't that just fantastic??

However as far as i know they simply failed to pimp that thing for
templates etc, which is why they gave up on it?  I personally
would love to be able to write C+, a bit of namespaces, simple
templates and objects with methods (as opposed to functions with
objects) on top of plain C.  That is overly cool.

I did not know about cfront-3, thanks for the pointer, i will try
it once i have new bandwidth.  It once tried to bring cfront to
live from an archived version from the beginning of the 90s or so,
i have forgotten where that came from.  Non-Plan9.  But i gave up,
too much effort for some island that will never make it.

Cool!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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


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

Re: [Tinycc-devel] CFront for TinyCC?

[Christian Jullien]

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 in this section is posted with the permission of the copyright 
owner for historical research purposes only."

It's fine if you use it within this scope otherwise you should not promote this 
dev. as a way to have a "kind of" C++ on top of tcc.

Christian


-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Domingo Alvarez Duarte
Sent: Tuesday, November 02, 2021 14:07
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] CFront for TinyCC?

Hello !

After making tinycc fully reentrant here 
https://github.com/mingodad/tinycc I decided to have a look at cfront 
and after a week of work on a fork from seiko2 I've got it to build for 
32/64 bits for linux here https://github.com/mingodad/cfront-3 , it also 
build on OSX and MYSYS2 with a bit of dirty tweaking that I need to 
figure out how to clean up.

I also fixed the parser to build with bison but the generated parser 
doesn't work as expected, need more investigation because bison doesn't 
find the same conflicts as byacc in a few places.

I already read the prior messages and understand the implications of the 
license, but for research and history preservation I think it was worth 
the trouble so far.

It can build itself through valgrind without any invalid memory access 
(of course it leaks memory as usual for this kind of software and it's 
epoch).

If anyone want/can give it a try and give any feedback I appreciate and  
thank you in advance !

Cheers !


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


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

Re: [Tinycc-devel] [macOS] Monterey patch

[Christian Jullien]

Hum, after reinstalling xcode with "xcode-select -install" it also added
missing MacOXS.sdk symlinks.

 

$ ls -ls /Library/Developer/CommandLineTools/SDKs

0 lrwxr-xr-x  1 root  wheel   14 Oct 30 16:53 MacOSX.sdk -> MacOSX12.0.sdk

0 drwxr-xr-x  7 root  wheel  224 Nov 30  2020 MacOSX11.1.sdk

0 drwxr-xr-x  7 root  wheel  224 Oct 30 16:53 MacOSX11.3.sdk

0 lrwxr-xr-x  1 root  wheel   14 Oct 30 16:52 MacOSX11.sdk -> MacOSX11.3.sdk

0 drwxr-xr-x  7 root  wheel  224 Oct 30 16:52 MacOSX12.0.sdk

0 lrwxr-xr-x  1 root  wheel   14 Oct 30 16:51 MacOSX12.sdk -> MacOSX12.0.sdk

 

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/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 days.

 

diff --git a/tccmacho.c b/tccmacho.c

index 57c62c3..5ad62d1 100644

--- a/tccmacho.c

+++ b/tccmacho.c

@@ -874,10 +874,13 @@ ST_FUNC void tcc_add_macos_sdkpath(TCCState* s)

 int (*f)(unsigned int, char**) = dlsym(xcs, "xcselect_host_sdk_path");

 cstr_new();

 if (f) f(1, );

-if (sdkroot)

+if (sdkroot) {

 pos = strstr(sdkroot,"SDKs/MacOSX");

-if (pos)

-cstr_printf(, "%.*s.sdk/usr/lib", (int)(pos - sdkroot + 11),
sdkroot);

+}

+if (pos) {

+int len = strlen(pos);

+cstr_printf(, "%.*s/usr/lib", (int)(pos - sdkroot + len),
sdkroot);

+}

 /* must use free from libc directly */

#pragma push_macro("free")

#undef free

 

There are also few errors I'll try to identify:

 

Test: 108_constructor...

--- 108_constructor.expect  2021-10-29 17:29:19.0 +0200

+++ 108_constructor.output  2021-10-29 18:15:43.0 +0200

@@ -1,3 +1,2 @@

constructor

main

-destructor

make[3]: *** [108_constructor.test] Error 1

Test: 109_float_struct_calling...

Test: 110_average...

Test: 111_conversion...

Test: 112_backtrace...

Test: 114_bound_signal...

--- 114_bound_signal.expect 2021-10-29 17:29:19.0 +0200

+++ 114_bound_signal.output 2021-10-29 18:15:43.0 +0200

@@ -1,2 +0,0 @@

-start

-end

make[3]: *** [114_bound_signal.test] Error 1

 

Christian

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

[Tinycc-devel] [macOS] Monterey patch

[Christian Jullien]

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 days.

 

diff --git a/tccmacho.c b/tccmacho.c

index 57c62c3..5ad62d1 100644

--- a/tccmacho.c

+++ b/tccmacho.c

@@ -874,10 +874,13 @@ ST_FUNC void tcc_add_macos_sdkpath(TCCState* s)

 int (*f)(unsigned int, char**) = dlsym(xcs, "xcselect_host_sdk_path");

 cstr_new();

 if (f) f(1, );

-if (sdkroot)

+if (sdkroot) {

 pos = strstr(sdkroot,"SDKs/MacOSX");

-if (pos)

-cstr_printf(, "%.*s.sdk/usr/lib", (int)(pos - sdkroot + 11),
sdkroot);

+}

+if (pos) {

+int len = strlen(pos);

+cstr_printf(, "%.*s/usr/lib", (int)(pos - sdkroot + len),
sdkroot);

+}

 /* must use free from libc directly */

#pragma push_macro("free")

#undef free

 

There are also few errors I'll try to identify:

 

Test: 108_constructor...

--- 108_constructor.expect  2021-10-29 17:29:19.0 +0200

+++ 108_constructor.output  2021-10-29 18:15:43.0 +0200

@@ -1,3 +1,2 @@

constructor

main

-destructor

make[3]: *** [108_constructor.test] Error 1

Test: 109_float_struct_calling...

Test: 110_average...

Test: 111_conversion...

Test: 112_backtrace...

Test: 114_bound_signal...

--- 114_bound_signal.expect 2021-10-29 17:29:19.0 +0200

+++ 114_bound_signal.output 2021-10-29 18:15:43.0 +0200

@@ -1,2 +0,0 @@

-start

-end

make[3]: *** [114_bound_signal.test] Error 1

 

Christian

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

Re: [Tinycc-devel] Making tinycc fully reentrant

[Christian Jullien]

Thanks, I hope maintainers will find an interest work your work.

C.

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Domingo Alvarez Duarte
Sent: Friday, October 22, 2021 07:42
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Making tinycc fully reentrant

Hello Christian !

Thank you for reply !

I also noticed that there was some problems when trying to compile for 
arm64 on Android under termux.

I'll put my changes here now https://github.com/mingodad/tinycc.

I did reverted all my changes !

Cheers !

On 22/10/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 strongly suggest you revert your all changes as, among others, it breaks
>
> - Windows:
> ../tccpe.c:871: warning: assignment from incompatible pointer type
> In file included from ../tcc.c:25:
> ../tcctools.c:442: error: 'S' undeclared
>
> - macOS
> In file included from tcc.c:21:
> In file included from ./tcc.h:362:
> ./libtcc.h:28:16: error: typedef redefinition with different types ('long' vs 
> '__darwin_off_t' (aka 'long long'))
>typedef long off_t;
> ^
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types/_off_t.h:31:33:
>  note: previous definition is here
> typedef __darwin_off_t  off_t;
>
> Christian
>
> -Original Message-
> From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] 
> On Behalf Of Domingo Alvarez Duarte
> Sent: Thursday, October 21, 2021 20:19
> To: tinycc-devel@nongnu.org
> Subject: [Tinycc-devel] Making tinycc fully reentrant
>
> Hello !
>
> I did it once in the past and did again moving almost all global
> variables to TCCState and on Ubuntu 18.04 x86_64 all tests from "make
> test" pass.
>
> It's a massive refactoring (3 full working days).
>
> Any comments/suggestions are welcome !
>
> Cheers !
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel

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


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

Re: [Tinycc-devel] Making tinycc fully reentrant

[Christian Jullien]

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, it breaks

- Windows:
../tccpe.c:871: warning: assignment from incompatible pointer type
In file included from ../tcc.c:25:
../tcctools.c:442: error: 'S' undeclared

- macOS
In file included from tcc.c:21:
In file included from ./tcc.h:362:
./libtcc.h:28:16: error: typedef redefinition with different types ('long' vs 
'__darwin_off_t' (aka 'long long'))
  typedef long off_t;
   ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types/_off_t.h:31:33:
 note: previous definition is here
typedef __darwin_off_t  off_t;

Christian

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Domingo Alvarez Duarte
Sent: Thursday, October 21, 2021 20:19
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] Making tinycc fully reentrant

Hello !

I did it once in the past and did again moving almost all global 
variables to TCCState and on Ubuntu 18.04 x86_64 all tests from "make 
test" pass.

It's a massive refactoring (3 full working days).

Any comments/suggestions are welcome !

Cheers !


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


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

Re: [Tinycc-devel] Opinions on constexpr being added to C2X?

[Christian Jullien]

Thanks,

Indeed, I see that __STDC_NO_COMPLEX__ is already defined for tcc which is 
correct. I missed this, sorry.

 

7.3 Complex arithmetic 

7.3.1 Introduction

1 The header  defines macros and declares functions that support 
complex

arithmetic.192)

2 Implementations that define the macro _ _STDC_NO_COMPLEX_ _ need not provide

this header nor support any of its facilities.

 

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Tyge Løvset
Sent: Monday, October 18, 2021 09:38
To: jull...@eligis.com; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Opinions on constexpr being added to C2X?

 

I added tgmath.h last year, which includes generic support for all non-complex 
math functions. As complex.h is optional in C11 and not included with tinycc, 
this should be fine.

 

I think any added C11 features should be welcome, C2X features are secondary, 
imo unless it is low-hanging fruit and easy to implement.

 

On constexpr, I  find it interesting for tinycc as it minimizes generated code 
- efficiency gains are not that important. Mutable types like in c++ are useful,

although it is possible to write functional style code 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  cabsf cabs   cabsl

expexpf   expexpl   cexpf cexp  cexpl

log  logflog  logl clogf  clogclogl

pow   powf pow   powl  cpowf   cpow cpowl

sqrtsqrtf  sqrtsqrtl   csqrtfcsqrt  csqrtl

sin  sinf sin  sinl csinf   csin
csinl

cos cosfcos coslccosf  ccos   ccosl

tan tanftan tanlctanf  ctan   ctanl

asinasinf  asinasinl   casinfcasin  casinl

acos   acosf acos   acosl  cacosf   cacos cacosl

atan   atanf atan   atanl  catanf   catan catanl

sinhsinhf  sinhsinhl   csinhfcsinh  csinhl

cosh   coshf cosh   coshl  ccoshf   ccosh ccoshl

tanh   tanhf tanh   tanhl  ctanhf   ctanh ctanhl

asinh asinhfasinh asinhlcasinhf  casinh   casinhl

acoshacoshf   acoshacoshl   cacoshf cacosh  cacoshl

atanhatanhf   atanhatanhl   catanhf catanh  catanhl

 

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis 
<mailto:tinycc-devel-bounces%2Beligis> =orange...@nongnu.org] On Behalf Of 
Elijah Stone
Sent: Sunday, October 17, 2021 01:09
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Opinions on constexpr being added to C2X?

 

Atomics are here now; I think the only thing missing is wide-chars/strings, no?

 

I have a patch to support a number of c11/c2x features (including widestrings), 
but the last time I 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 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.

> 

>  

> 

> M2c

> 

>  

> 

> From: Tinycc-devel 

> [mailto:tinycc-devel-bounces+eligis <mailto:tinycc-devel-bounces%2Beligis> 
> =orange...@nongnu.org] On Behalf Of 

> Marcus Johnson

> Sent: Thursday, October 14, 2021 10:36

> To: tinycc-devel@nongnu.org

> Subject: [Tinycc-devel] Opinions on constexpr being added to C2X?

> 

>  

> 

> There's a new proposal to add it, and the standard is especially interested 
> in hearing from small compiler devs their opinions on such a feature.

> 

> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2851.pdf

> 

> 

> 

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

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

Re: [Tinycc-devel] Opinions on constexpr being added to C2X?

[Christian Jullien]

➢ 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
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Opinions on constexpr being added to C2X?

[Christian Jullien]

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  cabsf cabs   cabsl

expexpf   expexpl   cexpf cexp  cexpl

log  logflog  logl clogf  clog
clogl

pow   powf pow   powl  cpowf   cpow cpowl

sqrtsqrtf  sqrtsqrtl   csqrtfcsqrt  csqrtl

sin  sinf sin  sinl csinf   csin
csinl

cos cosfcos coslccosf  ccos   ccosl

tan tanftan tanlctanf  ctan   ctanl

asinasinf  asinasinl   casinfcasin  casinl

acos   acosf acos   acosl  cacosf   cacos cacosl

atan   atanf atan   atanl  catanf   catan catanl

sinhsinhf  sinhsinhl   csinhfcsinh  csinhl

cosh   coshf cosh   coshl  ccoshf   ccosh ccoshl

tanh   tanhf tanh   tanhl  ctanhf   ctanh ctanhl

asinh asinhfasinh asinhlcasinhf  casinh   casinhl

acoshacoshf   acoshacoshl   cacoshf cacosh  cacoshl

atanhatanhf   atanhatanhl   catanhf catanh  catanhl

 

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of Elijah Stone
Sent: Sunday, October 17, 2021 01:09
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Opinions on constexpr being added to C2X?

 

Atomics are here now; I think the only thing missing is wide-chars/strings,
no?

 

I have a patch to support a number of c11/c2x features (including
widestrings), but the last time I 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 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.

> 

>  

> 

> M2c

> 

>  

> 

> From: Tinycc-devel 

> [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of 

> Marcus Johnson

> Sent: Thursday, October 14, 2021 10:36

> To: tinycc-devel@nongnu.org

> Subject: [Tinycc-devel] Opinions on constexpr being added to C2X?

> 

>  

> 

> There's a new proposal to add it, and the standard is especially
interested in hearing from small compiler devs their opinions on such a
feature.

> 

> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2851.pdf

> 

> 

> 

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

Re: [Tinycc-devel] Opinions on constexpr being added to C2X?

[Christian Jullien]

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.

 

M2c

 

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of Marcus Johnson
Sent: Thursday, October 14, 2021 10:36
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] Opinions on constexpr being added to C2X?

 

There's a new proposal to add it, and the standard is especially interested
in hearing from small compiler devs their opinions on such a feature.

 
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2851.pdf

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

[Tinycc-devel] Embedding Python on Linux requires -Xlinker -export-dynamic

[Christian Jullien]

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.

 

Another solution is to silently ignore "-Xlinker -export-dynamic" from tcc.
I can do that if you like.

 

Please tell me.

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

Re: [Tinycc-devel] Outdated .def files

[Christian Jullien]

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 and the stuff is now part of
gnumake trunk.

 

C.

 

From: pursuer2 [mailto:pursu...@qq.com] 
Sent: Sunday, September 19, 2021 11:38
To: jullien; tinycc-devel
Subject: Re: [Tinycc-devel] Outdated .def files

 

In my opinion, as tcc do not offer the complete libc on unix-like os,
Current Windows support in tcc which help tcc compile itself is enough. We
can recommand user to use tcc with compatible c library (like
"mingw","msvc","windows sdk"?) for other os-dependent feature.

 

I'm not familiar with Windows build system, these opinion is according to my
experience.

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

Re: [Tinycc-devel] Outdated .def files

[Christian Jullien]

GetVersionEx is also odd as it is stuck to 8 the version it returns for
Windows 10 and 11 by default.
To make it return the right version you need to call mt tool with a manifest
file like below.


 OpenLisp by Eligis
 
 
  
   
   
   
   
   
   
   
   
   
   
  
 
 
 
  
   

   
  
 


But tcc has no mt patching tool as you know.
To let tcc toolchain working without other Microsoft VC++ tools I wrote my
on mt version and I asked the group the permission to push it but got no
reply.
The tool is here:
https://sourceforge.net/p/wintcc/svn/HEAD/tree/ports/mt/mt.c
Feel free to take it if you like. It may be part of tcc front end like "tcc
-mt" similar to "tcc -ar"

Christian 

-Original Message-
From: grischka [mailto:gris...@gmx.de] 
Sent: Saturday, September 18, 2021 21:02
To: jull...@eligis.com; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] 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 purpose.

As far as I can see, "Windows 11" identifies itself as 10.0.21995(++),
that is "Windows 10" with a build number >= 21995.

And that information can be obtained simply with "GetVersion()" which
exists forever in all windoses.

While it seems that the API you just did add to the tinycc kernel32.def
already has been depreciated again:

 "VerifyVersionInfoA function (winbase.h)
  ...
  Note: This function has been deprecated for Windows 10. See 'targeting
  your applications for Windows' for more information."

And even the old GetVersionEx() was admittedly added only for the stupids:

 "The GetVersionEx function was developed because many existing
  applications err when examining the packed DWORD value returned
  by GetVersion, transposing the major and minor version numbers..."

(of course it's not the applications but the people who wrote them).

Seen that I'm inclined to think that much of the 3 times as big kernel32.def
from newer windoses that you did mention doesn't really serve a purpose
other
than to support an increasing stupidity (or at least the assumption of it)
?!?

Or otherwise that the purpose is to make people feel more stupid than they
really are:
"In time there will be a way to properly detect Windows 11, I'm sure
 Microsoft is still figuring out the most complicated way to make life
 more difficult for developers"
and
"Don't worry, they have a guy for that I'm sure."

comments from
https://www.techpowerup.com/forums/threads/gpu-z-2-40-2-vs-windows-11.283417
/

Really I don't care which scenario they want to prepare for with their OS,
but then again is is still up to us where we make TinyCC to go.

In any case saying "OUtdated .def files" means to me that you didn't really
understand anything of it.

As a fact the files were "outdated" already in their very first incarnation
when added in 2005 and haven't seen any significant changes since then.
Therefor "outdated" isn't really a category for something that never was
up-to-date nor ever even tried to be.

Btw. the easiest way to have all the functions of the windows system dll's
is just to delete the tinycc .def files on your computer.

--- grischka


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

Re: [Tinycc-devel] Outdated .def files

[Christian Jullien]

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 purpose.
Right after this push, I generated a kernel32.def from my Windows 10 machine
to see what are the differences from the version in tcc repo.
Diff is quite large as the latest kernel32.def is 3x times bigger.

Now the right question is. If I need xx function present in Windows yy and
not already in kernel32.def what should I do?
An easy, but very egoist, solution is to generate new versions of .def form
Windows yy kernel32.dll and use it **locally** to compile my project.
But other people will have to do the same for their own projects.

I have the impression that if you use a kernel32.def from a recent Windows
version you can still dynamic link with kernel32.dll as long as you only use
functions from this specific version.
Hence, an old kernel32.def prevents to use more recent API while a very
recent kernel32.def allows to use any version (but you may experience error
at runtime if the function you use is not present in kernel32.dll).

The most portable solution is of course to query function xx using
LoadLibrary/GetProcAddress but is it very tedious if you have a large number
of functions you want to use esp. if you target Windows versions all having
xx function. 

There is no good solution but, IMHO, an updated kernel32.def gives 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.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 you advice ?
>

Hi Christian,

didn't you already give the answer by your last commit that adds
3 functions to the kernel.def that we currently have.

You would not have done that if you wanted to replace it all together
with a newer version.

Not at least since you recently did promise not to touch the push button
until you actually did find the solution suited to stay for a decent
while without further intervention from either yourself or from other
people.

-- grischka



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

Re: [Tinycc-devel] Outdated .def files

[Christian Jullien]

If I use recent VC++ on Windows 10, I can limit myself to the set of API 
supported by XP and the result will (should) run on Windows XP.

If I however use specific Windows 10 API, it will hand on XP.

 

My opinion is that tcc should use a recent (latest?) kernel32.def and let the 
user decide what subset he supports.

 

In theory, _WIN32_WINNT should limit the subset an application can see by 
giving only the definitions available for a given version. I’m far from certain 
that our .h is aware of the different definitions.

A least a tcc developer will be able to supply its own declaration and use the 
associated definition in kernel32.def

 

M2c

 

From: avih [mailto:avih...@yahoo.com] 
Sent: Saturday, September 18, 2021 08:09
To: tinycc-devel@nongnu.org; jull...@eligis.com
Subject: Re: [Tinycc-devel] Outdated .def files

 

I _think_ the current win32 definitions are from Windows XP.

If we update to newer definitions, then I assume it would compile
successfully programs which use newer APIs, but the question is
what happens at runtime.

mingw has a system to define what to target (I don't recall the
specifics), so unless tcc's mingw files already have it, I think
it would 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 
enclosed)

It means many kernel32 API are not directly available for tcc.

 

It is probably the same with other .def files

 

What do you advice ?

 

 

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

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

[Tinycc-devel] Outdated .def files

[Christian Jullien]

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 you advice ?

 

 



kernel32.def
Description: Binary data
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Can tcc compile itself with Apple M1?

[Christian Jullien]

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 all 
the stuff for it but nobody is working on it AFAIK.

I’m ready to help volunteers but I have no enough knowledge on the binary forma 
to do it myself. 

 

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Niklas Rosencrantz
Sent: Saturday, September 11, 2021 03:54
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] Can tcc compile itself with Apple M1?

 

Hello,
It worked to compile and run tcc with Apple M1 but I could not make it compile 
itself. 

I get the following error message

error: 'tcc' failed to compile conftest.c.

 % ./tcc conftest.c 

tcc: error: R_AARCH64_(JUMP|CALL)26 relocation failed (val=11176, 
addr=110cc)

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

Re: [Tinycc-devel] 114_bound_signal error when tcc is compiled by tcc on macOS M1, new -arch behavior

[Christian Jullien]

Thank you Grischka.

I understand your point and can perfectly leave with it.
We'll reconsider this option when:
- tcc will be able to generate native arm64 code (probably not too hard, there 
are only issues with reloc)
- when we decide to allow generation of either x86_64/arm64 with two different 
drivers (like -m32/-64 on Windows)

Have a nice day.

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of grischka
Sent: Thursday, August 05, 2021 17:40
To: jull...@eligis.com; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] 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 dangerous to
> me to ignore argument? Please note that my error message was the same as
> gcc.

I did make considerations of course and I think the conclusion was
that this is category "fragmentary feature".  The error message
may be the same as with gcc but all the rest required to make it
a feature useful for other people is absent.

There was some aspect of "unnecessarily different" too. tcc -hh
already has a list the ignored options, there was no need to add
an extra line explaining that -arch is ignored now too.

It may be arguable how user-friendly or "dangerous" tcc is with
how it ignores some options, however I do not see the argument
to handle specifically this one differently. Rsp. arguments always
exist of course but do they justify the extra effort, that is
the consideration to be made.

--- grischka

>
>
>
> C.
>
>


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


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

[Tinycc-devel] 112_backtrace invalid memory access found on riscv64

[Christian Jullien]

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   /home/jullien/tinycc/static/include

Manual directory/home/jullien/tinycc/static/share/man

Info directory  /home/jullien/tinycc/static/share/info

Doc directory   /home/jullien/tinycc/static/share/doc

Source path /home/jullien/tinycc

C compiler  clang (11.0)

Target OS   Linux

CPU riscv64

Triplet riscv64-linux-gnu

 

I've got

 

Test: 112_backtrace...

--- 112_backtrace.expect2021-08-05 06:43:52.475956663 +

+++ 112_backtrace.output2021-08-05 06:54:24.806748723 +

@@ -3,11 +3,7 @@

* f1()

* f2()

* f3()

-112_backtrace.c:9: at f3: RUNTIME ERROR: invalid memory access

-112_backtrace.c:14: by f2

-112_backtrace.c:19: by f1

-112_backtrace.c:24: by main

-[returns 255]

+* exit main

 

[test_bcheck_1]

* main

gmake[3]: *** [Makefile:133: 112_backtrace.test] Error 1

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

[Tinycc-devel] 114_bound_signal error when tcc is compiled by tcc on macOS M1, new -arch behavior

[Christian Jullien]

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 ???: RUNTIME ERROR: illegal instruction

+7fff20268bb6 : by ???

\ No newline at end of file

gmake[3]: *** [Makefile:133: 114_bound_signal.test] Error 1

 

It works nice when bootstrapped with clang

 

=2==

As with the last commit, I initially simply ignore -arch argument but I
quickly changed my mind because one of project (on macOS) was not building
like it would.

 

clang knows how to build both arm64/x86_64 on macOS intel and arm64 cpu.

jullien@byas:~ $ clang -arch arm64 -c foo.c && file foo.o

foo.o: Mach-O 64-bit object arm64

jullien@byas:~ $ clang -arch x86_64 -c foo.c && file foo.o

foo.o: Mach-O 64-bit object x86_64

 

gcc only knows to build native object (here on my macOS x86_64). At least it
lets me know

jullien@byas:~ $ gcc -arch arm64 -c foo.c && file foo.o

gcc: error: this compiler does not support arm64  <= Sad
but I least I know!!

jullien@byas:~ $ gcc -arch x86_64 -c foo.c && file foo.o

foo.o: Mach-O 64-bit object x86_64

 

 

jullien@byas:~ $ tcc -arch x86_64 -c foo.c && file foo.o

foo.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

jullien@byas:~ $ tcc -arch arm64 -c foo.c && file foo.o

foo.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

 

With tcc the build succeeds but I'm not aware of.

 

Grischka, can you please reconsider this choice as it seems dangerous to me
to ignore argument? Please note that my error message was the same as gcc.

 

C.

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

Re: [Tinycc-devel] -Werror=X (but ugly)

[Christian JULLIEN]

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 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)


Steffen Nurpmeso wrote:
 grischka wrote in
  6102f8d1.40...@gmx.de:
  |Steffen Nurpmeso wrote:
  | The enum adds quite a bit on top of it; the addition of
  | set_W_flag() is, hmm, not nice, but i hope the current approach is
  | not too heavy.
  |
  |Maybe not heavy really but unnecessary, in quite some aspects.
  |One of them that after all tinycc currently does have only
  |2 warnings where all that bit-mask fuzz can develop.
  |
  |Just in case, below the commands how you can revert this more
  |or less cleanly:
  |
  |$ git revert -n 2709b7 49cd6f 0d59ac 0c1676 a7a138
  |$ git commit -m "revert experimental -W[no-]error=X ..."
  |
  |Take care ...

 \o/
 Greetings to the Microsoft world!

Greetings from the blatant uncomplexers
https://repo.or.cz/tinycc.git/commitdiff/4b2c6cf3

-- gr


 --steffen
 |
 |Der Kragenbaer,The moon bear,
 |der holt sich munter   he cheerfully and one by one
 |einen nach dem anderen runter  wa.ks himself off
 |(By Robert Gernhardt)

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

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


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

Re: [Tinycc-devel] -Werror=X (but ugly)

[Christian JULLIEN]

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)


Steffen Nurpmeso wrote:
 grischka wrote in
  6102f8d1.40...@gmx.de:
  |Steffen Nurpmeso wrote:
  | The enum adds quite a bit on top of it; the addition of
  | set_W_flag() is, hmm, not nice, but i hope the current approach is
  | not too heavy.
  |
  |Maybe not heavy really but unnecessary, in quite some aspects.
  |One of them that after all tinycc currently does have only
  |2 warnings where all that bit-mask fuzz can develop.
  |
  |Just in case, below the commands how you can revert this more
  |or less cleanly:
  |
  |$ git revert -n 2709b7 49cd6f 0d59ac 0c1676 a7a138
  |$ git commit -m "revert experimental -W[no-]error=X ..."
  |
  |Take care ...

 \o/
 Greetings to the Microsoft world!

Greetings from the blatant uncomplexers
https://repo.or.cz/tinycc.git/commitdiff/4b2c6cf3

-- gr


 --steffen
 |
 |Der Kragenbaer,The moon bear,
 |der holt sich munter   he cheerfully and one by one
 |einen nach dem anderen runter  wa.ks himself off
 |(By Robert Gernhardt)

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

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

[Tinycc-devel] anybody working on macOS fix?

[Christian JULLIEN]

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 (grischka?) either fix the fix or revert things 
back to last known working version.
Tia.___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] tcc need to support --arch on macOS

[Christian JULLIEN]

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:
+#onOSXM1with--cpu=x86_64,buildatcctorununderrosettaentirely+iftest"$darwin"="yes"-a"$cpu"="x86_64"-a"$cpu_sys"="arm64";then+CFLAGS="$CFLAGS-arch$cpu"+LDFLAGS="$LDFLAGS-arch$cpu"+fi
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] macOS M1 is broken since last Grischka commit

[Christian JULLIEN]

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 experiment changes which is then 
merged in mod if nothing gets wrong.
C.



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

[Tinycc-devel] macOS M1 bt-exe.c compilation error

[Christian JULLIEN]

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

Re: [Tinycc-devel] Linking system dylibs on macOS 11+

[Christian JULLIEN]

Hi,I don't think we are too far from real M1 code generation. We need to fix 
some relocation cases (something I don't know how to do).
C.



 Le :13 juillet 2021 à 16:28 (GMT +02:00)
De :"Ivan Medoedov" ivan.medoe...@gmail.com
À :"tinycc-devel@nongnu.org" tinycc-devel@nongnu.org
Objet :Re: [Tinycc-devel] Linking system dylibs on macOS 11+


Thank you for working on this, Christian!
By the way, tcc has great support of arm64 and mach-o, so I assume in the near 
future it'll be possible to generate arm64 bins on M1?
Or are there some weird things apple changed in arm64 mac-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 Jullien
Sent: Thursday, July 08, 2021 08:51
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Linking system dylibs on macOS 11+Hi,I 
get the two warnings with gcc, not with clang:./configure --cc=gcc 
--cpu=x86_64…gcc -o tccmacho.o -c tccmacho.c 
-DCONFIG_USR_INCLUDE="\"/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include\""
 -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DONE_SOURCE=0 
-Wall -O2 -Wdeclaration-after-statement -fno-strict-aliasing -Wno-pointer-sign 
-Wno-sign-compare -Wno-unused-result -Wno-format-truncation -I.In file included 
from 
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/string.h:194,
 from tcc.h:35,  
   from tccmacho.c:18:tccmacho.c: In 
function 'add_segment':tccmacho.c:265:5: warning: '__builtin_strncpy' specified 
bound 16 equals destination size [-Wstringop-truncation] 265 |  
 strncpy(sc-segname, name, 16);   |   
^~~In function 'add_section',  inlined from 'collect_sections' 
at tccmacho.c:649:22,  inlined from 'macho_output_file' at 
tccmacho.c:812:9:tccmacho.c:285:5: warning: '__builtin_strncpy' specified bound 
16 equals destination size [-Wstringop-truncation] 285 |   
strncpy(sec-sectname, name, 16);   |   
^~~Are you on Big Sur M1 (= aarch64) or Big Sur Intel? Rosetta comes 
only with M1 and it translates Intel code to Aarch64 on the fly.My 
previous attempt to build tcc on M1 was in fact to build a M1 (Aarch64) binary 
cross-compiler for x86_64. This way, tcc is a native binary on M1 which produce 
x86_64 user code translated by Rosetta (on a M1) to produce a workable 
program.Most (not to say about all) test fails.I get a much better result 
if I compile tcc as native x86_64 binary using:./configure 
--extra-cflags="-arch x86_64" --extra-ldflags="-arch x86_64" 
--cpu=x86_64Make test gives NO error at allTo summarize:On Big 
Sur Intel, I recommend ./configure; makeOn Big Sur M1, I recommend ./configure 
--extra-cflags="-arch x86_64" --extra-ldflags="-arch x86_64" 
--cpu=x86_64I’ll try to make the later options the ./configure default on 
M1.Many thanks all to make M1 support happen.C.From: 
Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Sushant Pandurangi
Sent: Wednesday, July 07, 2021 21:41
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Linking system dylibs on macOS 11+Hello 
Christian,Thanks for the Windows patches and the long double fix.To 
clarify about tcc -run, I'm not using --cpu=x86-64 at all, I am on a fresh M1 
and Rosetta is not even installed. Here, `tcc -run` starts running main() and 
very simple stuff (like Hello World) works already.On the other hand in a 
cross-compiler config, I wonder if tcc -run can work at all -- not unless 
Rosetta can do in-memory translation of the JIT'd x86-64 code.The 2 
warnings at tccmacho.c:265/285 -- those are not from my code, did they show up 
only after my patch? I wonder why. I'm not familiar with that function and 
probably not the best person to make a fix.To Herman, thanks a lot for 
catching the memcheck issues.Regards,SushantDate: Wed, 7 Jul 2021 
07:55:41 +0200
From: "Christian Jullien" eli...@orange.fr
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Linking system dylibs on macOS 11+
Message-ID: 000301d772f4$b88cf070$29a6d150$@orange.fr
Content-Type: text/plain;charset="utf-8"

Hello Sushant,

Your pushed patch works at 99%.

--- The details:

there are few warnings:

tccmacho.c: In function 'add_segment':
tccmacho.c:265:5: warning: '__builtin_strncpy' specified bound 16 equals 
destination size [-Wstringop-truncation]
265 |   strncpy(sc-segname, name, 16);
  |   ^~~
In function 'add_section',
 inlined from 'collect_sections' at tccmacho.c:649:22,
 inlined from 'macho_output_file' at tccmacho.c:812:9:
tccmacho.c:285:5: warning: '__builtin_strncpy' specified bound 16 equals 
destination size [-Wstringop-truncation]
285 |   strncpy(sec-sectname, name, 16);
  |   ^~~

--- More annoying.

BUG1: tcc -run fails because it