Re: [PATCH V2] Emit funcall external declarations only if actually used.

ping^ > ping > >> [Differences from V1: >> - Prototype for call_from_call_insn moved before comment block. >> - Reuse the `call' flag for SYMBOL_REF_LIBCALL. >> - Fallback to check REG_CALL_DECL in non-direct calls. >> - New test to check correct behavior for non-direct calls.] >> >> There are m

Re: [PATCH V2] Emit funcall external declarations only if actually used.

ping > [Differences from V1: > - Prototype for call_from_call_insn moved before comment block. > - Reuse the `call' flag for SYMBOL_REF_LIBCALL. > - Fallback to check REG_CALL_DECL in non-direct calls. > - New test to check correct behavior for non-direct calls.] > > There are many places in GCC

Re: [PATCH V4] Add warning options -W[no-]compare-distinct-pointer-types

Hi Marek. > On Thu, Aug 17, 2023 at 05:37:03PM +0200, Jose E. Marchesi via Gcc-patches > wrote: >> >> > On Thu, 17 Aug 2023, Jose E. Marchesi via Gcc-patches wrote: >> > >> >> +@opindex Wcompare-distinct-pointer-types >> >> +@item -Wcomp

Re: [PATCH] bpf: neg instruction does not accept an immediate

> The BPF virtual machine does not support neg nor neg32 instructions with > an immediate. > > The erroneous instructions were removed from binutils: > https://sourceware.org/pipermail/binutils/2023-August/129135.html > > Change the define_insn so that an immediate cannot be accepted. > > From te

[PATCH V2] Emit funcall external declarations only if actually used.

[Differences from V1: - Prototype for call_from_call_insn moved before comment block. - Reuse the `call' flag for SYMBOL_REF_LIBCALL. - Fallback to check REG_CALL_DECL in non-direct calls. - New test to check correct behavior for non-direct calls.] There are many places in GCC where alternative lo

Re: [PATCH] Emit funcall external declarations only if actually used.

Hi Jakub. Thanks for the review. > On Fri, Aug 18, 2023 at 03:53:51PM +0200, Jose E. Marchesi via Gcc-patches > wrote: >> --- a/gcc/final.cc >> +++ b/gcc/final.cc >> @@ -815,6 +815,8 @@ make_pass_compute_alignments (gcc::context *ctxt) >> reorg.cc, since th

[PATCH] Emit funcall external declarations only if actually used.

[Previous thread: https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608162.html] There are many places in GCC where alternative local sequences are tried in order to determine what is the cheapest or best alternative to use in the current target. When any of these sequences involve a libca

[COMMITTED] bpf: bump maximum frame size limit to 32767 bytes

This commit bumps the maximum stack frame size allowed for BPF functions to the maximum possible value. Tested in x86_64-linux-gnu host and target bpf-unknown-none. gcc/ChangeLog * config/bpf/bpf.opt (mframe-limit): Set default to 32767. gcc/testsuite/ChangeLog * gcc.target/bpf

Re: [PATCH V4] Add warning options -W[no-]compare-distinct-pointer-types

> On Thu, 17 Aug 2023, Jose E. Marchesi via Gcc-patches wrote: > >> +@opindex Wcompare-distinct-pointer-types >> +@item -Wcompare-distinct-pointer-types > > This @item should say @r{(C and Objective-C only)}, since the option isn't > implemented for C++. OK wit

[PATCH V4] Add warning options -W[no-]compare-distinct-pointer-types

[Changes from V3: - Previous thread: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600625.html - The tests have been augmented to check all six relational operators. In particular it covers both code paths impacted by the patch: the equality/inequality and the relational ops.] GCC e

[COMMITTED] bpf: support `naked' function attributes in BPF targets

The kernel selftests and other BPF programs make extensive use of the `naked' function attribute with bodies written using basic inline assembly. This patch adds support for the attribute to bpf-unkonwn-none, makes it to inhibit warnings due to lack of explicit `return' statement, and updates docu

Re: [PATCH] bpf: fix pseudoc w regs for small modes [PR111029]

> On Tue, Aug 15, 2023 at 9:03 PM Jose E. Marchesi via Gcc-patches > wrote: >> >> >> Hello David. >> Thanks for the patch. >> >> OK. > > Picking a random patch/mail for this question - how do we maintain BPF > support for the most recent GCC

Re: [PATCH] bpf: remove useless define_insn for extendsisi2

OK. Thanks! > This define_insn is never used, since a sign-extend to the same mode is > just a move, so delete it. > > Tested on x86_64-linux-gnu host for bpf-unknown-none target. > > gcc/ > > * config/bpf/bpf.md (extendsisi2): Delete useless define_insn. > --- > gcc/config/bpf/bpf.md | 7

Re: [PATCH] bpf: fix pseudoc w regs for small modes [PR111029]

Hello David. Thanks for the patch. OK. > In the BPF pseudo-c assembly dialect, registers treated as 32-bits > rather than the full 64 in various instructions ought to be printed as > "wN" rather than "rN". But bpf_print_register () was only doing this > for specifically SImode registers, meani

[COMMITTED] bpf: liberate R9 for general register allocation

We were reserving one of the hard registers in BPF in order to implement dynamic stack allocation: alloca and VLAs. However, there is kernel code that has inline assembly that requires all the non-fixed registers to be available for register allocation. This patch: 1. Liberates r9 that is now ava

[COMMITTED] bpf: allow exceeding max num of args in BPF when always_inline

BPF currently limits the number of registers used to pass arguments to functions to five registers. There is a check for this at function expansion time. However, if a function is guaranteed to be always inlined (and its body never generated) by virtue of the always_inline attribute, it can "rece

Re: [PATCH] bpf: Fixed GC mistakes in BPF builtins code.

Hi Cuper. OK. Hopefully all the roots are marked now to avoid these nodes being collected. Thanks. > Hi everyone, > > This patch fixes BPF CO-RE builtins support that missed information for > garbage collector (GC). > > The BPF CO-RE implementation defines several data structures that keep >

Re: [v2 PATCH 2/2] bpf: CO-RE builtins support tests.

OK. Thanks. > Hi, > > Resending this patch since I have noticed I had a testcase added in > previous patch. Makes more sense here. > > Thanks, > Cupertino > > From 334e9ae0f428f6573f2a5e8a3067a4d181b8b9c5 Mon Sep 17 00:00:00 2001 > From: Cupertino Miranda > Date: Thu, 27 Jul 2023 18:05:22 +0100

Re: [v2 PATCH 1/2] bpf: Implementation of BPF CO-RE builtins

Ok. Thanks! > From fda9603ded735205b6e20fc5b65a04f8d15685e6 Mon Sep 17 00:00:00 2001 > From: Cupertino Miranda > Date: Thu, 6 Apr 2023 15:22:48 +0100 > Subject: [PATCH v2 1/2] bpf: Implementation of BPF CO-RE builtins > > This patch updates the support for the BPF CO-RE builtins > __builtin_pre

Re: [PATCH 1/2] bpf: Implementation of BPF CO-RE builtins

> Jose E. Marchesi writes: > >>> This patch updates the support for the BPF CO-RE builtins >>> __builtin_preserve_access_index and __builtin_preserve_field_info, >>> and adds support for the CO-RE builtins __builtin_btf_type_id, >>> __builtin_preserve_type_info and __builtin_preserve_enum_value.

Re: [PATCH 1/2] bpf: Implementation of BPF CO-RE builtins

> This patch updates the support for the BPF CO-RE builtins > __builtin_preserve_access_index and __builtin_preserve_field_info, > and adds support for the CO-RE builtins __builtin_btf_type_id, > __builtin_preserve_type_info and __builtin_preserve_enum_value. > > These CO-RE relocations are now c

[COMMITTED] bpf: disable tail call optimization in BPF targets

clang disables tail call optimizations in BPF targets. Do the same in GCC. gcc/ChangeLog: * config/bpf/bpf.cc (bpf_option_override): Disable tail-call optimizations in BPF target. --- gcc/config/bpf/bpf.cc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/gcc/config/bpf/bpf

Re: [PATCH] bpf: ISA V4 sign-extending move and load insns [PR110782,PR110784]

Hi David. Thanks for the patch. > BPF ISA V4 introduces sign-extending move and load operations. This > patch makes the BPF backend generate those instructions, when enabled > and useful. > > A new option, -m[no-]smov gates generation of these instructions, and is > enabled by default for -mcpu

Re: [PATCH] bpf: minor doc cleanup for command-line options

Hi David, thanks for the patch. OK. > This patch makes some minor cleanups to eBPF options documented in > invoke.texi: > - Delete some vestigal docs for removed -mkernel option > - Add -mbswap and -msdiv to the option summary > - Note the negative versions of several options > - Note that

Re: [PATCH] bpf: correct pseudo-C template for add3 and sub3

> The pseudo-C output templates for these instructions were incorrectly > using operand 1 rather than operand 2 on the RHS, which led to some > very incorrect assembly generation with -masm=pseudoc. > > Tested on bpf-unknown-none. > OK? OK. Thanks for spotting and fixing this! > > gcc/ > >

Re: [PATCH v2 2/2] bpf: add v3 atomic instructions

OK. Thanks! > [Changes from v1: fix merge issue in invoke.texi] > > This patch adds support for the general atomic operations introduced in > eBPF v3. In addition to the existing atomic add instruction, this adds: > - Atomic and, or, xor > - Fetching versions of these operations (including add

[COMMITTED] bpf: fix generation of neg and neg32 BPF instructions

This patch fixes GCC to generate correct neg and neg32 instructions, which do not take a source register operand. A couple of new tests are added. Tested in bpf-unknown-none. gcc/ChangeLog 2023-07-26 Jose E. Marchesi * config/bpf/bpf.md: Fix neg{SI,DI}2 insn. gcc/testsuite/ChangeLo

Re: [PATCH 2/2] bpf: add v3 atomic instructions

Hi David. > +<<< HEAD There is a merge problem there. > @opindex mbswap > @item -mbswap > Enable byte swap instructions. Enabled for CPU v4 and above. > @@ -24715,6 +24716,12 @@ Enable byte swap instructions. Enabled for CPU v4 > and above. > @item -msdiv > Enable signed division a

Re: [PATCH 1/2] bpf: don't print () in bpf_print_operand_address

Hi David. > Unfortunately, the pseudo-C dialect syntax used for some of the v3 > atomic instructions clashes with unconditionally printing the > surrounding parentheses in bpf_print_operand_address. > > Instead, place the parentheses in the output templates where needed. > > Tested in bpf-unknow

Re: [COMMITTED] bpf: add pseudo-c asm dialect for "nop"

> The define_insn "nop" was missing a template for the pseudo-c dialect, > so the normal syntax was unconditionally emitted. Thank you. > Tested on bpf-unknown-none, committed as obvious. > > gcc/ > > * config/bpf/bpf.md (nop): Add pseudo-c asm dialect template. > --- > gcc/config/bpf/bp

[COMMITTED] bpf: sdiv/smod are now part of BPF V4

We used to support signed division and signed modulus instructions in the XBPF GCC-specific extensions to BPF. However, BPF catched up by adding these instructions in the V4 of the ISA. This patch changes GCC in order to use sdiv/smod instructions when -mcpu=v4 or higher. The testsuite and the m

[COMMITTED] bpf: remove -mkernel option and BPF_KERNEL_VERSION_CODE

Having the ability of specifying a target kernel version when building a BPF program is one of these things that sound pretty good in theory, but simply don't work in practice: kernels in practice contain backports, etc. Also, the addition of CO-RE to BPF has made this uneccessary. This patch rem

[COMMITTED] bpf: make use of the bswap{16,32,64} V4 BPF instruction

This patch makes the BPF backend to use the new V4 bswap{16,32,64} instructions in order to implement the __builtin_bswap{16,32,64} built-ins. It also adds support for -mcpu=v4 and -m[no]bswap command-line options. Tests and doc updates are includes. Tested in bpf-unknown-none. gcc/ChangeLog

Re: [PATCH v4] bpf: fixed template for neg (added second operand)

Better with the commit message. OK. Thanks. > This patch fixes define_insn for "neg" to support 2 operands. > Initial implementation assumed the format "neg %0" while the instruction > allows both a destination and source operands. The second operand can > either be a register or an immediate v

Re: [PATCH v3] bpf: fixed template for neg (added second operand)

Hi Cuper. OK. Thanks! > From 7756a4becd1934e55d6d14ac4a9fd6d408a4797b Mon Sep 17 00:00:00 2001 > From: Cupertino Miranda > Date: Fri, 21 Jul 2023 17:40:07 +0100 > Subject: [PATCH v3] bpf: fixed template for neg (added second operand) > > gcc/ChangeLog: > > * config/bpf/bpf.md: fixed temp

Re: [PATCH v3] bpf: pseudo-c assembly dialect support

> Thanks for the suggestions/fixes in changelog. > Inlined new patch. > > Cupertino > >>> gcc/ChangeLog: >>> >>> * config/bpf/bpf.opt: Added option -masm=. >>> * config/bpf/bpf-opts.h: Likewize. >>> * config/bpf/bpf.cc: Changed it to conform with new pseudoc >>> dialect support.

Re: [PATCH v2] bpf: pseudo-c assembly dialect support

> gcc/ChangeLog: > > * config/bpf/bpf.opt: Added option -masm=. > * config/bpf/bpf-opts.h: Likewize. > * config/bpf/bpf.cc: Changed it to conform with new pseudoc > dialect support. > * config/bpf/bpf.h: Likewise. > * config/bpf/bpf.md: Added pseudo-c templat

Re: [PATCH] bpf: pseudo-c assembly dialect support

Hello Cuper. Thanks for the patch. We will need an update for the "eBPF Options" section in the GCC manual, documenting -masm=@var{dialect} and the supported values. Can you please add it and re-submit? > Hi everyone, > > Looking forward to all your reviews. > > Best regards, > Cupertino > >

[COMMITTED] bpf: enable instruction scheduling

commit 53d12ecd624ec901d8449cfa1917f6f90e910927 (HEAD -> master, origin/master, origin/HEAD) Author: Jose E. Marchesi Date: Fri Jul 14 13:54:06 2023 +0200 bpf: enable instruction scheduling This patch adds a dummy FSM to bpf.md in order to get INSN_SCHEDULING defined. If th

Re: [PATCH 0/9] Add btf_decl_tag C attribute

> On Wed, Jul 12, 2023 at 2:44 PM Jose E. Marchesi > wrote: >> >> >> [Added Eduard Zingerman in CC, who is implementing this same feature in >> clang/llvm and also the consumer component in the kernel (pahole).] >> >> Hi Richard. >> >> > On Tue, Jul 11, 2023 at 11:58 PM David Faust via Gcc-patc

Re: [PATCH 0/9] Add btf_decl_tag C attribute

[Added Eduard Zingerman in CC, who is implementing this same feature in clang/llvm and also the consumer component in the kernel (pahole).] Hi Richard. > On Tue, Jul 11, 2023 at 11:58 PM David Faust via Gcc-patches > wrote: >> >> Hello, >> >> This series adds support for a new attribute, "btf

Re: [committed] Docs: Fix formatting issues in BPF built-ins documentation

Hi Sandra. > This section of the GCC manual had some issues with lines in the > example overflowing into the right margin of the PDF-format document, > but as I looked at it more closely I also saw that it was full of > missing or incorrect Texinfo markup, too. I've cleaned it up thusly. Thank

Re: [patch] bpf: Fix double whitespace warning

> Hi! > > Since a recent commit, the BPF target produces a new warning due to > two consecutive non-quoted spaces in a message. This'll fix it: > > gcc/ > * config/bpf/bpf.cc (bpf_option_override): Fix doubled space. > > > Ok? OK. Thanks for the patch. (Sorry I didn't fix this when you f

Re: [PATCH] bpf: fix memory constraint of ldx/stx instructions [PR108790]

Hi David. > In some cases where the target memory address for an ldx or stx > instruction could be reduced to a constant, GCC could emit a malformed > instruction like: > > ldxdw %r0,0 > > Rather than the expected form: > > ldxdw %rX, [%rY + OFFSET] > > This is due to the constraint allo

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

> On Thu, Dec 8, 2022 at 2:56 AM Jose E. Marchesi via Gcc-patches > wrote: >> >> The expand_expr_divmod function in expr.cc attempts to optimize cases >> where both arguments of a division/modulus are known to be positive >> when interpreted as signed. In these c

[COMMITTED] bpf: disable -fstack-protector in BPF

The stack protector is not supported in BPF. This patch disables -fstack-protector in bpf-* targets, along with the emission of a note indicating that the feature is not supported in this platform. Regtested in bpf-unknown-none. gcc/ChangeLog: * config/bpf/bpf.cc (bpf_option_override):

Re: [PATCH,WWWDOCS] htdocs: add an Atom feed for GCC news

> On Wed, 11 Jan 2023, Thomas Schwinge wrote: >> On 2022-12-23T10:50:13+0100, "Jose E. Marchesi via Gcc-patches" >> wrote: >>> This patch adds an Atom feed for GCC news, which can then be easily >>> aggregated in other sites, such as the GNU

Re: [PATCH] sched-deps: do not schedule pseudos across calls [PR108117]

> On Fri, 23 Dec 2022, Jose E. Marchesi wrote: > >> > +1 for trying this FWIW. There's still plenty of time to try an >> > alternative solution if there are unexpected performance problems. >> >> Let me see if Alexander's patch fixes the issue at hand (it must) and >> will also do some regressi

Re: [PATCH,WWWDOCS] htdocs: rotate news

> On Fri, 23 Dec 2022, Jose E. Marchesi via Gcc-patches wrote: >> htdocs/index.html | 24 >> htdocs/news.html | 24 >> 2 files changed, 24 insertions(+), 24 deletions(-) > > Okay, thank you. > > And you

Re: [PATCH,WWWDOCS] htdocs: news: GCC BPF in Compiler Explorer

> On Fri, 23 Dec 2022, Jose E. Marchesi via Gcc-patches wrote: >> This patch adds an entry to the News section in index.html, announcing >> the availability of a nightly build of bpf-unknown-none-gcc. > > Nice! > >> +https://godbolt.org";>GCC BPF in Comp

Re: [PATCH,WWWDOCS] htdocs: add an Atom feed for GCC news

>> Hi! >> >> On 2022-12-23T10:50:13+0100, "Jose E. Marchesi via Gcc-patches" >> wrote: >>> This patch adds an Atom feed for GCC news, which can then be easily >>> aggregated in other sites, such as the GNU planet >>> (https://planet.

Re: [PATCH,WWWDOCS] htdocs: add an Atom feed for GCC news

> Hi! > > On 2022-12-23T10:50:13+0100, "Jose E. Marchesi via Gcc-patches" > wrote: >> This patch adds an Atom feed for GCC news, which can then be easily >> aggregated in other sites, such as the GNU planet >> (https://planet.gnu.org). >> >&g

Re: [PATCH v2] bpf: correct bpf_print_operand for floats [PR108293]

> Hi Jose, > > As we discussed on IRC, since we don't currently define > TARGET_SUPPORTS_WIDE_INT it is safer to keep the handling for VOIDmode > CONST_DOUBLEs. My current understanding is that it may be needed if the > host is a 32-bit platform. > > I also added a gcc_unreachable () as you point

Re: [PATCH] bpf: correct bpf_print_operand for floats [PR108293]

Hi David. Thanks for the patch. > diff --git a/gcc/config/bpf/bpf.cc b/gcc/config/bpf/bpf.cc > index 2aeaeaf309b..9dde3944e9c 100644 > --- a/gcc/config/bpf/bpf.cc > +++ b/gcc/config/bpf/bpf.cc > @@ -880,13 +880,20 @@ bpf_print_operand (FILE *file, rtx op, int code > ATTRIBUTE_UNUSED) >o

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

ping. Would this be a good approach for fixing the issue? > Hi Jakub. > >> On Thu, Dec 08, 2022 at 02:02:36PM +0100, Jose E. Marchesi wrote: >>> So, I guess the right fix would be to call assemble_external_libcall >>> during final? The `.global FOO' directive would be generated >>> immediately

Re: [PATCH V2] Disable sched1 in functions that call setjmp

>> Am 24.12.2022 um 09:11 schrieb Alexander Monakov via Gcc-patches >> : >> >>  >>> On Fri, 23 Dec 2022, Qing Zhao wrote: >>> >>> BTW, Why sched1 is not enabled on x86 by default? >> >> Register allocation is tricky on x86 due to small number of general-purpose >> registers, and sched1 can m

Re: [PATCH V2] Disable sched1 in functions that call setjmp

> On Fri, 23 Dec 2022, Jose E. Marchesi wrote: > >> > (scheduling across calls in sched2 is somewhat dubious as well, but >> > it doesn't risk register pressure issues, and on VLIW CPUs it at least >> > can result in better VLIW packing) >> >> Does sched2 actually schedule across calls? All the

Re: [PATCH V2] Disable sched1 in functions that call setjmp

> On Fri, 23 Dec 2022, Qing Zhao wrote: >> >> I am a little confused, you mean pre-RA scheduler does not look at the >> >> data flow >> >> information at all when scheduling insns across calls currently? >> > >> > I think it does not inspect liveness info, and may extend lifetime of a >> > pse

Re: [PATCH V2] Disable sched1 in functions that call setjmp

> Alexander Monakov via Gcc-patches writes: >> On Thu, 22 Dec 2022, Jose E. Marchesi via Gcc-patches wrote: >> >>> The first instruction scheduler pass reorders instructions in the TRY >>> block in a way `b=true' gets executed before the call to the functio

[PATCH,WWWDOCS] htdocs: rotate news

--- htdocs/index.html | 24 htdocs/news.html | 24 2 files changed, 24 insertions(+), 24 deletions(-) diff --git a/htdocs/index.html b/htdocs/index.html index 2ddee6f6..2ab65a95 100644 --- a/htdocs/index.html +++ b/htdocs/index.html @@ -92,30 +92

[PATCH,WWWDOCS] htdocs: add an Atom feed for GCC news

This patch adds an Atom feed for GCC news, which can then be easily aggregated in other sites, such as the GNU planet (https://planet.gnu.org). The feed lives in a file news.xml, and this patch initializes it with the latest entry in News as an example. --- htdocs/index.html | 9 - htdoc

[PATCH,WWWDOCS] htdocs: news: GCC BPF in Compiler Explorer

This patch adds an entry to the News section in index.html, announcing the availability of a nightly build of bpf-unknown-none-gcc. --- htdocs/index.html | 6 ++ 1 file changed, 6 insertions(+) diff --git a/htdocs/index.html b/htdocs/index.html index 655b7373..e91fadf1 100644 --- a/htdocs/ind

[PATCH V2] Disable sched1 in functions that call setjmp

When the following testcase is built with -fschedule-insns in either x86_64 or aarch64: #include #include #include jmp_buf ex_buf__; #define TRY do{ if( !setjmp(ex_buf__) ){ #define CATCH } else { #define ETRY } }while(0) #define THROW longjmp(ex_buf__, 1) int f(int x)

[PATCH] Disable sched1 in functions that call setjmp

When the following testcase is built with -fschedule-insns in either x86_64 or aarch64: jmp_buf ex_buf__; int f(int x) { int arr[] = {1,2,6,8,9,10}; int lo=0; int hi=5; while(lo<=hi) { int mid=(lo+hi)/2; if(arr[mid]==x) { THROW; } else if(arr[mid]

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

Hi Jakub. > On Thu, Dec 08, 2022 at 02:02:36PM +0100, Jose E. Marchesi wrote: >> So, I guess the right fix would be to call assemble_external_libcall >> during final? The `.global FOO' directive would be generated >> immediately before the call sequence, but I guess that would be ok. > > During

Re: [PATCH] bpf: add define_insn for bswap

Hi David. > The eBPF architecture provides 'end[be,le]' instructions for endianness > swapping. Add a define_insn for bswap2 to use them instaed of > falling back on a libcall. > > Tested on bpf-unknown-none, no known regressions. > > OK to commit? > Thanks OK for master. Thanks! > gcc/ > >

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

>> Am 08.12.2022 um 11:56 schrieb Jose E. Marchesi via Gcc-patches >> : >> >> The expand_expr_divmod function in expr.cc attempts to optimize cases >> where both arguments of a division/modulus are known to be positive >> when interpreted as signed. In t

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

Hi Jakub. > On Thu, Dec 08, 2022 at 11:59:44AM +0100, Jose E. Marchesi via Gcc-patches > wrote: >> gcc/ChangeLog >> >> * expr.cc (expand_expr_divmod): Avoid side-effects of trying >> sequences involving funcalls in optimization. > > That look

[PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

The expand_expr_divmod function in expr.cc attempts to optimize cases where both arguments of a division/modulus are known to be positive when interpreted as signed. In these cases, both signed division and unsigned division will raise the same value, and therefore the cheapest option can be used.

Re: [PATCH] bpf: Use enum for resolved overloaded builtins

Hi David. > Change several places in the eBPF backend dealing with overloaded > built-in functions to consistently use the enum bpf_builtins type, > rather than variously using integer constants or booleans. The result is > eaiser to read and extend. > > Tested on bpf-unknown-none, no known regr

Re: [PATCH v3] bpf: add preserve_field_info builtin

Hi David. Thanks for the updates. OK for master. >>> I'm not sure whether this behavior is a known limitation or an >>> oversight. In my opinion it makes more sense to error at compile time, >>> becuase even after the loader patches the return value it still will >>> not be correct for these ca

Re: [PATCH v2] bpf: add preserve_field_info builtin

> Hi Jose, > > Thanks for your comments. I think I've addressed them all in the updated > patch below. > >>>+ get_inner_reference (src, &bitsize, &bitpos, &var_off, &mode, &unsignedp, >>>+ &reversep, &volatilep); >> >>Since the information returned by the builtin is always cons

Re: [PATCH] bpf: add preserve_field_info builtin

Hi David. Thanks for the patch. Please see a few comments below. > @@ -975,6 +978,161 @@ static tree bpf_core_compute (tree, vec > *); > static int bpf_core_get_index (const tree); > static bool is_attr_preserve_access (tree); > > +static void > +maybe_make_core_relo (tree expr, enum btf_c

Re: [PATCH V2] place `const volatile' objects in read-only sections

> On 8/5/22 05:41, Jose E. Marchesi via Gcc-patches wrote: >> [Changes from V1: >> - Added a test.] >> >> It is common for C BPF programs to use variables that are implicitly >> set by the BPF loader and run-time. It is also necessary for these >> variabl

[COMMITTED] bpf: remove unused variables from bpf_expand_{prologue,epilogue}

gcc/ChangeLog: * config/bpf/bpf.cc (bpf_expand_prologue): Remove unused automatic `insn'. (bpf_expand_epilogue): Likewise. --- gcc/config/bpf/bpf.cc | 18 -- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/gcc/config/bpf/bpf.cc b/gcc/config

Re: [PATCH] bpf: Fix unused variable warning

Hi Jan. > Building for for bpf-unknown-none target, recent GCCs will issue an unused > variable warning as the REGNO_REG_CLASS macro doesn't actually use its > argument. Reference the argument as (void) to silence the warning. > > .../gcc/configure --prefix=... --enable-werror-always --enable-la

Re: [COMMITTED] bpf: define __bpf__ as well as __BPF__ as a target macro

> On Mon, Aug 29, 2022 at 1:16 PM Jose E. Marchesi via Gcc-patches > wrote: >> >> >> LLVM defines both __bpf__ and __BPF_ as target macros. >> GCC was defining only __BPF__. >> >> This patch defines __bpf__ as a target macro for BPF. >>

Re: [PATCH v2] bpf: handle anonymous members in CO-RE reloc [PR106745]

> [changes from v1: simplify the new conditional logic as suggested.] > > The old method for computing a member index for a CO-RE relocation > relied on a name comparison, which could SEGV if the member in question > is itself part of an anonymous inner struct or union. > > This patch changes the

[COMMITTED] bpf: define __bpf__ as well as __BPF__ as a target macro

LLVM defines both __bpf__ and __BPF_ as target macros. GCC was defining only __BPF__. This patch defines __bpf__ as a target macro for BPF. Tested in bpf-unknown-none. gcc/ChangeLog: * config/bpf/bpf.cc (bpf_target_macros): Define __bpf__ as a target macro. --- gcc/config/bpf/

Re: [PATCH] bpf: handle anonymous members in CO-RE reloc [PR106745]

Hi David. > The old method for computing a member index for a CO-RE relocation > relied on a name comparison, which could SEGV if the member in question > is itself part of an anonymous inner struct or union. > > This patch changes the index computation to not rely on a name, while > maintaining

[PATCH V3] Add warning options -W[no-]compare-distinct-pointer-types

GCC emits pedwarns unconditionally when comparing pointers of different types, for example: int xdp_context (struct xdp_md *xdp) { void *data = (void *)(long)xdp->data; __u32 *metadata = (void *)(long)xdp->data_meta; __u32 ret; if (metadata + 1 > data)

Re: [PATCH V2] Add warning options -W[no-]compare-distinct-pointer-types

> On Thu, 18 Aug 2022, Jose E. Marchesi via Gcc-patches wrote: > >> diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc >> index de8780a1502..04af02add37 100644 >> --- a/gcc/c/c-typeck.cc >> +++ b/gcc/c/c-typeck.cc >> @@ -12397,7 +12397,8 @@ build_binary_op

[COMMITTED] bpf: facilitate constant propagation of function addresses

eBPF effectively supports two kind of call instructions: - The so called pseudo-calls ("bpf to bpf"). - External calls ("bpf to kernel"). The BPF call instruction always gets an immediate argument, whose interpretation varies depending on the purpose of the instruction: - For pseudo-calls, the

Re: [PATCH V2] place `const volatile' objects in read-only sections

ping > [Changes from V1: > - Added a test.] > > It is common for C BPF programs to use variables that are implicitly > set by the BPF loader and run-time. It is also necessary for these > variables to be stored in read-only storage so the BPF verifier > recognizes them as such. This leads to d

[PATCH V2] Add warning options -W[no-]compare-distinct-pointer-types

Hi Joseph. > On Fri, 5 Aug 2022, Jose E. Marchesi via Gcc-patches wrote: > >> +Wcompare-distinct-pointer-types >> +C C++ Var(warn_compare_distinct_pointer_types) Warning Init(1) >> +Warn if pointers of distinct types are compared without a cast. > > There'

[PATCH] Add warning options -W[no-]compare-distinct-pointer-types

GCC emits pedwarns unconditionally when comparing pointers of different types, for example: int xdp_context (struct xdp_md *xdp) { void *data = (void *)(long)xdp->data; __u32 *metadata = (void *)(long)xdp->data_meta; __u32 ret; if (metadata + 1 > data)

[PATCH V2] place `const volatile' objects in read-only sections

[Changes from V1: - Added a test.] It is common for C BPF programs to use variables that are implicitly set by the BPF loader and run-time. It is also necessary for these variables to be stored in read-only storage so the BPF verifier recognizes them as such. This leads to declarations using b

Re: [PATCH] place `const volatile' objects in read-only sections

Hi Richard. > On Fri, Aug 5, 2022 at 3:27 AM Jose E. Marchesi via Gcc-patches > wrote: >> >> >> Hi people! >> >> First of all, a bit of context. >> >> It is common for C BPF programs to use variables that are implicitly set >> by the under

[PATCH] place `const volatile' objects in read-only sections

Hi people! First of all, a bit of context. It is common for C BPF programs to use variables that are implicitly set by the underlying BPF machinery and not by the program itself. It is also necessary for these variables to be stored in read-only storage so the BPF verifier recognizes them as s

[COMMITED] testsuite: btf: fix regexps in btf-int-1.c

The regexps in hte test btf-int-1.c were not working properly with the commenting style of at least one target: powerpc64le-linux-gnu. This patch changes the test to use better regexps. Tested in bpf-unkonwn-none, x86_64-linux-gnu and powerpc64le-linux-gnu. Pushed to master as obvious. gcc/tes

Re: [PATCH] btf: do not use the CHAR `encoding' bit for BTF

> On 8/2/22 08:42, Jose E. Marchesi wrote: >> >>> On 7/26/22 14:58, Indu Bhagat wrote: >>>> On 7/22/22 4:23 AM, Jose E. Marchesi via Gcc-patches wrote: >>>>> >>>>> Contrary to CTF and our previous expectations, as per [1], turns o

Re: [PATCH] btf: do not use the CHAR `encoding' bit for BTF

> On 7/26/22 14:58, Indu Bhagat wrote: >> On 7/22/22 4:23 AM, Jose E. Marchesi via Gcc-patches wrote: >>> >>> Contrary to CTF and our previous expectations, as per [1], turns out >>> that in BTF: >>> >>> 1) The `encoding' field in intege

Re: [PATCH V2] btf: emit linkage information in BTF_KIND_FUNC entries

> On 7/12/22 08:13, Jose E. Marchesi via Gcc-patches wrote: >> >> The kernel bpftool expects BTF_KIND_FUNC entries in BTF to include an >> annotation reflecting the linkage of functions (static, global). For >> whatever reason they abuse the `vlen' field of th

Re: [PATCH 1/2] Allow subtarget customization of CC1_SPEC

Hi Sebastian. I find "subtarget" confusing in this context. If it is about rtems.h, linux.h or sol2.h, wouldn't this be better called OS_CC1_SPEC or similar? These files specify configurations that apply to a set of targets, not to a subset of a target... > gcc/ChangeLog: > > * gcc.cc (

[PATCH] btf: do not use the CHAR `encoding' bit for BTF

Contrary to CTF and our previous expectations, as per [1], turns out that in BTF: 1) The `encoding' field in integer types shall not be treated as a bitmap, but as an enumerated, i.e. these bits are exclusive to each other. 2) The CHAR bit in `encoding' shall _not_ be set when emitting ty

Re: kernel sparse annotations vs. compiler attributes and debug_annotate_{type,decl} WAS: Re: [PATCH 0/9] Add debug_annotate attributes

> On 7/14/22 8:09 AM, Jose E. Marchesi wrote: >> Hi Yonghong. >> >>> On 7/7/22 1:24 PM, Jose E. Marchesi wrote: Hi Yonghong. > On 6/21/22 9:12 AM, Jose E. Marchesi wrote: >> >>> On 6/17/22 10:18 AM, Jose E. Marchesi wrote: Hi Yonghong. > On 6/15/22

Re: kernel sparse annotations vs. compiler attributes and debug_annotate_{type,decl} WAS: Re: [PATCH 0/9] Add debug_annotate attributes

Hi Yonghong. > On 7/7/22 1:24 PM, Jose E. Marchesi wrote: >> Hi Yonghong. >> >>> On 6/21/22 9:12 AM, Jose E. Marchesi wrote: > On 6/17/22 10:18 AM, Jose E. Marchesi wrote: >> Hi Yonghong. >> >>> On 6/15/22 1:57 PM, David Faust wrote: On 6/14/22 22:53, Yong

[PATCH V2] btf: emit linkage information in BTF_KIND_FUNC entries

The kernel bpftool expects BTF_KIND_FUNC entries in BTF to include an annotation reflecting the linkage of functions (static, global). For whatever reason they abuse the `vlen' field of the BTF_KIND_FUNC entry instead of adding a variable-part to the record like it is done with other entry kinds

Re: [PATCH] btf: emit linkage information in BTF_KIND_FUNC entries

> On 7/8/22 11:30 AM, Jose E. Marchesi via Gcc-patches wrote: >> >> The kernel bpftool expects BTF_KIND_FUNC entries in BTF to include an >> annotation reflecting the linkage of functions (static, global). For >> whatever reason they (ab)use the `vlen'

[PATCH] btf: emit linkage information in BTF_KIND_FUNC entries

The kernel bpftool expects BTF_KIND_FUNC entries in BTF to include an annotation reflecting the linkage of functions (static, global). For whatever reason they (ab)use the `vlen' field of the BTF_KIND_FUNC entry instead of adding a variable-part to the record like it is done with other entry ki

  1   2   3   >