[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