grischka writes:
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Kirill Smelkov wrote:
Maybe yes, but that filter-outs and a lot of ifdefs inside tcc sources
looks not so good to me. ...
I agree that it looks horrible. Plus there is still the comment
# these should work too
# TESTS += test1 test2 speedtest btest weaktest
which doesn't make any sense i
On Sat, Nov 24, 2012 at 02:43:34PM +0100, Thomas Preud'homme wrote:
> Le samedi 24 novembre 2012 10:02:54, Kirill Smelkov a écrit :
> >
> > Thanks for the info. The progress on my side is as follows: I've learned
> > arm assembly and setup arm and armhf cross-toolchains (turned out to be
> > very
Le samedi 24 novembre 2012 10:02:54, Kirill Smelkov a écrit :
>
> Thanks for the info. The progress on my side is as follows: I've learned
> arm assembly and setup arm and armhf cross-toolchains (turned out to be
> very easy, thanks to emdebian[1]). Also I can run arm binaries via
> qemu-arm and b
On Thu, Nov 22, 2012 at 11:19:24AM +0100, Thomas Preud'homme wrote:
> On Thu, 22 Nov 2012 13:37:16 +0400, Kirill Smelkov wrote:
> >
> >I don't like that filter-out's. Actually, what I'd like to write here
> >is
> >
> >ifeq ($(CONFIG_TCC_BCHECK),y)
> >TESTS += btest
> >endif
>
> I a
( sorry for posting twice. I thought the first mail was lost on tmpfs
/tmp after neetbook lockup, but it looks like it already made it into
exim queue. Such things happens when you compose mail from the
underground in crush )
___
Tinycc-devel maili
On Thu, 22 Nov 2012 13:37:16 +0400, Kirill Smelkov wrote:
I don't like that filter-out's. Actually, what I'd like to write here
is
ifeq ($(CONFIG_TCC_BCHECK),y)
TESTS += btest
endif
I agree it fits more my mental model.
or even better
TESTS-$(CONFIG_TCC_BCHECK) += btes
On Wed, Nov 21, 2012 at 12:30:04PM +0100, Thomas Preud'homme wrote:
> On Wed, 21 Nov 2012 10:03:58 +0400, Kirill Smelkov wrote:
> >On Tue, Nov 20, 2012 at 03:29:26PM +0100, robo...@celest.fr wrote:
> >>Another regression is due to the unconditional activation of btest
> >>in the list of tests to ru
On Wed, Nov 21, 2012 at 12:30:04PM +0100, Thomas Preud'homme wrote:
> On Wed, 21 Nov 2012 10:03:58 +0400, Kirill Smelkov wrote:
> >On Tue, Nov 20, 2012 at 03:29:26PM +0100, robo...@celest.fr wrote:
> >>Another regression is due to the unconditional activation of btest
> >>in the list of tests to ru
On Wed, 21 Nov 2012 10:03:58 +0400, Kirill Smelkov wrote:
On Tue, Nov 20, 2012 at 03:29:26PM +0100, robo...@celest.fr wrote:
Another regression is due to the unconditional activation of btest
in the list of tests to run. Indeed, there is no bound checking on
arm (and also C67 and il). This test
On Tue, Nov 20, 2012 at 03:29:26PM +0100, robo...@celest.fr wrote:
> Another regression is due to the unconditional activation of btest
> in the list of tests to run. Indeed, there is no bound checking on
> arm (and also C67 and il). This test should thus be run only for
> architecture supporting i
There was a test regression on ARM recently which I managed to pinpoint
to commit b2a02961b4407ca76db5a66ca5ae855cbfba4e8e. All I can tell so
far is that it's related to the addition of the test
builtin_frame_address_test.
Another regression is due to the unconditional activation of btest in
12 matches
Mail list logo
