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
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
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
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
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
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
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>>
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
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
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
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
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
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.
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
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
> 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
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
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
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
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
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.
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
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
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
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
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
>> >
>>
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:
> >
> >
在 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
> 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" );
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.
> >
>
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
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
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
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
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
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
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
> 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
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
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"
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
> >
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
On Sun, May 11, 2025 at 10:34:11 +0200, Thomas Koenig via Gcc wrote:
> 2) Dump to standard output and check for the presence of certain
> regexps, ignoring anything else. Again, this is something I don't
> know how to do.
This is…fraught with peril and fiddliness. If the test can stomach some
C++
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
for dumping C prototypes from Fortran. The main problem
is that there is currently no test
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
for dumping C prototypes from Fortran. The main problem
is that there is currently no test in the testsuite.
for something along this variant you can tr
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
for dumping C prototypes from Fortran. The main problem
is that there is currently no test in the testsuite.
So, what to do? I see several possibilities:
1a) Change t
On Monday, May 5th, 2025 at 19:14, Andreas Schwab wrote:
>
>
> On Mai 05 2025, Basile Starynkevitch wrote:
>
> > and to my surprise its libgccjit.h was installed under /usr/local/include/
> > and
>
>
> libgccjit.h has always been installed in $(includedir), so this is
> expected.
By the wa
On Mai 05 2025, Basile Starynkevitch wrote:
> and to my surprise its libgccjit.h was installed under /usr/local/include/ and
libgccjit.h has always been installed in $(includedir), so this is
expected.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552
On Thu, May 1, 2025 at 11:41 AM Toon Moene wrote:
>
> Compare:
>
> https://gcc.gnu.org/pipermail/gcc-testresults/2025-April/845489.html
>
> (checking=yes,extra,rtl,df,gcac - shortly over 2 hours and 15 minutes)
>
> with:
>
> https://gcc.gnu.org/pipermail/gcc-testresults/2025-May/845705.html
>
> (c
Gerald Pfeifer writes:
> On Sat, 26 Apr 2025, Jonathan Wakely wrote:
>> $ grep -R 'generator.*Docutils' libgomp | wc -l
>> 136
>> $ grep -R 'generator.*Docutils' libitm | wc -l
>> 8
>> $ grep -R 'generator.*Docutils' gdc | wc -l
>> 7
>> $ grep -R 'generator.*Docutils' gfc-internals | wc -l
>>
On Sat, 26 Apr 2025, Jonathan Wakely wrote:
> $ grep -R 'generator.*Docutils' libgomp | wc -l
> 136
> $ grep -R 'generator.*Docutils' libitm | wc -l
> 8
> $ grep -R 'generator.*Docutils' gdc | wc -l
> 7
> $ grep -R 'generator.*Docutils' gfc-internals | wc -l
> 4
I yanked all these, including
"Richard Earnshaw (lists) via Gcc" writes:
> On 30/04/2025 18:34, Heiko Eißfeldt wrote:
>>> - FEAT_LRCPC2 (+rcpc2), enabled by default for
>>> + FEAT_RCPC2 (+rcpc2), enabled by default for
>>>
>>> and
>>>
>>> - FEAT_LRCPC3 instructions, when support for the instructions is
>>> + FE
Hi Heiko,
Thanks for doing this...
> On 30 Apr 2025, at 18:53, Richard Earnshaw (lists) via Gcc
> wrote:
>
> On 30/04/2025 17:23, Heiko Eißfeldt wrote:
>> 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
On 30/04/2025 18:34, Heiko Eißfeldt wrote:
>> - FEAT_LRCPC2 (+rcpc2), enabled by default for
>> + FEAT_RCPC2 (+rcpc2), enabled by default for
>>
>> and
>>
>> - FEAT_LRCPC3 instructions, when support for the instructions is
>> + FEAT_RCPC3 instructions, when support for the instructi
- FEAT_LRCPC2 (+rcpc2), enabled by default for
+ FEAT_RCPC2 (+rcpc2), enabled by default for
and
-FEAT_LRCPC3 instructions, when support for the instructions is
+FEAT_RCPC3 instructions, when support for the instructions is
These are incorrect. The features really are FEAT_LR
On 30/04/2025 17:23, Heiko Eißfeldt wrote:
> 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
> n
Hey folks,
I thought I'll post a follow up here in case it is of wider interest.
First, my colleague Nicolas Savoire did a Git bisect and identified the
commit[0] that stopped GCC from choosing AArch64 FP registers for pointer
storage. He even created a reproducer[1] on Godbolt that shows the
dif
On Fri, Apr 25, 2025 at 2:31 PM ywgrit via Gcc wrote:
>
> I encountered one problem with loop-im pass.
> I compiled the program dhry2reg which belongs to unixbench(
> https://github.com/kdlucas/byte-unixbench).
>
> The gcc used
> gcc (GCC) 12.3.0
>
> The commands executed as following
> make
> ./R
ywgrit writes:
> I encountered one problem with loop-im pass.
> I compiled the program dhry2reg which belongs to
> unixbench(https://github.com/kdlucas/byte-unixbench).
>
> The gcc used
> gcc (GCC) 12.3.0
>
> The commands executed as following
> make
> ./Run -c -i 1 dhry2reg
>
> The results are
I encountered one problem with loop-im pass.
I compiled the program dhry2reg which belongs to unixbench(
https://github.com/kdlucas/byte-unixbench).
The gcc used
gcc (GCC) 12.3.0
The commands executed as following
make
./Run -c -i 1 dhry2reg
The results are shown below.
Dhrystone 2 using registe
On Sat, 26 Apr 2025 at 19:24, Jonathan Wakely wrote:
>
> On Sat, 26 Apr 2025 at 13:55, Sam James wrote:
> >
> > Gerald Pfeifer writes:
> >
> > > On Tue, 4 Feb 2025, Jonathan Wakely wrote:
> > > :
> > >>> ./gnat_ugn/_static/
> > >>> ./libgccjit/_static/
> > >>> ./libgdiagnostics/_static/
> > >>>
On Sat, 26 Apr 2025 at 13:55, Sam James wrote:
>
> Gerald Pfeifer writes:
>
> > On Tue, 4 Feb 2025, Jonathan Wakely wrote:
> > :
> >>> ./gnat_ugn/_static/
> >>> ./libgccjit/_static/
> >>> ./libgdiagnostics/_static/
> >>> ./libgomp/_static/
> > :
> >> N.B. there's ./jit/_static which should stay,
Gerald Pfeifer writes:
> On Tue, 4 Feb 2025, Jonathan Wakely wrote:
> :
>>> ./gnat_ugn/_static/
>>> ./libgccjit/_static/
>>> ./libgdiagnostics/_static/
>>> ./libgomp/_static/
> :
>> N.B. there's ./jit/_static which should stay, because jit still uses
>> sphinx for its docs.
>
I found
https://gc
On Tue, 4 Feb 2025 at 15:16, Jonathan Wakely wrote:
>
> On Fri, 15 Nov 2024 at 12:43, Gerald Pfeifer wrote:
> >
> > On Fri, 15 Nov 2024, Jonathan Wakely wrote:
> > > All these directories should have been removed two years ago:
> >
> > Agreed. Thank you for digging into this and raising it, Jonat
I encountered one problem with loop-im pass.
I compiled the program dhry2reg which belongs to unixbench(
https://github.com/kdlucas/byte-unixbench).
The gcc used
gcc (GCC) 12.3.0
The commands executed as following
make
./Run -c -i 1 dhry2reg
The results are shown below.
Dhrystone 2 using registe
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 24/04/25 4:30 am, Peter Bergner wrote:
>
> The second release candidate for GCC 15.1 is available from
>
> https://gcc.gnu.org/pu
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 24/04/25 4:28 am, Peter Bergner wrote:
>
> The first release candidate for GCC 15.1 is available from
>
> https://gcc.gnu.org/pub/g
Hi -
> We were wondering if it would be possible / suitable to have https
> requests served by one container,
> and ssh ones by another? Maybe that's already the case though...
SSH stuff is already (un)contained.
> [...]
> so maybe it would help if we switched to ssh access for our CI user
> whe
Hi!
Thanks for all the hard work maintaining all this fundamental infrastructure.
On Mon, 21 Apr 2025 at 18:00, Mark Wielaard wrote:
>
> Hi hackers,
>
> TLDR; When using https://patchwork.sourceware.org or Bunsen
> https://builder.sourceware.org/testruns/ you might now have to enable
> javascrip
Hi Mark,
On Tue, 22 Apr 2025, 4:00 am Mark Wielaard, wrote:
> Hi hackers,
>
> TLDR; When using https://patchwork.sourceware.org or Bunsen
> https://builder.sourceware.org/testruns/ you might now have to enable
> javascript. This should not impact any scripts, just browsers (or bots
> pretending
On 2025-04-22 14:06, Jonathan Wakely wrote:
> On Tue, 22 Apr 2025 at 13:36, Guinevere Larsen via Gcc
> wrote:
> >
> > On 4/21/25 12:59 PM, Mark Wielaard wrote:
> > > Hi hackers,
> > >
> > > TLDR; When using https://patchwork.sourceware.org or Bunsen
> > > https://builder.sourceware.org/testruns/
On Tue, 22 Apr 2025, 14:17 Guinevere Larsen, wrote:
>
> On 4/22/25 10:06 AM, Jonathan Wakely wrote:
> > On Tue, 22 Apr 2025 at 13:36, Guinevere Larsen via Gcc
> > wrote:
> >> On 4/21/25 12:59 PM, Mark Wielaard wrote:
> >>> Hi hackers,
> >>>
> >>> TLDR; When using https://patchwork.sourceware.org
On 4/22/25 10:06 AM, Jonathan Wakely wrote:
On Tue, 22 Apr 2025 at 13:36, Guinevere Larsen via Gcc wrote:
On 4/21/25 12:59 PM, Mark Wielaard wrote:
Hi hackers,
TLDR; When using https://patchwork.sourceware.org or Bunsen
https://builder.sourceware.org/testruns/ you might now have to enable
jav
On Tue, 22 Apr 2025 at 13:36, Guinevere Larsen via Gcc wrote:
>
> On 4/21/25 12:59 PM, Mark Wielaard wrote:
> > Hi hackers,
> >
> > TLDR; When using https://patchwork.sourceware.org or Bunsen
> > https://builder.sourceware.org/testruns/ you might now have to enable
> > javascript. This should not
On 4/21/25 12:59 PM, Mark Wielaard wrote:
Hi hackers,
TLDR; When using https://patchwork.sourceware.org or Bunsen
https://builder.sourceware.org/testruns/ you might now have to enable
javascript. This should not impact any scripts, just browsers (or bots
pretending to be browsers). If it does ca
Hi,
On Fri, Apr 18, 2025 at 09:42:57PM +0100, Jonathan Wakely via Gcc wrote:
> On Fri, 18 Apr 2025, 20:14 Siva Sai Manchem via Gcc,
> wrote:
> > We wanted to bring to your attention that one of our customers, who is
> > utilizing Zscaler services, is currently facing difficulties accessing your
>
On Fri, 18 Apr 2025, 20:14 Siva Sai Manchem via Gcc,
wrote:
> Hi Team,
>
> I hope you're doing well.
>
> We wanted to bring to your attention that one of our customers, who is
> utilizing Zscaler services, is currently facing difficulties accessing your
> website. Upon reviewing the issue, we fou
On 17/04/2025 12:19, Wasim Khan via Gcc wrote:
>
>
>> -Original Message-
>> From: Richard Earnshaw (lists)
>> Sent: 17 April 2025 14:57
>> To: Wasim Khan ; gcc-h...@gcc.gnu.org;
>> gcc@gcc.gnu.org
>> Subject: Re: memcpy issue with arm-gnu-toolc
On 17/04/2025 07:49, Wasim Khan via Gcc wrote:
> Hi,
>
> I have a custom implementation of memcpy() function and don't want to use
> implementation provided by libc.a.
> Things works fine with toolchain version 12.3 and my local implementation in
> utils.c is considered.
> But when I move to too
> -Original Message-
> From: Richard Earnshaw (lists)
> Sent: 17 April 2025 14:57
> To: Wasim Khan ; gcc-h...@gcc.gnu.org;
> gcc@gcc.gnu.org
> Subject: Re: memcpy issue with arm-gnu-toolchain-14.2.rel1-x86_64-aarch64-
> none-elf
>
> [You don't of
++ gcc@gcc.gnu.org
> -Original Message-
> From: Wasim Khan
> Sent: 15 April 2025 12:41
> To: gcc-h...@gcc.gnu.org
> Subject: GCOV issue with GCC-14.2
>
> Hi,
>
> I am using GCOV for test coverage in a project using instructions for
> freestanding environment
>
> Below are the flags i us
I recommend creating a different name for your own memcpy() implementation,
and use that. You may also make it configurable which implementation to use.
On Thu, Apr 17, 2025, 08:51 Wasim Khan via Gcc-help
wrote:
> Hi,
>
> I have a custom implementation of memcpy() function and don't want to use
Hi, sorry for bumping this again
I forgot to mention that Windows inlining, from what I remember, was
ok before gcc 14 landed. It seemed that only once gcc 14 came about
that the insane inlining started happening. This might point to the
inlining heuristics having changed, but unfortunately gcc 13
Hi Jonathan,
Thanks for the suggestion, it seems promising. I switched out the
error attribute for the warning attribute at first, since they should
be equivalent except warning just warns instead of erroring. This
results in the link step failing if LTO is enabled for some reason
though. I then c
Hi,
On Mon, Apr 14, 2025 at 09:51:50PM +, justin.colon--- via Gcc wrote:
> Hello GCC and GNU support, I am the proxy service lead for Lockheed
> Martin and something seems to be blocking our traffic when our US
> users try to reach https://gcc.gnu.org/onlinedocs/. Our Non-US users
> do not hav
vior of a C ++ program is
undefined if it adds declarations or definitions to namespace std or
to a namespace within namespace std."
But ::malloc is not in namespace std, so that rule doesn't apply. But
that's arguably a defect in the standard caused by forgetting that
std::malloc m
1 - 100 of 63409 matches
Mail list logo
