Re: [r14-9173 Regression] FAIL: gcc.dg/tree-ssa/andnot-2.c scan-tree-dump-not forwprop3 "_expr" on Linux/x86_64

On Tue, Feb 27, 2024 at 3:44 PM Richard Biener wrote: > > On Tue, 27 Feb 2024, haochen.jiang wrote: > > > On Linux/x86_64, > > > > af66ad89e8169f44db723813662917cf4cbb78fc is the first bad commit > > commit af66ad89e8169f44db723813662917cf4cbb78fc > > Author: Richard Biener > > Date: Fri Feb

Re: [r14-9173 Regression] FAIL: gcc.dg/tree-ssa/andnot-2.c scan-tree-dump-not forwprop3 "_expr" on Linux/x86_64

On Tue, 27 Feb 2024, haochen.jiang wrote: > On Linux/x86_64, > > af66ad89e8169f44db723813662917cf4cbb78fc is the first bad commit > commit af66ad89e8169f44db723813662917cf4cbb78fc > Author: Richard Biener > Date: Fri Feb 23 16:06:05 2024 +0100 > > middle-end/114070 - folding breaking

ReRe:[PATCH V3 0/2] aarch64: Place target independent and dependent changed and unchanged code in one file.

Hello Richard/Alex: This patch has better diff with changed and unchanged code. Unchanged code and some of the changed code will be extracted into target independent headers and sources wherein target deoendent code changed and unchanged code would be in target dependent file like

Re: [PATCH] x86: Properly implement AMX-TILE load/store intrinsics

On Mon, Feb 26, 2024 at 6:30 PM H.J. Lu wrote: > > On Sun, Feb 25, 2024 at 8:25 PM H.J. Lu wrote: > > > > On Sun, Feb 25, 2024 at 7:03 PM Hongtao Liu wrote: > > > > > > On Mon, Feb 26, 2024 at 10:37 AM H.J. Lu wrote: > > > > > > > > On Sun, Feb 25, 2024 at 6:03 PM Hongtao Liu wrote: > > > > >

[PATCH 3/3] Fix PR libcc1/113977

PR libcc1/113977 points out a case where a simple expression is rejected with a compiler error message. The bug here is that gdb does not inform the plugin of the correct alignment -- in fact, there is no way to do that. This patch adds a new method to allow the alignment to be set, and bumps

[PATCH 2/3] Fix version negotiation in libcc1 plugins

This fixes version negotiation in the libcc1 plugins. It's done in a simple way: the version number from the context object is now passed to base_gdb_plugin. The idea behind this is that when the client (gdb) requests version N, the plugin should respond with the newest version that it knows of

[PATCH 1/3] Change 'v1' float and int code to fall back to v0

While working on another patch, I discovered that the libcc1 plugin code never did version negotiation correctly. So, the patches to introduce v1 never did anything -- the new code, as far as I know, has never been run. Making version negotiation work shows that the existing code causes crashes.

[PATCH 0/3] Fix libcc1 failure

| 2 +- 8 files changed, 90 insertions(+), 25 deletions(-) --- base-commit: 1e2a3b278d7770db6b5ca869756b1375fc3a77d6 change-id: 20240226-gdb-compile-align-f31c69137d6a Best regards, -- Tom Tromey

Re: [PATCH] rs6000: Don't allow immediate value in the vsx_splat pattern [PR113950]

on 2024/2/27 10:13, Peter Bergner wrote: > On 2/26/24 7:55 PM, Kewen.Lin wrote: >> on 2024/2/26 23:07, Peter Bergner wrote: >>> so I think we should use both Jeevitha's predicate change and >>> your operands[1] change. >> >> Since either the original predicate change or operands[1] change >> can

[PATCH] c++/modules: local class merging [PR99426]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this approach look reasonable? -- >8 -- One known missing piece in the modules implementation is merging of a streamed-in local class with the corresponding in-TU version of the local class. This missing piece turns out to cause a

Re: [PATCH] rs6000: Don't allow immediate value in the vsx_splat pattern [PR113950]

On 2/26/24 7:55 PM, Kewen.Lin wrote: > on 2024/2/26 23:07, Peter Bergner wrote: >> so I think we should use both Jeevitha's predicate change and >> your operands[1] change. > > Since either the original predicate change or operands[1] change > can fix this issue, I think it's implied that only

Re: [PATCH] rs6000: Don't allow immediate value in the vsx_splat pattern [PR113950]

on 2024/2/26 23:07, Peter Bergner wrote: > On 2/26/24 4:49 AM, Kewen.Lin wrote: >> on 2024/2/26 14:18, jeevitha wrote: >>> Hi All, >>> diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md >>> index 6111cc90eb7..e5688ff972a 100644 >>> --- a/gcc/config/rs6000/vsx.md >>> +++

Re: [PATCH] c++: Revert deferring emission of inline variables [PR114013]

On 2/21/24 05:28, Nathaniel Shead wrote: My earlier patch appears to have caused some regressions. I've taken a quick look to see if there are obvious workarounds, but given the time frame and the fact that I still don't really understand all the details of how and when symbols get emitted, I

Re: [PATCH] RISC-V: Add riscv_vector_cc function attribute

Thanks for supporting this. I'd rather leave this patch review to kito's since it's kito's proposal. juzhe.zh...@rivai.ai From: Li Xu Date: 2024-02-27 09:17 To: gcc-patches CC: kito.cheng; palmer; juzhe.zhong; zhengyu; xuli Subject: [PATCH] RISC-V: Add riscv_vector_cc function attribute From:

Re: Re: [PATCH] RISC-V: Update test expectancies with recent scheduler change

If the scheduling model increases the vsetvls, we shouldn't set it as default scheduling model juzhe.zh...@rivai.ai From: Robin Dapp Date: 2024-02-26 21:29 To: Edwin Lu; gcc-patches CC: rdapp.gcc; gnu-toolchain; pan2.li; juzhe.zh...@rivai.ai Subject: Re: [PATCH] RISC-V: Update test

Re: [PATCH] RISC-V: Add initial cost handling for segment loads/stores.

This patch looks odd to me. I don't see memrefs in the trunk code. Also, I prefer list all cost in cost tune info for NF = 2 ~ 8 like ARM SVE does: /* Detect cases in which a vector load or store represents an LD[234] or ST[234] instruction. */ switch (aarch64_ld234_st234_vectors

[PATCH] RISC-V: Add riscv_vector_cc function attribute

From: xuli Standard vector calling convention variant will only enabled when function has vector argument or returning value by default, however user may also want to invoke function without that during a vectorized loop at some situation, but it will cause a huge performance penalty due to

[PATCH] combine: Don't simplify paradoxical SUBREG on WORD_REGISTER_OPERATIONS [PR113010]

The sign-bit-copies of a sign-extending load cannot be known until runtime on WORD_REGISTER_OPERATIONS targets, except in the case of a zero-extending MEM load. See the fix for PR112758. 2024-02-22 Greg McGary PR rtl-optimization/113010 * combine.cc (simplify_comparison):

[PATCH] tree-profile: Don't instrument an IFUNC resolver nor its callees

We can't instrument an IFUNC resolver nor its callees as it may require TLS which hasn't been set up yet when the dynamic linker is resolving IFUNC symbols. Add an IFUNC resolver caller marker to symtab_node to avoid recursive checking. gcc/ChangeLog: PR tree-optimization/114115

[r14-9173 Regression] FAIL: gcc.dg/tree-ssa/andnot-2.c scan-tree-dump-not forwprop3 "_expr" on Linux/x86_64

On Linux/x86_64, af66ad89e8169f44db723813662917cf4cbb78fc is the first bad commit commit af66ad89e8169f44db723813662917cf4cbb78fc Author: Richard Biener Date: Fri Feb 23 16:06:05 2024 +0100 middle-end/114070 - folding breaking VEC_COND expansion caused FAIL: gcc.dg/tree-ssa/andnot-2.c

[patch,avr,applied] Tag optimization options as such.

Some avr options were missing the "Optimization" flag, which is added by this patch. Johann -- AVR: Tag optimization options as "Optimization". Some options that are pure optimizations where not tagged as such. gcc/ * config/avr/avr.opt (mcall-prologues, mrelax, maccumulate-args)

[PATCH] c++/modules: complete_vars ICE with non-exported constexpr var

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Here during stream-in of the non-exported constexpr var 'a' we call maybe_register_incomplete_var, which ends up taking the second branch and pushing {a, NULL_TREE} onto incomplete_vars. We later ICE from

[PATCH] c++/modules: befriending template from current class scope

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Here the TEMPLATE_DECL representing the template friend declaration for B has class scope since B has class scope, but get_merge_kind assumes all DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P TEMPLATE_DECL have

[PATCH V2] rs6000: Don't allow immediate value in the vsx_splat pattern [PR113950]

Hi All, The following patch has been bootstrapped and regtested on powerpc64le-linux. There is no immediate value splatting instruction in Power. Currently, those values need to be stored in a register or memory. To address this issue, I have updated the predicate for the second operand in

[avr,patch,applied] Remove some dead code

This code was dead in the block where it lived, because avr_adiw_reg_p() is only true when ADIW and SBIW are available -- which is not the case for AVR_TINY. Johann -- AVR: Dead code removal. gcc/ * config/avr/avr.cc (avr_out_compare) [AVR_TINY]: Remove code in an "if

Re: [PATCH v5 RESEND] C, ObjC: Add -Wunterminated-string-initialization

On 2/26/24 09:19, Joseph Myers wrote: On Mon, 26 Feb 2024, Alejandro Colomar wrote: The idea seems reasonable, but the patch needs documentation for the new option in invoke.texi. Thanks! Will do. I don't see an obvious order in that file. Where would you put the option? Do you want me

Re: [wwwdocs] Add Ada's GCC 14 changelog entry

Hi Mark, On 2/26/24 10:17, Marc Poulhiès wrote: > > Fernando, > > Thank you for this work! I have a few comments, see below. > > diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html > index 85ccc54d..e6c96c9f 100644 > --- a/htdocs/gcc-14/changes.html > +++

Re: [PATCH v5 RESEND] C, ObjC: Add -Wunterminated-string-initialization

On Feb 26, 2024, at 7:56 AM, Alejandro Colomar wrote: > > I don't see an obvious order in that file. Where would you put the > option? The best place, would be to put it just after: -Warray-bounds -Warray-bounds=n This is a functional style grouping that best mirrors the existing

[PATCH v1 05/13] Reuse MinGW from i386 for AArch64

Thank you for the fix, Bernhard! Please send it as a separate patch. Regards, Evgeny -Original Message- Sent: Monday, February 26, 2024 9:18 AM Bernhard Reutner-Fischer PS: Please don't forget to add an entry to contrib/config-list.mk thanks

[PATCH v1 04/13] aarch64: Add aarch64-w64-mingw32 COFF

Thanks for noticing this definition. Yes, it was added to enable proper types in mingw/mingw-stdint.h for AArch64. Based on the review, TARGET_64BIT has been excluded from aarch64/aarch64-coff.h, and mingw/mingw-stdint.h has been modified to support AArch64. Regards, Evgeny

Re: [PATCH] c++: Fix explicit instantiation of const variable templates after earlier implicit instantation [PR113976]

On Tue, 20 Feb 2024, Jakub Jelinek wrote: > Hi! > > Already previously instantiated const variable templates had > cp_apply_type_quals_to_decl called when they were instantiated, > but if they need runtime initialization, their TREE_READONLY flag > has been subsequently cleared. > Explicit

[PATCH v1 03/13] aarch64: Mark x18 register as a fixed register for MS ABI

In user mode on Windows, it points to TEB (Thread Environment Block). more information here https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#integer-registers https://learn.microsoft.com/en-us/windows/win32/api/winternl/ns-winternl-teb Regards, Evgeny

Re: [PATCH] c++: Revert deferring emission of inline variables [PR114013]

On Wed, 21 Feb 2024, Nathaniel Shead wrote: > My earlier patch appears to have caused some regressions. I've taken a > quick look to see if there are obvious workarounds, but given the time > frame and the fact that I still don't really understand all the details > of how and when symbols get

Re: [PATCH 1/3] vect: Pass stmt_vec_info to TARGET_SIMD_CLONE_USABLE

On 05/02/2024 09:56, Richard Biener wrote: On Thu, 1 Feb 2024, Andre Vieira (lists) wrote: On 01/02/2024 07:19, Richard Biener wrote: On Wed, 31 Jan 2024, Andre Vieira (lists) wrote: The patch didn't come with a testcase so it's really hard to tell what goes wrong now and how it is

Re: [PATCH] arm: fix c23 0-named-args caller-side stdarg

Hi Alexandre, I don't have the ability to OK the patch, but I'm attempting to do a review in order to reduce the workload for any maintainer.  (Apologies for the slow response). I think you're right that the AAPCS32 requires all arguments to be passed in registers for this testcase. (Nit on

[PATCH v1 03/13] aarch64: Mark x18 register as a fixed register for MS ABI

Thank you Jacek for clarifying Wine's needs for ms_abi! Work on vararg support is planned. Regards, Evgeny -Original Message- Friday, February 23, 2024 5:10 PM Jacek Caban wrote: > Dynamically might be needed also if we want to support ms_abi > attribute and/or -mabi=ms to support the

Re: Patch ping^2

> Hi! > > I'd like to ping 2 patches: > > https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644580.html > > > PR113617 P1 - Handle private COMDAT function symbol reference

Re: [PATCH v5 RESEND] C, ObjC: Add -Wunterminated-string-initialization

On Mon, 26 Feb 2024, Alejandro Colomar wrote: > > The idea seems reasonable, but the patch needs documentation for the new > > option in invoke.texi. > > Thanks! Will do. > > I don't see an obvious order in that file. Where would you put the > option? Do you want me to sort(1) it first, and

Re: [PATCH] ARM: Fix conditional execution [PR113915]

On 26/02/2024 16:05, Wilco Dijkstra wrote: > Hi Richard, > >> Did you test this on a thumb1 target?  It seems to me that the target parts >> that you've >> removed were likely related to that.  In fact, I don't see why this test >> would need to be changed at all. > > The testcase explicitly

[PATCH v1 03/13] aarch64: Mark x18 register as a fixed register for MS ABI

This change has been refactored based on the review and will be included in v2. Original aarch64.h will remain unchanged, and the required definition for MS ABI will be implemented in aarch64-abi-ms.h. The reference to this file will be added to config.gcc. This change has been verified, and it

Re: [PATCH] ARM: Fix conditional execution [PR113915]

Hi Richard, > Did you test this on a thumb1 target?  It seems to me that the target parts > that you've > removed were likely related to that.  In fact, I don't see why this test > would need to be changed at all. The testcase explicitly forces a Thumb-2 target (arm_arch_v6t2). The patterns

Re: [PATCH] tree-optimization/114074 - CHREC multiplication and undefined overflow

On Mon, Feb 26, 2024 at 03:15:02PM +0100, Richard Biener wrote: > When folding a multiply CHRECs are handled like {a, +, b} * c > is {a*c, +, b*c} but that isn't generally correct when overflow > invokes undefined behavior. The following uses unsigned arithmetic > unless either a is zero or a and

Re: [PATCH] ARM: Fix conditional execution [PR113915]

On 23/02/2024 15:46, Wilco Dijkstra wrote: > Hi Richard, > >> This bit isn't.  The correct fix here is to fix the pattern(s) concerned to >> add the missing predicate. >> >> Note that builtin-bswap.x explicitly mentions predicated mnemonics in the >> comments. > > I fixed the patterns in v2.

Re: [PATCH v5 RESEND] C, ObjC: Add -Wunterminated-string-initialization

Hi Joseph, On Mon, Feb 26, 2024 at 03:24:32PM +, Joseph Myers wrote: > On Sun, 25 Feb 2024, Mike Stump wrote: > > > On Feb 6, 2024, at 2:45 AM, Alejandro Colomar wrote: > > > > > > Warn about the following: > > > > > >char s[3] = "foo"; > > > > No ObjC specific impact here, so no

Re: [PATCH] tree-optimization/114074 - CHREC multiplication and undefined overflow

On Mon, Feb 26, 2024 at 04:51:08PM +0100, Michael Matz wrote: > On Mon, 26 Feb 2024, Jakub Jelinek wrote: > > > > Will update the patch, I think any improvement should be done > > > to get_range_pos_neg (it's a bit odd in behavior for unsigned > > > but I have only signed things incoming). > > >

[PATCH] RISC-V: Add initial cost handling for segment loads/stores.

Hi, This has been sitting on my local tree - I've been wanting to post it for a while but somehow forgot. This patch makes segment loads and stores more expensive. It adds segment_load and segment_store cost fields to the common vector costs and adds handling to adjust_stmt_cost. In the future

Re: [PATCH] tree-optimization/114074 - CHREC multiplication and undefined overflow

Hello, On Mon, 26 Feb 2024, Jakub Jelinek wrote: > > Will update the patch, I think any improvement should be done > > to get_range_pos_neg (it's a bit odd in behavior for unsigned > > but I have only signed things incoming). > > For unsigned if it always returned 1, it would be quite useless,

Re: [PATCH v5 RESEND] C, ObjC: Add -Wunterminated-string-initialization

On Sun, 25 Feb 2024, Alejandro Colomar wrote: > or if it's just that everyone was busy doing > other stuff. Yes, that's right. The patch was already listed on my patch review backlog, but that backlog is long. -- Joseph S. Myers josmy...@redhat.com

Re: [PATCH v5 RESEND] C, ObjC: Add -Wunterminated-string-initialization

On Sun, 25 Feb 2024, Mike Stump wrote: > On Feb 6, 2024, at 2:45 AM, Alejandro Colomar wrote: > > > > Warn about the following: > > > >char s[3] = "foo"; > > No ObjC specific impact here, so no need for ObjC review. > > As a member of the peanut gallery, I like the patch. > > Joseph,

Re: [PATCH] c: Improve some diagnostics for __builtin_stdc_bit_* [PR114042]

On Fri, 23 Feb 2024, Jakub Jelinek wrote: > Hi! > > The PR complains that for the __builtin_stdc_bit_* "builtins" the > diagnostics doesn't mention the name of the builtin the user used, but > instead __builtin_{clz,ctz,popcount}g instead (which is what the FE > immediately lowers it to). > >

Re: [PATCH] rs6000: Don't allow immediate value in the vsx_splat pattern [PR113950]

On 26/02/24 8:37 pm, Peter Bergner wrote: > On 2/26/24 4:49 AM, Kewen.Lin wrote: >> on 2024/2/26 14:18, jeevitha wrote: >>> Hi All, >>> diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md >>> index 6111cc90eb7..e5688ff972a 100644 >>> --- a/gcc/config/rs6000/vsx.md >>> +++

Re: [PATCH] rs6000: Don't allow immediate value in the vsx_splat pattern [PR113950]

On 2/26/24 4:49 AM, Kewen.Lin wrote: > on 2024/2/26 14:18, jeevitha wrote: >> Hi All, >> diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md >> index 6111cc90eb7..e5688ff972a 100644 >> --- a/gcc/config/rs6000/vsx.md >> +++ b/gcc/config/rs6000/vsx.md >> @@ -4660,7 +4660,7 @@ >>

Re: [PATCH] tree-optimization/114074 - CHREC multiplication and undefined overflow

On Mon, Feb 26, 2024 at 03:29:30PM +0100, Richard Biener wrote: > On Mon, 26 Feb 2024, Jakub Jelinek wrote: > > > On Mon, Feb 26, 2024 at 03:15:02PM +0100, Richard Biener wrote: > > > When folding a multiply CHRECs are handled like {a, +, b} * c > > > is {a*c, +, b*c} but that isn't generally

[PATCH] tree-optimization/114081 - dominator update for prologue peeling

The following implements manual update for multi-exit loop prologue peeling during vectorization. Boostrap / regtest running on x86_64-unknown-linux-gnu. I think the amount of coverage for prologue peeling with early exits is very low, so my testing success might not mean much. Richard.

Re: [PATCH] tree-optimization/114074 - CHREC multiplication and undefined overflow

On Mon, 26 Feb 2024, Jakub Jelinek wrote: > On Mon, Feb 26, 2024 at 03:15:02PM +0100, Richard Biener wrote: > > When folding a multiply CHRECs are handled like {a, +, b} * c > > is {a*c, +, b*c} but that isn't generally correct when overflow > > invokes undefined behavior. The following uses

Re: [PATCH] tree-optimization/114074 - CHREC multiplication and undefined overflow

On Mon, Feb 26, 2024 at 03:15:02PM +0100, Richard Biener wrote: > When folding a multiply CHRECs are handled like {a, +, b} * c > is {a*c, +, b*c} but that isn't generally correct when overflow > invokes undefined behavior. The following uses unsigned arithmetic > unless either a is zero or a and

[PATCH v2] DSE: Bugfix ICE after allow vector type in get_stored_val

From: Pan Li We allowed vector type for get_stored_val when read is less than or equal to store in previous. Unfortunately, we missed to adjust the validate_subreg part accordingly. When the vector type's size is less than vector register, it will be considered as invalid in the

[PATCH] tree-optimization/114074 - CHREC multiplication and undefined overflow

When folding a multiply CHRECs are handled like {a, +, b} * c is {a*c, +, b*c} but that isn't generally correct when overflow invokes undefined behavior. The following uses unsigned arithmetic unless either a is zero or a and b have the same sign. I've used simple early outs for INTEGER_CSTs and

RE: [PATCH]middle-end: delay updating of dominators until later during vectorization. [PR114081]

On Mon, 26 Feb 2024, Tamar Christina wrote: > > > The testcase shows an interesting case where we have multiple loops > > > sharing a > > > live value and have an early exit that go to the same location. The > > > additional > > > complication is that on x86_64 with -mavx we seem to also do

Re: [PATCH] RISC-V: Update test expectancies with recent scheduler change

On 2/24/24 00:10, Edwin Lu wrote: > Given the recent change with adding the scheduler pipeline descriptions, > many scan-dump failures emerged. Relax the expected assembler output > conditions on the affected tests to reduce noise. I'm not entirely sure yet about relaxing the scans like this.

[Ada] Fix PR ada/113893

The finalization of objects dynamically allocated through an anonymous access type is deferred to the enclosing library unit in the current implementation and a warning is given on each of them. However this cannot be done if the designated type is local, because this would generate dangling

Re: Ping: Re: [PATCH] libgcc: fix SEH C++ rethrow semantics [PR113337]

Il 26/02/24 02:41, NightStrike ha scritto: It's mostly up to you whether you want to make the patch and test it. I mean, the whole file has no code modifications since bd6ecbe48ada (2020), and that specific function is the same since it was first committed (bf1431e3596b, from 2012). I don't

RE: [PATCH]middle-end: delay updating of dominators until later during vectorization. [PR114081]

> > The testcase shows an interesting case where we have multiple loops sharing > > a > > live value and have an early exit that go to the same location. The > > additional > > complication is that on x86_64 with -mavx we seem to also do prologue > > peeling > > on the loops. > > > > We

[PATCH] Add myself to write after approval and DCO.

Hello, I have added myself to write after approval and DCO. Thanks, Juergen Christ ChangeLog: * MAINTAINERS: Add myself to write after approval and DCO. Signed-off-by: Juergen Christ --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS

[PATCH 2/2] tree-optimization/114099 - virtual LC PHIs and early exit vect

In some cases exits can lack LC PHI nodes for the virtual operand. We have to create them when the epilog loop requires them which also allows us to remove some only halfway correct fixups. This is the variant triggering for alternate exits. Bootstrap and regtest pending on

[PATCH 1/2] tree-optimization/114068 - missed virtual LC PHI after vect peeling

When we choose the IV exit to be one leading to no virtual use we fail to have a virtual LC PHI even though we need it for the epilog entry. The following makes sure to create it so that later updating works. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. PR

Re: [PATCH] rs6000: Don't allow immediate value in the vsx_splat pattern [PR113950]

Hi, on 2024/2/26 14:18, jeevitha wrote: > Hi All, > > The following patch has been bootstrapped and regtested on powerpc64le-linux. > > There is no immediate value splatting instruction in powerpc. Currently that > needs to be stored in a register or memory. For addressing this I have updated >

Re: Repost [PATCH 1/6] Add -mcpu=future

on 2024/2/21 15:19, Michael Meissner wrote: > On Tue, Feb 20, 2024 at 06:35:34PM +0800, Kewen.Lin wrote: >> Hi Mike, >> >> Sorry for late reply (just back from vacation). >> >> on 2024/2/8 03:58, Michael Meissner wrote: >>> On Wed, Feb 07, 2024 at 05:21:10PM +0800, Kewen.Lin wrote: on

Re: [PATCH]middle-end: delay updating of dominators until later during vectorization. [PR114081]

On Sun, 25 Feb 2024, Tamar Christina wrote: > Hi All, > > The testcase shows an interesting case where we have multiple loops sharing a > live value and have an early exit that go to the same location. The > additional > complication is that on x86_64 with -mavx we seem to also do prologue

Re: [PATCH] x86: Properly implement AMX-TILE load/store intrinsics

On Sun, Feb 25, 2024 at 8:25 PM H.J. Lu wrote: > > On Sun, Feb 25, 2024 at 7:03 PM Hongtao Liu wrote: > > > > On Mon, Feb 26, 2024 at 10:37 AM H.J. Lu wrote: > > > > > > On Sun, Feb 25, 2024 at 6:03 PM Hongtao Liu wrote: > > > > > > > > On Mon, Feb 26, 2024 at 5:11 AM H.J. Lu wrote: > > > > >

[patch,avr] PR114100 : Better indirect addressing on reduced cores

A description of what the patch does follows in the commit message below. On ATmega128, there are no changes in test results. On ATtiny40 (reduced core) there are no new execution fails, but apart from that there is quite some noise in the delta: unsupported (memory full) -> pass unsupported

Re: [PATCH 1/2] LoongArch: NFC: Deduplicate crc instruction defines

LGTM! Thanks! 在 2024/2/26 下午12:28, Xi Ruoyao 写道: Introduce an iterator for UNSPEC_CRC and UNSPEC_CRCC to make the next change easier. gcc/ChangeLog: * config/loongarch/loongarch.md (CRC): New define_int_iterator. (crc): New define_int_attr. (loongarch_crc_w__w,

Re: [PATCH]middle-end: update vuses out of loop which use a vdef that's moved [PR114068]

On Fri, 23 Feb 2024, Tamar Christina wrote: > Hi All, > > In certain cases we can have a situation where the merge block has a vUSE > virtual PHI and the exits do not. In this case for instance the exits lead > to an abort so they have no virtual PHIs. If we have a store before the first >

[COMMITTED] testsuite: Fix gcc.dg/attr-weakref-1.c on Solaris/x86 with as [PR70582]

gcc.dg/attr-weakref-1.c FAILs on 32 and 64-bit Solaris/x86 with the native assembler: FAIL: gcc.dg/attr-weakref-1.c (test for excess errors) UNRESOLVED: gcc.dg/attr-weakref-1.c compilation failed to produce executable Excess errors: Assembler: attr-weakref-1.c "/var/tmp//ccUSaysF.s",

[COMMITTED] testsuite: xfail gcc.c-torture/compile/pr61159.c on Solaris/x86 with as [PR61159]

gcc.c-torture/compile/pr61159.c currently FAILs on 32 and 64-bit Solaris/x86 with the native assembler: FAIL: gcc.c-torture/compile/pr61159.c -O0 (test for excess errors) FAIL: gcc.c-torture/compile/pr61159.c -O1 (test for excess errors) FAIL: gcc.c-torture/compile/pr61159.c -O2 (test

Re: Patch ping^2

On Mon, Feb 26, 2024 at 10:33 AM Jakub Jelinek wrote: > > Hi! > > I'd like to ping 2 patches: > https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645326.html > i386: Enable _BitInt support on ia32 > > all the FAILs mentioned in that mail have been fixed by now. LGTM, based on HJ's advice.

Patch ping^2

Hi! I'd like to ping 2 patches: https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644580.html PR113617 P1 - Handle private COMDAT function symbol reference in readonly data

Re: [wwwdocs] Add Ada's GCC 14 changelog entry

Fernando Oleo Blanco writes: > Dear all, > > just like last year, I would like to commit the changes that took place > over at GNAT for GCC v14. The patch is attached to the email. Hopefully > it is good enough to just be added to master. If you see something wrong > or if you would like to

Re: [PATCH v2] Do not emulate vectors containing floats.

On Mon, 26 Feb 2024, Jakub Jelinek wrote: > On Mon, Feb 26, 2024 at 09:53:41AM +0100, Richard Biener wrote: > > On Mon, 26 Feb 2024, Jakub Jelinek wrote: > > > > > On Mon, Feb 26, 2024 at 09:00:58AM +0100, Richard Biener wrote: > > > > > > @@ -6756,7 +6756,8 @@ vectorizable_operation (vec_info

Re: [PATCH v2] Do not emulate vectors containing floats.

On Mon, Feb 26, 2024 at 09:53:41AM +0100, Richard Biener wrote: > On Mon, 26 Feb 2024, Jakub Jelinek wrote: > > > On Mon, Feb 26, 2024 at 09:00:58AM +0100, Richard Biener wrote: > > > > > @@ -6756,7 +6756,8 @@ vectorizable_operation (vec_info *vinfo, > > > > >those through even when the

Re: [PATCH v2] Do not emulate vectors containing floats.

On Mon, 26 Feb 2024, Jakub Jelinek wrote: > On Mon, Feb 26, 2024 at 09:00:58AM +0100, Richard Biener wrote: > > > > @@ -6756,7 +6756,8 @@ vectorizable_operation (vec_info *vinfo, > > > > those through even when the mode isn't word_mode. For > > > > ops we have to lower the

Re: [PATCH v2] Do not emulate vectors containing floats.

On Mon, Feb 26, 2024 at 09:00:58AM +0100, Richard Biener wrote: > > > @@ -6756,7 +6756,8 @@ vectorizable_operation (vec_info *vinfo, > > >those through even when the mode isn't word_mode. For > > >ops we have to lower the lowering code assumes we are > > >dealing with word_mode. */ >

Re: [PATCH v2] x86: Check interrupt instead of noreturn attribute

On Sun, Feb 25, 2024 at 10:14 PM H.J. Lu wrote: > > ix86_set_func_type checks noreturn attribute to avoid incompatible > attribute error in LTO1 on interrupt functions. Since TREE_THIS_VOLATILE > is set also for _Noreturn without noreturn attribute, check interrupt > attribute for interrupt

Re: [PATCH v1 05/13] Reuse MinGW from i386 for AArch64

On Sun, 25 Feb 2024 at 22:12, Mark Harmstone wrote: > Also, there are relocation types needed for Windows programs that are > supported in COFF but not in ELF object files. > Right, it's been a long time since i last dealt with PECOFF and i had assumed that things might have changed in the

Re: [PATCH] match.pd: Guard 2 simplifications on integral TYPE_OVERFLOW_UNDEFINED [PR114090]

On Mon, 26 Feb 2024, Jakub Jelinek wrote: > Hi! > > These 2 patterns are incorrect on floating point, or for -fwrapv, or > for -ftrapv, or the first one for unsigned types (the second one is > mathematically correct, but we ought to just fold that to 0 instead). > > So, the following patch

Re: [PATCH] fold-const: Avoid infinite recursion in +-*&|^minmax reassociation [PR114084]

On Mon, 26 Feb 2024, Jakub Jelinek wrote: > Hi! > > In the following testcase we infinitely recurse during BIT_IOR_EXPR > reassociation. > One operand is (unsigned _BitInt(31)) a << 4 and another operand > 2147483647 >> 1 | 80 where both the right shift and the | 80 > trees have TREE_CONSTANT

Re: [PATCH v2] Do not emulate vectors containing floats.

On Fri, 23 Feb 2024, Jakub Jelinek wrote: > On Fri, Feb 23, 2024 at 02:43:45PM +0100, Juergen Christ wrote: > > The emulation via word mode tries to perform integer arithmetic on floating > > point values instead of floating point arithmetic. This leads to > > mis-compilations. > > > > Failure