在 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&T) mode for x86_64, but it breaks compilation for i686, where I get this:<inline asm>: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&T, 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&T 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&T it expands to a modulo operator, and for Intel it expands to blank.
So for AT&T `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 [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
