So the patch does make the build problem go away, by turning off the run-time error checking of whether the compile-time assumptions about the platform match what is seen at run-time.
Does anyone understand why the code is actually failing though? It seems that the compile-time generated signaling NaN doesn't match (at run-time) what signaling NaN is supposed to look like (as per airFPClass_f()). But I've never been on a machine that exhibited this, so I wouldn't know how to debug it myself. Incidentally, the whole point of these nan checks is to minimize the extent to which floating point exceptions are inappropriately triggered! The IEEE 754 spec unfortunately didn't specify how to represent a "quiet" vs "signaling" not-a-number (its indicated by the 22nd bit of a 32-bit float, but differently for different platforms, unrelated to endienness). Nrrd wants to know how to generate the quiet NaN that it frequently to represent "don't know" for floating-point values, and wants to be able to know it all at compile-time. But just once, the library wants to make sure the compile-time knowledge is correct, which is the code causing a problem here. This is all a result of trying to learn something about the local hardware (like endienness), rather than asserting or requiring some specific obscure handling of FP quantities. Is there anything about how endienness has been previously successfully handled on cross-platform builds (between different endiennesses) that could be informative here? Thanks, Gordon On Jun 18, 2012, at 9:00 AM, Williams, Norman K wrote: > Bradley, that error happens if floating point exceptions are turned on, > which isn't the default on any system I know about, is Debian the > exception? > > Paul that looks like it works, but it would be nice if the expression > wasn't that hairy, and didn't split a conditional clause in the middle > like that. More a style issue than substance ;-) > -- > Kent Williams [email protected] > > > > > > > On 6/15/12 8:20 AM, "Paul Novotny" <[email protected]> wrote: > >> Sorry, I didn't send this to you guys too. I just sent it to debian-med. >> Here is the patch. >> >> On Fri, 2012-06-15 at 09:12 -0400, Bradley Lowekamp wrote: >>> Hello, >>> >>> >>> I have unfortunately looked at many of the other 59 failing tests for >>> the 32-bit Debian sid (unstable) with gcc 4.7.0-12. I say unfortunate >>> because it sounds familiar and like is should be fixable, and should >>> not be punted. >>> >>> >>> http://open.cdash.org/viewTest.php?onlyfailed&buildid=2363925 >>> >>> >>> It looks like they are all related to the same problem emitting from >>> the NRRDIO library. Moreover, I recall that we have run into issue >>> with NRRD being rather assertive with what is expects with NAN >>> floating point handing before too. I think I have seen this error >>> before. >>> >>> >>> And this is a typical error message: >>> >>> >>> itk::ExceptionObject (0x980deb8) >>> Location: "unknown" >>> File: >>> /var/lib/jenkins/jobs/ITK-v4-Testing-32-chroot/workspace/MyTests/ITK/Modu >>> les/IO/NRRD/src/itkNrrdImageIO.cxx >>> Line: 257 >>> Description: itk::ERROR: NrrdImageIO(0x980d738): ReadImageInformation: >>> Error >>> reading >>> /var/lib/jenkins/jobs/ITK-v4-Testing-32-chroot/workspace/MyTests/ITK-buil >>> d/ExternalData/Testing/Data/Input/DwiCorpusCallosum.nhdr: >>> [nrrd] nrrdLoad: trouble reading >>> >>> "/var/lib/jenkins/jobs/ITK-v4-Testing-32-chroot/workspace/MyTests/ITK-bui >>> ld/ExternalData/Testing/Data/Input/DwiCorpusCallosum.nhdr" >>> [nrrd] nrrdRead: trouble >>> [nrrd] _nrrdRead: sanity check FAILED: have to fix and re-compile >>> [nrrd] nrrdSanity: airSanity() failed: airFPClass(AIR_QNAN,AIR_SNAN) >>> wrong >>> >>> >>> >>> >>> I am searching my email archive for related messages... I know we have >>> had this issue before on certain platforms. >>> >>> >>> Brad >>> >>> ======================================================== >>> >>> Bradley Lowekamp >>> >>> Medical Science and Computing for >>> >>> Office of High Performance Computing and Communications >>> >>> National Library of Medicine >>> >>> [email protected] >>> >>> >>> >>> >>> >>> >> >> _______________________________________________ >> 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 > > > > ________________________________ > Notice: This UI Health Care e-mail (including attachments) is covered by the > Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential > and may be legally privileged. If you are not the intended recipient, you > are hereby notified that any retention, dissemination, distribution, or > copying of this communication is strictly prohibited. Please reply to the > sender that you have received the message in error, then delete it. Thank > you. > ________________________________ > _______________________________________________ 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
