Re: Patches submission policy change

On 03.04.2024 15:11, Christophe Lyon wrote: > On Wed, 3 Apr 2024 at 10:30, Jan Beulich wrote: >> >> On 03.04.2024 10:22, Christophe Lyon wrote: >>> Dear release managers and developers, >>> >>> TL;DR: For the sake of improving precommit CI coverage and simplifying >>> workflows, I’d like to reques

Re: Patches submission policy change

On 03.04.2024 10:57, Richard Biener wrote: > On Wed, 3 Apr 2024, Jan Beulich wrote: >> On 03.04.2024 10:45, Jakub Jelinek wrote: >>> On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon wrote: Any concerns/objections? >>> >>> I'm all for it, in fact I've been sending it like that myself f

Re: Patches submission policy change

On 03.04.2024 10:45, Jakub Jelinek wrote: > On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon wrote: >> Any concerns/objections? > > I'm all for it, in fact I've been sending it like that myself for years > even when the policy said not to. In most cases, the diff for the > regenerated fi

Re: Patches submission policy change

On 03.04.2024 10:22, Christophe Lyon wrote: > Dear release managers and developers, > > TL;DR: For the sake of improving precommit CI coverage and simplifying > workflows, I’d like to request a patch submission policy change, so > that we now include regenerated files. This was discussed during th

Re: CREL relocation format for ELF

On 28.03.2024 08:43, Fangrui Song wrote: > On Fri, Mar 22, 2024 at 6:51 PM Fangrui Song wrote: >> >> On Thu, Mar 14, 2024 at 5:16 PM Fangrui Song wrote: >>> >>> The relocation formats REL and RELA for ELF are inefficient. In a >>> release build of Clang for x86-64, .rela.* sections consume a >>>

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

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)

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)

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)

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)

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)

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)

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: x86: making better use of vpternlog{d,q}

On 24.05.2023 11:01, Hongtao Liu wrote: > On Wed, May 24, 2023 at 3:58 PM Jan Beulich via Gcc wrote: >> >> Hello, >> >> for a couple of years I was meaning to extend the use of these AVX512F >> insns beyond the pretty minimalistic ones there are so far. Now th

x86: making better use of vpternlog{d,q}

Hello, for a couple of years I was meaning to extend the use of these AVX512F insns beyond the pretty minimalistic ones there are so far. Now that I've got around to at least draft something, I ran into a couple of issues I cannot explain. I'd like to start with understanding the unexpected effect

Re: Problems when building NT kernel drivers with GCC / LD

On 28.11.2022 09:40, Jonathan Wakely wrote: > On Mon, 28 Nov 2022, 08:08 Jan Beulich via Gcc, wrote: > >> On 26.11.2022 20:04, Pali Rohár wrote: >>> On Monday 21 November 2022 08:24:36 Jan Beulich wrote: >>>> But then, with you replying to >>>> me

Re: Problems when building NT kernel drivers with GCC / LD

On 26.11.2022 20:04, Pali Rohár wrote: > On Monday 21 November 2022 08:24:36 Jan Beulich wrote: >> But then, with you replying to >> me specifically, perhaps you're wrongly assuming that I would be >> planning to look into addressing any or all of these? My earlier reply >> was merely to point out

Re: Problems when building NT kernel drivers with GCC / LD

On 20.11.2022 14:10, Pali Rohár wrote: > On Saturday 05 November 2022 02:26:52 Pali Rohár wrote: >> On Saturday 05 November 2022 01:57:49 Pali Rohár wrote: >>> On Monday 31 October 2022 10:55:59 Jan Beulich wrote: On 30.10.2022 02:06, Pali Rohár via Binutils wrote: > * GCC or LD (not sure

Re: Problems when building NT kernel drivers with GCC / LD

On 30.10.2022 02:06, Pali Rohár via Binutils wrote: > * GCC or LD (not sure who) sets memory alignment characteristics > (IMAGE_SCN_ALIGN_MASK) into the sections of PE executable binary. > These characteristics should be only in COFF object files, not > executable binaries. Specially they sho

Re: libiberty D tuple demangling

On 25.07.2022 17:45, ibuc...@gdcproject.org wrote: >> On 25/07/2022 14:13 CEST Jan Beulich wrote: >> >> >> On 25.07.2022 14:05, ibuc...@gdcproject.org wrote: On 25/07/2022 08:45 CEST Jan Beulich wrote: while commit 3f30a274913b ("libiberty: Update D symbol demangling for latest A

Re: libiberty D tuple demangling

On 25.07.2022 14:05, ibuc...@gdcproject.org wrote: >> On 25/07/2022 08:45 CEST Jan Beulich wrote: >> while commit 3f30a274913b ("libiberty: Update D symbol demangling >> for latest ABI spec") mentions in its description that tuple encoding >> has changed, there's no real adjustment to dlang_parse_

libiberty D tuple demangling

Hello, while commit 3f30a274913b ("libiberty: Update D symbol demangling for latest ABI spec") mentions in its description that tuple encoding has changed, there's no real adjustment to dlang_parse_tuple() there, nor are there any new (or replaced) test cases for that. Was this simply overlooked?