Hello,
> On 29 Dec 2019, at 23:31, Daniel Glöckner wrote:
>
> Adding recursion depth limitation into all cycles of this graph is a
> lot of work.
It would also be counter-productive. Currently it takes a single ulimit command
to compile a larger-than-usual program, but if tcc enforced its own
Hello,
> On 22 Jul 2019, at 22:32, Zsolt Kántor via Tinycc-devel
> wrote:
>
> Hello,
> I read the online documentation, but found no option to warn for declared but
> unused variables. By default TCC don't warns.
> I'm missing something, or TCC has no such capability?
TCC is a minimalistic an
Hello,
On 21 Jul 2019, at 21:37, Ivan Medoedov
mailto:ivan.medoe...@gmail.com>> wrote:
No, it's a compilation error (error: field expected), and I can't reproduce it
in a small program. The original file has hundreds of thousands of loc.
Large inputs that cause unwarranted compilation errors a
Hello,
> On 24 Jun 2019, at 12:05, grischka wrote:
>
> Pascal Cuoq wrote:
>
> int t[][3]; [ error: unknown type size ]
>
> Actually that is not wrong. It's the same as
>
> extern int t[][3];
Ah yes. Anyway my patch did not change the behavior for
> On 24 Jun 2019, at 05:01, Michael Matz wrote:
>
> diff --git a/tccgen.c b/tccgen.c
> index c65cf76..84e0953 100644
> --- a/tccgen.c
> +++ b/tccgen.c
> @@ -4507,6 +4507,8 @@ static int post_type(CType *type, AttributeDef *ad, int
> storage, int td)
> post_type(type, ad, storage, 0);
>
Hello,
> On 23 Jun 2019, at 23:18, Michael Matz wrote:
>
> The patch definitely goes into the right direction, though it seem more
> verbose than necessary. I'd just test for functions or incomplete types (via
> type_size), and then you have the opportunity to retain the more precise
> error
On 22 Jun 2019, at 21:16, Michael Matz
mailto:matz@frakked.de>> wrote:
struct s {
char a;
enum e b[];
} s;
struct t {
int a[3];
void b[];
} t;
typedef void u;
struct v {
int a[3];
u b[];
} v;
struct w {
int a[3];
struct n b[];
} w;
The thing to realize about all these invali
On 22 Jun 2019, at 22:29, Vincent Lefevre
mailto:vinc...@vinc17.net>> wrote:
On 2019-06-22 20:59:57 +0200, Michael Matz wrote:
Indeed. The thing is that such "mis"-alignment isn't generically undefined
behaviour (and hence shouldn't even be part of -fsanitize=undefined). It's
implementation d
Hello Michael, and thanks for the guidance.
On 22 Jun 2019, at 01:17, Michael Matz
mailto:matz@frakked.de>> wrote:
Yes, there are generally two contexts, and in one of them (e.g. decls with
initializers) incomplete types are temporarily valid. So you'd either need two
modes of type_size (
On 21 Jun 2019, at 16:54, ian
mailto:sibian0...@gmail.com>> wrote:
Anyway, I don't think it's desirable that kinds of pointers are checked.
Should I emphasize that I am not offering to implement a warning in TCC? If you
think that GCC should not emit the warning shown by Christian, you can eit
On 21 Jun 2019, at 16:10, ian
mailto:sibian0...@gmail.com>> wrote:
Hello,IMHO, considering that flexibility is what I love in C programming, and
that this checking should be printf job (in that case),
Unfortunately, this is not how printf, or other variadic functions, work. The
way they work
On 21 Jun 2019, at 15:33, Christian Jullien
mailto:eli...@orange.fr>> wrote:
If I read you correctly, you want to protest if type does not strictly match
format directive.
I'm not protesting, I'm just offering a patch (in a series of patches) that
makes the TCC source code free of easily avoi
> On 21 Jun 2019, at 14:56, Christian Jullien wrote:
>
> This is a valuable check but IMHO, it should be controlled by -Wformat (as
> GNU gcc) and set of false by default.
> Otherwise, I suspect tcc users will have a lot a new warnings.
I'm not implementing a new warning in TCC. I am only ensur
Hello,
If no-one objects, I will push in a few days the following patch, which ensures
that the types of arguments to printing functions correspond exactly to their
formatters (%x expects an unsigned int, %s expects a pointer to character type,
etc.).
Pascal
formatting.patch
Description: for
Hello,
the function type_size can fail and return -1 for an incomplete enum:
https://repo.or.cz/tinycc.git/blob/944fe7036c53613889deb66cb9d03da2407d6c85:/tccgen.c#l2800
In this case it leaves *a untouched.
When this happens when called from the function classify_x86_64_arg, it leads
to using t
Hello,
> On 16 Jun 2019, at 21:49, Michael Matz wrote:
>
> On Wed, 12 Jun 2019, Petr Skočík wrote:
>
>> I think it looks a bit better without the extra variable:
>>
>> char _onstack[nb_args?nb_args:1], *onstack = _onstack;
>
> Agreed, if you put spaces around the ? and : ;)
So I pushed
> On 18 Jun 2019, at 09:54, Mike wrote:
>
> I keep having fun.
> In attach compile report under -fsanitize=undefined in gcc or clang.
I should warn you that your recent e-mails are about identical to a previous
message from January:
https://lists.nongnu.org/archive/html/tinycc-devel/2019-01/m
Hello,
On 12 Jun 2019, at 21:21, Mike
mailto:tankf33...@disroot.org>> wrote:
I've run "make test" under -fsanitize=address and got the same report for
several failed tests:
This appears to be caused by an offset into a dynamically allocated block being
assigned to sym in build_got_entries at
Hello,
Arrays of size zero are not part of standard C, even when they are Variable
Length Arrays (https://port70.net/~nsz/c/c11/n1570.html#6.7.6.2p5 ). GCC
accepts arrays of size 0 as an extension, but since TCC's small size and being
implemented in C in the first place may lead it to be compil
With TCC from git (commit 9382a3a), the two following inputs vla0.i and vla1.i
each cause the message “error: internal compiler error: vstack leak” to be
printed. In addition, the input vla1.i makes TCC crash:
$ cat vla0.i
int X=1;
int main(void) {
int t[][X];
}
$ ./tcc vla0.i
about to pop: 1
Hello,
On the following (invalid) C program, tcc goes into an unbounded recursion, and
crashes when it exhausts the space allowed for the stack. I tried to make a
valid C program with the same property, which would be a more interesting bug
report, but I couldn't find one.
Pascal
$ ca
Hello again,
On 17 Mar 2019, at 13:56, Pascal Cuoq
mailto:c...@trust-in-soft.com>> wrote:
2) I noticed that a variant of the input I initially reported in this thread is
still crashing TCC.
The variant that still crashes TCC as of commit d72b877 is:
void f(char *);
void g(void) {
f
Hello,
Thanks again Matthias, and also to Michael who fixed the other crashes I had
posted. I was going over the “interesting” inputs generated by fuzzing again,
and:
1) I found a bug in the tool I was using TCC as a reference implementation for,
so the bugs in TCC being fixed is really useful
Finally, adding one more bit of instrumentation shows that TCC can crash
because of the uninitialized variable being discussed in this thread.
On 08 Mar 2019, at 20:06, Pascal Cuoq
mailto:c...@trust-in-soft.com>> wrote:
the simplest way to make this problem visible is to instrume
Update: I have found an input that is accepted by GCC, accepted by Clang, and
that makes TCC use the variable n uninitialized in function post_type.
On 08 Mar 2019, at 20:06, Pascal Cuoq
mailto:c...@trust-in-soft.com>> wrote:
the simplest way to make this problem visible is to instrume
Hello,
the simplest way to make this problem visible is to instrument the functions
type_decl and post_type:
diff --git a/tccgen.c b/tccgen.c
index 87ec798..7fa6c72 100644
--- a/tccgen.c
+++ b/tccgen.c
@@ -4374,7 +4374,7 @@ static int post_type(CType *type, AttributeDef *ad, int
storage, int td
Hello,
The input below crashes TCC for me on Ubuntu 16.04 on x86-64.
In order to be certain to observe the problem, it can help to temporarily add a
debug printf call inside the function elfsym:
$ git diff
diff --git a/tccgen.c b/tccgen.c
index 87ec798..cbc6b09 100644
--- a/tccgen.c
+++ b/tccge
Hello,
With both the most current git commit (b082659) and version 0.9.27, on Ubuntu
16.04 on x86-64, when compiling the provided input addrof_addrof.i, TCC stops
abruptly with the message below:
$ cat addrof_addrof.i
void f(void) {
int i;
char *p;
p + &&b[i];
}
$ ./tcc addrof_addrof.i
tc
Hello,
> On 06 Mar 2019, at 18:56, uso ewin wrote:
>
> I've just push a patch that should fix this issue,
Many thanks for looking into this!
> I hope I didn't add a now bug
All the bugs I have so far are in syntactically incorrect inputs, so it would
be a valid choice not to risk introducing
In both version 0.9.25 and today's git version (commit
d27ea5155f47cb0c29699ef959b52b087dfff41a), tcc crashes while compiling the
following one-line invalid program:
enum myenum { L = -1 } L;
tcc crashes after emitting an error message:
pascal@TrustInSoft-Box-VII:~/tcc-2019-02-07$ bin/tcc -c e
Hello,
as a side-product of working on something else, I found that TCC 0.9.27 (x86_64
Linux) crashes for me on the following program:
pascal@TrustInSoft-Box-VII:~/tcc-bin$ cat crash.i
void f(char*);
void g(void) {
f((char[]){,});
}
pascal@TrustInSoft-Box-VII:~/tcc-bin$ bin/tcc crash.i
crash.
31 matches
Mail list logo
