[Mesa-dev] [PATCH] glsl: Use INFINITY instead of std::numeric_limits<float>::infinity().
Jose Fonseca
jfonseca at vmware.com
Thu Mar 19 08:30:40 PDT 2015
On 18/03/15 17:18, Matt Turner wrote:
> ---
> src/glsl/builtin_functions.cpp | 4 ++--
> src/glsl/s_expression.cpp | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
> index c607572..524b8d6 100644
> --- a/src/glsl/builtin_functions.cpp
> +++ b/src/glsl/builtin_functions.cpp
> @@ -60,7 +60,7 @@
> #include "ir_builder.h"
> #include "glsl_parser_extras.h"
> #include "program/prog_instruction.h"
> -#include <limits>
> +#include <math.h>
>
> #define M_PIf ((float) M_PI)
> #define M_PI_2f ((float) M_PI_2)
> @@ -3215,7 +3215,7 @@ builtin_builder::_isinf(builtin_available_predicate avail, const glsl_type *type
>
> ir_constant_data infinities;
> for (int i = 0; i < type->vector_elements; i++) {
> - infinities.f[i] = std::numeric_limits<float>::infinity();
> + infinities.f[i] = INFINITY;
> }
>
> body.emit(ret(equal(abs(x), imm(type, infinities))));
> diff --git a/src/glsl/s_expression.cpp b/src/glsl/s_expression.cpp
> index 7eaa491..f82e155 100644
> --- a/src/glsl/s_expression.cpp
> +++ b/src/glsl/s_expression.cpp
> @@ -23,8 +23,8 @@
> */
>
> #include <assert.h>
> -#include <limits>
> #include <stdio.h>
> +#include <math.h>
> #include "s_expression.h"
>
> s_symbol::s_symbol(const char *str, size_t n)
> @@ -70,7 +70,7 @@ read_atom(void *ctx, const char *&src, char *&symbol_buffer)
> // requires strtof to parse '+INF' as +Infinity, but we still support some
> // non-C99-compliant compilers (e.g. MSVC).
> if (n == 4 && strncmp(src, "+INF", 4) == 0) {
> - expr = new(ctx) s_float(std::numeric_limits<float>::infinity());
> + expr = new(ctx) s_float(INFINITY);
> } else {
> // Check if the atom is a number.
> char *float_end = NULL;
>
FWIW, std::numeric_limits is actually the "C++ way" of doing this, but
given we have a mixture of C99 in Mesa, using INFIFITY everywhere is
equally fine. Either way, there should be no problems for MSVC.
Reviewed-by: Jose Fonseca <jfonseca at vmware.com>
More information about the mesa-dev
mailing list