This one doesn't make sense to me: For __GNUC__ it uses implementation-defined non-standard stuff. For other compilers it divides by zero, which is undefined behaviour. Why not use standard macros NAN and INFINITY from math.h? The standard (section 7.12 in the C11 standard, AFAIK the wording is the same in earlier standards) says that they are provided if infinity and quit nan are supported by the implementation.
Philipp On 30.07.2012 07:26, Vinson Lee wrote: > This patch fixes this build failure with Intel Compiler. > > src/gallium/auxiliary/util/u_format_tests.c(903): error: floating-point > operation result is out of range > {PIPE_FORMAT_R16_FLOAT, PACKED_1x16(0xffff), PACKED_1x16(0x7c01), > UNPACKED_1x1( NAN, 0.0, 0.0, 1.0)}, > > Signed-off-by: Vinson Lee <v...@freedesktop.org> > --- > src/gallium/auxiliary/util/u_format_tests.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/src/gallium/auxiliary/util/u_format_tests.c > b/src/gallium/auxiliary/util/u_format_tests.c > index 457fda6..d348608 100644 > --- a/src/gallium/auxiliary/util/u_format_tests.c > +++ b/src/gallium/auxiliary/util/u_format_tests.c > @@ -66,8 +66,13 @@ > {{ 0, 0, 0, 0}, { 0, 0, 0, 0}, {0, 0, 0, 0}, {0, 0, 0, 0}}} > > > +#ifdef __GNUC__ > +#define NAN __builtin_nan("") > +#define INF __builtin_inf() > +#else > #define NAN (0.0 / 0.0) > #define INF (1.0 / 0.0) > +#endif > > /** > * Test cases. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev