On Tue, 20 Dec 2011 21:44:45 -0600 Jeff Epler <jep...@unpythonic.net> 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. ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
