You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the primary way to change x86 inline assembly dialect (intel vs AT&T) is -masm=intel & -masm=att. This is a global change, undesired if some #included code assumes AT&T.
Using .intel_syntax breaks on passing operands, as those still get generated with a leading % (#24606; https://godbolt.org/z/1xbfYsWh1). But, even if that were fixed, "m" operands would still likely remain broken due to having a completely different syntax.
A complete solution would be the ability to choose assembly dialect per assembly block. https://reviews.llvm.org/D113707 mentioned a potential option of #pragma clang asm_dialect push "att" & #pragma clang asm_dialect pop, but as far as I can tell nothing like that ever landed.
Motivating use-case is using inline intel assembly in a project which, for valgrind builds, uses <valgrind/valgrind.h> which in turn assumes AT&T assembly.
The text was updated successfully, but these errors were encountered:
@MitalAshok Something like that (but worse, i.e. ad-hoc identifiers) was what I was gonna propose if I hadn't found the previous proposal. Your attribute approach would be perfect.
Currently the primary way to change x86 inline assembly dialect (intel vs AT&T) is
-masm=intel
&-masm=att
. This is a global change, undesired if some#include
d code assumes AT&T.Using
.intel_syntax
breaks on passing operands, as those still get generated with a leading%
(#24606; https://godbolt.org/z/1xbfYsWh1). But, even if that were fixed,"m"
operands would still likely remain broken due to having a completely different syntax.A complete solution would be the ability to choose assembly dialect per assembly block. https://reviews.llvm.org/D113707 mentioned a potential option of
#pragma clang asm_dialect push "att"
&#pragma clang asm_dialect pop
, but as far as I can tell nothing like that ever landed.Motivating use-case is using inline intel assembly in a project which, for valgrind builds, uses
<valgrind/valgrind.h>
which in turn assumes AT&T assembly.The text was updated successfully, but these errors were encountered: