AVX Command Error for integer addition [duplicate] - cpu

Im learning to use intrinsics instead of asm-inlining. Yesterday, they were working but I always get error today. Changed nothing.
#include <iostream>
#include <intrin.h> // immintrin.h, smmintrin.h ... tried all, never worked
using namespace std;
int main()
{
_m256_zeroupper(); // __mm256_zeroupper(); does not work too
_mm128 x; // __mm128 x; does not work too
_mm256 y; // __mm256 y; does not work too
_m256_zeroupper(); // __mm256_zeroupper(); does not work too
cout << "Hello world!" << endl;
return 0;
}
Here are the errors. I tried all header files for different intrinsics but errors were same. Also reinstalled gcc but did not work.
Where am I wrong? What do I need to add to actually declare these intrinsic variables and functions?
C:\indirmeDenemesi\hello_intrin\main.cpp||In function 'int main()':|
C:\indirmeDenemesi\hello_intrin\main.cpp|8|error: '_mm256_zeroupper' was not declared in this scope|
C:\indirmeDenemesi\hello_intrin\main.cpp|9|error: '_mm128' was not declared in this scope|
C:\indirmeDenemesi\hello_intrin\main.cpp|9|error: expected ';' before 'x'|
C:\indirmeDenemesi\hello_intrin\main.cpp|10|error: '_mm256' was not declared in this scope|
C:\indirmeDenemesi\hello_intrin\main.cpp|10|error: expected ';' before 'y'|
||=== Build finished: 5 errors, 0 warnings (0 minutes, 0 seconds) ===|
Using 64-bit latest version of gcc on 64bit cpu with 64 bit windows.
CPU is FX8150.
Tried -march=bdver1 -mtune=bdver1 and it produced hundreds of junk error.
Does all these mean my CPU is dying?
Edit: some other projects are working now, but I did not change anything. This must be a project-specific thing.
Using code::blocks and when I right-click on a header and select "open", it gives error "could not find" but does not give any error when compiling related to that, just error for intrinsinc commands. Same for working projects(they compile everything and work, but does not find header files when right click and click open). Maybe some other windows services were interfering? I dont know but compiler errors are vanishing and coming again, time to time. Reinstalling also codeblocks did not solve. Only some projects can use intrinsics while other projects cannot(even if all projects have same headers.)
This code below does not work too.
#include <iostream>
#include <immintrin.h>
using namespace std;
int main()
{
_m256_zeroupper();
__mm128 x;
__mm256 y;
_m256_zeroupper();
cout << "Hello world!" << endl;
return 0;
}

Three things should make your code work:
Make sure you're using the -mavx compile flag.
Your variable should be declared as __m256 not _mm256.
Make sure you're including immintrin.h

Related

How to use langinfo.h features in glibc without breaking compilation in FreeBSD based system?

I am trying to make the following code work on both Linux and FreeBSD based system, Is it a valid usage of macros __GLIBC__ and __USE_XOPEN2K8?
#include <stdio.h>
#include <langinfo.h>
#include <locale.h>
#include <xlocale.h>
int main(void) {
//#if defined(__GLIBC__) && defined (__USE_XOPEN2K8)
locale_t loc;
char *locale_messages = "en-US.utf-8";
loc = newlocale(LC_ALL_MASK, locale_messages, (locale_t)0);
if (loc != NULL)
{
char result[256];
sprintf(result, "%s_%s.%s",
nl_langinfo_l(_NL_IDENTIFICATION_LANGUAGE, loc),
nl_langinfo_l(_NL_IDENTIFICATION_TERRITORY, loc),
nl_langinfo_l(CODESET, loc));
}
//#endif
}
If I don't use those directives, I get the following error on mac OS. I want to disable that code to avoid the following errors.
error: use of undeclared identifier '_NL_IDENTIFICATION_LANGUAGE'
nl_langinfo_l(_NL_IDENTIFICATION_LANGUAGE, loc),
^
error: use of undeclared identifier '_NL_IDENTIFICATION_TERRITORY'
nl_langinfo_l(_NL_IDENTIFICATION_TERRITORY, loc),
I have found one thread recommending use _GNU_SOURCE and _XOPEN_SOURCE, but as result above code is disabled on my linux system too. It seems I need to define _GNU_SOURCE before using it, but before proceding with this idea, can we work with __GLIBC__ and __USE_XOPEN2K8.
You can use
#indef __FreeBSD__
#endif
preprocessor directives to ignore the code that shouldn't be built on FreeBSD. However man nl_langinfo_l on FreeBSD says that this function is present on FreeBSD, so you shouldn't have any problems with it.
The best way is to use a build system to detect if that option is available and then conditionally enable that part of code depending of the detection result. This is how autotools project came to be - to detect differences between operating systems.
In cmake you could:
include(CheckCSourceCompiles)
check_c_source_compiles("
#define _GNU_SOURCE
#define _SOMETHING_READ_FEATURE_TEST_MACROS
#include <something something that is needed.h>
int main() { return _NL_IDENTIFICATION_TERRITORY; }
" WE_HAVE_NL_IDENTIFICATION_TERRITORY)
if(WE_HAVE_NL_IDENTIFICATION_TERRITORY)
target_add_definitions(your_target PUBLIC LIB_HAS_NL_IDENTIFICATION_TERRITORY)
endif()
and then use your own LIB_HAS_NL_IDENTIFICATION_TERRITORY macro that detect if that option is available or not. Such solution is stable, easy to port and dynamically reacts to environment changes.

g++ libstdc++-v3 ‘thread’ is not a member of ‘std’

I am building gcc 9.10 and it works great with c threads but im doing something wrong with g++ and libstdc++-v3 I just dont know what.
I compile gcc/g++, glibc, and libstdc++-v3
I see that the file at include/c++/9.1.0/threads
When I go to compile a simple test program I get
error: ‘thread’ is not a member of ‘std’
C pthread test program compiles
#include <pthread.h>
int main(){
tpthread_t t;
}
C test program compiles
#include <threads.h>
int main(){
thrd_t t;
}
Cxx test program does not compile
#include <thread>
int main(){
std::thread t;
}
Gets error
error: ‘thread’ is not a member of ‘std’
Looking into the header include/c++/9.1.0/threads
#if defined(_GLIBCXX_HAS_GTHREADS)
it looks like it skips everything if that is not defined
how can I check to see if thats the case and then why?
I made this little test and it compiles indicating to me that _GLIBCXX_HAS_GTHREADS is not defined
int main(){
#if defined(_GLIBCXX_HAS_GTHREADS)
123 here error
#endif
}
when compiling libstdc++-v3 I use
../libstdc++-v3/configure -v --enable-libstdcxx-threads=yes
even though I would think threads should be enabled by default on a linux x64 system
The other question doesnt help my situation it was from a long time ago and gcc has changed. One comment looks like it touches on my issue but doesnt go any deeper
If you look in the thread header, it appears that the class only exists #if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1). I'm not sure though, what you'd have to do to have those defined
Thats the issue im having but theres no solution
The answer was to configure with --enable-threads=yes I dont know why that was so hard to find and why thats not default

Including <Eigen/Dense> when using /openmp

I am pretty new user of Eigen and have run into a weird problem. I am adding to a C++ project that uses OpenMP (Visual Studio 2012 compiler, /openmp set). I get a compilation error:
include\eigen\src/Core/products/Parallelizer.h(34): error C3861:
'omp_get_max_threads': identifier not found
I have tried to google around for an answer, but have failed to find a solution. We have another project, not using openmp, where Eigen has been used successfully for a while. Adding /openmp to that project did not trigger the problem. I also tried to disable openmp in Eigen, using the EIGEN_DONT_PARALLELIZE preprocessor directive. The problem persists. All suggestions to solve the problem are more than welcome.
Long comment, not really an answer: Something appears to be broken in your project. I'm using Eigen 3.2.9 as a reference, as you haven't specified which version you're using. In Eigen/Core (133) we have
#if (defined _OPENMP) && (!defined EIGEN_DONT_PARALLELIZE)
#define EIGEN_HAS_OPENMP
#endif
#ifdef EIGEN_HAS_OPENMP
#include <omp.h>
#endif
So, if you properly defined EIGEN_DONT_PARALLELIZE in your project, EIGEN_HAS_OPENMP shouldn't be defined and omp.h shouldn't be included. Additionally, in Parallelizer.h(30):
#ifdef EIGEN_HAS_OPENMP
if(m_maxThreads>0)
*v = m_maxThreads;
else
*v = omp_get_max_threads();
#else
*v = 1;
#endif
So if you had properly defined EIGEN_DONT_PARALLELIZE, you would not be getting the error you are getting.
Regarding the C3861 error, it means that the compiler is not able to find a declaration for omp_get_max_threads (called in Parallelizer.h). As that code is called within a #ifdef EIGEN_HAS_OPENMP as is the line #include <omp.h> in Core, and omp_get_num_threads is only wrapped in an #if defined( __cplusplus) you could add a check in Core or omp.h to make sure that the code is active
// This is in Eigen/Core
#ifdef EIGEN_HAS_OPENMP
static_assert(0, "OMP FILE IS INCLUDED IN CORE...");
#include <omp.h>
#endif
and
// This is in omp.h
static_assert(0, "OMP FILE IS PROPERLY INCLUDED...");
_OMPIMP int _OMPAPI
omp_get_num_threads(
void
);
You should get both as errors if omp is loaded correctly.

Codeblocks: Including library

I am trying to get started with the VJoy virtual joystick, but i am having trouble getting it up and running.
I keep getting this error:
main.cpp|14| undefined reference to `_imp__vJoyEnabled'
I am trying to get it running using the code below.
#include <iostream>
#include <windows.h>
#include <stdlib.h>
#include "public.h"
#include "vjoyinterface.h"
using namespace std;
int main()
{
// Get the driver attributes (Vendor ID, Product ID, Version Number)
if (!vJoyEnabled())
{
cout << "Function vJoyEnabled Failed - make sure that vJoy is installed and enabled\n" << endl;
}
cout << "Hello world!" << endl;
return 0;
}
Within Codeblocks i have set the compiler to compile with C++11.
Also within Codeblocks i have linked the library (Project build options -> linker settings -> add library)
I have also tried playing with the Search Directory, but i can't seem to get it working.
Any ideas what i am missing?
I found out i was linking to the wrong locations. Unfortunately there wasn't a clear error indicating this.
So the solution to this problem(in my case):
-Make sure you link to the right library locations
-Move the libraries and all of its associated files inside of the codeblocks project folder
-Add the library to the linked libraries(Project build options -> Linker settings -> Link libraries)
-Add the library locations to the search directories(Project build options -> Search directories -> Linker -> add)

Clang (omp version) missing map and utility headers

I'm experiencing some sort of issue trying to compile a perfectly (windows+linux tested) mpi+openmp software I wrote my own.
I've managed to install and set to work the omp-adapted version of clang, and it works flawlessly in a simple omp "hello world" I've prepared.
As well I've installed open-mpi via homebrew, and the mpi "hello world" is working as well.
Now there come the issue.
Firstly, not so much confident in clang and openmp working together, I've created a version of my software without openmp calls. This version (MPI-only) of the code has been compiled with no issue.
Now comes my real dilemma.
I've reverted back the omp sections of my code, and tried to compile it with both MPI and openMP flags (mpic++ wrapper with ompclang forced in and -fopenmp flag added). The output of the compiler verbose mode is here below.
[...]
/usr/local/Cellar/open-mpi/1.8.4/include/openmpi/ompi/mpi/cxx/mpicxx.h:39:10:
fatal error: 'utility' file not found
#include <utility>
^
[...]
/usr/local/Cellar/open-mpi/1.8.4/include/openmpi/ompi/mpi/cxx/mpicxx.h:39:10:
fatal error: 'utility' file not found
#include <map>
^
[...]
After this output I tried to compile something like this:
#include <iostream>
#include <map>
#include <utility>
int main(int argc,char* argv[]){
std::cout<<"Hello World!!!!"<<std::endl;
return 0;
}
And the output keeps me saying the compiler can't find map, utility AND iostream as well.
It appears to me the problem is the compiler doesn't know where to find the standard c++ libraries.
Can anyone of you tell me how to solve this? Thanks in advance
Have fun,
gf
EDIT:
I've found a good suggestion from this site:
http://lists.cs.uiuc.edu/pipermail/cfe-users/2013-November/000293.html
That helped me to solve the issue.
I post the OMP+MPI hello world if anyone ever needs to test them together.
#include <mpi.h>
#include "omp.h"
int main(int argc, char** argv) {
// Initialize the MPI environment
MPI_Init(NULL, NULL);
// Get the number of processes
int world_size;
MPI_Comm_size(MPI_COMM_WORLD, &world_size);
// Get the rank of the process
int world_rank;
MPI_Comm_rank(MPI_COMM_WORLD, &world_rank);
// Get the name of the processor
char processor_name[MPI_MAX_PROCESSOR_NAME];
int name_len;
MPI_Get_processor_name(processor_name, &name_len);
// Print off a hello world message
#pragma omp parallel
printf("Hello from thread %d, nthreads %d,from processor %s, rank %d out of %d processors\n", omp_get_thread_num(), omp_get_num_threads(),processor_name, world_rank, world_size);
// Finalize the MPI environment.
MPI_Finalize();
}
Have fun
gf

Resources