Re: [wwwdocs] Porting-to-14: Mention new pragma GCC Target behavior

On Thu, 2 May 2024, Martin Jambor wrote: > Thanks for your suggestions, this is what I am going to commit in a > moment. Thanks! > diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html > > +Pragma GCC target now affects preprocessor > symbols A small detail I missed:

[pushed] wwwdocs: gcc-14: Close as such, not

Pushed. Gerald --- htdocs/gcc-14/porting_to.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html index a20d82c2..13772080 100644 --- a/htdocs/gcc-14/porting_to.html +++ b/htdocs/gcc-14/porting_to.html @@ -514,7

Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls

On Thu, May 2, 2024 at 12:23 PM Björn Schäpers wrote: > > Am 28.04.2024 um 20:16 schrieb Ian Lance Taylor: > > > > Which of your other patches are still relevant? Thanks. > > > only this one. Thanks. Committed. Ian

Re: [PATCH 3/3] Add parentheses around DECL_INIT for .original [PR23872]

On Fri, May 3, 2024 at 4:41 AM Richard Biener wrote: > > On Thu, May 2, 2024 at 11:40 PM Andrew Pinski > wrote: > > > > When we have : > > `void f (int y, int z) { int x = ( z++,y); }` > > > > This would have printed the decl's initializer without > > parentheses which can confusion if you

Re: [PATCH 2/3] Improve DECL_EXPR printing in .original [PR23872]

On Fri, May 3, 2024 at 4:36 AM Richard Biener wrote: > > On Thu, May 2, 2024 at 11:40 PM Andrew Pinski > wrote: > > > > Right now we don't print that a DECL_EXPR and we get > > basically double output of the decls and it looks confusing. > > This fixes that. > > for the simple example: > >

[PATCH, obvious] Fix for ICE in tree-nested.cc

I'm planning to push the attached patch to mainline in a couple days, unless someone disputes that it's "obvious" or has some other objection. I think it qualifies because the code immediately following the loop with the bad initializer is already conditionalized on GIMPLE_OMP_TARGET in the

Re: [PATCH v2 6/6] bpf,btf: enable BTF pruning by default for BPF

On 5/2/24 10:11, David Faust wrote: This patch enables -fprune-btf by default in the BPF backend when generating BTF information, and fixes BPF CO-RE generation when using -fprune-btf. When generating BPF CO-RE information, we must ensure that types used in CO-RE relocations always have

Re: [PATCH v2 5/6] btf: add -fprune-btf option

On 5/2/24 10:11, David Faust wrote: This patch adds a new option, -fprune-btf, to control BTF debug info generation. As the name implies, this option enables a kind of "pruning" of the BTF information before it is emitted. When enabled, rather than emitting all type information translated from

Re: [PATCH v2 4/6] btf: refactor and simplify implementation

On 5/2/24 10:11, David Faust wrote: This patch heavily refactors btfout.cc to take advantage of the structural changes in the prior commits. Now that inter-type references are internally stored as simply pointers, all the painful, brittle, confusing infrastructure that was used in the process

Re: [PATCH v2 3/6] ctf: use pointers instead of IDs internally

On 5/2/24 10:11, David Faust wrote: This patch replaces all inter-type references in the ctfc internal data structures with pointers, rather than the references-by-ID which were used previously. A couple of small updates in the BPF backend are included to make it compatible with the change.

Re: [PATCH v2 1/6] ctf, btf: restructure CTF/BTF emission

On 5/2/24 10:11, David Faust wrote: This commit makes some structural changes to the CTF/BTF debug info emission. In particular: a) CTF is new always fully generated and emitted before any BTF-related procedures are run. This means that BTF-related functions can change, even

[PATCH v21 20/23] c++: Implement __is_invocable built-in trait

Fixed datum reference problem. Ok for trunk? -- >8 -- This patch implements built-in trait for std::is_invocable. gcc/cp/ChangeLog: * cp-trait.def: Define __is_invocable. * constraint.cc (diagnose_trait_expr): Handle CPTK_IS_INVOCABLE. * semantics.cc

Re: [PATCH] c++: 'typename T::X' vs 'struct T::X' lookup [PR109420]

On Fri, May 3, 2024 at 8:08 AM Patrick Palka wrote: > > Hey Andrew, > > On Wed, 5 Apr 2023, Andrew Pinski wrote: > > > On Wed, Apr 5, 2023 at 10:32 AM Patrick Palka via Gcc-patches > > wrote: > > > > > > On Wed, 5 Apr 2023, Patrick Palka wrote: > > > > > > > r13-6098-g46711ff8e60d64 made

Re: [PATCH v20 23/26] c++: Implement __is_invocable built-in trait

On Fri, May 3, 2024 at 12:38 PM Jason Merrill wrote: > > On 5/2/24 23:25, Ken Matsui wrote: > > Addressed Jason's review comments. Ok for trunk? > > > > -- >8 -- > > > > This patch implements built-in trait for std::is_invocable. > > > > gcc/cp/ChangeLog: > > > > * cp-trait.def: Define

RE: [PATCH] DCE __cxa_atexit calls where the function is pure/const [PR19661]

> -Original Message- > From: Jeff Law > Sent: Friday, May 3, 2024 7:53 AM > To: Andrew Pinski (QUIC) ; gcc- > patc...@gcc.gnu.org > Subject: Re: [PATCH] DCE __cxa_atexit calls where the function is pure/const > [PR19661] > > > > On 5/2/24 3:56 PM, Andrew Pinski wrote: > > In C++

[pushed] c++: initializer_list and EH [PR114935]

Tested x86_64-pc-linux-gnu, applying to trunk and 14. -- 8< -- When we initialize an array of a type with a non-trivial destructor, such as the backing array for the initializer_list, we have a cleanup to destroy any constructed elements if a later constructor throws. When the array being

[PATCH] AARCH64: Add Qualcomnm oryon-1 core

This patch adds Qualcomm's new oryon-1 core; this is enough to recongize the core and later on will add the tuning structure. gcc/ChangeLog: * config/aarch64/aarch64-cores.def (oryon-1): New entry. * config/aarch64/aarch64-tune.md: Regenerate. * doc/invoke.texi (AArch64

Re: [PATCH v20 23/26] c++: Implement __is_invocable built-in trait

On 5/2/24 23:25, Ken Matsui wrote: Addressed Jason's review comments. Ok for trunk? -- >8 -- This patch implements built-in trait for std::is_invocable. gcc/cp/ChangeLog: * cp-trait.def: Define __is_invocable. * constraint.cc (diagnose_trait_expr): Handle CPTK_IS_INVOCABLE.

[PATCH] sra: Do not leave work for DSE (that it can sometimes not perform)

Hi, when looking again at the g++.dg/tree-ssa/pr109849.C testcase we discovered that it generates terrible store-to-load forwarding stalls because SRA was leaving behind aggregate loads but all the stores were by scalar parts and DSE failed to remove the useless load. SRA has all the knowledge

Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types

On Fri, May 03, 2024 at 09:11:20PM +0200, Martin Uecker wrote: > > TYPE_CANONICAL as used by the middle-end cannot express this but > > Hm. so how does it work now for arrays? Do you have a testcase which doesn't work correctly with the arrays? E.g. same_type_for_tbaa has type1 =

Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types

Am Freitag, dem 03.05.2024 um 20:48 +0200 schrieb Richard Biener: > > > Am 03.05.2024 um 20:37 schrieb Martin Uecker : > > > > Am Freitag, dem 03.05.2024 um 20:18 +0200 schrieb Jakub Jelinek: > > > > On Fri, May 03, 2024 at 08:04:18PM +0200, Martin Uecker wrote: > > > > A change that is not

Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types

> Am 03.05.2024 um 20:37 schrieb Martin Uecker : > > Am Freitag, dem 03.05.2024 um 20:18 +0200 schrieb Jakub Jelinek: >>> On Fri, May 03, 2024 at 08:04:18PM +0200, Martin Uecker wrote: >>> A change that is not optimal but would avoid a lot of trouble is to >>> only use the tag of the struct

Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types

Am Freitag, dem 03.05.2024 um 20:18 +0200 schrieb Jakub Jelinek: > On Fri, May 03, 2024 at 08:04:18PM +0200, Martin Uecker wrote: > > A change that is not optimal but would avoid a lot of trouble is to > > only use the tag of the struct for computing a TYPE_CANONICAL, which > > could then be set

Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types

On Fri, May 03, 2024 at 08:04:18PM +0200, Martin Uecker wrote: > A change that is not optimal but would avoid a lot of trouble is to > only use the tag of the struct for computing a TYPE_CANONICAL, which > could then be set already for incomplete types and never needs to > change again. We would

Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types

Am Freitag, dem 03.05.2024 um 19:30 +0200 schrieb Jakub Jelinek: > On Fri, May 03, 2024 at 05:32:12PM +0200, Martin Uecker wrote: > > Am Freitag, dem 03.05.2024 um 14:13 +0200 schrieb Richard Biener: > > > TYPE_STRUCTURAL_EQUALITY_P is part of our type system so we have > > > to make sure to

Re: [PATCH v2] gcc-14: Mention that some warnings are now errors

* Sebastian Huber: > On 03.05.24 17:06, Jonathan Wakely wrote: >>> I think it would be helpful to reference this change in the C >>> section. This warning to error change causes some issues with >>> legacy software. >> I agree it should be mentioned, but I would put it in the caveats >> section

Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types

Am Freitag, dem 03.05.2024 um 18:23 +0200 schrieb Richard Biener: > > > Am 03.05.2024 um 17:33 schrieb Martin Uecker : > > > > Am Freitag, dem 03.05.2024 um 14:13 +0200 schrieb Richard Biener: > > > TYPE_STRUCTURAL_EQUALITY_P is part of our type system so we have > > > to make sure to include

Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types

On Fri, May 03, 2024 at 05:32:12PM +0200, Martin Uecker wrote: > Am Freitag, dem 03.05.2024 um 14:13 +0200 schrieb Richard Biener: > > TYPE_STRUCTURAL_EQUALITY_P is part of our type system so we have > > to make sure to include that into the type unification done via > > type_hash_canon. This

[PATCH] Use DW_TAG_module for Ada

DWARF is not especially clear on the distinction between DW_TAG_namespace and DW_TAG_module, but I think that DW_TAG_module is more appropriate for Ada. This patch changes the compiler to do this. Note that the Ada compiler does not yet create NAMESPACE_DECLs. gcc * dwarf2out.cc

Re: [PATCH v2] gcc-14: Mention that some warnings are now errors

On 03.05.24 17:06, Jonathan Wakely wrote: I think it would be helpful to reference this change in the C section. This warning to error change causes some issues with legacy software. I agree it should be mentioned, but I would put it in the caveats section at the top, not as the last item of

[patch,avr,applied] PR92606: Don't optimize PROGMEM data against non-PROGMEM

Applied to fix this long standing wrong-code bug. Johann -- AVR: ipa/92606 - Don't optimize PROGMEM data against non-PROGMEM. ipa/92606: Inter-procedural analysis optimizes data across address-spaces and PROGMEM. As of v14, the PROGMEM part is still not fixed (and there is still no target

[RFA][RISC-V] Enable inlining str* by default

So with Chrstoph's patches from late 2022 we've had the ability to inline strlen, and str[n]cmp (scalar). However, we never actually turned this capability on by default! This patch flips the those default to allow inlinining by default. It also fixes one bug exposed by our internal

Re: [PATCH 3/3] combine: initialize a local var

On 5/3/24 01:26, Segher Boessenkool wrote: > On Thu, May 02, 2024 at 11:59:24AM -0700, Vineet Gupta wrote: >> This is no logic change (but technically still a functional change). > Where are 1/3 and 2/3? Or are those unrelated? Yes they were unrelated (minor doc fixes) hence didn't want to

[Committed 2/2] RISC-V: miscll comment fixes [NFC]

gcc/ChangeLog: * config/riscv/riscv.cc: Comment updates. * config/riscv/riscv.h: Ditto. Signed-off-by: Vineet Gupta --- gcc/config/riscv/riscv.cc | 6 -- gcc/config/riscv/riscv.h | 2 +- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git

[Committed 1/2] docs: rtl: document GET_MODE_INNER

gcc/ChangeLog * doc/rtl.texi: Add entry for GET_MODE_INNER. Signed-off-by: Vineet Gupta --- gcc/doc/rtl.texi | 7 +++ 1 file changed, 7 insertions(+) diff --git a/gcc/doc/rtl.texi b/gcc/doc/rtl.texi index 8ea6588cb71f..aa10b5235b53 100644 --- a/gcc/doc/rtl.texi +++

[PATCH] c++: Implement C++26 P2893R3 - Variadic friends [PR114459]

Hi! The following patch imeplements the C++26 P2893R3 - Variadic friends paper. The paper allows for the friend type declarations to specify more than one friend type specifier and allows to specify ... at the end of each. The patch doesn't introduce tentative parsing of friend-type-declaration

Re: [PATCH] Fix auto deduction for template specialization scopes [114915].

Thanks for the patch! On Wed, 1 May 2024, Seyed Sajad Kahani wrote: > When deducing auto for `adc_return_type`, `adc_variable_type`, and > `adc_decomp_type` contexts (at the usage time), we try to resolve the > outermost template arguments to be used for satisfaction. This is done by one > of

Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types

> Am 03.05.2024 um 17:33 schrieb Martin Uecker : > > Am Freitag, dem 03.05.2024 um 14:13 +0200 schrieb Richard Biener: >> TYPE_STRUCTURAL_EQUALITY_P is part of our type system so we have >> to make sure to include that into the type unification done via >> type_hash_canon. This requires the

Re: [PATCH v2] gcc-14: Mention that some warnings are now errors

On Fri, May 03, 2024 at 04:06:28PM +0100, Jonathan Wakely wrote: > I agree it should be mentioned, but I would put it in the caveats > section at the top, not as the last item of the C section. > > How about this? OK for wwwdocs? LGTM. > commit fe5fd75ea5a7a08eee0831cadbdd05689e9408db > Author:

Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types

Am Freitag, dem 03.05.2024 um 14:13 +0200 schrieb Richard Biener: > TYPE_STRUCTURAL_EQUALITY_P is part of our type system so we have > to make sure to include that into the type unification done via > type_hash_canon. This requires the flag to be set before querying > the hash which is the

[PATCH] c++: replace tf_norm with a local flag

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- The tf_norm flag controlling whether to build diagnostic information during constraint normalization doesn't need to be a global tsubst flag, and is confusingly named. This patch replaces it with a boolean

Re: [PATCH] c++: 'typename T::X' vs 'struct T::X' lookup [PR109420]

Hey Andrew, On Wed, 5 Apr 2023, Andrew Pinski wrote: > On Wed, Apr 5, 2023 at 10:32 AM Patrick Palka via Gcc-patches > wrote: > > > > On Wed, 5 Apr 2023, Patrick Palka wrote: > > > > > r13-6098-g46711ff8e60d64 made make_typename_type no longer ignore > > > non-types during the lookup, unless

Re: [PATCH v2] gcc-14: Mention that some warnings are now errors

On 02/05/24 16:29 +0200, Sebastian Huber wrote: On 24.04.24 14:28, Sebastian Huber wrote: - Am 15. Apr 2024 um 8:05 schrieb Sebastian Huber sebastian.hu...@embedded-brains.de: --- v2: Remove listing of options. htdocs/gcc-14/changes.html | 2 ++ 1 file changed, 2 insertions(+) diff

Re: [PATCH] DCE __cxa_atexit calls where the function is pure/const [PR19661]

On 5/2/24 3:56 PM, Andrew Pinski wrote: In C++ sometimes you have a deconstructor function which is "empty", like for an example with unions or with arrays. The front-end might not know it is empty either so this should be done on during optimization.o To implement it I added it to DCE

[PATCH] aarch64: Fix typo in aarch64-ldp-fusion.cc:combine_reg_notes [PR114936]

This fixes a typo in combine_reg_notes in the load/store pair fusion pass. As it stands, the calls to filter_notes store any REG_FRAME_RELATED_EXPR to fr_expr with the following association: - i2 -> fr_expr[0] - i1 -> fr_expr[1] but then the checks inside the following if statement expect the

Re: [PATCH] [ranger] Force buffer alignment in Value_Range [PR114912]

Ahh, that is indeed cleaner, and there's no longer a need to assert the sizeof of individual ranges. It looks like a default constructor is needed for the buffer now, but only for the default constructor of Value_Range. I have verified that the individual range constructors are not called on

Re: [PATCH] rs6000: Add OPTION_MASK_POWER8 [PR101865]

On 4/12/24 3:36 PM, Peter Bergner wrote: > Testing was clean on both LE and BE, so I pushed the changes. > I'll let things bake on trunk for a bit before pushing the backports. The backports all tested clean, so I pushed them. Fixed everywhere. Thanks everyone! Peter

[r15-124 Regression] FAIL: gcc.target/i386/pr70251.c (test for excess errors) on Linux/x86_64

On Linux/x86_64, 87e35da16df74cd1c4729a55d94e7bc592487f48 is the first bad commit commit 87e35da16df74cd1c4729a55d94e7bc592487f48 Author: Richard Biener Date: Thu May 2 13:55:15 2024 +0200 tree-optimization/114921 - _Float16 -> __bf16 isn't noop caused FAIL: gcc.target/i386/pr70251.c 1

Re: [PATCH] testsuite: fix analyzer C++ failures on Solaris [PR111475]

Hi Jakub, > On Fri, May 03, 2024 at 09:31:08AM -0400, David Malcolm wrote: >> Jakub, Richi, Rainer: this is a non-trivial change that cleans up >> analyzer C++ testsuite results on Solaris, but has a slight risk of >> affecting analyzer behavior on other targets. As such, I was thinking >> to

Re: [PATCH] testsuite: fix analyzer C++ failures on Solaris [PR111475]

On Fri, May 03, 2024 at 09:31:08AM -0400, David Malcolm wrote: > Jakub, Richi, Rainer: this is a non-trivial change that cleans up > analyzer C++ testsuite results on Solaris, but has a slight risk of > affecting analyzer behavior on other targets. As such, I was thinking > to hold off on

[PATCH] testsuite: fix analyzer C++ failures on Solaris [PR111475]

As part of PR analyzer/96395, these patches moved testcases from gcc.dg/analyzer to c-c++-common/analyzer: - r14-3503-g55f6a7d949abc7 - r14-3823-g50b5199cff6908 - r14-6564-gae034b9106fbdd Unfortunately this led to numerous g++ testsuite failures on Solaris, tracked as PR analyzer/111475. Almost

[PATCH] middle-end/114931 - type_hash_canon and structual equality types

TYPE_STRUCTURAL_EQUALITY_P is part of our type system so we have to make sure to include that into the type unification done via type_hash_canon. This requires the flag to be set before querying the hash which is the biggest part of the patch. Bootstrapped and tested on x86_64-unknown-linux-gnu

Re: [PATCH 3/3] Add parentheses around DECL_INIT for .original [PR23872]

On Thu, May 2, 2024 at 11:40 PM Andrew Pinski wrote: > > When we have : > `void f (int y, int z) { int x = ( z++,y); }` > > This would have printed the decl's initializer without > parentheses which can confusion if you think that is defining > another variable rather than the compound

Re: [PATCH 2/3] Improve DECL_EXPR printing in .original [PR23872]

On Thu, May 2, 2024 at 11:40 PM Andrew Pinski wrote: > > Right now we don't print that a DECL_EXPR and we get > basically double output of the decls and it looks confusing. > This fixes that. > for the simple example: > `void foo () { int result = 0;}` > This gives: > ``` > { > int result = 0;

Re: [PATCH 1/3] Fix printing COMPOUND_EXPR in .original [PR23872]

On Thu, May 2, 2024 at 11:40 PM Andrew Pinski wrote: > > Starting with the merge of the openmp branch into the trunk > (r0-73077-g953ff28998b59b), COMPOUND_EXPR started to be printed > as `expr; , expr` which is wrong. This was due to the wrong > conversion of dumping_stmts into `!(flags &

[PATCH] Add default bitmap obstack allocation check

The following adds a check that the global bitmap obstack is initialized when allocating a bitmap from it. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. * bitmap.cc (bitmap_alloc): When using the global bitmap obstack assert that is initialized. --- gcc/bitmap.cc

Re: [PATCH v2] Silence two instances of -Wcalloc-transposed-args

On Fri, May 3, 2024 at 10:03 AM Peter Damianov wrote: > > libgcc/ > * libgcov-util.c (tag_counters): Swap order of arguments to xcalloc. > (topen_to_memory_representation): Likewise. Thanks, I pushed this for you. Richard. > Signed-off-by: Peter Damianov > --- >

Re: [PATCH] libstdc++: Update powerpc-linux-gnu baseline_symbols

On Fri, May 3, 2024 at 12:55 PM Jonathan Wakely wrote: > > On Fri, 3 May 2024 at 11:51, Jonathan Wakely wrote: > > > > On Fri, 3 May 2024 at 10:30, Andreas Schwab wrote: > > > > > > * config/abi/post/powerpc-linux-gnu/baseline_symbols.txt: Update. > > > *

[PATCH v3] c++/modules: Fix dangling pointer with imported_temploid_friends

On Thu, May 02, 2024 at 02:05:38PM -0400, Jason Merrill wrote: > On 5/1/24 21:34, Nathaniel Shead wrote: > > On Thu, May 02, 2024 at 12:15:44AM +1000, Nathaniel Shead wrote: > > > On Wed, May 01, 2024 at 09:57:38AM -0400, Patrick Palka wrote: > > > > > > > > On Wed, 1 May 2024, Nathaniel Shead

Re: [PATCH] Avoid changing type in the type_hash_canon hash

On Fri, May 03, 2024 at 12:58:55PM +0200, Richard Biener wrote: > When building a type and type_hash_canon returns an existing type > avoid changing it, in particular its TYPE_CANONICAL. > > Bootstrapped and tested on x86_64-unknown-linux-gnu for all languages. > > OK for trunk? > > Thanks, >

[PATCH] Avoid changing type in the type_hash_canon hash

When building a type and type_hash_canon returns an existing type avoid changing it, in particular its TYPE_CANONICAL. Bootstrapped and tested on x86_64-unknown-linux-gnu for all languages. OK for trunk? Thanks, Richard. PR middle-end/114931 * tree.cc (build_array_type_1):

Re: [PATCH] libstdc++: Update powerpc-linux-gnu baseline_symbols

On Fri, 3 May 2024 at 11:51, Jonathan Wakely wrote: > > On Fri, 3 May 2024 at 10:30, Andreas Schwab wrote: > > > > * config/abi/post/powerpc-linux-gnu/baseline_symbols.txt: Update. > > * config/abi/post/powerpc64-linux-gnu/32/baseline_symbols.txt: > > Update. > > OK thanks Also

Re: [PATCH] libstdc++: Update powerpc-linux-gnu baseline_symbols

On Fri, 3 May 2024 at 10:30, Andreas Schwab wrote: > > * config/abi/post/powerpc-linux-gnu/baseline_symbols.txt: Update. > * config/abi/post/powerpc64-linux-gnu/32/baseline_symbols.txt: Update. OK thanks > --- > .../powerpc-linux-gnu/baseline_symbols.txt| 98

Re: [PATCH] PR middle-end/111701: signbit(x*x) vs -fsignaling-nans

On Thu, May 2, 2024 at 3:48 PM Roger Sayle wrote: > > > > From: Richard Biener > > On Thu, May 2, 2024 at 11:34 AM Roger Sayle > > wrote: > > > > > > > > > > From: Richard Biener On Fri, Apr 26, > > > > 2024 at 10:19 AM Roger Sayle > > > > wrote: > > > > > > > > > > This patch addresses PR

Re: [wwwdocs] Add znver5 to GCC 14 changes

Hi Gerald, On Fri, May 03 2024, Gerald Pfeifer wrote: > Hi Martin, > > On Thu, 2 May 2024, Martin Jambor wrote: >> + GCC now supports AMD CPUs based on the znver5 core via >> +-march=znver5. Based on ISA extensions enabled on >> +a znver4 core, the switch further enables the AVXVNNI,

Re: [PATCH] [ranger] Force buffer alignment in Value_Range [PR114912]

On Fri, May 3, 2024 at 2:24 AM Aldy Hernandez wrote: > > Sparc requires strict alignment and is choking on the byte vector in > Value_Range. Is this the right approach, or is there a more canonical > way of forcing alignment? I think the suggestion was to change over to use an union and use the

[PATCH] libstdc++: Update powerpc-linux-gnu baseline_symbols

* config/abi/post/powerpc-linux-gnu/baseline_symbols.txt: Update. * config/abi/post/powerpc64-linux-gnu/32/baseline_symbols.txt: Update. --- .../powerpc-linux-gnu/baseline_symbols.txt| 98 +++ .../32/baseline_symbols.txt | 98

[PATCH] [ranger] Force buffer alignment in Value_Range [PR114912]

Sparc requires strict alignment and is choking on the byte vector in Value_Range. Is this the right approach, or is there a more canonical way of forcing alignment? If this is correct, OK for trunk? gcc/ChangeLog: * value-range.h (class Value_Range): Use a union. --- gcc/value-range.h

Re: [PATCH V4 1/3] aarch64: Place target independent and dependent changed code in one file

On 22/04/2024 13:01, Ajit Agarwal wrote: > Hello Alex: > > On 14/04/24 10:29 pm, Ajit Agarwal wrote: > > Hello Alex: > > > > On 12/04/24 11:02 pm, Ajit Agarwal wrote: > >> Hello Alex: > >> > >> On 12/04/24 8:15 pm, Alex Coplan wrote: > >>> On 12/04/2024 20:02, Ajit Agarwal wrote: > Hello

Re: [wwwdocs] Add znver5 to GCC 14 changes

Hi Martin, On Thu, 2 May 2024, Martin Jambor wrote: > + GCC now supports AMD CPUs based on the znver5 core via > +-march=znver5. Based on ISA extensions enabled on > +a znver4 core, the switch further enables the AVXVNNI, MOVDIRI, > +MOVDIR64B, AVX512VP2INTERSECT, and PREFETCHI ISA

Re: [PATCH 3/3] combine: initialize a local var

On Thu, May 02, 2024 at 02:38:12PM -0600, Jeff Law wrote: > > > On 5/2/24 12:59 PM, Vineet Gupta wrote: > >This is no logic change (but technically still a functional change). > > > >Ran into this when stepping thru combine code. > >@newpat has some random garbage for a bit until it is actually

Re: [PATCH 3/3] combine: initialize a local var

On Thu, May 02, 2024 at 11:59:24AM -0700, Vineet Gupta wrote: > This is no logic change (but technically still a functional change). Where are 1/3 and 2/3? Or are those unrelated? Please don't make series like that. > Ran into this when stepping thru combine code. > @newpat has some random

[PATCH v2] Silence two instances of -Wcalloc-transposed-args

libgcc/ * libgcov-util.c (tag_counters): Swap order of arguments to xcalloc. (topen_to_memory_representation): Likewise. Signed-off-by: Peter Damianov --- libgcc/libgcov-util.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libgcc/libgcov-util.c

Re: [PATCH] tree-inline: Add __builtin_stack_{save,restore} pair about inline calls with calls to alloca [PR113596]

On Fri, 3 May 2024, Jakub Jelinek wrote: > Hi! > > The following patch adds save_NNN = __builtin_stack_save (); ... > __builtin_stack_restore (save_NNN); > pair around inline calls which call alloca (alloca calls because of > VLA vars are ignored in that decision). > The patch doesn't change

[PATCH] tree-inline: Add __builtin_stack_{save,restore} pair about inline calls with calls to alloca [PR113596]

Hi! The following patch adds save_NNN = __builtin_stack_save (); ... __builtin_stack_restore (save_NNN); pair around inline calls which call alloca (alloca calls because of VLA vars are ignored in that decision). The patch doesn't change anything on whether we try to inline such calls or not, it

Re: [Backport] ifcvt: Don't lower bitfields with non-constant offsets [PR 111882]

On Fri, 3 May 2024, Richard Ball wrote: > Hi, > > Requesting permission to backport: > https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=24cf1f600b8ad34c68a51f48884e72d01f729893 > to gcc-13 in order to fix: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111882 > > Applies cleanly and with no

Re: cfgrtl: Fix MEM_EXPR update in duplicate_insn_chain [PR114924]

On Thu, 2 May 2024, Alex Coplan wrote: > Hi, > > The PR shows that when cfgrtl.cc:duplicate_insn_chain attempts to > update the MR_DEPENDENCE_CLIQUE information for a MEM_EXPR we can end up > accidentally dropping (e.g.) an ARRAY_REF from the MEM_EXPR and end up > replacing it with the