[Insight-developers] Expecting a good dashboard tomorrow
Ho Cheung
hocheung20 at gmail.com
Fri Dec 13 21:18:37 EST 2013
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
hocheung20 at gmail.com
Cell: (775) 388-2368
On Sat, Nov 30, 2013 at 8:00 AM, Bradley Lowekamp <blowekamp at mail.nih.gov>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 <hocheung20 at gmail.com> 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 at 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
> hocheung20 at gmail.com
> Cell: (775) 388-2368
>
>
> On Wed, Nov 27, 2013 at 7:23 AM, Bradley Lowekamp <blowekamp at mail.nih.gov>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 <skalexander at gmail.com>
>> 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 <blowekamp at mail.nih.gov
>> > 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 <hocheung20 at gmail.com> 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 <skalexander at gmail.com>
>>> 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 <
>>> blowekamp at mail.nih.gov> 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 <skalexander at gmail.com>
>>>> 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 <
>>>> blowekamp at mail.nih.gov> 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,
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-developers/attachments/20131213/012b6e82/attachment.htm>
More information about the Insight-developers
mailing list