> 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?
>
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,
.c i386.exp=asm-hard-reg-*.c
--target_board='unix{,-m32}'"
shows no unexpected failures. However, running the tests via cross
compiler some of the tests fail:
...
Target is x86_64-pc-linux-gnu
Host is s390x-ibm-linux-gnu
=== gcc tests ===
Schedule of variatio
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.)
ch won't trap by the relationship between the outer
branch and the inner branch? If this is possible then ifcombine pass can
do a merge on this nested branch. In spec2006's 473.astar program, this
nested branch is a hotspot with poor prediction accuracy, so the
performance improvement
ment and the
inline asm. For example
long bar (void);
long
foo (void)
{
register long x asm ("rax") = 42;
bar ();
asm volatile ("" :: "r" (x));
return x;
}
On x86_64, the assignment $rax=42 materializes before the function call.
Since the functions return va
__asm ("inc %0" : "+r" (z));
return x; // returning in r24
}
The 1st asm is clobbering r24, and therefore x must not be kept in
r24 at that point. This is demonstrated by the generated code:
$ avr-gcc asm.c -S -Os -dp
func:
mov r25,r24 ; 20 [c=4 l=1]
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
> > optimiz
Snapshot gcc-16-20250720 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/16-20250720/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 16 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
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
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;
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
are you serious right now?? – lauren
https://docs.google.com/presentation/d/1_mSFedxtPqDadkvUww75hdUF4cyCZP_vJlVYQEtwTZo/edit?usp=sharing#PbCWtqwO
you’re making me question everything – april
https://docs.google.com/presentation/d/1h0mw6RJX9IODRhL5T8aMcROZDTQY1bTQeqAEgqnd0dM/edit?usp=sharing#46Is4u
Snapshot gcc-15-20250719 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/15-20250719/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 15 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
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+p
Snapshot gcc-14-20250718 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/14-20250718/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 14 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
insn-recog.cc files and follow the recognizer,
but that's only when I can't see what's going on with visual inspection
of the dumps & md file.
After spending two days I have found the source of the problem, however,
to my surprise, in completely different place:
diff --git
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])
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])
m and c are arrays, so the 2nd branch belongs to a bb
Hi all,
I filed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121157
for an error when compiling to an object file with -gcodeview.
Mark Harmstone, I think you might be interested in this.
Regards,
Tom
> 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.
Snapshot gcc-13-20250717 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-20250717/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
> 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.
> >
> > S
for several of its features). I
> would then make a single tarball including both Emacs- and
> Grep-related files. Does that mean that I'm not under an obligation
> to provide source code of _both_ Emacs and Grep? I don't think so.
That has nothing to do with the issue here. We&
> 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&
> > 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
> 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 an
> 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
> 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
> > agains
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
> 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 q
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
> 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 d
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,
>
> 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 th
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 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,
> 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 in
> 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 t
> 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 link
> 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
> 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,
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
> thi
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 mes
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
Dear GCC Team,
I hope this message finds you well. I'm writing to seek official clarification
regarding the use of GCC compilers in our proprietary, closed-source commercial
software development.
Our specific use case involves:
1.
Using GCC executables (gcc.exe<https://gcc.exe/>, g
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/
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
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.
>
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
to handle automatic dependence generation for headers
> >already and is how gcc handles its own build system without having to
> >record every new header that is included.
> >
>
> I understand that GNU Make and C++ Modules address many current challenges
> with head
2025年7月15日 16:00:06 JST、Andrew Pinski より:
>There are c++ modules. Which is being designed. Maybe that is what you
>looking for.
>
>Also Why not just use gnu make?
>
>It has the ability to handle automatic dependence generation for headers
>already and is how gcc handles
I believe the project configurations in which the optimization causes problems
might be too common to add it to a flag like that from the get-go. Andi Kleen
suggested on the gcc thread, to have the use of the optimization be dependent
on -fno-semtantic-interposition, -flto and -fwhole-program
Hello,
I'm preparing a proposal for a licensing BoF for the Cauldron where
licensing-related questions of the maintainers and developers of the
toolchain projects could be answered. The BoF is intended as an
informal, interactive exchange about the topics you find interesting and
also an oppo
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-
ing the
syntax
Do you think this direction could benefit the GNU system or help evolve GCC?
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 gl
and option specific to GLIBC_ABI_GNU2_TLS, and
>> that current linkers treat as an error.)
>>
>> Would such an unconditional requirement be acceptable to GCC 16? I
>> don't think so. So we'd still have to design a configure option for it.
>> And that requires f
GLIBC_ABI_GNU2_TLS dependency.
>
> (Such a linker requirement could be enforced by requiring that the
> linker recognizes a command option specific to GLIBC_ABI_GNU2_TLS, and
> that current linkers treat as an error.)
>
> Would such an unconditional requirement be acceptable to GCC
t current linkers treat as an error.)
>
> Would such an unconditional requirement be acceptable to GCC 16? I
> don't think so. So we'd still have to design a configure option for it.
> And that requires further compiler changes. It's also not entirely
> clear how this would
rement could be enforced by requiring that the
linker recognizes a command option specific to GLIBC_ABI_GNU2_TLS, and
that current linkers treat as an error.)
Would such an unconditional requirement be acceptable to GCC 16? I
don't think so. So we'd still have to design a configure o
_ABI_GNU2_TLS [BZ #33129]
> >>
> >> <https://inbox.sourceware.org/libc-alpha/20250704205341.155335-1-hjl.to...@gmail.com/>
> >>
> >> This requires changes to all linkers, GCC and glibc.
>
> >> I'm personally leaning towards (d) or (a) for GCC 16. I
0704205341.155335-1-hjl.to...@gmail.com/>
>>
>> This requires changes to all linkers, GCC and glibc.
>> I'm personally leaning towards (d) or (a) for GCC 16. I dislike (b).
>> And (e) is unrealistic in the short term.
>
> We did something similar to (b) f
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
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 contr
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/xcomp/gcc-build-stage1/./gcc/xgcc
-B/d/Works
I had not, but here is some code which I compiled with the same gcc version,
the only difference being that in one, I had the optimization enabled:
#include
#include
#include
struct A {
virtual ~A() {}
};
struct B final : A {
virtual ~B() {}
};
B* __attribute__ ((noinline)) dc(A* a
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 f
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 this brings issues with it in some cases (specified in threa
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,
> >>
> >> Than
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. Pl
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
Snapshot gcc-16-20250713 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/16-20250713/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 16 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
Snapshot gcc-15-20250712 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/15-20250712/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 15 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
Hi,
On July 16th at 10 AM CEST we have a live webinar about Open Source Tool
Qualification.
Learn how gcc based C/C++ compilers and gcov can be qualified for safety
critical applications.
In this webinar on Wednesday 10 AM CEST, we show how we can qualify open source
tools for safety relevant
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
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 fro
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
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 expe
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 passes before
committing.
A
particular
release, 12.5, the release notes link can be seen from
https://gcc.gnu.org/gcc-12 (the changes are at
https://gcc.gnu.org/gcc-12/changes.html).
On Fri, 11 Jul 2025 at 13:51, Richard Biener wrote:
> The GNU Compiler Collection version 12.5 has been released.
>
> GCC 12.5 is
Snapshot gcc-14-20250711 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/14-20250711/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 14 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
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
The releases/gcc-15 branch is open for regression and documentation fixes.
This is now the time to prepare for the GCC 15.2 release - a release
candidate is planned for Friday Aug 1st, three weeks from now, with
the GCC 15.2 release following a week after that.
Please go over reported
The GNU Compiler Collection version 12.5 has been released.
GCC 12.5 is a bug-fix release from the GCC 12 branch
containing important fixes for regressions and serious bugs in
GCC 12.4 with more than 241 bugs fixed since the previous release.
This is also the last release from the GCC 12 branch
The GCC 12 branch is now closed, no further changes can be pushed
there.
Snapshot gcc-13-20250710 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-20250710/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
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 commun
Dear GCC developers,
Hello everyone!
I am a member of the OSPP open source community who is very interested in C
language and GCC development. I am currently adding multi-versioning support to
GFortran. Specifically, I am adding `target` and `target_clones` support at the
function and
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 10
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 compatibi
= build_address(trgt_vtbl_decl);
From: Thomas de Bock
Sent: 07 July 2025 16:05:17
To: gcc@gcc.gnu.org
Subject: Offset vtable address
Currently working with the C++-frontend, I am trying to compare the addresses
of the "trgt" (originally a type
Currently working with the C++-frontend, I am trying to compare the addresses
of the "trgt" (originally a type) and "src" (originally a class instance)
vtables.
Currently I am successfully retrieving the vptr value of the src instance at
runtime, and the vtable address of the trgt at compiletim
become more unified; thus the testsuite will have to
> be adjusted.
> FWIW, even you you were to get rid of the current dump files (which
> I think would be stifling for GCC development for the above
> reasons), you would have to adjust the testsuite.
> So, we could use the json fr
Dear Gcc,
I hope this message finds you well. I wanted to check in regarding the message
I sent earlier about the Yamaha piano that belonged to my late husband. It’s a
special piece with a lot of meaning, and I’d be so happy if it ended up with
someone who truly appreciates music.
Please feel
* 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
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
>
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 AB
1 - 100 of 10347 matches
Mail list logo
