On Wed, Aug 1, 2012 at 2:50 PM, Matt Turner wrote:
>
> Indeed. I wondered the same. The use of NAN/INF are inside an #if
> !defined(PIPE_CC_MSVC) block, so MSVC can't be the problem. NAN and
> INFINITY are c99, which I'm not sure we can assume. Then again, if not
> MSVC, what compiler is the probl
On Tue, Jul 31, 2012 at 1:16 AM, Philipp Klaus Krause wrote:
> 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? Th
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
Looks good.
Jose
- Original Message -
> 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(0x),
> PACKED_1x16(0x7c01),
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(0x), PACKED_1x16(0x7c01),
UNPACKED_1x1(NAN, 0.0, 0.0, 1.0)},
Signed-off-by: Vins
