On Jan 10, 2011, at 11:40 AM, Roy Stogner wrote: > > > On Mon, 10 Jan 2011, Cody Permann wrote: > >> So I've been looking into making some of the error handling stuff >> more robust on the Mac Platform, i.e. catching NaNs better and >> better stack traces. I was just looking through the print_trace.C >> file and noticed that somebody has written wrappers for the >> demangler and stack trace that seem to work just fine on the current >> Mac platform with the Mac version of the g++ compiler. However this >> code is disabled in the print_trace file defaulting to the other >> Linux code which doesn't demangle on the Macs. Perhaps the Mac code >> was never enabled because of inadequate testing or some other >> problem? > > s/inadequate testing/no testing/ > > When writing print_trace I found a couple references online to APIs > that purported to do the same stack grabbing and demangling on OSX > that we do on Linux; however at that time I didn't have an OSX libMesh > build and couldn't even test whether the code would compile or not. > > Then when I finally got an OSX build, a year or two later, I didn't > think to go back and check whether the OSX print_trace would work or > not. >
>> Unless somebody has a reason not to, I propose that we >> enable that code again for the Mac platform. I'll make the >> necessary changes and will check it back in. > > Thanks! > >> I'm also looking into catching NaNs sooner. The current isNaN stuff >> that Roy recently added doesn't work very well on the Mac Platform. >> It appears that the g++ compiler on this platform doesn't honor >> signaling nans even when using the appropriate compile flags >> (-fsignaling-nans or -ftrapping_math). > > Wait, I specifically avoided using g++ - the whole point of that one > .c file is to let us take advantage of the standard-in-C-but-not-C++ > isnan() macro. That macro doesn't work on OSX? Sorry for the confusion - the isnan macro is working. I was being more lazy than that. In the past on other codes, I found it useful to to have signals generated when NaNs are generated/used. This is something that can be control (in a somewhat non-portable way) through changing some processor control environment masks. That way we could avoid scattering isnan through our applications down into our user codes, instead relying on signal handling to flag the point of generation/use. We already have isnan in some key places in our debug builds but many times by the time we've hit those checks we don't know exactly where the nan was generated in the first place. I'm after something a little different here. > >> I did find some Intel specific code using intrinsics that does work >> though. > > Silly question: does testing "x != x" work? I think that's supposed > to be the most standard C++-only way to test isnan. This usually works but again is an explicit check, something I was trying to avoid > >> The down side is that this code will only work on Mac Intel >> processors which is a little less portable but probably not a big >> issue. If I find a portable way to add this to the library I will >> do so. > > Don't worry too much about portability in libmesh_isnan.c; the whole > reason for libmesh_isnan() to exist is to wrap a bunch of potentially > non-portable/hackish implementations into a single portable inline > function. If I figure out this whole signal business that's the option i'd like to add. It would have to be something that could easily be turned on/off and throw exceptions earlier and possibly without explicit isnan calls. > --- > Roy
------------------------------------------------------------------------------ Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
