Re: RFC: Formalization of the Intel assembly syntax (PR53929)

2024-01-31 Thread LIU Hao via Gcc
在 2024-01-30 12:22, Hans-Peter Nilsson 写道: It's #APP #NO_APP, not /APP /NO_APP, for x86_64-linux, even for -masm=intel. For x86_64-w64-mingw64, GCC emits `/APP`; but Clang still emits `#APP`, as other targets. (https://gcc.godbolt.org/z/oj8vdGb78) That said, I guess you're going to modify

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

2024-01-29 Thread Hans-Peter Nilsson
On Fri, 19 Jan 2024, LIU Hao wrote: > ? 2024-01-18 20:54, Jan Beulich ??: > > I'm sorry, but most of your proposal may even be considered for being > > acceptable only if you would gain buy-off from the MASM guys. Anything > > MASM treats as valid ought to be permitted by gas as well (within the >

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

2024-01-23 Thread Jan Beulich via Gcc
On 23.01.2024 10:21, LIU Hao wrote: > 在 2024-01-23 17:03, Jan Beulich 写道: >> Hmm, that would suggest to me that the Dwarf code abuses the interface. >> A "name" certainly shouldn't be an expression. And hence the result of >> the example ought to be >> >> .long "LXXYY"-1# "LXXYY" minus on

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

2024-01-23 Thread LIU Hao via Gcc
在 2024-01-23 17:03, Jan Beulich 写道: Hmm, that would suggest to me that the Dwarf code abuses the interface. A "name" certainly shouldn't be an expression. And hence the result of the example ought to be .long "LXXYY"-1# "LXXYY" minus one So I shouldn't have checked for `*` right? Th

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

2024-01-23 Thread Jan Beulich via Gcc
On 23.01.2024 10:00, LIU Hao wrote: > 在 2024-01-23 16:38, Jan Beulich 写道: >> Right, but this is very "draft". You can't blindly assume the gas you use >> actually can deal with quotation. > > Let's assume that for the time being, but there's something else; see below. > > >>> .refptr.bx: >>>

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

2024-01-23 Thread LIU Hao via Gcc
在 2024-01-23 16:38, Jan Beulich 写道: Right, but this is very "draft". You can't blindly assume the gas you use actually can deal with quotation. Let's assume that for the time being, but there's something else; see below. .refptr.bx: .quad bx Sure, this one needs quoting then, t

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

2024-01-23 Thread Jan Beulich via Gcc
On 23.01.2024 02:27, LIU Hao wrote: > 在 2024-01-22 16:39, Jan Beulich 写道: >> Right, I did some work in that direction a while ago. But iirc there are >> still cases left to be addressed. > > Attached is a draft patch for GCC, bootstrapped on {i686,x86_64}-w64-mingw32 > with GCC 13.2 and > binuti

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

2024-01-22 Thread LIU Hao via Gcc
在 2024-01-22 16:39, Jan Beulich 写道: Right, I did some work in that direction a while ago. But iirc there are still cases left to be addressed. Attached is a draft patch for GCC, bootstrapped on {i686,x86_64}-w64-mingw32 with GCC 13.2 and binutils 2.41.0. This addresses the issue when a bad n

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

2024-01-22 Thread Jan Beulich via Gcc
On 20.01.2024 13:40, LIU Hao wrote: > 在 2024-01-19 17:13, Jan Beulich 写道: >> But I see a severe issue with your aim at confining strict mode to >> compiler generated code only: In inline assembly (see your mentioning of >> APP / NO_APP above) you still potentially reference C symbols. So the >> amb

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

2024-01-20 Thread LIU Hao via Gcc
在 2024-01-19 17:13, Jan Beulich 写道: But I see a severe issue with your aim at confining strict mode to compiler generated code only: In inline assembly (see your mentioning of APP / NO_APP above) you still potentially reference C symbols. So the ambiguities don't disappear in APP / NO_APP regions

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

2024-01-20 Thread LIU Hao via Gcc
在 2024-01-19 16:19, Fangrui Song 写道: It is also unfortunate that whether the displacement is an immediate or not change the behavior of brackets. mov eax, DWORD PTR 0 # mov$0x0,%eax mov eax, DWORD PTR [0]# mov0x0,%eax mov eax, DWORD PTR sym# mov0x0,%eax with

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

2024-01-19 Thread Jan Beulich via Gcc
On 18.01.2024 17:40, LIU Hao wrote: > 在 2024-01-18 20:54, Jan Beulich 写道: >> I'm sorry, but most of your proposal may even be considered for being >> acceptable only if you would gain buy-off from the MASM guys. Anything >> MASM treats as valid ought to be permitted by gas as well (within the >> sc

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

2024-01-19 Thread Fangrui Song
On Thu, Jan 18, 2024 at 5:42 PM LIU Hao wrote: > > 在 2024-01-18 17:02, Fangrui Song 写道: > > Thanks for the proposal. I hope that -masm=intel becomes more useful:) > > > > Do you have a list of assembly in the unambiguous cases that fail to > > be parsed today as a gas PR? > > For example, > > Not

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

2024-01-18 Thread Jan Beulich via Gcc
On 19.01.2024 02:42, LIU Hao wrote: > In addition, `as -msyntax=intel -mnaked-reg` doesn't seem to be equivalent to > `.intel_syntax noprefix`: > > $ as -msyntax=intel -mnaked-reg <<< 'mov eax, DWORD PTR gs:0x48' -o a.o > {standard input}: Assembler messages: > {standard input}:1: Err

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

2024-01-18 Thread LIU Hao via Gcc
在 2024-01-18 17:02, Fangrui Song 写道: Thanks for the proposal. I hope that -masm=intel becomes more useful:) Do you have a list of assembly in the unambiguous cases that fail to be parsed today as a gas PR? For example, Not really. Most of these are results from high-level languages. For exampl

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

2024-01-18 Thread LIU Hao via Gcc
在 2024-01-18 20:54, Jan Beulich 写道: I'm sorry, but most of your proposal may even be considered for being acceptable only if you would gain buy-off from the MASM guys. Anything MASM treats as valid ought to be permitted by gas as well (within the scope of certain divergence that cannot be changed

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

2024-01-18 Thread Jan Beulich via Gcc
On 18.01.2024 06:34, LIU Hao wrote: > My complete proposal can be found at > . > Some ideas actually > reflect the AT&T syntax. I hope it helps. I'm sorry, but most of your proposal may even be considered for being acce

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

2024-01-18 Thread Fangrui Song
On Wed, Jan 17, 2024 at 9:34 PM LIU Hao wrote: > > Hello, > > There hasn't been an solution to https://gcc.gnu.org/PR53929 since almost a > dozen years ago, mostly > due to compatibility with MASM. I was told that the ambiguity of Intel syntax > should be classified > as its own limitation and d

RFC: Formalization of the Intel assembly syntax (PR53929)

2024-01-17 Thread LIU Hao via Gcc
Hello, There hasn't been an solution to https://gcc.gnu.org/PR53929 since almost a dozen years ago, mostly due to compatibility with MASM. I was told that the ambiguity of Intel syntax should be classified as its own limitation and disrecommendation. Notwithstanding, I am proposing a permanen