Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Bastian_B_
New Contributor I
834 Views

Compatibility with GCC 7 + glibc 2.27

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
834 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
 

Bastian_B_
New Contributor I
834 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

Fabian_W_
Beginner
834 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

 

Bastian_B_
New Contributor I
834 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.

Fabian_W_
Beginner
834 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

 

Judith_W_Intel
Employee
834 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

 

Bastian_B_
New Contributor I
834 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

TimP
Black Belt
834 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. 

Fabian_W_
Beginner
834 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.

 

Bastian_B_
New Contributor I
834 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.

Fabian_W_
Beginner
834 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++?

 

 

 

Bastian_B_
New Contributor I
834 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).

Fabian_W_
Beginner
834 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}

Judith_W_Intel
Employee
834 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

Wenjie_L_Intel
Employee
834 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

 

 

Simmons__Stephen
Beginner
834 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