Package: libtool;
Reported by: Jeff Squyres <jsquyres <at> cisco.com>
Date: Thu, 20 Oct 2011 12:06:01 UTC
Severity: normal
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Larry Baker <baker <at> usgs.gov> To: bug-libtool <at> gnu.org Cc: Jeff Squyres <jsquyres <at> cisco.com> Subject: Re: [OMPI devel] make check fails for Intel 2011.6.233 (OpenMPI 1.4.3) Date: Tue, 8 Nov 2011 11:09:54 -0800
[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)]
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.