On Thu, Aug 07, 2025 at 03:25:45PM +, Thomas de Bock wrote:
> "I see what you mean, I think there is probably no way to apply the
> optimization to all functions then indeed, since there is no way to
> know if the early break on inequality of a field was arbitrary
> or because it indicates the
On Thu, Aug 07, 2025 at 08:12:44PM +0200, Toon Moene wrote:
> On 8/7/25 18:38, Andrew Pinski (QUIC) via Gcc wrote:
>
> > So looking into https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121448, I
> > Noticed the options needed to hit this is `-fsignaling-nans
> > -ffinite-math-only`. These 2 options
On Thu, Aug 07, 2025 at 09:37:24AM +, Thomas de Bock wrote:
> Why does that it not matter that the destination of all the chain blocks'
> FALSE edge is the same, if we have:
> :
> _1 = this_13(D)->a;
> _2 = _14(D)->a;
> if (_1 == _2)
> goto ; [INV]
> else
> goto ; [INV]
> :
> _3 = this_13
On Wed, Aug 06, 2025 at 01:32:07PM +, Thomas de Bock wrote:
> Apologies if I was unclear or misunderstand, I believe that's exactly what I
> am
> doing right now. I change the !='s' to =='s' and switch their true with their
> false
> edge, from there we can simply find the equality edge by fi
On Wed, Aug 06, 2025 at 12:29:09PM +, Thomas de Bock wrote:
> I've looked at the pattern LLVM recognizes and there is indeed a lot of
> different
> ways we could recognize the chains and generalize the optimization.
> The way I do the pattern recognition now is by changing the conditions to ==
On Wed, Aug 06, 2025 at 08:48:55AM +0200, Richard Biener via Gcc wrote:
> For loops the canonical place to perform such optimization is the loop
> distribution pass which already recognizes
> memcpy but also strlen (strcmp is more like strlen).
>
> For straight-line code there's also a bugreport a
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
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
> >>>
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
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
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
On Tue, Jul 01, 2025 at 09:44:50PM +0200, Eric Botcazou wrote:
> > Some years ago (well, 5+ honestly) I was using I think 119 to help
> > figure out some endian-specific bugs in a patch I was working on. It
> > is slightly worrying if AIX/power support has bitrotted due to it
> > being kicked off t
On Sun, Jun 29, 2025 at 06:28:11AM +0200, Alejandro Colomar via Gcc wrote:
> --- i/libcpp/include/cpplib.h
> +++ w/libcpp/include/cpplib.h
> @@ -1363,6 +1363,7 @@ struct cpp_num
> #define CPP_N_SIZE_T 0x200 /* C++23 size_t literal. */
> #define CPP_N_BFLOAT16 0x400 /* std::bfloat16_t t
On Wed, Jun 18, 2025 at 11:34:42AM +0200, Pierrick Philippe wrote:
> Hi everyone,
>
> I am currently reading the C23 standard along the pre-release GCC 16
> documentations (users and internals), and I noticed that there is no
> mention on how to create new attributes using the new C23 standard
> a
On Tue, Jun 10, 2025 at 09:52:42AM +0200, David Brown via Gcc wrote:
> So while correcting the mistakes of the past is either very slow or
> impossible, we can avoid them in the future. Consistent parameter order
> makes code clearer and neater, and should be encouraged.
If the clauses are proper
On Thu, Jun 05, 2025 at 09:25:11PM +0200, JeanHeyd Meneide wrote:
> The C and C++ Compatibility Study Group, when working on the new
> standard `#embed` preprocessor parameter that mirrors the
> `clang::offset(...)` and `gnu::offset(...)` parameters, had someone
> raise a concern that the order of
Status
==
The GCC 13.4 release tarballs have been created, the releases/gcc-13
branch is open again for regression and documentation bugfixing.
GCC 13.5 can be expected in a year and a few months unless something
serious changes the plans.
Quality Data
Priority # Cha
The GNU Compiler Collection version 13.4 has been released.
GCC 13.4 is a bug-fix release from the GCC 13 branch
containing important fixes for regressions and serious bugs in
GCC 13.3 with more than 129 bugs fixed since the previous release.
This release is available from the FTP servers listed
The second release candidate for GCC 13.4 is available from
https://gcc.gnu.org/pub/gcc/snapshots/13.4.0-RC-20250530/
ftp://gcc.gnu.org/pub/gcc/snapshots/13.4.0-RC-20250530/
and shortly its mirrors. It has been generated from git commit
r13-9730-gec78a0d9962f144.
I have so far bootstrapped an
Status
==
The GCC 13 branch is now frozen for the GCC 13.4 release, a release
candidate is being prepared.
All changes to the branch require release manager approval.
Quality Data
Priority # Change from last report
--- ---
P1
P2
The first release candidate for GCC 13.4 is available from
https://gcc.gnu.org/pub/gcc/snapshots/13.4.0-RC-20250529/
ftp://gcc.gnu.org/pub/gcc/snapshots/13.4.0-RC-20250529/
and shortly its mirrors. It has been generated from git commit
r13-9726-gaf73c8bf5168848.
I have so far bootstrapped and
On Wed, May 14, 2025 at 09:55:07PM +0200, ASSI wrote:
> That seems appropriate for the GCC Releases document, while the one I
> linked to is advertised to show "future releases and an alternative view
> of the release history". But I get it that it's just not getting an
> update at this time so th
On Wed, Apr 30, 2025 at 08:56:57AM +0200, Jakub Jelinek wrote:
> On Mon, Apr 28, 2025 at 07:27:31PM +0200, Josef Melcr wrote:
> > As for the attribute, I am honestly not too sure about what to do, as clang
> > is
> > not consistent in with its own indexing, be it with t
Status
==
The GCC 15.1 release tarballs have been created, the releases/gcc-15
branch is open again for regression and documentation bugfixing.
GCC 15.2 can be expected in about two months unless something serious
changes the plans.
Quality Data
Priority # Change fro
The GCC developers are proud to announce a new major GCC release, 15.1.
The C frontend now defaults to the GNU C23 dialect. Some code needs
porting for this, see https://gcc.gnu.org/gcc-15/porting_to.html#c23
for more details. Some remaining C23 features have been implemented,
as well as some ne
The second release candidate for GCC 15.1 is available from
https://gcc.gnu.org/pub/gcc/snapshots/15.1.0-RC-20250423/
ftp://gcc.gnu.org/pub/gcc/snapshots/15.1.0-RC-20250423/
and shortly its mirrors. It has been generated from git commit
r15-9577-g3483a2b39591db06.
I have so far bootstrapped a
The first release candidate for GCC 15.1 is available from
https://gcc.gnu.org/pub/gcc/snapshots/15.1.0-RC-20250418/
ftp://gcc.gnu.org/pub/gcc/snapshots/15.1.0-RC-20250418/
and shortly its mirrors. It has been generated from git commit
r15-9556-g96171a5cc7b99cb6.
I have so far bootstrapped an
On Tue, Apr 01, 2025 at 10:09:56AM +0200, Martin Jambor wrote:
> The simple fix is to initialize the variable to nullptr in the source,
> of course. :-)
It is a false positive.
gimple *stmt;
...
for (gsi = gsi_last_bb (bb); !gsi_end_p (gsi); gsi_prev (&gsi))
{
stmt = gsi_stmt (gsi);
On Tue, Apr 01, 2025 at 09:19:08AM +0200, Richard Biener via Gcc wrote:
> On Tue, Apr 1, 2025 at 12:04 AM Thomas Schwinge
> wrote:
> > In Nvidia PTX, "A state space is a storage area with particular
> > characteristics. All variables reside in some state space. [...]".
> > These include:
> >
>
On Tue, Mar 25, 2025 at 07:21:32AM +0300, Eldar Kusdavletov via Gcc wrote:
> *Dear GCC Mentoring Team,*
> I am writing to submit my proposal for the Google Summer of Code (GSoC)
> 2025 program, aiming to contribute to the GCC project by implementing a
> feature similar to Clang's -ftime-trace. This
On Sat, Mar 15, 2025 at 12:20:14PM -0500, Robert Dubner wrote:
> Details. Easy-peasy. I'll probably create some python scripts for doing
> it in a more general way for my directory structures, where each test is
> in its own directory.
>
> And then for UAT I'll have to extract both the source co
On Sat, Mar 15, 2025 at 05:34:21PM +0100, Jakub Jelinek via Gcc wrote:
> So, if you have test-0001.cob and test-0001.expected-output, you could do
> for i in *.cob; do \
> sed 's/\([].*()[]\)/\\\1/g;s/^/*> { dg-output {/;s/$/(\\n|\\r\\n|\\r)}
> }/;$s/.\{12\}} }$/} }/'
On Sat, Mar 15, 2025 at 11:02:59AM -0500, Robert Dubner wrote:
> I am struggling with the learning curves, here. I am trying to understand
> dejagnu, and I am trying to understand tcl, and I am trying to understand
> the testsuite chain of commands and files that result, somehow, in the
> programs
On Thu, Feb 27, 2025 at 08:44:25PM +, Joseph Myers via Gcc wrote:
> On Thu, 27 Feb 2025, Alejandro Colomar via Gcc wrote:
>
> > Can you please confirm if we should add a version of this operator that
> > need not be diagnosed under pedantic mode? If so, I'll propose this
>
> I'm doubtful of
On Mon, Feb 03, 2025 at 10:55:10AM +, Jonathan Wakely via Gcc wrote:
> On Mon, 3 Feb 2025 at 10:27, Marc Poulhiès wrote:
> >
> > I usually look at the queue a few times a day (working day)... So at least
> > in my case, I may not be very active during the weekends (even less so this
> > weeke
On Fri, Jan 31, 2025 at 11:24:33PM +0900, The Cuthour via Gcc wrote:
> > C++ requires constant expressions to be known during compilation, not
> > at link time.
>
> A constant that is not determined at compile-time is akin to
> constructor that is const but not constexpr. While it remains
> consta
On Thu, Jan 30, 2025 at 10:48:43AM +0100, Richard Biener via Gcc wrote:
> On Thu, Jan 30, 2025 at 10:01 AM Dmitry Antipov wrote:
> >
> > With (probably) -Wmaybe-uninitialized and/or -Wextra, shouldn't the
> > compiler emit
> > warning about possibly uninitialized 'y' passed to 'ddd()' in the exam
On Wed, Jan 15, 2025 at 08:58:50PM +, Jonathan Wakely wrote:
> It looks like there are only 24 uses of __int24 in the testsuite, so
> maybe just adding __extension__ to those places is the best solution.
Ah, ok.
Still, there should be one new test with -pedantic and without __extension__
to ve
On Wed, Jan 15, 2025 at 09:36:51PM +0100, Georg-Johann Lay via Gcc wrote:
> > This pedwarn is correct, so I'm not sure why it's a problem. If you
> > don't want warnings about non-standard extensions, don't use
> > -pedantic-errors.
>
> The point is that I don't pedwarn explicitly, that's how the
On Tue, Jan 07, 2025 at 07:19:34PM +0100, Thomas Koenig via Gcc wrote:
> Am 07.01.25 um 18:04 schrieb Andreas Schwab:
> > On Jan 07 2025, Thomas Koenig via Gcc wrote:
> >
> > > Side remark (which I will also address): https://gcc.gnu.org/bugs/ does
> > > not mention -freport-bug.
> >
> > But the
On Tue, Jan 07, 2025 at 05:46:48PM +0100, Thomas Koenig via Gcc wrote:
> Am 07.01.25 um 16:41 schrieb Thomas Koenig via Gcc:
> > Thanks for the explanation. I think it might be good to add a bit
> > of this to the docs. I will prepare a patch.
>
> Side remark (which I will also address): https://
On Tue, Jan 07, 2025 at 04:04:22PM +0100, Thomas Koenig wrote:
> Am 07.01.25 um 15:48 schrieb Jakub Jelinek:
> > On Tue, Jan 07, 2025 at 03:45:02PM +0100, Thomas Koenig via Gcc wrote:
> > > Would it be reasonable to dump a preprocessed file (if any) on an ICE,
> > > and
On Tue, Jan 07, 2025 at 03:45:02PM +0100, Thomas Koenig via Gcc wrote:
> when an ICE occurs somewhere when building a complex software package,
> it can be cumbersome for the user to obtain the preprocessed file
> that we ask people to submit to us.
>
> Would it be reasonable to dump a preprocesse
On Mon, Dec 02, 2024 at 11:17:08AM +, Prathamesh Kulkarni wrote:
> --- a/gcc/cfgloop.h
> +++ b/gcc/cfgloop.h
> @@ -233,6 +233,12 @@ public:
> flag_finite_loops or similar pragmas state. */
>unsigned finite_p : 1;
>
> + /* True if SIMD loop needs delayed lowering of artefacts like
On Sat, Nov 30, 2024 at 09:54:02AM +, Jonathan Wakely via Gcc wrote:
> On Sat, 30 Nov 2024, 09:01 David H. Lynch Jr. via Gcc,
> wrote:
>
> > Is it possible to build gcc 13 with gcc 14 ?
> >
>
> Yes
Note, there are some exceptions, I think e.g. Ada needs the same or older
major version of gn
On Thu, Nov 14, 2024 at 08:29:26AM +, Prathamesh Kulkarni wrote:
> + /* True if SIMD loop needs delayed lowering of artefacts like
> + safelen and length of omp simd arrays that depend on target's
> + max_vf. This is true for offloading, when max_vf is computed after
2 spaces after .,
On Mon, Nov 04, 2024 at 10:21:58AM +, Andrew Stubbs wrote:
> @@ -999,6 +1000,18 @@ omp_max_vf (void)
> && OPTION_SET_P (flag_tree_loop_vectorize)))
> return 1;
>
> + if (ENABLE_OFFLOADING && offload)
> +{
> + for (const char *c = getenv ("OFFLOAD_TARGET_NAMES"); c;)
> +
On Sat, Nov 02, 2024 at 03:53:34PM +, Prathamesh Kulkarni wrote:
> The attached patch adds a new bitfield needs_max_vf_lowering to loop, and
> sets that in expand_omp_simd for loops that need delayed lowering of
> safelen and omp simd arrays. The patch defines a new macro
> OMP_COMMON_MAX_VF (
Hi!
https://en.cppreference.com/w/c/compiler_support
has a table with compiler support for C23.
I've added #embed and [[unsequenced]]/[[reproducible]] in there
yesterday, but am wondering about the accuracy of the rest.
Given the switch to -std=gnu23 preparation, I wonder what is still
unimplemen
On Mon, Oct 07, 2024 at 03:14:22PM +, Qing Zhao wrote:
> > Consider the qsort case. My understanding was that the paper is making
> > typedef int (*cmpfn) (const void *, const void *);
> > qsort (NULL, 0, 1, (cmpfn) NULL);
> > valid (but is
> > qsort (NULL, 1, 0, (cmpfn) NULL);
> > still inval
On Fri, Oct 04, 2024 at 12:42:24AM +0200, Florian Weimer wrote:
> * Joseph Myers:
>
> > The real question is how to achieve optimal warnings in the absence of the
> > attribute. Should we have a variant of the nonnull attribute that warns
> > for NULL arguments but without optimizing based on t
On Thu, Sep 26, 2024 at 11:20:15PM +0200, Enrico via Gcc wrote:
> I am trying to understand how 'flag_pic' works.
> It is used extensively in TARGET_OPTION_OVERRIDE functions in the form 'if
> (flag_pic) ... '.
> The flags fPic and fpic have a default value of -1, so as far as I
> understand, if th
On Thu, Sep 12, 2024 at 06:09:53PM +0200, Jose E. Marchesi via Gcc wrote:
> - "noreturn" and jump tables run-time hints
>
> It has been expressed on the kernel side the desire of having the C compiler
> emit run-time hints marking functions that are not supposed to return and
> also to provi
On Fri, Aug 09, 2024 at 03:42:06PM +0200, Jakub Jelinek via Gcc wrote:
> On Fri, Aug 09, 2024 at 03:25:00PM +0200, Alejandro Colomar wrote:
> > The problem with that is that the error will still be enforced _after_
> > GCC would change the behavior of sizeof(aparam).
>
> I
On Fri, Aug 09, 2024 at 03:25:00PM +0200, Alejandro Colomar wrote:
> The problem with that is that the error will still be enforced _after_
> GCC would change the behavior of sizeof(aparam).
I don't think it should unless C2Y requires that.
> Admittedly, I could write configure checks to determin
On Fri, Aug 09, 2024 at 02:19:26PM +0200, Alejandro Colomar via Gcc wrote:
> On Thu, Aug 08, 2024 at 09:31:37AM GMT, Martin Uecker wrote:
> > Am Donnerstag, dem 08.08.2024 um 02:36 +0200 schrieb Alejandro Colomar:
> > > Hi Martin,
> > >
> > > Can we promote -Wno-sizeof-array-argument to a hard err
The GNU Compiler Collection version 14.2 has been released.
GCC 14.2 is a bug-fix release from the GCC 14 branch
containing important fixes for regressions and serious bugs in
GCC 14.1 with more than 102 bugs fixed since the previous release.
This release is available from the FTP servers listed
The second release candidate for GCC 14.2 is available from
https://gcc.gnu.org/pub/gcc/snapshots/14.2.0-RC-20240729/
ftp://gcc.gnu.org/pub/gcc/snapshots/14.2.0-RC-20240729/
and shortly its mirrors. It has been generated from git commit
r14-10521-gda7f0be91e2ae15.
I have so far bootstrapped a
The first release candidate for GCC 14.2 is available from
https://gcc.gnu.org/pub/gcc/snapshots/14.2.0-RC-20240723/
ftp://gcc.gnu.org/pub/gcc/snapshots/14.2.0-RC-20240723/
and shortly its mirrors. It has been generated from git commit
r14-10504-ga544898f6dd6a16.
I have so far bootstrapped an
On Sun, Jul 14, 2024 at 08:07:02PM +0800, LIU Hao via Gcc wrote:
> 在 2024-07-11 15:56, Jakub Jelinek via Gcc 写道:
> > Status
> > ==
> >
> > The gcc-14 branch is open for regression and documentation fixes.
> >
> > It's time to plan for a GCC 14.2 re
Status
==
The gcc-14 branch is open for regression and documentation fixes.
It's time to plan for a GCC 14.2 release which should follow
roughly two to three months after the .1 release. The plan is
to do a release candidate for GCC 14.2 on Tuesday, Jul 23rd
with the release following a week
On Tue, Jul 09, 2024 at 11:07:59AM +0200, Alejandro Colomar wrote:
> > > restrict, as of what -Wrestrict warns about, seems a reasonable
> > > thing.
> > >
> > > How about a [[gnu::restrict()]] attribute, similar to
> > > [[gnu::access()]],
> > > which is simpler than the qualifier? Since restric
On Fri, Jul 05, 2024 at 09:38:21PM +0800, Xi Ruoyao via Gcc wrote:
> On Fri, 2024-07-05 at 15:03 +0200, Alejandro Colomar wrote:
> > ISO C specifies these APIs as accepting a restricted pointer in their
> > first parameter:
> >
> > $ stdc c99 strtol
> > long int strtol(const char *restrict nptr, c
On Tue, Jul 02, 2024 at 12:54:09PM -0400, David Malcolm via Gcc wrote:
> Back in 2007 glibc gained some logic to implement "error" and
> "error_at_line" by splitting into zero and non-zero cases, with the
> nonzero case calling a "noreturn" function [1].
>
> This doesn't seem to work. I tested bac
The GNU Compiler Collection version 12.4 has been released.
GCC 12.4 is a bug-fix release from the GCC 12 branch
containing important fixes for regressions and serious bugs in
GCC 12.3 with more than 84 bugs fixed since the previous release.
This release is available from the FTP servers listed h
On Mon, Jun 17, 2024 at 03:53:41PM +0200, Martin Uecker wrote:
> > If c_update_type_canonical is only ever called for the main variants of the
> > type and they always have !TYPE_QUALS (t), then yes.
> > But if we rely on that, perhaps we should gcc_checking_assert that.
> > So
> > gcc_checking_a
On Mon, Jun 17, 2024 at 03:33:05PM +0200, Martin Uecker wrote:
> > I've done that and that was because build_qualified_type uses that
> > predicate, where qualified types created by build_qualified_type have
> > as TYPE_CANONICAL the qualified type of the main variant of the canonical
> > type, whi
On Mon, Jun 17, 2024 at 02:42:05PM +0200, Richard Biener wrote:
> > > > I am trying to understand what check_qualified_type
> > > > does exactly. The direct comparison of TYPE_NAMES seems incorrect
> > > > for C and its use is c_update_type_canonical then causes
> > > > PR114930 and PR115502. In t
On Wed, Jun 12, 2024 at 04:53:38PM +0200, Mikael Morin wrote:
> > Perhaps you could create a mirror version of the repo and do some
> > experiments locally on that to identify where the bottle-neck is coming
> > from?
> >
> Not sure where to start for that.Are the hooks published somewhere?
Yes
Hi!
Yesterday the gcc git repository was locked for 3 hours
locked by user mikael at 2024-06-11 13:27:44.301067 (pid = 974167)
78:06 python hooks/update.py refs/users/mikael/tags/fortran-dev_merges/r10-1545
c2f9fe1d8111b9671bf0aa8362446516fd942f1d
process
On Tue, Jun 04, 2024 at 07:43:40PM +0200, Michael Matz via Gcc wrote:
> (Well, and without reverse-recognition of isfinite-like idioms in the
> sources. That's orthogonal as well.)
Why? If isfinite is better done by a libcall, why isn't isfinite-like
idiom also better done as a libcall?
On Tue, May 28, 2024 at 07:35:43AM -0700, Paul Eggert wrote:
> On 2024-05-28 01:20, Jonathan Wakely wrote:
> > I am not aware of any distro ever changing the default -std setting for g++
> > or clang++. Are you attempting to solve a non-problem, but introducing new
> > ones?
>
> If it's a non-prob
On Mon, May 27, 2024 at 12:04:40PM -0700, Paul Eggert wrote:
> On 2024-05-27 03:35, Florian Weimer wrote:
> > Does this turn on experimental language modes by default? That's
> > probably not what we want.
>
> What do C++ developers want these days? Autoconf should have a reasonable
> default, an
Status
==
The gcc-12 branch is open for regression and documentation fixes.
It's time to do the annual release from the branch, GCC 12.4, and
the plan is to do a release candidate on June 13th followed
by the actual release a week after that.
Please look through bugzilla and see which of you
The GNU Compiler Collection version 13.3 has been released.
GCC 13.3 is a bug-fix release from the GCC 13 branch
containing important fixes for regressions and seriou
On Tue, May 14, 2024 at 06:31:19PM +0200, Jakub Jelinek via Gcc wrote:
> If all goes well, we'd like to release 13.3 on Thursday, May 21st.
Tuesday, May 21st. Sorry for the pasto.
Jakub
The first release candidate for GCC 13.3 is available from
https://gcc.gnu.org/pub/gcc/snapshots/13.3.0-RC-20240514/
ftp://gcc.gnu.org/pub/gcc/snapshots/13.3.0-RC-20240514/
and shortly its mirrors. It has been generated from git commit
r13-8774-g1db45e83021a8a.
I have so far bootstrapped and
On Tue, May 07, 2024 at 04:40:55PM -0400, James K. Lowden wrote:
> /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.32' not
> found (required by build-O2/gcc/cobol1
The cc1/cc1plus/f951/... binaries are normally linked with
-static-libstdc++ -static-libgcc in second and later stages (fir
On Wed, May 08, 2024 at 01:15:21PM +0200, Matthias Urlichs via Gcc wrote:
> On 08.05.24 11:50, Richard Biener wrote:
> > > "With the |-fpermissive| option, programs can use C99 inlining semantics
> > > and features that were removed from C99"
> > >
> > > Umm, what? this sentence doesn't make sense
The second release candidate for GCC 14.1 is available from
https://gcc.gnu.org/pub/gcc/snapshots/14.1.0-RC-20240503/
ftp://gcc.gnu.org/pub/gcc/snapshots/14.1.0-RC-20240503/
and shortly its mirrors. It has been generated from git commit
r14-10165-g3b4d6b6ecd79df790.
The https://gcc.gnu.org/PR
On Tue, Apr 30, 2024 at 03:09:51PM -0400, Jason Merrill via Gcc wrote:
> On Fri, Apr 26, 2024 at 5:44 AM Aldy Hernandez via Gcc
> wrote:
> >
> > In implementing prange (pointer ranges), I have found a 1.74% slowdown
> > in VRP, even without any code path actually using the code. I have
> > track
Status
==
The gcc-13 branch is open for regression and documentation fixes.
It's time to do the annual release from the branch, GCC 13.3, and
the plan is to do a release candidate in two weeks, around May 14th,
following with the actual release around May 21st.
Please look through bugzilla a
The first release candidate for GCC 14.1 is available from
https://gcc.gnu.org/pub/gcc/snapshots/14.1.0-RC-20240430/
ftp://gcc.gnu.org/pub/gcc/snapshots/14.1.0-RC-20240430/
and shortly its mirrors. It has been generated from git commit
r14-10154-g7a00c459cbb913a.
I have so far bootstrapped an
Status
==
The trunk has branched for the GCC 14 release and is now open
again for general development, stage 1. Please consider not
disrupting it too much during the RC phase of GCC 14 so it
is possible to test important fixes for 14.1 on it.
Quality Data
Priority #
Status
==
On Thu, Apr 25, 2024 at 07:16:31PM +0800, LIU Hao via Gcc wrote:
> --- a/gcc/rust/parse/rust-parse.cc
> +++ b/gcc/rust/parse/rust-parse.cc
> @@ -89,7 +89,7 @@ extract_module_path (const AST::AttrVec &inner_attrs,
>// Source: rustc compiler
>//
> (https://github.com/rust-lang/rust/blob/9863
On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon wrote:
> Any concerns/objections?
I'm all for it, in fact I've been sending it like that myself for years
even when the policy said not to. In most cases, the diff for the
regenerated files is very small and it helps even in patch review t
On Wed, Feb 07, 2024 at 11:02:51PM +0800, Paul Edwards via Gcc wrote:
> I am using a slightly modified gcc 3.2.3 for x86_64 and for this code:
Don't, gcc 3.2.3 is not supported for more than 20 years already.
> int fff(char *x)
> {
> return (x[-1]);
> }
>
>
> It is generating:
>
> .globl fff
>
Hi!
Seems libgcc mostly uses triplets after GCC_ in symbol version names in the
last few years (looking at GCC 5+):
find -name \*.ver -o -name \*.ver.in | xargs grep
'GCC_[156789][0-9]*\.[0-9]*\.[0-9]* '
./config/i386/libgcc-glibc.ver:%inherit GCC_12.0.0 GCC_7.0.0
./config/i386/libgcc-glibc.ver:
On Thu, Jan 18, 2024 at 02:36:02PM +0200, Mohamed Atef via Gcc wrote:
> I'm sorry for not getting back to you this long time. As I mentioned
> The military service here is a must. Thank God I finished my military
> service.
> I am still interested in working on OMPD. Are there any plans for OMP
On Wed, Jan 10, 2024 at 02:47:08PM -0600, Robert Dubner wrote:
> Here's the thing: when I run valgrind on the compilation -- not on the
> executable, but on the compiler with the COBOL front end -- I am getting a
> bunch of errors that look like variations of this:
>
> ==1232157== Command: /hom
On Sun, Jan 07, 2024 at 03:12:32PM -0700, Jeff Law via Gcc wrote:
> On 1/7/24 08:48, waffl3x via Gcc wrote:
> > https://gcc.gnu.org/develop.html#timeline
> > The date for stage 4 is listed as the 8th on here, is that date final?
> > There is at least 1 patch pending (mine) that is complete but Jaso
On Fri, Dec 01, 2023 at 01:03:01PM +0100, Jan Hubicka via Gcc wrote:
> > On Dez 01 2023, Richard Biener via Gcc wrote:
> >
> > > Hmm, so why's it then referenced and not "GCed"?
> >
> > This has nothing to do with garbage collection. It's just the way
> > libgcc avoids having too many source fil
On Tue, Nov 14, 2023 at 09:30:21AM +0100, Rainer Orth wrote:
> For the last couple of days (since 2023-11-09), gcc/DATESTAMP hasn't
> been updated.
I'll have a look. Probably some bad commit again.
Jakub
On Mon, Nov 06, 2023 at 05:38:40PM +0100, Florian Weimer via Gcc wrote:
> Emacs has a very useful facility. You press “C-x 4 a” in a place where
> you make changes, and the editor automatically opens the right ChangeLog
> file and adds a draft entry to it, like this:
>
> 2023-11-06 Florian Weime
On Thu, Nov 02, 2023 at 04:44:30PM +, Joseph Myers wrote:
> On Thu, 2 Nov 2023, Richard Biener via Gcc wrote:
>
> > Note the semantic of __builtin_clz is _not_ altered by
> > CLZ_DEFINED_VALUE_AT_ZERO, the behavior
> > of __builtin_clz (x) is that is has undefined result for x == 0.
>
> Note
On Tue, Oct 10, 2023 at 12:30:52PM -0400, Jason Merrill via Gcc wrote:
> On Tue, Oct 10, 2023 at 7:30 AM Florian Weimer via Gcc
> wrote:
>
> > Are these code fragments valid C89 code?
> >
> > int i1 = 1;
> > char *p1 = i;
> >
> > char c;
> > char *p2 = &c;
> > int i2 = p2;
> >
> > Or ca
On Thu, Sep 28, 2023 at 09:03:39PM +0200, Toon Moene wrote:
> > > The full question of "lto-ing" run time libraries is more
> > > complicated than just "whether it works" as those who attended the
> > > BoF will recall.
> >
> > I didn't attend the Cauldron (but that discussion would have been
> >
On Thu, Sep 28, 2023 at 09:29:02AM +0200, Tobias Burnus wrote:
> the following works for me. I have only tried a normal build (where it
> does silence the same warning) and not an LTO build and I just believed
> the comment - see attached patch. Comments?
>
> On 28.09.23 08:25, Richard Biener via
On Tue, Sep 26, 2023 at 10:28:34AM +0200, Florian Weimer via Gcc wrote:
> My understanding of the consensus goes as follows:
>
> * We want to make some changes in this area for GCC 14.
> * We should do the same thing that Clang does: default to the relevant
> -Werror= options.
I think it doesn'
1 - 100 of 1364 matches
Mail list logo
