Clang (omp version) missing map and utility headers - c++11

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

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

AVX Command Error for integer addition [duplicate]

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

delay.h: No such file or directory

I wrote a simple code in Atmel Studio 6.1 to blink a LED.
#include <avr/io.h>
#include <delay.h>
int main(void)
{
...
return (0);
}
The problem is when I compile the code I get the following error:
delay.h: No such file or directory
I don't think delay.h is not available because it is in this folder:
C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native \3.4.2.1002
\avr8-gnu-toolchain\avr\include\avr\delay.h
What's actually going on?
You can use this to solve your problem.
#include <util/delay.h>

Write C DLL for MATLAB

I'm trying to write and compile some C code which I would use frm MATLAB with VS 2012
Here is my header file:
#ifndef _DLLTEST_H_
#define _DLLTEST_H_
#include <iostream>
#include <stdio.h>
#include <windows.h>
extern "C" __declspec(dllexport) int Add(int a, int b);
#endif
And here is implementation:
#include "stdafx.h"
#include "nureader.h"
extern "C" __declspec(dllexport) int Add(int a, int b)
{
return (a + b);
}
Compilation goes fine, but when I try to load DLL to MATLAB, I getting a strange error:
>> [a,b] = loadlibrary('nureader.dll', 'nureader.h')
Error using loadlibrary (line 419)
Failed to preprocess the input file.
Output from preprocessor is:nureader.h
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\eh.h(27) : fatal error C1189: #error : "eh.h
is only for C++!"
Take a look at VS output
fatal error C1189: #error : "eh.h is only for C++!"
You want to write a C library, right? so don't include C++ in it. or compile with G++ but since you're using windows I don't think you have that option...
In any case, track down what includes "eh.h" and try without it. If it builds without it - great, if not - you will need to only isolate the C portion of your program. By looking at the code, you don't seem to need anything more than
#include <stdio.h>
#include <windows.h>
So try that.

Resources