tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Regression on ARM


From: Kirill Smelkov
Subject: Re: [Tinycc-devel] Regression on ARM
Date: Wed, 21 Nov 2012 10:03:58 +0400
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Nov 20, 2012 at 03:29:26PM +0100, address@hidden 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 it.

Sorry, my fault, that was late at night. Does the following patch fixes
btest issue for you?

---- 8< ----
From: Kirill Smelkov <address@hidden>
Date: Wed, 21 Nov 2012 09:47:23 +0400
Subject: [PATCH] tests: btest should only run on targets supporting bcheck

After 40a54c43 (Repair bounds-checking runtime), and in particular
5d648485 (Now btest pass!) `make test` was broken on ARCH != i386,
because I've changed btest to unconditionally run on all arches.

But bounds-checking itself is only supported on i386 and oops...

My fault, fix it.

Reported-by: Thomas Preud'homme <address@hidden>
---
 tests/Makefile | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tests/Makefile b/tests/Makefile
index af1fdb8..ca581b0 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -11,12 +11,16 @@ TESTS = libtest \
                test2 \
                test3 \
                speedtest \
-               btest \
                weaktest
 
                # test4 # this test does not seem to work on any platform
                # asmtest # this test does not seem to work on any platform
 
+# bounds-checking is supported only on i386
+ifeq ($(ARCH),i386)
+    TESTS += btest
+endif
+
 # these should work too
 # TESTS += test1 test2 speedtest btest weaktest
 
-- 
1.8.0.289.g7a667bc


> 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.

Thanks for the report.

I'm new to arm - will try to setup arm cross-compiler toolchain and see
what is going on there, but that will probably take time. In the
meantime, I'm having problem to build tcc arm cross compiler on i386:

    gcc -o arm-fpa-tcc tcc.c -DONE_SOURCE -DTCC_TARGET_ARM  -Wall -g -O2 
-fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result 
-mpreferred-stack-boundary=2 -march=i386 -falign-functions=0 -m32 -lm -ldl 
    In file included from libtcc.c:50:0,
                     from tcc.c:22:
    arm-gen.c: In function ‘gfunc_call’:
    arm-gen.c:1058:7: warning: implicit declaration of function ‘vfpr’ 
[-Wimplicit-function-declaration]
    In file included from libtcc.c:42:0,
                     from tcc.c:22:
    tccpp.c: In function ‘macro_subst’:
    tccpp.c:2806:12: warning: ‘*((void *)&cval+4)’ is used uninitialized in 
this function [-Wuninitialized]
    /tmp/ccWBLnLc.o: In function `gfunc_call':
    /home/kirr/src/tools/tinycc/arm-gen.c:1058: undefined reference to `vfpr'
    /home/kirr/src/tools/tinycc/arm-gen.c:1058: undefined reference to `vfpr'
    collect2: error: ld returned 1 exit status
    Makefile:194: recipe for target 'arm-fpa-tcc' failed
    make: *** [arm-fpa-tcc] Error 1


could you please fix it, or tell me what is the workaround, so I could
try fixing tcc while working on cross-version of it?


Also, while I'm studying how to setup arm toolchain, what is `objdump -d`
output on arm for gcc and tcc for the next source?

---- 8< ----
void *bfa0()
{
    return __builtin_frame_address(0);
}

void *bfa1()
{
    return __builtin_frame_address(1);
}

void *bfa2()
{
    return __builtin_frame_address(2);
}
---- 8< ----


By the way, what arm variant I should test against - it seems there are
many? Another question: maybe you know, what is the most convenient way
to setup arm cross-toolchain on Debian GNU/Linux on i386?

Thanks,
Kirill



reply via email to

[Prev in Thread] Current Thread [Next in Thread]