This is an archive of the discontinued LLVM Phabricator instance.

Always support masm syntax when intel dialect is active
AbandonedPublic

Authored by serge-sans-paille on Mar 26 2019, 2:31 AM.

Details

Reviewers
rnk
mcrosier
Summary

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.

Diff Detail

Repository
rL LLVM

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptMar 26 2019, 2:31 AM
serge-sans-paille retitled this revision from Always support masm syntax when inte dialect is active to Always support masm syntax when intel dialect is active.Mar 26 2019, 2:31 AM
rnk requested changes to this revision.Apr 2 2019, 10:59 AM

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.

This revision now requires changes to proceed.Apr 2 2019, 10:59 AM
serge-sans-paille abandoned this revision.Apr 3 2019, 12:17 AM

GNU as compatibility totally makes sense, dropping the patch, and thanks for the detailed answer!