[Mesa-dev] Mesa (master): glsl: fix assorted MSVC warnings
Brian Paul
brianp at vmware.com
Tue Nov 16 13:12:27 PST 2010
On 11/16/2010 12:55 PM, Ian Romanick wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 11/15/2010 05:48 PM, Brian Paul wrote:
>
>> case ir_unop_b2f:
>> assert(op[0]->type->base_type == GLSL_TYPE_BOOL);
>> for (unsigned c = 0; c< op[0]->type->components(); c++) {
>> - data.f[c] = op[0]->value.b[c] ? 1.0 : 0.0;
>> + data.f[c] = op[0]->value.b[c] ? 1.0F : 0.0F;
>
> Please don't do this. This particular MSVC warning should just be
> disabled. If this warning were generated for non-literals and for
> literals that actually did lose precision being stored to a float, it
> might have a chance at having some value. Instead, it's just noise.
>
> Individual warnings can be disabled with a pragma, and this one should
> probably be disabled in mesa/compiler.h:
>
> #pragma warning(disable: 4244)
>
> There may be a way to do it from the command line, but I don't know what
> it is.
>
> The F suffixes on constants are also worthless, and they make the code
> ugly. Expecting that they will be added everywhere when no other
> compiler generates this warning is a losing battle.
I've been in the habit of using F suffixes for many, many years. Back
in my IRIX days it told the compiler to use a float and not a double
for the computation (which was faster). And according to Jose's email
which I just spotted, that's still the case with gcc.
I recall another another old unix compiler that I used back then
(maybe AIX) issued warnings similar to MSVC. Old habits die hard.
But I don't think it's a bad habit.
>
>> }
>> break;
>> case ir_unop_f2b:
>> assert(op[0]->type->base_type == GLSL_TYPE_FLOAT);
>> for (unsigned c = 0; c< op[0]->type->components(); c++) {
>> - data.b[c] = bool(op[0]->value.f[c]);
>> + data.b[c] = op[0]->value.f[c] != 0.0F ? true : false;
>
> This warning should also be disabled for the same reason as the above.
> This one isn't even a correctness warning, is a performance warning.
> The code that is replacing the case may have even worse performance than
> the cast! The other changes can stay, but this one needs to be reverted.
Perhaps data.b[c] = bool((int) op[0]->value.f[c]); would do the trick.
>> }
>> break;
>> case ir_unop_b2i:
>> @@ -163,7 +163,7 @@ ir_expression::constant_expression_value()
>> case ir_unop_i2b:
>> assert(op[0]->type->is_integer());
>> for (unsigned c = 0; c< op[0]->type->components(); c++) {
>> - data.b[c] = bool(op[0]->value.u[c]);
>> + data.b[c] = op[0]->value.u[c] ? true : false;
>
> What warning is this? I was unable to reproduce a warning on Visual
> Studio 2008 Express Edition. I suspect this should be reverted too.
The warning was:
src\glsl\ir_constant_expression.cpp(166) : warning C4800: 'unsigned
int' : forcing value to bool 'true' or 'false' (performance warning)
-Brian
More information about the mesa-dev
mailing list