When doing on x86_64:
cd tests; make btest
I get a core dump:
#0 tcc_add_bcheck (s1=0x46a2a0) at x86_64-gen.c:665
#1 0x004227aa in tcc_add_runtime (s1=0x46a2a0) at tccelf.c:1323
#2 0x00424d6e in elf_output_file (s1=0x46a2a0,
filename=0x46b540 "a") at tccelf.c:2260
#3 0x0
Hi guys,
Testing mod show that ARM and Aarch64 are broken differently. I'm reluctant to
test it only Windows as it will break my Lisp development toolchain.
=== For ARM
gcc -o libtcc_test_mt libtcc_test_mt.c ../libtcc.a -fno-strict-aliasing -I..
-I.
va_list, as used by printf, holds information about variable arguments.
It is implementation dependant. It loses types and sizes of arguments it
contains.
The purpose of format directive is to collect the right object size and
coerce this shunk of bytes into the expected type.
On ARM (32bit
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).
The point I see to a reentrant compiler: You could use this as a
compiling-interpreter.
ie You could write program code into an ordered sequence of text boxes, run
that code as-is, then potentially change that code and (if you chose)
re-evaluate it as it was running.
(?)
On Tue, Dec 10, 2019 at
On Mon, Dec 09, at 03:33 Michael Matz wrote:
> Hi,
>
> On Sat, 7 Dec 2019, Christian Jullien wrote:
>
> > > 2) slower code: most of the time the indirection through a pointer
> >variable (the state) in comparison to a direct access to a static
> >variable doesn't matter.
> >
> > In fa
> #define pv(m) printf(sizeof (s->m + 0) == 8 ? "%llx\n" : "%x\n", s->m)
What's wrong with printf("%llx\n", (unsigned long long)s->m)?
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
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;
(&c)[20] = 21;
free(a);
Seems to pass without any complain.
Btw
Hello,
On Tue, 10 Dec 2019, Herman ten Brugge via Tinycc-devel wrote:
> I still have one small problem with testcase 111_conversion.c
>
> The problem is that it fails on i386.c (linux) when compiling with:
> tcc 111_conversion.c -o 111_conversion -b
> ./111_conversion
>
> I fixed this (and com
Herman,
The error is not from gcc but because the printf format was not correct when
printing long long:
#define pv(m) printf(sizeof (s->m + 0) == 8 ? "%llx\n" : "%x\n", s->m)
Fixes the issue. If you agree I can push this change.
-Original Message-
From: Tinycc-devel [mailto:tinycc-deve
I fixed the Makefile for wine on sourceforge. I cannot test the cygwin
code so I let you do the change.
Regards,
Herman
On 2019-12-10 09:01, Christian Jullien wrote:
It is fixed for Aarch64 not for ARM which still gives:
test3
../tcc -B.. -I../include -I.. -I..
Oops. You reported 2 problems. The second one I cannot fix because the
gcc compiler on arm has a bug.
When tcctest.gcc is run on arm the output is (last 2 lines):
0a
When running this code on x86_64 the output is:
0a
0014
The x86_64 output is correct.
Perhaps we co
It is fixed for Aarch64 not for ARM which still gives:
test3
../tcc -B.. -I../include -I.. -I.. -DCONFIG_TRIPLET="\"arm-linux-gnueabihf\""
-DTCC_CPU_VERSION=7 -DTCC_TARGET_ARM -DTCC_ARM_EABI -DTCC_ARM_HARDFLOAT
-DTCC_ARM_VFP -run ../tcc.c -B.. -I../include -I.. -I..
-D
13 matches
Mail list logo
