Re: Manually set sret parameter

On Sun, Jun 29, 2025, 4:42 PM Andrew Pinski wrote: > > > On Sun, Jun 29, 2025, 4:36 PM Antoni Boucher wrote: > >> >> >> Le 2025-06-29 à 10 h 46, Andrew Pinski a écrit : >> > >> > >> > On Sun, Jun 29, 2025, 7:43 AM Andrew Pinski > > > wrote: >> > >> > On Sun, Jun 29,

Re: Manually set sret parameter

On Sun, Jun 29, 2025, 4:36 PM Antoni Boucher wrote: > > > Le 2025-06-29 à 10 h 46, Andrew Pinski a écrit : > > > > > > On Sun, Jun 29, 2025, 7:43 AM Andrew Pinski > > wrote: > > > > On Sun, Jun 29, 2025, 7:36 AM Antoni Boucher via Gcc > > mailto:gcc@gcc.gnu.org>

Re: Manually set sret parameter

Le 2025-06-29 à 10 h 46, Andrew Pinski a écrit : On Sun, Jun 29, 2025, 7:43 AM Andrew Pinski > wrote: On Sun, Jun 29, 2025, 7:36 AM Antoni Boucher via Gcc mailto:gcc@gcc.gnu.org>> wrote: Hi. Is there a way in GENERIC to specify that a para

Re: Implementing wbN suffix for literals (#119058)

Hi Jakub, On Sun, Jun 29, 2025 at 08:22:01PM +0200, Jakub Jelinek wrote: > On Sun, Jun 29, 2025 at 06:28:11AM +0200, Alejandro Colomar via Gcc wrote: > > --- i/libcpp/include/cpplib.h > > +++ w/libcpp/include/cpplib.h > > @@ -1363,6 +1363,7 @@ struct cpp_num > > #define CPP_N_SIZE_T 0x200 /

Re: Implementing wbN suffix for literals (#119058)

On Sun, Jun 29, 2025 at 06:28:11AM +0200, Alejandro Colomar via Gcc wrote: > --- i/libcpp/include/cpplib.h > +++ w/libcpp/include/cpplib.h > @@ -1363,6 +1363,7 @@ struct cpp_num > #define CPP_N_SIZE_T 0x200 /* C++23 size_t literal. */ > #define CPP_N_BFLOAT16 0x400 /* std::bfloat16_t t

Re: Manually set sret parameter

On Sun, Jun 29, 2025, 7:43 AM Andrew Pinski wrote: > On Sun, Jun 29, 2025, 7:36 AM Antoni Boucher via Gcc > wrote: > >> Hi. >> Is there a way in GENERIC to specify that a parameter will be passed in >> "sret", or is this solely controlled by the hook struct_value_rtx? >> > > It is only controlle

Re: Manually set sret parameter

On Sun, Jun 29, 2025, 7:36 AM Antoni Boucher via Gcc wrote: > Hi. > Is there a way in GENERIC to specify that a parameter will be passed in > "sret", or is this solely controlled by the hook struct_value_rtx? > It is only controlled by the hook. What exactly are trying to do? You could set the r

Re: fixincludes comes up empty

Hi James > On 23 Jun 2025, at 17:08, Richard Biener via Gcc wrote: >> Am 23.06.2025 um 17:56 schrieb James K. Lowden : >> On Sat, 21 Jun 2025 11:03:19 +0200 >> Richard Biener wrote: >> A comparison of the mentions of "fixinclude" in config.{status,log} of two directories, bootstrap a

Re: fixincludes comes up empty

> Am 23.06.2025 um 17:56 schrieb James K. Lowden : > > On Sat, 21 Jun 2025 11:03:19 +0200 > Richard Biener wrote: > >>> A comparison of the mentions of "fixinclude" in config.{status,log} >>> of two directories, bootstrap and non-bootstrap, shows no >>> difference. >>> >>> What should I b

Re: fixincludes comes up empty

On Sat, 21 Jun 2025 11:03:19 +0200 Richard Biener wrote: > > A comparison of the mentions of "fixinclude" in config.{status,log} > > of two directories, bootstrap and non-bootstrap, shows no > > difference. > > > > What should I be looking for? > > For why fixinclude isn?t built - the config.

Re: RFD: switch/case statement dispatch using hash

Florian Weimer via Gcc writes: > * Andi Kleen via Gcc: > >> Joern Wolfgang Rennecke writes: >> >>> This has come up several time over the years: >>> https://gcc.gnu.org/legacy-ml/gcc/2006-07/msg00158.html >>> https://gcc.gnu.org/legacy-ml/gcc/2006-07/msg00155.html >>> https://gcc.gnu.org/piperma

Re: RFD: switch/case statement dispatch using hash

On 23/06/2025 12:31, Florian Weimer wrote: Also carry-less multiply persumably. It's challenging to use those instructions for compiling switch statements because they would then be used all over the place. Not necessarily; you can hide them in an UNSPEC if you are worried that exposing the

Re: RFD: switch/case statement dispatch using hash

* Andi Kleen via Gcc: > Joern Wolfgang Rennecke writes: > >> This has come up several time over the years: >> https://gcc.gnu.org/legacy-ml/gcc/2006-07/msg00158.html >> https://gcc.gnu.org/legacy-ml/gcc/2006-07/msg00155.html >> https://gcc.gnu.org/pipermail/gcc/2010-March/190234.html >> >> , but

Re: RFD: switch/case statement dispatch using hash

Joern Wolfgang Rennecke writes: > This has come up several time over the years: > https://gcc.gnu.org/legacy-ml/gcc/2006-07/msg00158.html > https://gcc.gnu.org/legacy-ml/gcc/2006-07/msg00155.html > https://gcc.gnu.org/pipermail/gcc/2010-March/190234.html > > , but maybe now (or maybe a while ago)

Re: fixincludes comes up empty

> On 21 Jun 2025, at 12:03, Richard Biener via Gcc wrote: > > > >> Am 21.06.2025 um 08:45 schrieb James K. Lowden : >> >> I guess I'm doing something wrong, or not enough. "make install" is >> failing after a bootstrap build because the build/fixincludes directory >> is empty. Edited for

Re: RFD: switch/case statement dispatch using hash

Hi Joern, I've also been thinking about implementing something like that. First I would experiment with implementing switches using perfect hashing functions to see if this really speeds up execution on current CPUs. Then I would try to come up with some heuristic that tells GCC when it is advan

Re: fixincludes comes up empty

> Am 21.06.2025 um 08:45 schrieb James K. Lowden : > > I guess I'm doing something wrong, or not enough. "make install" is > failing after a bootstrap build because the build/fixincludes directory > is empty. Edited for brevity: > > $ make -C build-boot/ V=1 install > make: Entering directo

RE: GCC harm in ARM

> -Original Message- > From: Basile Starynkevitch > Sent: Thursday, June 19, 2025 11:51 > To: Bob Dubner > Cc: gcc@gcc.gnu.org > Subject: GCC harm in ARM > > HEllo, > > > Bob Dubner wrote on gcc@ > > > > Thus, the statement > > > > CALL "foo" > > > > might be the equivalent, imp

RE: harm in ARM

> -Original Message- > From: Richard Biener > Sent: Wednesday, June 18, 2025 09:28 > To: James K. Lowden > Cc: gcc@gcc.gnu.org; Bob Dubner > Subject: Re: harm in ARM > > On Tue, Jun 17, 2025 at 7:51 PM James K. Lowden > wrote: > > > > The

Re: harm in ARM

On Wed, 18 Jun 2025 15:28:29 +0200 Richard Biener wrote: > That means, the adjustment should end up unifying the FUNCTION_DECL > used for all calls. Thank you. Not to put words in his mouth, but I think that's what Bob suspected. > Btw, is there any way that the thing 'prog' calls can turn o

Re: An alternative way of appointing reviewers and maintainers

On Wed, Jun 18, 2025 at 9:14 AM Richard Biener wrote: > On Mon, Jun 16, 2025 at 7:06 PM Segher Boessenkool > wrote: > > > > Hi! > > > > On Mon, Jun 16, 2025 at 11:41:37AM +0200, Mark Wielaard wrote: > > > > WaA is decided by the sourceware maintainers. The request form says > > > > "email addre

Re: harm in ARM

On Wed, Jun 18, 2025 at 3:28 PM Richard Biener wrote: > > On Tue, Jun 17, 2025 at 7:51 PM James K. Lowden > wrote: > > > > The COBOL FE emits code for a recent ARM VM that is definitely not what > > the user or, ahem, the FE author intended. The observed behavior is > > that the program enters a

Re: harm in ARM

On Tue, Jun 17, 2025 at 7:51 PM James K. Lowden wrote: > > The COBOL FE emits code for a recent ARM VM that is definitely not what > the user or, ahem, the FE author intended. The observed behavior is > that the program enters an infinite loop calling the main entry point, > eventually exhausting

Re: An alternative way of appointing reviewers and maintainers

On Mon, Jun 16, 2025 at 7:06 PM Segher Boessenkool wrote: > > Hi! > > On Mon, Jun 16, 2025 at 11:41:37AM +0200, Mark Wielaard wrote: > > > WaA is decided by the sourceware maintainers. The request form says > > > "email address of person who approved request", but that is not who has > > > the fi

Re: About C23 attributes and plugins

Ok, thank you for your answer, I missed that apparently. Pierrick On 18/06/2025 11:46, Jakub Jelinek wrote: > On Wed, Jun 18, 2025 at 11:34:42AM +0200, Pierrick Philippe wrote: >> Hi everyone, >> >> I am currently reading the C23 standard along the pre-release GCC 16 >> documentations (users and

Re: About C23 attributes and plugins

On Wed, Jun 18, 2025 at 11:34:42AM +0200, Pierrick Philippe wrote: > Hi everyone, > > I am currently reading the C23 standard along the pre-release GCC 16 > documentations (users and internals), and I noticed that there is no > mention on how to create new attributes using the new C23 standard > a

Re: An alternative way of appointing reviewers and maintainers

Hi! On Mon, Jun 16, 2025 at 11:41:37AM +0200, Mark Wielaard wrote: > > WaA is decided by the sourceware maintainers. The request form says > > "email address of person who approved request", but that is not who has > > the final call :-) Which of course makes sense, the sourceware > > maintainer

Re: An alternative way of appointing reviewers and maintainers

Hi Segher, On Sun, Jun 15, 2025 at 11:07:15AM -0500, Segher Boessenkool wrote: > On Sun, Jun 15, 2025 at 05:52:50PM +0200, Mark Wielaard wrote: > > On Wed, Jun 11, 2025 at 10:40:02AM -0500, Segher Boessenkool wrote: > > > On Wed, Jun 04, 2025 at 05:53:18PM -0600, Jeff Law via Gcc wrote: > > > > If

Re: Sourceware Open Office Friday, June 13, 16:00 UTC

Hi, It was a busy open office, so a quick overview: - During the meeting Frank and Karen finalized the procurement of the bigger server (3x memory [24x64GB], 10x storage [6x3.84TB], 2x cpu ish [2x28 cores] compared to the current servers). The new data center should also have a a faster/big

Re: An alternative way of appointing reviewers and maintainers

Hi! On Sun, Jun 15, 2025 at 05:52:50PM +0200, Mark Wielaard wrote: > On Wed, Jun 11, 2025 at 10:40:02AM -0500, Segher Boessenkool wrote: > > On Wed, Jun 04, 2025 at 05:53:18PM -0600, Jeff Law via Gcc wrote: > > > On 6/3/25 1:41 PM, David Edelsohn via Gcc wrote: > > > >What is not working with the

Re: An alternative way of appointing reviewers and maintainers

Hi Segher, On Wed, Jun 11, 2025 at 10:40:02AM -0500, Segher Boessenkool wrote: > On Wed, Jun 04, 2025 at 05:53:18PM -0600, Jeff Law via Gcc wrote: > > On 6/3/25 1:41 PM, David Edelsohn via Gcc wrote: > > >What is not working with the current system? What is this fixing? > > It relies on the someo

Re: templates

On Sat, 14 Jun 2025 at 13:32, саша савельев wrote: > > > To whom it may concern > > Why we can’t use in this context? > > #include < iostream > > template < auto N > > void f () { > std::cout << N << std::endl ; > } > int main () { > f < 1 >(); > f < '!' >(); > f < "!!" >(); // e

Re: An alternative way of appointing reviewers and maintainers

On Wed, Jun 11, 2025 at 11:46 AM Segher Boessenkool < seg...@kernel.crashing.org> wrote: > On Wed, Jun 04, 2025 at 05:53:18PM -0600, Jeff Law via Gcc wrote: > > On 6/3/25 1:41 PM, David Edelsohn via Gcc wrote: > > >What is not working with the current system? What is this fixing? > > It relies on

Re: An alternative way of appointing reviewers and maintainers

On Wed, Jun 04, 2025 at 05:53:18PM -0600, Jeff Law via Gcc wrote: > On 6/3/25 1:41 PM, David Edelsohn via Gcc wrote: > >What is not working with the current system? What is this fixing? > It relies on the someone to shepherd the process and it's something that > often gets pushed down on my daily

Re: [ C Frontend / Preprocessor ] Embed Preprocessor Parameter Order

On 10/06/2025 18:43, Christopher Bazley wrote: Hi David, On 10/06/2025 14:19, David Brown wrote: On 10/06/2025 10:43, Jakub Jelinek wrote: On Tue, Jun 10, 2025 at 09:52:42AM +0200, David Brown via Gcc wrote: So while correcting the mistakes of the past is either very slow or impossible, we ca

Re: [ C Frontend / Preprocessor ] Embed Preprocessor Parameter Order

Hi David, On 10/06/2025 14:19, David Brown wrote: On 10/06/2025 10:43, Jakub Jelinek wrote: On Tue, Jun 10, 2025 at 09:52:42AM +0200, David Brown via Gcc wrote: So while correcting the mistakes of the past is either very slow or impossible, we can avoid them in the future.  Consistent paramete

Re: [ C Frontend / Preprocessor ] Embed Preprocessor Parameter Order

On 10/06/2025 10:43, Jakub Jelinek wrote: On Tue, Jun 10, 2025 at 09:52:42AM +0200, David Brown via Gcc wrote: So while correcting the mistakes of the past is either very slow or impossible, we can avoid them in the future. Consistent parameter order makes code clearer and neater, and should be

Re: [ C Frontend / Preprocessor ] Embed Preprocessor Parameter Order

On 10/06/2025 10:17, LIU Hao wrote: 在 2025-6-10 15:52, David Brown via Gcc 写道: On 09/06/2025 12:13, Andreas Schwab wrote: On Jun 09 2025, Chris Bazley via Gcc wrote: C is a language that allows considerable latitude in where things are placed: static int volatile p; volatile int s

Re: [ C Frontend / Preprocessor ] Embed Preprocessor Parameter Order

On Tue, Jun 10, 2025 at 09:52:42AM +0200, David Brown via Gcc wrote: > So while correcting the mistakes of the past is either very slow or > impossible, we can avoid them in the future. Consistent parameter order > makes code clearer and neater, and should be encouraged. If the clauses are proper

Re: [ C Frontend / Preprocessor ] Embed Preprocessor Parameter Order

在 2025-6-10 15:52, David Brown via Gcc 写道: On 09/06/2025 12:13, Andreas Schwab wrote: On Jun 09 2025, Chris Bazley via Gcc wrote: C is a language that allows considerable latitude in where things are placed: static int volatile p; volatile int static q; C23 says (6.11.5 Storage-cl

Re: [ C Frontend / Preprocessor ] Embed Preprocessor Parameter Order

On 09/06/2025 12:13, Andreas Schwab wrote: On Jun 09 2025, Chris Bazley via Gcc wrote: C is a language that allows considerable latitude in where things are placed: static int volatile p; volatile int static q; C23 says (6.11.5 Storage-class specifiers): The placement of a st

Re: [ C Frontend / Preprocessor ] Embed Preprocessor Parameter Order

On Jun 09 2025, Chris Bazley via Gcc wrote: > C is a language that allows considerable latitude in where things are placed: > > static int volatile p; > volatile int static q; C23 says (6.11.5 Storage-class specifiers): The placement of a storage-class specifier other than at the

Re: [ C Frontend / Preprocessor ] Embed Preprocessor Parameter Order

Hi, C is a language that allows considerable latitude in where things are placed: static int volatile p; volatile int static q; I do not think that the order of named parameters should be enforced, nor do I think that diagnostics should be produced if parameters are specified in an une

Re: [ C Frontend / Preprocessor ] Embed Preprocessor Parameter Order

JeanHeyd Meneide via Gcc writes: [...] > While the following 2 invocation of `#embed` are identical and produce > exactly the same data: > > - > #embed clang::offset(1) limit(3) /* ONE */ > #embed limit(3) clang::offset(1) /* TWO */ > - > > some people questioned whether or not the di

Re: [ C Frontend / Preprocessor ] Embed Preprocessor Parameter Order

On Thu, Jun 05, 2025 at 09:25:11PM +0200, JeanHeyd Meneide wrote: > The C and C++ Compatibility Study Group, when working on the new > standard `#embed` preprocessor parameter that mirrors the > `clang::offset(...)` and `gnu::offset(...)` parameters, had someone > raise a concern that the order of

Re: An alternative way of appointing reviewers and maintainers

On 6/3/25 1:41 PM, David Edelsohn via Gcc wrote: What is not working with the current system? What is this fixing? It relies on the someone to shepherd the process and it's something that often gets pushed down on my daily todo list. As a result nominations don't happen or are extremely

Re: An alternative way of appointing reviewers and maintainers

On 6/3/25 4:16 AM, Richard Sandiford via Gcc wrote: Hi, At the moment, all reviewers and maintainers have to be appointed by the Steering Committee. I wonder if we could add a second, more community-based route: someone can be appointed as a reviewer or maintainer with the agreement of a giv

Re: An alternative way of appointing reviewers and maintainers

Hi, On Tue, Jun 03, 2025 at 11:47:41AM +0100, Jonathan Wakely via Gcc wrote: > On Tue, 3 Jun 2025 at 11:21, Richard Sandiford via Gcc > wrote: > > At the moment, all reviewers and maintainers have to be appointed by the > > Steering Committee. I wonder if we could add a second, more community-b

Re: Build appears to be broken.

On Wed, 4 Jun 2025 at 16:43, Frank Ch. Eigler via Gcc wrote: > > Jerry D writes: > > > I am getting this tonight. > > [...] > > 257 | __gthread_cond_t _M_cond = __GTHREAD_COND_INIT; > > By the way, you can scan the sourceware.org buildbots, which include a > broadish coverage of architectur

Re: Build appears to be broken.

Jerry D writes: > I am getting this tonight. > [...] > 257 | __gthread_cond_t _M_cond = __GTHREAD_COND_INIT; By the way, you can scan the sourceware.org buildbots, which include a broadish coverage of architectures and distros. Broken builds show up pretty obviously both in the builds and

Re: An alternative way of appointing reviewers and maintainers

On 04/06/2025 14:57, David Edelsohn wrote: On Wed, Jun 4, 2025 at 5:24 AM Richard Earnshaw (lists) mailto:richard.earns...@arm.com>> wrote: On 03/06/2025 20:41, David Edelsohn via Gcc wrote: > On Tue, Jun 3, 2025 at 3:23 PM Richard Sandiford mailto:richard.sandif...@arm.com>>

Re: Second GCC 13.4 Release Candidate available from gcc.gnu.org

I bootstrapped and tested on Power8 and Power9 BE in both 32-bit and 64-bit modes, and on Power8, Power9 & Power10 LE in 64-bit mode, and everything looks good. On 30/05/25 9:16 pm, Jakub Jelinek via Gcc wrote: > The second release candidate for GCC 13.4 is available from > > https://gcc.gnu.org

Re: An alternative way of appointing reviewers and maintainers

On Wed, Jun 4, 2025 at 5:24 AM Richard Earnshaw (lists) < richard.earns...@arm.com> wrote: > On 03/06/2025 20:41, David Edelsohn via Gcc wrote: > > On Tue, Jun 3, 2025 at 3:23 PM Richard Sandiford < > richard.sandif...@arm.com> > > wrote: > > > >> David Edelsohn writes: > >>> On Tue, Jun 3, 2025

Re: An alternative way of appointing reviewers and maintainers

On 03/06/2025 20:41, David Edelsohn via Gcc wrote: > On Tue, Jun 3, 2025 at 3:23 PM Richard Sandiford > wrote: > >> David Edelsohn writes: >>> On Tue, Jun 3, 2025 at 6:22 AM Richard Sandiford via Gcc < >> gcc@gcc.gnu.org> >>> wrote: >>> Hi, At the moment, all reviewers and maintai

Re: An alternative way of appointing reviewers and maintainers

On Tue, Jun 3, 2025 at 10:46 PM Richard Sandiford via Gcc wrote: > > David Edelsohn via Gcc writes: > > On Tue, Jun 3, 2025 at 3:23 PM Richard Sandiford > > wrote: > > > >> David Edelsohn writes: > >> > On Tue, Jun 3, 2025 at 6:22 AM Richard Sandiford via Gcc < > >> gcc@gcc.gnu.org> > >> > wrot

Re: An alternative way of appointing reviewers and maintainers

David Edelsohn via Gcc writes: > On Tue, Jun 3, 2025 at 3:23 PM Richard Sandiford > wrote: > >> David Edelsohn writes: >> > On Tue, Jun 3, 2025 at 6:22 AM Richard Sandiford via Gcc < >> gcc@gcc.gnu.org> >> > wrote: >> > >> >> Hi, >> >> >> >> At the moment, all reviewers and maintainers have to b

Re: An alternative way of appointing reviewers and maintainers

On Tue, Jun 3, 2025 at 3:23 PM Richard Sandiford wrote: > David Edelsohn writes: > > On Tue, Jun 3, 2025 at 6:22 AM Richard Sandiford via Gcc < > gcc@gcc.gnu.org> > > wrote: > > > >> Hi, > >> > >> At the moment, all reviewers and maintainers have to be appointed by the > >> Steering Committee.

Re: An alternative way of appointing reviewers and maintainers

David Edelsohn writes: > On Tue, Jun 3, 2025 at 6:22 AM Richard Sandiford via Gcc > wrote: > >> Hi, >> >> At the moment, all reviewers and maintainers have to be appointed by the >> Steering Committee. I wonder if we could add a second, more >> community-based >> route: someone can be appointed

Re: An alternative way of appointing reviewers and maintainers

On Tue, Jun 3, 2025 at 6:22 AM Richard Sandiford via Gcc wrote: > Hi, > > At the moment, all reviewers and maintainers have to be appointed by the > Steering Committee. I wonder if we could add a second, more > community-based > route: someone can be appointed as a reviewer or maintainer with th

Re: An alternative way of appointing reviewers and maintainers

> Am 03.06.2025 um 12:22 schrieb Richard Sandiford via Gcc : > > Hi, > > At the moment, all reviewers and maintainers have to be appointed by the > Steering Committee. I wonder if we could add a second, more community-based > route: someone can be appointed as a reviewer or maintainer with t

Re: An alternative way of appointing reviewers and maintainers

On Tue, 3 Jun 2025 at 11:21, Richard Sandiford via Gcc wrote: > > Hi, > > At the moment, all reviewers and maintainers have to be appointed by the > Steering Committee. I wonder if we could add a second, more community-based > route: someone can be appointed as a reviewer or maintainer with the a

Re: Build appears to be broken.

On Tue, 3 Jun 2025, 03:19 Jerry D via Gcc, wrote: > I am getting this tonight. > This is a glibc change to the definition of PTHREAD_COND_INITIALIZER. It looks like you updated glibc. A clean build should fix it. > Jerry > > In file included from > > /home/jerry/dev/usr/include/c++/16.0.0/x8

Re: Review for gcc-15/changes.html

Hi Heiko, Thanks for the patch! I've pushed everything except for: Heiko Eißfeldt writes: > @@ -832,8 +832,8 @@ > (aarch64-w64-mingw32). At present, this target > supports C and C++ for base Armv8-A, but with some caveats: > > - Although most variadic functions work, the i

Re: typeof and operands in named address spaces

o address space > variable attributes? > > Maybe stripping all qualifiers is fine since you can add them back in > if necessary? > > const volatile foo; > const nonqual_typeof(foo) bar = foo; // strips off both qualifiers, > re-adds const to bar > -- > Thanks, > ~Nick Desaulniers

Re: Review for gcc-15/changes.html

Thanks for the reminder! I have now adapted the patch. Greetings, Heiko --- "GCC 15 Release Series — Changes, New Features, and Fixes - GNU Project.html.org" 2025-04-30 15:09:45.736597984 +0200 +++ "GCC 15 Release Series — Changes, New Features, and Fixes - GNU Project.html" 2025-05-27 19:43:47.

Re: Possible memory access optimization opportunity? Comparison with Java JIT

I checked: the mystery of fast JIT sorting is solved. It's not about memory access — C++ handles that very well. The key is function inlining. C++ does inline functions, but not recursive ones. JIT inlines recursive functions for specific cases — e.g., for 5 million elements. As an example: Java co

Re: Possible memory access optimization opportunity? Comparison with Java JIT

ould eliminate the whole thing - leaving you nothing but a couple of calls to now() in your loop. Then there are the calls to the high_resolution_clock. My guess is that the compiler can't eliminate these or re-order them with respect to each other. But it /can/ re-order them wi

Re: Possible memory access optimization opportunity? Comparison with Java JIT

On Sat, 24 May 2025, 18:58 Andy via Gcc, wrote: > Dear GCC developers, > > I would like to ask whether there might be room for improvement in memory > access optimization in GCC. > > I've prepared a simple benchmark in both C++ (using -std=c++20 for digit > separators like 5'000'000) and Java. Th

Re: Review for gcc-15/changes.html

Heiko Eißfeldt writes: > Hi, > > here is a patch for some mostly minor typos in > https://gcc.gnu.org/gcc-15/changes.html. > My fixes might be wrong of course, so they are just suggestions. > > Also, the linked page https://gcc.gnu.org/gcc-15/porting_to.html > contains the now outdated > "Note: G

Re: Use of register keyword for Globals

On Fri, May 23, 2025 at 12:33 PM Richard Biener wrote: > > > Am 23.05.2025 um 18:32 schrieb Joel Sherrill : > >  > > > On Fri, May 23, 2025 at 10:12 AM Richard Biener < > richard.guent...@gmail.com> wrote: > >> >> >> > Am 23.05.2025 um 17:06 schrieb Joel Sherrill via Gcc : >> > >> > Hi >> > >>

Re: Use of register keyword for Globals

On Fri, May 23, 2025 at 10:12 AM Richard Biener wrote: > > > > Am 23.05.2025 um 17:06 schrieb Joel Sherrill via Gcc : > > > > Hi > > > > In the SPARC port of RTEMS, there is a global variable assigned to a > > register for performance reasons. This is the near decade old line of > code: > > > >

Re: Use of register keyword for Globals

在 2025-5-23 23:03, Joel Sherrill via Gcc 写道: Hi In the SPARC port of RTEMS, there is a global variable assigned to a register for performance reasons. This is the near decade old line of code: register struct Per_CPU_Control *_SPARC_Per_CPU_current __asm__( "g6" ); +1 for this. On ARM64, Win

Re: Use of register keyword for Globals

> Am 23.05.2025 um 17:06 schrieb Joel Sherrill via Gcc : > > Hi > > In the SPARC port of RTEMS, there is a global variable assigned to a > register for performance reasons. This is the near decade old line of code: > > register struct Per_CPU_Control *_SPARC_Per_CPU_current __asm__( "g6" );

Re: Request for Removal of Personal Information from Relevant Messages

On Wed, May 21, 2025, 05:27 Jonathan Wakely via Gcc wrote: > On Wed, 21 May 2025 at 09:27, Homam Alkhateeb wrote: > > I hope this message finds you well. I am writing to request the removal > of personal information from all relevant messages that I posted on the > gcc.gnu.org mailing list. > > >

Re: GCC 14.3 Release Candidate available from gcc.gnu.org

On Thu, May 15, 2025 at 5:09 PM Richard Biener via Gcc wrote: > > The first release candidate for GCC 14.3 is available from > > https://gcc.gnu.org/pub/gcc/snapshots/14.3.0-RC-20250515/ > ftp://gcc.gnu.org/pub/gcc/snapshots/14.3.0-RC-20250515/ > > and shortly its mirrors. It has been generated

Re: GCC 14.3 Release Candidate available from gcc.gnu.org

I bootstrapped and tested on Power8 and Power9 BE in both 32-bit and 64-bit modes, and on Power8, Power9 & Power10 LE in 64-bit mode, and everything looks good. On 15/05/25 8:38 pm, Richard Biener via Gcc wrote: > The first release candidate for GCC 14.3 is available from > > https://gcc.gnu.org

Re: Request for Removal of Personal Information from Relevant Messages

On Wed, 21 May 2025 at 09:27, Homam Alkhateeb wrote: > > Dear GCC Mailing List Administrators, This is the main GCC mailing list, not how to reach the list administrators. gcc-owner@gcc... is probably better for reaching the admins, otherwise you're just adding more emails with your name in them t

Re: GCC development mailing list.

On Mon, 19 May 2025 at 16:58, Martin C. Foster wrote: > > Hi, > > I am a retired software engineer. I'm looking for projects where I might > be useful. I would like to get on your mailing list. > > I listened to an interview with Jonathan Wakely on the podcast cppcast > and contributing to the gcc

Re: Question for maintainers: ARCv3 port feasibility

Hi, I think using a different arc64 port is better as the new ARCv3 comes with some new innovations which are not in the "classical" arc port. Moreover, the classical arc is implementing arcv1, arcv2 and all kinds of variations in between. Adding a new 64bit architecture will just complicate the e

Re: Question for maintainers: ARCv3 port feasibility

On 15/05/2025 17:55, Richard Biener wrote: On Thu, May 15, 2025 at 6:43 PM Andrew Stubbs wrote: Dear GCC Maintainers and Steering Committee, I'm currently doing a feasibility study and effort estimate for upstreaming the existing ARCv3 out-of-tree port [1]. Question: Is there likely to be an

Re: Question for maintainers: ARCv3 port feasibility

On 16/05/2025 01:23, Paul Koning wrote: On May 15, 2025, at 8:06 PM, Oleg Endo via Gcc wrote: Hi, On Thu, 2025-05-15 at 17:41 +0100, Andrew Stubbs wrote: Dear GCC Maintainers and Steering Committee, I'm currently doing a feasibility study and effort estimate for upstreaming the existing A

Re: Question for maintainers: ARCv3 port feasibility

> On May 15, 2025, at 8:06 PM, Oleg Endo via Gcc wrote: > > Hi, > > On Thu, 2025-05-15 at 17:41 +0100, Andrew Stubbs wrote: >> Dear GCC Maintainers and Steering Committee, >> >> I'm currently doing a feasibility study and effort estimate for >> upstreaming the existing ARCv3 out-of-tree por

Re: Question for maintainers: ARCv3 port feasibility

Hi, On Thu, 2025-05-15 at 17:41 +0100, Andrew Stubbs wrote: > Dear GCC Maintainers and Steering Committee, > > I'm currently doing a feasibility study and effort estimate for > upstreaming the existing ARCv3 out-of-tree port [1]. > > Question: Is there likely to be any objection to adding a new

Re: Question for maintainers: ARCv3 port feasibility

On Thu, May 15, 2025 at 6:43 PM Andrew Stubbs wrote: > > Dear GCC Maintainers and Steering Committee, > > I'm currently doing a feasibility study and effort estimate for > upstreaming the existing ARCv3 out-of-tree port [1]. > > Question: Is there likely to be any objection to adding a new "arc64"

Re: GCC Development Plan update?

On Wed, 14 May 2025 at 21:26, Jonathan Wakely wrote: > > On Wed, 14 May 2025 at 20:56, ASSI wrote: > > > > Jonathan Wakely via Gcc writes: > > > For 13.4 the link on the https://gcc.gnu.org home page for the gcc 13 > > > status goes to https://gcc.gnu.org/pipermail/gcc/2025-April/245992.html > >

Re: GCC Development Plan update?

On Wed, 14 May 2025 at 20:56, ASSI wrote: > > Jonathan Wakely via Gcc writes: > > For 13.4 the link on the https://gcc.gnu.org home page for the gcc 13 > > status goes to https://gcc.gnu.org/pipermail/gcc/2025-April/245992.html > > which says: > > "The plan is to do a release candidate for GCC 13.

Re: GCC Development Plan update?

On Wed, May 14, 2025 at 09:55:07PM +0200, ASSI wrote: > That seems appropriate for the GCC Releases document, while the one I > linked to is advertised to show "future releases and an alternative view > of the release history". But I get it that it's just not getting an > update at this time so th

Re: GCC Development Plan update?

Jonathan Wakely via Gcc writes: > For 13.4 the link on the https://gcc.gnu.org home page for the gcc 13 > status goes to https://gcc.gnu.org/pipermail/gcc/2025-April/245992.html > which says: > "The plan is to do a release candidate for GCC 13.4 on Thursday, May > 29th, one week after the GCC 14.3

Re: GCC Development Plan update?

Jonathan Wakely via Gcc writes: > On Wed, 14 May 2025 at 19:12, ASSI wrote: >> >> >> The current schedule as published at >> >> https://gcc.gnu.org/develop.html >> >> ends with the 16.1 release. > > No it doesn't btw - it ends with the 15.1 release and with stage 1 for > gcc 16, we're still a year

Re: GCC Development Plan update?

On Wed, 14 May 2025 at 20:09, Jonathan Wakely wrote: > > On Wed, 14 May 2025 at 19:12, ASSI wrote: > > > > > > The current schedule as published at > > > > https://gcc.gnu.org/develop.html > > > > ends with the 16.1 release. Is there an updated / extended version > > available that shows the pla

Re: GCC Development Plan update?

On Wed, 14 May 2025 at 19:12, ASSI wrote: > > > The current schedule as published at > > https://gcc.gnu.org/develop.html > > ends with the 16.1 release. No it doesn't btw - it ends with the 15.1 release and with stage 1 for gcc 16, we're still a year away from the 16.1 release. > Is there an

Re: GCC Development Plan update?

On Wed, 14 May 2025 at 19:12, ASSI wrote: > > > The current schedule as published at > > https://gcc.gnu.org/develop.html > > ends with the 16.1 release. Is there an updated / extended version > available that shows the planned releases for the next half year at > least? No, but you can extrapol

Re: Generating compile_commands.json for GCC source code

f the overall build process being tracked by bear. For now I only have less than 50 lines. Best regards, Yuao From: Sam James Sent: Wednesday, May 14, 2025 10:32 To: Yuao Ma via Gcc Cc: Yuao Ma Subject: Re: Generating compile_commands.json for GCC source code Yu

Re: Generating compile_commands.json for GCC source code

Yuao Ma via Gcc writes: > Hello GCC developers, > I am trying to generate a compile_commands.json file for the GCC source code. > This file is very useful for various development tools and IDE integrations. > Since GCC uses a Makefile-based build system, I attempted to use bear > (https://githu

Re: Question About GPU-Powered Parallel Compilation in GCC

On Tue, May 13, 2025 at 12:51 PM Andrew Stubbs wrote: > > On 12/05/2025 15:27, Nikhil Patil via Gcc wrote: > > Hi Richard, > > > > Thank you so much for the reply! > > > > You're absolutely right about using CPU threads. I’m just really curious > > about whether GPU acceleration could somehow be e

Re: Question About GPU-Powered Parallel Compilation in GCC

On 12/05/2025 15:27, Nikhil Patil via Gcc wrote: Hi Richard, Thank you so much for the reply! You're absolutely right about using CPU threads. I’m just really curious about whether GPU acceleration could somehow be explored for compilation, even if it’s not traditionally well-suited. I know it

Re: Question About GPU-Powered Parallel Compilation in GCC

Hi Nikhil, While today's compilers are still largely very intricate code for Turing machines, this will certainly change during your career. It seems you'll be using GPUs for AI-assisted construction of optimal program graphs and immediately testing the performance of code fragments instead of rel

Re: Question About GPU-Powered Parallel Compilation in GCC

Hi Richard, Thank you so much for the reply! You're absolutely right about using CPU threads. I’m just really curious about whether GPU acceleration could somehow be explored for compilation, even if it’s not traditionally well-suited. I know it might not be practical, but I wanted to understand

Re: Question About GPU-Powered Parallel Compilation in GCC

On Mon, May 12, 2025 at 2:55 PM Nikhil Patil via Gcc wrote: > > Hi GCC Team, > > I'm fairly new to the world of compilers and trying to understand how they > work in more depth. Recently, I started exploring the idea of *parallelizing > the internal steps of compilation* — such as parsing, code ge

Re: Testing for prototypes generated from Fortran

On Sun, May 11, 2025 at 8:38 PM Harald Anlauf wrote: > > Hi Thomas, > > Am 11.05.25 um 12:51 schrieb Thomas Koenig via Gcc: > > Hi Harald, > > > >> Hi Thomas, > >> > >> On 5/11/25 10:34, Thomas Koenig via Gcc wrote: > >>> As PR120139 has shown (again), it is too easy to create regressions > >>> fo

  1   2   3   4   5   6   7   8   9   10   >