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 reb

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 c

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 mer

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/

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 a

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

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 dif

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 selfte

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

Re: [VERY URGENT] GNU ideas for GSOC 2020

Hi again. David points me out that GCC applied on its own as a mentoring organization for GSOC 2020, so please disregard the previous email, which applies to GNU projects _not_ applying on their own. Sorry for the noise, and good luck with the application! :) Salud! /me whips himself for hasty

[VERY URGENT] GNU ideas for GSOC 2020

Hi people! Once again, we are applying as a mentoring organization for GSOC 2020. At this point, we need to populate our ideas page with projects [1]. This should be done before this Thursday (yes tomorrow). So, if you want your GNU package to participate in GSOC, please send us your ideas to

Re: GCC wwwdocs move to git done

Hi Joseph. I've done the move of GCC wwwdocs to git (using the previously posted and discussed scripts), including setting up the post-receive hook to do the same things previously covered by the old CVS hooks, and minimal updates to the web pages dealing with the CVS setup fo

GNU Devroom in FOSDEM 2020 - proposal submitted

Hi People! As promised during the GNU Tools Cauldron last week, I just submitted a devroom proposal for the next edition of FOSDEM. Let's see what they say... I will know the next 30th of September. Salud!

Linux Plumbers Toolchain Micro-Conference CFP

Hi people! This is a call for proposals for the Toolchain micro-conference at this years' Linux Plumbers Conference (LPC) 2019 which will be held in Lisbon, Portugal for September 9-11. The Linux kernel is particularly demanding in terms of tooling, and the main purpose of this micro-conference

Re: GCC GSOC 2016

> As usual, GNU applied to participate in this year's GSOC and was > accepted as a mentoring organization. > > GCC related projects can be performed under the umbrella of the GNU org, > provided there are suitable mentors. > > Please see http://www.gnu.org/software/soc-

Re: GCC GSOC 2016

> I am interested in contributing to gcc for the gsoc 2016. Unfortunately, it seems GCC did not apply to participate in GSoC 2016 and the deadline passed already: https://summerofcode.withgoogle.com/organizations/?sp-search=GCC It also seems we did not apply last

Re: gnu-gabi group

> Great. I'll ask overseers to create a mailinglist. [...] Done [1] [2]. If y'all need a wiki too, just ask. [1] gnu-g...@sourceware.org [2] https://sourceware.org/ml/gnu-gabi/ The link to the "GNU GABI project web page" in https://sourceware.org/ml/gnu-gabi is brok

Re: gnu-gabi group

> +1 > > Since it's GNU tools we're talking about, we'd better use a medium that > we've all already agreed to use, than one that a number of us objects > to. I, for one, have closed my Google account several Valentine's Days > ago, for privacy reasons, and this makes the

Re: gnu-gabi group

On Thu, Feb 11, 2016 at 04:38:28PM +, Joseph Myers wrote: > I think that none of the ABI extensions in question are anything to do > with Linux, the kernel. Rather, they are ABI extensions for userspace in > the GNU system, which apply the same under multiple kernels (but so

Re: use of sphinx/rest as source for GNAT doc

On 05/23/14 09:23, Arnaud Charlet wrote: > At AdaCore, we have switched most of our product documentation the > rest/sphinx format: http://sphinx-doc.org/ > which provides most of the advantages of texinfo (text format, > can generate output in multiple formats, supported by fr

[gnu.org #263454] Re: Headsup: Rogue or hacked account spamming via RT? re: [gnu.org #263454]

Hi Dave. It was me who, in a mistake (I wanted to delete them) marked those tickets as "Opened". Sorry for the inconvenience. -- Jose E. Marchesi GNU Project http://www.gnu.org