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'
On Mon, Sep 18, 2023 at 01:26:54PM +0200, Martin Uecker wrote:
> > I think that changing the default to =standard without -ffast-math is
> > reasonable.
> > IIRC the standard allows such default if it's indicated, so it doesn't
> > require
> > =off anywhere.
>
> The C standard requires a pragma t
On Fri, Sep 01, 2023 at 10:13:40AM +0200, Richard Biener via Gcc wrote:
> The value of .CLZ (0) is undefined then. I belive your analysis is correct in
> that both 63 - _35 might overflow and that dom3 (thus ranger) mis-computes
> the range for _35. I wonder why we don't elide _36 ? _31 : 1 with
On Wed, Aug 30, 2023 at 11:10:57AM +0200, FX Coudert via Gcc wrote:
> std::max and std::min, introduced by d99d73c77d1e and 2bad0eeb5573, are not
> available because is not included. The following patch fixes the
> build for me:
>
> diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/regio
On Sat, Aug 19, 2023 at 11:58:31AM +0200, Jakub Jelinek via Gcc wrote:
> well. So, if aarch64-darwin wants 64-bit long double, the question is if
> it should have __float128 support and q suffix support at all. If it
> should, then it needs to initialize float128t_type_node to a dist
On Sat, Aug 19, 2023 at 10:25:50AM +0100, Jonathan Wakely wrote:
> On Fri, 18 Aug 2023 at 20:08, FX Coudert via Gcc wrote:
> >
> > Hello,
> >
> > On the WIP aarch64-darwin port of GCC
> > (https://github.com/iains/gcc-darwin-arm64), there are some C++ testsuite
> > failures which are due to the
On Mon, Aug 07, 2023 at 08:03:05PM -0700, Nikolas Klauser wrote:
> Thanks for the answers!
>
> There are a few really interesting extensions that I would like to use:
>
> - inline variables
> - variable templates
> - `if constexpr`
> - fold expressions
> - conditional explicit
> - static operator
Status
==
GCC 13.2 has been released, the releases/gcc-13 branch is open again
for regression and documentation bugfixing. GCC 13.3 can be expected
in spring next year unless something serious changes the plans.
Quality Data
Priority # Change from last report
--
Status
==
The GCC 13 branch is frozen for the release of GCC 13.2 with
a first release candidate published. All changes require
release manager approval.
Quality Data
Priority # Change from last report
--- ---
P10
The first release candidate for GCC 13.2 is available from
https://gcc.gnu.org/pub/gcc/snapshots/13.2.0-RC-20230720/
ftp://gcc.gnu.org/pub/gcc/snapshots/13.2.0-RC-20230720/
and shortly its mirrors. It has been generated from git commit
r13-7597-g9aac37ab8a7b91.
I have so far bootstrapped and
On Tue, Jul 18, 2023 at 09:25:44AM +0800, juzhe.zh...@rivai.ai wrote:
> Thanks Jeff.
> I will wait after Robin updated his MAINTAINERS (since I don't known what
> information I need put in).
Add
riscv port Juzhe Zhong
line to the Reviewers section of MAINTAINERS file (alphabetically be
On Sat, Jul 15, 2023 at 10:58:40PM +0200, Martin Jambor wrote:
> Hi,
>
> On Sat, Jul 15 2023, FX Coudert via Gcc wrote:
> > Hi,
> >
> > I am finding it very hard to reliably compare test results and regressions
> > with the very large number of gcc.dg/guality test failures that are
> > apparentl
On Tue, Jun 20, 2023 at 03:03:19PM +, Michael Matz via Gcc wrote:
> Hello,
>
> On Tue, 20 Jun 2023, Jakub Jelinek via Gcc wrote:
>
> > ce1 pass results in emit_conditional_move with
> > (gt (reg/v:SF 83 [ x ]) (reg:SF 84)), (reg/v:SF 83 [ x ]), (reg:SF 84)
> > o
On Tue, Jun 20, 2023 at 10:15:37AM +0200, Richard Biener wrote:
> On Mon, Jun 19, 2023 at 9:45 PM Jakub Jelinek via Gcc wrote:
> >
> > On Mon, Jun 19, 2023 at 09:10:53PM +0200, André Günther via Gcc wrote:
> > > I noticed that a simple function like
> > > auto rel
On Mon, Jun 19, 2023 at 09:10:53PM +0200, André Günther via Gcc wrote:
> I noticed that a simple function like
> auto relu( float x ) {
> return x > 0.f ? x : 0.f;
> }
> compiles to different ASM using GCC11 (or lower) and GCC12 (or higher). On
> -O3 -mavx2 the former compiles above function to
On Sat, Jun 10, 2023 at 07:51:10PM +0200, Jakub Juszczakiewicz via Gcc wrote:
> Hi all,
>
> I don't know is here right place for sharing ideas, but I don't have
> idea, where I can send it.
> I have simple idea. When I turned on OpenMP, for parallelly execute simple
> for it's enough when I ad
On Mon, May 29, 2023 at 02:50:06PM +, Felix LeClair via Gcc wrote:
> Hi everyone,
>
> Quick note that it seems like the freshly updated docs for GCC 11.4 seem to
> be hitting a 404 error when attempting to access them.
>
> Links that 404 for me:
>
> https://gcc.gnu.org/onlinedocs/gcc-11.
The GNU Compiler Collection version 11.4 has been released.
GCC 11.4 is the first bug-fix release from the GCC 11 branch containing
important fixes for regressions and serious bugs in GCC 11.3 with more
than 110 bugs fixed since the previous release.
This release is available from the WWW servers
On Sat, May 27, 2023 at 11:04:11PM +0200, Stefan Kanthak wrote:
> OUCH: popcnt writes the WHOLE result register, there is ABSOLUTELY
> no need to clear it beforehand nor to clear the higher 24 bits
> afterwards!
Except that there is. See https://gcc.gnu.org/PR62011 for details.
On Fri, May 26, 2023 at 03:07:59PM +0100, Jonathan Wakely wrote:
> > These points are obvious.
> > NOT obvious is but that -m -march= does not clear any
> > not supported in , i.e the last one does NOT win here.
>
> The last -march option selects the base set of instructions. The -mISA
> options
On Fri, May 26, 2023 at 02:19:54PM +0200, Stefan Kanthak wrote:
> > I find it very SURPRISING that you're only just learning the basics of
> > how to use gcc NOW, after YELLING about all the OUCH.
>
> I'm NOT surprised that you don't grok it!
>
> gcc -msse4.1 -m32 -march=core2 ...
>
> Which -m*
On Fri, May 26, 2023 at 10:59:03AM +0200, Stefan Kanthak wrote:
> 3) SSE4.1 is supported since Core2, but -march=core2 fails to enable it.
>That's bad, REALITY CHECK, please!
You're wrong.
SSE4.1 first appeared in the 45nm versions of Core2, the 65nm versions
didn't have it.
The supported CPU
The first release candidate for GCC 11.4 is available from
https://gcc.gnu.org/pub/gcc/snapshots/11.4.0-RC-20230522/
ftp://gcc.gnu.org/pub/gcc/snapshots/11.4.0-RC-20230522/
and shortly its mirrors. It has been generated from git commit
r11-10806-gfcf62b96ec9ae3.
I have so far bootstrapped and
On Tue, May 16, 2023 at 01:39:26PM +0300, Alexander Monakov wrote:
>
> On Tue, 16 May 2023, Florian Weimer wrote:
>
> > > (FWIW: no, this should not be an error, a warning is fine, and I actually
> > > think the current state of it not being in Wall is the right thing as
> > > well)
>
> (this
Status
==
The gcc-11 branch is open for regression and documentation fixes.
It's time to do the annual release from the branch, GCC 12.4.
I'd like to make the first release candidate on Monday, May 22nd,
and a release one week later if all goes well.
Please look through bugzilla and see whic
On Fri, May 12, 2023 at 11:33:01AM +0200, Martin Jambor wrote:
> > One fairly big GCC-internal task is to clear up the C test suite so that
> > it passes with the new compiler defaults. I already have an offer of
> > help for that, so I think we can complete this work in a reasonable time
> > fram
On Fri, May 12, 2023 at 10:53:28AM +0300, Eli Zaretskii via Gcc wrote:
> > From: Arsen Arsenović
> > Cc: luang...@yahoo.com, jwakely@gmail.com, gcc@gcc.gnu.org
> > Date: Thu, 11 May 2023 21:25:53 +0200
> >
> > >> This seems like a good route to me - it facilitates both veterans
> > >> maintai
1 - 100 of 1338 matches
Mail list logo
