GNU bug report logs -
#9806
Fwd: [OMPI devel] make check fails for Intel 2011.6.233 (OpenMPI 1.4.3)
Previous Next
Reported by: Jeff Squyres <jsquyres <at> cisco.com>
Date: Thu, 20 Oct 2011 12:06:01 UTC
Severity: normal
Done: Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9806 in the body.
You can then email your comments to 9806 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-libtool <at> gnu.org:
bug#9806; Package
libtool.
(Thu, 20 Oct 2011 12:06:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Jeff Squyres <jsquyres <at> cisco.com>:
New bug report received and forwarded. Copy sent to
bug-libtool <at> gnu.org.
(Thu, 20 Oct 2011 12:06:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Libtool developers --
FYI. I don't know offhand if you're checking the intel compiler #defines for version numbers, but the following issue just came up on the Open MPI list: the intel 12.1.x compilers seem to have done terrible things to the version #defines. So we're passing along this info in case you need it.
See below.
Begin forwarded message:
> From: Larry Baker <baker <at> usgs.gov>
> Date: October 19, 2011 4:25:26 PM EDT
> To: Open MPI Developers <devel <at> open-mpi.org>
> Subject: Re: [OMPI devel] make check fails for Intel 2011.6.233 (OpenMPI 1.4.3)
> Reply-To: Open MPI Developers <devel <at> open-mpi.org>
>
> Here's what I get for the version no. macros from the Intel compilers I have installed on our cluster:
>
>> Intel V11.1.080
>>
>> $ icc -v
>> Version 11.1
>>
>> #define __ICC 1110
>> #define __INTEL_COMPILER 1110
>> #define __INTEL_COMPILER_BUILD_DATE 20101201
>>
>> Intel V2011.3.174
>>
>> $ icc -v
>> Version 12.0.3
>>
>> #define __ICC 1200
>> #define __INTEL_COMPILER 1200
>> #define __INTEL_COMPILER_BUILD_DATE 20110309
>>
>> Intel V2011.4.191
>>
>> $ icc -v
>> Version 12.0.4
>>
>> #define __ICC 1200
>> #define __INTEL_COMPILER 1200
>> #define __INTEL_COMPILER_BUILD_DATE 20110427
>>
>> Intel V2011.5.220
>>
>> $ icc -v
>> Version 12.0.5
>>
>> #define __ICC 1200
>> #define __INTEL_COMPILER 1200
>> #define __INTEL_COMPILER_BUILD_DATE 20110719
>>
>> Intel V2011.6.233
>>
>> $ icc -v
>> icc version 12.1.0 (gcc version 4.1.2 compatibility)
>>
>> #define __ICC 9999
>> #define __INTEL_COMPILER 9999
>> #define __INTEL_COMPILER_BUILD_DATE 20110811
>
> As Hubert mentioned, only the build date has a reliable value.
>
> Larry Baker
> US Geological Survey
> 650-329-5608
> baker <at> usgs.gov
>
> On 19 Oct 2011, at 11:45 AM, Larry Baker wrote:
>
>> I posted my findings about the bad version no. macros to the same thread that described the Intel V12.1 optimizer bug (http://software.intel.com/en-us/forums/showthread.php?t=87132). The response I got is:
>>
>>> Posted By: Hubert Haberstock (Intel)
>>> __________________________________________
>>>
>>> The build date is currently the only suitable macro. This allows to check for the Intel Compiler and for specific compiler versions. Makes sense? Regards, Hubert.
>>> __________________________________________
>>
>> That is contrary to what the online V12.1 documentation says. I'm going to find out what the previous versions do, then report this through my normal support channels. If the documentation is wrong, they should fix it; if the documentation is right, they should fix the compiler. (However, there will still be an errant V12.1.0 that reports itself as 9999, so use of the version no. macros will never be reliable without a hack to handle this errant case.) I'll report here what I find about the values of the version no. macros. It is probably better, though, that automake/libtool rely on the output of icc -v, since that seems to always result in a value that matches the version of the product (as opposed to #define __INTEL_COMPILER 9999 and #define __ICC 9999 from within the V12.1.0 compiler).
>>
>> Larry Baker
>> US Geological Survey
>> 650-329-5608
>> baker <at> usgs.gov
If you care, you can see the rest of the thread here:
http://www.open-mpi.org/community/lists/devel/2011/10/9791.php
--
Jeff Squyres
jsquyres <at> cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
Information forwarded
to
bug-libtool <at> gnu.org:
bug#9806; Package
libtool.
(Tue, 08 Nov 2011 19:18:02 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
FYI. This is a follow-up to Jeff Squyres' earlier note.
Intel release 2011.6.233 has a bug in the vectorizer that breaks
OpenMPI. The bug is fixed in Intel release 2011.7.256.
Both Intel release 2011.6.233 and 2011.7.256 identify themselves as
V12.1.0 using the -v command line option. (This bug has been reported.)
The only reliable way to distinguish the Intel compiler release is the
predefined __INTEL_COMPILER_BUILD_DATE macro.
Below are the compiler identification strings available from the Intel
2011.6.233 and 2011.7.256 compiler releases:
> [baker <at> hydra tmp]$ module list
> Currently Loaded Modulefiles:
> 1) modules 2) compilers/intel/2011.6.233
> [baker <at> hydra tmp]$ icc -v
> icc version 12.1.0 (gcc version 4.1.2 compatibility)
> [baker <at> hydra tmp]$ icc -E -dM junk.c | grep INTEL
> #define __INTEL_COMPILER 9999
> #define __INTEL_RTTI__ 1
> #define __INTEL_COMPILER_BUILD_DATE 20110811
> [baker <at> hydra tmp]$ module list
> Currently Loaded Modulefiles:
> 1) modules 2) compilers/intel/2011.7.256
> [baker <at> hydra tmp]$ icc -v
> icc version 12.1.0 (gcc version 4.1.2 compatibility)
> [baker <at> hydra tmp]$ icc -E -dM junk.c | grep INTEL
> #define __INTEL_COMPILER 1210
> #define __INTEL_RTTI__ 1
> #define __INTEL_COMPILER_BUILD_DATE 20111011
Larry Baker
US Geological Survey
650-329-5608
baker <at> usgs.gov
On 20 Oct 2011, at 5:03 AM, Jeff Squyres wrote:
> Libtool developers --
>
> FYI. I don't know offhand if you're checking the intel compiler
> #defines for version numbers, but the following issue just came up
> on the Open MPI list: the intel 12.1.x compilers seem to have done
> terrible things to the version #defines. So we're passing along
> this info in case you need it.
>
> See below.
>
> Begin forwarded message:
>
>> From: Larry Baker <baker <at> usgs.gov>
>> Date: October 19, 2011 4:25:26 PM EDT
>> To: Open MPI Developers <devel <at> open-mpi.org>
>> Subject: Re: [OMPI devel] make check fails for Intel 2011.6.233
>> (OpenMPI 1.4.3)
>> Reply-To: Open MPI Developers <devel <at> open-mpi.org>
>>
>> Here's what I get for the version no. macros from the Intel
>> compilers I have installed on our cluster:
>>
>>> Intel V11.1.080
>>>
>>> $ icc -v
>>> Version 11.1
>>>
>>> #define __ICC 1110
>>> #define __INTEL_COMPILER 1110
>>> #define __INTEL_COMPILER_BUILD_DATE 20101201
>>>
>>> Intel V2011.3.174
>>>
>>> $ icc -v
>>> Version 12.0.3
>>>
>>> #define __ICC 1200
>>> #define __INTEL_COMPILER 1200
>>> #define __INTEL_COMPILER_BUILD_DATE 20110309
>>>
>>> Intel V2011.4.191
>>>
>>> $ icc -v
>>> Version 12.0.4
>>>
>>> #define __ICC 1200
>>> #define __INTEL_COMPILER 1200
>>> #define __INTEL_COMPILER_BUILD_DATE 20110427
>>>
>>> Intel V2011.5.220
>>>
>>> $ icc -v
>>> Version 12.0.5
>>>
>>> #define __ICC 1200
>>> #define __INTEL_COMPILER 1200
>>> #define __INTEL_COMPILER_BUILD_DATE 20110719
>>>
>>> Intel V2011.6.233
>>>
>>> $ icc -v
>>> icc version 12.1.0 (gcc version 4.1.2 compatibility)
>>>
>>> #define __ICC 9999
>>> #define __INTEL_COMPILER 9999
>>> #define __INTEL_COMPILER_BUILD_DATE 20110811
>>
>> As Hubert mentioned, only the build date has a reliable value.
>>
>> Larry Baker
>> US Geological Survey
>> 650-329-5608
>> baker <at> usgs.gov
>>
>> On 19 Oct 2011, at 11:45 AM, Larry Baker wrote:
>>
>>> I posted my findings about the bad version no. macros to the same
>>> thread that described the Intel V12.1 optimizer bug (http://software.intel.com/en-us/forums/showthread.php?t=87132
>>> ). The response I got is:
>>>
>>>> Posted By: Hubert Haberstock (Intel)
>>>> __________________________________________
>>>>
>>>> The build date is currently the only suitable macro. This allows
>>>> to check for the Intel Compiler and for specific compiler
>>>> versions. Makes sense? Regards, Hubert.
>>>> __________________________________________
>>>
>>> That is contrary to what the online V12.1 documentation says. I'm
>>> going to find out what the previous versions do, then report this
>>> through my normal support channels. If the documentation is
>>> wrong, they should fix it; if the documentation is right, they
>>> should fix the compiler. (However, there will still be an errant
>>> V12.1.0 that reports itself as 9999, so use of the version no.
>>> macros will never be reliable without a hack to handle this errant
>>> case.) I'll report here what I find about the values of the
>>> version no. macros. It is probably better, though, that automake/
>>> libtool rely on the output of icc -v, since that seems to always
>>> result in a value that matches the version of the product (as
>>> opposed to #define __INTEL_COMPILER 9999 and #define __ICC 9999
>>> from within the V12.1.0 compiler).
>>>
>>> Larry Baker
>>> US Geological Survey
>>> 650-329-5608
>>> baker <at> usgs.gov
>
> If you care, you can see the rest of the thread here:
>
> http://www.open-mpi.org/community/lists/devel/2011/10/9791.php
>
> --
> Jeff Squyres
> jsquyres <at> cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#9806; Package
libtool.
(Tue, 17 Jun 2025 15:46:03 GMT)
Full text and
rfc822 format available.
Message #11 received at 9806 <at> debbugs.gnu.org (full text, mbox):
For the Intel OneAPI compiler 2024.0 we have for comparison:
mathar <at> mathar:~> /opt/apps/software/intel2024/oneapi/2024.0/bin/icx -E -dM t2.c | grep INTEL
#define __INTEL_CLANG_COMPILER 20240002
#define __INTEL_LLVM_COMPILER 20240002
mathar <at> mathar:~> /opt/apps/software/intel2024/oneapi/2024.0/bin/icx -v
Intel(R) oneAPI DPC++/C++ Compiler 2024.0.2 (2024.0.2.20231213)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/apps/software/intel2024/oneapi/compiler/2024.0/bin/compiler
Configuration file: /opt/apps/software/intel2024/oneapi/compiler/2024.0/bin/compiler/../icx.cfg
Found candidate GCC installation: /usr/lib64/gcc/x86_64-suse-linux/7
Selected GCC installation: /usr/lib64/gcc/x86_64-suse-linux/7
Candidate multilib: .;@m64
Selected multilib: .;@m64
Reply sent
to
Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>:
You have taken responsibility.
(Wed, 12 Nov 2025 16:49:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Jeff Squyres <jsquyres <at> cisco.com>:
bug acknowledged by developer.
(Wed, 12 Nov 2025 16:49:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 9806-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
The reported bug was fixed in an OpenMPI release. Also, Libtool does not
check #defines for OpenMPI, so closing.
--
Ileana Dumitrescu
GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
[OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, attachment)]
[OpenPGP_signature.asc (application/pgp-signature, attachment)]
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 11 Dec 2025 12:24:16 GMT)
Full text and
rfc822 format available.
This bug report was last modified 16 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.