Hello,
On Tue, 10 Oct 2023, Herman ten Brugge via Tinycc-devel wrote:
On 10/5/23 22:55, Detlef Riekenberg wrote:
After the comments from grischka and Michael,
i prepared a different patch to fix the build break of netbsd-curses
and also updated the patch to current mob.
`make test`
Hello,
On Sat, 23 Sep 2023, grischka wrote:
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 ." for example. There is
only one place from where tcc_load_dll() is called:
in
Hello,
On Tue, 12 Sep 2023, avih via Tinycc-devel wrote:
> Also, what is "pure machine code"? With neither input nor output it
> couldn't do anything but waste instruction cycles.
A function implemented in machine code, where the input is the
arguments in whatever calling convention the
Hey,
On Wed, 8 Mar 2023, Detlef Riekenberg wrote:
> Your commit c771cb52 fixes a lot of bugs in the yarpgen v1 generated tests.
>
> For seed values from 1 to 99, only 4 result failures left: 26, 56, 64 and
> 84.
> For 100 to 200, there are some more result failures (102, 117 and 173)
> and some
Hey,
On Sat, 18 Feb 2023, wine@web.de wrote:
While trying yarpgen (v1 branch of github.com/intel/yarpgen ),
various test files compiled with tcc (x86_64@linux) produce a wrong result.
I compared the first failed program with gcc
and found an "if" section in the example code,
where the
Hello,
On Thu, 17 Nov 2022, Christian Jullien wrote:
Test later fails with
tcctest.c:2903:17: error: incompatible pointer to integer conversion passing
'void *' to parameter of type 'int' [-Wint-conversion]
old_style_f((void *)1, 2, 3.0);
^
So, this is a
Hello,
On Thu, 20 Oct 2022, avih 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 indeed the case on win10 for you. So,
ion 1764:58]
__FILE__, __FUNCTION__, dest, src, (unsigned long)n);
[position 1774:58]
__FILE__, __FUNCTION__, dest, src, (unsigned long)n);
[position 1784:58]
__FILE__, __FUNCTION__, s, c, (unsigned long)n); [position
1794:53]
__FILE__, __FUNCTION
Hello,
On Fri, 14 Oct 2022, avih via Tinycc-devel wrote:
0x7ff72b42b266 <+50>: repnz scas %es:(%rdi),%al
0x7ff72b42b268 <+52>: dec %edi
This is the problem. "dec %edi" truncates the %rdi register to 32bit by
zero-extension, so that ...
0x7ff72b42b26a <+54>: mov
Hello,
On Sat, 1 Oct 2022, Liam Wilson wrote:
Note __attribute__((constructor)) has been stripped off bar and not foo.
Yep, that's the glibc headers defining __attribute__ away ...
Digging a bit further, it seems to be due to sys/cdefs.h (which is
included by string.h and many other
Hey,
On Sun, 18 Sep 2022, Detlef Riekenberg wrote:
tcc can't compile the attached VLA check (gcc works)
and configure adds "#define __STDC_NO_VLA__ 1" to config.h
The code was generated using the autoconf macro "AC_C_VARARRAYS".
console output:
tcc -std=c11 vla_conftest.c -c
Hey,
On Tue, 16 Aug 2022, ntysdd via Tinycc-devel wrote:
Sorry, bad format.
#define G(x) _Generic((x),int*:"int*",void*:"void*")
int printf(const char*, ...);
int main()
{
int y = 0;
const char *s = G(1?(void*)(y*0LL):);
printf("%s\n", s);
}
Fixed in mob.
Hey,
On Fri, 6 May 2022, Raul Hernandez wrote:
It would seem better to canonicalize during generating this, because
the above and this don't look equivalent anyway (they are equivalent
only when the above relative path is less that seven levels deep from
/).
In our case this isn’t an
Hey,
On Thu, 5 May 2022, Raul Hernandez wrote:
The code we generate looks something like this:
#line 29
"../../../../../../home/spaceface/git/v/v/vlib/builtin/builtin.c.v"
It would seem better to canonicalize during generating this, because the
above ...
Hi,
On Tue, 26 Apr 2022, Raul Hernandez wrote:
I guess TCC does this as either an optimization (to take advantage of
vectorization in the implementation of memmove), or as a way of simplifying
the generated code.
The latter, plus simplifying the generat_ing_ code (i.e. TCC itself).
My
Hello,
On Sun, 17 Apr 2022, Volodymyr Boyko wrote:
Hi
I'm trying to assemble the following snippet of code:
.global sigsetjmp
.global __sigsetjmp
.type sigsetjmp,@function
.type __sigsetjmp,@function
sigsetjmp:
__sigsetjmp:
mov 8(%esp),%ecx
jecxz 1f
mov 4(%esp),%eax
Hello,
On Fri, 8 Apr 2022, Davidson Francis wrote:
Hi Domingo, thanks for the additional data. That's exactly what I've
observed here: no type of lock or special instruction is generated,
nor is a function call generated either.
I'm not well-versed with compilers, but looking through the
Hello,
On Mon, 28 Feb 2022, John Scott wrote:
On Mon, 2022-02-28 at 09:25 +0100, david.k...@libertysurf.fr wrote:
Gcc allows this, but Gcc is not conformant and creates "extensions" as it see
fit.
This is not a GCC extension; it's my understanding that this is pure
C99. N2310 [1] (a C17
Hello,
On Tue, 1 Feb 2022, Domingo Alvarez Duarte wrote:
Hello Elijah !
On 1/2/22 6:30, Elijah Stone wrote:
‘cleanup’ variable attribute
It doesn't seem that tinycc has this implemented properly because testing it
with this example
Hello grischka,
On Tue, 7 Dec 2021, grischka wrote:
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
Hey,
On Tue, 7 Dec 2021, Antoni Gual Via wrote:
Perhaps it's time to have a new official release?Antoni
Perhaps, but not because inlining would be done now: it isn't. TCC
doesn't inline functions into others. But due to how c99 and c11 have
special requirement for functions marked
Hey,
On Sun, 5 Dec 2021, Herman ten Brugge via Tinycc-devel wrote:
On 12/1/21 15:18, grischka wrote:
Got this report on private email. Not sure what it means ...
-->>
Output of the code below if compiled with TCC is
Hello,
On Mon, 9 Aug 2021, Elijah Stone wrote:
IMO a cleaner solution would be to support clang's
__has_feature/__has_builtin/__has_extension. This:
- Is clearer: says exactly what you mean.
- Is less error-prone; if a feature goes away in a later version or in
some configuration, or if
Hello,
On Tue, 27 Jul 2021, Christian JULLIEN wrote:
In order to support tcc bootstrap with tcc on macOS, we'll need to add -arch
option to tcc.
It should at least support this option even if nothing is implemented
because -arch is now given on macOS because of this new configure test:
Why
Hello,
On Mon, 19 Jul 2021, Sam Ellicott wrote:
I updated my patch to only include the bare minimum definitions
required to get tcc to compile the newlib stdint.h header. Thank you
for the advice on using the config-extra.mak file, that worked
perfectly.
If this looks okay, then I will push
Hello,
On Wed, 7 Jul 2021, Sushant Pandurangi wrote:
Thanks for the Windows patches and the long double fix.
To clarify about tcc -run, I'm not using --cpu=x86-64 at all, I am on a
fresh M1 and Rosetta is not even installed. Here, `tcc -run` starts running
main() and very simple stuff (like
Hello,
On Mon, 5 Jul 2021, Christian Jullien wrote:
With
./configure --cpu=x86_64
I can build a working tcc on macOS Big Sur M1.
Compiler works using Rosetta, generated code also produces x86_64 code which
runs the same way using Rosetta.
So your patch is workable solution to build and use
Hello,
On Sat, 26 Jun 2021, Elijah Stone wrote:
On Sat, 26 Jun 2021, Clive Tovero via Tinycc-devel wrote:
Also watch out for "ar", this will cause the problem too.
Perhaps 'tcc -ar' should add libtcc.a automatically (unless you tell it not
to)? That way it would be possible to compile a
Hello,
On Tue, 4 May 2021, uso ewin wrote:
Tinycc handle inline function like if they were macro, so using inline
in tcc always inline functions.
That's not accurate. Inline functions in TCC are emitted like normal
functions but only when there's reason to emit them (which are involved
Hello,
On Mon, 26 Apr 2021, Hayden Seay wrote:
Hello there! I'm sure you're likely aware, but, as of macOS Big Sur,
system dylibs are found exclusively in the dyld_shared_cache.
This poses a unique issue, where nothing can be linked now, as it can't
find a libc mach-o. This can be solved
Hello,
On Mon, 19 Apr 2021, Michael Matz wrote:
I'm not sure what "this" refers to here, but we basically need to accept any
of these forms of decls and defs of main:
int main();
int main() { ... }
void main();
void main() { ... }
Gah! And of course also the ones with void (
Hello,
On Sat, 17 Apr 2021, Stefanos wrote:
No particular reason most probably (except in the case when specifically
the standard mandated behaviour of 'int main()' is tested). If you prefer
the void form for new tests use it. (please don't change existing tests
except for good reasons)
Hello,
On Sun, 11 Apr 2021, Stefanos wrote:
I hope you are doing well.
The following line in commit 48df89e10e confused me a bit: "don't use
c99 in tcc (array designators etc.)"
Which C version is being used in TCC's implementation, can you please
clarify?
If you restrict yourself to
Hello,
On Mon, 29 Mar 2021, Ivan Medoedov wrote:
Hi Christian,
Just to confirm, you are ok with using GitHub Actions as the official CI for
the project?
What makes something official to you? Noone can hinder you in setting up
CI for anything you are interested enough to invest the work.
Hello,
On Mon, 22 Mar 2021, Dmitry Selyutin wrote:
"is it really the same type?"
A bit ambiguous wording. What I mean is that, for a naturally-aligned type
N, the corresponding call can be generated to routine __atomic_X_N. The code
generator doesn't need to care whether types in the
Hello,
On Mon, 22 Mar 2021, Dmitry Selyutin wrote:
Is the above atomic_load supposed to be similar to the GCC __atomic_load
intrinsic?
No, it's supposed to be similar to __atomic_load_N.
I see. Those return integer types and hence aren't convertible to struct
types either (not even with a
Hello,
On Fri, 19 Mar 2021, Dmitry Selyutin wrote:
Some complex types can still be small and simple enough to fit into
register. Other compilers allow some operations on these types, and it
seems to be quite a reasonable choice. From now on, we should be able
to compile the following
Hello,
On Mon, 22 Mar 2021, Dmitry Selyutin wrote:
> Dispatching to per-type functions (instead of per-size ones) is mere busy
work
Having a function per each supported size plus one for emulated locking is
still safer than having a pair, where one deals with opaque data type.
> all that code
Hello,
On Sat, 20 Mar 2021, Dmitry Selyutin wrote:
This needs casts, both sign- and type-wise, e.g. signed long long to
unsigned char, and has no way to enforce type safety, even in the minimal
form. A minimally suitable form would require a statement expression, plus
typeof, and even then it
.
Le : 24 février 2021 à 18:24 (GMT +01:00)
De : "Michael Matz"
À : "jull...@eligis.com" ,
"tinycc-devel@nongnu.org"
Objet : Re: [Tinycc-devel] macOS Big Sur M1 port status
Hello,
On Mon, 22 Feb 2021, Christian Jullien wrote:
Hello,
On Wed, 24 Feb 2021, Yakov wrote:
Thanks for checking. I just tried again and I found that it only
crashes with `-run`. Actually I had `-run` misbehaving many times.
Just today strcpy() was SIGSEGV i.e.:.
int main() {
char *c = malloc(6);
strcpy(c, "hello");
}
That still leaves
Hello,
On Mon, 22 Feb 2021, Christian Jullien wrote:
I started to adapt mob to compile tcc natively on M1 (which is a damn
cool and fast CPU, really).
With my few latest changes already pushed on mod, I’m able to build tcc
and its libs.
I’m facing an important issue with Big Sur,
Hello,
On Mon, 15 Feb 2021, Elijah Stone wrote:
On Tue, 16 Feb 2021, Michael Matz wrote:
(Note that TCC and GCC behave different with non-top-level flex array
members: GCC accepts but discards initializers of these with a warning,
TCC rejects them. That's fine, flex array members
Hello again,
On Tue, 16 Feb 2021, Michael Matz wrote:
On Sun, 14 Feb 2021, Dmitry Selyutin wrote:
The first patch introduces a set of routines which any platform which
wants to support atomics must implement. I don't quite like that
there's a lot of code duplication, but I haven't come up
Hello,
On Sun, 14 Feb 2021, Dmitry Selyutin wrote:
The first patch introduces a set of routines which any platform which
wants to support atomics must implement. I don't quite like that
there's a lot of code duplication, but I haven't come up with a good
idea on how to avoid it (I've been
Hello,
On Mon, 15 Feb 2021, Herman ten Brugge via Tinycc-devel wrote:
I ran the tests/gcctestsuite.sh script and found one test that dumps core.
($GCC_DIR/gcc/testsuite/gcc.c-torture/compile/pr28865.c)
The reduced testcase is:
struct A { int a; char b[]; };
struct A a = { 1, "1" };
struct B
Hello Dmitry,
On Sat, 13 Feb 2021, Dmitry Selyutin wrote:
I work on support for std atomics and currently attempt to switch from
the initial idea of calling the routines to inlining the assembly
code. Unfortunately I'm lost in the relationships between the code
generator and SValue stack.
Hello,
On Sun, 7 Feb 2021, Zhuo Zhang wrote:
Hi,
I am writing to report a stack exhaustion on current TinyC ‘mob’ Branch, which
is triggered when compiling a crafted program (named pop_stack.c and attacked).
+ How to trigger the bug:
simple run “./tcc poc_stack.c"
+ Detailed
Hello Danny,
On Sat, 13 Feb 2021, Danny Milosavljevic wrote:
as of commit 24c94fff09ea21f2e70b575256824e4648124aad on tinycc mob,
arm-asm is finished. I've added all that one could reasonably want in
lowest-common-denominator ARM assembly.
That's quite cool!
(For
Hello,
On Thu, 11 Feb 2021, Zhuo Zhang wrote:
A heap-buffer overflow occurs in commit
fbef90a7039b994907db34fde50f6fa5e46ab535 (ASAN on).
System info: ubuntu 18.04, x86-64
$ cat poc.c
a() {
int b;
asm("" : : ""(b == 0), ""(b));
}
Thanks for the report, it showed a real bug. Fixed in
Hello,
On Thu, 11 Feb 2021, Zhuo Zhang wrote:
I find there is an assertion failure in current tcc code.
$ cat poc.c
int a = b(c() * 1e678);
$ ./tcc -c poc.c
test.c:1: warning: implicit declaration of function 'b'
test.c:1: warning: implicit declaration of function 'c'
tcc: x86_64-gen.c:530:
Hello,
On Thu, 11 Feb 2021, Zhuo Zhang wrote:
A global-buffer overflow occurs in commit
fbef90a7039b994907db34fde50f6fa5e46ab535 (ASAN on).
System info: ubuntu 18.04, x86-64
Without ASAN, tcc will encounter a segment fault due to this overflow.
Actually you won't get a segfault but an
Hello,
On Thu, 11 Feb 2021, Ayush Varshney wrote:
[1] https://www.researchgate.net/publication/245578769_Fully_Countering_Tru
sting_Trust_through_Diverse_Double-Compiling
On Thu, Feb 11, 2021 at 9:27 AM Ayush Varshney
wrote:
Hi everyone,
Hope you all are doing well!!
I am new to the
Hello,
On Tue, 2 Feb 2021, Kyryl Melekhin wrote:
Hello Grischka and Tcc community,
I have found a regression bug in Tcc code gen (X86_64).
Caused by this commit: 8227db3a23fd3cf11840eaa25eab5f3f5f813ac7
This may have triggered the problem, but I think only by chance. The bug
is really in
Hello,
On Thu, 21 Jan 2021, Elijah Stone wrote:
You can't declare a struct in the declaration part of the for stmt
(6.8.5p3), only objects of auto and register class.
Hmmm. I think the spec is somewhat ambiguous here.
The specific wording is:
The declaration part of a for statement
Hello,
On Thu, 21 Jan 2021, Elijah Stone wrote:
Patch is attached to fix tcc scoping behaviour. Test should be
self-explanatory. (Citation: c11 §6.8.4p3 and §6.8.5p5.)
Nearly, but your testcase isn't completely C99/C11. It's not related
to the scoping issue you fixed, but to a side
Hello,
On Tue, 19 Jan 2021, Steffen Nurpmeso wrote:
Bruno Haible wrote in
<2278523.dGrNHthDRc@omega>:
|Michael Matz wrote:
...
|> Okay, that's quite limited, and very easy to implement: disallow casting
|> away immutability and you're done. But in this limited form you then
|&
Hello,
On Mon, 18 Jan 2021, Bruno Haible wrote:
Michael Matz wrote:
... you also need to invalidate all _copies_ of wp:
wp = malloc(); init(wp);
p = freeze(wp);
globalp->foo = ...; // should be disallowed
where init(wp) is something like:
struct S *globalp;
void i
Hello,
On Mon, 18 Jan 2021, Barath Aron via Tinycc-devel wrote:
Yes, this is how you would do it without proper type system (like C
has). I mean, if you want to add runtime stuff here, it is fine for me
(until it is optional :P -- I use tcc on an exotic hosted system, so it
is crucial for me
Hello,
On Mon, 18 Jan 2021, Barath Aron via Tinycc-devel wrote:
Hello,
On Mon, 18 Jan 2021 12:32:29 +0100 Bruno Haible wrote:
((struct data *) p)->x = 9; // Violation of immutability,
crashes ...
If you do not allow such cast, you don't have to do anything at runtime.
Depends
Hello,
On Wed, 6 Jan 2021, Danny Milosavljevic wrote:
Hello,
On Wed, 6 Jan 2021 00:07:07 +0100 (CET)
Michael Matz wrote:
Hmm, how can I get the name of the tcc executable to use for tests from
inside the shell script? Do I just use ./tcc ?
Probably easiest to pass $(TCC) to the shell
:
On 2021-01-04 04:59:28 +0100, Michael Matz wrote:
Hello,
On Mon, 4 Jan 2021, Vincent Lefevre wrote:
-
#include
#include
#include
int main(int argc, char **argv)
{
double d = strtod("-nan", NULL);
d = -d;
printf("%g, signbi
Hello,
On Tue, 5 Jan 2021, Danny Milosavljevic wrote:
Hi,
On Mon, 4 Jan 2021 05:05:40 +0100 (CET)
Michael Matz wrote:
Yeah, put it into tests/ I'd say.
Ok, I've added it as tests/arm-asm-testsuite.sh .
The x86 assembler also has a little
testfile in there that isn't used by default
Hello,
On Tue, 5 Jan 2021, Danny Milosavljevic wrote:
On Tue, 5 Jan 2021 18:12:35 +
Ramsay Jones wrote:
I just pushed a fix-up to the 'mob' branch to recover three
commits which had been 'overwritten' somehow. (Danny, did
you not see an error message when you tried to push?).
Thank
Hello,
On Tue, 5 Jan 2021, Danny Milosavljevic wrote:
Some tests which cannot be automatically generated:
1.
__asm__(".a:\n\t"
"mov r0, #1\n\t"
"bne .a");
2.
__asm__("mov r0, #1\n\t"
"bne L0\n\t"
"L0:\n\t");
3.
__asm__("mov r1, #2\n\t"
".L0:\n\t"
Hello,
On Mon, 4 Jan 2021, Christian Jullien wrote:
Also on OpenBSD x64 with clang 10
Bah. I could fix this generically with using signbit(3) to check
for the required sign flip, but I'm not sure how widespread it's
availability or correctnes is on other platforms. So Hermans disabling
Hello,
On Sun, 3 Jan 2021, Danny Milosavljevic wrote:
Updated test script for all of this (should I also commit this? Where?):
Yeah, put it into tests/ I'd say. The x86 assembler also has a little
testfile in there that isn't used by default (as it shows a few
differences between GNU as
Hello,
On Mon, 4 Jan 2021, Vincent Lefevre wrote:
-
#include
#include
#include
int main(int argc, char **argv)
{
double d = strtod("-nan", NULL);
d = -d;
printf("%g, signbit(d) = %d\n", d, signbit(d));
return 0;
}
Hello,
On Fri, 1 Jan 2021, Joshua Scholar wrote:
I noticed that in the win32 directory there are 46 include files in the main
include directory, 9 in include/sys, there's a secure api directory with 12
files, an a libtcc directory with an include file and a def file.. but the
include directory
Hello,
On Fri, 1 Jan 2021, Christian Jullien wrote:
First, happy new year all.
To you as well.
Porting tcc on *BSD systems raised issues/questions with stddef.h from tcc
distrib.
First, it contains a mix of definitions coming from both stddef.h and
stdint.h IMHO it should only contain
Hello Danny,
On Sat, 26 Dec 2020, Danny Milosavljevic wrote:
This patchset adds an ARM inline assembler.
Wonderful! I like the content and the form of presentation :)
Cool stuff.
Ciao,
Michael.
___
Tinycc-devel mailing list
Hello,
On Sat, 26 Dec 2020, Michael Matz wrote:
c) no top-posting [1], no full-quoting if answering to only some parts,
And obviously I could use an email client that asked me that, if I had
used something like "[1]" to reference a foot note, and then not
actually put in a
Hello,
On Fri, 25 Dec 2020, Vaidas BoQsc wrote:
What is the proper way to quote and reply in a Mailing List? Thanks.
I just noticed that instead of replying, I created a new thread.
Thank you for asking. Generally the usual netiquette rules should be
obeyed, but we don't need to be too
Hello,
On Fri, 25 Dec 2020, Sudipto Mallick wrote:
When I compiled a recent version of tinycc from mob, I looked at the
source of the manpage. I don't like it.
In which sense? tcc.1 is a generated file, it's not supposed to be
edited. The source is tcc-doc.texi, i.e. texinfo, via texi2pod
Hello,
On Sun, 20 Dec 2020, Joshua Scholar wrote:
4) If I did something weird like have a call out from generated code to
my
code, and my code returned on the same stack but in the context of a
different thread than it entered from, would that break anything?
No. Or, perhaps better said,
Hello,
On Thu, 24 Dec 2020, Herman ten Brugge via Tinycc-devel wrote:
The recent commit 'ELF: include SHT_NOTE sections everywhere' does not work
for me on x86_64.
The problem is in /usr/lib64/crt1.o
If I do: readelf -a -W /usr/lib64/crt1.o | grep .gnu.build.attributes.hot
I get:
[64]
.
C.
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of Michael Matz
Sent: Sunday, December 20, 2020 23:41
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Anyone else working with the RISC-V port?
Hello,
On Sat, 19 Dec 2020
Hello,
In addition to the answers already given by Kyryl:
On Sun, 20 Dec 2020, Joshua Scholar wrote:
Now questions about generated code. The jit I'm hoping to make is for a
language that's embarrassingly parallel, so I need to know how the generated
code works with threads and stacks and
Hello,
On Sat, 19 Dec 2020, Charles Lohr wrote:
I am interested in doing a project using TinyCC, a web-based IDE for the
ESP32-C3, a wifi-enabled microcontroller.
https://github.com/cnlohr/espwebc3/blob/main/README.md
I spent a while trying to decipher riscv-gen, and it's actually not that
Hello,
On Sun, 13 Dec 2020, Anton Shepelev wrote:
Vincent Lefevre:
No issue with tcc 0.9.27+git20200814.62c30a4a-1 provided
by Debian.
The bug on my side is reproduced with this version just five
days old:
Hello,
On Thu, 3 Dec 2020, Jonathan Levi wrote:
I am using LibTCC to compile runtime defined functions for a rendering layer
of a project of mine. I compile many of these functions in parallel.
LibTCC is crashing with exit code -11, at what appears to be when execution
is passed to LibTCC on
Hello again,
On Sun, 29 Nov 2020, Michael Matz wrote:
The only other fast C map I know
of is khash (https://attractivechaos.github.io/klib), however not memory
efficient, and the codebase is somewhat bigger.
I guess there as many map implementations as there are C developers :-)
Though
compiler tech experience way back from creating an external syntax checker
for www.autoitscript.com, using flex and yacc.
(http://www.google.com/search?q=au3check)
Cheers,
Tyge
On Sat, 28 Nov 2020 at 00:32, Michael Matz wrote:
Hello,
On Fri, 27 Nov 2020, Tyge Løvset wrote
Hello,
On Fri, 27 Nov 2020, Tyge Løvset wrote:
Is this a known bug, or regression?
Known bug.
I tried to follow the code in parse_btype() in tccgen.c for the missing
struct member symbol lookup check, but didn't succeed so far:
} else {
c = 0;
flexible = 0;
of it)
with tcc, then you would have a capable 'ar' program available.
Ciao,
Michael.
cheers
James
James Mills / prologic
E: prolo...@shortcircuit.net.auw: prologic.shortcircuit.net.au
Blog: Read my Blog
Twtxt: Follow me on twtxt.net
On Thu, Nov 19, 2020 at 5:28 AM Michael Matz wrote
Hello,
On Tue, 17 Nov 2020, James Mills wrote:
Hi guys,
Tried to build sudo with tcc and it fails with:
libtool: link: (cd .libs/sudoers.lax/libparsesudoers.a && ar
x"/usr/ports/sudo/build/src/sudo-1.9.3p1/plugins/sudoers/./.libs/libparsesud
oers.a")
usage: tcc -ar [rcsv] lib file...
create
Hello,
On Mon, 9 Nov 2020, Somchai Smythe wrote:
I guess it's documented somewhere, and I tried to find out that way,
but failed. I looked in the tcc git root directory README file, the
man page, the TODO, the wikipedia page
https://en.wikipedia.org/wiki/Tiny_C_Compiler,
Hello,
On Thu, 5 Nov 2020, Somchai Smythe wrote:
With gcc and clang, I specify the AMD64 large code model with
-mcmodel=large
but that doesn't seem to work for tcc. What is the right way to do that on tcc?
tcc only supports the normal ("small") code model, so there's no way to
specify a
Hello,
I just pushed a change to reinstate proper handling of the alias attribute
(352e1d0f). It affects targets with different symbol leading underscore
conventions, some of which I can't properly test, namely Windows. Can
someone do this for me please? Thanks in advance.
(The commit
Hello,
On Thu, 16 Jul 2020, Herman ten Brugge via Tinycc-devel wrote:
While testing gmp on the riscv target I discovered a compare bug.
(t-get_d test fails in directory tests/mpq)
The code:
#include
int tst(void) {
long value = 3;
return -value;
}
int main(void) {
printf ("%d\n",
Hello,
On Thu, 16 Jul 2020, Herman ten Brugge via Tinycc-devel wrote:
While testing gmp on the x86_64 target I discovered a fuction pointer bug.
(reuse in directory tests/mpf)
The code:
#include
typedef int (*func) (int);
func allfunc[] = { putchar };
int main(void) {
printf ("%d\n",
Hello,
On Wed, 15 Jul 2020, Vincent Lefevre wrote:
With TCC mob on aarch64, the double to long double conversion
is buggy on subnormal values. This makes a MPFR test fail
(reported by Christian Jullien).
Thanks for the report, it was indeed unhandled in the support routines.
I fixed this in
Hello,
On Wed, 15 Jul 2020, Christian JULLIEN wrote:
I think that float.h should be modified accordingly, is it Ok?
Yes, as the aarch64 backend indeed uses the IEEE float128 for long double.
(what are the risc-v values)
Same as on aarch64.
Ciao,
Michael.
Hello,
On Tue, 14 Jul 2020, UnknownGamer40464 wrote:
I see. I had assumed it was for unix compatibility but I guess not.
Is it supposed to show up in the win32 tcclib.h file then?
tcclib.h is a small convenience header that exists merely to show how a
minimal installation on unix-like
Hello,
On Fri, 10 Jul 2020, Christian Jullien wrote:
Thank you for testing the different configure options on macos. I can
easily fix this but it will fail later. I'm not sure that tcc is
currently able to generate .dylib
It's not, and even if it were I wouldn't want to support the complete
Hello Christian,
(I missed the question earlier, apologies)
On Thu, 9 Jul 2020, Christian Jullien wrote:
If you have a moment, can you please test if my macos fix for dyld also
works on your configuration?
Yes, it works fine here on my emulated macOS.
Ciao,
Michael.
Hello,
On Thu, 9 Jul 2020, arn...@skeeve.com wrote:
I compile gawk with it all the time and gawk passes its test suite.
I use it mainly when I want a quick build to test something.
My big wish for tcc is that it'd produce debug info for use with GDB.
Recent mob has some changes that make
/bin/sh: line 1: 62220 Abort trap: 6 ../tcc -vv
+ ldd ../tcc
/bin/sh: ldd: command not found
+ exit 1
make[2]: *** [hello-exe] Error 1
make[1]: *** [all] Error 2
make: *** [test] Error 2
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.or
Hello,
On Wed, 8 Jul 2020, Christian Jullien wrote:
It is still unclear why it does not work but on macOS, ./configure
–disable-static
Now raises an error:
hello-exe
=== recurse /Users/jullien/tinycc/tests/.. ===
dyld: Library not loaded: libtcc.dylib
Hello,
On Mon, 6 Jul 2020, Herman ten Brugge wrote:
In the old code you can also make it fail:
tst.s:
-
.data
.globl foo
.long 0
foo
.byte 0
-
If you compile it in the old compiler with:
tcc -include tst.s -c
1 - 100 of 514 matches
Mail list logo
