Personally I don't think this is required, but I don't pretend to
represent the tinycc maintainers' opinion. If it is added, however,
then the following should probably be taken into account:
- This mostly works, but it won't work on all terminals, for instance
the original DEC VT100 has bold bu
On Tuesday, September 12, 2023 at 12:44:45 PM GMT+3, grischka
wrote:
On 12.09.2023 11:01, avih via Tinycc-devel wrote:
>> Tcc does not guarantee to compile pure C code into pure machine code,
>> and any pure-C implementation which the user provides might end up
>> depending
tions involuntarily. The user has no control..
- avih
----- Mail d'origine -
De: avih via Tinycc-devel
À: tinycc-devel@nongnu.org
Cc: avih
Envoyé: Tue, 12 Sep 2023 10:33:01 +0200 (CEST)
Objet: Re: [Tinycc-devel] Re : Re: win32: -Wl,-nostdlib: undefined symbol
'memset'
And
when linking with libtcc1?
On Tuesday, September 12, 2023 at 12:11:17 AM GMT+3, avih via Tinycc-devel
wrote:
Thanks. I was going by the official gcc docs. I did not test
what it requires beyond those mem* implementations.
Back to tcc, the current help for nostdlib is:
> -nostdlib do no
aybe even more beyond those?
Should the mem* functions and libtcc1 cover these linking issues, assuming
the user code doesn't use the crt and stdlib?
- avih
On Monday, September 11, 2023 at 10:32:26 PM GMT+3, grischka
wrote:
On 11.09.2023 14:41, avih via Tinycc-devel wrote:
>
The issue is bigger than just memset. I found at least 5 more functions
which are required in some cases, not all of them part of stdlib, and I'm
guessing sure there are more, depending on the platform. For instance:
// test3.c ---
typedef struct { int a, b; } S;
void _start(void) {
I don't think that's a valid argument.
This is plain C code which on its own doesn't require the standard library,
so I don't think the user should provide an alternative standard library
implementation just so that the startup code which tcc uses can be linked.
Today it seems that only `memset`
Correction: the expected name is "_start" - not "_startup".
- avih
On Saturday, September 9, 2023 at 07:19:32 PM GMT+3, avih
wrote:
The following is test.c:
#include
void _start(void) {
char buf[16] = {0};
ExitProcess(42);
}
Try to compile it using:
tcc -Wl,-nostdlib te
The following is test.c:
#include
void _start(void) {
char buf[16] = {0};
ExitProcess(42);
}
Try to compile it using:
tcc -Wl,-nostdlib test.c -lkernel32
Result:
tcc: error: undefined symbol 'memset'
Which I'm guessing is tcc trying to zero buf on startup using memset,
but failing to
What some random script tries or doesn't try to do is irrelevant.
tcc should follow the spec and common practices.
Generally speaking, applications which respect the POSIX syntax
guidelines should treat non-option-argument "--" as an indication
that all further arguments are operands:
- https://
__unaligned is defined as _attribute__((packed))
at win32/include/_mingw.h and pretty much always included, so tcc
shouldn't blindly define it to something else in advance.
The warnings can be observed when compiling tcc on Windows, or
when using the resulting newly built tcc, or when cross-compil
The patch below works for me. If you think it's good, please push it.
Feel free to modify it however you see fit.
The issue with your original patch was that __clang__ is only defined
when compiling the reference using clang, but not when compiling the
test using tcc.
In this patch, preprocessor
On Saturday, March 18, 2023, 02:07:35 PM GMT+2, avih wrote:
> If I use #if 0 instead of #if !defined(__clang__) || GCC_MAJOR >= 11
> then it does pass. Not quite sure what's going on.
Ah, I do get it. When it compiles the reference using clang then
these elements are 0, but when it compile
The patch does not work. The file compiles but there's a diff:
test3
--- test.ref 2023-03-18 14:01:39.0 +0200
+++ test.out3 2023-03-18 14:01:40.0 +0200
@@ -973,9 +973,9 @@
6 1490
7 3010
8 3010
-9 0
-10 0
-11 0
+9 2444
+10 3056
+11 3056
12 16149
13 32
This is a second reply to the same email.
On Tuesday, March 14, 2023, 06:02:35 PM GMT+2, Herman ten Brugge
wrote:
> Can you change the code in 'tests/tcctest.c' on line 3865 to '#if
> GCC_MAJOR >= 40'.
This works. Specifically, only the __builtin_clrsb* are an issue,
while the others are fin
I thought it would be useful to be able to reach from tcc 0.9.27
to the current mob HEAD cleanly, and I've encountered several issues:
1. On Ubuntu 64 22.04 LTS (gcc 11.3), tcc 0.9.27 does not build.
git clean -xfd
git checkout release_0_9_27
./configure --prefix=$PWD/../tcc0927
make
# ends wit
On Tuesday, March 14, 2023, 06:02:35 PM GMT+2, Herman ten Brugge
wrote:
> The config-new-macho=no was the default with commit 62096265.
Right, so that explains why --config-new-macho=no didn't help,
and I'd guess there are no options which would make it work, right?
(I don't have a need for th
On Tuesday, March 14, 2023, 02:53:19 PM GMT+2, Herman ten Brugge via
Tinycc-devel wrote:
> I can only test things on macos 12.6 (aarch64) and macos 10.15.7 (x86_64).
> These 2 platforms work with head.
>
> I applied a lot of fixes since november so head is probably the best version.
>
>
> I do
The offending commit is from November 2022.
Here are test outputs with the offending commit and then current mob.
Below is the output with the offending commit 62096265
of the test part of:
git clean -xfd && ./configure && make && make test
hello-exe
dyld: REBASE_OPCOD
On Wednesday, October 19, 2022, 03:36:59 PM GMT+3, Michael Matz
wrote:
> ...
> "dec %edi" truncates the %rdi register to 32bit by zero-extension,
> so that ... this is now segfault. That only matters if the stack
> (which %rdi points into) is setup such that it's beyond 32bit,
> which ... is in
On Friday, October 14, 2022, 05:27:47 PM GMT+3, grischka
wrote:
>> and indeed, when tcc64 is compiled using tcc64 then on win10
>> s->sh_addr is ~22 bits, and all tests do pass _before_ d76e0323.
>
> Well, maybe behavior of malloc on Win10 has to do with the image-base
> of the process. (see o
In reply to the second half of:
https://lists.nongnu.org/archive/html/tinycc-devel/2022-10/msg00021.html
> As to spurious problems with MSYS2 I can only say that in my experience
> it is not a completely reliable build system.
>
> As a derivative from cygwin it shares the same fork() emulation
On Monday, October 10, 2022, 12:33:48 PM GMT+3, grischka wrote:
>> tcc-busybox is:
>> http://download.savannah.nongnu.org/releases/tinycc/tcc-busybox-for-win32.zip
>>
>> building this busybox using tcc which was built from mob 20a1ebf
>> or later results in sh.exe which always prints "sh: apple
Hi,
It's the first time I tried building it (cute), and turns out that it's
currently broken.
tcc-busybox is:
http://download.savannah.nongnu.org/releases/tinycc/tcc-busybox-for-win32.zip
building this busybox using tcc which was built from mob 20a1ebf
or later results in sh.exe which always
Hi,
The following tests fail for me currently (0fd7376 gnu hash) when
building tcc for win32 x86-64 (but pass when building i386)
from tests/:
- test3
- test1b
from tests/tests2/:
- 104_inline.test
I sampled several revisions since release_0_9_27, and all of them
fail somehow, mostly in tests (
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 u
I also think the hash should be there.
git describe can be useful here too.
On Wednesday, March 31, 2021, 06:44:39 PM GMT+3, Dmitry Selyutin
wrote:
Hi Jullien,
I think this is a really good idea. I'd also consider git hash, not a date, but
this is likely a minor.
> +TCC_GIT_DATE=$(s
local in a sh script is not posix, and while some shells do support it, some
do not,
e.g. ksh 88/93 (frequently used on traditional unix systems), yash, and more.
So portable sh scripts should not use local.
- avih
On Sunday, February 14, 2021, 09:30:48 PM GMT+2, Danny Milosavljevic
wro
There is a CodingStyle file, and the second paragraph clearly
states (rightly) that style-only changes should be avoided.
The instructions at this file are still valid.
- avih
On Wednesday, December 2, 2020, 01:08:33 PM GMT+2, Tyge Løvset
wrote:
I have slowly started to look into t
I already replied to it the last time you asked:
https://lists.nongnu.org/archive/html/tinycc-devel/2020-09/msg00034.html
On Wednesday, September 23, 2020, 10:22:40 PM GMT+3, Thema
wrote:
Dear tcc Development Team;
I have downloaded the latest version of the Tiny C Compiler butwhen I
On Monday, September 14, 2020, 04:18:21 PM GMT+3, Thema
wrote:
> I have downloaded the latest version of the Tiny C Compiler but
> when I try to run a program compiled by it, I get an error message
> about the exec format being invalid. I suppose that the ELF header
> is not compatible with the
08:44, Kyryl Melekhin :
>
> About formatting, what's the preferred vim setting you use? I looked
> through the code and couldn't figure out what it was, it seemed so
> inconsistent so I just thought you guys don't care about that.
>
> сб, 12 сент. 2020 г. в 05:55, gr
While force-pushing is usually possible, I'd argue that at the tcc repo
(and generally elsewhere too, but to each his own practices) no one
should force push except maybe maintainers and maybe other regular
contributors which 100% know what they're doing when force-pushing.
I.e. if you want some
It's now embedded into the tcc binary.
See docs/tcc-win32.txt
On Saturday, August 29, 2020, 12:33:50 PM GMT+3, Vaidas BoQsc
wrote:
I downloaded tcc-0.9.27-win64-bin.zip from
http://download.savannah.gnu.org/releases/tinycc/
And in this release I couldn't find tiny_impdef.exe
that do
I don't have proper gcc installed (via brew or macports), but I think it would
make sense to first check what gcc does and supports.
On the other hand, if it's only aliases to existing options, possibly which are
enabled only on OSX, then I don't think [m]any would object, and it should
be fairly
nycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of avih via Tinycc-devel
Sent: Friday, July 10, 2020 11:42
To: tinycc-devel@nongnu.org
Cc: avih
Subject: [Tinycc-devel] [issue] macos: tcc cannot self-host with
--disable-static
Self-hosting with static linking works fi
Self-hosting with static linking works fine:
[ -e ./conftest.c ] || { echo error: not tcc root; exit 1; }
rm -rf ./bld ./bldself ./dist1 2>/dev/null || :
mkdir bld && cd bld && \
../configure --prefix=$(pwd)/../dist1 && make && make test && make install
cd .. && mkdir bldself && cd bldself && \
I've pushed a fix to mob to support arbitrary libdir (c69290fb).
The relative path is now used during `make test', while the fixed libdir is
used after install.
On Thursday, July 9, 2020, 09:12:06 PM GMT+3, avih via Tinycc-devel
wrote:
Note to self: Make sure to do
on 0.9.27 (x86_64 Darwin)
install: /Users/jullien/tinycc/dist/lib/tcc
…
It work for me. If it also works for you I’ll add this step to macos build
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of avih via Tinycc-devel
Sent: Thursday, July 09, 2
you I’ll add this step to macos build
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of avih via Tinycc-devel
Sent: Thursday, July 09, 2020 18:23
To: tinycc-devel@nongnu.org; jull...@eligis.com
Cc: avih
Subject: Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no l
Seems that moving ./dist/lib/libtcc.dylib to ./dist/bin/ makes it work,
compile programs successfully, and -run works as well.
So it seems that install target doesn't take everything into account.
On Thursday, July 9, 2020, 07:17:38 PM GMT+3, avih
wrote:
Oh, I missed the commits f
Oh, I missed the commits from today.
Indeed, with latest mob (6bd0ced) this now succeeds:
./configure --disable-static && make && make test
However, when building and installing like this:
./configure --disable-static --prefix=$(pwd)/dist && make && make test && make
install
Then it succeeds,
What's the fix? I tried looking at the earlier messages, but didn't
see a diff/patch.
For me on osx 10.13 (real MBA) I also have the same issue when
using --disable-static, but it seems fine without it, including -run.
On Thursday, July 9, 2020, 06:38:10 PM GMT+3, Michael Matz
wrote:
I've built mpv with tcc on both Ubuntu and Alpine linux, though not
recently. It did require patching waf (the build system) because it's
very picky with compiler identification, as well as some minor patches
in mpv to replace few #pragma once with normal include guards.
tcc builds st ( http://st
For me, with current tcc mob (but also with version at least 6 months
old) this does work: tcc hello.c -l c
Which version did you try?
As for -O, it seems that the option-argument is optional - in both
tcc and gcc. The posix syntax for optional arguments is that the
value must follow at the same
תודה. זה מגיע לתיבת הדואר שלך? או שהם משאירים את זה במקום כללי ואת לוקחת את זה?
On Wednesday, August 7, 2019, 10:14:29 AM GMT+3, Mai Aylon
wrote:
היי אבימצרפת לך את החשבון של ועד הביתיום נעיםמאי ___
Tinycc-devel mailing list
Tinycc-devel@n
x,double y,double z){printf("f(%4.1f,%4.1f,%4.1f)\n",x,y,z);}
int main(int argc,char **argv){double u=0.0;f(u*1.0,7.0,8.0);return 0;}
> tcc -o test test.c
> ./test
f( 0.0, 7.0, 8.0)
Fra: Tinycc-devel [tinycc-devel-bounces+grue=di.ku...@nongnu.org] på vegne af
avih via Tin
You're right, and I can confirm that the win64 version downloaded the
same as you exhibits the same issue, and the issue also exists if
I build 0.27 for win64 myself (git d348a9a).
However, it was apparently fixed shortly after tcc 0.27 was released,
at the following commit:
commit 8f6fcb709ae7b
> On Wednesday, July 31, 2019, 8:55:18 PM GMT+3, Christian JULLIEN
> wrote:
>
> This my THIRD attempt to reply to this thread since Jul, 26. The
> two prev. attempts never reached the list. Hope this one will work
> and go to the list!
It did, at least to me (but I was addressed). FWIW, I don
Hi Michael,
> > Patch is attached. If there are no objections, I'll push it in few days.
>
> But why? TCC is a compiler, it doesn't generally provide a C library.
> Use newlib or musl or the like for that.
You know as well as anyone that the Windows build of tcc is more than
that. It's a self
Patch is attached. If there are no objections, I'll push it in few days.
>From the commit message:
This is a POSIX compliant implementation of getopt (short options).
It passes all tests of gnu getopt in posixly-correct mode, with
additional safeguards against out-of-bounds access (optind, optpo
51 matches
Mail list logo
