- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
There seems to be an incompability between Intel Compiler 14.0.1 and the "fenv.h" header in the GNU Standard C++ Library provided with GCC 4.8.1.
Here is an example code :
[mboisson@r103-n2 tmp]$ cat test_fenv.cpp
[cpp]
#include <fenv.h>
fexcept_t data;
[/cpp]
[mboisson@r103-n2 tmp]$ echo $CPLUS_INCLUDE_PATH
[mboisson@r103-n2 tmp]$ icpc -c test_fenv.cpp
#### compiles fine without the gnu stdlibc++
[mboisson@r103-n2 tmp]$ export CPLUS_INCLUDE_PATH=/software6/compilers/gcc/4.8.1/include/c++/4.8.1/
[mboisson@r103-n2 tmp]$ icpc -c test_fenv.cpp
[bash]
test_fenv.cpp(3): error: identifier "fexcept_t" is undefined
fexcept_t data;
^
compilation aborted for test_fenv.cpp (code 2)
[/bash]
#### does not compile either when specifying std=c++11
[mboisson@r103-n2 tmp]$ icpc -std=c++11 -c test_fenv.cpp
[bash]
In file included from test_fenv.cpp(1):
/software6/compilers/gcc/4.8.1/include/c++/4.8.1/fenv.h(58): error: the global scope has no "fenv_t"
using ::fenv_t;
^
In file included from test_fenv.cpp(1):
/software6/compilers/gcc/4.8.1/include/c++/4.8.1/fenv.h(59): error: the global scope has no "fexcept_t"
using ::fexcept_t;
^
In file included from test_fenv.cpp(1):
/software6/compilers/gcc/4.8.1/include/c++/4.8.1/fenv.h(62): error: the global scope has no "feclearexcept"
using ::feclearexcept;
^
In file included from test_fenv.cpp(1):
/software6/compilers/gcc/4.8.1/include/c++/4.8.1/fenv.h(63): error: the global scope has no "fegetexceptflag"
using ::fegetexceptflag;
^
In file included from test_fenv.cpp(1):
/software6/compilers/gcc/4.8.1/include/c++/4.8.1/fenv.h(64): error: the global scope has no "feraiseexcept"
using ::feraiseexcept;
^
In file included from test_fenv.cpp(1):
/software6/compilers/gcc/4.8.1/include/c++/4.8.1/fenv.h(65): error: the global scope has no "fesetexceptflag"
using ::fesetexceptflag;
^
In file included from test_fenv.cpp(1):
/software6/compilers/gcc/4.8.1/include/c++/4.8.1/fenv.h(66): error: the global scope has no "fetestexcept"
using ::fetestexcept;
^
In file included from test_fenv.cpp(1):
/software6/compilers/gcc/4.8.1/include/c++/4.8.1/fenv.h(68): error: the global scope has no "fegetround"
using ::fegetround;
^
In file included from test_fenv.cpp(1):
/software6/compilers/gcc/4.8.1/include/c++/4.8.1/fenv.h(69): error: the global scope has no "fesetround"
using ::fesetround;
^
In file included from test_fenv.cpp(1):
/software6/compilers/gcc/4.8.1/include/c++/4.8.1/fenv.h(71): error: the global scope has no "fegetenv"
using ::fegetenv;
^
In file included from test_fenv.cpp(1):
/software6/compilers/gcc/4.8.1/include/c++/4.8.1/fenv.h(72): error: the global scope has no "feholdexcept"
using ::feholdexcept;
^
In file included from test_fenv.cpp(1):
/software6/compilers/gcc/4.8.1/include/c++/4.8.1/fenv.h(73): error: the global scope has no "fesetenv"
using ::fesetenv;
^
In file included from test_fenv.cpp(1):
/software6/compilers/gcc/4.8.1/include/c++/4.8.1/fenv.h(74): error: the global scope has no "feupdateenv"
using ::feupdateenv;
^
test_fenv.cpp(3): error: identifier "fexcept_t" is undefined
fexcept_t data;
^
compilation aborted for test_fenv.cpp (code 2)
[/bash]
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This by the way prevents me from compiling boost 1.55.0 with Intel 14.0.1 and the GNU Standard C++ library , while it compiles just fine with GCC itself.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
It is defined. Here is the content of the fenv.h :
[cpp]
// -*- C++ -*- compatibility header.
// Copyright (C) 2007-2013 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library. This library is free
// software; you can redistribute it and/or modify it under the
// terms of the GNU General Public License as published by the
// Free Software Foundation; either version 3, or (at your option)
// any later version.
// This library is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
// Under Section 7 of GPL version 3, you are granted additional
// permissions described in the GCC Runtime Library Exception, version
// 3.1, as published by the Free Software Foundation.
// You should have received a copy of the GNU General Public License and
// a copy of the GCC Runtime Library Exception along with this program;
// see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
// <http://www.gnu.org/licenses/>.
/** @file fenv.h
* This is a Standard C++ Library header.
*/
#ifndef _GLIBCXX_FENV_H
#define _GLIBCXX_FENV_H 1
#pragma GCC system_header
#include <bits/c++config.h>
#if _GLIBCXX_HAVE_FENV_H
# include_next <fenv.h>
#endif
#if __cplusplus >= 201103L
#if _GLIBCXX_USE_C99_FENV_TR1
#undef feclearexcept
#undef fegetexceptflag
#undef feraiseexcept
#undef fesetexceptflag
#undef fetestexcept
#undef fegetround
#undef fesetround
#undef fegetenv
#undef feholdexcept
#undef fesetenv
#undef feupdateenv
namespace std
{
// types
using ::fenv_t;
using ::fexcept_t;
// functions
using ::feclearexcept;
using ::fegetexceptflag;
using ::feraiseexcept;
using ::fesetexceptflag;
using ::fetestexcept;
using ::fegetround;
using ::fesetround;
using ::fegetenv;
using ::feholdexcept;
using ::fesetenv;
using ::feupdateenv;
} // namespace
#endif // _GLIBCXX_USE_C99_FENV_TR1
#endif // C++11
#endif // _GLIBCXX_FENV_H
[/cpp]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi again,
Looked like the message did not go through, likely because of the large code block. Here is the code for the fenv.h
http://code.woboq.org/userspace/include/c++/4.8.1/fenv.h.html
Maxime Boissonneault
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I did some testing by changing the fenv.h from glibc++.
Notably, if I change the line
# include_next <fenv.h>
by
# include_next </usr/include/fenv.h>
Both the -std=c++11 and the one without work. It seems that ICC does not deal with "include_next" directive properly, and instead of including the system fenv.h, finds only the one from glibc++ and includes this one a second time.
Best regards,
Maxime
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi once more,
It seems that if I add /usr/include at the end of my CPATH, then it works. Isn't /usr/include searched by default by the precompiler ?
Is there a way, beside overwriting CPATH, to add /usr/include in the default search paths for icpc ?
Best regards,
Maxime
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The behaviors of include_next have been discussed before, e.g. http://software.intel.com/en-us/forums/topic/338378
By default, icpc should search the same include paths as the active g++, but it's even possible that icpc doesn't see the same g++ active as you expect. Typical problems include a new shell cluster management schemes changing the order of g++ versions on search path. Still, I think it's safer to depend on 'which g++' than on setting an INCLUDE_PATH. Anyway, I think it's possible as you found for /usr/include to be skipped if you don't specify it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Tim,
We only have a single g++ on our system, and it was compiled manually, from source code. We
1) Installed the CentOS6 g++ package.
2) Installed gcc 4.8.1 from source
3) bootstrapped the gcc 4.8.1 so it does not depend anymore on the CentOS6 default
4) uninstalled the centos6 default
5) installed ICC with gcc 4.8.1 in the paths.
We still have the glibc from the OS (we were unsuccessfull in making the loader work without it), but not the glibc++ (we have the one from source).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I suppose fenv.h would be found in glibc, and would be selected according to paths used by the gcc you used to bootstrap. I don't see that g++ libraries which are built with gcc/g++ have a bearing on finding fenv.h. If it's on a path which isn't inherited by icpc from your g++ you might expect to need to specify that path.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There does not seem to be any include directories that are printed by the -print-search-dirs option :
[mboisson@r103-n3 tmp]$ icpc -print-search-dirs
install: /software6/compilers/intel/composer_xe_2013_sp1.1.106/bin/intel64
programs: =/software6/compilers/intel/composer_xe_2013_sp1.1.106/bin/intel64::/software6/apps/cmake/2.8.12/bin:/software6/apps/mercurial/2.7.2/bin:/software6/apps/git/1.8.4.1/bin:/software6/apps/flex/2.5.37/bin:/software6/apps/moab/moab/bin:/software6/mpi/openmpi/1.6.5_intel/bin:/software6/compilers/intel/composer_xe_2013_sp1/bin:/software6/compilers/gcc/4.8.1/bin:/software6/apps/bison/3.0/bin:/software6/apps/make/3.82/bin:/software6/apps/automake/1.14/bin:/software6/apps/autoconf/2.69/bin:/software6/apps/m4/1.4.17/bin:/clumeq/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/var/cfengine/bin:/clumeq/bin:/software6/centos6-extra/bin:/software6/centos6-extra/usr/bin:/home/mboisson/bin:/home/mboisson/Scripts:/clumeq/staff/torque-moab-tools:/home/mboisson/Scripts/torque-moab
libraries: =/software6/compilers/intel/composer_xe_2013_sp1.1.106/compiler/lib/intel64:/usr/lib64
Is that normal ?
Maxime
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Here it is : [mboisson@r103-n3 ~]$ icpc -print-search-dirs
install: /software6/compilers/intel/composer_xe_2013_sp1.1.106/bin/intel64
programs: =/software6/compilers/intel/composer_xe_2013_sp1.1.106/bin/intel64::/software6/apps/cmake/2.8.12/bin:/software6/apps/mercurial/2.7.2/bin:/software6/apps/git/1.8.4.1/bin:/software6/apps/flex/2.5.37/bin:/software6/apps/moab/moab/bin:/software6/mpi/openmpi/1.6.5_intel/bin:/software6/compilers/intel/composer_xe_2013_sp1/bin:/software6/compilers/gcc/4.8.1/bin:/software6/apps/bison/3.0/bin:/software6/apps/make/3.82/bin:/software6/apps/automake/1.14/bin:/software6/apps/autoconf/2.69/bin:/software6/apps/m4/1.4.17/bin:/clumeq/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/var/cfengine/bin:/clumeq/bin:/software6/centos6-extra/bin:/software6/centos6-extra/usr/bin:/home/mboisson/bin:/home/mboisson/Scripts:/clumeq/staff/torque-moab-tools:/home/mboisson/Scripts/torque-moab
libraries: =/software6/compilers/intel/composer_xe_2013_sp1.1.106/compiler/lib/intel64:/usr/lib64
[mboisson@r103-n3 ~]$ icpc -print-search-dirs -v
icpc version 14.0.1 (gcc version 4.8.0 compatibility)
[mboisson@r103-n3 ~]$ icpc -print-search-dirs -V
Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.1.106 Build 20131008
Copyright (C) 1985-2013 Intel Corporation. All rights reserved.
Is that what you meant ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This looks like a user error to me. I don't think we support the compilation of the headers using CPLUS_INCLUDE_PATH only. Note that the icc compiler queries the gcc/g++ in the user's path to determine which headers to include. The example worked for me in the g++48 environment.
$ icpc -c test_fenv.cpp -M
test_fenv.o: test_fenv.cpp \
/opt/intel/composer_xe_2013_sp1.1.106/compiler/include/fenv.h \
/opt/gcc/gcc-4.8.1/include/c++/4.8.1/fenv.h \
/opt/gcc/gcc-4.8.1/include/c++/4.8.1/x86_64-unknown-linux-gnu/bits/c++config.h \
/opt/gcc/gcc-4.8.1/include/c++/4.8.1/x86_64-unknown-linux-gnu/bits/os_defines.h \
/usr/include/features.h /usr/include/sys/cdefs.h /usr/include/bits/wordsize.h \
/usr/include/gnu/stubs.h /usr/include/bits/wordsize.h \
/usr/include/gnu/stubs-64.h \
/opt/gcc/gcc-4.8.1/include/c++/4.8.1/x86_64-unknown-linux-gnu/bits/cpu_defines.h \
/usr/include/fenv.h /usr/include/bits/fenv.h /usr/include/bits/wordsize.h \
/usr/include/bits/fenvinline.h
Note that include/c++/4.8.1/fenv.h is included from our gcc48 installation.
Our suggestion is to put the desired version of gcc/g++ in the user's path and do not set CPLUS_INCLUDE_PATH at all.
Regards, Qiao
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
The desired version of gcc/g++ IS in the user's path in this case :
[mboisson@r103-n3 ~]$ echo $PATH
/software6/apps/cmake/2.8.12/bin:/software6/apps/mercurial/2.7.2/bin:/software6/apps/git/1.8.4.1/bin:/software6/apps/flex/2.5.37/bin:/software6/apps/moab/moab/bin:/software6/mpi/openmpi/1.6.5_intel/bin:/software6/compilers/intel/composer_xe_2013_sp1/bin:/software6/compilers/gcc/4.8.1/bin:/software6/apps/bison/3.0/bin:/software6/apps/make/3.82/bin:/software6/apps/automake/1.14/bin:/software6/apps/autoconf/2.69/bin:/software6/apps/m4/1.4.17/bin:/clumeq/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/var/cfengine/bin:/clumeq/bin:/software6/centos6-extra/bin:/software6/centos6-extra/usr/bin:/home/mboisson/bin:/home/mboisson/Scripts:/clumeq/staff/torque-moab-tools:/home/mboisson/Scripts/torque-moab
[mboisson@r103-n3 ~]$ which g++
/software6/compilers/gcc/4.8.1/bin/g++
[mboisson@r103-n3 ~]$ which gcc
/software6/compilers/gcc/4.8.1/bin/gcc
Note also that g++ does compile this example fine without adding /usr/include to the environment paths.
It does seem however that adding neither /usr/include in the CPATH nor the c++/include folder the CPLUS_INCLUDE_PATH work, for both the example and a C++11 code (I tested with <array>).
So it seems that not specifying paths works best, and setting CPLUS_INCLUDE_PATH messes with the default behavior. Does this statement seem correct ?
Maxime
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You are right ,using CPLUS_INCLUDE_PATH is not well supported in compilation of the headers.
Best ,Qiao
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page