arm neon intrinsics cross compile error on windows system

Project Infrastructure LLVM Dev List Archives
1

Dear all.

I built the LLVM 3.0 rc4 with Clang front-end in windows os env. (also with -DLLVM_TARGETS_TO_BUILD=all option)
For arm neon intrinsics testing, I tried to compile some codes, which are included a few neon intrinsics.
Although I got a well done bitcode on ubuntu build pc, it shows some errors when compile the codes on windows.

Could you let me know why occurred errors? is this just a bug at windows system?

the used command is

clang helloneon.c -o helloneon.bc -c -emit-llvm -ccc-host-triple= armv7-none-gnueabi -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=hard -mthumb -I"C:\Program Files\CodeSourcery\Sourcery_CodeBench_for_ARM_EABI\arm-none-eabi\include" -ferror-limit=1000

and the followings are error codes.

Thanks and regards,
Seung-yeon.

In file included from helloneon.c:4:
d:/llvm_projects/llvm-3.0rc4/bin/…/lib/clang/3.0/include\arm_neon.h:41:24: error: invalid vector element type ‘int32_t’ (aka ‘long’)
typedef attribute((neon_vector_type(2))) int32_t int32x2_t;
^
d:/llvm_projects/llvm-3.0rc4/bin/…/lib/clang/3.0/include\arm_neon.h:42:24: error: invalid vector element type ‘int32_t’ (aka ‘long’)
typedef attribute((neon_vector_type(4))) int32_t int32x4_t;
^
d:/llvm_projects/llvm-3.0rc4/bin/…/lib/clang/3.0/include\arm_neon.h:49:24: error: invalid vector element type ‘uint32_t’ (aka ‘unsigned long’)
typedef attribute((neon_vector_type(2))) uint32_t uint32x2_t;
^
d:/llvm_projects/llvm-3.0rc4/bin/…/lib/clang/3.0/include\arm_neon.h:50:24: error: invalid vector element type ‘uint32_t’ (aka ‘unsigned long’)
typedef attribute((neon_vector_type(4))) uint32_t uint32x4_t;
^
d:/llvm_projects/llvm-3.0rc4/bin/…/lib/clang/3.0/include\arm_neon.h:355:10: error: invalid conversion between vector type ‘attribute((vector_size(16 * sizeof(signed char)))) signed char’ and integer type ‘int32x4_t’ (aka ‘long’) of different size
return (int32x4_t)__builtin_neon_vmovl_v((int8x8_t)__a, 18); }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
d:/llvm_projects/llvm-3.0rc4/bin/…/lib/clang/3.0/include\arm_neon.h:357:44: error: invalid conversion between vector type ‘int8x8_t’ and integer type ‘int32x2_t’ (aka ‘long’) of different size
return (int64x2_t)__builtin_neon_vmovl_v((int8x8_t)__a, 19); }
^~~~~~~~~~~~~
d:/llvm_projects/llvm-3.0rc4/bin/…/lib/clang/3.0/include\arm_neon.h:361:10: error: invalid conversion between vector type ‘attribute((vector_size(16 * sizeof(signed char)))) signed char’ and integer type ‘uint32x4_t’ (aka ‘unsigned long’) of different size
return (uint32x4_t)__builtin_neon_vmovl_v((int8x8_t)__a, 26); }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
d:/llvm_projects/llvm-3.0rc4/bin/…/lib/clang/3.0/include\arm_neon.h:363:45: error: invalid conversion between vector type ‘int8x8_t’ and integer type ‘uint32x2_t’ (aka ‘unsigned long’) of different size
return (uint64x2_t)__builtin_neon_vmovl_v((int8x8_t)__a, 27); }
^~~~~~~~~~~~~
d:/llvm_projects/llvm-3.0rc4/bin/…/lib/clang/3.0/include\arm_neon.h:368:10: error: invalid conversion between vector type ‘attribute((vector_size(16 * sizeof(signed char)))) signed char’ and integer type ‘int32x4_t’ (aka ‘long’) of different size
return (int32x4_t)__builtin_neon_vmull_v((int8x8_t)__a, (int8x8_t)__b, 18); }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
d:/llvm_projects/llvm-3.0rc4/bin/…/lib/clang/3.0/include\arm_neon.h:370:44: error: invalid conversion between vector type ‘int8x8_t’ and integer type ‘int32x2_t’ (aka ‘long’) of different size
return (int64x2_t)__builtin_neon_vmull_v((int8x8_t)__a, (int8x8_t)__b, 19); }
^~~~~~~~~~~~~
…

2

Hello

In file included from helloneon.c:4:
d:/llvm_projects/llvm-3.0rc4/bin/../lib/clang/3.0/include\arm_neon.h:41:24:
error: invalid vector element type 'int32_t' (aka 'long')

This looks weird, why int32_t is long? Are you using cygwin somehow?

3

Hello, Anton Korobeynikov.

I just built the llvm using ms visual studio 2010 and ran the compile command on windows default command console.
additionally, I also specified include dir of arm codesourcery latest toolchain because of missing stdio.h and stdint.h .

Thanks and best regards,
Seung-yeon.

2011/11/23 Anton Korobeynikov <anton@korobeynikov.info>

4

Hi,

additionally, I also specified include dir of arm codesourcery latest toolchain because of missing stdio.h and stdint.h .

I think this is your problem. Uint32_t is defined in stdint.h, and if you’re not using clang’s stdint.h then all bets are off (int is the same size as long on 32-bit x86, so it’s perfectly reasonable for gcc’s headers to define int32_t as long).

Clang comes with stdint.h (but not stdio.h) – you should use clang’s.

Cheers,

James

5

Hello, James Molly.

Thank you for your advices.

Now I aware that this is the problem of stdint.h. And, codesourcery toolchain also has stdint.h header file at same place of stdio.h

Generally, Clang has “lib/clang/3.0/include” default search path.

If I added codesourcery toolchain path for stdio.h with -I option, stdint.h has been loaded at the specified toolchain path first cuz clang’s default search path priority moved back.

In my case, when I busted codesourcery toolchains stdint.h, it’s okay to build.
And also it was okay cuz clang called /usr/include/stdint.h first on Unbuntu linux.

How could I avoid this conflict, not to be removed stdint.h of toolchian?
I think arm_neon.h in clang lib folder can handle this.

Thanks and regards
Seung-yeon.

2011/11/24 James Molloy <james.molloy@arm.com>

6

Hello,

I totally understood about this problem.
codesourcery codebench arm eabi version uses newlibc.
but, arm gnu/linux version uses glibc.

hm… actually there is no problem. it was my mistake as james told me.

Thanks.

2011/11/24 Seung-yeon Choe <sychoe@gmail.com>

7

Hi,

Just to clarify, some header files are compiler specific. Stdint.h is one of them. The reason your Ubuntu stdint.h works is because, coincidentally, Clang’s stdint.h uses the same layout and pre-processor built-ins as GCC.

This is an implementation detail. Do not rely upon it. You should use Clang’s stdint.h.

Cheers,

James

8

Hi,

There is a little bit awkward thing.

If I need to use the newlibc printf function regardless stdint.h is compiler specific implementation,

I should remove or block newlibc’s stdint.h and the others because as you know clang already stdint.h (glibc compatible??) header but it is not standard library full set, right?

On the other hand, even if I want to use other toolchain’s glibc function, I have to replace them with headers in /lib/clang/*/include folder, right?

Please show me the lights of solution one more time. :slight_smile:

Thanks and regards,
Seung-yeon.

2011/11/24 James Molloy <James.Molloy@arm.com>

9

Hi,

There’s an open question as to the compatibility of specific headers within libraries – Clang’s stdint.h should be compatible with newlib, and so you should be able to just overwrite all duplicate headers in newlib that are also provided by Clang.

Cp -r newlib/libc/include/* /tmp/include

Cp –r lib/clang/3.0/include/* /tmp/include

Clang –I/tmp/include …

Cheers,

James