Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Maxime_B_
Beginner
532 Views

Errors when compiling with GNU Standard C++ Library

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]

0 Kudos
19 Replies
Maxime_B_
Beginner
532 Views

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.

SergeyKostrov
Valued Contributor II
532 Views

Take a look at a declaration: ... typedef unsigned short fexcept_t; ... in the fenv.h. If it is missed then this is the bug. Or, search for that declaration in all header files to confirm that it is Not declared.
SergeyKostrov
Valued Contributor II
532 Views

Take a look at a declaration: ... typedef unsigned short fexcept_t; ... in the fenv.h. If it is missed then this is the bug. Or, search for that declaration in all header files to confirm that it is Not declared.
Maxime_B_
Beginner
532 Views

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]

Maxime_B_
Beginner
532 Views

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

Maxime_B_
Beginner
532 Views

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

Maxime_B_
Beginner
532 Views

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

TimP
Black Belt
532 Views

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.

Maxime_B_
Beginner
532 Views

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).

TimP
Black Belt
532 Views

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.

SergeyKostrov
Valued Contributor II
532 Views

>>...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 ? Use ... -print-search-dirs Display the directories in the compiler's search path ... to verify it and I usually use ... -B Add to the compiler's search paths ... when some path to a folder needs to be added.
Maxime_B_
Beginner
532 Views

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

SergeyKostrov
Valued Contributor II
532 Views

Did you try to use -v option at the end of your command line?
Maxime_B_
Beginner
532 Views

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 ?

QIAOMIN_Q_
New Contributor I
532 Views

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

Maxime_B_
Beginner
532 Views

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

QIAOMIN_Q_
New Contributor I
532 Views

You are right ,using CPLUS_INCLUDE_PATH is not well supported in compilation of the headers.

Best ,Qiao

SergeyKostrov
Valued Contributor II
532 Views

>>...[mboisson@r103-n3 ~]$ icpc -print-search-dirs -v >>icpc version 14.0.1 (gcc version 4.8.0 compatibility) I see that icpc displays the version information instead of different default and non-default settings, paths, etc.
SergeyKostrov
Valued Contributor II
532 Views

This is what I've expected to see when -v option is used at the end of a command line: ... Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=c:/worklib/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto --enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc ,obj-c++,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-vers ion-specific-runtime-libs --with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mi ngw32-src/bld --with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp --enable-thr eads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/mingw Thread model: win32 gcc version 4.8.1 (GCC) COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' c:/worklib/mingw/bin/../libexec/gcc/mingw32/4.8.1/cc1plus.exe -quiet -v -iprefix c:\worklib\mingw\bin\../lib/gcc/mi ngw32/4.8.1/ Test.cpp -quiet -dumpbase Test.cpp -mtune=generic -march=pentiumpro -auxbase Test -version -o C:\DOCUME ~1\Admin\LOCALS~1\Temp\cceKDbUV.s GNU C++ (GCC) version 4.8.1 (mingw32) compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=130982 ignoring duplicate directory "c:/worklib/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/include/c++" ignoring duplicate directory "c:/worklib/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/include/c++/mingw32" ignoring duplicate directory "c:/worklib/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/include/c++/backward" ignoring duplicate directory "c:/worklib/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/include" ignoring nonexistent directory "e:/p/giaw/mingw/include" ignoring nonexistent directory "/mingw/include" ignoring duplicate directory "c:/worklib/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/include-fixed" ignoring duplicate directory "c:/worklib/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/../../../../mingw32/include" ignoring nonexistent directory "/mingw/include" #include "..." search starts here: #include <...> search starts here: c:\worklib\mingw\bin\../lib/gcc/mingw32/4.8.1/include/c++ c:\worklib\mingw\bin\../lib/gcc/mingw32/4.8.1/include/c++/mingw32 c:\worklib\mingw\bin\../lib/gcc/mingw32/4.8.1/include/c++/backward c:\worklib\mingw\bin\../lib/gcc/mingw32/4.8.1/include c:\worklib\mingw\bin\../lib/gcc/mingw32/4.8.1/../../../../include c:\worklib\mingw\bin\../lib/gcc/mingw32/4.8.1/include-fixed c:\worklib\mingw\bin\../lib/gcc/mingw32/4.8.1/../../../../mingw32/include End of search list. GNU C++ (GCC) version 4.8.1 (mingw32) compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=130982 Compiler executable checksum: 6d99dac674bcce78dd6fce9da190f423 COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' c:/worklib/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/as.exe -v -o C:\DOCUME~1\Admin\LOCALS~1\Temp\ ccp1LBpm.o C:\DOCUME~1\Admin\LOCALS~1\Temp\cceKDbUV.s GNU assembler version 2.23.2 (mingw32) using BFD version (GNU Binutils) 2.23.2 COMPILER_PATH=c:/worklib/mingw/bin/../libexec/gcc/mingw32/4.8.1/;c:/worklib/mingw/bin/../libexec/gcc/;c:/worklib/min gw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ LIBRARY_PATH=c:/worklib/mingw/bin/../lib/gcc/mingw32/4.8.1/;c:/worklib/mingw/bin/../lib/gcc/;c:/worklib/mingw/bin/.. /lib/gcc/mingw32/4.8.1/../../../../mingw32/lib/;c:/worklib/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../ COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' c:/worklib/mingw/bin/../libexec/gcc/mingw32/4.8.1/collect2.exe -Bdynamic -u ___register_frame_info -u ___deregister _frame_info c:/worklib/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/lib/crt2.o c:/worklib/mingw/bin/../lib /gcc/mingw32/4.8.1/crtbegin.o -Lc:/worklib/mingw/bin/../lib/gcc/mingw32/4.8.1 -Lc:/worklib/mingw/bin/../lib/gcc -Lc: /worklib/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/lib -Lc:/worklib/mingw/bin/../lib/gcc/mingw32/4.8.1/ ../../.. C:\DOCUME~1\Admin\LOCALS~1\Temp\ccp1LBpm.o -lstdc++ -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt - ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt c:/worklib/mingw/bin/. ./lib/gcc/mingw32/4.8.1/crtend.o ...
Reply