Joseph Myers <jos...@codesourcery.com> writes: > On Tue, 25 Mar 2014, Matthew Fortune wrote: > > > Can you envisage any way of us raising a warning/error if INVALID > > exceptions get enabled in this hybrid NaN world? I believe that is the > > only major problem area with mixing NaNs. I.e. It should be possible > > to introduce a magic symbol if LD merged opposing NaN modules and have > > fesetexcept check for it but I can't think up a way to indicate to > > fesetexcept if LDSO linked opposing NaN modules (I'm not sufficiently > > experienced with dynamic linkers to know what is possible though). > > fesetexcept - a new function in TS 18661-1, not implemented in glibc - > has nothing to do with this; the issue is about exceptions from > arithmetic rather than those from functions explicitly setting them. > And to a first approximation you can ignore exceptions being "enabled" > (i.e. traps being > enabled) and presume they are tested for by C99 facilities such as > fetestexcept - which has no way to return any sort of error status.
Sorry Joseph I was being retarded, my brain thought one thing and fingers typed another. I meant to refer to feenableexcept. I was thinking more along the lines of having such things as feenableexcept and fetestexcept simply abort (or at least be noisy) if they were called to check for/trap for INVALID exceptions from an application that included both NaN encodings. This too is probably overkill as INVALID has many more reasons to be triggered than sNaN and the abort/warning would happen for those cases too. I am warming to the combined ideas of Richard and Maciej for allowing MSA to be compiled with the 'wrong' NaN encoding and also supporting a kernel mode to do full FPU emulation when software and hardware NaN encodings differ. The issue though is that the full emulation effectively renders MSA useless as it can only exist in NaN2008 cores anyway and that would be the trigger case for emulation. This then removes one of the primary reasons for needing mixed nan support in the first place so the kernel emulation option may just have to be used at a user's discretion. I'll talk to the engineers working on Linux distributions and see what they think. I really appreciate all the discussion on this topic. Regards, Matthew
