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

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

Re: [Tree][Static Analyzer] Tree representing types and svalues type

On 17/01/2024 23:52, David Malcolm wrote: > On Tue, 2024-01-16 at 15:44 +0100, Pierrick Philippe wrote: >> Hi David, hi all, > Hi Pierrick. First, thanks for you answer. [stripping] > I confess that I've been quite sloppy in places with types in the > analyzer, keeping track of them when it's easy,

Regarding OMPD

Hello everyone, I'm sorry for not getting back to you this long time. As I mentioned The military service here is a must. Thank God I finished my military service. I am still interested in working on OMPD. Are there any plans for OMPD, soon? Would anyone be able to work with me on some parts of

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

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: Regarding OMPD

On Thu, Jan 18, 2024 at 02:36:02PM +0200, Mohamed Atef via Gcc wrote: > I'm sorry for not getting back to you this long time. As I mentioned > The military service here is a must. Thank God I finished my military > service. > I am still interested in working on OMPD. Are there any plans for OMP

Re: Regarding OMPD

Hello Mohamed, Jakub Jelinek wrote: Mohamed Atef via Gcc wrote: I am still interested in working on OMPD. Are there any plans for OMPD, soon? I think no one is currently working on OMPD or is planning to do so in the near future - but support for OMPD would be surely nice. It is surely to

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

在 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

OMPD development status

Hello all, Just to remind you, there's an OMPD branch, on the repo: https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/devel/omp/ompd What is in the branch? Initialization of the library (libgompd): the third-party tools can successfully load OMPD allocates memory for the process, i.e. (al

gcc-11-20240118 is now available

Snapshot gcc-11-20240118 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20240118/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch

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

在 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)

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