On 29.09.2024 09:58, Yao Zi via Tinycc-devel wrote:
endbr64 has no operand but comes with a ModR/M byte. Handle it in the
same way as *fence instructions.
If you know what you're doing then please push
-> https://repo.or.cz/w/tinycc.git
Thanks, -- gr
Signed-off-by: Yao Zi
---
i386-asm.c
On 06.08.2024 07:31, Eric Raible wrote:
Sorry for the self-reply, but I'm still trying to figure this out.
One more piece of information: using -vv I can see that
libm.so is only listed as being loaded one time.
After that, it is available, but is not listed. Which is weird, b.c.
libc.so (for i
On 01.08.2024 13:22, Jonathan M. Wilbur wrote:
I am terribly sorry on both counts. I actually had no idea there even
was a test suite. I thought the test folder was just an assortment of
files to manually test against as needed.
If that were so then after 20 years there would be hundreds of fil
On 16.06.2024 23:01, Jake Anderson wrote:
The "winapi-full-for-0.9.27.zip" file that has a fuller set of the Windows API is broken on the
newest builds. I need to comment out the "#include " in order to compile with the
newest TCC builds.
Any hints what the problem is? tcc error message, som
st. And remove the test file.
Does the "mov ecx" not work because the compiler would falsely believe ecx
can be used again after a function call into windows 32 ABI while windows 32 can clobber
it?
Or what is the reason it won't work?
Best of wishes,
Gynt
On 10.06.2024 11:06, Edward Gynt wrote:
Hi Grischka,
I am very new here, nice to meet you! I fixed the issues:
https://github.com/gynt/tinycc/pull/2
Let me know if I should push this to mob or whether you want to have a look
first.
I hope this is "the route that's already prov
On 07.06.2024 15:03, Edward Gynt wrote:
I am having trouble reproducing your issue. My .exe files output the correct information.
The "C file" code you mention doesn't mark main as a __thiscall, but your
decompiled function lists sub_401000 as __thiscall. Why?
I don't own IDA so I can't reprodu
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 interest
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 version
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 tcc_reloca
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
b
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)
https://repo.or.cz/tinycc.git/com
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 not
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
at links to it, with possibly different 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 {
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 ...
-- g
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?
Obviousl
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:
> This
tps://repo.or.cz/tinycc.git/commitdiff/af686a796bda94dc92fc3ad140ef438dafa08950
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
we could just as 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
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 someth
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 f
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 [-Wc23-extens
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.
Anyway
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: "/usr
me is a well proven 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 re
r to deleted doesn't 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 the
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 libcurses/libcurses.so
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"? prin
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 require
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 line
On 14.08.2023 14:34, Steve Fan wrote:
I want to implement a compressed, read-only header manifest embedded directly
into the compiler itself. This way I can have one single static binary to run
everywhere without headers.
I want to see if we can wrap the C file manipulation API with a custom T
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 better
27;s why I think that our patches must strive for two things always:
1) to fix the problem and 2) in a way that logically does make sense ;)
-- grischka
Herman
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mail
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: inco
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 binar
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. Mo
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 aft
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
w
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 alia
and still 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 ras
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, 17.0
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 u
exists there unchanged because nobody did even try it with
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-dev
ions files -run @ arguments
I'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
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 val
when "tcc -bench"
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
cross-compiler
for example:
./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
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 'sh
or static data 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 th
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'
useful command if you 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_
.
--- 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 thepas
us-defender-etc...ware. What I see is that on a windows-10
with its 'defender' ON, building & 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.
Int
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 u
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 hav
e help me?
Thank 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&#x
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 c
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
DECODING HERE -> patching previous
// jumps?
}
} 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
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
ression.
It shall evaluate 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
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, &start); // Segfaults
}
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
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 desc
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 *p
ide a legal declaration 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 t
was necessary with the introduction 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
linux-gnu/include
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, ar
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 encoun
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. GCC
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, Bar
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 t
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
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 b
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 tim
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
#in
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" b
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
th "#define tok s1->tok" etc. and 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
c
hould 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/.
-
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
y 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
an add one or two tests in 60_errors_and_warnings.c,
if you want.
-- grischka
Suote127
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
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
1 - 100 of 992 matches
Mail list logo
