use of preserve_temp_slots in copy_blkmode_from_reg

copy_blkmode_from_reg (called from expand_call) calls preserve_temp_slots without pushing a scope first. Hence it appears to be possible, and I'm appearantly running into such a case, that it calls this when temp_slot_level is zero, leading to array accesses with index -1 (resulting in ill behav

building 3.4.x with in-tree binutils 2.16.*

These patches http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02319.html http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00466.html are needed (the former in at least a rudimentary backport form) in order to be able to build a 3.4.x tree with an overlaid binutils 2.16 or newer tree. Are there any p

Bug or feature: symbol names of global/extern variables

I don't think this has anything to do with binutils; whether linking succeeds exclusively depends on the mangling method used (VC does mangle data object names, while g++ doesn't). AFAIK the standard only talks about function signatures, meaning mangling data object names is neither prohibited nor

Re: Bug or feature: symbol names of global/extern variables

>>> Wolfgang Roemer <[EMAIL PROTECTED]> 06.10.05 16:02:37 >>> >On Thu Oct 06, 2005 15:54, Michael Veksler wrote: >[..] >>> 2. I think that it will break C. As I remember, it is sometimes >>> legal in C (or in some dialects of C) to have conflicting types. >>> You may define in one transl

improved ia64 atomic ops

Richard, in the context of internal discussions regarding target/24757 I have been made aware of a change to the sync operations on ia64, and I have problems understanding >This differs from the generic code in that we know about the zero-extending >properties of cmpxchg, and the zero-ext

g++.dg/ext/packed3.C

This test contains three invocations of Ref(), but only two of them are considered ill. What I'd like to get an explanation for is why the third (middle) instance is considered correct. After all, the u member of Packed is packed, and hence all the members of Unpacked in that context are, too. Name

testsuite issue

>2005-12-01 Hans-Peter Nilsson <[EMAIL PROTECTED]> > > * gcc.dg/20041106-1.c, gcc.dg/20030321-1.c, gcc.dg/pr17112-1.c, > gcc.dg/pr17112-1.c, g++.dg/other/packed1.C, > g++.dg/other/crash-4.C, g++.dg/ext/packed8.C: Match "attribute > ignored" warnings when "packing" is the s

Re: testsuite issue

>> While most of these changes appear to be correct, I see a regression on >> *-*-netware* (which by default uses packed structures) in >> gcc.dg/20030321-1.c, and I believe the warning tested for cannot be >> expected (since the code generating the warning tests >> >> TYPE_ALIGN (TREE_TYPE (*node

Re: testsuite issue

>> While most of these changes appear to be correct, I see a regression on >> *-*-netware* (which by default uses packed structures) in >> gcc.dg/20030321-1.c, and I believe the warning tested for cannot be >> expected (since the code generating the warning tests >> >> TYPE_ALIGN (TREE_TYPE (*node

Re: g++.dg/ext/packed3.C

>>> Nathan Sidwell <[EMAIL PROTECTED]> 07.12.05 16:58:11 >>> >Jan Beulich wrote: >> This test contains three invocations of Ref(), but only two of them are >> considered ill. What I'd like to get an explanation for is why the third >> (middle

Re: g++.dg/ext/packed3.C

>>> Nathan Sidwell <[EMAIL PROTECTED]> 07.12.05 17:22:10 >>> >Jan Beulich wrote: > >> And that is precisely the reason why I think binding a reference to the >> whole object or any of its members, when the object itself is a member >> of a packed

Re: testsuite issue

>Just for the record (in case someone else has the same thoughts) >and because I'd already written most of the reply, I also >replied to your first email. See last for your follow-up. > >> What has the alignment of type 'long long' to do with structure >> packing? > >Only the obvious(?): if long l

build breakage due to r108059

Paolo, >toplevel: >2005-12-05 Paolo Bonzini <[EMAIL PROTECTED]> > > * configure.in (CONFIGURED_BISON, CONFIGURED_YACC, CONFIGURED_M4, > CONFIGURED_FLEX, CONFIGURED_LEX, CONFIGURED_MAKEINFO): Remove > "CONFIGURED_" from the AC_CHECK_PROGS invocation. Move below. > Find in

Re: g++.dg/ext/packed3.C

>It can be made to work by not packing Baz::m, and that is what g++ does (with a >warning%). Issuing an error in this case I don't think is acceptable -- I know >of users who would complain. If the user explicitly packed Baz::m field, rather >than the containing structure, I would be happy wit

Re: selection or target tools

Yes, this seems to meet the needs I expressed. Thanks, Jan >>> Paolo Bonzini <[EMAIL PROTECTED]> 23.12.05 10:10:01 >>> > One appropriate default for --with-build-tools could be the same as > the defaults for --program-transform-name. A default native build > would use 'as', a default cross build

Re: Broken check rejecting -fcf-protection and -mindirect-branch=thunk-extern

On 28.04.2020 17:00, H.J. Lu wrote: > On Tue, Apr 28, 2020 at 6:41 AM Andrew Cooper > wrote: >> >> On 28/04/2020 14:00, H.J. Lu wrote: >>> On Tue, Apr 28, 2020 at 5:43 AM Andrew Cooper >>> wrote: Hello, I raised https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93654 but it has h

Re: New x86-64 micro-architecture levels

On 13.07.2020 09:40, Florian Weimer wrote: > * Richard Biener: >>> 2. I have a library with AVX2 and FMA, which directory should it go? >> >> Eventually GCC/gas can annotate objects with the lowest architecture >> level that is applicable? > > H.J. has patches for ELF program properties. I think

Re: New x86-64 micro-architecture levels

On 21.07.2020 20:04, Florian Weimer wrote: > * Premachandra Mallappa: > >> [AMD Public Use] >> >> Hi Floarian, >> >>> I'm including a proposal for the levels below. I use single letters for >>> them, but I expect that the concrete implementation of this proposal will >>> use >>> names like “x8

Re: New x86-64 micro-architecture levels

On 22.07.2020 12:34, Florian Weimer wrote: > The remaining issue is the - vs _ issue. I think GCC currently uses > “x86-64” in places that are not part of identifiers or target triplets. > Richard mentioned “x86_64-” as a potential choice. Would it be too > awkward to have ”-march=x86_64-…”? Per

configure.{in -> ac} rename (commit 35eafcc71b) broke in-tree binutils building of gcc

Alan, gcc maintainers, I was quite surprised for my gcc 4.9.3 build (using binutils 2.25 instead of 2.24 as I had in use with 4.9.2) to fail in rather obscure ways. Quite a bit of digging resulted in me finding that gcc/configure.ac looks for configure.in in a number of binutils subtrees. Globally

Re: configure.{in -> ac} rename (commit 35eafcc71b) broke in-tree binutils building of gcc

>>> On 15.07.15 at 03:20, wrote: > On Tue, Jul 14, 2015 at 10:13:06AM +0100, Jan Beulich wrote: >> (there doesn't seem >> to be a fix for this in gcc trunk either, which I originally expected I could >> simply backport). > > The configure.in->confi

Re: PATCH: Also check configure.ac in binutils source tree

>>> On 15.07.15 at 17:18, wrote: > Here is a patch. Tested on Linux/x86-64 with native GCC as well as > cross-toolchain. > Any comments, feedbacks, objections? Comparing to the patch I sent earlier today I miss an adjustment to gcc/acinclude.m4, which also has one bad use. Jan

common subexpression elimination no longer working for asm()?

I noticed the issue with 4.9.1 (in that x86 Linux'es this_cpu_read_stable() no longer does what the comment preceding its definition promises), and the example below demonstrates this in a simplified (but contrived) way. I just now verified that trunk has the same issue; 4.8.3 still folds redundant

Re: common subexpression elimination no longer working for asm()?

>>> On 23.10.14 at 13:32, wrote: > On Wed, Oct 22, 2014 at 5:28 PM, Jan Beulich wrote: >> I noticed the issue with 4.9.1 (in that x86 Linux'es >> this_cpu_read_stable() no longer does what the comment preceding >> its definition promises), and the exam

Re: common subexpression elimination no longer working for asm()?

>>> On 23.10.14 at 15:42, wrote: > On Wed, Oct 22, 2014 at 04:28:52PM +0100, Jan Beulich wrote: >> I noticed the issue with 4.9.1 (in that x86 Linux'es >> this_cpu_read_stable() no longer does what the comment preceding >> its definition promises), and the exam

Re: common subexpression elimination no longer working for asm()?

>>> On 24.10.14 at 11:11, wrote: > On Fri, Oct 24, 2014 at 10:01:52AM +0100, Jan Beulich wrote: >> > This changed because of my http://gcc.gnu.org/PR60663 fix. >> > In your testcase the inline asm doesn't have more than one output >> > (which IMNSHO is

aarch64 asm operand checking

Hello, in the Xen project we had (meanwhile fixed) code like this (meant to be uniform between 32- and 64-bit): static inline int fls(unsigned int x) { int ret; asm("clz\t%0, %1" : "=r" (ret) : "r" (x)); return BITS_PER_LONG - ret; } Being mainly an x86 person, when I fir

Re: aarch64 asm operand checking

>>> On 29.01.15 at 09:20, wrote: > On Wed, Jan 28, 2015 at 11:54 PM, Jan Beulich wrote: >> Hello, >> >> in the Xen project we had (meanwhile fixed) code like this (meant to >> be uniform between 32- and 64-bit): >> >> static inline int fls(unsi

Re: [x86-64-psABI] RFC: Add R_X86_64_RELAX_PC32 and R_X86_64_RELAX_PLT32

>>> On 12.05.15 at 20:42, wrote: > Here is the updated proposal. I changed nop prefix from 0x48 > to 0x67 and clarified how foo@GOTPCREL(%rip) should be > resolved. Mind clarifying how 67 is better than 48? > I am proposing to add 2 new relocations, R_X86_64_RELAX_PC32 and > R_X86_64_RELAX_PLT3

AVX512 woes

Kirill, others, in the course of putting together test harness extensions for AVX512 additions to the Xen hypervisor's built-in instruction emulator I've come across a number of issues. Since it may easily be that I'm simply not knowing the full background, rather than adding bugzilla entries for

Re: [PATCH] x86: fix CVT{,T}PD2PI insns

>>> On 27.06.19 at 11:03, wrote: > With just an "m" constraint misaligned memory operands won't be forced > into a register, and hence cause #GP. So far this was guaranteed only > in the case that CVT{,T}PD2DQ were chosen (which looks to be the case on > x86-64 only). > > Instead of switching the

Re: [PATCH] x86: fix CVT{,T}PD2PI insns

>>> On 27.06.19 at 12:22, wrote: > On Thu, Jun 27, 2019 at 11:10 AM Jan Beulich wrote: >> >> >>> On 27.06.19 at 11:03, wrote: >> > With just an "m" constraint misaligned memory operands won't be forced >> > into a register, and

Re: [PATCH] x86: fix CVT{,T}PD2PI insns

>>> On 27.06.19 at 13:02, wrote: > On Thu, Jun 27, 2019 at 12:47 PM Jan Beulich wrote: >> >> >>> On 27.06.19 at 12:22, wrote: >> > On Thu, Jun 27, 2019 at 11:10 AM Jan Beulich wrote: >> >> >> >> >>> On 27.06.19 at 11

Re: [PATCH] x86: fix CVT{,T}PD2PI insns

>>> On 27.06.19 at 14:07, wrote: > On Thu, Jun 27, 2019 at 1:31 PM Jan Beulich wrote: >> >> >>> On 27.06.19 at 13:02, wrote: >> > On Thu, Jun 27, 2019 at 12:47 PM Jan Beulich wrote: >> >> >> >> >>> On 27.06.19 at

loading of zeros into {x,y,z}mm registers

Kirill, in an unrelated context I've stumbled across a change of yours from Aug 2014 (revision 213847) where you "extend" the ways of loading zeros into registers. I don't understand why this was done, and the patch submission mail also doesn't give any reason. My point is that simple VEX-encoded

Re: loading of zeros into {x,y,z}mm registers

>>> On 01.12.17 at 06:45, wrote: > On 29 Nov 08:59, Jan Beulich wrote: >> in an unrelated context I've stumbled across a change of yours >> from Aug 2014 (revision 213847) where you "extend" the ways >> of loading zeros into registers. I don

Re: x32 psABI draft version 0.2

>>> On 16.02.11 at 21:04, "H. Peter Anvin" wrote: > On 02/16/2011 11:22 AM, H.J. Lu wrote: >> Hi, >> >> I updated x32 psABI draft to version 0.2 to change x32 library path >> from lib32 to libx32 since lib32 is used for ia32 libraries on Debian, >> Ubuntu and other derivative distributions. The

Re: x32 psABI draft version 0.2

>>> On 17.02.11 at 16:49, "H.J. Lu" wrote: > On Thu, Feb 17, 2011 at 7:44 AM, Jan Hubicka wrote: >>> > According to Mozilla folks however REL+RELA scheme used by EABI leads >>> > to significandly smaller libxul.so size >>> > >>> > According to http://glandium.org/blog/?p=1177 the difference is ab

Re: x32 psABI draft version 0.2

>>> On 17.02.11 at 18:59, "H.J. Lu" wrote: > On Thu, Feb 17, 2011 at 8:11 AM, Jan Beulich wrote: >>>>> On 17.02.11 at 16:49, "H.J. Lu" wrote: >>> On Thu, Feb 17, 2011 at 7:44 AM, Jan Hubicka wrote: >>>>> > Accord

Re: x32 psABI draft version 0.2

>>> On 18.02.11 at 00:07, Jakub Jelinek wrote: > So one way to cut down the size of .rela.dyn section would be a relocation > like > R_X86_64_RELATIVE_BLOCK where applying such a relocation with r_offset O and > r_addend N would be: > uint64_t *ptr = O; > for (i = 0; i < N; i++) > ptr[i] += bias

Re: x32 psABI draft version 0.2

>>> On 18.02.11 at 18:53, "H.J. Lu" wrote: > How about only allowing REL relocations in executables and DSOes? That'd be at least part of it, but I'd still prefer not forbidding them altogether, but also not requiring an implementation to support them (just to repeat it - in a long abandoned new

Re: [x32] Allow R_X86_64_64

>>> On 12.08.11 at 06:37, "H.J. Lu" wrote: > On Mon, Aug 1, 2011 at 3:15 PM, H.J. Lu wrote: >> Hi, >> >> It turns out that x32 needs R_X86_64_64. One major reason is >> the displacement range of x32 is -2G to +2G. It isn't a problem >> for compiler since only small model is required for x32. >>

Re: [x32] Allow R_X86_64_64

>>> On 12.08.11 at 14:09, "H.J. Lu" wrote: > On Fri, Aug 12, 2011 at 12:30 AM, Jan Beulich wrote: >>>>> On 12.08.11 at 06:37, "H.J. Lu" wrote: >>> On Mon, Aug 1, 2011 at 3:15 PM, H.J. Lu wrote: >>>> Hi, >>>

Re: [x32] Allow R_X86_64_64

>>> On 12.08.11 at 15:22, "H.J. Lu" wrote: > On Fri, Aug 12, 2011 at 6:17 AM, Jan Beulich wrote: >>>>> On 12.08.11 at 14:09, "H.J. Lu" wrote: >>> On Fri, Aug 12, 2011 at 12:30 AM, Jan Beulich wrote: >>>>>>> On 12.08

Re: [x32] Allow R_X86_64_64

>>> On 12.08.11 at 19:53, "H.J. Lu" wrote: > For R_X86_64_64 relocation, if addend is 0, linker will > turn it to R_X86_64_32 and zero-extends it to 64bit. Otherwise, Rather odd a treatment, especially since at the source level one can't necessarily control the addend emitted. > linker will gene

Re: RFC: Add 32bit x86-64 support to binutils

>>> On 30.12.10 at 21:02, "H.J. Lu" wrote: > > Here is the ILP32 psABI: > > http://www.kernel.org/pub/linux/devel/binutils/ilp32/ > I think it is a gross misconception to tie the ABI to the ELF class of an object. Specifying the ABI should imo be done via e_flags or one of the unused bytes of

Re: RFC: Add 32bit x86-64 support to binutils

>>> On 04.01.11 at 21:02, Jakub Jelinek wrote: > On Tue, Jan 04, 2011 at 10:35:42AM -0800, H. Peter Anvin wrote: >> On 01/04/2011 09:56 AM, H.J. Lu wrote: >> >> >> >> I think it is a gross misconception to tie the ABI to the ELF class of >> >> an object. Specifying the ABI should imo be done via e

Re: RFC: Add 32bit x86-64 support to binutils

>>> On 05.01.11 at 09:01, "H. Peter Anvin" wrote: > On 01/04/2011 11:46 PM, Jan Beulich wrote: >>>> >>>> Oh god, please, no. >>>> >>>> I have to say I'm highly questioning to Jan's statement in the first >>&g

preprocessing question

Can anyone set me strait on why, in the following code fragment int x(unsigned); struct alt_x { unsigned val; }; #define xalt_x #define alt_x(p) x(p+1) int test(struct x *p) { return x(p->val); } the function invoked in test() is alt_x (rather than x)? I would have expe

Re: preprocessing question

>>> Daniel Jacobowitz <[EMAIL PROTECTED]> 25.09.06 18:43 >>> >On Mon, Sep 25, 2006 at 05:23:34PM +0200, Jan Beulich wrote: >> Can anyone set me strait on why, in the following code fragment >> >> int x(unsigned); >> >> struct alt_x {

RE: preprocessing question

#define xalt_x > >the preprocessor token "x" is an object-like macro standing for "alt_x", so >when we get to > #define alt_x(p) x(p+1) > > what the preprocessor sees after the first round of expansion is > >#define alt_x(p) alt_x(p+1) As pointed out before - there is *no* expan

Fwd: Re: Visibility=hidden for x86_64 Xen builds -- problems?

silent, and another one that doesn't). Thanks, Jan >>> Keir Fraser <[EMAIL PROTECTED]> 28.09.06 10:56 >>> >On 28/9/06 09:23, "Keir Fraser" <[EMAIL PROTECTED]> wrote: >> On 28/9/06 07:46, "Jan Beulich" <[EMAIL PROTECTED]> wr

frame unwind issue with discontiguous code

While I'm not certain whether gcc is able to split one function's code between different sections (if for nothing else, this might help reduce TLB pressure by moving code unlikely to be executed not just out of the main function body), by way of inline assembly the Linux kernel certainly does in ma

Re: Fwd: Re: Visibility=hidden for x86_64 Xen builds -- problems?

>>> "H. J. Lu" <[EMAIL PROTECTED]> 28.09.06 15:24 >>> >On Thu, Sep 28, 2006 at 10:45:38AM +0100, Jan Beulich wrote: >> >> 2) Why does the linker silently resolve the (32-bit PC-relative) >> relocation targeting an undefined weak symbol, yiel

unusable libatomic.so built in certain environments

In an environment with relatively old core components (dynamic loader and glibc) but with up-to-date binutils (perhaps built along with gcc) libatomic.so gets built in a way such that it is unusable on the build system. A similar issue was reported in a mail leading to http://gcc.gnu.org/ml/gcc-pat

Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX

>>> On 08.08.13 at 02:33, "H.J. Lu" wrote: > We use the .gnu_attribute directive to record an object attribute: > > enum > { > Tag_GNU_X86_EXTERN_BRANCH = 4, > }; > > for the types of external branch instructions in relocatable files. > > enum > { > /* All external branch instructions are l

Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX

>>> On 08.08.13 at 18:01, "H.J. Lu" wrote: > On Thu, Aug 8, 2013 at 12:19 AM, Jan Beulich wrote: >>>>> On 08.08.13 at 02:33, "H.J. Lu" wrote: >>> We use the .gnu_attribute directive to record an object attribute: >>> >>&

Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX

>>> On 09.08.13 at 19:03, "H.J. Lu" wrote: > On Fri, Aug 9, 2013 at 12:08 AM, Jan Beulich wrote: >>>>> On 08.08.13 at 18:01, "H.J. Lu" wrote: >>> On Thu, Aug 8, 2013 at 12:19 AM, Jan Beulich wrote: >>>>>>> On 08.0

Re: [Xen-devel] coverage license information

>>> On 04.02.13 at 17:46, Ian Lance Taylor wrote: > On Mon, Feb 4, 2013 at 6:54 AM, Frediano Ziglio > wrote: >> >> I imported some headers from Linux kernel which mainly came from >> gcov-io.h and the structures used internally by GCC. >> >> Our problem is currently about the license. In gcov-io.

Re: PATCH: PR gas/5534: "XXX PTR" isn't checked properly in Intel syntax

While I agree on the subject, I slightly disagree on the approach you took: The added flags shouldn't go on the instructions, but on their operands (otherwise you'll likely end up creating more special case code namely for movzx/movsx, but perhaps also elsewhere): Just like for registers, memory

-fpic support detection in testsuite

gcc/testsuite/lib/target-supports.exp checks whether the compiler spits out any messages when using -fpic/-fPIC; this doesn't cover the case where the compiler happily processes everything, but the linker cannot deal with the result (in the given case, because the specific gas (x86) in use accepts

Re: [Bug c/33076] Warning when passing a pointer to a const array to a function that expects a point

Andreas, besides doing this act of bookkeeping, could you also point out a solution to the problem at hand? Thanks, Jan >>> "schwab at suse dot de" <[EMAIL PROTECTED]> 19.09.07 11:47 >>> --- Comment #4 from schwab at suse dot de 2007-09-19 09:47 --- *** This bug has been marked as a

Re: [RFC] [PATCH] 32-bit pointers in x86-64

>You can't use conventional 32-bit x86 code, so there seems little or no >benefit in allowing 32 and 64-bit code to be mixed. Why not? Switching between 32- and 64-bit modes doesn't involve anything (apart from knowing the proper selector register values) that cannot be done purely in user mode.

Re: [RFC] [PATCH] 32-bit pointers in x86-64

>>You can't use conventional 32-bit x86 code, so there seems little or no >>benefit in allowing 32 and 64-bit code to be mixed. > >Why not? Switching between 32- and 64-bit modes doesn't involve anything >(apart from knowing the proper selector register values) that cannot be done >purely in user

Re: [RFC] [PATCH] 32-bit pointers in x86-64

>>> "Andrew Pinski" <[EMAIL PROTECTED]> 25.11.07 19:45 >>> >On 11/25/07, Luca <[EMAIL PROTECTED]> wrote: >> 7.1. Add __attribute__((pointer_size(XXX))) and #pragma pointer_size >> to allow 64-bit pointers in 32-bit mode and viceversa > >This is already there, try using __attribute__((mode(DI) )).

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?

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 chan

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 ("

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: 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 wrot

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

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

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

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

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 refere

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

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 s

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 >> &

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

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