Re: hard-reg constraints in md: spill fails from LRA

FYI, here are the IRA and LRA dumps as of -da Am 04.08.25 um 13:04 schrieb Georg-Johann Lay via Gcc: Rewriting avr.md so it uses less explicit hard registers, I came across the ICE below.  I am using 2 patches as attached: - A tentative fix for LRA https://gcc.gnu.org/PR121198 - A WIP to rewri

Re: Help with RTL/MD needed

On 7/18/25 10:18 AM, Jan Dubiec wrote: 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

Re: Help with RTL/MD needed

On 7/18/25 10:18 AM, Jan Dubiec wrote: Good.  Note that I've got a tester I can throw things into.  I'll do a regression test of mh, ms, msx with -mint32.  I can add your patch to that tester to see what happens. I would be nice. The new version is in the attachment. I run tests on the simu

Re: acceptable diagnostic format characters

On Fri, Aug 01, 2025 at 01:32:47PM -0400, James K. Lowden wrote: > As I said, the pointer arithmetic in this case will disappear. I intend > to modify the function that now returns a pointer to return size_t, > because that's what std::vector::operator[] accepts. In my mind the > question remains

Re: acceptable diagnostic format characters

On Thu, 31 Jul 2025 23:02:20 +0200 Rainer Orth wrote: > >> This code is just wrong. %zu expects size_t but the argument is > >> ptrdiff_t That is indisputable. In this case, we know args.data() < p, so the difference will never be negative, and the high bit always zero. But, sure. Jakub provid

Re: acceptable diagnostic format characters

Hi James > On 31 Jul 2025, at 21:22, James K. Lowden wrote: > > 3. The last 32-bit Apple machine was manufactured in 2006, before Taylor > Swift was famous, when we still knew where Jim Gray was. I agree with Jakub that there’s no specific reason to single out 32b Darwin, there are plenty

Re: acceptable diagnostic format characters

On Thu, Jul 31, 2025 at 11:02:20PM +0200, Rainer Orth via Gcc wrote: > Hi Jonathan, > > > On Thu, 31 Jul 2025, 22:44 Jonathan Wakely, wrote: > > > >> > >> > >> On Thu, 31 Jul 2025, 22:23 James K. Lowden, > >> wrote: > >> > >>> I want to understand what our baseline is wrt %z in diagnostic > >>>

Re: acceptable diagnostic format characters

On Thu, Jul 31, 2025 at 04:22:20PM -0400, James K. Lowden wrote: > I want to understand what our baseline is wrt %z in diagnostic > messages. The proximate cause is this change on July 11 for 32-bit > Darwin to gcc/cobol/parse.y: > >error_msg(loc, "FUNCTION %qs has " > -"inconsist

Re: acceptable diagnostic format characters

Hi Jonathan, > On Thu, 31 Jul 2025, 22:44 Jonathan Wakely, wrote: > >> >> >> On Thu, 31 Jul 2025, 22:23 James K. Lowden, >> wrote: >> >>> I want to understand what our baseline is wrt %z in diagnostic >>> messages. The proximate cause is this change on July 11 for 32-bit >>> Darwin to gcc/cobol

Re: acceptable diagnostic format characters

On Thu, 31 Jul 2025, 22:44 Jonathan Wakely, wrote: > > > On Thu, 31 Jul 2025, 22:23 James K. Lowden, > wrote: > >> I want to understand what our baseline is wrt %z in diagnostic >> messages. The proximate cause is this change on July 11 for 32-bit >> Darwin to gcc/cobol/parse.y: >> >>error_

Re: acceptable diagnostic format characters

On Thu, 31 Jul 2025, 22:23 James K. Lowden, wrote: > I want to understand what our baseline is wrt %z in diagnostic > messages. The proximate cause is this change on July 11 for 32-bit > Darwin to gcc/cobol/parse.y: > >error_msg(loc, "FUNCTION %qs has " > -"inconsistent parameter

Re: GCC 15.1.1 Status Report (2025-07-11)

On Mon, Jul 28, 2025 at 11:49:59AM -0500, Robert Dubner wrote: > I would like to know exactly what you did. Did you create a list of commit > hashes that you then attempted to cherry-pick, one at a time, so that you > could evaluate each result and decide to skip it or not? Perhaps for start gi

RE: GCC 15.1.1 Status Report (2025-07-11)

> -Original Message- > From: Thomas Schwinge > Sent: Monday, July 28, 2025 11:05 > To: Robert Dubner > Cc: Richard Biener ; Andreas Schwab ; > David > Malcolm ; gcc@gcc.gnu.org; gcc-patc...@gcc.gnu.org; > James > K. Lowden > Subject: RE: GCC 15.1.1 Sta

RE: GCC 15.1.1 Status Report (2025-07-11)

know why I can't do such a big update to > just COBOL. > > Best regards to all, > > Bob Dubner > >> -Original Message- >> From: Robert Dubner >> Sent: Sunday, July 27, 2025 11:25 >> To: Richard Biener >> Cc: gcc@gcc.gnu.org; gcc

RE: GCC 15.1.1 Status Report (2025-07-11)

> -Original Message- > From: Richard Biener > Sent: Monday, July 28, 2025 04:17 > To: Robert Dubner > Cc: Andreas Schwab ; Thomas Schwinge > ; > David Malcolm ; gcc@gcc.gnu.org; > gcc-patc...@gcc.gnu.org; > James K. Lowden > Subject: RE: GCC 15.1.1 Sta

RE: GCC 15.1.1 Status Report (2025-07-11)

stuff. But it's now also way too late to do all this manual surgery. Thanks, Richard. > Best regards to all, > > Bob Dubner > > > -Original Message- > > From: Robert Dubner > > Sent: Sunday, July 27, 2025 11:25 > > To: Richard Biener > > Cc:

RE: GCC 15.1.1 Status Report (2025-07-11)

rd Biener > Cc: gcc@gcc.gnu.org; gcc-patc...@gcc.gnu.org; James K. Lowden > > Subject: RE: GCC 15.1.1 Status Report (2025-07-11) > > Thanks to everybody. I actually did do the more specific searches over a > range starting at the gcc-15 starting point; in my frustration I didn&#

RE: GCC 15.1.1 Status Report (2025-07-11)

7, 2025 06:56 > To: Robert Dubner > Cc: gcc@gcc.gnu.org; gcc-patc...@gcc.gnu.org; James K. Lowden > > Subject: RE: GCC 15.1.1 Status Report (2025-07-11) > > On Sat, 26 Jul 2025, Robert Dubner wrote: > > > > > > > > -Original Message- > > > Fr

RE: GCC 15.1.1 Status Report (2025-07-11)

On Sat, 26 Jul 2025, Robert Dubner wrote: > > > > -Original Message- > > From: Richard Biener > > Sent: Saturday, July 26, 2025 12:06 > > To: Robert Dubner > > Cc: gcc@gcc.gnu.org; gcc-patc...@gcc.gnu.org; James K. Lowden > > > > S

Re: GCC 15.1.1 Status Report (2025-07-11)

On Jul 27 2025, Thomas Schwinge wrote: > Hi Bob! > > On 2025-07-27T08:55:04+0200, Andreas Schwab wrote: >> On Jul 26 2025, Robert Dubner wrote: >>> Follow-up: After poking around on the internet for inspiration, I used >>> >>> git log >>> basepoints/gcc-15~1..HEAD --reverse --grep="^gcc/cobol"

Re: GCC 15.1.1 Status Report (2025-07-11)

Hi Bob! On 2025-07-27T08:55:04+0200, Andreas Schwab wrote: > On Jul 26 2025, Robert Dubner wrote: >> Follow-up: After poking around on the internet for inspiration, I used >> >> git log >> basepoints/gcc-15~1..HEAD --reverse --grep="^gcc/cobol" --grep="^libgcobol" >> --grep="cobol.dg" You ne

Re: GCC 15.1.1 Status Report (2025-07-11)

On Jul 26 2025, Robert Dubner wrote: > Follow-up: After poking around on the internet for inspiration, I used > > git log > basepoints/gcc-15~1..HEAD --reverse --grep="^gcc/cobol" --grep="^libgcobol" > --grep="cobol.dg" git rev-list --reverse --grep=^cobol --grep=^libgcobol origin/releases/g

RE: GCC 15.1.1 Status Report (2025-07-11)

> -Original Message- > From: Richard Biener > Sent: Saturday, July 26, 2025 12:06 > To: Robert Dubner > Cc: gcc@gcc.gnu.org; gcc-patc...@gcc.gnu.org; James K. Lowden > > Subject: Re: GCC 15.1.1 Status Report (2025-07-11) > > > > > Am 26.07

RE: GCC 15.1.1 Status Report (2025-07-11)

> -Original Message- > From: Richard Biener > Sent: Saturday, July 26, 2025 12:06 > To: Robert Dubner > Cc: gcc@gcc.gnu.org; gcc-patc...@gcc.gnu.org; James K. Lowden > > Subject: Re: GCC 15.1.1 Status Report (2025-07-11) > > > > > Am 26.07

Re: GCC 15.1.1 Status Report (2025-07-11)

> Am 26.07.2025 um 01:31 schrieb Robert Dubner : > > Richard, this message of yours about changes for 15.2 RC has been > percolating in my head since I first saw it. > > So, today I gave it a shot. > > A significant amount of COBOL development has occurred in the four months > since GCC-15 w

RE: GCC 15.1.1 Status Report (2025-07-11)

Richard, this message of yours about changes for 15.2 RC has been percolating in my head since I first saw it. So, today I gave it a shot. A significant amount of COBOL development has occurred in the four months since GCC-15 was released. I just built a patch that brought changes in COBOL from

Re: [RISC-V][RVV] wide bitfield insertion & extractions to/from vector regs

There are two levels of dysfunction here: 1. Why spill & fill through the stack? Why not extract scalars directly from vregs directly into scalar regs? 2. Why involve scalar registers at all? Why not vslide or even vrgather, using temporary vregs as necessary? That's how expmed does

Re: Switching x86-64 to GNU2 TLS descriptors

"H.J. Lu" writes: > 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 ru

Re: Slight typo in #ifdef C preprocessor documentation

On Wed, Jul 23, 2025 at 7:48 PM Evan Cooney via Gcc wrote: > > Hello GNU GCC Developers, > > My name is Evan Cooney and I'm a student at the University of Missouri. I > was reading the documentation for the #ifdef preprocessor macro and I think > I found a slight typo. It is in section 4.2.1 "Ifde

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

  1   2   3   4   5   6   7   8   9   10   >