Steffen Nurpmeso wrote:
Hello.
So i thought about it and come back to apologize. At least
mildly. I guess the right thing to do would be to strip all paths
which are also in the system array from the user paths present in
the non-standardized $C_INCLUDE_PATH environment variable, even if
that
inycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of grischka
Sent: jeudi 12 octobre 2017 09:32
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] plans to 0.9.27
Christian Jullien wrote:
Chris,
This is precisely why I wrote win32/Makefile which, with only
A
On Wed, Aug 23, 2017 at 8:57 AM, grischka <gris...@gmx.de> wrote:
Andrei E. Warkentin wrote:
Dear tinycc-devel,
A few more fixes for your review.
- support for generating ARM64 PE32+ images
- support for generating X64, ARM64, IA32 (untested) and ARM (untested)
UEFI images.
I don't th
might
be, but it's hard to test and guarantee.
As for making the instructions simple, IMHO we should publish instructions for
users with only microsoft tools, and for users with mingw shell dev env.
On Tuesday, September 26, 2017 6:45 PM, Christian Jullien <eli...@orange.fr>
septembre 2017 19:40
To: 'grischka'; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] plans to 0.9.28
Very nice indeed.
I offer you my time to test every attempts on:
Windows x86/x64
Linux x86/x64
RPi arm
Aarch64
-Original Message-
From: grischka [mailto:gris...@gmx.de]
Sent: dimanche
I wonder which would be the smaller patch: The changes you propose
for tcc or a patch to support these constructs as is in the bootstrap
compiler.
Otherwise if that is not your criterion what would be the arguments
for the semantics that you mention that they do not belong to
"simple enough C"?
Hi,
I just pushed a patch for more complete 'long' support (which was started
by Matthias Gatto for _Generic), as well as with eome improvements for
multicharacter constants:
http://repo.or.cz/tinycc.git/commitdiff/1443039416dd02750765efde1af35e31c8d41be3
So, now, basically, I'd agree to,
pen/read/write/close, more or less),
doesn't look good. A matter of taste. A case of "the feature is not to
have that feature". Which you might or might not agree to ;)
-- grischka
Regards,
Petr S.
___
Tinycc-devel mailing list
avih wrote:
I'd like to push my reproducible build script to mob, are there objections?
Not in principle.
Except I'd appreciate some concept to advise users which method to build
tcc on or for windows to use best in what situation.
We do support:
* msys with the normal ./configure && make &&
avih wrote:
Two things:
1. Will the version be 0.9.27 or 0.9.28?
0.9.27.
2. On windows in msys2 mingw 64 environment with gcc 7.2.0, (building tcc 64
for windows with mingw gcc 64) the build completes but some tests fail (see
below).
Works for me with gcc 5.3 and earlier but does not
Larry Doolittle wrote:
The comma operator example you posted, that confused me at first,
is an exception, and I just pushed a patch.
You override someone else's style decision with your own because you
are confused?
We're all confused, eventually.
-- gr
Joel Bodenmann wrote:
Hello folks,
I am successfully using libtcc in an application. I'm very happy with it and
I thank you for providing this awesome tool.
So far, my needs were basically completely covered by the libtcc_test.c
example program that uses tcc_add_symbol() to give the
avih wrote:
> On Wednesday, September 27, 2017 9:30 AM, grischka <gris...@gmx.de> wrote:
> May I suggest something: Why don't you guys combine your knowledge> and
personal preferences and apply it to our standard Makefile instead> of adding each
your own scripts
grischka wrote:
avih wrote:
Two things:
1. Will the version be 0.9.27 or 0.9.28?
0.9.27.
2. On windows in msys2 mingw 64 environment with gcc 7.2.0, (building
tcc 64 for windows with mingw gcc 64) the build completes but some
tests fail (see below).
Now, I fixed that, plus the ARM
ease win32 binary packages.
No problems with maintenance, no extra files to confuse the user, just
a new make target that everybody can use:
./configure
make win32-dist
What do you guys think?
--- grischka
___
Tinycc-devel mailing list
Ti
fined symbol 'x5'
$ tcc -c t1.c && objdump -x t1.o
SYMBOL TABLE:
ldf *ABS* t1.c
004a l .text 001f x5
Here 'x5' should have the g[lobal] binding from C.
--- grischka
___
T
avih wrote:
- tcc 64 fails the asm tests (again, all versions regardless of how it was
built).
Different calling convention on win64. I'd suggest the attached
version which is more platform neutral.
-- gr
On Thursday, November 23, 2017 8:17 PM, grischka <gris...@gmx.de>
' is a string prefix in newer gcc versions.
(Don't know, maybe for unicode?).
Btw, what about the "vide" hack on tccasm.c:1020 from commit 6afe668ec
Can we delete it?
Ciao,
--- grischka
avih wrote:
The test is always compiled by tcc.
Of course.
So if you say "initial compiler&
data section.
I don't see how commit e7c71e24 could make a difference.
Are you sure the .def file isn't generated by a TCC from a commit before?
Otherwise I'm at a loss, and not having a Windows system I can't help
much. grischka, any ideas?
.def is created automatically if an "export
then say ... next Sunday.
Thanks,
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Michael Matz wrote:
Maybe this is the problem in that gdb doesn't want to read debug info
further after seeing this error?
Yes, seems that GDB (or some version of) refuses to load any symbols
at all, also not from stabs, if dwarf info (which comes from crt1/i/n.o)
is broken.
And that might
Jullien Claudio Bley Daniel Glöckner
Dave Dodge Dave Long David Mertens Dennis Yurichev
Detlef Riekenberg Domingo Alvarez Duarte Edmund Grimley Evans emekoi
Emil Fabrice Bellard Felix Nawothnig Filip Navara Frédéric Féret
Gabriel Corneanu grischka gus knight Hanzac Chen
ple that "free_asm_labels"
should be called only once at the end of each "translation unit" (file).
Below is some test that I just have tried.
--- grischka
$ gcc -c t1.c t2.c && gcc t1.o t2.o -o t.exe && t.exe
x1
x2
x3
$ tcc -c t1.c t2.c && tcc t1.o t2.o
Forgot to mention the actual benefit from my former change:
It was (IIRC) to allow the dlltest test pass on musl. (That is
to use tcc on x86_64 to create a libtcc.so without DT_TEXTREL)
-- gr
grischka wrote:
Michael Matz wrote:
Hello grischka,
I had to revert a small part of your da8c62
altogether and instead handles R_XXX_RELATIVE in the relocate backends
(as it should be).
It also sets the uw_pdata section in case it was not set by any
compilation, that is if you wanted to run just already compiled
object files.
If it works I'll push that later.
--- grisch
ception_caught == 1);
}
*Also, if I directly pass the 'p' pointer above from
**pe_add_unwind_data** into
**RtlAddFunctionTable **(by hacking some stuff), everything works as it
should and the test passes.*
So I wouldn't mind fixing this, but if anyone (especially grischka) could
shed some ba
bols as "static" first always. This however needs to
post-process asm symbol again (to convert any still undefined symbols
to globals), as well as to patch relocation entries if such global
already was defined in a previous file.
See attached (additional) patch. It definitely
e release, say next Sun (17.12.)
How does that sound?
--- grischka
Ciao,
Michael.
commit 13a9037e137c1f75bb1023fcc9d0226591a5ba0f
Author: grischka
Date: Sun Dec 10 10:25:33 2017 +0100
fix
diff --git a/tccgen.c b/tccgen.c
index 4159b9e..47098c2 100644
--- a/tccgen.c
+++ b/tccgen.
ssibly simpler and
better approach then I think it's worth to still wait, 1, 2, 3 ...
weeks doesn't matter ;)
--- grischka
Ciao,
Michael.
commit 21f943378bbbec0a499412e411ddecd51e505b89
Author: grischka
Date: Thu Nov 30 15:15:22 2017 +0100
tccasm: use global(_symbol)_stack
* re
me of course ;)
Thanks,
-- grischka
Best Regards,
Jason
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
to access the stab sections at runtime is win32 specific though.
-- gr
Thank you
Yash
>From dfbfa24f6370b8d4038d3fe886ca047c69a381ed Mon Sep 17 00:00:00 2001
From: grischka
Date: Wed, 15 Sep 2010 13:43:54 +0200
Subject: tccrun: enable standalone backtrace
Tested on win32. Detailed recipe:
the wrong _stat struct did not issue a
warning as it should, here
http://repo.or.cz/tinycc.git/commitdiff/2b155a8c16b2856461020e65370385347a485d65
Ciao,
--- grischka
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https
emekio,
please remove the binary file (libtcc.so) from your commit, then
push again.
--gr
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
tcc@web.de wrote:
The i386-tcc compiler can't build a binary on a 64bit linux,
because it can't find the crt*.o start files.
cross-compilers need manual configuration, type 'make help'
-- gr
The missing files are present in:
/usr/lib/i386-linux-gnu
additional static libraries are
Kenneth Roger wrote:
The method described in tcc-win32.txt for linking windows resource files
does not work. For example:
C:\tcc\lib00>\mingw\bin\windres -O coff gen.rc -o genres.o
C:\tcc\lib00>..\tcc gen.c genres.o -o gen.exe
genres.o: error: unrecognized file type
I'm using
j...@ysengrin.com wrote:
Hi,
Thanks for releasing a new version and specially
for adding the full winapi.
shlobj.h was missing before this useful addition.
So I finally was able to compile, link and run
my little project with tcc
http://tinyfiledialogs.sf.net
However, I had to make 2
grischka wrote:
Though it seems to me that if you do
#define _wstat _wstat64
then you'd also need to
#define _stat _stat64
in order to have the st_Xtime members filled correctly.
Hm. Actually I wonder since when tcc doesn't warn if a function
is called with an incompatible struct
k2tom wrote:
tcc -o test.exe test.c -mwindows
-mwindows nas no effect. TCC will create a GUI executable automatically
if there is a WinMain function.
tcc: _winstart not defined
I suspect the libtcc1.a that you once did build yourself is missing
files. See
Christian Jullien wrote:
Grischka,
FYI The link on http://download.savannah.nongnu.org/releases/tinycc/ is not
working => 404
Not YET working, I suppose:
Downloads will redirect to your nearest mirror site.
Files on mirrors may be subject to a replication delay of up to 24 ho
g);
/* mov %xmm0, %rxx */
o(0x66);
Thanks,
-- grischka
If you wanted to do that optimization correctly, you'd need to build
control flow graph, and tcc is just too simple to do that.
Mikulas
Signed-off-by: Mikulas Patocka <mpato...@twibright.c
grischka wrote:
But why, as the comment suggests, some versions of GDB work better if
dwarf info is broken remains a mystery to me. Maybe these won't
load stabs if dwarf is ok.
If it were me I'd still just remove that "&& (s->sh_flags & SHF_ALLOC))".
Ok, I was able
Agathoklis D. Chatzimanikas wrote:
On Fri, Mar 23, at 08:58 grischka wrote:
Agathoklis D.E Chatzimanikas wrote:
Hi,
I created a tinycc binding for the S-Lang programming language,
https://github.com/agathoklisx/slang-devel/tree/master/slang-modules/tcc
and while I was trying to create
you can fix it on the mob branch,
welcome.
Thanks,
-- grischka
Best
Αγαθοκλής
p.s.,
(note that my C Fu is at a novice level, so be kind for any error :))
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.o
tion might return no value: 'intr'
Auto Test3 OK
That is maybe because your headers #define __attribute__
Try
#undef __attribute__
somewhere.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Pascal Cuoq wrote:
int t[][3]; [ error: unknown type size ]
Actually that is not wrong. It's the same as
extern int t[][3];
MSVC accepts it without warning, and GCC too if either 'extern' or
the size is still specified:
int t[][3];
extern int t[][3];
or
int
Harald van Dijk wrote:
As that commit is an optimization, not a codegen fix, I would like to
ask whether the original issue is still present and just requires a more
complex test case to expose, or whether it has accidentally been fixed
by this commit.
No, I think this bug must exist since the
uot; and
"te-amo-godmau5" (and some more).
As to "prevent them from being re-added" I didn't see how right now.
Thanks,
-- grischka
Cheers,
Harald van Dijk
___
Tinycc-devel mailing list
Tinycc-devel@nongn
nup
ARM C aarch64 c67 compiler fast generator linux otcc
relicense tcc tinycc windows x64 x86
Thanks,
-- grischka
Cheers,
Harald van Dijk
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.o
Michael Matz wrote:
So let's find out what causes the difference: if you can send me ...
Well, see win32/lib/chkstk.S, at the bottom
/* SEH on x86-64 not implemented */
;)
One could try the code below instead but I would need some time to
rethink how good it is.
--- grischka
static
AndreyCh wrote:
Hello,
How can I add the path to .def files,
the -I or -L switch does not work.
tcc -vv glfw.def opengl32.def glu32.def -DGLFW_DLL -run triangle.c
-L always has an effect only in combination with -l :
tcc -L -lglfw ...
With this tcc will look in for
glfw.def,
and dreams ;)
-- grischka
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
ant, except compilation itself. Such that in order to be
thread-safe one would need to put a semaphore just around the "tcc_compile()"
function.
-- grischka
So, while I can see the wish for this feature, I don't necessarily see
that tcc should be changed to accomodate.
If anything I would
Hey,
Couldn't help to try out some things, related to the matter.
See
https://repo.or.cz/tinycc.git/commitdiff/72729d8e360489416146d6d4fd6bc57c9c72c29b
Anyway I think, it still does look like tinycc.
--- grischka
ag wrote:
And at the end is always about mechanics and mechanism[s] (funny
ep' and 'gettimeofday', maybe it needs unistd.h or time.h or
maybe sys/time.h. I see your gcc suggests to use 'fseek' instead of
'usleep'. That is interesting.
Thanks,
--- grischka
=== For ARM
gcc -o libtcc_test_mt libtcc_test_mt.c ../libtcc.a -fno-str
Ulrich Schmidt wrote:
Am 11.12.2019 um 03:58 schrieb grischka:
With multi-threading though, the underlying machine tcc code, should
account for
side effects of the shared execution space, so adds even a tiny bit
(and with the
best of efforts) of complexity. So that is not quite primitive
uso ewin wrote:
On Wed, Dec 11, 2019 at 3:44 PM Michael Matz wrote:
Hi,
On Wed, 11 Dec 2019, grischka wrote:
Couldn't help to try out some things, related to the matter.
See
https://repo.or.cz/tinycc.git/commitdiff/72729d8e360489416146d6d4fd6bc57c9c72c29b
Yeah, something like
this case (except one wanted to compile files
from within a TCCErrorFunc callback ;)
Cheers,
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
idea you could come up with,
given the common limitations of time of course.
Also, new features should have at least some relevance for other people
too. Which personal easter-eggs or home-brew temporary debugging add-ons
usually don't.
Thanks,
--- grischka
Herman ten Brugge via Tinycc-devel wrote:
I just committed a large patch that fix a lot of bounds checking problems.
Hmm, is this supposed to find something, too? For example:
{
char a[10], b[10], c;
b[15] = 16;
()[20] = 21;
free(a);
Seems to pass without any complain.
Btw,
/msys2/wiki/MSYS2-installation
There is a 'mingw32/64_shell.bat' to start the shell. I wouldn't
at first update the base itself as they describe, just use as is.
To start with:
pacman -S mingw-w64-i686-gcc (or -x86_64-)
pacman -S make diffutils
--- grischka
with DLLs/SOs too (i.e. multiple instances of stab
debug infos). See
https://repo.or.cz/tinycc.git/commitdiff/ef42295f
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
t;void f() {}" | tcc - -shared -o a.so
echo "main() {}" | tcc - a.so
Thanks,
--- grischka
All other tests in 112_backtrace.c have simular problems.
Perhaps I did something wrong with windows/wine. I only use windows
to update my tomtom.
The makefile for w
25960 of Verneed record
--- grischka
Regards,
Herman
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
d 327 bytes
(0) before:
../lib/bt-log.c:61: at test_stack: 7008
../tccpp.c:2772: parsing at 'next_nomacro1'
../tccgen.c:2214: by gen_opic
../tccgen.c:2674: by gen_op
...
../tcc.c:346: by main
[136 levels]
code: 220284 bytes, suppressed 327 bytes
--- grischk
f;
} else
gvtst_set(i, t);
This appears to generate byte-identical code to before, with my tests.
option 2:
moving up 'ncw_prev = nocode_wanted;'.
This appears to work too but generates more code.
It's all somehow brittle, with the mix of ++/-- with |=/&a
on)
s : Shell (exit to return)
7 : Back to Basics
0 : Quit
Enter: _
See also the included 'about.txt'. Last and only somehow related, I
pushed a patch on 'mob' to allow make to run more silently.
Cheers,
-- grischka
___
Tinycc-dev
ome notes somewhere though, about how people can
build this and how and where they can use it at all. ;)
--- grischka
Erlend Sveen wrote:
Hi,
It's been a while now since I've been working on and off various projects
for the last few months, but I finally think my TCC additions are ready for
a sec
avih via Tinycc-devel wrote:
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
Pursuer wrote:
Thanks a lot for your rearranging and advice.
by the way I'm sure I only add tcc.h to the commit "misplaced parenthese
around...", So I'm also confused about the side-effect mentioned
by Christian Jullien. (In fact I had cloned a new copy before
rearranging, In which the
John Scott wrote:
Hello,
I've pushed a couple miniscule commits to mob and would like to work up to more
complex tasks. I've reported more issues than I've fixed and would like to turn
that around
Hi, fixes are always welcome but don't start with things that aren't
broken: MS-VC8's
,
MAP_PRIVATE, fd, 0);
+#endif
Might depend on what selinux features you have enabled but IIRC
alpine musl for example did not allow to run code from memory
that once was allocated as writable.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel
advantages.
--- grischka
Regards,
Erlend S.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
changed, 124 insertions(+), 155 deletions(-)
libtcc: accept tcc_define_symbol(s1, "sym=value", NULL)
3 files changed, 19 insertions(+), 44 deletions(-)
that is -152 lines total ;)
-- grischka
___
Tinycc-devel mailing list
Tinycc-devel@
t at least *tries* to explain
something, for the other people, I mean. ?
-- grischka
Herman
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
target, aka wince. I don't know if
it's still functional (or ever was) though.
--- grischka
The only target that does now uses DT_TEXTREL is i386. But this requires
a complete rewrite.
Herman
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
Arthur Williams wrote:
I noticed a problem with tcc and _Generic that caused function pointers
with different return types to be treated as compatible which would
prevent the following code from compiling with the error "error: type
match twice".
I'm aware that the person who originally added
Tyge Løvset wrote:
I have slowly started to look into the core code of tinycc, but can't
help being annoyed by the inconsistent formatting of the code, in
particular the mixing of tabs and spaces. (sometimes tabs means 4
indents, sometimes 8).
Not anywhere in tcc that I know are tabs equal to
Herman ten Brugge via Tinycc-devel wrote:
On 12/18/20 2:45 PM, grischka wrote:
Christian Jullien wrote:
On OpenBSD:
I noticed some tests were excluded but the reasons were say
not really obvious:
Test: 106_pthread...
From it's name it's testing pthreads. OpenBSD appears to have
pthreads
Christian Jullien wrote:
On OpenBSD:
I noticed some tests were excluded but the reasons were say
not really obvious:
Test: 106_pthread...
From it's name it's testing pthreads. OpenBSD appears to have
pthreads. So what is the deal?
Test: 113_btdll...
Seen from the snippet below, tcc
I removed that check. Probably it was there for a reason once but
I don't remember what it was. At best it is not needed anymore.
--- grischka
Any hints how I could modify that code?
I am not a PE expert and thus I do not know how uninitialized symbols
are represented in PE.
Best Regards,
Code Hz wrote:
Hello,
This is the minimal sample input, it only crash on the windows, but I
do not think it is os-dependent.
```
b(){"
"2
```
I fixed that. The problem here was not with the multi-line string but
rather with the two constant tokens ("" & 2) following each other
immediately
tinycc.git/commitdiff/aeb8f427e2be133d6a0a67b695eb9579f5fa4232
-- grischka
... but alas, fixed in mob.
Thanks for the report, Arnold.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Danny Milosavljevic wrote:
So I think what happened is that one time I force-pushed and overwrote the mob
branch with a command like the one above (sorry). It should have only affected
a tiny bit though since I rebase arm-asm on top of mob.
Do not use the -f option with push, please.
In
what scenario, and is it desirable always or should it maybe depend
on a -fPIE switch or like that?
Thanks,
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
a solution. But maybe Grischka can solve this?
Don't know, maybe look what gcc does?
However, with your example, for example, one could take the address
int *p =
and pass that to other functions, as well. There is not much
that the compiler could do.
For the 96_nodata_wanted test using 'packed
)
and also not
'return' with a void value (in asm_opcode());
---grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Danny Milosavljevic wrote:
Since I don't have that compiler, please test.
Works, thanks. Looks very good btw, the arm-asm ...
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc
'working' example of what
you have in mind. As if the compiler that has all the experimental
features that it needs to run it, already would exist.
--- grischka
Thanks.
Ivan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https
Wwrite-strings. Hmm.
Maybe if we had a feature to find any currently non-const declared
objects that still are not modified anywhere (and therefor could be
marked const), maybe that could be useful...
--- grischka
Some people like the idea [1][2].
Such a thing had been implemented for Common Lis
(CFLAGS/LDFLAGS += -g)
and
./configure (LDFLAGS += -s)
Any reason why we need more than that?
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
in progress for something, the
'git add --amend ...'
option can be very helpful to correct mistakes or review an idea
already before one would push the push button finally.
For happiness with less #ifdefs,
--- grischka
Christian.
___
Tinycc-devel
Herman ten Brugge via Tinycc-devel wrote:
I did test this on arm32 openbsd. This is where the problem was.
However the above patch fails. I will provide a new patch.
I need to add support float/double/long double/pointers for this to work.
I would suggest just to forget it. Nobody will ever
KED;
//#endif
and run the tests?
Btw, do we really need all these gen_increment_tcov ()'s?
Can't we just use the inc(0, TOK_INC) for all targets?
--- grischka
Herman
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.
Dwight Schauer wrote:
With "0.9.27 - 0378168" I get some unexpected behavior.
1) the byte sizes of compilation units (separate libtcc states)
are about 8K larger each than with the stock libtcc
runtime memory now gets permissions (r/w/x) set per section more
accurately however this means that
Christian Jullien wrote:
All parameters go to the right arguments. So patch looks good
What happens if the first condition is false (A = 0) ?
-- gr
void main() {
int A = 1;
int B = 2;
map_add(10, 20, 30, 40, 50, 60, 70, 80, A && B);
}
$ tcc foo.c -o foo && ./foo;echo
Elijah Stone wrote:
Actually, the problem is with the CEXPR_EH macro; it always returns 1.
If I replace the definition with '#define CEXPR_EH
__builtin_constant_p', all of your tests pass.
I guess the problem is that the behaviour of this clause (from 6.5.15p6)
is not correctly implemented:
Pursuer via Tinycc-devel wrote:
Christian Jullien wrote:
Without the patch, it also coredumps on Risc-V:
So you mean the second patch can fix this?
As I haven't got other complain or comment about the patchs yet. Should
I push the second patch?
While reasons or explanations may vary,
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
Elijah Stone wrote:
I should clarify: these are not extensions to make tcc run on plan9 or
target it. They are just regular extensions which happen to originate
in plan9. They're also implemented by gcc; see documentation at
https://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html
While nicely
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
601 - 700 of 803 matches
Mail list logo
