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.
Related
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.
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
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
I am trying to use mciSendString in visual studio express 2013 (Visual C++) but I keep getting an error
Error 1 error C3861: 'mciSendStringA': identifier not found
I assume this i because I have not linked to the correct dll, but I cannot find any details online or on msdn about how to link to the dll. It seems quite strange that there wouldn't be more obvious documentation about this. Can someone tell me how to link to the dll?
EDIT:
Here is the code I am trying to run:
#include <Windows.h>
#include <iostream>
#include <mmsystem.h>
extern char command1[] = "open C:\\boing.mp3 type MPEGVideo alias 0";
extern char command2[] = "play 0 from 0";
int main()
{
mciSendStringA(command1, NULL, 0, 0);
mciSendStringA(command2, NULL, 0, 0);
}
To make mciSendString() to work, you need to link to winmm.lib.
Just adding winmm.lib to Project Properties > Linker > Input > Additional Dependencies will be fine.
Looking at mmsystem.h (admittedly from the V7.1A Windows SDK, which is the most recent I have installed), I can see that there's a #ifdef _WIN32 block in there. If _WIN32 is not defined, then mciSendStringA is not declared. Instead mciSendString is declared.
Check your project options and ensure that both WIN32 and _WIN32 are defined. I'm guessing that you started from a console project, rather than a Windows Application project, and that at least one of those isn't defined.
I'm not able to compile clang(3.3) using MinGW 4.8.1. The following error always pops-up when 70% build is complete:
clang/lib/Basic/FileManager.cpp includes sys/stat.h, which defines #define stat _stat64i32 (actually there are a few other defines in between, but you get the idea ;)
clang/include/clang/Basic/FileManager.h does not include sys/stat.h; instead only has a forward-declaration.
Hence, while parsing the header, the forward declaration is used (struct stat)
But when it finally arrives at the implementation, the preprocessor will kick in and replace struct stat with struct stat64i32. Hence the mismatch.
The best solution would be to change the forward declaration in the header to instead include sys/stat.h. (I didn't actually test if it will compile then)
The current trunk does not contain the code anymore.
Update: regarding off64_t. This is defined in _mingw_off_t.h these days as:
#ifndef _OFF64_T_DEFINED
#define _OFF64_T_DEFINED
__MINGW_EXTENSION typedef long long _off64_t;
#if !defined(NO_OLDNAMES) || defined(_POSIX)
__MINGW_EXTENSION typedef long long off64_t;
#endif
#endif /*_OFF64_T_DEFINED */
So you probably want to define _POSIX before including io.h (or stdio.h)