Re: Inquiry about Loop Unswitching Behavior in GCC 15

On Thu, Jul 24, 2025 at 8:40 AM Richard Biener wrote: > > On Thu, Jul 24, 2025 at 2:39 AM magic0826gc via Gcc wrote: > > > > Dear GCC Developers, > > I'm writing to report an observation regarding loop unswitching behavior > > when compiling the attached code with GCC 15 using -O2 -funswitch-loo

Re: RFC/RFH: uninit warning vs DSE of store from a known uninitialized variable

On Thu, Jul 24, 2025 at 4:23 AM Jeff Law via Gcc wrote: > > > > On 7/23/25 5:45 PM, Andrew Pinski via Gcc wrote: > > Hi all, > >When I improved DSE to remove stores where the rhs is known 100% to be > > an uninitialized variables (ssa_undefined_value_p), I get a few regressions > > due to an

Re: Inquiry about Loop Unswitching Behavior in GCC 15

On Thu, Jul 24, 2025 at 2:39 AM magic0826gc via Gcc wrote: > > Dear GCC Developers, > I'm writing to report an observation regarding loop unswitching behavior when > compiling the attached code with GCC 15 using -O2 -funswitch-loops > optimization flags. Here's a detailed analysis of the issue:

Re: RFC/RFH: uninit warning vs DSE of store from a known uninitialized variable

On 7/23/25 5:45 PM, Andrew Pinski via Gcc wrote: Hi all, When I improved DSE to remove stores where the rhs is known 100% to be an uninitialized variables (ssa_undefined_value_p), I get a few regressions due to an uninitialized warning does not happen: gcc.dg/uninit-40.c for an example. (

RE: RFC/RFH: uninit warning vs DSE of store from a known uninitialized variable

> -Original Message- > From: Andrew Pinski > Sent: Wednesday, July 23, 2025 4:45 PM > To: gcc@gcc.gnu.org > Subject: RFC/RFH: uninit warning vs DSE of store from a > known uninitialized variable > > Hi all, > When I improved DSE to remove stores where the rhs is > known 100% to be an un

Re: GCov space optimization

On 23/07/2025 17:29, Alexander Monakov wrote: On Wed, 23 Jul 2025, Jan Hubicka via Gcc wrote: Thank you for the careful explanation. It seems like all the "innermost" blocks would need to be instrumented, and in most cases the rest can be assumed. Unfortunately, that probably means instrument

Re: GCov space optimization

On 23/07/2025 17:05, Jan Hubicka wrote: Am 23.07.2025 um 16:42 schrieb Andrew Stubbs : On 23/07/2025 15:22, Michael Matz wrote: Hello, On Tue, 22 Jul 2025, Andrew Stubbs wrote: Don’t you need to instrument more (or at least different) edges when only having visited bits ? With counters yo

Re: GCov space optimization

On Wed, 23 Jul 2025, Jan Hubicka via Gcc wrote: > > > Thank you for the careful explanation. It seems like all the "innermost" > > > blocks would need to be instrumented, and in most cases the rest can be > > > assumed. Unfortunately, that probably means instrumenting the hottest > > > blocks,

Re: GCov space optimization

> > > > Am 23.07.2025 um 16:42 schrieb Andrew Stubbs : > > > > On 23/07/2025 15:22, Michael Matz wrote: > >> Hello, > >> On Tue, 22 Jul 2025, Andrew Stubbs wrote: > Don’t you need to instrument more (or at least different) edges when > only having visited bits ? With counters you can

Re: GCov space optimization

> Am 23.07.2025 um 16:42 schrieb Andrew Stubbs : > > On 23/07/2025 15:22, Michael Matz wrote: >> Hello, >> On Tue, 22 Jul 2025, Andrew Stubbs wrote: Don’t you need to instrument more (or at least different) edges when only having visited bits ? With counters you can derive coverage

Re: GCov space optimization

On 23/07/2025 15:22, Michael Matz wrote: Hello, On Tue, 22 Jul 2025, Andrew Stubbs wrote: Don’t you need to instrument more (or at least different) edges when only having visited bits ? With counters you can derive coverage of related edges by diffing counters (consider a simple diamond). I

Re: GCov space optimization

Hello, On Tue, 22 Jul 2025, Andrew Stubbs wrote: > > Don’t you need to instrument more (or at least different) edges when > > only having visited bits ? With counters you can derive coverage of > > related edges by diffing counters (consider a simple diamond). > > I have not yet got this deep

Re: Patrick Palka as C++ front-end reviewer

On Tue, 22 Jul 2025, Jason Merrill wrote: > I am pleased to announce that the GCC Steering Committee has appointed > Patrick Palka as a reviewer for the C++ front-end. > Patrick, please update your listing in the MAINTAINERS file. Thank you! Updated MAINTAINERS in r16-2430-gc720869f0eed38. >

Re: GCov space optimization

On 22/07/2025 16:45, Richard Biener wrote: Am 22.07.2025 um 16:56 schrieb Andrew Stubbs : Hi all, Question: Would it be acceptable to introduce a new "counter" variety, together with options and UI support, that simply records a "visited" state? Have there been any previous efforts in thi

Re: GCov space optimization

> Am 22.07.2025 um 16:56 schrieb Andrew Stubbs : > > Hi all, > > Question: Would it be acceptable to introduce a new "counter" variety, > together with options and UI support, that simply records a "visited" state? > > Have there been any previous efforts in this space that I've missed? >

Re: Testsuite differences between native and cross build

On Jul 22 2025, Stefan Schulze Frielinghaus via Gcc wrote: > and the cross build with > > --target=x86_64-linux-gnu > --enable-languages=c > --without-headers > --enable-checking=yes,rtl > --disable-nls Using --without-headers can subtly change the compiler, better use a sysroot. > Sin

Re: Could we enhance the ifcombine pass?

ywgrit via Gcc writes: > Sure, I'll give an example of the performance gains that can be gained with > an ifcombine pass in the bugreport and cc you and Andrew Pinski on the > email. (Please file it on our Bugzilla.)

Re: Could we enhance the ifcombine pass?

Sure, I'll give an example of the performance gains that can be gained with an ifcombine pass in the bugreport and cc you and Andrew Pinski on the email. I'm here, extracting the example as the following demo, and I have the following question: // Way.h struct waymapt { int fillnum; int num; }

Re: hard-reg constraints: Question about materialization

On Mon, Jul 21, 2025 at 03:30:08PM +0200, Georg-Johann Lay wrote: > The recently pushed hreg-constraints (HRCs) feature has this in > the docs: > > > register asm may not only be clobbered by function calls but also by inline > asm in conjunction with hard register constraints. For example, in th

Re: Could we enhance the ifcombine pass?

On Sat, 19 Jul 2025, Andrew Pinski wrote: > On Sat, Jul 19, 2025 at 8:41 PM ywgrit via Gcc wrote: > > > > I've tested merging for nested branches on icc, and it seems that icc does > > a branch merge for code that might trap, making a more aggressive > > optimization. > > So it is not exactly it

Re: Could we enhance the ifcombine pass?

On Sat, Jul 19, 2025 at 8:41 PM ywgrit via Gcc wrote: > > I've tested merging for nested branches on icc, and it seems that icc does > a branch merge for code that might trap, making a more aggressive > optimization. So it is not exactly it might trap but rather it is part of a bigger struct and

Re: Could we enhance the ifcombine pass?

I've tested merging for nested branches on icc, and it seems that icc does a branch merge for code that might trap, making a more aggressive optimization. Way_.cpp struct waymapt { int fillnum; int num; }; typedef waymapt* waymappt; class wayobj { public: int boundl; waymappt waymap;

Re: Could we enhance the ifcombine pass?

Can we add a -merge-branch option to merge branch bbs when the programmer can ensure that the inner branch bb will not trap? Also, the current ifcombine pass can only merge very simple nested branches, and if statements usually generate multiple gimple statements, so a lot of merge opportunities ar

Re: GNU cargo (as a plugin to GCC)

2025年7月17日 2:25:44 JST、Basile Starynkevitch より: > >The Cuthour wrote to the GCC mailing list > >> I understand that GNU Make and C++ Modules address many current challenges >> with headers and dependency management. >> >> But what I'm suggesting is a build+package manager tightly integrated with

Re: Help with RTL/MD needed

On 14.07.2025 20:02, Jeff Law wrote: [...] MD is a completely new topic to me so I am looking for some hints how to debug the issue. Is it possible that this particular MD is not fully complete? Debugging failure to match is painful. I sometimes remove all the #line markers in the generated ins

Re: Could we enhance the ifcombine pass?

On Fri, 18 Jul 2025, ywgrit wrote: > For now, if combine pass can combine the simple nested comparison branches, > e.g. > if (a != b) > if (c == d) > These cond bbs must have only the conditional, which is too harsh. > > We often meet code like this: > if (a != b) > if (m[index] == k[index])

Re: Question about GCC license for commercial use

> AFAIU, having the shared libraries in separate files means they are > not "combined" with the program's code. That's how I understand what > RMS told me back then, in the quote that I brought up. Nothing in the GCC Runtime Exception says that the "Target Code" consists of a single file.

Re: Question about GCC license for commercial use

> Date: Thu, 17 Jul 2025 05:23:50 -0700 (PDT) > Cc: gcc@gcc.gnu.org, jwakely@gmail.com, qifan.z...@xpeedic.com > From: ken...@adacore.com (Richard Kenner) > > > I don't see how distributing in the same tarball would solve the > > problem. > > > > Suppose I'd decide to distribute a Windows bui

Re: Question about GCC license for commercial use

> I don't see how distributing in the same tarball would solve the > problem. > > Suppose I'd decide to distribute a Windows build of Emacs together > with GNU Grep (e.g., because MS-Windows systems don't come with Grep > OOTB, whereas Emacs users need Grep for several of its features). I > would

Re: Question about GCC license for commercial use

> Date: Thu, 17 Jul 2025 03:43:29 -0700 (PDT) > Cc: gcc@gcc.gnu.org, jwakely@gmail.com, qifan.z...@xpeedic.com > From: ken...@adacore.com (Richard Kenner) > > > > Yes, but the discussion wasn't about "as a separate file", but as a file > > > that's part of the distribution of another program.

Re: Question about GCC license for commercial use

> > Yes, but the discussion wasn't about "as a separate file", but as a file > > that's part of the distribution of another program. > > A shared library is always a separate file. Yes, of course. What I meant is that it's not *being distributed separately*. For example, it can be in the same t

Re: Question about GCC license for commercial use

> Date: Thu, 17 Jul 2025 02:28:36 -0700 (PDT) > Cc: gcc@gcc.gnu.org, jwakely@gmail.com, qifan.z...@xpeedic.com > From: ken...@adacore.com (Richard Kenner) > > > That's not what RMS told me when I asked him some time ago. He said > > that, since libgcc DLL and libstdc++ DLL are basically separ

Re: Question about GCC license for commercial use

> That's not what RMS told me when I asked him some time ago. He said > that, since libgcc DLL and libstdc++ DLL are basically separate files > and thus separate builds of the libraries, the run-time exception you > pointed to is not applicable to them. Quoting his response back then: > > Ther

Re: Question about GCC license for commercial use

> Date: Wed, 16 Jul 2025 19:03:21 +0200 > Cc: qifan.z...@xpeedic.com, gcc@gcc.gnu.org > From: David Brown > > >> Well they didn't ask about distributing the DLLs :-) > > > > They did, indirectly: programs compiled by MinGW GCC are linked > > against libgcc and libstdc++ import libraries, and thu

Re: Question about GCC license for commercial use

On 16/07/2025 17:37, Eli Zaretskii via Gcc wrote: From: Jonathan Wakely Date: Wed, 16 Jul 2025 16:12:01 +0100 Cc: qifan.z...@xpeedic.com, gcc@gcc.gnu.org On Wed, 16 Jul 2025 at 15:59, Eli Zaretskii wrote: Please stop giving bad advice and direct people to read the appropriate documentation.

Re: Question about GCC license for commercial use

> Date: Wed, 16 Jul 2025 17:44:41 +0200 > From: Dennis Luehring via Gcc > > Am 16.07.2025 um 17:37 schrieb Eli Zaretskii via Gcc: > > Unless the Windows loader can find them on > > the end-user's machine, it will refuse to run the program. > > the initial question was: do they fall under GPL whe

Re: Question about GCC license for commercial use

Am 16.07.2025 um 17:37 schrieb Eli Zaretskii via Gcc: Unless the Windows loader can find them on the end-user's machine, it will refuse to run the program. the initial question was: do they fall under GPL when just using gcc - how complex or error prone their distribution concepts get is of no

Re: Question about GCC license for commercial use

> From: Jonathan Wakely > Date: Wed, 16 Jul 2025 16:12:01 +0100 > Cc: qifan.z...@xpeedic.com, gcc@gcc.gnu.org > > On Wed, 16 Jul 2025 at 15:59, Eli Zaretskii wrote: > > > > > Please stop giving bad advice and direct people to read the > > > appropriate documentation. > > > > Why the animosity?

Re: Question about GCC license for commercial use

On Wed, 16 Jul 2025 at 15:59, Eli Zaretskii wrote: > > > From: Jonathan Wakely > > Date: Wed, 16 Jul 2025 15:08:50 +0100 > > Cc: qifan.z...@xpeedic.com, gcc@gcc.gnu.org > > > > > > AFAIU, this is accurate if libgcc and libstdc++ are linked statically, > > > > but not if the program is linked to t

Re: Question about GCC license for commercial use

> From: Jonathan Wakely > Date: Wed, 16 Jul 2025 15:08:50 +0100 > Cc: qifan.z...@xpeedic.com, gcc@gcc.gnu.org > > > > AFAIU, this is accurate if libgcc and libstdc++ are linked statically, > > > but not if the program is linked to their DLL versions (and therefore > > > the DLLs must be distribut

Re: Question about GCC license for commercial use

On Wed, 16 Jul 2025 at 15:06, Jonathan Wakely wrote: > > On Wed, 16 Jul 2025 at 13:21, Eli Zaretskii wrote: > > > > > Date: Wed, 16 Jul 2025 11:12:44 +0100 > > > Cc: gcc , gcc-help > > > From: Jonathan Wakely via Gcc > > > > > > On Wed, 16 Jul 2025 at 10:06, Qifan.Zhou via Gcc wrote: > > > > >

Re: Question about GCC license for commercial use

On Wed, 16 Jul 2025 at 13:21, Eli Zaretskii wrote: > > > Date: Wed, 16 Jul 2025 11:12:44 +0100 > > Cc: gcc , gcc-help > > From: Jonathan Wakely via Gcc > > > > On Wed, 16 Jul 2025 at 10:06, Qifan.Zhou via Gcc wrote: > > > > > > Dear GCC Team, > > > > Please don't email both gcc@gcc.gnu.org and

Re: Question about GCC license for commercial use

> Date: Wed, 16 Jul 2025 06:49:23 -0700 (PDT) > Cc: gcc@gcc.gnu.org, jwakely@gmail.com, qifan.z...@xpeedic.com > From: ken...@adacore.com (Richard Kenner) > > > Not if we are talking about Windows binaries intended to be used by > > people who don't have GCC installed. (The OP asked about Min

Re: Question about GCC license for commercial use

> Not if we are talking about Windows binaries intended to be used by > people who don't have GCC installed. (The OP asked about MinGW, which > is why I bring up this case.) These DLLs are part of the MinGW GCC > installation, but do not come with the OS OOTB. But then what the OP could do is to

Re: Question about GCC license for commercial use

> Date: Wed, 16 Jul 2025 06:20:42 -0700 (PDT) > Cc: gcc@gcc.gnu.org, jwakely@gmail.com, qifan.z...@xpeedic.com > From: ken...@adacore.com (Richard Kenner) > > > AFAIU, this is accurate if libgcc and libstdc++ are linked statically, > > but not if the program is linked to their DLL versions (an

Re: Question about GCC license for commercial use

> AFAIU, this is accurate if libgcc and libstdc++ are linked statically, > but not if the program is linked to their DLL versions (and therefore > the DLLs must be distributed with the resulting program). In the > latter case, the LGPL exception doesn't apply, and distributing these > DLLs falls u

Re: Question about GCC license for commercial use

> Date: Wed, 16 Jul 2025 11:12:44 +0100 > Cc: gcc , gcc-help > From: Jonathan Wakely via Gcc > > On Wed, 16 Jul 2025 at 10:06, Qifan.Zhou via Gcc wrote: > > > > Dear GCC Team, > > Please don't email both gcc@gcc.gnu.org and gcc-h...@gcc.gnu.org, pick > the appropriate one. You're not discussin

Re: GNU cargo

On Wed, 16 Jul 2025 at 11:11, David Brown via Gcc wrote: > > Some people do want a centralised source of C and/or C++ libraries and > other code, or other common repositories, as is found for a number of > other languages. Most C and C++ programmers, I think, understand that > this could only be

Re: Question about GCC license for commercial use

On Wed, 16 Jul 2025 at 10:06, Qifan.Zhou via Gcc wrote: > > Dear GCC Team, Please don't email both gcc@gcc.gnu.org and gcc-h...@gcc.gnu.org, pick the appropriate one. You're not discussing development of GCC so this belongs on the gcc-help list. Anyway ... > I hope this message finds you well.

Re: GNU cargo

When you are new to a mailing list or other discussion forum, it is a good idea to do one of two things - stick rigidly to rational technical points, or find out who you are talking to before straying from the technicalities. Insulting one of the big contributors and experts on gcc development

Re: GNU cargo

You must be AI. 2025年7月16日 5:07:45 JST、Andrew Pinski より: >On Tue, Jul 15, 2025 at 1:06 PM The Cuthour wrote: >> >> >> Facts >> >> (1) There's no header files in Java/Rust. >> (2) There's cargo in Rust. > >Ok, sounds like you want a language that is NOT C. Or you want to >improve the standard C/

Re: GNU cargo

On Tue, 15 Jul 2025 at 19:38, The Cuthour via Gcc wrote: > Would the GCC project consider supporting such a tool if developed > independently as cargo-cc? It could be a frontend to g++, like rustc is for > Rust, but standardized. If it's standardized, GCC would probably want to support it. Doe

Re: GNU cargo

On Tue, Jul 15, 2025 at 1:06 PM The Cuthour wrote: > > > Facts > > (1) There's no header files in Java/Rust. > (2) There's cargo in Rust. Ok, sounds like you want a language that is NOT C. Or you want to improve the standard C/C++ language. This is the wrong location to talk about doing that. >

Re: GNU cargo

Facts (1) There's no header files in Java/Rust. (2) There's cargo in Rust. I wish (1) There was no header files also in C/C++. (2) There was cargo also in C/C++. 2025年7月16日 3:50:19 JST、Andrew Pinski より: >On Tue, Jul 15, 2025 at 11:37 AM The Cuthour wrote: >> I understand that GNU Make and

Re: GNU cargo

uch a tool if developed > independently as cargo-cc? It could be a frontend to g++, like rustc is for > Rust, but standardized. > > > > ____ > From: Andrew Pinski > Sent: Tuesday, July 15, 2025 4:00:06 PM > To: The Cuthour > Cc: GCC Mailing Li

Re: GNU cargo

PM To: The Cuthour Cc: GCC Mailing List Subject: Re: GNU cargo On Mon, Jul 14, 2025, 11:46 PM The Cuthour via Gcc mailto:gcc@gcc.gnu.org>> wrote: I think Rust's cargo is a de facto standard build system and package manager, tightly integrated with the language and compiler. I'

Re: Addition of compiler flag for dynamic_cast optimization

Subject: [ext] Re: Addition of compiler flag for dynamic_cast optimization On Mon, Jul 14 2025, Jonathan Wakely via Gcc wrote: > On Mon, 14 Jul 2025 at 14:57, Thomas de Bock via Gcc wrote: >> >> Hello all, I've been looking into a compiler optimization implemented by >&

Re: Addition of compiler flag for dynamic_cast optimization

On Mon, Jul 14 2025, Jonathan Wakely via Gcc wrote: > On Mon, 14 Jul 2025 at 14:57, Thomas de Bock via Gcc wrote: >> >> Hello all, I've been looking into a compiler optimization implemented by >> clang but not gcc that substitutes a __dynamic_cast call for a simple vtable >> ptr comparison in th

Re: GNU cargo

On Mon, Jul 14, 2025, 11:46 PM The Cuthour via Gcc wrote: > > I think Rust's cargo is a de facto standard build system and package > manager, tightly integrated with the language and compiler. > > I'm proposing something similar for C and C++: > - cargo-c for C > - cargo-cc for C++ > - carg

Re: Switching x86-64 to GNU2 TLS descriptors

On Tue, Jul 15, 2025 at 3:26 AM H.J. Lu via Gcc wrote: > > On Tue, Jul 15, 2025 at 8:47 AM 'Florian Weimer' via X86-64 System V > Application Binary Interface wrote: > > > > * H. J. Lu: > > > > > Compilers will never know since the build-time glibc is independent of > > > the run-time glibc. If

Re: Switching x86-64 to GNU2 TLS descriptors

* H. J. Lu: > On Tue, Jul 15, 2025 at 8:47 AM 'Florian Weimer' via X86-64 System V > Application Binary Interface wrote: >> >> * H. J. Lu: >> >> > Compilers will never know since the build-time glibc is independent of >> > the run-time glibc. If compilers want to be 100% sure that the run-time

Re: Switching x86-64 to GNU2 TLS descriptors

Florian Weimer writes: > * H. J. Lu: > >> Compilers will never know since the build-time glibc is independent of >> the run-time glibc. If compilers want to be 100% sure that the run-time >> is GNU2 TLS bug-free, they can require linkers which generate the >> GLIBC_ABI_GNU2_TLS dependency. > >

Re: Switching x86-64 to GNU2 TLS descriptors

On Tue, Jul 15, 2025 at 8:47 AM 'Florian Weimer' via X86-64 System V Application Binary Interface wrote: > > * H. J. Lu: > > > Compilers will never know since the build-time glibc is independent of > > the run-time glibc. If compilers want to be 100% sure that the run-time > > is GNU2 TLS bug-fr

Re: Switching x86-64 to GNU2 TLS descriptors

* H. J. Lu: > Compilers will never know since the build-time glibc is independent of > the run-time glibc. If compilers want to be 100% sure that the run-time > is GNU2 TLS bug-free, they can require linkers which generate the > GLIBC_ABI_GNU2_TLS dependency. (Such a linker requirement could be

Re: Switching x86-64 to GNU2 TLS descriptors

On Tue, Jul 15, 2025 at 7:55 AM Florian Weimer wrote: > > * Adhemerval Zanella Netto: > > >> (b) Introduce binary markup to indicate that binaries may need the glibc > >> fix, and that glibc has the fix. > >> > >> [PATCH] x86-64: Add GLIBC_ABI_GNU2_TLS [BZ #33129] > >> > >>

Re: Switching x86-64 to GNU2 TLS descriptors

* Adhemerval Zanella Netto: >> (b) Introduce binary markup to indicate that binaries may need the glibc >> fix, and that glibc has the fix. >> >> [PATCH] x86-64: Add GLIBC_ABI_GNU2_TLS [BZ #33129] >> >> >>

Re: Help with RTL/MD needed

On 7/14/25 10:57 AM, Jan Dubiec via Gcc wrote: Recently I have started playing with machine descriptions in the context of PR109324 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109324). I have nodified MDs (see the attached patch) and got following ICE when I tried to build gcc: /d/Works/

Re: Pushing a lot of commits to an old branch

Thomas Koenig via Gcc writes: > Hi, > > there is a branch I want to update. Git currently tells me > > Your branch is ahead of 'origin/devel/coarray_native' by 28906 commits. > There are still a few ChangeLog entries to clean up, I'll make sure > that contrib/gcc-changelog/git_check_commit.py pas

Re: Addition of compiler flag for dynamic_cast optimization

4 To: Thomas de Bock Cc: gcc@gcc.gnu.org Subject: [ext] Re: Addition of compiler flag for dynamic_cast optimization On Mon, 14 Jul 2025 at 14:57, Thomas de Bock via Gcc wrote: > > Hello all, I've been looking into a compiler optimization implemented by > clang but not gcc that substi

Re: Addition of compiler flag for dynamic_cast optimization

On Mon, 14 Jul 2025 at 14:57, Thomas de Bock via Gcc wrote: > > Hello all, I've been looking into a compiler optimization implemented by > clang but not gcc that substitutes a __dynamic_cast call for a simple vtable > ptr comparison in the case that the class being cast to is final. > > However

Re: GCC 12.5 Released

On Mon, Jul 14, 2025 at 10:19:43AM +0100, Richard Earnshaw (lists) via Gcc wrote: > On 14/07/2025 08:04, Richard Biener via Gcc wrote: > > On Sat, Jul 12, 2025 at 7:06 AM Andrew Marlow via Gcc > > wrote: > >> > >> Hello Richard, > >> > >> Thank you for making these announcements, they are very u

Re: GCC 12.5 Released

On 14/07/2025 08:04, Richard Biener via Gcc wrote: > On Sat, Jul 12, 2025 at 7:06 AM Andrew Marlow via Gcc wrote: >> >> Hello Richard, >> >> Thank you for making these announcements, they are very useful and >> informative. But I have one small request to make. Please include a link to >> the web

Re: GCC 12.5 Released

On Sat, Jul 12, 2025 at 7:06 AM Andrew Marlow via Gcc wrote: > > Hello Richard, > > Thank you for making these announcements, they are very useful and > informative. But I have one small request to make. Please include a link to > the web page that describes the changes from the last release. The

Re: Pushing a lot of commits to an old branch

On 7/12/25 13:31, Thomas Koenig via Gcc wrote: Am 12.07.25 um 13:11 schrieb Jonathan Wakely via Gcc: Yes, it will probably make git unusable for a few hours, please don't push all at once! OK, I won't :-) There might be two other possibilities that I can think of: One would be to squash al

Re: Pushing a lot of commits to an old branch

On Sat, 12 Jul 2025 at 12:31, Thomas Koenig wrote: > > Am 12.07.25 um 13:11 schrieb Jonathan Wakely via Gcc: > > Yes, it will probably make git unusable for a few hours, please don't > > push all at once! > > OK, I won't :-) > > There might be two other possibilities that I can think of: > One wou

Re: Pushing a lot of commits to an old branch

Am 12.07.25 um 13:11 schrieb Jonathan Wakely via Gcc: Yes, it will probably make git unusable for a few hours, please don't push all at once! OK, I won't :-) There might be two other possibilities that I can think of: One would be to squash all the commits (most of which came from mainline gcc

Re: Pushing a lot of commits to an old branch

On Sat, 12 Jul 2025 at 12:07, Mikael Morin via Gcc wrote: > > Le 12/07/2025 à 11:46, Thomas Koenig via Gcc a écrit : > > > > After doing that, can I just do a "git push", or will this cause any bad > > effects like hanging servers etc? I seem to remember there were some > > issues a while back. >

Re: Pushing a lot of commits to an old branch

Le 12/07/2025 à 11:46, Thomas Koenig via Gcc a écrit : After doing that, can I just do a "git push", or will this cause any bad effects like hanging servers etc?  I seem to remember there were some issues a while back. The hooks don't scale very well as far as I know, and I expect a number of

Re: GCC 12.5 Released

Hello Richard, Thank you for making these announcements, they are very useful and informative. But I have one small request to make. Please include a link to the web page that describes the changes from the last release. The links are on the page https://gcc.gnu.org/releases.html and for this part

Re: smtgcc mid-year update

On Fri, 11 Jul 2025, Filip Kastl wrote: Please let me know if there are additional configurations you would like me to include in the testing. Seems like work on smtgcc is going nicely. Good to hear! Have you considered -Ofast or some subset of the flags it enables? Perhaps that would uncov

Re: smtgcc mid-year update

On Tue 2025-07-01 20:06:18, Krister Walfridsson via Gcc wrote: > I have continued working on my translation validator, smtgcc [1]. Here is an > update of what I have done since the end-of-year update. > > > smtgcc-tv-backend > - > The main focus has been improving the smtgcc-tv-ba

Re: [RFC] Add multi-attributes syntax to future `target_clones` in GFortran

Thanks for your interest to contribute to GCC. This request should be directed to the GNU Fortran mailing list. Thanks, David On Thu, Jul 10, 2025 at 1:44 PM 泽邦 贺 via Gcc wrote: > Dear GCC developers, > > Hello everyone! > > I am a member of the OSPP open source community who is very intereste

Re: libatomic vs. __atomic_test_and_set()

Hello, I am not sure how this should be fixed. For example, clang generates for the test case a call to __atomic_exchange_1(): https://godbolt.org/z/EY49jPs78 >From my point of view it makes more sense, if the compiler generates calls to >_1, _2, ... variants. GCC does it for atomic_uint_leas

Re: Criteria for adding AIX as a secondary platform.

Hi All, Please suggest if changes are required in the patch. Thanks, Sangamesh On Fri, Jul 4, 2025 at 11:48 PM swamy sangamesh wrote: > Tried with the below change and able to bootstrap on AIX and X86. > > diff --git a/gcc/tree.cc b/gcc/tree.cc > index e9a83e4260b..b693a58ab9d 100644 > --- a/g

Re: Switching x86-64 to GNU2 TLS descriptors

On 07/07/25 05:37, Florian Weimer via Gcc wrote: > H.J. proposed to switch the default for GCC 16 (turning on > -mtls-dialect=gnu2 by default). This is a bit tricky because when we > tried to make the switch in Fedora (for eventual implementation), we hit > an ABI compatibility problem: > >

Re: Offset vtable address

Managed to get it working with: tree index = build_int_cst (NULL_TREE, -2 * TARGET_VTABLE_DATA_ENTRY_DISTANCE); tree src_vptr = build_address(build_vtbl_ref(src_obj, index)); tree trgt_vtbl_decl = get_vtable_decl(target_type, 0); tree trgt_vtbl_addr =

Re: scan-*-dump-times across multiple functions considered harmful

On Thu, 2025-07-03 at 10:12 +0100, Joern Wolfgang Rennecke wrote: > > On 02/07/2025 18:59, David Malcolm wrote: >   ... > > Brainstorming some ideas on other possible approaches on making our > > tests less brittle; for context I did some investigation back in > > 2018 > > about implementing "op

Re: Switching x86-64 to GNU2 TLS descriptors

* Richard Biener: > I think both (a) or (d) are reasonable, though I am missing a > configure time flag to override the changed default. Even with > glibc fixed we likely do not want to have this change in older > enterprise code streams given there might be unknown external > tooling that might

Re: Switching x86-64 to GNU2 TLS descriptors

On Mon, Jul 7, 2025 at 10:50 AM Richard Biener wrote: > > On Mon, Jul 7, 2025 at 10:39 AM Florian Weimer via Gcc > wrote: > > > > H.J. proposed to switch the default for GCC 16 (turning on > > -mtls-dialect=gnu2 by default). This is a bit tricky because when we > > tried to make the switch in F

Re: Switching x86-64 to GNU2 TLS descriptors

On Mon, Jul 7, 2025 at 10:39 AM Florian Weimer via Gcc wrote: > > H.J. proposed to switch the default for GCC 16 (turning on > -mtls-dialect=gnu2 by default). This is a bit tricky because when we > tried to make the switch in Fedora (for eventual implementation), we hit > an ABI compatibility pro

Re: Switching x86-64 to GNU2 TLS descriptors

On Mon, Jul 7, 2025 at 4:37 PM Florian Weimer wrote: > > H.J. proposed to switch the default for GCC 16 (turning on > -mtls-dialect=gnu2 by default). This is a bit tricky because when we > tried to make the switch in Fedora (for eventual implementation), we hit > an ABI compatibility problem: > >

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

On Mon, 7 Jul 2025, Iain Sandoe wrote: > > > > On 4 Jul 2025, at 08:53, Richard Biener via Gcc wrote: > > > > The first release candidate for GCC 12.5 is available from > > > > https://gcc.gnu.org/pub/gcc/snapshots/12.5.0-RC-20250704/ > > ftp://gcc.gnu.org/pub/gcc/snapshots/12.5.0-RC-20250704

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

> On 4 Jul 2025, at 08:53, Richard Biener via Gcc wrote: > > The first release candidate for GCC 12.5 is available from > > https://gcc.gnu.org/pub/gcc/snapshots/12.5.0-RC-20250704/ > ftp://gcc.gnu.org/pub/gcc/snapshots/12.5.0-RC-20250704/ > > and shortly its mirrors. It has been generated

Re: smtgcc mid-year update

On Wed, 2 Jul 2025, Sam James wrote: Please let me know if there are additional configurations you would like me to include in the testing. We sometimes get interesting bugs, especially with UBSAN (-fsanitize=undefined), with SAVE_EXPR. PR120471 is one example and PR120837 is another. These

Re: Compiler optimization help

mean I now know I cannot compare the type info in this way, but are there any already implemented functions that let you retrieve the vtable and the address of the base class vtable from a type that someone could point me to? From: Thomas de Bock Sent: 04 July 20

Re: building generic tree to compare base classes at runtime

I mean I now know I cannot compare the type info in this way, but are there any already implemented functions that let you retrieve the vtable and the address of the base class vtable from a type that someone could point me to? From: Gcc on behalf of Thomas de

RE: What's up with CXXFLAGS_FOR_BUILD?

> -Original Message- > From: Eric Botcazou > Sent: Friday, July 4, 2025 04:11 > To: Robert Dubner > Cc: gcc@gcc.gnu.org > Subject: Re: What's up with CXXFLAGS_FOR_BUILD? > > > This raises two, presumably related, questions. > > > > 1) Wha

Re: Criteria for adding AIX as a secondary platform.

Tried with the below change and able to bootstrap on AIX and X86. diff --git a/gcc/tree.cc b/gcc/tree.cc index e9a83e4260b..b693a58ab9d 100644 --- a/gcc/tree.cc +++ b/gcc/tree.cc @@ -64,6 +64,7 @@ along with GCC; see the file COPYING3. If not see #include "stringpool.h" #include "attribs.h" #i

Re: What's up with CXXFLAGS_FOR_BUILD?

> This raises two, presumably related, questions. > > 1) What is CXXFLAGS_FOR_BUILD supposed to be doing? Set CXXFLAGS when you're compiling something for the build platform. > 2) How can I set compilation switches for gcc stuff (like the gcc/cobol > front end) without affecting lib*** stuff? I

Re: New AArch64 maintainers and reviewers appointed

On Wed, Jul 2, 2025 at 8:36 PM David Edelsohn wrote: > > I am pleased to announce that the GCC Steering Committee has appointed Tamar > Christina as AArch64 maintainer. I am pleased to announce that the GCC > Steering Committee has appointed Alex Coplan, Alice Carlotti, Andrew Pinski, > and Wi

  1   2   3   4   5   6   7   8   9   10   >