On 22.04.2024 06:16, Paul Moore wrote:
Weird processor. It only supports absolute jumps. So this is something that
needs to be fixed up during link time. I do not know the elf details well
enough to be able to work out how to do it
Seems like I need the jmp instruction to be a have reloc that
On 11.03.2024 20:38, Robert Schlicht wrote:
> Yes, it is. But it’s really primitive, basically just a text editor that has
the compiler integrated, and calling it an IDE may be an exaggeration. It’s the
thing that is intended to make writing a “Hello, World!” program (and slightly
more
On 08.03.2024 07:30, Eric Raible wrote:
I guess that I just want the numbers to add up.
Using your example:
1) -DMEM_DEBUG -DCONFIG_RUNMEM_RO=0
2) your test.c
3) but I added an early return to tcc_delete() to no-op it
Running: valgrind tcc -nostdlib -vv -bench -run test.c
produced:
tcc
On 03.03.2024 21:26, Eric Raible wrote:
> isn't there a garbage collecting done at the end to remove all the unused
stuff
> to produce a binary that contains only the necessary parts ?
That very well might be the case, but given that tcc_get_symbol()
can be used at any time between
On 02.03.2024 20:15, Jake Anderson wrote:
When compiling TCC using TCC, there is an error about missing _strtoui64 in
msvcrt.dll on Windows 2000 and older. This does not occur when using old
versions of GCC to compile TCC.
Maybe you want to replace
in tcc.h
# define strtoull _strtoui64
On 01.03.2024 17:32, Rich Felker wrote:
The relocation emitted is the pc-relative address based on the
beginning of the add opcode, but it needs to be based on the beginning
of the immediate operand in the add opcode.
I just moved the addition of (ind + 4)
On 01.03.2024 07:49, Herman ten Brugge via Tinycc-devel wrote:
On 2/29/24 23:17, grischka wrote:
On 29.02.2024 07:26, Herman ten Brugge via Tinycc-devel wrote:
Setting CONFIG_RUNMEM_RO=0 looks incorrect to me because it sets write in
executables.
Apple has implemented W^X (Writes can
releases.
Using CONFIG_RUNMEM_RO=1 may be the right thing to do in
future, however there was a severe off-bounds problem with
the un-mprotect call which I just fixed. Maybe that was
the reason?
-- grischka
Can I revert the change and set CONFIG_RUNMEM_RO=1 for all targets as before?
Herman
concepts each. (Not
sure if/where it really can happen though).
-- grischka
Herman
fix1:
diff --git a/lib/runmain.c b/lib/runmain.c
index 1cbf6dd..307bf45 100644
--- a/lib/runmain.c
+++ b/lib/runmain.c
@@ -60,6 +60,7 @@ typedef struct rt_frame {
} rt_frame;
void __rt_exit(rt_frame
On 25.02.2024 11:02, Eric Raible wrote:
If build with:
-DCONFIG_RUNMEM_ALIGNED=0
I'm hoping you'd be good to go.
Don't mind, I reverted the usage of those "more recent" system
features (as in memalign() & gettid()). Simpler code, less
problems ...
-- grischka
On l
On 12.02.2024 15:35, George Sedov wrote:
Hi all,
First of all, I noticed that throughout the codebase there is a mix of spaces
and tabs. This makes it very difficult to produce out-of-tree patches, since
most of the editors will replace tabs with spaces. Is there a reason behind it?
On 11.02.2024 11:08, draco via Tinycc-devel wrote:
You're right, I didn't verify closely, but the ABI is still intact. Sorry...
To be nice I've made tcc_relocate() abort with a notice
when it's called with the former two-step method ;)
-- gr
Am 10.02.24 um 22:12 schrieb Eric Raible:
>
z/tinycc.git/commitdiff/af686a796bda94dc92fc3ad140ef438dafa08950
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
s well remove that
option entirely, and have a simpler and more "lovely" API then ...
What do you think?
-- grischka
When using
void *mem = malloc(tcc_relocate(s, NULL));
tcc_relocate(s, mem);
wouldn't it make sense for tcc to export a function to safely
restore the pages to R/W in a platfo
On 19.01.2024 07:18, Herman ten Brugge via Tinycc-devel wrote:
I wanted to avoid an extra check for ';' because I found code like:
case xxx: ; }
Instead of writing 'break;' they used ';'.
Without checking for ';' a warning was printed:
Always same problem: we want something and do
On 16.01.2024 00:38, Michael Larson wrote:
Hello,
I have been tinkering around with TCC porting to a RISC cpu of my own
design, I have my own C simulator and verilog targeted for a FPGA.. I
have a lot of tests for functionality, but I need more so TCC looked
like a good option to generate code
On 15.01.2024 00:51, Brad Robinson via Tinycc-devel wrote:
Questions:
1. Is it possible to keep, use and then release the compiled code after the
initial compiler instance has been deleted
FYI below some version of libtcc_test.c to run without state.
Note the LoadDll is needed only when the
On 18.01.2024 17:38, Herman ten Brugge via Tinycc-devel wrote:
That depends on the version of gcc / clang.
Gcc 13.2.1 prints no error.
Clang 17.0.6 prints "error: expected expression"
Clang 18.0.0(not released yet) prints "warning: label followed by a declaration is a
C23 extension
On 15.01.2024 00:34, Brad Robinson via Tinycc-devel wrote:
Hey All,
First post here. Firstly, thank you all for your work on this project. I
discovered tcc just a month or so ago and really enjoying using it as a
back-end code generator for a custom scripting language I'm working on.
On 06.01.2024 01:10, Detlef Riekenberg via Tinycc-devel wrote:
Of course, there might be more issues in 0.9.28rc
As example, "i386-tcc" on a x86_64 linux machine
is missing additional search dirs:
Can we see the output of "i386-tcc -vv" ?
include: "/usr/i686-linux-gnu/include"
lib:
method to cause confusion. Try to get rid of that.
Also, not necessarily was tcc written with any not yet existing
features already in mind. If you can organize existing stuff differently
to make the new feature fit more nicely, then why not ... ;)
-- grischka
Best regards,
Reimar
make much sense
either, IMO.
-- grischka
Herman
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
On 02.10.2023 05:45, Eric Raible wrote:
It seems to me that "ST_FUNC void skip(int c)" needs to be smarter
about handling 'c',
perhaps formatting it into a string before calling tcc_error(). I
could (in theory) fix this,
but it looks like it would require refactoring get_tok_str() to not
use
On 22.09.2023 21:17, Detlef Riekenberg wrote:
Obviously when loading a .so library,
tcc additionally is loads its dependencies too.
That would be correct, when the target is TCC_OUTPUT_MEMORY
but i think, in all other cases, tcc should not do that.
I'd suggest to use "grep -nrw tcc_load_dll
On 16.09.2023 12:01, Detlef Riekenberg wrote:
libcurses/libcurses.so: error: referenced dll 'libterminfo.so' not found
make: *** [GNUmakefile:529: libpanel/libpanel.so] Fehler 1
Command exited with non-zero status 2
Analyse results so far:
* libpanel/libpanel.so depends on
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 on those functions involuntarily. The user has no control..
How do you define "pure C code"?
On 11.09.2023 14:41, avih via Tinycc-devel wrote:
But in the case of tcc, it's not documented, and seems to go
quite a bit further than what gcc requires
libgcc.a from mingw-gcc-6.3.0 is 6218 kB, all full with according
to your standards "undocumented" stuff that however gcc surely
will
On 18.08.2023 12:41, Jens Nyberg wrote:
Hi!
I have two questions really:
1, I am thinking of adding the "ltrw" instuction to i386. I see there is
already an ltr instruction so there might be good reason you don't have the w-variant? In
any case how would I add it properly? Would adding a
On 31.07.2023 13:42, Herman ten Brugge via Tinycc-devel wrote:
I agree with your comments above. The size is incorrect.
I could change gfunc_sret in x86_64-gen.c and then calculate the size in
tccgen.c
as you suggested. But I am not sure regsize is set correctly all the time.
I like this
On 23.07.2023 16:11, wizzwizz4 via Tinycc-devel wrote:
I tried compiling QuickJS with tcc.
After setting `-DEMSCRIPTEN -DCONFIG_VERSION=""`, I get:
quickjs.c:2664: warning: function might return no value: 'JS_AtomGetKind'
quickjs.c:39834: error: initializer element is not constant
I'm guessing
On 24.07.2023 21:23, Sagar Acharya via Tinycc-devel wrote:
I'm building tcc on voidlinux with gcc as below
./configure --config-musl
make
On 'make test'
+In file included from 124_atomic_counter.c:3:
+In file included from /usr/include/stdlib.h:19:
+/usr/include/bits/alltypes.h:18: error:
On 14.07.23 15:30, Brian Callahan wrote:
* __start_crt_compiler: referenced symbol not found
Seems you'd need to provide this function, for example in libtcc1.a.
Google has some info about it.
This symbol is provided in the Solaris C runtime startup files, and it
is linked into the
On 11.07.2023 07:22, Brian Callahan wrote:
Hi all --
Attached for review/testing is a diff that enables TCC to work on
Solaris/Illumos x86. Tested on an OpenIndiana (Illumos distro) machine,
where all tests pass when running TCC as an i386 compiler.
Solaris/Illumos is a multiarch environment.
On 07.07.2023 20:09, Herman ten Brugge via Tinycc-devel wrote:
I did a benchmark on linux and it is about 2% slower on my machine.
Well, and how much in comparison is the gain from the ifndef_cache,
in your benchmark? I mean just in case to make sure the cache won't
be slower than no cache
On 07.07.2023 18:15, Ziyao via Tinycc-devel wrote:
Hi,
I noticed that test 131 (authored by me) has been modified
in commit 5b28165: Fix test 131 for 32 bits targets:
struct with two long int members are replaced by long long
int ones.
Test 131 (return struct in registers) is intended to test
On 07.07.2023 07:45, draco wrote:
Hermann,
I tested your patch a bit, seems to work as expected and brings tcc
win32 back to it's normal speed.
It might be too slow on linux too ...
Basically the "#ifndef cache" is meant to make it faster,
while the #pragma once also needs to detect path
would work for all purposes of #pragma once except when 'b.h' is
a link to 'a.h' and both are used in the same translation unit.
-- grischka
I tested this also before committing. I could not find a problem.
I only have an x86_64 machine on redhat linux and a raspberry pi with 32
and 64 bits.
I
On 25.06.2023 20:30, Herman ten Brugge via Tinycc-devel wrote:
I just pushed a patch to fix this.
Hi Hermann,
some numbers from Win32:
before:
# 6.334 s, 85768 lines/s, 27.9 MB/s
after first patch:
# 11.825 s, 45941 lines/s, 14.9 MB/s
after second patch:
# 10.406 s, 52206 lines/s,
On 27.05.2023 02:28, Fred van Kempen via Tinycc-devel wrote:
Herman:
>> Based on the 0.9.27 release code, I added a patch to tcc.c to let it "find"
itself and its
>> support directories (include, lib etc) even it is not located in the root
of that setup. I
>> normally have stuff organized
ith
a more recent version of tcc since then?
Did you check how well it would work at all?
-- gr
- certanan
--- Original Message ---
On Monday, April 17th, 2023 at 8:18 AM, grischka wrote:
On 17.04.2023 07:59, avih via Tinycc-devel wrote:
What some random script tries or doesn't
'd consider the latter form still rather "unofficial" so we could
still replace it by
tcc options files -run -- arguments
which might (or might not) look better, in some sense.
What do people think?
-- grischka
Generally speaking, applications which respect the POSIX
On 15.04.2023 22:38, certanan via Tinycc-devel wrote:
From what it seems to me, even Bellard's QEmacs seems to be relying on this,
rather, standard feature since at least 19 years ago, as referenced in its
official GitHub repository.
Am I missing something cardinal, or is there, indeed, no
t;
output is compatible with it?
-- grischka
I hope, that we get more attention with a 0.9.28 release
and maybe also new contributions/testers.
Thanks for your effort.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/
le:
./configure
make cross-arm-eabi
sudo make install
which is not so bad at least for developers.
-- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
an it used to be? ;)
-- grischka
Herman
___
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.
On 01.03.2023 14:58, Andrew Randrianasulu wrote:
I tried to make tcc from commit
29ae3ed4d5b83eec43598d6cd7949bccb41c8083
it makes itself fine, just 'make test' result in
~/tinycc $ make test
make[1]: Entering directory '/data/data/com.termux/files/home/tinycc/tests'
hello-exe
On 22.12.2022 09:20, Harry Yan wrote:
Hello,
I am trying to build the SQLite3 command-line tool with TCC.
It works well with GCC:
$ gcc -c shell.c dirent.c
(no complaints)
However, TCC seems to be confused by a structure field:
Hi, yes, seems, but is not in that case.
Instead in that
which is never SHN_UNDEF).
Such I guess your options probably are:
- use gcc -fPIC
- use tcc to compile SDL (more like -FPIC but not optimized)
- provide SDL as a shared library
- link SDL into the host application and provide its symbols via tcc_add_symbol
- work on tcc to fix the prob
On 25.10.2022 00:08, Bernhard Reutner-Fischer wrote:
AFAICS the "warn about incorrect use of output_*" by using an enum did
never end up on mob.
Just because features often come with more complexity does not mean
that more complexity already is a feature.
Much more often the contrary is true:
On 23.10.2022 09:48, Bernhard Reutner-Fischer wrote:
Hi Grischka and folks!
I have just pulled after some time.
In my clone, i see a remotes/origin/mob-stuff branch and i wonder what
that is/was about, does anybody remember by chance? Was that a staging
area for mob or somesuch?
Maybe it's
ou happen to want find out:
$ gdb tcctest.exe
> run
> bt
> disass
> info reg
--- grischka
I then tried also
make -C tests clean
make -C tests test3
and it's the same end of output as with test1, and same
diagnostics (pass if commenting out RUN(asm_test), else
crash at strn
.
--- grischka
I sampled several revisions since release_0_9_27, and all of them
fail somehow, mostly in tests (one revision also failed to build).
This could be related to the mingw gcc I'm testing with - gcc 11.3.0
using mingw64 in MSYS2. I _think_ the x86-64 win32 tests did pass
in thepast, so
ng & test tcc with msys is almost twice
as slow.
-- grischka
The steps to reproduce below are using MSYS2 mingw, but it was
reproduced also after building win32 tcc in other environments.
Interestingly, renaming the binary to ash.exe seem to "fix" it. e.g.
./sh.exe -c 'echo hel
On 04.10.2022 07:45, Eric Raible wrote:
Perhaps I was using libtcc incorrectly, but libtcc.h is a bit unclear about it.
The comment for tcc_set_output_type() says:
/* set output type. MUST BE CALLED before any compilation */
In reality, as of e41730f11 that is no longer good enough.
It used to
On 02.10.2022 17:33, Giang Vĩnh Lộc wrote:
Hi all,
I will try to explain my situation as simple as I can :))
- I have x86_64 Linux machine as host
- I want to compile tcc (from source, no prebuild binary) for running tcc on
that machine
- I have ARM Linux as target. I want to build my C code
On 26.09.2022 23:32, Detlef Riekenberg wrote:
Hey grischka.
Reducing the search path is a good idea. Thanks for that,
but your code does not work for the i386-tcc
on x86_64-linux.
Hi Detlef, sorry about that, but there was little information in your
patch itself or in your comments what
On 25.08.2022 21:40, Ekaitz Zarraga wrote:
Hi grischka,
vtop->r and vtop->cmp_r are used interchangeably in some parts of the codebase
and I don't really understand why.
I don't know where you see this?
I'm probably mistaken by the code I read. I'm having a hard time r
ank you,
Ekaitz
--- Original Message ---
On Wednesday, August 10th, 2022 at 1:53 PM, Ekaitz Zarraga eka...@elenq.tech
wrote:
Hi,
On Wednesday, August 10th, 2022 at 1:43 PM, grischka gris...@gmx.de wrote:
On 09.08.2022 20:39, Ekaitz Zarraga wrote:
Hi all,
I'm working on the RISC-V
On 11.08.2022 17:06, pursuer2 via Tinycc-devel wrote:
I'm sorry to send a duplicate mail by mistack a short while ago.
what I really want to say is that I make a patch to add all missing scope
modifier .
Static scope is userful when use ONE_SOURCE build mode, which can avoid
unexpected name
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
else {
// Just jump?
// Why return `t`?
t = gjmp(t);
gsym(vtop->c.i);
}
}
vtop--;
return t;
}
```
Thank you all for the help,
Ekaitz
PS: grischka, I added you on copy as you are the autor of the mentioned commit.
_
On 06.08.2022 21:35, Arthur Williams via Tinycc-devel wrote:
Was trying to compile X and noticed that it failed building hw/xfree86/
Turns out tcc was segfaulting by trying to deference a null address.
Bisected mob to conclude that this regression was introduced by
`ebaa5c8 dynamic executables
On 30.07.2022 20:13, Vincent Lefevre wrote:
On 2022-07-30 19:48:29 +0200, grischka wrote:
Sorry, what? Are you saying that (n & (n - 1)) with n == 1 -> (1 & 0)
and with n == 0 -> (0 & -1) does not evaluate to 0 in both cases always
necessarily, in C?
Yes, if the 0 happens
to a valid fundamental alignment, or to a valid
extended alignment supported by the implementation for an object
of the storage duration (if any) being declared, or to zero.
Then I think we can still accept larger values as "extended align
On 28.07.2022 16:34, Detlef Riekenberg wrote:
Hi grischka.
Hi Detlef,
Please try to be more precise. For example, in your last commit,
you wrote:
"Do not fail with _Alignas(0) and _Alignas(1), used by autotools"
But there wasn't anything wrong with _Alignas(1), to begin
On 20.07.2022 06:03, Arthur Williams via Tinycc-devel wrote:
Hi,
Was writing an application and noticed a bug. The script can be reduced
to the following:
```
#!/bin/tcc -run
#include
int main() {
struct timespec start, current;
clock_gettime(CLOCK_MONOTONIC, ); // Segfaults
}
```
uld be though.
You could try to see where tcctest crashes like so:
$ tcc -g -I. tests/tcctest.c
$ gdb a.out
r
bt
or using tcc's builtin stack trace:
$ tcc -bt -I. tests/tcctest.c
$ ./a.out
thanks,
-- grischka
./configure --cpu=x86_64 --config-bcheck=no --config-backtrace=no --cc=tcc
--pre
On 13.07.2022 16:45, Ziyao wrote:
On Wed, Jul 13, 2022 at 12:01:57PM +0200, grischka wrote:
Is it necessary or a good idea to remove that behavior/feature now
from tcc?
I've seen no arguments.
Sorry for my impulsive decision.
It is a valuable feature to be honest but supposed to be described
On 13.07.2022 17:17, Vincent Lefevre wrote:
On 2022-07-13 12:01:57 +0200, grischka wrote:
There was no bug here in tcc, it was/is just different behavior, fully
intentional and even documented with a test case.
There was a bug in tcc: the ISO C standard requires a diagnostic.
Well, define
ssary or a good idea to remove that behavior/feature now from tcc?
I've seen no arguments.
--- grischka
Ziyao
---
diff --git a/tccpp.c b/tccpp.c
index 25654b2..f070640 100644
--- a/tccpp.c
+++ b/tccpp.c
@@ -944,19 +944,16 @@ static uint8_t *parse_
ion for it from (non-patched) tclDefs.h:
extern TclStubs *tclStubsPtr;
(-> extern TclStubs *(*_imp__tclStubsPtr); )
See also tcc/win32/include/stdlib.h for example:
#define _environ (*_imp___environ)
extern char ***_imp___environ;
--- grischka
Michael
IIRC tcc from 0.9.27 on tr
oduction of 64-bit targets
to the effect that data objects that are resolved via tcc_add_symbol()
are now accessed by the same mechanism as those that come from dlls.
This mechanism needs special code to be generated already at compile
time which is what happens when tcc sees __declspec(dllimport) (and
d
de
Well, could you maybe share the possibly more interesting part of
your "OOTB Experience", too? How did you make that arm64-tcc?
-- grischka
The tcc pakage from the OS is too old
and provides only i386-tcc and tcc (on x86_64),
but not for arm, arm64 and other t
Sam Ellicott wrote:
Example code is here
```
.global _start
_start:
la gp, _global_pointer
la a0, _bss_start
la a1, _bss_end
bgeu a0, a1, 2f
1: sw zero, (a0)
addi a0, a0, 4
bltu a0, a1, 1b
2: # setup the stack
la sp, _stack_end
call main
```
For example when the `_global_pointer` symbol is
Example?
On April 16, 2022 5:03:59 AM UTC, Sam Ellicott wrote:
>Hi All,
>I have been working on porting tcc to generate code for riscv32
>targets and have run into an issue when writing the assembler in the
>case of an externally defined symbol.
...
Antoni Gual Via wrote:
Hello
I have recently compiled a Win64 version of TCC from the mob using the
busybox and a 0.9.27 Win64 release.
When trying to compile with the -m32 switch mentioned in the help I get
all kind of errors. I guess the headers and libs I have are all for 64
bits windows.
Arthur Williams via Tinycc-devel wrote:
On Thu, Mar 10, 2022 at 10:27:25AM -0800, Elijah Stone wrote:
Hi,
The following code results in an initialiser overflow ICE on the latest
version of tcc (917aad3), amd64 linux.
#include
#include
typedef struct { char b[2]; } Barb;
Barb *f(Barb x,
Antoni Gual Via wrote:
Hi
To build a Windows app, windres from gcc is required. By default it uses
the gcc preprocessor to resolve the defines, and gcc has its
dependencies, so a complete Mingw install is required. A command line
option in windres allows to use any other preprocessor, and using
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
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
See tccdefs.h where you can put the SIZEOF constants.
--gr
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
Michael Matz wrote:
So, the problematic type was:
int (*)[a][b]
That's pointer to an vla-array of an vla-array of int. All three (inner
array, outer array and pointer, but not the int) should be marked
VT_VLA.
Hm...,
IMO one (very) invariant convention is that VT_ARRAY rsp. VT_VLA
always
Got this report on private email. Not sure what it means ...
-->>
Output of the code below if compiled with TCC is pretty messy:
array values are "misplaced" and overwrite each other.
But everything's ok if compiled with GCC.
#include
david.k...@libertysurf.fr wrote:
'GLFrontier-win32\src\lib\SDLmain.lib' contains an entry point to 'main'
Yet is not recognized as a library.
'GLFrontier-win32\src\lib\libSDLmain.a' contains an entry point to
'console_main'
Both contains an entry point to 'WinMain@16', but this is "handled"
Domingo Alvarez Duarte wrote:
Hello again grischka !
I finally managed to get a github workflow to build my reentrant fork of
tinycc on linux, osx and windows.
Actually there is two builds:
- one with CONFIG_TCC_SEMLOCK set to ONE here
https://github.com/mingodad/tinycc/actions/runs
d have everything rewritten
including function protos and calls with just some commands from a shell
script. ;)
--- grischka
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 ma
know how to help out themselves, in my opinion.
FWIW tcc's current win32 includes are from an early mingw-64 from 2009
(tinycc commit dc251a7d). Also the winapi-full-for-0.9.27 pack on
http://download.savannah.nongnu.org/releases/tinycc/.
-- grischka
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, "Wind
warnings.c,
if you want.
-- grischka
Suote127
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/ti
Alvarito050506 wrote:
The patch isn't great (it abuses macros, for example) so suggestions,
criticism, and feedback in general would be appreciated.
I guess that patch is two patches actually, one for the feature and
one to obfuscate tcctok.h a little bit plus adding a new file to the
project
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
,
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
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
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 ...
--- grischka
Keep on going tc
till adds 78 lines total though:
$ git diff --shortstat a7a138~1 2709b7
8 files changed, 126 insertions(+), 48 deletions(-)
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Christian JULLIEN wrote:
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
Steffen Nurpmeso wrote:
Hello!
I would like to have it, but the implementation is so ugly!
Classic dilemma ...
My "natural" thought would be to have flag carriers, and simply
use bit 1 for "warn" and bit 2 for "error out", but that needs
quite some work.
Sure. Natural and simple idea but
t
obviously no "stdint.h" seen by tcc so far did require any of these defines.
Therefor it might be just a mistake on the cygwin people's side.
Maybe you can try with files from a real riscv system first?
--- grischka
I put together a small patch that seems to fix the issue
(0001
eature (note the ':')
In any case, all existing remote branches including personal ones can be seen
with
$ git ls-remote
Last, if you want to try this, much likely your username won't be 'fred'. ;)
--- grischka
___
Tinycc-devel mailing list
Tinycc-d
Christian Jullien wrote:
Hi no one complains or comments, I suggest you push your patches end of June
Since when do we tell other people what to do and until when, in tinycc?
-- gr
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
1 - 100 of 803 matches
Mail list logo
