The following piece code
#pragma omp parallel
printf("%f", 1.0f);
produces the a "Floating point exception". Has anyone encountered anything like that?
More details:
No problems when I try to print out strings or integers.
No problem if OpenMP is not used.
I am running it on Mac OSX 10.6.8 and the Intel C++ compiler 12.0.4.
Other than that, OpenMP works fine.
The code:
#include <stdio.h>
#include <omp.h>
int main()
{
#pragma omp parallel
printf("%d", 1);
printf("\n...\n");
fflush(stdout);
#pragma omp parallel
printf("%f", 2.0);
}
compiled with:
icpc -o test test.cc -fp-trap-all=all -openmp
produces:
1111
...
Floating point exception
Related
If I understood correctly, the article https://en.cppreference.com/w/cpp/language/aggregate_initialization says that designated initialization is allowed starting from c++20, and is not allowed in c++11.
So why is the following compiled in c++11? g++ -std=c++11 main.cpp
struct A { int x; int y; int z; };
int main(int argc, char const *argv[])
{
A b{.x = 1, .z = 2};
return 0;
}
My first guess was that there is some kind of gcc extension that supports it, but clang compile this code as well (clang -std=c++11 main.cpp)
Why is designator initialization compiled in c++11?
The program is ill-formed in C++11. The C++ language doesn't disallow ill-formed programs from compiling.
My first guess was that there is some kind of gcc extension that supports it, but clang compile this code as well
Your first guess is good, and you can simply expand it to arrive at the answer: The language is extended by both GCC and Clang. Clang often attempts to be as compatible with GCC as possible. For better and for worse.
I installed CIVL in ubuntu 14.04 and want to use it to verify OpenMP programs, but I encountered some questions as following:
If I use the command 'civl verify file_name.c' to verify OpenMP, it just regard the OpenMP program as a common C program, because I missed a optional parameter '-ompNoSimplify'.
However, if I use the command 'civl verify -ompNoSimplify file_name.c', it cannot verify any OpenMP programs, even the very simple OpenMP programs. such as the following program
#include <stdio.h>
#include <omp.h>
int main()
{
#pragma omp parallel for
for (char i = 'a'; i <= 'z'; i++)
printf("%c\n",i);
return 0;
}
the output of verification
I'm trying to compile a program on Windows using MingW (msys2) and it fails with the j0 function. On Linux it compiles no problem. It seems to hate when I use the -std=c++11 flag on the compiler. How can I get this to compile properly and with the -std=c++11 flag on?
Sample code:
#include <cmath>
int main( int argc, char *argv[] )
{
float test = j0( 5 );
}
Output
$ g++ -std=c++11 test.cpp -o test
test.cpp: In function 'int main(int, char**)':
test.cpp:6:21: error: 'j0' was not declared in this scope
float test = j0( 5 );
Apparently, MinGW defines the Bessel functions only when __STRICT_ANSI__ is not defined, and it is defined when -std=c++11 is specified. I was able to get your code to compile in MinGW by adding #undef __STRICT_ANSI__ at the top of the file. See https://sourceforge.net/p/mingw-w64/feature-requests/68/
You might also try -std=gnu++11 instead. See https://stackoverflow.com/a/19667112/10077
I have spent the day searching for an answer to what should be a simple problem. I am building a c++ program to call a fairly large amount of existing fortran. I started by changing the fortran main to a subroutine and then called it with a simple c++ main. My steps look like:
gfortran -c f1.f90 f2.f90 ......
g++ -c mn.cpp
gfortran -lstdc++ -o prog.exe mn.o f1.o ....
mn.cpp started out looking like the code below, and the above steps do work ok. I get a host of linker errors if I try to link with:
g++ -lgfortran (this never works!)
Next, I tried to instantiate a simple array class (remove the 2 commented lines). This produced linker errors concerning gxx_personality_seh0, vtable, and operator new.I get similar errors if I just create an array of doubles with new (remove comment), and if I remove the call to the fortran program completely (still linking with gfortran). Obviously, -lstdc++ does not bring in all the libraries needed. Which libraries are needed and how can I get it to link them?
I am using Windows 7 with Cygwin. The libraries it links are in ...lib/x86_64-pc-cygwin/4.9.3. I can post the linker output if it would be helpful.
mn.cpp which works (code commented out) is below:
#include <string.h>
#include <stdlib.h>
//#include "array.h"
extern "C" {
void mnf90_(const char*,int);
}
int main(int argc, char* argv[]){
// Array2D A; // first derivative
static const char *feos = "d/fld9x.dat";
int npoint = 20;
// double *xc = new double[npoint];
mnf90_(feos,strlen(feos));
}
Background
We have been trying unsuccessfully to use the new GCC 5.1 release to offload OpenMP blocks to the Intel MIC (i.e. the Xeon Phi). Following the GCC Offloading page, we've put together the build.sh script to build the "accel" target compiler for "intelmic" and the host compiler. The compilation appears to complete successfully.
Using the env.sh script we then attempt to compile the simple hello.c program listed below. However, this program seems to only run on the host and not the target device.
As we are new to offloading in general, as well as compiling GCC, there are multiple things we could be doing incorrectly. However, we've investigated the resources already mentioned plus the following (I do not have enough rep to post the links):
Offloading for Xeon Phi
Xeon Phi Tutorial
Intel Xeon Phi Offload Programming Models
The biggest problem is they usually reference the Intel compiler. While we plan to purchase a copy, we do NOT currently have a copy. In addition, the majority of our development pipeline is already integrated with GCC and we'd prefer to keep it that way (if possible).
We have installed the latest MPSS 3.5 distribution, making the necessary modifications to work under Ubuntu. We can successfully communicate and check the status of the Xeon Phis in our system.
In our efforts, we never saw any indication that the code was running in the mic emulation mode either.
Questions
Has anyone successfully built a host/target GCC compiler combination that actually offloads to the Xeon Phi? If so, what resources did you use?
Are we missing anything in the build script?
Is there anything wrong with the test source code? They compile with no errors (except what is mentioned below) and run with 48 threads (i.e. the number of logical threads in the host system).
Since Google search does not reveal much, does anyone have suggestions for the next step (besides giving up on GCC offloading)? Is this a bug?
Thanks!
build.sh
#!/usr/bin/env bash
set -e -x
unset LIBRARY_PATH
GCC_DIST=$PWD/gcc-5.1.0
# Modify these to control where the compilers are installed
TARGET_PREFIX=$HOME/gcc
HOST_PREFIX=$HOME/gcc
TARGET_BUILD=/tmp/gcc-build-mic
HOST_BUILD=/tmp/gcc-build-host
# i dropped the emul since we are not planning to emulate!
TARGET=x86_64-intelmic-linux-gnu
# should this be a quad (i.e. pc)?? default (Ubuntu) build seems to be x86_64-linux-gnu
HOST=x86_64-pc-linux-gnu
# check for the GCC distribution
if [ ! -d $GCC_DIST ]; then
echo "gcc-5.1.0 distribution should be here $PWD"
exit 0
fi
#sudo apt-get install -y libmpfr-dev libgmp-dev libmpc-dev libisl-dev dejagnu autogen sysvbanner
# prepare and configure the target compiler
mkdir -p $TARGET_BUILD
pushd $TARGET_BUILD
$GCC_DIST/configure \
--prefix=$TARGET_PREFIX \
--enable-languages=c,c++,fortran,lto \
--enable-liboffloadmic=target \
--disable-multilib \
--build=$TARGET \
--host=$TARGET \
--target=$TARGET \
--enable-as-accelerator-for=$HOST \
--program-prefix="${TARGET}-"
#--program-prefix="$HOST-accel-$TARGET-" \
# try adding the program prefix as HINTED in the https://gcc.gnu.org/wiki/Offloading
# do we need to specify a sysroot??? Wiki says we don't need one... but it also says "better to configure as cross compiler....
# build and install
make -j48 && make install
popd
# prepare and build the host compiler
mkdir -p $HOST_BUILD
pushd $HOST_BUILD
$GCC_DIST/configure \
--prefix=$HOST_PREFIX \
--enable-languages=c,c++,fortran,lto \
--enable-liboffloadmic=host \
--disable-multilib \
--build=$HOST \
--host=$HOST \
--target=$HOST \
--enable-offload-targets=$TARGET=$TARGET_PREFIX
make -j48 && make install
popd
env.sh
#!/usr/bin/env bash
TARGET_PREFIX=$HOME/gcc
HOST_PREFIX=$HOME/gcc
HOST=x86_64-pc-linux-gnu
VERSION=5.1.0
export LD_LIBRARY_PATH=/opt/intel/mic/coi/host-linux-release/lib:/opt/mpss/3.4.3/sysroots/k1om-mpss-linux/usr/lib64:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=$HOST_PREFIX/lib:$HOST_PREFIX/lib64:$HOST_PREFIX/lib/gcc/$HOST/$VERSION:$LD_LIBRARY_PATH
export PATH=$HOST_PREFIX/bin:$PATH
hello.c (version 1)
#include <omp.h>
#include <stdio.h>
#include <stdlib.h>
int main (int argc, char *argv[])
{
int nthreads, tid;
/* Fork a team of threads giving them their own copies of variables */
#pragma offload target (mic)
{
#pragma omp parallel private(nthreads,tid)
{
/* Obtain thread number */
tid = omp_get_thread_num();
printf("Hello World from thread = %d\n", tid);
/* Only master thread does this */
if (tid == 0) {
nthreads = omp_get_num_threads();
printf("Number of threads = %d\n", nthreads);
}
#ifdef __MIC__
printf("on target...\n");
#else
printf("on host...\n");
#endif
}
}
}
We compiled this code with:
gcc -fopenmp -foffload=x86_64-intelmic-linux-gnu hello.c -o hello
hello_omp.c (version 2)
#include <omp.h>
#include <stdio.h>
#include <stdlib.h>
int main (int argc, char *argv[])
{
int nthreads, tid;
/* Fork a team of threads giving them their own copies of variables */
#pragma omp target device(mic)
{
#pragma omp parallel private(nthreads,tid)
{
/* Obtain thread number */
tid = omp_get_thread_num();
printf("Hello World from thread = %d\n", tid);
/* Only master thread does this */
if (tid == 0) {
nthreads = omp_get_num_threads();
printf("Number of threads = %d\n", nthreads);
}
#ifdef __MIC__
printf("on target...\n");
#else
printf("on host...\n");
#endif
}
}
}
Almost the same thing, but instead we tried the
#pragma omp target device
syntax. In fact, with mic, it complains, but with any device numbers (i.e. 0) it compiles and runs on the host. This code was compiled in the same manner.
Offloading to Xeon Phi with GCC 5 is possible. In order to get it to work, one must compile liboffloadmic for native MIC target, similarly to how it is done here. The problem of your setup is that it compiles host emulation libraries (libcoi_host.so, libcoi_device.so), and sticks with emulated offloading even though the physical Xeon Phi is present.