[Insight-developers] Problem with 3.14 release

Fri May 29 19:57:45 EDT 2009

Hi Brad,

It looks like on your build, cmake finds that
VXL_HAS_SSE2_HARDWARE_SUPPORT is true.

Now VXL_HAS_SSE2_HARDWARE_SUPPORT comes from a cmake try_run.
http://www.itk.org/cgi-bin/viewcvs.cgi/Utilities/vxl/config/cmake/config/CMakeLists.txt?revision=1.15&root=Insight&sortby=date&view=markup
http://www.itk.org/cgi-bin/viewcvs.cgi/Utilities/vxl/config/cmake/config/vxl_config_macros.cmake?root=Insight&sortby=date&view=markup
http://www.itk.org/cgi-bin/viewcvs.cgi/Utilities/vxl/config/cmake/config/vxl_platform_tests.cxx?root=Insight&sortby=date&view=markup

According to
http://www.cmake.org/Wiki/CMake_FAQ#Platform-specific_questions
http://www.mail-archive.com/cmake@cmake.org/msg03134.html
try_run is not safe for universal binaries. However, try_compile
should be usable and should be sufficient to detect that sse2 cannot
be used on ppc.  What I don't understand is that try_compile is
basically the first step of try_run. So in this specific case, from
the documentation, I would say that the cmake sse2 detection using
try_run should work in your case.

I am not sure this helps you though...

Additional helpful information could be gathered from the trace of
this try_run. Unfortunately, it is not on
http://www.cdash.org/CDash/testDetails.php?test=24107090&build=343521
I know that vxl does not run its platform tests each time. Could you
resubmit an experimental after manually changing
VXL_UPDATE_CONFIGURATION to ON? This should trigger the try_run to be
re-run.

Thanks,
Tom

On Sat, May 30, 2009 at 00:51, Tom Vercauteren <tom.vercauteren at m4x.org> wrote:
> Hi Brad,
>
> I remember testing your scenario (universal binary on intel mac) and
> it worked, weird... The configuration might have been somewhat
> different. I'll have a chance to retest on Tuesday but not before
> that.
>
> Anyhow, the errors you get are sse2 related. They typically appear
> with gcc when -msse2 is required to enable sse2 support. To bypass the
> sse2 implementation, can you try by manually disabling
> VNL_CONFIG_ENABLE_SSE2_ROUNDING in cmake? The implementation should
> then fallback to a gcc assembly when compiling for intel and to a
> vanilla c implementation when compiling fro ppc/ppc64. Then you
> shouldn't get these errors anymore (let's hope you don't get other).
>
> ITK_USE_PORTABLE_ROUND should have no effect on your build issues.
>
> The potential explanation you mention sounds realistic. It might well
> be that sse2 is supported (without any flag?) on your machine when you
> build for intel but not when you build for ppc and that the vnl test
> build only checks one of these configurations. I am not sufficiently
> familiar with universal binaries and cmake to tell but I will have a
> look at it.
>
> To ease the testing when I get back, can you provide some more
> information about your setup? I guess that your failing build is this
> one:
> http://www.cdash.org/CDash/buildSummary.php?buildid=343521
> From the system information
> http://www.cdash.org/CDash/testDetails.php?test=24107090&build=343521
> I cannot tell which version of gcc you were using. Is it the default
> one from apple?
>
> Also was it a clean build or did you reuse an old one?
>
> Tom
>
> On Fri, May 29, 2009 at 22:44, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
>> Unless RougeResearch5 is an intel, I don't see any machines on the dash
>> board which cover this case. I should have chosen by build configurations
>> for the mini's better.
>> By setting:
>>
>> CMAKE_OSX_ARCHITECTURES:STRING=ppc;i386;ppc64;x86_64
>>
>> I am getting the following compilation error:
>> [ 24%] Building CXX object
>> Utilities/vxl/core/vnl/CMakeFiles/itkvnl.dir/vnl_math.o
>> In file included from
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/vnl_math.cxx:8:
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/vnl_math.h:51:46:
>> error: emmintrin.h: No such file or directory
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/vnl_math.h: In
>> function ‘int vnl_math_rnd_halfinttoeven(float)’:
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/vnl_math.h:193:
>> error: ‘_mm_set_ss’ was not declared in this scope
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/vnl_math.h:193:
>> error: ‘_mm_cvtss_si32’ was not declared in this scope
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/vnl_math.h: In
>> function ‘int vnl_math_rnd_halfinttoeven(double)’:
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/vnl_math.h:200:
>> error: ‘_mm_set_sd’ was not declared in this scope
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/vnl_math.h:200:
>> error: ‘_mm_cvtsd_si32’ was not declared in this scope
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/vnl_math.h: In
>> function ‘int vnl_math_floor(float)’:
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/vnl_math.h:359:
>> error: ‘_mm_set_ss’ was not declared in this scope
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/vnl_math.h:359:
>> error: ‘_mm_cvtss_si32’ was not declared in this scope
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/vnl_math.h: In
>> function ‘int vnl_math_floor(double)’:
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/vnl_math.h:366:
>> error: ‘_mm_set_sd’ was not declared in this scope
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/vnl_math.h:366:
>> error: ‘_mm_cvtsd_si32’ was not declared in this scope
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/vnl_math.h: In
>> function ‘int vnl_math_ceil(float)’:
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/vnl_math.h:444:
>> error: ‘_mm_set_ss’ was not declared in this scope
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/vnl_math.h:444:
>> error: ‘_mm_cvtss_si32’ was not declared in this scope
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/vnl_math.h: In
>> function ‘int vnl_math_ceil(double)’:
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/vnl_math.h:451:
>> error: ‘_mm_set_sd’ was not declared in this scope
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/vnl_math.h:451:
>> error: ‘_mm_cvtsd_si32’ was not declared in this scope
>> make[2]: *** [Utilities/vxl/core/vnl/CMakeFiles/itkvnl.dir/vnl_math.o] Error
>> 1
>>
>> If I am just building ppc, or intel, it fine (this is what I think is
>> covered on the dash board. But if it's both architectures, I get these error
>> messages.
>> As intel and ppc have different endianness, a similar handling of this cross
>> compilation issue was done here in itkConfigure.h.in :
>> /* what byte order */
>> /* All compilers that support Mac OS X define either __BIG_ENDIAN__ or
>>    __LITTLE_ENDIAN__ to match the endianness of the architecture being
>>    compiled for. This is not necessarily the same as the architecture of
>>    the machine doing the building. In order to support Universal Binaries on
>>    Mac OS X, we prefer those defines to decide the endianness.
>>    On other platform, we use the result of the TRY_RUN. */
>> #if !defined(__APPLE__)
>>   #cmakedefine CMAKE_WORDS_BIGENDIAN
>>   #ifdef CMAKE_WORDS_BIGENDIAN
>>     #define ITK_WORDS_BIGENDIAN
>>   #endif
>> #elif defined(__BIG_ENDIAN__)
>>   #define CMAKE_WORDS_BIGENDIAN
>>   #define ITK_WORDS_BIGENDIAN
>> #endif
>> I think the checks for VNL_CONFIG_ENABLE_SSE2_ROUNDING, appear to build a
>> build test only. This is insufficient when building an apple universal
>> binary.
>> Brad
>>
>>
>> On May 29, 2009, at 4:11 PM, Lowekamp, Bradley (NIH/NLM/LHC) [C] wrote:
>>
>> Hello,
>> I think there is a problem with the 3.14. If you have an intel mac and are
>> building a universal binary there is a compilation issue.
>> This is likely due to the rounding changing, and how it checks for the
>> architecture. I am building an experimental now (victoria.nlm). And I am
>> going to change mini1.nlm, to cover this case tonight too.
>> Brad
>> ========================================================
>> Bradley Lowekamp
>> Lockheed Martin Contractor for
>> Office of High Performance Computing and Communications
>> National Library of Medicine
>> blowekamp at mail.nih.gov
>>
>> <ATT00001.txt>
>>
>> ========================================================
>>
>> Bradley Lowekamp
>>
>> Lockheed Martin Contractor for
>>
>> Office of High Performance Computing and Communications
>>
>> National Library of Medicine
>>
>> blowekamp at mail.nih.gov
>>
>>
>