I am using neon in android-ndk,
but I'm facing an problem as topic title.
I download hello-neon demo here :
https://github.com/googlesamples/android-ndk
this is a demo shows how to use neon in android ndk.
and I add this code like this :
#include <arm_neon.h>
uint16_t neonTest(uint8x16_t input){
uint8x16_t minput = vandq_u8(input,input);
uint8x16_t tmp = vpaddq_u8(minput,minput);
tmp = vpaddq_u8(tmp,tmp);
tmp = vpaddq_u8(tmp,tmp);
return vgetq_lane_u16(vreinterpretq_u16_u8(tmp),0);
}
The most strange thing is : both vandq_u8 & vpaddq_u8 are include from arm_neon.h , but the exception trace is :
error: use of undeclared identifier 'vpaddq_u8'
It means 'vandq_u8' is include but 'vpaddq_u8' isn't . but they are in same header file .
How should I resolve this problem?
I believe the issue here is that you are compiling the same code not only for ARM, but also for x86.
The NDK has got a version of arm_neon.h also for x86, which has got an incomplete set of the ARM intrinsics, which emulate them using different SSE intrinsics. This allows using the same SIMD code even for x86, but won't get optimal performance. (Whether this even is desireable, or whether it actually does give you better performance than plain serial code, is highly disputed.) This header does contain vandq_u8, but is lacking vpaddq_u8.
So, make sure to not compile the code containing NEON intrinsics for x86 (remove x86 and x86_64 from ndk.abiFilters in build.gradle). Alternatively, use ifdefs to only use this code when targeting ARM/AArch64, and replace it with a fallback for other architectures.
Related
We are compiling fmt with the Intel C compiler on Windows 32bit and 64 bit. On 32 bit we get a strange error. Maybe we are doing something wrong but the issue is what? Here is the error message:
../master/extern/fmt/8.0.1/include/fmt/format-inl.h(1126): error: expression must have a constant value
static constexpr const uint128_wrapper pow10_significands[] = {
^
Any suggestions for a fix? We could potentially build with MSVC.
Update: format-inl.h (=inline format) is only supposed to be used in a header only mode as far I understand and that is not what I want and has not turned on. So I have to figure why this happens.
PS: fmt is great.
The expression in question is constant so this looks like a bug in the compiler or possibly incomplete implementation of constexpr. The error message is misleading but you might be able to workaround the issue by removing constexpr or some other way.
Have you tried building with a C++17 compiler? constexpr isn’t a C keyword afaik.
I am following some Linux instructions on OS X and am stuck on one line:
strip -N main my_file.o
The OS X version of strip doesn't have an -N option and I've read through the man page twice but am just not sure how to do this.
So how do I strip a single name from the symbol table on OS X?
As you say, the OSX version of strip doesn't allow this; the only way therefore is to limit its visibility in code using this on the declaration:
__attribute__((visibility("hidden"))) void MyFunction1();
Alternatively you could compile with -fvisibility=hidden and use "default" in the above __attribute__ to only expose the symbols you want.
This is a better approach anyway, as it does not require an external build step.
Note: I have found this doesn't work as expected when Objective-C code is introduced into the code base...
Reference
What is the purpose of the features.h header? Why and when can it be used in my code?
Does it define source features supported by the system?
Or does it define some additional things which must be defined depending on other defines?
The features.h header file provides various macro definitions that indicate standard conformance to other header files, i.e. which features (hence the name) should be turned on or off depending on which standard the user wishes to use.
Most C/C++ compilers have command line options to handle standards conformance. Let's take GCC as an example: when you pass the -std=gnu9x option, you ask for the GNU dialect of the C99 standard. The features.h header makes sure that all other headers that include it will turn exactly those features on or off that are needed to support this particular dialect. This is achieved by #define -ing or #undef - ing some "intermediate" macros.
As a bonus, features.h also provides the glibc version information macros as well, and various other bits & bobs.
I have grepped POSIX 7 as explained at: https://unix.stackexchange.com/questions/340285/install-the-latest-posix-man-pages/483198#483198 and there are no hits for features.h, so it must be a glibc extension only.
In glibc 2.28, it is present at include/features.h.
One of the interesting things that it defines are version macros:
#include <stdio.h>
#include <features.h>
int main(void) {
printf("__GLIBC__ %u\n", __GLIBC__);
printf("__GLIBC_MINOR__ %u\n", __GLIBC_MINOR__);
return 0;
}
Ubuntu 16.04, which has glibc 2.23, this outputs:
__GLIBC__ 2
__GLIBC_MINOR__ 23
See also: Check glibc version for a particular gcc compiler
Also, this header seems to get included in most / all glibc headers, which might allow you to check if glibc is being used: How to tell if glibc is used but TODO I couldn't find a documentation for that.
From features.h File Reference
Defines on whether to include algorithm variants.
Less variants reduce executable size and compile time. This file is a GNU parallel extension to the Standard C++ Library.
So this file will include some algorithm listed in the reference page.
In general if you need to use any of the variables or functions defined in a header file, you need to include it in your program. This rule is valid for features.h also. You can see a URL for features.h for your reference below:
http://repo-genesis3.cbi.utsa.edu/crossref/heccer/usr/include/features.h.html
I have just downloaded MinGW 64 bit for Windows (I'm not quite used to Linux) on http://sourceforge.net/projects/mingw-w64/?source=dlp
When I compile the following code, I get no errors:
#include <iostream>
int main()
{
std::cout << "Code 64 bit :D !" << std::endl;
return 0;
}
Also, when I execute the program in Code::Blocks, eveything works perfectly (using cb_console_runner.exe). The problem occurs when I execute my program outside Code::Blocks. I get the error "The application couldn't start properly (0xc000007b)". By the way, I translated the error from french. Do you have any idea what is the problem or how I can debug this? Oh I forgot: I don't get any errors when code is empty (i.e. when int main(){return0;}).
Thank you!
I've seen this happen here and there when GCC's standard C++ library (libstdc++) (or libgcc as well) is not in your %PATH%. Furthermore, this may also be the case that you have a mismatched version (i.e. a 32 bit version) of the same DLL in your path. Use something like Dependency Walker to determine this.
This doesn't happen when your program is empty since you are not using any symbols from the standard C++ library and thus it is not linked with your application. However when you use std::cout that references a symbol defined in the C++ library and thus it must be linked.
I'm using bison & flex (downloaded via cygwin) with vc++. When I compile the program I got an error:
...: fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory
The corresponding code in the flex-generated file is:
#ifndef YY_NO_UNISTD_H
/* Special case for "unistd.h", since it is non-ANSI. We include it way
* down here because we want the user's section 1 to have been scanned first.
* The user has a chance to override it with an option.
*/
/* %if-c-only */
#include <unistd.h>
/* %endif */
/* %if-c++-only */
/* %endif */
#endif
If I define YY_NO_UNISTD_H in the flex file(.l) this error will disappear, but I get several other errors:
...: error C2447: '{' : missing function header (old-style formal list?)
...: warning C4018: '<' : signed/unsigned mismatch
...: error C3861: 'isatty': identifier not found
How can I fix this problem?
All these errors occur in the flex-generated scanner.
I know it's because unistd.h doesn't exist in windows. Do I have to write my own unistd.h? If so how to write it in order to eliminate those errors?
isatty is used by the lexer to determine if the input stream is a terminal or a pipe/file. The lexer uses this information to change its caching behavior (the lexer reads large chunks of the input when it is not a terminal). If you know that your program will never be used in an interactive kind, you can add %option never-interactive to you lexer. When the program is run with user input, use %option interactive. When both uses are desired, you can either generate an interactive lexer, which gives a performance loss when used in batch mode, or provide your own isatty function.
Use %option nounistd in your .l file to remove the dependence on unistd.h.
just in case somebody's still this problem, Flex comes with unistd.h within its devel files. I found this here:
http://sourceforge.net/tracker/index.php?func=detail&aid=931222&group_id=23617&atid=379173
to put it short, just make sure your compiler can reach it. in my case it's just adding "C:\GnuWin32\include" to the additional inclusion directories
use win_flex.exe with option --wincompat and you dont need to hack your lex file
unistd.h is a UNIX header, so it's not present in VC++; your best bet is probably to compile it using g++ in Cygwin (or mingw/msys). You could also look at this question for other suggestions.
I'm using flex 2.5.4 that comes from the GnuWin32 project, which doesn't check for YY_NO_UNISTD_H.
In my version, Flex looks for unistd.h only when being compiled as C++, so you can save yourself all this trouble if your yylval doesn't use any C++ constructs.
I had to use the STL in yylval (using a pointer to make it a POD type), so in order to make flex compile in C++ I created this simple unistd.h:
#include <io.h>
That's all it takes (actually, I could copy the unistd.h file that comes with GnuWin32, like flyontheweb suggests).
P.S. To wrap things up: in Bison I put yylval's required STL header files in %code requires {} and added the current directory to the INCLUDE paths in my makefile.
I am too late but anyway I will share my findings to save someone still looking for answer.
In my case having an empty unistd.h file in the location where compiler looks for headers works for me.
Well this post is old but I face the same problem and here is something that should work.
WinFlexBison
I ran into this problem recently after upgrading to Angular 14.
npm install -g latest-version
resolved my issue.