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

Reply via email to