I've been trying to reproduce this problem with a minimal example with no success for quite some time (spent a large part of my last 2 weekends trying out different things). Perhaps some compiler guru can figure out what is going on :\
I did come across this though, which looks to be somewhat related to the problem. https://randomascii.wordpress.com/2013/12/01/vc-2013-class-layout-change-and-wasted-space/ Ho Cheung [email protected] Cell: (775) 388-2368 On Sat, Nov 30, 2013 at 8:00 AM, Bradley Lowekamp <[email protected]>wrote: > Hello, > > If you can come up with minimal code to reproduce the MSVC12 bug, then I > can report it to them. > > Thanks, > Brad > > On Nov 29, 2013, at 3:36 PM, Ho Cheung <[email protected]> wrote: > > Looks like this is compiler bug relating to SSE and alignment. The Win32 > and Win64 Debug builds all use the x87 stack so do not experience this > issue. > > Here is the assembly code from one of the crashing tests: > > const SpacingType spacing = outputImage->GetSpacing(); > 000000013FE078C9 mov rax,qword ptr [rcx] > 000000013FE078CC call qword ptr [rax+180h] > 000000013FE078D2 movaps xmm0,xmmword ptr > [__xmm@3ff00000000000003ff0000000000000 (0140120C10h)] > > for ( unsigned int i = 0; i < ImageDimension; i++ ) > { > coeffs[i] = 1.0 / static_cast< double >( spacing[i] ); > 000000013FE078D9 divpd xmm0,xmmword ptr [rax] > > Following it with the debugger, RAX = 0000000002162018 at the divpd > instruction. > > The memory operands of divpd must be aligned on 16-byte boundary[1] but as > we can see clearly here it is only aligned on 8-byte boundary. > > RAX is last set by the call to GetSpacing (itkGetConstReferenceMacro), > here is the assembly for that: > > itkGetConstReferenceMacro(Spacing, SpacingType); > 000000013F58B720 lea rax,[rcx+0B8h] > 000000013F58B727 ret > > RCX = 0000000002111F60 > > I googled to see if anyone else were having this alignment issue, and it > seems not so I wonder if we were doing something to upset the compiler's > "natural" alignment. I tried to use /Zp16 [2] compiler option but it > appears to only align to the minimum of the "natural" alignment and the Zp > parameter, so it does not work. It seems we are forced to use > __declspec(align(16)) [3] for all array declaration to fix this issue but > that still leaves user and new code unprotected. > > Does anyone have any suggestions on how to fix this issue? > > [1] http://n0ah.org/mirrors/siyobik.info/instruction/DIVPD.html > [2] http://msdn.microsoft.com/en-us/library/xh3e3fd0.aspx > [3] http://msdn.microsoft.com/en-us/library/83ythb65%28v=vs.80%29.aspx > > > Ho Cheung > [email protected] > Cell: (775) 388-2368 > > > On Wed, Nov 27, 2013 at 7:23 AM, Bradley Lowekamp > <[email protected]>wrote: > >> Just to follow up. On the same system I have a clean VS12 (2013) Win32, I >> have a nightly build for Win64 with 123 test failures. So this confirms >> that it's just a Win64 issue. >> >> Brad >> >> >> >> On Nov 26, 2013, at 9:46 AM, Simon Alexander <[email protected]> >> wrote: >> >> I have the same suspicion. If I can find the time I will look for root >> cause and a work around if possible. >> >> Unfortunately, regressions took precedence and I haven't been able to >> rerun the dashboard. I'll look at this again when I have a free machine. >> >> >> On Tue, Nov 26, 2013 at 8:46 AM, Bradley Lowekamp <[email protected] >> > wrote: >> >>> Hello, >>> >>> Here is my nightly with VS12 32-bit: >>> >>> http://open.cdash.org/buildSummary.php?buildid=3115540 >>> >>> It comes back clean. >>> >>> There reports have also been that VS12 64-bit in Debug is clean. >>> >>> Also Simon reports: >>> >>> These seem to maybe be related to copy ctor on itk::Vector types and the >>> optimizer (VS12, 64 bit) >>> >>> e.g. >>> >>> >>> code that looks like this: >>> >>> typedef typename TOutputImage::SpacingType SpacingType; >>> const SpacingType spacing = outputImage->GetSpacing(); >>> >>> leads to a segfault as soon as spacing is accessed (in Release mode, not >>> Debug) >>> >>> but >>> >>> typedef typename TOutputImage::SpacingType SpacingType; >>> const SpacingType &spacing = outputImage->GetSpacing(); >>> >>> >>> I am very suspicious that this is not a bug in ITK. >>> >>> >>> >>> >>> >>> On Nov 25, 2013, at 10:39 PM, Ho Cheung <[email protected]> wrote: >>> >>> Here’s v4.5rc01 on VS2013 Ultimate 64-bit Release mode. Seems like still >>> quite a lot of segfaults. I’ll have a closer look when I get some time off >>> over Thanksgiving weekend if not solved by then. >>> >>> http://open.cdash.org/buildSummary.php?buildid=3114945 >>> >>> On Nov 25, 2013, at 8:52 AM, Simon Alexander <[email protected]> >>> wrote: >>> >>> Bradley, >>> >>> Thanks, missed adding the list. My builds are all 64 bit on 64 bit OS. >>> I will pull a new copy of master tonight and manually run the dashboard. >>> >>> >>> On Mon, Nov 25, 2013 at 9:36 AM, Bradley Lowekamp < >>> [email protected]> wrote: >>> >>>> Simon, >>>> >>>> I am including the developers list. >>>> >>>> My nightly is 32-bit, perhaps thats related? I'll configure up a 64-bit >>>> build nightly too, to see if that's different. >>>> >>>> You likely should start with a clean master repo, as start with a fresh >>>> CMake configured build too. Results shared on the dashboard are welcomed. >>>> >>>> Brad >>>> >>>> >>>> >>>> On Nov 25, 2013, at 9:25 AM, Simon Alexander <[email protected]> >>>> wrote: >>>> >>>> Hi Bradley, >>>> >>>> It is interesting that the build does not show the same pattern of >>>> errors. If it is helpful I can run the ctest suite again here (win x64, 64 >>>> bit builds) but there are certainly things I can't test (like the >>>> wrapping). >>>> >>>> cheers, >>>> Simon >>>> >>>> >>>> On Sat, Nov 23, 2013 at 4:07 PM, Bradley Lowekamp < >>>> [email protected]> wrote: >>>> >>>>> Hello, >>>>> >>>>> Thanks for all who have contributed patches and reviews in the last >>>>> couple of days in preparation of the release candidate. >>>>> >>>>> I am expecting a good dashboard tomorrow, which should have WrapITK, >>>>> and VS12 ( 2013 ) green. Here are a couple experimental build I have fired >>>>> off: >>>>> >>>>> http://open.cdash.org/buildSummary.php?buildid=3112037 >>>>> http://open.cdash.org/buildSummary.php?buildid=3112076 >>>>> >>>>> Interestingly, VS12 has not test failure which is different than had >>>>> been reported by others. >>>>> >>>>> Thanks, >>>>> Brad >>>>> _______________________________________________ >>>>> Powered by www.kitware.com >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Kitware offers ITK Training Courses, for more information visit: >>>>> http://kitware.com/products/protraining.php >>>>> >>>>> Please keep messages on-topic and check the ITK FAQ at: >>>>> http://www.itk.org/Wiki/ITK_FAQ >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> http://www.itk.org/mailman/listinfo/insight-developers >>>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Kitware offers ITK Training Courses, for more information visit: >>> http://kitware.com/products/protraining.php >>> >>> Please keep messages on-topic and check the ITK FAQ at: >>> http://www.itk.org/Wiki/ITK_FAQ >>> >>> Follow this link to subscribe/unsubscribe: >>> http://www.itk.org/mailman/listinfo/insight-developers >>> >>> >>> >>> >> >> > ue, > > >
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Kitware offers ITK Training Courses, for more information visit: http://kitware.com/products/protraining.php Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ Follow this link to subscribe/unsubscribe: http://www.itk.org/mailman/listinfo/insight-developers
