Re: COBOL: Call to builtin_decl_explicit (BUILT_IN_EXIT), is optimized away.

Nah, I see ECF_TM_PURE despite the name seems to be doing something very different than ECF_CONST and ECF_PURE: if (flags & ECF_PURE) DECL_PURE_P (decl) = 1; ... if ((flags & ECF_TM_PURE) && flag_tm) apply_tm_attr (decl, get_identifier ("transaction_pure")); Still, you may try to

Re: COBOL: Call to builtin_decl_explicit (BUILT_IN_EXIT), is optimized away.

Perhaps it is because you are using ECF_TM_PURE when defining the built-in in cobol1.cc: #define ATTR_TMPURE_NORETURN_NOTHROW_LEAF_COLD_LIST (ECF_TM_PURE|ECF_NORETURN|ECF_NOTHROW|ECF_LEAF|ECF_COLD) [...] gfc_define_builtin ("__builtin_exit", ftype, BUILT_IN_EXIT, "exit", ATTR_T

Re: [GSoC] Tooling for running BPF GCC tests on a live kernel

> On Tue, Apr 1, 2025 at 8:07 PM Jose E. Marchesi > wrote: >> >> Hello Piyush. > Hello Jose, > >> Sounds like a quite good background. > Thank you! > >> Have you built GCC from sources? > Yes, I have. I built GCC while working on LFS and recently rebuilt it, > running the test suite while going

Re: [GSoC] Tooling for running BPF GCC tests on a live kernel

Hello Piyush. > I’m resending this email from my university account as my previous > message isn’t showing in the GCC mailing list archives. I’ve cc’d the > project mentors in case this email also fails to deliver. Apologies > for any duplicate notifications, and thank you for your understanding

Re: What branch to use for the Algol 68 front-end

>> Hi Jose, >> >> On Sat, Mar 08, 2025 at 02:17:52PM +0100, Jose E. Marchesi wrote: >>> > Since you already have a fork on the (experimental) forge we could >>> > also move your fork under https://forge.sourceware.org/gcc that way >>> > you can experiment with merge requests if you like. Even if

Re: What branch to use for the Algol 68 front-end

> Hi Jose, > > On Sat, Mar 08, 2025 at 02:17:52PM +0100, Jose E. Marchesi wrote: >> > Since you already have a fork on the (experimental) forge we could >> > also move your fork under https://forge.sourceware.org/gcc that way >> > you can experiment with merge requests if you like. Even if all yo

Re: What branch to use for the Algol 68 front-end

> Hi, > > On Fri, Mar 07, 2025 at 03:57:40PM +, Richard Earnshaw (lists) via Gcc > wrote: >> On 07/03/2025 15:41, Jose E. Marchesi via Gcc wrote: >> > The Steering Committee has decided not to merge the Algol 68 Front-End >> > in master at this point,

What branch to use for the Algol 68 front-end

Hello people! The Steering Committee has decided not to merge the Algol 68 Front-End in master at this point, but is ok with us using a branch in gcc.git to develop and maintain the front-end as well as a mailing list in algo...@gcc.gnu.org. The mailing list has been already set up by the source

Re: Announcement: GCC BPF is now being tested on BPF CI

> On Thursday, January 16th, 2025 at 3:58 PM, Jose E. Marchesi > wrote: > >> >> [...] >> > > >> > > Effective BPF selftests denylist for GCC BPF is located here: >> > > https://github.com/kernel-patches/vmtest/blob/master/ci/vmtest/configs/DENYLIST.test_progs-bpf_gcc >> > >> > The announceme

Re: Announcement: GCC BPF is now being tested on BPF CI

> As of now, an important missing piece on GCC side is the decl_tags > support, as they are heavily used by BPF selftests. See a message from > Yonghong Song: > https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673841.html Faust is working on a V2 of that patch series that will be submitted

Re: Announcement: GCC BPF is now being tested on BPF CI

Thank you for getting this up and running! > Hi everyone. > > GCC BPF support in BPF CI has been landed. > > The BPF CI dashboard is here: > https://github.com/kernel-patches/bpf/actions/workflows/test.yml > > A summary of what happens on CI (relevant to GCC BPF): > * Linux Kernel is built on

Re: Announcement: GCC BPF is now being tested on BPF CI

> On Thursday, January 16th, 2025 at 12:44 PM, Ihor Solodrai > wrote: > >> >> >> Hi everyone. >> >> GCC BPF support in BPF CI has been landed. >> >> The BPF CI dashboard is here: >> https://github.com/kernel-patches/bpf/actions/workflows/test.yml >> >> A summary of what happens on CI (rele

Re: Errors compiling BPF programs from Linux selftests/bpf with GCC

> Hi everyone. > > I built and ran selftests/bpf with GCC 15-20241229, and would like to > share my findings. > > Building required small adjustments in the Makefile, besides -std=gnu17 > > With the following change we can mitigate int64_t issue: > > +progs/test_cls_redirect.c-CFLAGS := -nostdinc

Re: Errors compiling BPF programs from Linux selftests/bpf with GCC

> On Thu, 2025-01-02 at 19:24 +0100, Jose E. Marchesi wrote: > > [...] > >> IMO the BPP selftest (and BPF programs in general) must not include host >> glibc headers at all, regardless of what BPF compiler is used. The >> glibc headers installed in the host are tailored to some particular >> arc

Re: Errors compiling BPF programs from Linux selftests/bpf with GCC

> [...] >>> We could switch to "wrap" to align with clang, but in that case it would >>> be up to the user to provide a "host" stdint.h that contains sensible >>> definitions for BPF. The kernel selftests, for example, would need to >>> do so to avoid including /usr/include/stdint.h that more li

Re: Errors compiling BPF programs from Linux selftests/bpf with GCC

> On Fri, 2025-01-03 at 01:16 +0100, Jose E. Marchesi wrote: > > [...] > >> Yes, in the GCC BPF backend we are using >> >>   use_gcc_stdint=provide >> >> which makes GCC to provide the version of stdint.h that assumes >> freestanding ("baremetal") mode. If we changed it to use >> >>   use_gcc

Re: Errors compiling BPF programs from Linux selftests/bpf with GCC

> On Thu, 2025-01-02 at 10:47 +0100, Jose E. Marchesi wrote: >> Hi Ihor. >> Thanks for working on this! :) >> >> > [...] >> > Older versions compile the dummy program without errors, however on >> > attempt to build the selftests there is a different issue: conflicting >> > int64 definitions (fu

Re: Errors compiling BPF programs from Linux selftests/bpf with GCC

> On Thursday, January 2nd, 2025 at 1:47 AM, Jose E. Marchesi > wrote: > >> Hi Ihor. >> Thanks for working on this! :) >> >> > [...] >> > Older versions compile the dummy program without errors, however on >> > attempt to build the selftests there is a different issue: conflicting >> > int64 d

Re: Errors compiling BPF programs from Linux selftests/bpf with GCC

Hi Ihor. Thanks for working on this! :) > [...] > Older versions compile the dummy program without errors, however on > attempt to build the selftests there is a different issue: conflicting > int64 definitions (full log at [6]). > > In file included from /usr/include/x86_64-linux-gnu/sys/ty

Re: GCC devroom at FOSDEM 2025?

Hi Thomas. > FOSDEM have recently posted the "FOSDEM 2025 call for devrooms", > . > Given the great success of last year's GCC devroom: > , I'd like to apply again, > for a GCC devroom (and relate

Re: [CAULDRON] Topics for the Toolchain and Linux kernel BoF

[Adding Josh in CC] > On Thu, Sep 12, 2024 at 06:09:53PM +0200, Jose E. Marchesi via Gcc wrote: >> - "noreturn" and jump tables run-time hints >> >> It has been expressed on the kernel side the desire of having the C >> compiler >> emit ru

[CAULDRON] Topics for the Toolchain and Linux kernel BoF

Hello people! This year we will be having a kernel BoF at Cauldron. It is scheduled for Saturday from 15:30 to 16:30. There will be several kernel maintainers and hackers in attendance, and the goal of the BoF is to discuss and collect feedback about several toolchain-related issues that are o

CFP deadline for Toolchains Track @ LPC 2024 extended

The call for proposals deadline for the Toolchains Track at the Linux Plumbers Conference has been extended to the 31th of July! https://lpc.events/event/18/abstracts/ The aim of the Toolchains track is to fix particular toolchain issues which are of the interest of the kernel and, ideally, fin

Re: Where to place warning about non-optimized tail and sibling calls

>> The Gambit Scheme->C compiler has an option to generate more efficient >> code if it knows that all tail and sibling calls in the generated C >> code will be optimized. If gcc does not, however, optimize a tail or >> sibling call, the generated C code may be incorrect (depending on >> circums

Re: Where to place warning about non-optimized tail and sibling calls

> The Gambit Scheme->C compiler has an option to generate more efficient > code if it knows that all tail and sibling calls in the generated C > code will be optimized. If gcc does not, however, optimize a tail or > sibling call, the generated C code may be incorrect (depending on > circumstance

Appointing a new reviewer for the BPF backend

Hello. I would like to recommend the GCC Steering Committee to appoint David Faust as a REVIEWER for the BPF backend. He has a lot of experience hacking the backend, and I trust his judgement to approve other's patches in the area. Thanks!

Project wiki page for the BPF backend

Hello people! We would like to use a project page in gcc.gnu.org/wiki to help coordinating the work in the BPF backend: links to specs, to open bugzillas, etc. I just created an user JoseMarchesi in the wiki, but I would need someone to add me to the list in EditorGroup. Thanks!

Re: Using CMake for building GCC

> On Sun, Sep 11, 2022, 10:30 Junk Trash via Gcc wrote: > >> Hi, >> >> I want to get the opinions of GCC developers regarding adding CMake as a >> build system for GCC. Is it something you would like, something you are >> neutral about, or something you are strongly against? >> >> Thanks for you

Re: Announcement: gcobol

> https://git.symas.net:443/cobolworx/gcc-cobol/ > https://github.com/Apress/beg-cobol-for-programmers > > Greetings, gcc! We come bearing gifts! > > When you set your clock ahead an hour yesterday, you might not have > realized you set your calendar back to 1985. There's a new gcc COBOL > comp

Re: [RFP] Toolchains and Kernel MC in LPC 2021

ping. There is still time to add more topics/key participants to the MC proposal. If interested in participating, please let us know in jema...@gnu.org and ndesaulni...@google.com. Thanks! > Hi people! > > This year the Linux Plumbers Conference (https://linuxplumbersconf.org) will > be fully

Re: Update to GCC copyright assignment policy

>> > GCC was created as part of the GNU Project but has grown to operate as >> > an autonomous project. >> > >> > The GCC Steering Committee has decided to relax the requirement to >> > assign copyright for all changes to the Free Software Foundation. GCC >> > will continue to be developed, dist

Re: Update to GCC copyright assignment policy

>> > GCC was created as part of the GNU Project but has grown to operate as >> > an autonomous project. >> > >> > The GCC Steering Committee has decided to relax the requirement to >> > assign copyright for all changes to the Free Software Foundation. GCC >> > will continue to be developed, dist

Re: Update to GCC copyright assignment policy

> GCC was created as part of the GNU Project but has grown to operate as > an autonomous project. > > The GCC Steering Committee has decided to relax the requirement to > assign copyright for all changes to the Free Software Foundation. GCC > will continue to be developed, distributed, and licen

[RFP] Toolchains and Kernel MC in LPC 2021

Hi people! This year the Linux Plumbers Conference (https://linuxplumbersconf.org) will be fully virtual, and will happend from 20 to 24 September 2021. As part of the event, we are organizing a `Toolchains and Kernel Micro-conference' devoted to discuss specific topics involving kernel and too

Toolchain-and-Linux-kernel session at LPC

Hi good peoples! As you probably know there is gonna be a GNU Tools Track at the virtual LPC 2020 conference. Instructions on how to participate have been already sent here and can be found at https://gcc.gnu.org/wiki/linuxplumbers2020. [By the way, the deadline to send proposals for talks is