Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.

Compatibility with GCC 7 + glibc 2.27

Bastian_B_
New Contributor I
4,478 Views

Hello,

I'm using the Intel Compiler 2018 Update 2 on Linux x86_64 (Arch Linux). Arch Linux's default compiler and glibc versions are GCC 7.3.1 and glibc 2.27 at the moment. In

https://software.intel.com/en-us/comment/1915553#

I reported an incompatibility of ICC 17 when used with GCC 7 + glibc 2.26. This incompatibility is now fixed, but similar problems have now arisen with glibc 2.27. glibc 2.27 adds a few function declarations for the _Float32, _Float32x, _Float64, _Float64x, ... types in case the corresponding __HAVE_FLOATXYZ macros are defined, for example:
 

#if __HAVE_FLOAT32 && __GLIBC_USE (IEC_60559_TYPES_EXT) 
extern _Float32 strtof32 (const char *__restrict __nptr, 
                         char **__restrict __endptr)
    __THROW __nonnull ((1));
#endif


This fails to compile with Intel Compiler 2018 Update 2, when using GCC 7. GCC 7 is needed because one of its headers will define the __HAVE_FLOATXYZ macros (see https://gcc.gnu.org/gcc-7/changes.html, search for Float32).

Another unrelated incompatibility with glibc 2.27 is this part in the Intel Compiler math.h:

#if (!defined(__linux__) || !defined(__USE_MISC)) && !defined(__NetBSD__) || defined (__PURE_INTEL_C99_HEADERS__)
typedef enum ___LIB_VERSIONIMF_TYPE {
     _IEEE_ = -1    /\* IEEE-like behavior    *\/
    ,_SVID_         /\* SysV, Rel. 4 behavior *\/
    ,_XOPEN_        /\* Unix98                *\/
    ,_POSIX_        /\* Posix                 *\/
    ,_ISOC_         /\* ISO C9X               *\/
} _LIB_VERSIONIMF_TYPE;
#else
# define _LIB_VERSIONIMF_TYPE _LIB_VERSION_TYPE
#endif

_LIBIMF_EXTERN_C _LIB_VERSIONIMF_TYPE _LIBIMF_PUBVAR _LIB_VERSIONIMF;

This part of math.h causes a compilation failure because glibc 2.27 removed the '_LIB_VERSION_TYPE' enum (https://sourceware.org/git/?p=glibc.git;a=commit;h=813378e9fe17e029caf627cab76fe23eb46815fa).


I realize that the current version of the compiler does not officially support glibc 2.27, but it would be nice to have this fixed in a future release, which is why I'm reporting these incompatibilities here.

16 Replies
Judith_W_Intel
Employee
4,478 Views

 

Hi,

Hi Bastian

Can you explain how the use of the __LIB_VERSION_TYPE macro (that is now undefined) is causing harm in math.h?

This is the relevant conditional:

#if (!defined(__linux__) || !defined(__USE_MISC)) && !defined(__NetBSD__) || defined (__PURE_INTEL_C99_HEADERS__)
typedef enum ___LIB_VERSIONIMF_TYPE {
     _IEEE_ = -1    /* IEEE-like behavior    */
    ,_SVID_         /* SysV, Rel. 4 behavior */
    ,_XOPEN_        /* Unix98                */
    ,_POSIX_        /* Posix                 */
    ,_ISOC_         /* ISO C9X               */
} _LIB_VERSIONIMF_TYPE;
#else
# define _LIB_VERSIONIMF_TYPE _LIB_VERSION_TYPE
#endif

Are you on a system where __USE_MISC or __NetBSD__ is defined?

I wrote a test case which just includes <math.h> and it compiles for me on RHEL7 using the latest GNU headers.

 

thanks

Judy
 

0 Kudos
Bastian_B_
New Contributor I
4,478 Views

Hey Judy,

Yes I'm on Linux and __USE_MISC is set here. The compilation error is:

$ cat foo.c
#include <math.h>

$ icpc -c -o foo foo.c
In file included from foo.c(1):
/opt/intel/compilers_and_libraries_2018.2.199/linux/compiler/include/math.h(1230): error: identifier "_LIB_VERSION_TYPE" is undefined
 _LIBIMF_EXTERN_C _LIB_VERSIONIMF_TYPE _LIBIMF_PUBVAR _LIB_VERSIONIMF;
                  ^

compilation aborted for foo.c (code 2)

Thanks
Bastian

0 Kudos
Fabian_W_
Beginner
4,478 Views

Please see also https://software.intel.com/en-us/forums/intel-c-compiler/topic/760979#comment-1921433

In /usr/inlcude/math.h there is no _LIB_VERSION_TYPE

 

0 Kudos
Bastian_B_
New Contributor I
4,478 Views

Yes thanks for the reference. The enum was removed in glibc 2.27 (https://sourceware.org/git/?p=glibc.git;a=commit;h=813378e9fe17e029caf627cab76fe23eb46815fa) as I wrote above.

0 Kudos
Fabian_W_
Beginner
4,478 Views

I get the Float32 issue when compiling hdf5 1.8.12 

In file included from /usr/include/math.h(389),
                 from /home/opt/intel/compilers_and_libraries_2018.1.163/linux/compiler/include/math.h(173),
                 from *hdf5/src/H5private.h(56),
                 from *hdf5/src/H5make_libsettings.c(46):
/usr/include/bits/mathcalls.h(125): error: identifier "_Float32" is undefined
  __MATHCALL (logb,, (_Mdouble_ __x));
  ^

Is there a suggestion for a fix/workaround? I'll check also with a newer hdf5. Several other external libs compile with Intel under glibc 2.27

Note that I found a dirty workaround for the LIB_VERSION issue: https://software.intel.com/en-us/forums/intel-c-compiler/topic/760979#comment-1921437

 

0 Kudos
Judith_W_Intel
Employee
4,478 Views

 

Hi Bastian,

I am trying to reproduce the problem. I don't see it on Red Hat Linux.

It looks like __USE_MISC is only defined in features.h under these conditions:

#if defined _BSD_SOURCE || defined _SVID_SOURCE
# define __USE_MISC     1
#endif

__USE_MISC --> Define things common to BSD and System V Unix.

So please tell me what Linux system you are on. Or else please tell me the results of the command "/proc/version".

thanks again,

Judy

 

0 Kudos
Bastian_B_
New Contributor I
4,478 Views

Hey Judith,

I don't think Red Hat Linux has glibc 2.27. To reproduce the issues mentioned in the OP you will need a system which has both GCC 7+ (for the FloatX  type problem) and glibc 2.27+ (for both the FloatX problem and the VERSION_TYPE problem). I think none of the systems which are officially supported by the compiler have this very recent combination of GCC and glibc.

I am on Arch Linux (which isn't officially supported, so I'm not complaining).

I'm just hoping to draw the attention of the developers to this problem so that Intel 19 will be compatible with glibc 2.27+ + GCC 7+ again.

Thanks for your help!
Bastian

0 Kudos
TimP
Honored Contributor III
4,478 Views

If you are looking for a feature to appear in the 2019 compiler, you shouldn't leave us in doubt as to whether you are trying the 2019 beta test. Admittedly this hasn't been announced in the expected ways. apparently the usual policy of not discussing details on this forum is in effect. Unfortunately,  although I submitted my regression report by the specified method, ending up at supporttickets.intel.com, and got a fairly quick response, the support people don't appear to be aware of the public beta test.  If this doesn't change, we may yet need to discuss it here. 

0 Kudos
Fabian_W_
Beginner
4,478 Views

My reported issue above about

"/usr/include/bits/mathcalls.h(125): error: identifier "_Float32" is undefined"

happens with Intel 2018 update 1 and update 2 on openSUSE tumbleweed. This has glibc 2.27 meanwhile:

ldd --version
ldd (GNU libc) 2.27

I'm grateful for any suggestions on how to fix this. I assume this are some lines in
*/intel/compilers_and_libraries_2018.1.163/linux/compiler/include/math.h

and I'm happy to test and report such a suggestion.

 

0 Kudos
Bastian_B_
New Contributor I
4,478 Views

Fabian,

here is what I think is happening. The GCC compiler added support for new types _Float32, _Float64, ... in version 7. This means that the compiler can now parse this code:

_Float32 a;

which was not possible before. Now glibc 2.26 and 2.27 added function stubs which make use of these new types. In order to stay compatible with GCC before 7.0 they have added compatibility code to 'floatn.h' and 'floatn-common.h' such as this:

#  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
typedef float _Float32;
#  endif


And this is where the incompatibility with the Intel Compiler comes: ICC advocates the same version of GCC as GCC itself would (it defines __GNUC__ and __GNUC_MINOR__ to same numbers). This means that glibc thinks that the compiler understand _Float32 when in fact the Intel Compiler does not.

This was fixed for _Float128 in ICC 18 Update 2 which restored the compatibility with glibc 2.26 since that versin of glibc did not declare any function stubs with _Float32 or _Float64. But glibc 2.27 does and that is why this problem reappeared.

I think you can work around the problem by manually defining _Float32 to "float", _Float64 to "long double" in your compiler invocation.

The real fix would be to wait until Intel Compiler supports _Float32, _Float64, ... (also the ...x variants). At the moment this is not the case even for the 2019 Beta release.

0 Kudos
Fabian_W_
Beginner
4,478 Views

Bastian, than you for your response.

I added

typedef float _Float32;
typedef long double _Float64;
typedef double _Float32x;
typedef long double _Float64x;

before the two locations of #include_next <math.h> in */intel/compilers_and_libraries_2018.1.163/linux/compiler/include/math.h

and that helped for the location mentioned above, where math.h is included.

Now the error appears as

hdf5/src/hdf5/src/H5FDmulti.c(28):
/usr/include/stdlib.h(140): error: identifier "_Float32" is undefined
  extern _Float32 strtof32 (const char *__restrict __nptr,

Where no math.h is included but only

#include <assert.h>
#include <stdlib.h>

What did you mean with "manually defining ... in compiler invokation"?
Strange enough, this appears only when compiling hdf5, but it works without any typedefs with my own code and all other libraries. Possibly because hdf5 is C and my stuff C++?

 

 

 

0 Kudos
Bastian_B_
New Contributor I
4,478 Views

The _Float32/64(x) problem is not specific to math.h. In fact as you have found there are new function stubs in stdlib.h and also in wchar.h.

What i meant with 'manually defining in compiler invocation' was to add '-D_Float32=float' and '-D_Float64="long double"' to your compiler flags (try CFLAGS, this should influence the hdf5 build also).

And yes, as you can see from the snippet above C++ code will not have the problem (because __cplusplus is defined).

0 Kudos
Fabian_W_
Beginner
4,478 Views

Thank you, that works!

As I have the issue only with the hdf5 library and I build it via cmake as external package, it is sufficient to set there

set(hdf5_c_flags "-D_Float32=float -D_Float64='long double' -D_Float32x=double -D_Float64x='long double' ${whatever_default_c_flags_you_have}")

-DCMAKE_C_FLAGS:STRING=${hdf5_c_flags}

0 Kudos
Judith_W_Intel
Employee
4,478 Views

 

I was finally able to get access to a Fedora28 system which has the glibc version 2.27 headers and was able to reproduce both problems.

I submitted cmplrs-50184 for the math.h problem and cmplrs-50380 for the stdlib.h problem. 

Thanks for reporting these and we will get fixes for these as soon as we are able.

Judy

0 Kudos
Wenjie_L_Intel
Employee
4,478 Views

This issue could be reproduced on Ubuntu 18.04 too.

With GCC7 + glibc2.27: stdlib.h error: identifier "_Float32/_Float64 " is undefined

With GCC6 +  glibc2.27: math.h: error: identifier "_LIB_VERSION_TYPE" is undefined

 

 

0 Kudos
Simmons__Stephen
Beginner
4,478 Views

I also had this on Ubuntu 18.04/glibc2.27, when compiling numpy with ICC 18 update 3.

stdlib.h error: identifiers _Float32/_Float64/_Float32x/_Float64x undefined.
-> solution is to add this line to the ICC flags at L64 of numpy/distutils/intelcompiler.py:
'-D_Float32=float -D_Float32x=float -D_Float64=\\"long double\\" -D_Float64x=\\"long double\\" '
The quoting is needed because just a single " gets stripped out, making the definition -D_Float64=long, with the now unquoted double treated as the name of a file to compile.

math.h: error: identifier "_LIB_VERSION_TYPE" is undefined.
-> solution is in Fabian W's link above: https://software.intel.com/en-us/forums/intel-c-compiler/topic/760979#comment-1921437

 

 

 

0 Kudos
Reply