[Insight-developers] Problem with 3.14 release

Sat May 30 05:56:31 EDT 2009

Hi Brad,

Thanks for the information. It's nice to ear that at least disabling
VNL_CONFIG_ENABLE_SSE2_ROUNDING fixed the compilation issues.

As I said, I won't be able to tests things before Tuesday.

Regarding VNL_CONFIG_ENABLE_SSE2, this configuration flag is
considered buggy by the vxl developers and should thus not be turned
on (unless you are trying to fix it of course).

On the other hand, I agree that it would be nice if, when building
universal binaries (UB) also, VNL_CONFIG_ENABLE_SSE2_ROUNDING could be
turned on for x86 and turned off for other architectures.

As far as I can tell, the vxl cmake magic does not seem to allow such
things in its current state. Right now, the best we can expect is that
cmake detects that VXL_HAS_SSE2_HARDWARE_SUPPORT is false with UB,
i.e. it is not true for at least one target architecture. This would
lead to turning VNL_CONFIG_ENABLE_SSE2_ROUNDING off for all target
architectures.

If we want to be on the safe side until this universal binary problem
is sorted out, we could also disable VNL_CONFIG_ENABLE_SSE2_ROUNDING
by default for everyone. What do you think?

This can be done by changing, in
  http://www.itk.org/cgi-bin/viewcvs.cgi/Utilities/vxl/core/vnl/CMakeLists.txt?root=Insight&sortby=date&view=markup
by changing

OPTION(VNL_CONFIG_ENABLE_SSE2_ROUNDING
  "Enable Streaming SIMD Extensions 2 implementation of rounding
(hardware dependant)."
  ${VXL_HAS_SSE2_HARDWARE_SUPPORT} )

into

OPTION(VNL_CONFIG_ENABLE_SSE2_ROUNDING
  "Enable Streaming SIMD Extensions 2 implementation of rounding
(hardware dependant)."
  OFF )

Regards,
Tom

On Sat, May 30, 2009 at 04:09, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
> Hello Tom,
>
> Disabling VNL_CONFIG_ENABLE_SSE2_ROUNDING seems to fix the build errors,
> (still waiting for tests).
>
> Making it a clean build was one of the first things I did.
>
> I believe the experimental victoria build was build with xcode 3.1's gcc
> 4.2. I just rebuild it on my laptop with XCode 3.0's gcc 4.0, and the same
> things happened.
>
> I have mini0 on the dashboard which just builds a ppc version on an intel
> processor and that seems to be working fine. It's a little complicated to
> get this configuration, but it's what I always use to install, so that I
> have one library for what ever I may be building. This is a very useful
> configuration, though.
>
>
> mini1 should resubmit a clean build tomorrow, which will hopefully have the
> information you need from a vxl clean configure.
>
> Ideally I would think that VNL_CONFIG_ENABLE_SSE2_ROUNDING ( and
> VNL_CONFIG_ENABLE_SSE2 ) would be enabled for the intel build, but not for
> the ppc. However looking at the way this is defined in vnl_config.h.in, I
> don't think with one configuration with one generated vn_config.h this is
> possible, because it's based on a single cmake variable for both
> architectures.
>
> I am not sure about how the try_compile works with universal builds...
>
> Brad
>
> On May 29, 2009, at 6:51 PM, Tom Vercauteren 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
>>>
>>>
>
>