Re: [PATCH] gcc, cobol: Check for get_current_dir_name [PR119301]

>> On 18 Mar 2025, at 12:08, Richard Biener wrote: >> >> On Tue, Mar 18, 2025 at 1:07 PM Iain Sandoe wrote: >>> >>> >>> On 18 Mar 2025, at 12:01, Richard Biener wrote: On Tue, Mar 18, 2025 at 12:13 PM Iain Sandoe wrote: > > tested on x86_64/aarch64 Linux and

Re: [PATCH 2/2] cobol: use ldirname in cdf-copy.cc

> On Mon, Mar 17, 2025 at 7:45 PM Jose E. Marchesi > wrote: >> >> This patch changes gcc/cobol/cdf-copy.cc to use the new ldirname from >> libibertay rather than the host's dirname. This removes an include >> for libgen.h. >> >> Regtested in x86_6

Re: COBOL: Implementation of STOP RUN / GOBACK

> Am 20.03.2025 um 21:50 schrieb James K. Lowden: >> On Mar 13, 2025, at 8:04 AM, Simon Sobisch wrote: >>> >>> exit() allows us to "pass to the operating system" directly; but it doesn't >>> directly say "success" or "fail". >>> >>> >>> Obviously the statements >>>STOP RUN WITH NORMAL STATU

[PATCH 0/2] Add ldirname to libiberty and make cobol to use it

ning `make check-cobol', but I am not sure whether the small testsuite now in master covers this particular code change. Jose E. Marchesi (2): libiberty: add ldirname function cobol: use ldirname in cdf-copy.cc gcc/cobol/cdf-copy.cc | 24 +++ include/libiberty.h | 12 +

[PATCH 2/2] cobol: use ldirname in cdf-copy.cc

This patch changes gcc/cobol/cdf-copy.cc to use the new ldirname from libibertay rather than the host's dirname. This removes an include for libgen.h. Regtested in x86_64-linux-gnu by running make check-cobol. gcc/cobol/ChangeLog * cdf-copy.cc (copybook_elem_t::open_file): Use ldirname

[PATCH 1/2] libiberty: add ldirname function

This patch adds a function ldirname to libiberty. It is implemented in terms of lbasename. Basically, given a given pathname, the dirname part is what is not the basename minus the last directory separator separating the dirname with the basename. include/ChangeLog * libiberty.h (ldirna

Re: [PATCH+wwwdocs] Add link to the algo...@gcc.gnu.org mailing list

> On Thu, 13 Mar 2025, Jose E. Marchesi wrote: >> This patch adds a link to the Algol 68 front-end development list to >> lists.html. OK? > > Sure. > >> + https://gcc.gnu.org/ml/algol68/";>algol68 is >> + the discussion and development list for

[PATCH+wwwdocs] Add link to the algo...@gcc.gnu.org mailing list

Hello people! This patch adds a link to the Algol 68 front-end development list to lists.html. OK? Thanks! --- htdocs/lists.html | 5 + 1 file changed, 5 insertions(+) diff --git a/htdocs/lists.html b/htdocs/lists.html index 03e4a2a2..d5f1d3c8 100644 --- a/htdocs/lists.html +++ b/htdocs/l

Re: BPF, nvptx: Standardize on 'sorry, unimplemented: dynamic stack allocation not supported'

> diff --git a/gcc/testsuite/gcc.target/bpf/diag-alloca-1.c > b/gcc/testsuite/gcc.target/bpf/diag-alloca-1.c > index 0406f2c3595..e549cab84ca 100644 > --- a/gcc/testsuite/gcc.target/bpf/diag-alloca-1.c > +++ b/gcc/testsuite/gcc.target/bpf/diag-alloca-1.c > @@ -3,7 +3,8 @@ > int > foo (int x)

Re: BPF, nvptx: Standardize on 'sorry, unimplemented: dynamic stack allocation not supported'

>> diff --git a/gcc/testsuite/gcc.target/bpf/diag-alloca-1.c >> b/gcc/testsuite/gcc.target/bpf/diag-alloca-1.c >> index 0406f2c3595..e549cab84ca 100644 >> --- a/gcc/testsuite/gcc.target/bpf/diag-alloca-1.c >> +++ b/gcc/testsuite/gcc.target/bpf/diag-alloca-1.c >> @@ -3,7 +3,8 @@ >> int >> foo (

Re: BPF, nvptx: Standardize on 'sorry, unimplemented: dynamic stack allocation not supported'

Hi Thomas. > José, any objection to me pushing the attached > "BPF, nvptx: Standardize on 'sorry, unimplemented: dynamic stack allocation > not supported'"? Sure, please do. It is good to have a consistent message, and yours is better anyway. > (Why this is useful, you'll understand later to

Re: [WIP 0/8] Algol 68 GCC Front-End

ents: > > > On 2025-01-01T03:09:44+0100, "Jose E. Marchesi" > wrote: >> The parser used in this front-end has been borrowed and adapted from >> Algol 68 Genie, an Algol 68 interpreter written by Marcel van der >> Veer. It is worth noting that this p

[COMMITTED] bpf: install a wrapping stdint.h for bpf-none-unknown targets

This patch makes GCC to wrap the host's stdint.h header when operating in the default hosted/non-freestanding mode. It is thus up to the user to provide a suitable standard header unless -ffreestanding gets explicitly passed in the compilation line. A few tests that use stdint.h are adapted to ex

Re: [WIP 3/8] algol68: front-end misc files

> On Wed, 2025-01-01 at 03:09 +0100, Jose E. Marchesi wrote: >> --- >>  gcc/algol68/Make-lang.in |  239 + >>  gcc/algol68/README   |  102 ++ >>  gcc/algol68/a68-diagnostics.cc   |  450 + >>  gcc/algol68/a68-lang.cc  

Re: [WIP 1/8] algol68: top-level, include/ and config/ changes

> "Jose E. Marchesi" writes: > >> This patch contains the changes to files in the GCC top-level >> directory to introduce the Algol 68 front-end. >> --- >> MAINTAINERS |2 + >> Makefil

Re: [WIP 0/8] Algol 68 GCC Front-End

> As to where to host the project, the obvious choice is perhaps a > project at sourceware, but it would be nice if we could develop the > front-end in a branch in the GCC git repo, to have a mailing list > under gcc.gnu.org and to use a page in the GCC wiki to track the FE > progress... please l

Re: [WIP 3/8] algol68: front-end misc files

Hi Sam. >> +#ifdef HAVE_LD_STATIC_DYNAMIC >> + /* Remove -static-libphobos from the command only if target >> supports > > pasto Fixed. Thanks!

[WIP 1/8] algol68: top-level, include/ and config/ changes

@@ objective-c/c++ Mike Stump objective-c/c++ Iain Sandoe RustArthur Cohen RustPhilip Herron +Algol 68Jose E. Marchesi Various Maintainers

[WIP 7/8] algol68: libgac run-time library

@@ +# Makefile for libgac. +# Copyright (C) 2025 Jose E. Marchesi. +# +# This file is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later

[WIP 2/8] algol68: gcc/ changes

--- gcc/Makefile.in| 34 - gcc/common.opt | 3 +++ gcc/config.gcc | 47 ++ gcc/configure | 41 ++-- gcc/configure.ac | 14 ++ gcc/doc/tm.texi| 18

[WIP 0/8] Algol 68 GCC Front-End

channel in irc.oftc.net. Everyone is welcome to join and have fun with Algol 68. Salud! PS: many thanks to Iain, Andrew, Segher and others for their help and patience answering my FE related n00b questions in the IRC channel. You are the best. Jose E. Marchesi (8): algol68: top-

[COMMITED] bpf: fix build adding new required arg to RESOLVE_OVERLOADED_BUILTIN

gcc/ChangeLog * config/bpf/bpf.cc (bpf_resolve_overloaded_builtin): Add argument `complain'. --- gcc/config/bpf/bpf.cc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gcc/config/bpf/bpf.cc b/gcc/config/bpf/bpf.cc index fd913ecdb65..9a927e3a6ff 100644 --- a/gc

Re: [PATCH] bpf: avoid possible null deref in btf_ext_output [PR target/117447]

Hi Faust. Thanks for the patch. OK for master. > The BPF-specific .BTF.ext section is always generated for BPF programs > if -gbtf is specified, and generating it requires BTF information and > assumes that the BTF info has already been generated. > > Compiling non-C languages to BPF is not sup

[COMMITTED, BPF] bpf: do not emit BPF non-fetching atomic instructions

When GCC finds a call to one of the __atomic_OP_fetch built-ins in which the return value is not used it optimizes it into the corresponding non-fetching atomic operation. Up to now we had definitions in gcc/config/bpf/atomic.md to implement both atomic_OP and atomic_fetch_OP sets of insns: ato

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

> On Thu, 17 Aug 2023, Jose E. Marchesi via Gcc-patches wrote: >> [Changes from V3: > : >> LLVM supports an option -W[no-]compare-distinct-pointer-types that can >> be used in order to enable or disable the emission of such warnings. > > It looks this went in,

Re: [PATCH v4 5/6] bpf,btf: enable BTF pruning by default for BPF

> On 6/12/24 09:55, Jose E. Marchesi wrote: >> >> Hi Faust. >> Thanks for the patch. >> Please see a question below. >> >>> This patch enables -gprune-btf by default in the BPF backend when >>> generating BTF information, and fixes BPF CO-RE

Re: [PATCH v4 5/6] bpf,btf: enable BTF pruning by default for BPF

Hi Faust. Thanks for the patch. Please see a question below. > This patch enables -gprune-btf by default in the BPF backend when > generating BTF information, and fixes BPF CO-RE generation when using > -gprune-btf. > > When generating BPF CO-RE information, we must ensure that types used > in C

[COMMITTED BPF] bpf: fix printing of memory operands in pseudoc asm dialect

The BPF backend was emitting memory operands in pseudo-C syntax without surrounding parentheses. These were being provided in the corresponding instruction templates. This was causing GCC emitting invalid instructions when finding inline assembly with memory operands like: asm volatile (

Re: [PATCH] bpf: set PREFERRED_DEBUGGING_TYPE to BTF_DEBUG

Hi David. OK. Thanks for the patch. > BTF is the standard debug info used with BPF programs, so it makes sense > to default to BTF rather than DWARF. > > Tested on x86_64-linux-gnu host for bpf-unknown-none target. > > gcc/ > * config/bpf/bpf.h (PREFERRED_DEBUGGING_TYPE): Set to BTF_DEBUG

Re: [PATCH] bpf: avoid issues with CO-RE and -gtoggle

Hi Faust. OK. Thanks for the patch. > Compiling a BPF program with CO-RE relocations (and BTF) while also > passing -gtoggle led to an inconsistent state where CO-RE support was > enabled but BTF would not be generated, and this was not caught by the > existing option parsing. This led to an I

[COMMITTED BPF] bpf: default to using pseudo-C assembly syntax by default

At this point the kernel headers that almost all BPF programs use contain pseudo-C inline assembly and having the GNU toolchain using the conventional assembly syntax by default would force users to specify the command-line option explicitly almost all of the time, which is very inconvenient. This

[COMMITTED BPF] bpf: define BPF feature pre-processor macros

This commit makes the BPF backend to define the following macros for c-family languages: __BPF_CPU_VERSION__ This is a numeric value identifying the version of the BPF "cpu" for which GCC is generating code. __BPF_FEATURE_ALU32 __BPF_FEATURE_JMP32 __BPF_FEATURE_JMP_EXT __BPF_FE

Re: [PATCH 3/3] bpf: add line_info support to BTF.ext section.

>> Jose E. Marchesi writes: >> >>> Hi Cuper. >>> Thanks for the patch. >>> >>>> This patch adds line_info debug information support to .BTF.ext >>>> sections. >>>> Line info information is used by the BPF verifier t

Re: [PATCH 3/3] bpf: add line_info support to BTF.ext section.

> Jose E. Marchesi writes: > >> Hi Cuper. >> Thanks for the patch. >> >>> This patch adds line_info debug information support to .BTF.ext >>> sections. >>> Line info information is used by the BPF verifier to improve error >>> r

Re: [PATCH 3/3] bpf: add line_info support to BTF.ext section.

Hi Cuper. Thanks for the patch. > This patch adds line_info debug information support to .BTF.ext > sections. > Line info information is used by the BPF verifier to improve error > reporting and give more precise source core referenced errors. > > gcc/Changelog: > * config/bpf/bpf-protos.h

Re: [PATCH 1/3] bpf: support more instructions to match CO-RE relocations

Hi Cupertino. OK for master. Thanks! > BPF supports multiple instructions to be CO-RE relocatable regardless of > the position of the immediate field in the encoding. > In particular, not only the MOV instruction allows a CO-RE > relocation of its immediate operand, but the LD and ST instruction

Re: [PATCH] bpf: define INT8_TYPE as signed char

Hi David. > Change the BPF backend to define INT8_TYPE with an explicit sign, rather > than a plain char. This is in line with other targets and removes the > risk of int8_t being affected by the signedness of the plain char type > of the host system. OK. I would add to the commit message tha

Re: [PATCH 1/3] bpf: Fix CO-RE field expression builtins

>> Jose E. Marchesi writes: >> >>>> This patch corrects bugs within the CO-RE builtin field expression >>>> related builtins. >>>> The following bugs were identified and corrected based on the expected >>>> results of bpf-next s

Re: [PATCH 1/3] bpf: Fix CO-RE field expression builtins

> Jose E. Marchesi writes: > >>> This patch corrects bugs within the CO-RE builtin field expression >>> related builtins. >>> The following bugs were identified and corrected based on the expected >>> results of bpf-next selftests testsuit

Re: [PATCH 1/3] bpf: Fix CO-RE field expression builtins

> This patch corrects bugs within the CO-RE builtin field expression > related builtins. > The following bugs were identified and corrected based on the expected > results of bpf-next selftests testsuite. > It addresses the following problems: > - Expressions with pointer dereferencing now point

Re: [PATCH v2] bpf: add size threshold for inlining mem builtins

Hi Faust. OK. Thanks! > [Changes from v1: > - Error if threshold is exceeded instead of silently emitting libcall > - Update test accordingly > - Expand documentation to explain this behavior ] > > BPF cannot fall back on library calls to implement memmove, memcpy and > memset, so we attemp

Re: [PATCH] bpf: add size threshold for inlining mem builtins

Hi Faust. > BPF cannot fall back on library calls to implement memmove, memcpy and > memset, so we attempt to expand these inline always if possible. > However, this inline expansion was being attempted even for excessively > large operations, which could result in gcc consuming huge amounts of

Re: [PATCH] bpf: testsuite: fix unresolved test in memset-1.c

Hi David. OK. Thanks. > The test was trying to do too much by both checking for an error, and > checking the resulting assembly. Of course, due to the error no asm was > produced, so the scan-asm went unresolved. Split it into two separate > tests to fix the issue. > > Tested on x86_64-linux-gn

Re: [PATCH] bpf: add inline memset expansion

Hi David. Thanks for the patch. OK. > Similar to memmove and memcpy, the BPF backend cannot fall back on a > library call to implement __builtin_memset, and should always expand > calls to it inline if possible. > > This patch implements simple inline expansion of memset in the BPF > backend in

Re: [PATCH v3] bpf: add inline memmove and memcpy expansion

Hi David. This is OK. Thank you, very nice stuff! > [Changes from v2: > - Fix incorrectly passing a location instead of OPT_W* for warning (). > - Reword warning/error message and test accordingly. ] > > [Changes from v1: Jose's review comments, all of which I agree with. > - Fix 'implme

Re: [PATCH v2] bpf: add inline memmove and memcpy expansion

Hi Faust. > +bool > +bpf_expand_cpymem (rtx *operands, bool is_move) > +{ > + /* Size must be constant for this expansion to work. */ > + if (!CONST_INT_P (operands[2])) > +{ > + const char *name = is_move ? "memmove" : "memcpy"; > + if (flag_building_libgcc) > + warning (RT

Re: [PATCH] bpf: Add documentation for the -mcpu option

Hello Will. Thanks for the patch. I just installed it on your behalf. > Add documentation describing the meaning and values for the -mcpu > command-line option. > > Tested for bpf-unknown-none on x86_64-linux-gnu host. > > gcc/ChangeLog: > > * config/bpf/bpf.opt: Add help information for

Re: [PATCH] bpf: add inline memmove and memcpy expansion

Hi David. Thanks for the patch. See a couple of comments regarding error handling below. > BPF programs are not typically linked, which means we cannot fall back > on library calls to implement __builtin_{memmove,memcpy} and should > always expand them inline if possible. > > GCC already succes

Re: [PATCH] bpf: fix zero_extendqidi2 ldx template

Hi Faust. OK, thank you. > Commit 77d0f9ec3809b4d2e32c36069b6b9239d301c030 inadvertently changed > the normal asm dialect instruction template for zero_extendqidi2 from > ldxb to ldxh. Fix that. > > Tested for bpf-unknown-none on x86_64-linux-gnu host. > > gcc/ > > * config/bpf/bpf.md (zer

[COMMITTED] bpf: emit empty epilogues in naked functions

This patch fixes the BPF backend to not generate `exit' (return) instructions in epilogues of functions that are declared as naked via the corresponding compiler attribute. Having extra exit instructions upsets the kernel BPF verifier. Tested in bpf-unknown-none target in x86_64-linux-gnu host.

[COMMITTED] bpf: add constant pointer to helper-skb-ancestor-cgroup-id.c test

The purpose of this test is to make sure that constant propagation is achieved with the proper optimization level, so a BPF call instruction to a kernel helper is generated. This patch updates the patch so it also covers kernel helpers defined with constant static pointers. The motivation for thi

Re: [r14-5930 Regression] FAIL: gcc.c-torture/compile/libcall-2.c -Os (test for excess errors) on Linux/x86_64

>> mcmodel=large s not supported (yet) on any Darwin arch [PR90698], so > the test needs skipping or xfailing, I think (either way with a > reference to the PR). > > Pushed as > https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=b74981b5cf32ebf4bfffd25e7174b5c80243447a Thanks for fixing this.

Re: [PATCH] btf: fix PR debug/112656

> Hi Indu. > This is OK. Thanks. Oops sorry scratch that, I am no reviewer for the BTF area. Will have to wait for Faust or someone else to chime in :) > >> PR debug/112656 - btf: function prototypes generated with name >> >> With this patch, all BTF_KIND_FUNC_PROTO will appear anonymous in th

Re: [PATCH] btf: fix PR debug/112656

Hi Indu. This is OK. Thanks. > PR debug/112656 - btf: function prototypes generated with name > > With this patch, all BTF_KIND_FUNC_PROTO will appear anonymous in the > generated BTF section. > > As noted in the discussion in the bugzilla, the number of > BTF_KIND_FUNC_PROTO types output varie

[COMMITTED] bpf: quote section names whenever necessary in assembly output

In BPF section names are used to encode the kind of BPF program and other metadata, involving all sort of non alphanumeric characters. For example: /* use auto-attach format for section definition. */ SEC("uretprobe//proc/self/exe:trigger_func2") int handle_uretprobe_byname(struct pt_regs *

Re: [PATCH] bpf: change ASM_COMMENT_START to '#'

Hi David. OK. Thanks. > The BPF "pseudo-C" assembly dialect uses semi-colon (;) to separate > statements, not to begin line comments. The GNU assembler was recently > changed accordingly: > > https://sourceware.org/pipermail/binutils/2023-November/130867.html > > This patch adapts the BPF bac

Re: [r14-5930 Regression] FAIL: gcc.c-torture/compile/libcall-2.c -Os (test for excess errors) on Linux/x86_64

> On Wed, Nov 29, 2023 at 09:20:55AM +0100, Jose E. Marchesi wrote: >> OK to the patch below? >> >> >From a697f9e9442d96d3eda228b825dd8e8e06206c03 Mon Sep 17 00:00:00 2001 >> From: "Jose E. Marchesi" >> Date: Wed, 29 Nov 2023 09:16:48 +0100 >

Re: [r14-5930 Regression] FAIL: gcc.c-torture/compile/libcall-2.c -Os (test for excess errors) on Linux/x86_64

> On Wed, Nov 29, 2023 at 07:51:15AM +0100, Jose E. Marchesi wrote: >> > FAIL: gcc.c-torture/compile/libcall-2.c -O1 (test for excess errors) >> > FAIL: gcc.c-torture/compile/libcall-2.c -O2 -flto >> > -fno-use-linker-plugin -flto-partition=none (test for e

Re: [r14-5930 Regression] FAIL: gcc.c-torture/compile/libcall-2.c -Os (test for excess errors) on Linux/x86_64

> On Linux/x86_64, > > f31a019d1161ec78846473da743aedf49cca8c27 is the first bad commit > commit f31a019d1161ec78846473da743aedf49cca8c27 > Author: Jose E. Marchesi > Date: Fri Nov 24 06:30:28 2023 +0100 > > Emit funcall external declarations only if actually u

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

>> "Jose E. Marchesi" writes: >>> 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

Re: bpf: Throw error when external libcalls are generated.

> Hi Cuper. > OK. Thanks for the patch. This commit is breaking the BPF build, because libgcc emits libcalls to __builtin_abort. We need to rethink this. Please revert: commit faf5b148588bd7fbb60ec669aefa704044037cdc Author: Cupertino Miranda Date: Thu Nov 23 22:28:01 2023 + Tha

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

> "Jose E. Marchesi" writes: >> 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 >> l

Re: bpf: Throw error when external libcalls are generated.

Hi Cuper. OK. Thanks for the patch. > Hi everyone, > > The attached patch is a temporary solution for the lack of proper linker > and external library linking of the eBPF platform. > Any calls created by the compiler, that would usually be defined within > libgcc, will endup being undefined in b

[COMMITTED] bpf: remove bpf-helpers.h

Now that we are finally able to use the kernel provided bpf_helpers.h file and associated machinery, there is no longer need to distribute our own version. This patch removes bpf-helpers.h and deletes most of the associated tests from the gcc.target/bpf testsuite. Two tests are adapted and retain

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

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 libcall, the current implementation of emit_library_call_value_1 introduce a side-effect consi

Re: [PATCH] bpf: Forces __buildin_memcmp not to generate a call upto 1024 bytes.

Hi Cuper. Sorry, I missed this patch last week. This is OK. Thanks! > This patch forces __builtin_memcmp calls upto data sizes of 1024 to > become inline in caller. > This is a requirement by BPF and it mimics the default behaviour of the > clang BPF implementation. > > gcc/ChangeLog: >

Re: [PATCH V2] libgcc: mark __hardcfr_check_fail as always_inline

>> Am 23.11.2023 um 16:17 schrieb Jose E. Marchesi : >> >> [Changes from V1: >> - Use always_inline only in BPF target.] >> >> The function __hardcfr_check_fail in hardcfr.c is internal and static >> inline. It receives many arguments, which requir

[PATCH V2] libgcc: mark __hardcfr_check_fail as always_inline

[Changes from V1: - Use always_inline only in BPF target.] The function __hardcfr_check_fail in hardcfr.c is internal and static inline. It receives many arguments, which require more than five registers to be passed in bpf-none-unknown targets. BPF is limited to that number of registers to pass

Re: [PATCH] libgcc: mark __hardcfr_check_fail as always_inline

> On Wed, Nov 22, 2023 at 3:39 PM Jose E. Marchesi > wrote: >> >> The function __hardcfr_check_fail in hardcfr.c is internal and static >> inline. It receives many arguments, which require more than five >> registers to be passed in bpf-none-unknown targets. BP

[PATCH] libgcc: mark __hardcfr_check_fail as always_inline

The function __hardcfr_check_fail in hardcfr.c is internal and static inline. It receives many arguments, which require more than five registers to be passed in bpf-none-unknown targets. BPF is limited to that number of registers to pass arguments, and therefore libgcc fails to build in that targ

[COMMITTED] bpf: fix pseudo-c asm emitted for *mulsidi3_zeroextend

This patch fixes the pseudo-c BPF assembly syntax used for *mulsidi3_zeroextend, which was being emitted as: rN *= wM instead of the proper way to denote a mul32 in pseudo-C syntax: wN *= wM Includes test. Tested in bpf-unknown-none-gcc target in x86_64-linux-gnu host. gcc/ChangeLog:

[COMMITED] bpf: testsuite: fix expected regexp in gcc.target/bpf/ldxdw.c

gcc/testsuite/ChangeLog: * gcc.target/bpf/ldxdw.c: Fix regexp with expected result. --- gcc/testsuite/gcc.target/bpf/ldxdw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/testsuite/gcc.target/bpf/ldxdw.c b/gcc/testsuite/gcc.target/bpf/ldxdw.c index 0985ea3e6ac..

Re: RFC (V2) the proposal to resolve the missing dependency issue for counted_by attribute

> On Thu, Nov 09, 2023 at 03:49:49PM +, Qing Zhao wrote: >> Is it reasonable to add one option to disable the “counted_by” attribute? >> (then no insertion of the new .ACCESS_WITH_SIZE into IL). >> >> The major reason is: some users might want to ignore all the “counted_by” >> attribute a

Re: __hardcfr_check_fail and BPF

> Hi, > > On Oct 31, 2023, "Jose E. Marchesi" wrote: > >> As you may know, in BPF we have to live (for now) with the constant pain >> from being limited to functions whose arguments can be compiled to get >> their arguments in five or less registers. &g

__hardcfr_check_fail and BPF

Hi Alex. As you may know, in BPF we have to live (for now) with the constant pain from being limited to functions whose arguments can be compiled to get their arguments in five or less registers. The recently introduced __hardcfr_check_fail in the run-time component of hardcfr breaks the bpf-un

Re: [PATCH] gcov-io.h: fix comment regarding length of records

> On 10/24/23 06:41, Jose E. Marchesi wrote: >> The length of gcov records is stored as a signed 32-bit number of >> bytes. >> Ok? > OK. Pushed. Thanks.

[PATCH] gcov-io.h: fix comment regarding length of records

The length of gcov records is stored as a signed 32-bit number of bytes. Ok? diff --git a/gcc/gcov-io.h b/gcc/gcov-io.h index bfe4439d02d..e6f33e32652 100644 --- a/gcc/gcov-io.h +++ b/gcc/gcov-io.h @@ -101,7 +101,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see Rec

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

> "Jose E. Marchesi" writes: >> Hi Richard. >> Thanks for looking at this! :) >> >> >>> "Jose E. Marchesi" writes: >>>> ping >>> >>> I don't know this code very well, and have AFAIR haven't worke

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

Hi Richard. Thanks for looking at this! :) > "Jose E. Marchesi" writes: >> ping > > I don't know this code very well, and have AFAIR haven't worked > with an assembler that requires external declarations, but since > it's at a second ping

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 ma

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_t

  1   2   3   4   5   >