Re: Defining __uint24

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

Re: Defining __uint24

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

Re: RFC: Leave preprocessed files on ICE

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

Re: RFC: Leave preprocessed files on ICE

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://

Re: RFC: Leave preprocessed files on ICE

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

Re: RFC: Leave preprocessed files on ICE

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

Re: [RFC] Enabling SVE with offloading to nvptx

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

Re: building gcc 14 with gcc 14 ?

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

Re: [RFC] Enabling SVE with offloading to nvptx

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 .,

Re: [RFC] Enabling SVE with offloading to nvptx

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;) > +

Re: [RFC] Enabling SVE with offloading to nvptx

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 (

C23 status on cppreference

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

Re: Handling C2Y zero-length operations on null pointers

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

Re: Handling C2Y zero-length operations on null pointers

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

Re: Meaning of flag_pic

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

Re: [CAULDRON] Topics for the Toolchain and Linux kernel BoF

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

Re: Promote -Wno-sizeof-array-argument to an error

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

Re: Promote -Wno-sizeof-array-argument to an error

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

Re: Promote -Wno-sizeof-array-argument to an error

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

GCC 14.2 Released

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

Second GCC 14.2 Release Candidate available from gcc.gnu.org

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

GCC 14.2 Release Candidate available from gcc.gnu.org

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

Re: GCC 14.1.1 Status Report (2024-07-11)

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

GCC 14.1.1 Status Report (2024-07-11)

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

Re: WG14 paper for removing restrict from nptr in strtol(3)

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

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

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

Re: Bad interaction between gcc and glibc's handling of GNU extension [GCC PR 115724]

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

GCC 12.4 Released

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

Re: check_qualified_type

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

Re: check_qualified_type

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

Re: check_qualified_type

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

Re: gcc git locked out for hours second day in a row

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

gcc git locked out for hours second day in a row

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

Re: How to avoid some built-in expansions in gcc?

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?

Re: configure adds -std=gnu++11 to CXX variable

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

Re: configure adds -std=gnu++11 to CXX variable

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

GCC 12.3.1 Status Report (2024-05-24)

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

GCC 13.3 Released

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

Re: GCC 13.3 Release Candidate available from gcc.gnu.org

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

GCC 13.3 Release Candidate available from gcc.gnu.org

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

Re: FE C++ requirement

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

Re: Error in gcc 14 porting document

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

Second GCC 14.1 Release Candidate available from gcc.gnu.org

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

Re: 1.76% performance loss in VRP due to inlining

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

GCC 13.2.1 Status Report (2024-04-30)

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

GCC 14.1 Release Candidate available from gcc.gnu.org

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

GCC 15.0.0 Status Report (2024-04-26)

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 #

GCC 14.0.1 Status Report (2023-04-26)

Status ==

Re: [PATCH] Fix rust on *-w64-mingw32

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

Re: Patches submission policy change

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

Re: gcc 3.2.3 x64 negative indexes

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 >

(in)consistency of libgcc symbol versions

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:

Re: Regarding OMPD

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

Re: I am causing valgrind errors...

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

Re: Stage 4 date

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

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

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

Re: gcc/DATESTAMP not updated since 20231109

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

Re: Emacs ChangeLog generation and commit messages

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

Re: Suspecting a wrong behavior in the value range propagation analysis for __builtin_clz

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

Re: C89 question: Do we need to accept -Wint-conversion warnings

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

Re: Test with an lto-build of libgfortran.

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 > >

Re: Test with an lto-build of libgfortran.

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

Re: Report from the additional type errors for GCC 14 BoF at Cauldron

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'

Re: Concerns regarding the -ffp-contract=fast default

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

Re: CLZ when CLZ_DEFINED_VALUE_AT_ZERO is false

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

Re: Analyzer failure due to missing header

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

Re: Testsuite issue and warning about floating-point conversion

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

Re: Testsuite issue and warning about floating-point conversion

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

Re: GCC support for extensions from later standards

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

GCC 13.2.1 Status Report (2023-07-27)

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 --

GCC 13.1.1 Status Report (2023-07-20)

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

GCC 13.2 Release Candidate available from gcc.gnu.org

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

Re: Ju-Zhe Zhong and Robin Dapp as RISC-V reviewers

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

Re: Hundreds of gcc.dg/guality failures on both 14 and 13.1 branches

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

Re: Different ASM for ReLU function between GCC11 and GCC12

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

Re: Different ASM for ReLU function between GCC11 and GCC12

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

Re: Different ASM for ReLU function between GCC11 and GCC12

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

Re: C/C++ extension for SIMD proposal

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

Re: GCC 11.4 documentation 404's

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.

GCC 11.4 Released

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

Re: Another epic optimiser failure

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.

Re: Will GCC eventually support SSE2 or SSE4.1?

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

Re: Will GCC eventually support SSE2 or SSE4.1?

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*

Re: Will GCC eventually support SSE2 or SSE4.1?

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

GCC 11.4 Release Candidate available from gcc.gnu.org

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

Re: More C type errors by default for GCC 14

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

GCC 11.3.1 Status Report (2023-05-15)

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

Re: More C type errors by default for GCC 14

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

Re: More C type errors by default for GCC 14

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

Re: std::format not listed on the C++ Standards support page

On Wed, May 10, 2023 at 06:45:55PM +0200, Jakub Jelinek via Gcc wrote: > On Wed, May 10, 2023 at 10:38:02AM -0600, C. Heide via Gcc wrote: > > Hello, just a note that support for std::format (P0645R10) does > > not seem to be listed anywhere on the current C++ Standards > >

Re: std::format not listed on the C++ Standards support page

On Wed, May 10, 2023 at 10:38:02AM -0600, C. Heide via Gcc wrote: > Hello, just a note that support for std::format (P0645R10) does > not seem to be listed anywhere on the current C++ Standards > Support page (https://gcc.gnu.org/projects/cxx-status.html). > > I was trying to figure out if it was

Re: More C type errors by default for GCC 14

On Wed, May 10, 2023 at 11:36:10AM -0500, Joel Sherrill wrote: > On Wed, May 10, 2023 at 10:14 AM Jakub Jelinek wrote: > > > On Wed, May 10, 2023 at 10:10:37AM -0500, Joel Sherrill wrote: > > > > > What practices might the GCC community recommend to a project > &

Re: More C type errors by default for GCC 14

On Wed, May 10, 2023 at 06:30:40PM +0300, Eli Zaretskii wrote: > > Date: Wed, 10 May 2023 16:22:26 +0200 > > From: Jakub Jelinek > > Cc: Gabriel Ravier , jwakely@gmail.com, > > fwei...@redhat.com, gcc@gcc.gnu.org, ar...@aarsen.me > > > > > >

Re: More C type errors by default for GCC 14

On Wed, May 10, 2023 at 10:10:37AM -0500, Joel Sherrill wrote: > > > What practices might the GCC community recommend to a project > > > wanting to discover the issues uncovered and slowly address them? I > > > > -Werror=implicit-int > > -Werror=implicit-function-declaration > > -Werror=int-convers

Re: More C type errors by default for GCC 14

On Wed, May 10, 2023 at 05:14:43PM +0300, Eli Zaretskii wrote: > > Date: Wed, 10 May 2023 14:41:27 +0200 > > Cc: jwakely@gmail.com, fwei...@redhat.com, gcc@gcc.gnu.org, > > ar...@aarsen.me > > From: Gabriel Ravier > > > > >>> Because GCC is capable of compiling it. > > >> That is not a good

Re: More C type errors by default for GCC 14

On Wed, May 10, 2023 at 02:30:07PM +0300, Eli Zaretskii wrote: > > From: Jonathan Wakely > > Date: Wed, 10 May 2023 09:04:12 +0100 > > Cc: Florian Weimer , "gcc@gcc.gnu.org" > > , > > Jakub Jelinek , Arsen Arsenović > > > > void foo(int

Re: More C type errors by default for GCC 14

On Tue, May 09, 2023 at 10:04:06PM +0300, Eli Zaretskii via Gcc wrote: > > From: Jonathan Wakely > > Date: Tue, 9 May 2023 18:15:59 +0100 > > Cc: Arsen Arsenović , gcc@gcc.gnu.org > > > > On Tue, 9 May 2023 at 17:56, Eli Zaretskii wrote: > > > > > > No one has yet explained why a warning about th

Re: End of subscription

On Tue, May 09, 2023 at 09:44:08PM +0530, Ruchit Raushan via Gcc wrote: > Don't want to receive further emails. Each mail on the mailing list tells that in the headers: List-Unsubscribe: ,

Re: More C type errors by default for GCC 14

On Tue, May 09, 2023 at 05:16:19PM +0200, Richard Biener via Gcc wrote: > > > > Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc : > > > > TL;DR: This message is about turning implicit-int, > > implicit-function-declaration, and possibly int-conversion into errors > > for GCC 14. > > I su

Re: GCC 12.3 Release Candidate available from gcc.gnu.org

On Thu, May 04, 2023 at 10:31:21AM -0400, Jason Merrill via Gcc wrote: > My patch for 106890 caused 109666, so I'd like to revert the 106890 patch > (r12-9441-g94569d91bd4c60) for 12.3. Ok. Guess we should do RC2 either tonight or tomorrow then, there are I think 2 other commits that could get som

  1   2   3   4   5   6   7   8   9   10   >