[LLVMdev] build errors while cross compiling llvm-gcc for ARM

[Sanjeev C]

I'm getting following errors while cross compiling llvm for ARM. Please help
since it is urgent and critical

My gcc version is 4.2.0, 32bit Linux and target is ARM

Configure options are:

./configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu
--target=armv7fl-montavista-linux-gnueabi --enable-cross
--with-sysroot=/home//arm_v7_vfp_le/target/
--with-build-sysroot=/home//arm_v7_vfp_le/target/ --enable-shared
--enable-languages=c,c++ --with-as=/home//arm_v7_vfp_le/bin/arm_v7_vfp_le-as
--with-ld=/home//arm_v7_vfp_le/bin/arm_v7_vfp_le-ld
--enable-checking=release --disable-multilib
--enable-llvm=/home//Desktop/Sanjeev/LLVM/llvm-2.7 --enable-clocale=gnu
--with-cpu=cortex-a8 --with-interwork --with-arch=armv7-a --with-mode=arm
--with-tune=cortex-a8 --with-fpu=vfp3 --disable-bootstrap

I get following errors:

/home/llvm-gcc-4.2-2.7.source/host-i686-pc-linux-gnu/gcc/xgcc
-B/home/llvm-gcc-4.2-2.7.source/host-i686-pc-linux-gnu/gcc/
-B/usr/local/armv7fl-montavista-linux-gnueabi/bin/
-B/usr/local/armv7fl-montavista-linux-gnueabi/lib/ -isystem
/usr/local/armv7fl-montavista-linux-gnueabi/include -isystem
/usr/local/armv7fl-montavista-linux-gnueabi/sys-include -DHAVE_CONFIG_H -I.
-I../.././libmudflap -I. -Wall -ffunction-sections -fdata-sections -O2 -g
-O2 --sysroot=/home//arm_v7_vfp_le/target/ -MT mf-runtime.lo -MD -MP -MF
.deps/mf-runtime.Tpo -c ../.././libmudflap/mf-runtime.c -o mf-runtime.o
>/dev/null 2>&1
make[4]: *** [mf-runtime.lo] Error 1
make[4]: Leaving directory
`/home//llvm-gcc-4.2-2.7.source/armv7fl-montavista-linux-gnueabi/libmudflap'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/home//llvm-gcc-4.2-2.7.source/armv7fl-montavista-linux-gnueabi/libmudflap'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/home//llvm-gcc-4.2-2.7.source/armv7fl-montavista-linux-gnueabi/libmudflap'
make[1]: *** [all-target-libmudflap] Error 2
make[1]: Leaving directory `/home//llvm-gcc-4.2-2.7.source'
make: *** [all] Error 2

Thanks a lot
Sanjeev
--
View this message in context: http://old.nabble.com/build-errors-while-cross-compiling-llvm-gcc-for-ARM-tp28778845p28778845.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.

_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Dimitry Andric]

On 2010-06-04 13:41, Sanjeev C wrote:
> I get following errors:
>
> /home/llvm-gcc-4.2-2.7.source/host-i686-pc-linux-gnu/gcc/xgcc
> -B/home/llvm-gcc-4.2-2.7.source/host-i686-pc-linux-gnu/gcc/
> -B/usr/local/armv7fl-montavista-linux-gnueabi/bin/
> -B/usr/local/armv7fl-montavista-linux-gnueabi/lib/ -isystem
> /usr/local/armv7fl-montavista-linux-gnueabi/include -isystem
> /usr/local/armv7fl-montavista-linux-gnueabi/sys-include -DHAVE_CONFIG_H -I.
> -I../.././libmudflap -I. -Wall -ffunction-sections -fdata-sections -O2 -g
> -O2 --sysroot=/home//arm_v7_vfp_le/target/ -MT mf-runtime.lo -MD -MP -MF
> .deps/mf-runtime.Tpo -c ../.././libmudflap/mf-runtime.c -o mf-runtime.o
>> /dev/null 2>&1
> make[4]: *** [mf-runtime.lo] Error 1

Unfortunately, the only informative part of this compilation error was
hidden by the "> /dev/null 2>&1" redirection. Could you please remove
that redirection, re-run the build, and report the actual error message?

[Sanjeev chugh]

This is  the full description of errors I am getting

/home/llvm-gcc-4.2-2.7.source/host-i686-pc-linux-gnu/gcc/xgcc
-B/home/llvm-gcc-4.2-2.7.source/host-i686-pc-linux-gnu/gcc/
-B/usr/local/armv7fl-montavista-linux-gnueabi/bin/
-B/usr/local/armv7fl-montavista-linux-gnueabi/lib/ -isystem
/usr/local/armv7fl-montavista-linux-gnueabi/include -isystem
/usr/local/armv7fl-montavista-linux-gnueabi/sys-include -DHAVE_CONFIG_H -I.
-I../.././libmudflap -I. -Wall -ffunction-sections -fdata-sections -O2 -g
-O2 --sysroot=/home//arm_v7_vfp_le/target/ -MT mf-runtime.lo -MD -MP -MF
.deps/mf-runtime.Tpo -c ../.././libmudflap/mf-runtime.c -o mf-runtime.o

/tmp/cczBL31y.s: Assembler messages:
/tmp/cczBL31y.s:409: rdhi, rdlo and rm must all be different
/tmp/cczBL31y.s:2742: Error: offset too big
/tmp/cczBL31y.s:2743: Error: offset too big
/tmp/cczBL31y.s:2752: Error: offset too big
/tmp/cczBL31y.s:2753: Error: offset too big
/tmp/cczBL31y.s:2762: Error: offset too big
/tmp/cczBL31y.s:2763: Error: offset too big
/tmp/cczBL31y.s:2772: Error: offset too big
/tmp/cczBL31y.s:2773: Error: offset too big
/tmp/cczBL31y.s:2778: Error: offset too big
/tmp/cczBL31y.s:2779: Error: offset too big
/tmp/cczBL31y.s:2788: Error: offset too big
/tmp/cczBL31y.s:2789: Error: offset too big
/tmp/cczBL31y.s:2801: Error: offset too big
/tmp/cczBL31y.s:2802: Error: offset too big
/tmp/cczBL31y.s:3826: Error: offset too big
/tmp/cczBL31y.s:3827: Error: offset too big
/tmp/cczBL31y.s:3840: Error: offset too big
/tmp/cczBL31y.s:3841: Error: offset too big
/tmp/cczBL31y.s:5125: Error: offset too big
/tmp/cczBL31y.s:5126: Error: offset too big
/tmp/cczBL31y.s:5130: Error: offset too big
/tmp/cczBL31y.s:5131: Error: offset too big

[Anton Korobeynikov]

Hello

> /tmp/cczBL31y.s:409: rdhi, rdlo and rm must all be different

This is binutils bug fixed ~2 years ago:
http://sourceware.org/ml/binutils/2007-11/msg00046.html

Make sure you're using the latest binutils for ARM (from binutils CVS)

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

[Sanjeev chugh]

Hello,

Thanks for the reply. We have an product whose one part has lot of algorithms doing some graphics work. Our intention was to figure out if there can be any performance gain if we use llvm instead of native ARM. This is for ARM target. Earlier, I have built this component using llvm and tested  it on x86. Performance was 4x as compared to native gcc. Then I built llvm for ARM and tested this component on ARM with llvm compiler and performance of llvm+arm against native ARM was almost equal or less :( However, I have run a simple sorting algorithms who run for 100K times and sort 10K elements on llvm+arm and this time it's performance was 3x better than native ARM. Can you guys please suggest what could be there in this graphics component which is not allowing the performance to improve for ARM+llvm.

cross-compiler has been built with these flags

Using built-in specs.
Target: armv7fl-montavista-linux-gnueabi
Configured with: ./configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=armv7fl-montavista-linux-gnueabi --enable-cross --with-sysroot=/home/arm_v7_vfp_le/target/ --with-build-sysroot=/home/arm_v7_vfp_le/target/ --enable-shared --enable-languages=c,c++ --with-as=/home/arm_v7_vfp_le/bin/arm_v7_vfp_le-as --with-ld=/home/arm_v7_vfp_le/bin/arm_v7_vfp_le-ld --enable-checking=release --disable-multilib --enable-llvm=/home/Desktop/Sanjeev/LLVM/llvm-2.7 --enable-clocale=gnu --with-cpu=cortex-a8 --with-interwork --with-arch=armv7-a --with-mode=arm --with-tune=cortex-a8 --with-fpu=vfp3 --disable-bootstrap --disable-libmudflap --disable-libssp
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build)

 

 

These are the steps how I'm building library on ARM+llvm. generated .a is linked with other targets built with native arm compiler.

g++-cross -flto -O2 -Wall -function-sections -fdata-sections ; for all .cpps
llvm-ld -link-as-library *.bc target.bc // Consolidate all .bcs into one
llc target.bc -o target.s
cross-as target.s -o target.o
ar q target.a target.o

[Sanjeev chugh]

Hi,

 

Any help would b appreicated. This is one of my critical assignment.

 

Thanks

Sanjeev

[Anton Korobeynikov]

> Any help would b appreicated. This is one of my critical assignment.

Well, as was already indicated - make sure that you're using the
latest binutils (2.20 is not fresh enough, btw).

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

[Sanjeev chugh]

No, I'm using the latest binutils.

[Anton Korobeynikov]

> No, I'm using the latest binutils.

What is the version of 'latest' ?

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

[Sanjeev chugh]

Sorry about that.  As you can see, I'm using binutils (ld & as ) from arm toolchain we use to build things for our target.

 

arm_a_b_c_ld -v gives 2.17.50.20070611

 

arm_a_b_c_as -v gives 2.17.50.20070611

 

Do you belive that older binaries of (linker & assembler) can cause performance drop ? Unfortunately I'm not in a position to update the arm compiler for my company :) 

[Anton Korobeynikov]

> Sorry about that.  As you can see, I'm using binutils (ld & as ) from arm
> toolchain we use to build things for our target.
>
> arm_a_b_c_ld -v gives 2.17.50.20070611
>
> arm_a_b_c_as -v gives 2.17.50.20070611

This is definitely not the latest binutils you've stated before. As
you might see - these are at least 3 years old and are known to be
heavily buggy on ARM.

> Do you belive that older binaries of (linker & assembler) can cause performance drop ?

No. They are just buggy (at least assembler).

> Unfortunately I'm not in a position to update the arm compiler for my company :)

Well, sorry, then you're not lucky then. You should expect invalid
code / spurious error messages produced in many places (and you
already saw this!)

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

_______________________________________________

[Sanjeev chugh]

Thanks, last doubt :)

 

But I wanted to say is using these binutils I have built a llvm compiler for our ARM target.

 

Now our libraries which are either compiled with native ARM or with this llvm compiler gives same performance numbers. However this only llvm compiler if compared with x86 compiler gives huge performance gain.

 

Any idea why this might be happening ?

[Anton Korobeynikov]

> But I wanted to say is using these binutils I have built a llvm compiler for
> our ARM target.

That's correct. Mostly because gcc is using pre-UAL ARM assembler syntax
and LLVM switched fully to UAL one. Also, UAL is needed for correct Thumb-2
support, etc. So, in short: gcc is generating some subset of ARM assembler
and thus gas is bug-free. LLVM generates somehow different subset and this
uncovered many bugs inside gas :)

> Now our libraries which are either compiled with native ARM or with this
> llvm compiler gives same performance numbers. However this only llvm
> compiler if compared with x86 compiler gives huge performance gain.

You mean that llvm-generated code is faster on x86, but not on ARM compared
to the vendor compiler / gcc, right?

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

[Sanjeev chugh]

exactly

[Anton Korobeynikov]

> exactly
Well, in general, there is no connection between the performance on
x86 and on ARM.
You can try to profile your code and find what causes the speedup on
x86 and figure out the slowdowns on ARM.

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

[Félix Cloutier]

Hey guys,

Is there a way to force the LLVM JIT compiler to omit the frame pointer in its generated i386/amd64 code? I've got a complex situation in which the stack can potentially be moved around so I'd prefer that the base pointer doesn't get pushed there.

Félix

[Howell, Nathan]

Take look at TargetOptions.h - http://llvm.org/doxygen/TargetOptions_8h_source.html

I thought FPO is enabled by default (I explicitly disable it), but try setting:

llvm::NoFramePointerElim = false;

[Sanjeev chugh]

Hello,

Since, I cudn't get performance gain using llvm compiler, I've tried to use gold linker instead of going through these following steps.

a) 'llvm-gcc -c -flo -O2' to generate the .bc files.
b) 'llvm-ld' to combine them into a single .bc. No, not a .so nor a .a.
c) 'llc' to turn your combined .bc into a .s
d) 'as' to turn your .s into a .o

I followed instructions from web page. http://llvm.org/docs/GoldPlugin.html

I configured linker with these paramters.
../src/configure --host=i686-pc-linux-gpu --build=i686-pc-linux-gpu --target=armv7fl-montavista-linux-gnueabi --enable-gold --enable-plugins --enable-lto --with-cpu=cortex-a8 --with-interwork --with-arch=armv7-a --with-mode=arm --with-tune=cortex-a8 --with-fpu=vfp3

Did a make then.

But the code generated with ld-new is intel binary and not a ARM binary :(

I did
arm_v7_vfp-le a.c
ld-new libs a.o -o binary
file ./binary
./binary: ELF 32-bit LSB executable, intel 80386 version 1(SYSV) dynamically linked (uses shared libs), for GNU/Linux 2.6.9 not stripped

Any idea Why is it so ? Hoping for a quick reply

-Sanjeev

[Anton Korobeynikov]

Hello

> a) 'llvm-gcc -c -flo -O2' to generate the .bc files.

How llvm-gcc was configured & compiled?

With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

[Sanjeev chugh]

my g++-cross was configured with following parameters:

./configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=armv7fl-montavista-linux-gnueabi --enable-cross --with-sysroot=/home/arm_v7_vfp_le/target/ --with-build-sysroot=/home/arm_v7_vfp_le/target/ --enable-shared --enable-languages=c,c++ --with-as=/home/arm_v7_vfp_le/bin/arm_v7_vfp_le-as --with-ld=/home/arm_v7_vfp_le/bin/arm_v7_vfp_le-ld --enable-checking=release --disable-multilib --enable-llvm=/home/Desktop/Sanjeev/LLVM/llvm-2.7 --enable-clocale=gnu --with-cpu=cortex-a8 --with-interwork --with-arch=armv7-a --with-mode=arm --with-tune=cortex-a8 --with-fpu=vfp3 --disable-bootstrap --disable-libmudflap --disable-libssp

But any file e.g. a.c compiled with g++-cross if I try to link using ld-new, I get error

ld-new libs a.o -o binary

a.o : incompatible object file

ld-new works only with those objects which are compiled using native gcc but doesn't work for cross-compiler gcc/arm.

[Anton Korobeynikov]

> ld-new works only with those objects which are compiled using native gcc but
> doesn't work for cross-compiler gcc/arm.

Ok, please show:

ld --version
and last few lines of the ld --help output

--

With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

[Anton Korobeynikov]

> ld-new works only with those objects which are compiled using native gcc but
> doesn't work for cross-compiler gcc/arm.

And yes, please carefully read, understand and follow the "Usage"
section of http://llvm.org/docs/GoldPlugin.html

--

With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

[Sanjeev chugh]

Did you mean ld-new ?

ld-new -v
GNU gold (GNU Binutils 2.20.51.20100707) 1.9

ld-new --help
./ld-new: supported targets: elf32-i386 elf32-i386-freebsd elf64-x86-64 elf64-x86-64-freebsd elf64-sparc elf32-sparc elf64-powerpcle elf64-powerpc elf32-powerpcle elf32-powerpc elf32-bigarm elf32-littlearm

[Sanjeev chugh]

Yes, I'm following this page only and did whatever is mentioned there.

[Anton Korobeynikov]

> Yes, I'm following this page only and did whatever is mentioned there.

It doesn't seem so. E.g. it contains the following line:
"The linker takes a -plugin option that points to the path of the
plugin .so file."
and
"Replace that with ld-new -plugin /path/to/libLLVMgold.so to test it out."

At least you are not telling ld-new to use any plugin. Thus ld-new
does not know how to deal with LLVM IR inside .o and you obtain:

>ld-new libs a.o -o binary
>a.o : incompatible object file

--

With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

[Sanjeev chugh]

Sorry for not explaining well.

After compiling with g++-cross
g++-cross -c a.c

I do link using this command
/gold_binutils/build/gold/ld-new -plugin ~/Desktop/Sanjeev/LLVM/llvm-2.7/Release/lib/libLLVMgold.so --eh-frame-hdr -melf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o
/usr/local/lib/gcc/i686-pc-linux-gnu/4.2.0/crtbegin.o -L/usr/local/lib/gcc/i686-pc-linux-gnu/4.2.0  -L/usr/local/lib -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc -lpthread -lrt --as-needed -lgcc_s --no-as-needed /usr/local/lib/gcc/i686-pc-linux-gnu/4.2.0/crtend.o
/usr/lib/crtn.o a.o -o sanjeevtest

[Anton Korobeynikov]

> ~/Desktop/Sanjeev/LLVM/llvm-2.7/Release/lib/libLLVMgold.so --eh-frame-hdr
> -melf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o

Ok, this way you're generating code for x86

> /usr/lib/crti.o
> /usr/local/lib/gcc/i686-pc-linux-gnu/4.2.0/crtbegin.o
> -L/usr/local/lib/gcc/i686-pc-linux-gnu/4.2.0  -L/usr/local/lib -lgcc
> --as-needed -lgcc_s --no-as-needed -lc -lgcc -lpthread -lrt --as-needed
> -lgcc_s --no-as-needed /usr/local/lib/gcc/i686-pc-linux-gnu/4.2.0/crtend.o
> /usr/lib/crtn.o a.o -o sanjeevtest

And you're using x86 libs. Surely you won't obtain ARM binary.

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

_______________________________________________

[Sanjeev chugh]

Hello,

I'm using gold linker now to see if there can be any performance gain. Also using latest gcc version (4.4.4) and latest binutils.

But when I'm compiling llvm-gcc, I'm getting this error.

/home/jal/llvm-gcc-4.2-2.7.source/host-i686-pc-linux-gnu/gcc/xgcc -B/home/jal/llvm-gcc-4.2-2.7.source/host-i686-pc-linux-gnu/gcc/ -B/usr/local/arm-v7a8-linux-gnueabi/bin/ -B/usr/local/arm-v7a8-linux-gnueabi/lib/ -isystem /usr/local/arm-v7a8-linux-gnueabi/include -isystem /usr/local/arm-v7a8-linux-gnueabi/sys-include  -O2  -O2 -g -O2 --sysroot=/home/jal/VDLinux-armv7a8-toolchain/arm-v7a8-linux-gnueabi/libc -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include  -I../.././gcc/../libdecnumber -I../libdecnumber -I/home/jal/llvm-2.7/include -DL_mulsc3 -fvisibility=hidden -DHIDE_EXPORTS -c ../.././gcc/libgcc2.c -o libgcc/./_mulsc3.o
/tmp/ccmyj0Hi.s: Assembler messages:
/tmp/ccmyj0Hi.s:60: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:62: Error: bad instruction `vmrsvs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:71: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:76: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:83: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:87: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:105: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:109: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:112: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:118: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:125: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:130: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:136: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:146: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:158: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:161: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:167: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:171: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:186: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:190: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:193: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:199: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:206: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:211: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:217: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:222: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:236: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:240: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:244: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:248: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:252: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:256: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:260: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:264: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:269: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:274: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:280: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:285: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:291: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:296: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:302: Error: bad instruction `vmrs apsr_nzcv,fpscr'
/tmp/ccmyj0Hi.s:308: Error: bad instruction `vmrs apsr_nzcv,fpscr'
make[3]: *** [libgcc/./_mulsc3.o] Error 1
make[3]: Leaving directory `/home/jal/llvm-gcc-4.2-2.7.source/host-i686-pc-linux-gnu/gcc'
make[2]: *** [stmp-multilib] Error 2
make[2]: Leaving directory `/home/jal/llvm-gcc-4.2-2.7.source/host-i686-pc-linux-gnu/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/home/jal/llvm-gcc-4.2-2.7.source'
make: *** [all] Error 2

Toolkit version is
Configured with: /scratch/julian_vda8/2010q1-release-linux-lite/src/gcc-4.4-2010q1/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-v7a8-linux-gnueabi --enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --enable-extra-sgxxlite-multilibs --with-gnu-as --with-gnu-ld --with-specs='%{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables} %{O2:%{!fno-remove-local-statics: -fremove-local-statics}} %{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics: -fremove-local-statics}}}' --enable-languages=c,c++ --enable-shared --disable-lto --enable-symvers=gnu --enable-__cxa_atexit --with-pkgversion='VDLinux ga-release 2010-06-30' --with-bugurl=http://linux.sec.samsung.net/VDLinux/ --disable-nls --prefix=/opt/codesourcery --with-sysroot=/opt/codesourcery/arm-v7a8-linux-gnueabi/libc --with-build-sysroot=/scratch/julian_vda8/2010q1-release-linux-lite/install/arm-v7a8-linux-gnueabi/libc --with-gmp=/scratch/julian_vda8/2010q1-release-linux-lite/obj/host-libs-2010q1-202-arm-v7a8-linux-gnueabi-i686-pc-linux-gnu/usr --with-mpfr=/scratch/julian_vda8/2010q1-release-linux-lite/obj/host-libs-2010q1-202-arm-v7a8-linux-gnueabi-i686-pc-linux-gnu/usr --with-ppl=/scratch/julian_vda8/2010q1-release-linux-lite/obj/host-libs-2010q1-202-arm-v7a8-linux-gnueabi-i686-pc-linux-gnu/usr --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-cloog=/scratch/julian_vda8/2010q1-release-linux-lite/obj/host-libs-2010q1-202-arm-v7a8-linux-gnueabi-i686-pc-linux-gnu/usr --disable-libgomp --enable-poison-system-directories --with-build-time-tools=/scratch/julian_vda8/2010q1-release-linux-lite/install/arm-v7a8-linux-gnueabi/bin --with-build-time-tools=/scratch/julian_vda8/2010q1-release-linux-lite/install/arm-v7a8-linux-gnueabi/bin --with-interwork --with-cpu=cortex-a8 --with-arch=armv7-a --with-mode=arm --with-tune=cortex-a8 --with-fpu=vfp3 --with-float=softfp
Thread model: posix
gcc version 4.4.1 (VDLinux ga-release 2010-06-30)

And llvm-gcc configured with
/configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=arm-v7a8-linux-gnueabi --enable-cross --with-sysroot=/home/jal/VDLinux-armv7a8-toolchain/arm-v7a8-linux-gnueabi/libc --with-build-sysroot=/home/jal/VDLinux-armv7a8-toolchain/arm-v7a8-linux-gnueabi/libc --enable-languages=c,c++ --with-as=/home/jal/VDLinux-armv7a8-toolchain/bin/arm-v7a8-linux-gnueabi-as --with-ld=/home/jal/VDLinux-armv7a8-toolchain/bin/arm-v7a8-linux-gnueabi-ld --enable-checking=release --disable-multilib --enable-llvm=/home/jal/llvm-2.7 --enable-clocale=gnu --with-cpu=cortex-a8 --with-interwork --with-arch=armv7-a --with-mode=arm --with-tune=cortex-a8 --with-fpu=vfp3 --with-float=softfp --disable-bootstrap --disable-libmudflap --disable-libssp

Thanks & Regards
Sanjeev

[Anton Korobeynikov]

Hello

> I'm using gold linker now to see if there can be any performance gain. Also
> using latest gcc version (4.4.4) and latest binutils.

Sorry, I misinformed you last time. The necessary fixes were *not*
pushed into the binutils 2.20.1 release. You should grab so-called
development snapshot (aka 2.20.51). Make sure it's recent (say, after
January 2010).

PS: Note that gold is currently not pretty much usable for ARM code.

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

[Sanjeev chugh]

Does you mean that these assembler errors are due to this particular version of binutils(2.20.1) and may get resolved if used 2.20.51.

[Anton Korobeynikov]

> Does you mean that these assembler errors are due to this particular version
> of binutils(2.20.1) and may get resolved if used 2.20.51.

Yes, they are.

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University