On 6/13/2013 21:48, Jacek Caban wrote:
> On 06/13/13 00:11, JonY wrote:
>> I discovered it was including devicetopology.h and then including ks.h
>> and ksmedia.h. These declarations are already in devicetopology.h but
>> dummied out because it was checking for _KS_ #define before declaring
>> thes
On 06/13/13 00:11, JonY wrote:
> I discovered it was including devicetopology.h and then including ks.h
> and ksmedia.h. These declarations are already in devicetopology.h but
> dummied out because it was checking for _KS_ #define before declaring
> these. ks.h defines it and blocks the declaration
I am concerned about making out of function-prototypes instead macros.
A reasonable concern. I have struggled with this on occasion. It's
certainly worth a second look (below).
I admit that in most cases that won't cause any troubles, but by
macros we pessimize some potential user-code ove
Hi,
I am concerned about making out of function-prototypes instead macros.
I admit that in most cases that won't cause any troubles, but by
macros we pessimize some potential user-code overrides. Additional a
macro has no implementation-address. So there are no
pointer-references possible (well
This patch addresses the following issues:
1) The existing code for __faststorefence doesn't actually generate a
fence. It just generates a barrier. This patch maps __faststorefence
to _mm_sfence (instead of doing MS's trick with "lock or"). sfence
appears to be faster than MS's "fast" appr
> I think we should ignore that somebody uses -mno-sse for x64. First
> this would be clearly an ABI-breakage, due SSE is mandatory in
> calling-convention.
Agreed.
TIL: x64 uses SSE features for passing parameters (for example using
XMM0 for floating point).
>
>> There is a similar question fo
