Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] make check fails for Intel 2011.6.233 (OpenMPI 1.4.3)
From: Larry Baker (baker_at_[hidden])
Date: 2011-10-19 16:25:26


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_[hidden]

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_[hidden]
>
> On 19 Oct 2011, at 10:47 AM, Jeff Squyres wrote:
>
>> Did this get reported to the Intel compiler support people?
>>
>>
>> On Oct 19, 2011, at 8:24 AM, George Bosilca wrote:
>>
>>> Thanks Larry,
>>>
>>> Will forward this info upstream.
>>>
>>> george.
>>>
>>> On Oct 18, 2011, at 21:56 , Larry Baker wrote:
>>>
>>>> George,
>>>>
>>>> Thanks for the update. FYI, here's all the version numbers
>>>> reported by the compiler releases I have installed:
>>>>
>>>>> [baker_at_hydra ~]$ module load compilers/intel/11.1.080
>>>>> [baker_at_hydra ~]$ icc -v
>>>>> Version 11.1
>>>>> [baker_at_hydra ~]$ module unload compilers/intel/11.1.080
>>>>
>>>>> [baker_at_hydra ~]$ module load compilers/intel/2011.3.174
>>>>> [baker_at_hydra ~]$ icc -v
>>>>> Version 12.0.3
>>>>> [baker_at_hydra ~]$ module unload compilers/intel/2011.3.174
>>>>
>>>>> [baker_at_hydra ~]$ module load compilers/intel/2011.4.191
>>>>> [baker_at_hydra ~]$ icc -v
>>>>> Version 12.0.4
>>>>> [baker_at_hydra ~]$ module unload compilers/intel/2011.4.191
>>>>
>>>>> [baker_at_hydra ~]$ module load compilers/intel/2011.5.220
>>>>> [baker_at_hydra ~]$ icc -v
>>>>> Version 12.0.5
>>>>> [baker_at_hydra ~]$ module unload compilers/intel/2011.5.220
>>>>
>>>>> [baker_at_hydra ~]$ module load compilers/intel/2011.6.233
>>>>> [baker_at_hydra ~]$ icc -v
>>>>> icc version 12.1.0 (gcc version 4.1.2 compatibility)
>>>>> [baker_at_hydra ~]$ module unload compilers/intel/2011.6.233
>>>>
>>>> Another problem I found with the Intel 12.1.0 compiler: I started
>>>> to look at adding a test for the Intel compiler version around
>>>> the #pragma that disables optimization for OpenMPI and I found
>>>> the __ICC and __INTEL_COMPILER predefined macros (compiler
>>>> version no.) are not properly defined:
>>>>
>>>> $ icc -E -dD hello.c | grep __INTEL_COMPILER
>>>> #define __INTEL_COMPILER 9999
>>>> #define __INTEL_COMPILER_BUILD_DATE 20110811
>>>>
>>>> $ icc -E -dD hello.c | grep __ICC
>>>> #define __ICC 9999
>>>>
>>>> $ icc -v
>>>> icc version 12.1.0 (gcc version 4.1.2 compatibility)
>>>>
>>>> I do not know if there is code in OpenMPI that looks at __ICC and
>>>> __INTEL_COMPILER, but that could cause problems. (Pass this on
>>>> upstream to the libtool people?)
>>>>
>>>> Larry Baker
>>>> US Geological Survey
>>>> 650-329-5608
>>>> baker_at_[hidden]
>>>>
>>>> On 17 Oct 2011, at 8:18 PM, George Bosilca wrote:
>>>>
>>>>> Larry,
>>>>>
>>>>> Sorry for not updating this thread. The issue was identified and
>>>>> fixed by Rainer in r25290 (https://svn.open-mpi.org/trac/ompi/changeset/25290
>>>>> ). Please read the comments and the linked thread on the Intel
>>>>> forum for more info about.
>>>>>
>>>>> I couldn't find a trace of this being fixed in the 1.4 series,
>>>>> so I would wait upgrading until this issue gets resolved.
>>>>>
>>>>> Thanks,
>>>>> george.
>>>>>
>>>>> On Oct 17, 2011, at 23:00 , Larry Baker wrote:
>>>>>
>>>>>> George,
>>>>>>
>>>>>> I have not had time to look over the 1.4.3 make check failure
>>>>>> for Intel 2011.6.233 compilers. Have you?
>>>>>>
>>>>>> I had planned to get 1.4.3 compiled on all six of our compilers
>>>>>> using the latest compiler releases. I was putting off
>>>>>> upgrading to 1.4.4 or 1.5.x until after that to minimize the
>>>>>> number of things that could go wrong. Do you recommend
>>>>>> otherwise?
>>>>>>
>>>>>> Larry Baker
>>>>>> US Geological Survey
>>>>>> 650-329-5608
>>>>>> baker_at_[hidden]
>>>>>>
>>>>>> On 7 Oct 2011, at 6:46 PM, George Bosilca wrote:
>>>>>>
>>>>>>> The may_alias attribute was part of a forward-looking
>>>>>>> attribute checking, at a time where few compiler supported
>>>>>>> them. This explains why they are not widely used in the
>>>>>>> library itself. Moreover, as they do not affect the
>>>>>>> compilation itself (as your test highlights this is not the
>>>>>>> issue with the icc 2011.6.233 compiler), there is no urge to
>>>>>>> remove the may_alias support.
>>>>>>>
>>>>>>> I just got that particular version of the compiler installed
>>>>>>> on one of our machines. I'll give it a try over the weekend.
>>>>>>>
>>>>>>> george.
>>>>>>>
>>>>>>> On Oct 7, 2011, at 20:21 , Larry Baker wrote:
>>>>>>>
>>>>>>>> The test for the __may_alias_ attribute uses the following
>>>>>>>> short code snippet:
>>>>>>>>
>>>>>>>>> int * p_value __attribute__ ((__may_alias__));
>>>>>>>>> int
>>>>>>>>> main ()
>>>>>>>>> {
>>>>>>>>>
>>>>>>>>> ;
>>>>>>>>> return 0;
>>>>>>>>> }
>>>>>>>>
>>>>>>>> Indeed, for Intel 2011 compilers prior to 2011.6.233, this
>>>>>>>> results in a warning:
>>>>>>>>
>>>>>>>>> root_at_hydra openmpi-1.4.3]# module load compilers/intel/
>>>>>>>>> 2011.5.220
>>>>>>>>> [root_at_hydra openmpi-1.4.3]# icc -c may_alias_test.c
>>>>>>>>> may_alias_test.c(123): warning #1292: attribute
>>>>>>>>> "__may_alias__" ignored
>>>>>>>>> int * p_value __attribute__ ((__may_alias__));
>>>>>>>>> ^
>>>>>>>>>
>>>>>>>>> [root_at_hydra openmpi-1.4.3]# module unload compilers/intel/
>>>>>>>>> 2011.5.220
>>>>>>>>
>>>>>>>>> [root_at_hydra openmpi-1.4.3]# module load compilers/intel/
>>>>>>>>> 2011.6.233
>>>>>>>>> [root_at_hydra openmpi-1.4.3]# icc -c may_alias_test.c
>>>>>>>>
>>>>>>>> I modified ./configure to force
>>>>>>>>
>>>>>>>>> ompi_cv___attribute__may_alias=0
>>>>>>>>
>>>>>>>> Then I compiled and tested the library. Unfortunately, the
>>>>>>>> results were exactly the same:
>>>>>>>>
>>>>>>>>> make check-TESTS
>>>>>>>>> make[3]: Entering directory `/state/partition1/root/src/
>>>>>>>>> openmpi-1.4.3/test/datatype'
>>>>>>>>> /bin/sh: line 4: 26326 Segmentation fault ${dir}$tst
>>>>>>>>> FAIL: checksum
>>>>>>>>> /bin/sh: line 4: 26359 Segmentation fault ${dir}$tst
>>>>>>>>> FAIL: position
>>>>>>>>> ========================================================
>>>>>>>>> 2 of 2 tests failed
>>>>>>>>> Please report to http://www.open-mpi.org/community/help/
>>>>>>>>> ========================================================
>>>>>>>>
>>>>>>>> I could not find any use of the may_alias attribute, other
>>>>>>>> than in a #define in opal/include/opal_config_bottom.h. Is
>>>>>>>> OMPI_HAVE_ATTRIBUTE_MAY_ALIAS just cruft that can be removed?
>>>>>>>>
>>>>>>>> Larry Baker
>>>>>>>> US Geological Survey
>>>>>>>> 650-329-5608
>>>>>>>> baker_at_[hidden]
>>>>>>>>
>>>>>>>> On 7 Oct 2011, at 11:08 AM, Larry Baker wrote:
>>>>>>>>
>>>>>>>>> I ran into a problem this past week trying to upgrade our
>>>>>>>>> OpenMPI 1.4.3 for the latest Intel 2011 compiler, 2011.6.233.
>>>>>>>>>
>>>>>>>>> make check fails with Segmentation Fault errors:
>>>>>>>>>
>>>>>>>>>> [root_at_hydra openmpi-1.4.3]# tail -20 ../openmpi-1.4.3-check-
>>>>>>>>>> intel.6.233.log
>>>>>>>>>> /bin/sh ../../libtool --tag=CC --mode=link icc -DNDEBUG -
>>>>>>>>>> g -O3 -finline-functions -fno-strict-aliasing -restrict -
>>>>>>>>>> pthread -fvisibility=hidden -shared-intel -export-dynamic -
>>>>>>>>>> shared-intel -o ddt_pack ddt_pack.o ../../ompi/libmpi.la -
>>>>>>>>>> lnsl -lutil
>>>>>>>>>> libtool: link: icc -DNDEBUG -g -O3 -finline-functions -fno-
>>>>>>>>>> strict-aliasing -restrict -pthread -fvisibility=hidden -
>>>>>>>>>> shared-intel -shared-intel -o .libs/ddt_pack ddt_pack.o -
>>>>>>>>>> Wl,--export-dynamic ../../ompi/.libs/libmpi.so /usr/local/
>>>>>>>>>> src/openmpi-1.4.3/orte/.libs/libopen-rte.so /usr/local/src/
>>>>>>>>>> openmpi-1.4.3/opal/.libs/libopen-pal.so -ldl -lnsl -lutil -
>>>>>>>>>> pthread -Wl,-rpath -Wl,/usr/local/lib
>>>>>>>>>> make[3]: Leaving directory `/state/partition1/root/src/
>>>>>>>>>> openmpi-1.4.3/test/datatype'
>>>>>>>>>> make check-TESTS
>>>>>>>>>> make[3]: Entering directory `/state/partition1/root/src/
>>>>>>>>>> openmpi-1.4.3/test/datatype'
>>>>>>>>>> /bin/sh: line 4: 6322 Segmentation fault ${dir}$tst
>>>>>>>>>> FAIL: checksum
>>>>>>>>>> /bin/sh: line 4: 6355 Segmentation fault ${dir}$tst
>>>>>>>>>> FAIL: position
>>>>>>>>>> ========================================================
>>>>>>>>>> 2 of 2 tests failed
>>>>>>>>>> Please report to http://www.open-mpi.org/community/help/
>>>>>>>>>> ========================================================
>>>>>>>>>> make[3]: *** [check-TESTS] Error 1
>>>>>>>>>> make[3]: Leaving directory `/state/partition1/root/src/
>>>>>>>>>> openmpi-1.4.3/test/datatype'
>>>>>>>>>> make[2]: *** [check-am] Error 2
>>>>>>>>>> make[2]: Leaving directory `/state/partition1/root/src/
>>>>>>>>>> openmpi-1.4.3/test/datatype'
>>>>>>>>>> make[1]: *** [check-recursive] Error 1
>>>>>>>>>> make[1]: Leaving directory `/state/partition1/root/src/
>>>>>>>>>> openmpi-1.4.3/test'
>>>>>>>>>> make: *** [check-recursive] Error 1
>>>>>>>>>
>>>>>>>>> Before trying to track down the problem, I thought I'd
>>>>>>>>> describe what I see here in case someone recognizes what
>>>>>>>>> might be happening.
>>>>>>>>>
>>>>>>>>> We have been using OpenMPI 1.4.3 compiled with the Intel
>>>>>>>>> 2011.3.174 compiler. I've updated the Intel 2011 compilers
>>>>>>>>> as they have come out with new versions: 2011.4.191,
>>>>>>>>> 2011.5.220, and now 2011.6.233. However, I've not
>>>>>>>>> recompiled OpenMPI 1.4.3 until now.
>>>>>>>>>
>>>>>>>>> Since the original compilation of OpenMPI 1.4.3 with the
>>>>>>>>> Intel 2011.3.174 compilers, I have installed libnuma and
>>>>>>>>> libnuma-devel RPMs on our cluster front end. I noticed that
>>>>>>>>> changed the OpenMPI 1.4.3 ./configure output. To test that
>>>>>>>>> this was not the cause of the problem, I recompiled OpenMPI
>>>>>>>>> 1.4.3 using both the CentOS/Rocks GNU compilers and the
>>>>>>>>> Intel 2011.3.174 compilers. They both passed all the make
>>>>>>>>> check tests.
>>>>>>>>>
>>>>>>>>> To find out when this problem first occurs, I systematically
>>>>>>>>> configured, compiled, and checked OpenMPI 1.4.3 with all
>>>>>>>>> four versions of the Intel 2011 compilers we have. We use
>>>>>>>>> the modules package to load the compiler environment:
>>>>>>>>>
>>>>>>>>>> [root_at_hydra openmpi-1.4.3]# env | grep /opt/intel
>>>>>>>>>> LD_LIBRARY_PATH=/opt/intel/composer_xe_2011_sp1.6.233/
>>>>>>>>>> compiler/lib/intel64:/opt/intel/composer_xe_2011_sp1.6.233/
>>>>>>>>>> mkl/lib/intel64
>>>>>>>>>> PATH=/opt/intel/composer_xe_2011_sp1.6.233/bin/intel64:/usr/
>>>>>>>>>> kerberos/sbin:/usr/kerberos/bin:/usr/java/latest/bin:/usr/
>>>>>>>>>> local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/
>>>>>>>>>> opt/eclipse:/opt/ganglia/bin:/opt/ganglia/sbin:/opt/maui/
>>>>>>>>>> bin:/opt/torque/bin:/opt/torque/sbin:/opt/rocks/bin:/opt/
>>>>>>>>>> rocks/sbin:/root/bin
>>>>>>>>>
>>>>>>>>> Here's the steps I use to make and test OpenMPI 1.4.3 (I use
>>>>>>>>> a patched version to accommodate the six compilers we have;
>>>>>>>>> I've submitted those patches here in the past):
>>>>>>>>>
>>>>>>>>>> # cd /usr/local/src
>>>>>>>>>> # tar -xjf openmpi-1.4.3-patched.tar.bz2
>>>>>>>>>> # cd openmpi-1.4.3
>>>>>>>>>> # module load compilers/intel/2011.6.233
>>>>>>>>>> # ./configure >../openmpi-1.4.3-configure-intel.6.233.log
>>>>>>>>>> 2>&1 --with-tm --with-openib --without-valgrind --without-
>>>>>>>>>> udapl --enable-contrib-no-build=vt --with-wrapper-ldflags="-
>>>>>>>>>> shared-intel" CC="icc" CFLAGS="-g -O3" CXX="icpc"
>>>>>>>>>> CXXFLAGS="-g -O3" FC="ifort" FCFLAGS="-g -O3" F77="ifort"
>>>>>>>>>> FFLAGS="-g -O3" LDFLAGS="-shared-intel"
>>>>>>>>>> # make >../openmpi-1.4.3-make-intel.6.233.log 2>&1
>>>>>>>>>> # make check >../openmpi-1.4.3-check-intel.6.233.log 2>&1
>>>>>>>>>
>>>>>>>>> (When I generate the OpenMPI 1.4.3 library we actually use,
>>>>>>>>> I also add a --prefix. But, that complicates diff's of the
>>>>>>>>> stdout files for these steps, so it is not used here. Thus,
>>>>>>>>> I do NOT proceed to make install any of these libraries.)
>>>>>>>>>
>>>>>>>>> The three earlier versions of the Intel 2011 compilers all
>>>>>>>>> pass the make check tests. When I compare the ./configure
>>>>>>>>> stdout files, they are all identical. However, the ./
>>>>>>>>> configure stdout file for the Intel 2011.6.233 compilers has
>>>>>>>>> one difference:
>>>>>>>>>
>>>>>>>>>> [root_at_hydra openmpi-1.4.3]# diff ../openmpi-1.4.3-configure-
>>>>>>>>>> intel.{5.220,6.233}.log
>>>>>>>>>> 178c178
>>>>>>>>>> < checking for __attribute__(may_alias)... no
>>>>>>>>>> ---
>>>>>>>>>>> checking for __attribute__(may_alias)... yes
>>>>>>>>>
>>>>>>>>> That is obviously where I will start looking for the source
>>>>>>>>> of the problem.
>>>>>>>>>
>>>>>>>>> Maybe someone reading this list knows what the purpose of
>>>>>>>>> that test is, whether the Intel 2011 compilers are expected
>>>>>>>>> to have this feature enabled, and whether the code this
>>>>>>>>> enables can cause this problem if the Intel 2011.6.233
>>>>>>>>> compilers do not fully support whatever this test is
>>>>>>>>> intended to discern.
>>>>>>>>>
>>>>>>>>> Larry Baker
>>>>>>>>> US Geological Survey
>>>>>>>>> 650-329-5608
>>>>>>>>> baker_at_[hidden]
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> devel mailing list
>>>>>>>>> devel_at_[hidden]
>>>>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> devel mailing list
>>>>>>>> devel_at_[hidden]
>>>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> devel mailing list
>>>>>>> devel_at_[hidden]
>>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>>>>
>>>>>> _______________________________________________
>>>>>> devel mailing list
>>>>>> devel_at_[hidden]
>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>>>
>>>>> _______________________________________________
>>>>> devel mailing list
>>>>> devel_at_[hidden]
>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>>
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel_at_[hidden]
>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>
>>> _______________________________________________
>>> devel mailing list
>>> devel_at_[hidden]
>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>>
>> --
>> Jeff Squyres
>> jsquyres_at_[hidden]
>> For corporate legal information go to:
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>
>>
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel