Re: [Mingw-w64-public] [PATCH] crt: Make CRT buildable with `-masm=intel`
On 3/23/23 07:03, Martin Storsjö wrote: On Wed, 22 Mar 2023, Jacek Caban wrote: On 3/22/23 15:21, LIU Hao wrote: 在 2023-03-22 21:07, Jacek Caban 写道: That's the motivation for this? I can see a point in supporting both syntaxes in headers (which may be included by users with various compiler options), but for crt, why isn't supporting a single syntax understood by all supported compilers enough? Yes that is the only motivation. Why? Because AT is unofficial, foreign, and awkward. 1. No Intel or AMD doc ever speaks this way. This is already enough for being thrown into the dustbin of history. 2. It was designed for PDP originally, and got widespread just because Plan 9 dogs couldn't stop barking. Oh please take a look at the Go assembler, and what they've done to ARM, brilliant. 3. And, we want `xmm0 = xmm1 - xmm2` and `vsubpd xmm0, xmm1, xmm2`, not the backward nonsense `vsubpd %xmm2, %xmm1, %xmm0`; same for `cmp`. 4. And we want `mov eax, [rsi + rbx * 8 + 12]`, not `movl 12(%rsi, %rbx, 8), %eax`. Intel syntax also copes better with other tools - Microsoft compilers, NASM, IDA, x64dbg, countless assembler and disassemblers - none of them produce or accept nonstandard AT syntax in any way. There have been enough talks about that [1]; I hope I would not have to repeat myself [2]. [1] https://outerproduct.net/2021-02-13_att-asm.html [2] https://gcc.gnu.org/pipermail/gcc/2022-November/240103.html I didn't really mean to ask which syntax is better, but what exactly are we trying to achieve. From GCC thread, my understanding is that you want to support toolchains that default to Intel syntax. How about the attached patch? You need to move the option down into (the weirdly named) CPPFLAGS32 and CPPFLAGS64; for arm/aarch64 targets, Clang warns and GCC errors if given the -masm=att parameter. Oh, right, thanks. I pushed with that changed. If we find more compatibility problems, we can also have configure check, but that doesn't seem needed at this point. Thanks, Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Make CRT buildable with `-masm=intel`
On Wed, 22 Mar 2023, Jacek Caban wrote: On 3/22/23 15:21, LIU Hao wrote: 在 2023-03-22 21:07, Jacek Caban 写道: That's the motivation for this? I can see a point in supporting both syntaxes in headers (which may be included by users with various compiler options), but for crt, why isn't supporting a single syntax understood by all supported compilers enough? Yes that is the only motivation. Why? Because AT is unofficial, foreign, and awkward. 1. No Intel or AMD doc ever speaks this way. This is already enough for being thrown into the dustbin of history. 2. It was designed for PDP originally, and got widespread just because Plan 9 dogs couldn't stop barking. Oh please take a look at the Go assembler, and what they've done to ARM, brilliant. 3. And, we want `xmm0 = xmm1 - xmm2` and `vsubpd xmm0, xmm1, xmm2`, not the backward nonsense `vsubpd %xmm2, %xmm1, %xmm0`; same for `cmp`. 4. And we want `mov eax, [rsi + rbx * 8 + 12]`, not `movl 12(%rsi, %rbx, 8), %eax`. Intel syntax also copes better with other tools - Microsoft compilers, NASM, IDA, x64dbg, countless assembler and disassemblers - none of them produce or accept nonstandard AT syntax in any way. There have been enough talks about that [1]; I hope I would not have to repeat myself [2]. [1] https://outerproduct.net/2021-02-13_att-asm.html [2] https://gcc.gnu.org/pipermail/gcc/2022-November/240103.html I didn't really mean to ask which syntax is better, but what exactly are we trying to achieve. From GCC thread, my understanding is that you want to support toolchains that default to Intel syntax. How about the attached patch? You need to move the option down into (the weirdly named) CPPFLAGS32 and CPPFLAGS64; for arm/aarch64 targets, Clang warns and GCC errors if given the -masm=att parameter. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Make CRT buildable with `-masm=intel`
在 2023/3/23 05:48, Jacek Caban 写道: I didn't really mean to ask which syntax is better, but what exactly are we trying to achieve. From GCC thread, my understanding is that you want to support toolchains that default to Intel syntax. How about the attached patch? Being a compromise for some well established evilness, the patch is not bad itself. You may commit it as appropriate. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Make CRT buildable with `-masm=intel`
On 3/22/23 15:21, LIU Hao wrote: 在 2023-03-22 21:07, Jacek Caban 写道: That's the motivation for this? I can see a point in supporting both syntaxes in headers (which may be included by users with various compiler options), but for crt, why isn't supporting a single syntax understood by all supported compilers enough? Yes that is the only motivation. Why? Because AT is unofficial, foreign, and awkward. 1. No Intel or AMD doc ever speaks this way. This is already enough for being thrown into the dustbin of history. 2. It was designed for PDP originally, and got widespread just because Plan 9 dogs couldn't stop barking. Oh please take a look at the Go assembler, and what they've done to ARM, brilliant. 3. And, we want `xmm0 = xmm1 - xmm2` and `vsubpd xmm0, xmm1, xmm2`, not the backward nonsense `vsubpd %xmm2, %xmm1, %xmm0`; same for `cmp`. 4. And we want `mov eax, [rsi + rbx * 8 + 12]`, not `movl 12(%rsi, %rbx, 8), %eax`. Intel syntax also copes better with other tools - Microsoft compilers, NASM, IDA, x64dbg, countless assembler and disassemblers - none of them produce or accept nonstandard AT syntax in any way. There have been enough talks about that [1]; I hope I would not have to repeat myself [2]. [1] https://outerproduct.net/2021-02-13_att-asm.html [2] https://gcc.gnu.org/pipermail/gcc/2022-November/240103.html I didn't really mean to ask which syntax is better, but what exactly are we trying to achieve. From GCC thread, my understanding is that you want to support toolchains that default to Intel syntax. How about the attached patch? Thanks, Jacek diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am index 933ff5532..3db2f307b 100644 --- a/mingw-w64-crt/Makefile.am +++ b/mingw-w64-crt/Makefile.am @@ -20,7 +20,7 @@ else endif AM_CPPFLAGS=$(sysincludes) -AM_CFLAGS=-pipe -std=gnu99 -D_CRTBLD -D_WIN32_WINNT=0x0f00 -D__MSVCRT_VERSION__=0x700 -D__USE_MINGW_ANSI_STDIO=0 @CFGUARD_CFLAGS@ @ADD_C_CXX_WARNING_FLAGS@ @ADD_C_ONLY_WARNING_FLAGS@ +AM_CFLAGS=-pipe -std=gnu99 -masm=att -D_CRTBLD -D_WIN32_WINNT=0x0f00 -D__MSVCRT_VERSION__=0x700 -D__USE_MINGW_ANSI_STDIO=0 @CFGUARD_CFLAGS@ @ADD_C_CXX_WARNING_FLAGS@ @ADD_C_ONLY_WARNING_FLAGS@ AM_CXXFLAGS=@ADD_C_CXX_WARNING_FLAGS@ @ADD_CXX_ONLY_WARNING_FLAGS@ CPPFLAGSARM32=-mfpu=vfpv3 CPPFLAGS32=-m32 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Make CRT buildable with `-masm=intel`
在 2023-03-22 21:07, Jacek Caban 写道: That's the motivation for this? I can see a point in supporting both syntaxes in headers (which may be included by users with various compiler options), but for crt, why isn't supporting a single syntax understood by all supported compilers enough? Yes that is the only motivation. Why? Because AT is unofficial, foreign, and awkward. 1. No Intel or AMD doc ever speaks this way. This is already enough for being thrown into the dustbin of history. 2. It was designed for PDP originally, and got widespread just because Plan 9 dogs couldn't stop barking. Oh please take a look at the Go assembler, and what they've done to ARM, brilliant. 3. And, we want `xmm0 = xmm1 - xmm2` and `vsubpd xmm0, xmm1, xmm2`, not the backward nonsense `vsubpd %xmm2, %xmm1, %xmm0`; same for `cmp`. 4. And we want `mov eax, [rsi + rbx * 8 + 12]`, not `movl 12(%rsi, %rbx, 8), %eax`. Intel syntax also copes better with other tools - Microsoft compilers, NASM, IDA, x64dbg, countless assembler and disassemblers - none of them produce or accept nonstandard AT syntax in any way. There have been enough talks about that [1]; I hope I would not have to repeat myself [2]. [1] https://outerproduct.net/2021-02-13_att-asm.html [2] https://gcc.gnu.org/pipermail/gcc/2022-November/240103.html -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Make CRT buildable with `-masm=intel`
On 3/22/23 04:08, LIU Hao wrote:
This is the first attempt to allow the CRT to be built with
`-masm=intel`. This patch itself may look messy because it contains a
lot of inline changes. It should be examined with `git show
--color-words='\S'`.
I have only verified that the CRT actually builds with
{i686,x86_64}-w64-mingw32-gcc; not sure whether anything goes wrong.
Martin, would you please include this patch in your nightly tests?
`-masm=intel` requires the latest Clang, though. Older versions do not
accept Intel syntax in inline assembly (but they do output Intel syntax).
That's the motivation for this? I can see a point in supporting both
syntaxes in headers (which may be included by users with various
compiler options), but for crt, why isn't supporting a single syntax
understood by all supported compilers enough?
Thanks,
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Make CRT buildable with `-masm=intel`
在 2023/3/22 20:48, Martin Storsjö 写道: Sorry for the imprecise terminology - I meant that it expands to blank - no tokens at all, not an empty string. And it expands to blank for both AT and Intel mode. For AT it expands to a modulo operator, and for Intel it expands to blank. That's not my experience. Oh yeah, indeed. Noted. I think I will have to move that thing into a .S file, or introduce more magic.. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Make CRT buildable with `-masm=intel`
On Wed, 22 Mar 2023, LIU Hao wrote: Looking at the change, I see that you're trying to use __REGISTER_PREFIX__ to disambiguate between the two modes - but as far as I can see, __REGISTER_PREFIX__ expands to an empty string in both GCC and Clang, for both i686 and x86_64, when running in the default AT mode. So I don't really see how that mode detection is meant to work? `__REGISTER_PREFIX__` expands to a token, not a string. Sorry for the imprecise terminology - I meant that it expands to blank - no tokens at all, not an empty string. And it expands to blank for both AT and Intel mode. For AT it expands to a modulo operator, and for Intel it expands to blank. That's not my experience. $ /usr/bin/x86_64-w64-mingw32-gcc -masm=att -E -dM - < /dev/null | grep REGISTER #define __REGISTER_PREFIX__ $ cat att-intel.c #if 0 __REGISTER_PREFIX__ + 1 == 0 // `0 % + 1 == 0` for at #error att #else #error intel #endif $ /usr/bin/x86_64-w64-mingw32-gcc -c att-intel.c -masm=att att-intel.c:4:2: error: #error intel 4 | #error intel | ^ $ /usr/bin/x86_64-w64-mingw32-gcc --version | head -1 x86_64-w64-mingw32-gcc (GCC) 10-posix 20220113 // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Make CRT buildable with `-masm=intel`
在 2023/3/22 19:19, Martin Storsjö 写道:
Out of curiosity, do you have a reference to when it got this new support? (16.0.0 was just released
a few days ago.) Anyway, I'll test with the very latest from git.
Looks like Clang 14: https://gcc.godbolt.org/z/oYd4Kfvdc
The patch successfully builds with Clang for x86_64 in the default (AT) mode for x86_64, but it
breaks compilation for i686, where I get this:
:4:6: error: brackets expression not supported on this target
jmp [__imp___scprintf]
I think I had better find a workaround for this. There are a couple of issues
around this one:
1. GCC generates insane syntax for the indirect call:
jmp [DWORD PTR _foo]
instead of
jmp DWORD PTR [_foo]
2. GCC documentation says basic asm (outside a function definition)
follows `-masm=` [1]; but Clang doesn't seem so. Basic asm statements
in Clang seem to be AT, always.
[1] https://gcc.gnu.org/onlinedocs/gcc/Basic-Asm.html:
On targets such as x86 that support multiple assembler dialects
all basic asm blocks use the assembler dialect specified by the
-masm command-line option (see x86 Options). Basic asm provides no
mechanism to provide different assembler strings for different
dialects.
Looking at the change, I see that you're trying to use __REGISTER_PREFIX__ to disambiguate between
the two modes - but as far as I can see, __REGISTER_PREFIX__ expands to an empty string in both GCC
and Clang, for both i686 and x86_64, when running in the default AT mode. So I don't really see
how that mode detection is meant to work?
`__REGISTER_PREFIX__` expands to a token, not a string. For AT it expands to a modulo operator,
and for Intel it expands to blank.
So for AT `0 __REGISTER_PREFIX__ + 1` expands to `0 % +1` which yields zero. For Intel `0
__REGISTER_PREFIX__ + 1` expands to `0 + 1` which yields one.
If building with -masm=intel (I configured by adding CFLAGS="-g -O2 -masm=intel" to the configure
line), I'm getting lots of build errors though:
x86_64-w64-mingw32/include/psdk_inc/intrin-impl.h:811:1: error: unknown token
in expression
__buildreadseg(__readgsbyte, unsigned char, "gs", "b")
This is a bit strange, though. Our headers have been compilable with `-masm=intel` for many years.
Indeed your compiler seemed to want Intel syntax, but in that case it should look for the second
alternative within { | }, not the other. Does GCC also give the same error?
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Make CRT buildable with `-masm=intel`
On Wed, 22 Mar 2023, LIU Hao wrote:
This is the first attempt to allow the CRT to be built with `-masm=intel`.
This patch itself may look messy because it contains a lot of inline changes.
It should be examined with `git show --color-words='\S'`.
I have only verified that the CRT actually builds with
{i686,x86_64}-w64-mingw32-gcc; not sure whether anything goes wrong. Martin,
would you please include this patch in your nightly tests? `-masm=intel`
requires the latest Clang, though. Older versions do not accept Intel syntax
in inline assembly (but they do output Intel syntax).
Out of curiosity, do you have a reference to when it got this new support?
(16.0.0 was just released a few days ago.) Anyway, I'll test with the very
latest from git.
The patch successfully builds with Clang for x86_64 in the default (AT)
mode for x86_64, but it breaks compilation for i686, where I get this:
:4:6: error: brackets expression not supported on this target
jmp [__imp___scprintf]
^
1 error generated.
Looking at the change, I see that you're trying to use __REGISTER_PREFIX__
to disambiguate between the two modes - but as far as I can see,
__REGISTER_PREFIX__ expands to an empty string in both GCC and Clang, for
both i686 and x86_64, when running in the default AT mode. So I don't
really see how that mode detection is meant to work?
(The same issue also affects the change in __guard_dispatch_icall_dummy,
but it's not immediately appear as a build error when building
mingw-w64-crt on its own.)
If building with -masm=intel (I configured by adding CFLAGS="-g -O2
-masm=intel" to the configure line), I'm getting lots of build errors
though:
x86_64-w64-mingw32/include/psdk_inc/intrin-impl.h:811:1:
error: unknown token in expression
__buildreadseg(__readgsbyte, unsigned char, "gs", "b")
^
include/psdk_inc/intrin-impl.h:222:14:
note: expanded from macro '__buildreadseg'
__asm__ ("mov{" a " %%" z ":%[offset], %[ret] | %[ret], %%" z
":%[offset]}" \
^
:2:10: note: instantiated into assembly here
mov al, %gs:[rax]
^
../profile/mcountFunc.S:41:7: error: unknown token in expression
push %rbp
^
../math/llrint.c:13:25: error: ambiguous operand size for instruction
'fistp'
__asm__ __volatile__ ("fistp{ll} %0" : "=m" (retval) : "t" (x) : "st");
^
:2:8: note: instantiated into assembly here
fistp [rsp]
^
../stdio/scanf.S:48:11: error: unknown token in expression
pushq %rbp
^
../math/x86/_chgsignl.S:32:8: error: unknown token in expression
movq (%rdx), %rax
^
../math/x86/acosf.c:20:13: error: unknown token in expression
"fld%%st\n\t"
^
:2:6: note: instantiated into assembly here
fld %st
^
../math/x86/exp.def.h:87:71: error: ambiguous operand size for instruction
'fld'
"{ fldt %2 | fld %2 }\n\t"
/* 4 c0 */
^
:16:7: note: instantiated into assembly here
fld [rip + offset c0]
^
(Plus lots, lots more - I just tried to pick up examples of each class of
issues that I saw.)
// Martin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] crt: Make CRT buildable with `-masm=intel`
This is the first attempt to allow the CRT to be built with `-masm=intel`. This patch itself may
look messy because it contains a lot of inline changes. It should be examined with `git show
--color-words='\S'`.
I have only verified that the CRT actually builds with {i686,x86_64}-w64-mingw32-gcc; not sure
whether anything goes wrong. Martin, would you please include this patch in your nightly tests?
`-masm=intel` requires the latest Clang, though. Older versions do not accept Intel syntax in inline
assembly (but they do output Intel syntax).
--
Best regards,
LIU Hao
From c019d44f8a06e4105967d5a2de4c8109a2c6edb5 Mon Sep 17 00:00:00 2001
From: LIU Hao
Date: Wed, 22 Mar 2023 10:47:43 +0800
Subject: [PATCH] crt: Make CRT buildable with `-masm=intel`
The unofficial AT syntax will likely be kept the default in foreseeable
future. However my long-term plan is to transition to Intel syntax, even
after decades. This is the zwischenzug for allowing the CRT to be built
with GCC and latest Clang with the `-masm=intel` option, just like our
headers.
Signed-off-by: LIU Hao
---
mingw-w64-crt/cfguard/mingw_cfguard_support.c | 4 +
mingw-w64-crt/math/llrint.c | 2 +-
mingw-w64-crt/math/llrintf.c | 2 +-
mingw-w64-crt/math/llrintl.c | 2 +-
mingw-w64-crt/math/lrint.c| 2 +-
mingw-w64-crt/math/lrintf.c | 2 +-
mingw-w64-crt/math/lrintl.c | 2 +-
mingw-w64-crt/math/modf.c | 42 +
mingw-w64-crt/math/modff.c| 43 +
mingw-w64-crt/math/modfl.c| 42 +
mingw-w64-crt/math/x86/cossin.c | 81 +
mingw-w64-crt/math/x86/exp.def.h | 88 ++-
mingw-w64-crt/math/x86/pow.def.h | 45 ++
mingw-w64-crt/misc/feclearexcept.c| 6 +-
mingw-w64-crt/misc/fegetround.c | 2 +-
mingw-w64-crt/misc/winbs_uint64.c | 6 +-
mingw-w64-crt/misc/winbs_ulong.c | 2 +-
mingw-w64-crt/misc/winbs_ushort.c | 2 +-
mingw-w64-crt/stdio/_scprintf.c | 12 ++-
19 files changed, 214 insertions(+), 173 deletions(-)
diff --git a/mingw-w64-crt/cfguard/mingw_cfguard_support.c b/mingw-w64-crt/cfguard/mingw_cfguard_support.c
index cf4535afd..2c6caeb4b 100644
--- a/mingw-w64-crt/cfguard/mingw_cfguard_support.c
+++ b/mingw-w64-crt/cfguard/mingw_cfguard_support.c
@@ -21,7 +21,11 @@ static void __guard_check_icall_dummy(void) {}
// is passed via %rax.
__asm__(
"__guard_dispatch_icall_dummy:\n"
+#if 0 __REGISTER_PREFIX__ + 1 == 0 // `0 % + 1 == 0` for at
"jmp *%rax\n"
+#else
+"jmp rax\n"
+#endif
);
// This is intentionally declared as _not_ a function pointer, so that the
diff --git a/mingw-w64-crt/math/llrint.c b/mingw-w64-crt/math/llrint.c
index 4ba7af7e6..2d05878ba 100644
--- a/mingw-w64-crt/math/llrint.c
+++ b/mingw-w64-crt/math/llrint.c
@@ -10,7 +10,7 @@ long long llrint (double x)
{
long long retval = 0ll;
#if defined(_AMD64_) || defined(__x86_64__) || defined(_X86_) || defined(__i386__)
- __asm__ __volatile__ ("fistpll %0" : "=m" (retval) : "t" (x) : "st");
+ __asm__ __volatile__ ("fistp{ll} %0" : "=m" (retval) : "t" (x) : "st");
#else
int mode = fegetround();
if (mode == FE_DOWNWARD)
diff --git a/mingw-w64-crt/math/llrintf.c b/mingw-w64-crt/math/llrintf.c
index e8085ec4e..f5cd19fc2 100644
--- a/mingw-w64-crt/math/llrintf.c
+++ b/mingw-w64-crt/math/llrintf.c
@@ -10,7 +10,7 @@ long long llrintf (float x)
{
long long retval = 0ll;
#if defined(_AMD64_) || defined(__x86_64__) || defined(_X86_) || defined(__i386__)
- __asm__ __volatile__ ("fistpll %0" : "=m" (retval) : "t" (x) : "st");
+ __asm__ __volatile__ ("fistp{ll} %0" : "=m" (retval) : "t" (x) : "st");
#else
int mode = fegetround();
if (mode == FE_DOWNWARD)
diff --git a/mingw-w64-crt/math/llrintl.c b/mingw-w64-crt/math/llrintl.c
index 6a2bf73d8..d3651059c 100644
--- a/mingw-w64-crt/math/llrintl.c
+++ b/mingw-w64-crt/math/llrintl.c
@@ -10,7 +10,7 @@ long long llrintl (long double x)
{
long long retval = 0ll;
#if defined(_AMD64_) || defined(__x86_64__) || defined(_X86_) || defined(__i386__)
- __asm__ __volatile__ ("fistpll %0" : "=m" (retval) : "t" (x) : "st");
+ __asm__ __volatile__ ("fistp{ll} %0" : "=m" (retval) : "t" (x) : "st");
#else
int mode = fegetround();
if (mode == FE_DOWNWARD)
diff --git a/mingw-w64-crt/math/lrint.c b/mingw-w64-crt/math/lrint.c
index 7831446be..1bf489b85 100644
--- a/mingw-w64-crt/math/lrint.c
+++ b/mingw-w64-crt/math/lrint.c
@@ -15,7 +15,7 @@ long lrint (double x)
#if defined(_AMD64_) || defined(__x86_64__)
retval = _mm_cvtsd_si32(_mm_load_sd());
#elif defined(_X86_) || defined(__i386__)
- __asm__ __volatile__ ("fistpl %0" : "=m" (retval) : "t" (x) : "st");
+ __asm__ __volatile__ ("fistp{l} %0" : "=m" (retval) : "t" (x) : "st");
#elif
