[Mesa-dev] [PATCH 4/4] MSVC2013: Namespace qualify fma to override ambiguity with fma from math.h
Thomas Sondergaard
ts at medical-insight.com
Tue Jan 7 15:03:24 PST 2014
On 2014-01-07 23:45, Kenneth Graunke wrote:
> On 01/07/2014 12:31 PM, Thomas Sondergaard wrote:
>> MSVC 2013 version of math.h includes an fma() function.
>> ---
>> src/glsl/builtin_functions.cpp | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
>> index 10127f3..b3e407a 100644
>> --- a/src/glsl/builtin_functions.cpp
>> +++ b/src/glsl/builtin_functions.cpp
>> @@ -3936,7 +3936,7 @@ builtin_builder::_fma(const glsl_type *type)
>> ir_variable *c = in_var(type, "c");
>> MAKE_SIG(type, gpu_shader5, 3, a, b, c);
>>
>> - body.emit(ret(fma(a, b, c)));
>> + body.emit(ret(ir_builder::fma(a, b, c)));
>>
>> return sig;
>> }
>>
>
> Shouldn't function overloading already make this work out, though? The
> fma() in math.h certainly doesn't have the same operand types.
>
> That's basically why we've gotten away with using incredibly generic
> names like abs()...
>
> --Ken
>
Here is the compiler error from MSVC 2013:
src\glsl\builtin_functions.cpp(3939) : error C2664: 'ir_return
*ir_builder::ret(ir_builder::operand)' : cannot convert argument 1 from
'float' to 'ir_builder::operand'
No constructor could take the source type, or constructor
overload resolution was ambiguous
scons: *** [build\windows-x86\glsl\builtin_functions.obj] Error 2
It means the compiler has selected the wrong overload, one that returns
a float. There are three overloads in C:/Program Files (x86)/Microsoft
Visual Studio 12.0/VC/include/math.h:
_CRTIMP double __cdecl fma(_In_ double _X, _In_ double _Y, _In_ double _Z);
inline float __CRTDECL fma(_In_ float _X, _In_ float _Y, _In_ float _Z)
throw()
inline long double __CRTDECL fma(_In_ long double _X, _In_ long double
_Y, _In_ long double _Z) throw()
I don't see how it can pick any of those with the given arguments, but
the patch makes the problem go away.
Regards,
Thomas
More information about the mesa-dev
mailing list