I think the assumption of it will not fail is incorrect. Because the
function have a return value, and other crt check the return value. The
main program cannot run if was some wrong getting the main args. I think is
a little not serious continue without check the result error getting the
main args
Michael Matz wrote:
On Sat, 15 Oct 2016, David Mertens wrote:
Ah, now I get errors running the preprocessor tests. Here's a
representative
result:
PPTest 14 ...
Yes. The whole commit range around there is a bit shaky. You need some
commits from after that one to get a better working comp
Hi,
On Sat, 15 Oct 2016, David Mertens wrote:
Ah, now I get errors running the preprocessor tests. Here's a representative
result:
PPTest 14 ...
--- 14.expect 2016-10-15 13:07:53.790016538 -0400
+++ 14.output 2016-10-15 22:36:25.971293975 -0400
@@ -1,3 +1,8 @@
+
return Z(Z(1,2),2);
+
r
Ah, now I get errors running the preprocessor tests. Here's a
representative result:
PPTest 14 ...
--- 14.expect2016-10-15 13:07:53.790016538 -0400
+++ 14.output2016-10-15 22:36:25.971293975 -0400
@@ -1,3 +1,8 @@
+
return Z(Z(1,2),2);
+
return Q(1,2);
+
return ((A + A) * (A + A)) + ((B
D'oh! Thanks!
On Sat, Oct 15, 2016 at 6:09 PM, Michael Matz wrote:
> Hello,
>
> On Sat, 15 Oct 2016, David Mertens wrote:
>
> This commit:
>>
>> 0a624782dfc8fee6f0600066b135d3b20e4274f4
>>
>> causes "make test" to fail on my 64-bit Linux (ubuntu 16.04). Any idea of
>> what's going on? Below is t
Hello,
On Sat, 15 Oct 2016, David Mertens wrote:
This commit:
0a624782dfc8fee6f0600066b135d3b20e4274f4
causes "make test" to fail on my 64-bit Linux (ubuntu 16.04). Any idea of
what's going on? Below is the output of "make" followed by "make test".
$ make test
../tcc -B.. -I/include -I -I..
This commit:
0a624782dfc8fee6f0600066b135d3b20e4274f4
causes "make test" to fail on my 64-bit Linux (ubuntu 16.04). Any idea of
what's going on? Below is the output of "make" followed by "make test".
David
$ make
gcc -o tcc.o -c tcc.c -DCONFIG_MULTIARCHDIR="\"x86_64-linux-gnu\""
-DTCC_TARGET_X8
nycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] cleanups
Hi,
On Mon, 10 Oct 2016, grischka wrote:
> In general, often when I see people adding tests I think: "Well you
> just fixed that, what's the point? I'd rather see what's still broken."
The point of course
Hi,
On Mon, 10 Oct 2016, grischka wrote:
> In general, often when I see people adding tests I think: "Well you
> just fixed that, what's the point? I'd rather see what's still broken."
The point of course is to not break things ever again, after somebody got
to the length of fixing something
Michael Matz wrote:
I wonder about only one change:
6d2be31b93 test/pp: cleanup
There you removed tests/pp/15.{c,expect} and changed
tests/pp/14.{c,expect} to be something completely different. I don't
see them added back in later commits so I think that was unintended.
Certainly at least te
Hi grischka,
On Sat, 1 Oct 2016, grischka wrote:
I did push some cleanups to prepare for a release 0.9.27, eventually.
Just if you wonder what's the point of that.
I wonder about only one change:
6d2be31b93 test/pp: cleanup
There you removed tests/pp/15.{c,expect} and changed
tests/pp/14.{
Carlos Montiers wrote:
Why in win32/lib/crt1.c the code for check success of __getmainargs was
removed?
I think is important check the return of that function before call to main.
There is no need to check if we assume that it cannot fail.
Machines are all based on assumptions, not, say, proba
Daniel Glöckner wrote:
On Mon, Oct 03, 2016 at 12:48:00PM +0200, grischka wrote:
Ok, have seen it: crash in "make test".
So it's
long long *p, v;
p = &v;
p[0]++;
that is miscompiled without the save_regs.
To load the upper half of p[0] 4 is added to the register that h
Hi,
On Mon, 3 Oct 2016, grischka wrote:
Ok, have seen it: crash in "make test".
I did something different now. It's not nice but maybe works. It would
just run a second pass in copy_params to reload registers that have been
saved on stack by accident.
http://repo.or.cz/tinycc.git/commitdi
Why in win32/lib/crt1.c the code for check success of __getmainargs was
removed?
I think is important check the return of that function before call to main.
Carlos Montiers A.
2016-10-03 7:48 GMT-03:00 grischka :
> grischka wrote:
>
>> Daniel Glöckner wrote:
>>
>>> Hi,
>>>
>>> On Sat, Oct 01, 20
On Mon, Oct 03, 2016 at 12:48:00PM +0200, grischka wrote:
> Ok, have seen it: crash in "make test".
So it's
long long *p, v;
p = &v;
p[0]++;
that is miscompiled without the save_regs.
To load the upper half of p[0] 4 is added to the register that holds p.
But the register
grischka wrote:
Daniel Glöckner wrote:
Hi,
On Sat, Oct 01, 2016 at 09:03:47PM +0200, grischka wrote:
I did push some cleanups to prepare for a release 0.9.27,
eventually. Just if you wonder what's the point of that.
I'd vote for applying Balazs' patches from August 25 ("Incorrect
function c
Hi,
great news !
While working on a c interactive environment using libtcc
(https://github.com/anael-seghezzi/CToy)
I came across a crash (a call to exit(0) in fact) in come occasions, I noticed
that tcc_compile could call
gen_inline_functions even after detecting compilation errors, you seem to
Daniel Glöckner wrote:
Hi,
On Sat, Oct 01, 2016 at 09:03:47PM +0200, grischka wrote:
I did push some cleanups to prepare for a release 0.9.27,
eventually. Just if you wonder what's the point of that.
I'd vote for applying Balazs' patches from August 25 ("Incorrect
function call code on ARMv6
Jean-Claude Beaudoin wrote:
One fact that gives me serious pause in that area is that the
majority of the commits I contributed in the last few days were
simply reverted thus reintroducing the problems they tried to fix
or introducing some new lesser one when the revert was partial.
A good number
On Sat, Oct 1, 2016 at 3:03 PM, grischka wrote:
> Hey all,
>
> I did push some cleanups to prepare for a release 0.9.27,
> eventually. Just if you wonder what's the point of that.
>
I was indeed wondering if we would see a new release sometime soon
considering that the latest one dates from a f
Hi,
On Sat, Oct 01, 2016 at 09:03:47PM +0200, grischka wrote:
> I did push some cleanups to prepare for a release 0.9.27,
> eventually. Just if you wonder what's the point of that.
I'd vote for applying Balazs' patches from August 25 ("Incorrect
function call code on ARMv6") before the release.
-devel@nongnu.org
Subject: [Tinycc-devel] cleanups
Hey all,
I did push some cleanups to prepare for a release 0.9.27, eventually. Just
if you wonder what's the point of that.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
Hey all,
I did push some cleanups to prepare for a release 0.9.27,
eventually. Just if you wonder what's the point of that.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Le lundi 4 février 2013 20:51:29, grischka a écrit :
> Thomas Preud'homme wrote:
> >> 1) too many warnings "conversion from/to ptr <-> integer of different
> >> size"
> >>
> >> http://repo.or.cz/w/tinycc.git/commitdiff/82bcbd027f100d7601c6139e93e1f6
> >> 9a 9cc46244
> >
> > Why some uplong were r
Le lundi 4 février 2013 18:47:59, grischka a écrit :
>
> Yes, just that it once worked for me before another real case
> obviously "won" over mine.
>
> In any case the
> #ifndef CONFIG_LDDIR
> clause in tcc.h now looks right which it didn't before.
Absolutely.
> Anyhow. Maybe you might w
Thomas Preud'homme wrote:
1) too many warnings "conversion from/to ptr <-> integer of different size"
http://repo.or.cz/w/tinycc.git/commitdiff/82bcbd027f100d7601c6139e93e1f69a
9cc46244
Why some uplong were replaced by uintptr_t?
Well, that is with
LIBTCCAPI int tcc_add_symbol(TCCState
Le lundi 4 février 2013 16:30:53, grischka a écrit :
> Hi, I reinstalled my linux partitions and did run some tests.
>
> My conclusions:
> 1) too many warnings "conversion from/to ptr <-> integer of different size"
>
> http://repo.or.cz/w/tinycc.git/commitdiff/82bcbd027f100d7601c6139e93e1f69a
Thomas Preud'homme wrote:
State on my old ubuntu-64 is that it has an
lib/x86_64-linux-gnu (empty)
and has
/lib64 (link to /lib)
.
Ok, then real case wins over hypothetical case.
Yes, just that it once worked for me before another real case
obviously "won" over mine.
In any c
Le lundi 4 février 2013 17:34:28, grischka a écrit :
> Thomas Preud'homme wrote:
> > If you want to keep the if structure you created, there should be a comma
> > so that each if is in the else clause of the previous one.
>
> Yep, mistake. Fixed.
>
> > Because here multiarch
> > dir is tested on
Thomas Preud'homme wrote:
If you want to keep the if structure you created, there should be a comma so
that each if is in the else clause of the previous one.
Yep, mistake. Fixed.
Because here multiarch
dir is tested only if there is a /lib64. Maybe even better making the
CONFIG_LDDIR sett
Le lundi 4 février 2013 17:08:24, Thomas Preud'homme a écrit :
>
> > 2) CONFIG_LDDIR for x86_64 wasn't set correctly on my (rather old) ubuntu
> > 64.
> > http://repo.or.cz/w/tinycc.git/commitdiff/3186455599043938d765b4cc9b92af5
> > f de7241cd
>
> Oups, that must have been me. However the commit
Hi, I reinstalled my linux partitions and did run some tests.
My conclusions:
1) too many warnings "conversion from/to ptr <-> integer of different size"
http://repo.or.cz/w/tinycc.git/commitdiff/82bcbd027f100d7601c6139e93e1f69a9cc46244
2) CONFIG_LDDIR for x86_64 wasn't set correctly on my
33 matches
Mail list logo
