Re: [Libmesh-devel] print_trace and NaNs on Mac OS X

[Roy S. <roy...@ic...>]

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?

> 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.

> 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.
---
Roy