Re: [Emc-developers] EMC crashes on G3

[Michael B. <m...@bu...>]

On Tue, 20 Dec 2011 21:44:45 -0600
Jeff Epler <je...@un...> wrote:

> Can you point me towards where it is documented that -ffast-math changes
> the ABI?  I was not aware of this.
> 
> Since these flags were introduced to get the right behavior of
> isinf / isnan (on i386),

Well that effectively _is_ an ABI change of these functions.
It also defines the __FAST_MATH__ preprocessor macro, which seems to change
some error handling, as far as I can spot from a quick look.
http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Optimize-Options.html

I don't think it's a bad idea to use -fno-fast-math,
but I _do_ think it is a very bad idea to compile RTAI and EMC with
distinct fast-math settings, so that they have different views on
the (internal) math ABI. This is especially bad as RTAI does _provide_ the kernel
math helper functions to EMC.

The "-funsafe-math-optimizations" descriptions sounds pretty scary
for kernel code:
"When used at link-time, it may include libraries or startup files that
change the default FPU control word or other similar optimizations."
However, it also sounds as scary to compile linked codepaths with distinct
settings for this option.
So removal of -fno-unsafe-math-optimizations was also needed for some reason
to fix the issue.

> it seems like we could replace our definitions
> of those functions with e.g., __asm__ blocks that use fxam (i386/x87) or
> ucomisd (x86_64/sse2) or bit twiddling hacks (other architectures).
> Having done that, it would be possible to revert these flag changes so
> that x86_64 works right.
> 
> Otherwise, before incorporating this patch I'd like to at least make it
> conditional on x86_64 so that we retain proper functioning of isinf and
> isnan for i386 users.

Seems fair enough for now.

> Right now it looks like the only place in RT that is using isinf/isnan
> is rtapi_vsnprintf.  However, when debugging some users have also found
> the ability to add explicit checks for isinf/isnan useful.

I don't think it necessarily crashes inside isinf or isnan. These compiler
switches seem to affect way more code than only these two special cases.
I'm not completely sure where it crashes. The program counter given by
the realtime oops seems to be mangled in some way (It points to the
RTAI task context switcher).

-- 
Greetings, Michael.