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 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 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 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 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 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 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 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 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, 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 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 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 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 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 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 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
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 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
>
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 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
Status
==
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 #
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 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
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
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 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
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
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 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 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
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
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
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 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?
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 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
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 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 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
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 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
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 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
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 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
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
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 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
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
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 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, 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 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
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 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 (
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 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 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 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 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 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 point the user to it? The e
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 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 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 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 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 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 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 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
301 - 372 of 372 matches
Mail list logo
