Where is "uint16x8_t" defined?

Hi, I program on Ubuntu 12.04, 32bit for some ARM projects. On Ubuntu, a Linaro toolchain works well for some time. Recently, I begin to write NEON code. Some on line code uses uint16x8_t, uint32x4_t etc. Although the project can build, the eclipse complains these variables unresolved. I have tried many settings on eclipse, but I fail.

One on line snippet uses header with those uint variables. But o n my Ubuntu, I do not find those declarations in several stdint.h files. I am working on a Cortex-A8 project. Could you help me to solve this problem?

Thanks,

Reply to
rxjwg98
Loading thread data ...

You probably need to compile with -mfpu=neon and include arm_neon.h

Reply to
Robert Wessel

aro toolchain works well for some time. Recently, I begin to write NEON cod e. Some on line code uses uint16x8_t, uint32x4_t etc. Although the project can build, the eclipse complains these variables unresolved. I have tried m any settings on eclipse, but I fail.

t on my Ubuntu, I do not find those declarations in several stdint.h files. I am working on a Cortex-A8 project. Could you help me to solve this probl em?

Excuse me. I do have those two settings in the build. In fact, the build su cceeds, but eclipse does not know those variables. Thanks.

Reply to
rxjwg98

aro toolchain works well for some time. Recently, I begin to write NEON cod e. Some on line code uses uint16x8_t, uint32x4_t etc. Although the project can build, the eclipse complains these variables unresolved. I have tried m any settings on eclipse, but I fail.

t on my Ubuntu, I do not find those declarations in several stdint.h files. I am working on a Cortex-A8 project. Could you help me to solve this probl em?

Because the build can succeed, I would like to find the true declaration of those variables. The stdint.h under the cross tool chain has such short co ntents:

#ifndef _GCC_WRAP_STDINT_H #if __STDC_HOSTED__ # include_next #else # include "stdint-gcc.h" #endif #define _GCC_WRAP_STDINT_H #endif

I still do not know where those variables are declared.

Reply to
rxjwg98

aro toolchain works well for some time. Recently, I begin to write NEON cod e. Some on line code uses uint16x8_t, uint32x4_t etc. Although the project can build, the eclipse complains these variables unresolved. I have tried m any settings on eclipse, but I fail.

t on my Ubuntu, I do not find those declarations in several stdint.h files. I am working on a Cortex-A8 project. Could you help me to solve this probl em?

The weird thing is that there are many similar variables in arm_neon.h, see below please. But it has no clue where those variables declared. Do you ha ve some ideas?

Below are excerpt from arm_neon.h:

#ifndef _GCC_ARM_NEON_H #define _GCC_ARM_NEON_H 1

typedef struct int8x8x2_t { int8x8_t val[2]; } int8x8x2_t;

typedef struct int8x16x2_t { int8x16_t val[2]; } int8x16x2_t;

typedef struct int16x4x2_t { int16x4_t val[2]; } int16x4x2_t;

typedef struct int16x8x2_t { int16x8_t val[2]; } int16x8x2_t;

typedef struct int32x2x2_t { int32x2_t val[2]; } int32x2x2_t;

Reply to
rxjwg98

Sure, they declare different SIMD (vector) types. You are, after all, using the Neon SIMD stuff. int16x4_t for example, is a four element (lane) vector of 16 bit ints. int16x4x2_t is an array of two of those. The others follow basically the same pattern.

formatting link

Reply to
Robert Wessel

In arm_neon.h?

Reply to
Robert Wessel

I don't believe that is rxjwg98's issue. Eclipse has its own syntax checker and is quite good at highlighting trivial hard to find mistakes with big consequences. I presume that eclipse doesn't understand uint16x8_t and the like and throwing a small wobbly.

To include the likes of "uint16x8_t" you need to find the appropriate header file, I assume "arm_neon.h" in this case and add it to the include directories path in:

Project > C/C++ General > Paths and Symbols > Includes (or library paths)

My recollection is a little hazy so I may be wrong.

--
Mike Perkins 
Video Solutions Ltd 
 Click to see the full signature
Reply to
Mike Perkins

Eclipse is easily confused, sometimes, and it's a pain to un-confuse it. I figure that the compiler has the final word on what's what.

In general, if Eclipse things you're writing for your platform when you're writing for embedded, it's going to be looking at entirely the wrong set of header files, which helps it to get confused. If you really want to flog things, figure out how to point it at your tool chain's header files.

--
Tim Wescott 
Control system and signal processing consulting 
 Click to see the full signature
Reply to
Tim Wescott

I find I can usually get /most/ things to work in Eclipse by getting the include paths for the Eclipse project to match the real include paths for the compiler. But it's not uncommon that there are a few points that don't work, such as pre-defined macros in the compiler, or compiler extensions that the IDE doesn't know about. I solve these by making a defined symbol ECLIPSE in the project setup for the IDE, but not in the Makefile used for actual compilation. Then I have an include file that has Eclipse-friendly "definitions" of the items in question, surrounded by an #ifdef ECLIPSE / #endif pair. If you are using Eclipse's project manager to handle the build (I don't - I much prefer an external Makefile) then you can do the opposite - add a compiler flag "-DNOT_ECLIPSE" or similar.

The same trick is very often used for Doxygen.

Reply to
David Brown

Go to the base directory for your header files and type "grep -r uint16x8_t * | less" to see everywhere that string occurs. The chances are quite high that you can spot where it is defined.

Reply to
David Brown

Thanks all of you. After I realized that the definition is included in arm_neon.h., I add the following to the source .c file. Then, eclipse found the header file. More interestingly, it remembered that path even I commented out the definition later. The key point of the problem to me is to get confirmed that it were an eclipse setting and which header file problems.

#define __ARM_NEON__

Reply to
Robert Willy

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.