This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Make ieee754 fma tolerate architectures without exceptionsupport.


On 11/5/2012 5:09 PM, Joseph S. Myers wrote:
> On Mon, 5 Nov 2012, Chris Metcalf wrote:
>> Meanwhile, does my proposed change seem plausible?  It unbreaks the libm
>> build for tile, and the tests continue to report 0 or 1 ULP for all the fma
>> tests, much better than the generic fma.
> I'd have thought that putting something in your math_private.h to allow 
> this file to build, when it's used outside the circumstances for which it 
> was designed, would be better.

How does the appended diff look?

Is it worth trying to use the libc_fesetround() prefix naming for things
like feraiseexcept() and feclearexcept() as well?  (This would also imply
fixing up the test code, since tile needs to fix those API symbol names for
the test code currently as well.)

2012-11-05  Chris Metcalf  <cmetcalf@tilera.com>

       * sysdeps/tile/math_private.h: Provide additional no-op defines
       for exception and rounding macros.

diff --git a/ports/sysdeps/tile/math_private.h b/ports/sysdeps/tile/math_private.h
index 858db4a..f40faef 100644
--- a/ports/sysdeps/tile/math_private.h
+++ b/ports/sysdeps/tile/math_private.h
@@ -1,13 +1,31 @@
 #ifndef _MATH_PRIVATE_H

+/* Internally, we suppress any use of exception or rounding other
+   than what is supported by the hardware.  This does mean that some
+   code will silently fail to report exceptions, set rounding mode
+   as expected, etc., but it allows math code to compile that otherwise
+   wouldn't (such as math/s_fma.c) and so is valuable.
+
+   We intentionally ignore the "exception" arguments of functions that
+   take an exception, since we can't even evaluate the argument
+   without causing a build failure.  The extra level of statement
+   expression wrapping avoids "statement with no effect" warnings.
+   Since the callers don't check for errors anyway, we just claim
+   success in every case.
+
+   The overrides for libc_ functions must happen before we include
+   the generic math_private.h, and the overrides for regular
+   <fenv.h> functions must happen afterwards, to avoid clashing with
+   the declarations of those functions.  */
+
+#define libc_fesetround(rnd)                   ({ 0; })
+#define libc_fetestexcept(exc)                 ({ 0; })
+#define libc_feholdexcept_setround(env, exc)   ({ (void) (env); 0; })
+#define libc_feupdateenv_test(env, exc)                ({ (void) (env); 0; })
+
 #include_next <math_private.h>

-/* We have no exception support, so feraiseexcept() must be a no-op.
-   And since we don't define FE_INVALID, FE_DIVBYZERO, etc., we
-   must ignore the argument of feraiseexcept() as well.  we return
-   "1" to indicate we failed to raise an exception, though none of
-   the callers in glibc actually care.  The extra level of statement
-   expression wrapping avoids "statement with no effect" warnings.  */
-#define feraiseexcept(excepts) ({ 1; })
+#define feraiseexcept(excepts)                 ({ 0; })
+#define feclearexcept(exc)                     ({ 0; })

 #endif


-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]