This helps to generate proper header files instead of using manual cpp_quote.
Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
Signed-off-by: Liu Hao <lh_mouse@126.com>
They are declared in 'intrin.h' but were not defined anywhere.
The implementations might be imperfect: If the second argument is <= zero
or is >= the width of the first parameter, one of the shift counts will be
out of range and cause undefined behavior. Some bitwise arithmetic may be
involved to prevent this (like in 'ia32intrin.h' from GCC 8), which is
unfortunately not recognized by GCC 7 and earlier versions as bitwise
rotation and results in rather complex code.
Reference: https://docs.microsoft.com/en-us/cpp/intrinsics/rotl8-rotl16?view=msvc-160
Reference: https://github.com/msys2/MINGW-packages/issues/7437
Signed-off-by: Liu Hao <lh_mouse@126.com>
Otherwise it results in a compilation error with widl 6.0-rc1:
include/bdatypes.h:43: error: 'PBDA_EVENT_ID': [v1_enum] attribute applied to non-enum type
The code generated without this [v1_enum] is the same but we can keep this
information.
widl 6.0-rc1 reports the following error:
include/wincrypt.idl:17: error: calling convention applied to non-function type
FARPROC is not used in any IDL file anyway.
* rename D3DENUM_NO_WHQL_LEVEL to D3DENUM_WHQL_LEVEL
* remove D3DCAPS2_NO2DDURING3DSCENE
* remove D3DCAPS2_CANRENDERWINDOWED
Removed defines seems to have been copied from d3d8.h and according to
public docs do not exist in d3d9.
Signed-off-by: Rafał Harabień <rafalh92@outlook.com>
Signed-off-by: Liu Hao <lh_mouse@126.com>
This fixes the error: 'sprintf_s' was not declared in this scope.
Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
The headers have a number of brittle workarounds, all trying to make
the "#define _mm_malloc _aligned_malloc" redirect in malloc.h work
properly.
That define is problematic, because it behaves differently depending
on the order headers are included. If malloc.h is included before
GCC's mm_malloc.h, malloc.h does "#define _mm_malloc _aligned_malloc"
and "#define _MM_MALLOC_H_INCLUDED", making sure that a later include
of GCC's mm_malloc.h define nothing. If the user code calls
_mm_malloc() after that, it ends up calling _aligned_malloc().
However, if the user code (implicitly) includes mm_malloc.h before
malloc.h, the situation is much trickier. (mm_malloc.h gets implicitly
included by x86intrin.h, which is included by e.g. winnt.h.)
GCC's mm_malloc.h looks like this, a little simplified:
#ifndef _MM_MALLOC_H_INCLUDED
#define _MM_MALLOC_H_INCLUDED
#include <stdlib.h>
static __inline__ void *_mm_malloc (...)
The stdlib.h include implicitly includes malloc.h, which does
"#define _mm_malloc _aligned_malloc", which causes GCC's mm_malloc.h
to suddenly define a static inline _aligned_malloc instead.
This has been halfway worked around by not defining the non-inline
_aligned_malloc in malloc.h if _MM_MALLOC_H_INCLUDED already was
defined, making the inline function the only definition of it.
So when expanding malloc.h in this context, there's no way to stop the
outer mm_malloc.h from defining a static inline function, and regardless
of whatever name it is renamed to with a define, that static inline
function is what callers to _mm_malloc end up calling.
This causes calls to both _mm_malloc and _aligned_malloc to end
up either with the dllimported function or the static inline version,
depending on which header was included first. If one translation unit
calls _mm_malloc and another one calls _mm_free, there's a risk that
they end up mismatched, which is potentially fatal.
This was earlier attempted to be worked around in e.g. intrin.h, by
forcing including malloc.h before x86intrin.h, but such workarounds
are futile, as user code could also include x86intrin.h, immintrin.h
or even mm_malloc.h directly, without passing through mingw headers.
Instead just remove the _mm_malloc redefinition and include the
compiler's mm_malloc.h header. This makes sure that regardless of
header include order, calls to _aligned_malloc and _mm_malloc will
always end up to the same function, avoiding risks of mismatches
between *_malloc and *_free.
This also has the effect of no longer hiding the declaration of
_aligned_malloc when including intrin.h first.
Signed-off-by: Martin Storsjö <martin@martin.st>
These workarounds stem from an earlier attempt to work around clashes
between _mm_malloc and _mm_free with _aligned_malloc, see
228f1adee7 for where the earlier
"#define _aligned_malloc ..." workaround was removed.
Signed-off-by: Martin Storsjö <martin@martin.st>
