Instead of activating masm syntax by hand, better couple this activation to the syntax dialect choice.
This also fixes https://bugzilla.redhat.com/show_bug.cgi?id=1692486.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Thanks for the reminder, sorry I missed this.
This seems like it's explicitly undoing the effect of D53535 / rL345189. The whole point of that was to *disable* masm-style integer literals in standalone assembly files with .intel_syntax, so I think this is working as intended. GNU as does not accept these types of integer literals:
$ cat t.s .intel_syntax noprefix mov eax, 0dbeefh $ as t.s -o t.o && llvm-objdump -d t.o t.s: Assembler messages: t.s:2: Error: junk `beefh' after expression
By default, the standalone assembly parser aims for GNU as compatibility, so I don't think we want to change this behavior. I think if we want to support using -h suffixed hex literals, we'll need some new flag to control "masm" integer literals, or maybe just hex literals ending in 'h'.
I think there is a desire to add some kind of ml64-compatible assembler to LLVM, so there is a long term desire to have a new masm mode.
GNU as compatibility totally makes sense, dropping the patch, and thanks for the detailed answer!