Re: [Fortran, Patch, PR 96992] Fix Class arrays of different ranks are rejected as storage association argument

Hi Harald, thank you for the investigation and useful tips. I had to figure what went wrong here, but I now figured, that the array needs repacking when a negative stride is used (or at least a call to that routine, which then fixes "stuff"). I have added it, freeing the memory allocated potential

Re: [PATCH] Fortran: fix for CHARACTER(len=*) dummies with bind(C) [PR115390]

Hi Harald, that patch looks quite obvious to me. Therefore ok for mainline by me. Thanks for the patch. Regards, Andre On Tue, 18 Jun 2024 22:10:55 +0200 Harald Anlauf wrote: > Dear all, > > the attached simple patch fixes warnings for use of uninitialized > temporaries for the string

Re: [C PATCH] Fix ICE related to incomplete structures in C23 [PR114930,PR115502].

Am Mittwoch, dem 19.06.2024 um 08:57 +0200 schrieb Richard Biener: > On Wed, 19 Jun 2024, Martin Uecker wrote: > > > Am Mittwoch, dem 19.06.2024 um 08:04 +0200 schrieb Richard Biener: > > > > > > > Am 18.06.2024 um 20:18 schrieb Martin Uecker : > > > > > > > > Am Dienstag, dem 18.06.2024 um 17:

Re: [Patch, rs6000, middle-end] v2: Add implementation for different targets for pair mem fusion

Hello Richard: On 19/06/24 2:01 am, Richard Sandiford wrote: > Ajit Agarwal writes: >> Hello Richard: >> >> On 14/06/24 4:26 pm, Richard Sandiford wrote: >>> Ajit Agarwal writes: Hello Richard: All comments are addressed. >>> >>> I don't think this addresses the following comments

Re: [PATCH v4] rs6000: Fix incorrect RTL for Power LE when removing the UNSPECS [PR106069]

on 2024/6/19 03:02, Peter Bergner wrote: > On 6/12/24 2:50 AM, Kewen.Lin wrote: >> As the recent PR115355 shows, this issue can also affect the >> behavior when users are adopting vectorization optimization, >> IMHO we should get this landed as soon as possible. > > I agree we want this fixed ASAP

Re: [PATCH v4] rs6000: Fix incorrect RTL for Power LE when removing the UNSPECS [PR106069]

Hi Segher, on 2024/6/19 04:31, Segher Boessenkool wrote: > On Fri, Feb 10, 2023 at 10:59:52AM +0800, Xionghu Luo via Gcc-patches wrote: > So, nothing here is obvious at all still. Could you please split it up > a bit more, so that every step is either small or simple? I just chatted with Xionghu

Re: [C PATCH] Fix ICE related to incomplete structures in C23 [PR114930,PR115502].

On Wed, 19 Jun 2024, Martin Uecker wrote: > Am Mittwoch, dem 19.06.2024 um 08:57 +0200 schrieb Richard Biener: > > On Wed, 19 Jun 2024, Martin Uecker wrote: > > > > > Am Mittwoch, dem 19.06.2024 um 08:04 +0200 schrieb Richard Biener: > > > > > > > > > Am 18.06.2024 um 20:18 schrieb Martin Uecker

RE: [PATCH v1] Match: Support more forms for the scalar unsigned .SAT_SUB

Hi Richard, Given almost all unsigned SAT_ADD/SAT_SUB patches are merged, I revisit the original code pattern aka zip benchmark. It may look like below: void test (uint16_t *x, uint16_t *y, unsigned wsize, unsigned count) { unsigned m = 0, n = count; register uint16_t *p; p = x; do {

Re: [C PATCH] Fix ICE related to incomplete structures in C23 [PR114930,PR115502].

On Wed, Jun 19, 2024 at 09:26:00AM +0200, Martin Uecker wrote: > Ok. Then should it, instead of > > TYPE_CANONICAL (x) > = build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS (x)); > > be > > tree c = build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS (x)); > TYPE_CANONICAL (x) = TREE

Re: [C PATCH] Fix ICE related to incomplete structures in C23 [PR114930,PR115502].

On Wed, Jun 19, 2024 at 09:36:40AM +0200, Richard Biener wrote: > > TYPE_CANONICAL (x) > > = build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS (x)); > > That looks indeed weird. What are the constraints on 't' for > c_update_type_canonical? If it is TYPE_STRUCTURAL_EQUALITY_P > the ab

Re: [Patch, rs6000, middle-end] v2: Add implementation for different targets for pair mem fusion

Hello Richard: On 19/06/24 12:52 pm, Ajit Agarwal wrote: > Hello Richard: > > On 19/06/24 2:01 am, Richard Sandiford wrote: >> Ajit Agarwal writes: >>> Hello Richard: >>> >>> On 14/06/24 4:26 pm, Richard Sandiford wrote: Ajit Agarwal writes: > Hello Richard: > > All comments ar

Re: [PATCH v1] Match: Support more forms for the scalar unsigned .SAT_SUB

On Wed, Jun 19, 2024 at 9:37 AM Li, Pan2 wrote: > > Hi Richard, > > Given almost all unsigned SAT_ADD/SAT_SUB patches are merged, I revisit the > original code pattern aka zip benchmark. > It may look like below: > > void test (uint16_t *x, uint16_t *y, unsigned wsize, unsigned count) > { > uns

Re: [PATCH v2] xtensa: constantsynth: Reforge to fix some non-fatal issues

On Tue, Jun 18, 2024 at 7:56 PM Takayuki 'January June' Suwa wrote: > > The previous constant synthesis logic had some issues that were non-fatal > but worth considering: > > - It didn't work with DFmode literals, because those were cast to SImode >rather SFmode when splitting into two natural

Re: [Patch, rs6000, middle-end] v2: Add implementation for different targets for pair mem fusion

Ajit Agarwal writes: >> What happens if you leave the assert alone? When does it fire? Is it >> still for uses in debug insns? If so, it's the fusion pass's responsibility >> to update those, as mentioned above. And it must update them before, >> or at the same time as, it deletes the definiti

Re: [Patch, rs6000, middle-end] v2: Add implementation for different targets for pair mem fusion

Hello Richard: On 19/06/24 1:54 pm, Richard Sandiford wrote: > Ajit Agarwal writes: >>> What happens if you leave the assert alone? When does it fire? Is it >>> still for uses in debug insns? If so, it's the fusion pass's responsibility >>> to update those, as mentioned above. And it must upd

Re: [Patch, rs6000, middle-end] v2: Add implementation for different targets for pair mem fusion

Ajit Agarwal writes: > Hello Richard: > > On 19/06/24 1:54 pm, Richard Sandiford wrote: >> Ajit Agarwal writes: What happens if you leave the assert alone? When does it fire? Is it still for uses in debug insns? If so, it's the fusion pass's responsibility to update those,

Re: [Patch, rs6000, middle-end] v2: Add implementation for different targets for pair mem fusion

Hello Richard: On 19/06/24 2:40 pm, Richard Sandiford wrote: > Ajit Agarwal writes: >> Hello Richard: >> >> On 19/06/24 1:54 pm, Richard Sandiford wrote: >>> Ajit Agarwal writes: > What happens if you leave the assert alone? When does it fire? Is it > still for uses in debug insns? If

Re: [Patch, rs6000, middle-end] v2: Add implementation for different targets for pair mem fusion

Ajit Agarwal writes: > On 19/06/24 2:40 pm, Richard Sandiford wrote: >> Ajit Agarwal writes: >>> Hello Richard: >>> >>> On 19/06/24 1:54 pm, Richard Sandiford wrote: Ajit Agarwal writes: >> What happens if you leave the assert alone? When does it fire? Is it >> still for uses in d

Re: [Patch, Fortran, 90076] 1/3 Fix Polymorphic Allocate on Assignment Memory Leak

Hi Paul, thanks for the review. Committed as: gcc-15-1434-gdbb718175d7 Please take a look at the other two merge request or tell me that you have no time, then I ping them to hopefully get some one else to take a look. Thanks again for the review. Regards, Andre On Mon, 17 Jun 2024 06:

Re: [Patch, rs6000, middle-end] v2: Add implementation for different targets for pair mem fusion

Hello Richard: On 19/06/24 2:52 pm, Richard Sandiford wrote: > Ajit Agarwal writes: >> On 19/06/24 2:40 pm, Richard Sandiford wrote: >>> Ajit Agarwal writes: Hello Richard: On 19/06/24 1:54 pm, Richard Sandiford wrote: > Ajit Agarwal writes: >>> What happens if you leave

[PATCH] Improve gcc.dg/vect/bb-slp-32.c testcase

The following adds a correctness check to the combined store/reduce vectorization. Tested on x86_64-unknown-linux-gnu, pushed. * gcc.dg/vect/bb-slp-32.c: Add check for correctness. --- gcc/testsuite/gcc.dg/vect/bb-slp-32.c | 26 -- 1 file changed, 20 insertions(+)

Re: [Patch, rs6000, middle-end] v2: Add implementation for different targets for pair mem fusion

Ajit Agarwal writes: > On 19/06/24 2:52 pm, Richard Sandiford wrote: >> Ajit Agarwal writes: >>> On 19/06/24 2:40 pm, Richard Sandiford wrote: Ajit Agarwal writes: > Hello Richard: > > On 19/06/24 1:54 pm, Richard Sandiford wrote: >> Ajit Agarwal writes: What happe

Re: [PATCH][ivopts]: use affine_tree when comparing IVs during candidate selection [PR114932]

On Fri, 14 Jun 2024, Tamar Christina wrote: > Hi All, > > IVOPTS normally uses affine trees to perform comparisons between different > IVs, > but these seem to have been missing in two key spots and instead normal tree > equivalencies used. > > In some cases where we have a structural equivalen

Re: [PATCH][ivopts]: perform affine fold on unsigned addressing modes known not to overflow. [PR114932]

On Fri, 14 Jun 2024, Tamar Christina wrote: > Hi All, > > When the patch for PR114074 was applied we saw a good boost in exchange2. > > This boost was partially caused by a simplification of the addressing modes. > With the patch applied IV opts saw the following form for the base addressing; >

Re: [PATCH v2] ARM: thumb1: Use LDMIA/STMIA for DI/DF loads/stores

On 18/06/2024 19:14, Siarhei Volkau wrote: > If the address register is dead after load/store operation it looks > beneficial to use LDMIA/STMIA instead of pair of LDR/STR instructions, > at least if optimizing for size. > > Changes v1 -> v2: > - switching to peephole2 approach > - added test ca

[PATCH] tree-optimization/114413 - SLP CSE after permute optimization

We currently fail to re-CSE SLP nodes after optimizing permutes which results in off cost estimates. For gcc.dg/vect/bb-slp-32.c this shows in not re-using the SLP node with the load and arithmetic for both the store and the reduction. The following implements CSE by re-bst-mapping nodes as final

[PATCH v2] RISC-V: Remove float vector eqne pattern

We can unify eqne and other comparison operations. Tested on RV32 and RV64 gcc/ChangeLog: * config/riscv/riscv-vector-builtins-bases.cc: Remove eqne cond * config/riscv/vector.md (@pred_eqne_scalar): Remove patterns (*pred_eqne_scalar_merge_tie_mask): Ditto (*pred

Re: [PATH 1/8] vect: Add a function to check lane-reducing stmt

On Sun, Jun 16, 2024 at 9:21 AM Feng Xue OS wrote: > > The series of patches are meant to support multiple lane-reducing reduction > statements. Since the original ones conflicted with the new single-lane slp > node patches, I have reworked most of the patches, and split them as small as > poss

Re: [PATCH 2/8] vect: Remove duplicated check on reduction operand

On Sun, Jun 16, 2024 at 9:22 AM Feng Xue OS wrote: > > In vectorizable_reduction, one check on a reduction operand via index could be > contained by another one check via pointer, so remove the former. OK. Thanks, Richard. > Thanks, > Feng > > --- > gcc/ > * tree-vect-loop.cc (vectoriza

Re: [PATCH 3/8] vect: Use one reduction_type local variable

On Sun, Jun 16, 2024 at 9:23 AM Feng Xue OS wrote: > > Two local variables were defined to refer same STMT_VINFO_REDUC_TYPE, better > to keep only one. OK. Richard. > Thanks, > Feng > > --- > gcc/ > * tree-vect-loop.cc (vectorizable_reduction): Remove v_reduc_type, and > replace

[PATCH V2] rs6000: load high and low part of 128bit vector independently [PR110040]

Hi All, Updated the patch based on review comments. This patch passed bootstrap and regression testing on powerpc64le-linux with no regressions. PR110040 exposes an issue concerning moves from vector registers to GPRs. There are two moves, one for upper 64 bits and the other for the lower 64 bits

Re: [PATCH 0/2] arm, doloop: Add support for MVE Tail-Predicated Low Overhead Loops

On 23/05/2024 15:37, Andre Vieira wrote: > > Hi, > > We held these two patches back in stage 4 because they touched > target-agnostic code, though I am quite confident they will not affect other > targets. Given stage one has reopened, I am reposting them, I rebased them > but they seem to a

Re: [PING^3][PATCH v2] rs6000: Fix issue in specifying PTImode as an attribute [PR106895]

Ping! Please review. Are there any more changes required? Thanks & Regards Jeevitha On 21/05/24 10:28 am, jeevitha wrote: > Ping! > > please review. > > Thanks & Regards > Jeevitha > > > On 17/04/24 2:44 pm, jeevitha wrote: >> Ping! >> >> I've incorporated all the suggested changes. Please r

Re: [PATCH] tree-optimization/114413 - SLP CSE after permute optimization

Richard Biener writes: > We currently fail to re-CSE SLP nodes after optimizing permutes > which results in off cost estimates. For gcc.dg/vect/bb-slp-32.c > this shows in not re-using the SLP node with the load and arithmetic > for both the store and the reduction. The following implements > CS

Re: [PATCH v2] Arm: Fix ldrd offset range [PR115153]

On 11/06/2024 17:42, Wilco Dijkstra wrote: > v2: use a new arm_arch_v7ve_neon, fix use of DImode in output_move_neon > > The valid offset range of LDRD in arm_legitimate_index_p is increased to > -1024..1020 if NEON is enabled since VALID_NEON_DREG_MODE includes DImode. > Fix this by moving the LD

Re: [PATCH 4/8] vect: Determine input vectype for multiple lane-reducing

On Sun, Jun 16, 2024 at 9:25 AM Feng Xue OS wrote: > > The input vectype of reduction PHI statement must be determined before > vect cost computation for the reduction. Since lance-reducing operation has > different input vectype from normal one, so we need to traverse all reduction > statements t

Re: [PATCH 6/8] vect: Tighten an assertion for lane-reducing in transform

On Sun, Jun 16, 2024 at 9:28 AM Feng Xue OS wrote: > > According to logic of code nearby the assertion, all lane-reducing operations > should not appear, not just DOT_PROD_EXPR. Since "use_mask_by_cond_expr_p" > treats SAD_EXPR same as DOT_PROD_EXPR, and WIDEN_SUM_EXPR should not be > allowed > b

Re: [PATCH 5/8] vect: Use an array to replace 3 relevant variables

On Sun, Jun 16, 2024 at 9:27 AM Feng Xue OS wrote: > > It's better to place 3 relevant independent variables into array, since we > have requirement to access them via an index in the following patch. At the > same time, this change may get some duplicated code be more compact. OK. I might have

Re: [PATCH] tree-optimization/114413 - SLP CSE after permute optimization

On Wed, 19 Jun 2024, Richard Sandiford wrote: > Richard Biener writes: > > We currently fail to re-CSE SLP nodes after optimizing permutes > > which results in off cost estimates. For gcc.dg/vect/bb-slp-32.c > > this shows in not re-using the SLP node with the load and arithmetic > > for both th

[committed] libstdc++: Fix warning regressions in

Tested x86_64-linux. Pushed to trunk. -- >8 -- I caused some new warnings with -Wsystem-headers with my recent changes to std::get_temporary_buffer and std::_Temporary_buffer. There's a -Wsign-compare warning which can be avoided by casting the ptrdiff_t argument to size_t (which also convenientl

Re: [PATCH] tree-optimization/114413 - SLP CSE after permute optimization

Richard Biener writes: > On Wed, 19 Jun 2024, Richard Sandiford wrote: > >> Richard Biener writes: >> > We currently fail to re-CSE SLP nodes after optimizing permutes >> > which results in off cost estimates. For gcc.dg/vect/bb-slp-32.c >> > this shows in not re-using the SLP node with the load

[PATCH v1 1/8] RISC-V: Add testcases for unsigned .SAT_SUB vector form 3

From: Pan Li After the middle-end support the form 3 of unsigned SAT_SUB and the RISC-V backend implement the .SAT_SUB for vector mode, thus add more test case to cover that. Form 3: #define DEF_VEC_SAT_U_SUB_FMT_3(T) \ void __attribute__((noinline))

[PATCH v1 2/8] RISC-V: Add testcases for unsigned .SAT_SUB vector form 4

From: Pan Li After the middle-end support the form 4 of unsigned SAT_SUB and the RISC-V backend implement the .SAT_SUB for vector mode, thus add more test case to cover that. Form 4: #define DEF_VEC_SAT_U_SUB_FMT_4(T) \ void __attribute__((noinline))

[PATCH v1 6/8] RISC-V: Add testcases for unsigned .SAT_SUB vector form 8

From: Pan Li After the middle-end support the form 8 of unsigned SAT_SUB and the RISC-V backend implement the .SAT_SUB for vector mode, thus add more test case to cover that. Form 8: #define DEF_VEC_SAT_U_SUB_FMT_8(T) \ void __attribute__((noinline))

[PATCH v1 3/8] RISC-V: Add testcases for unsigned .SAT_SUB vector form 5

From: Pan Li After the middle-end support the form 5 of unsigned SAT_SUB and the RISC-V backend implement the .SAT_SUB for vector mode, thus add more test case to cover that. Form 5: #define DEF_VEC_SAT_U_SUB_FMT_5(T) \ void __attribute__((noinline))

[PATCH v1 7/8] RISC-V: Add testcases for unsigned .SAT_SUB vector form 9

From: Pan Li After the middle-end support the form 9 of unsigned SAT_SUB and the RISC-V backend implement the .SAT_SUB for vector mode, thus add more test case to cover that. Form 9: #define DEF_VEC_SAT_U_SUB_FMT_9(T) \ void __attribute__((noinline))

[PATCH v1 4/8] RISC-V: Add testcases for unsigned .SAT_SUB vector form 6

From: Pan Li After the middle-end support the form 6 of unsigned SAT_SUB and the RISC-V backend implement the .SAT_SUB for vector mode, thus add more test case to cover that. Form 6: #define DEF_VEC_SAT_U_SUB_FMT_6(T) \ void __attribute__((noinline))

[PATCH v1 8/8] RISC-V: Add testcases for unsigned .SAT_SUB vector form 10

From: Pan Li After the middle-end support the form 10 of unsigned SAT_SUB and the RISC-V backend implement the .SAT_SUB for vector mode, thus add more test case to cover that. Form 10: #define DEF_VEC_SAT_U_SUB_FMT_10(T) \ void __attribute__((noinline))

Re: [PATCH v1 1/8] RISC-V: Add testcases for unsigned .SAT_SUB vector form 3

lgtm --Reply to Message-- On Wed, Jun 19, 2024 21:17 PM pan2.li

[PATCH v1 5/8] RISC-V: Add testcases for unsigned .SAT_SUB vector form 7

From: Pan Li After the middle-end support the form 7 of unsigned SAT_SUB and the RISC-V backend implement the .SAT_SUB for vector mode, thus add more test case to cover that. Form 7: #define DEF_VEC_SAT_U_SUB_FMT_7(T) \ void __attribute__((noinline))

Re: [PATCH v1 2/8] RISC-V: Add testcases for unsigned .SAT_SUB vector form 4

lgtm --Reply to Message-- On Wed, Jun 19, 2024 21:17 PM pan2.li

Re: [PATCH v1 6/8] RISC-V: Add testcases for unsigned .SAT_SUB vector form 8

lgtm --Reply to Message-- On Wed, Jun 19, 2024 21:17 PM pan2.li

Re: [PATCH v1 3/8] RISC-V: Add testcases for unsigned .SAT_SUB vector form 5

lgtm --Reply to Message-- On Wed, Jun 19, 2024 21:17 PM pan2.li

Re: [PATCH v1 4/8] RISC-V: Add testcases for unsigned .SAT_SUB vector form 6

lgtm --Reply to Message-- On Wed, Jun 19, 2024 21:17 PM pan2.li

Re: [PATCH v1 7/8] RISC-V: Add testcases for unsigned .SAT_SUB vector form 9

lgtm --Reply to Message-- On Wed, Jun 19, 2024 21:17 PM pan2.li

Re: [PATCH v1 8/8] RISC-V: Add testcases for unsigned .SAT_SUB vector form 10

lgtm --Reply to Message-- On Wed, Jun 19, 2024 21:17 PM pan2.li

Re: [PATCH v1 5/8] RISC-V: Add testcases for unsigned .SAT_SUB vector form 7

lgtm --Reply to Message-- On Wed, Jun 19, 2024 21:17 PM pan2.li

RE: [PATCH][ivopts]: perform affine fold on unsigned addressing modes known not to overflow. [PR114932]

> -Original Message- > From: Richard Biener > Sent: Wednesday, June 19, 2024 1:14 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; bin.ch...@linux.alibaba.com > Subject: Re: [PATCH][ivopts]: perform affine fold on unsigned addressing modes > known not to overflow. [PR114932] >

Re: [PATCH v4] RISC-V: Promote Zaamo/Zalrsc to a when using an old binutils

LGTM :) Patrick O'Neill 於 2024年6月19日 週三 05:40 寫道： > Binutils 2.42 and before don't support Zaamo/Zalrsc. When users specify > both Zaamo and Zalrsc, promote them to 'a' in the -march string. > > This does not affect testsuite results for users with old versions of > binutils. > Testcases that fa

Re: [PATCH v2] RISC-V: Remove float vector eqne pattern

lgtm from my side but plz wait for robin the last review. thanks. --Reply to Message-- On Wed, Jun 19, 2024 20:30 PM demin.han

RE: [PATCH v1 1/8] RISC-V: Add testcases for unsigned .SAT_SUB vector form 3

Committed the series, thanks Juzhe. Pan From: 钟居哲 Sent: Wednesday, June 19, 2024 9:20 PM To: Li, Pan2 ; gcc-patches Cc: kito.cheng ; jeffreyalaw ; rdapp.gcc ; Li, Pan2 Subject: Re: [PATCH v1 1/8] RISC-V: Add testcases for unsigned .SAT_SUB vector form 3 lgtm --Reply to Message---

RE: [PATCH v1] Match: Support more forms for the scalar unsigned .SAT_SUB

Got it. Thanks Richard for suggestion. Pan -Original Message- From: Richard Biener Sent: Wednesday, June 19, 2024 4:00 PM To: Li, Pan2 Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@gmail.com; jeffreya...@gmail.com; rdapp@gmail.com Subject: Re: [PATCH v1] Match: Sup

[PATCH] c++: implement DR1363 and DR1496 for __is_trivial [PR85723]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- is_trivial was introduced in which split POD into is_trivial and is_standard_layout. Later came CWG 1363. Since struct A { A() = default; A(int =

[PATCH] gcc/doc: adjust __builtin_choose_expr() description

Present wording has misled people to believe the ?: operator would be evaluating all three of the involved expressions. gcc/ * doc/extend.texi: Clarify __builtin_choose_expr() similarity to the ?: operator. --- a/gcc/doc/extend.texi +++ b/gcc/doc/extend.texi @@ -14962,9 +14962,9

[to-be-committed] [RISC-V] [PATCH V2] Minor cleanup/improvement to bset/binv patterns

Changes since V1: Whitespace fixes noted by the linter Missed using the iterator for the output template in _mask pattern! -- This patch introduces a bit_optab iterator that maps IOR/XOR to bset and binv (and one day bclr if we need it). That allows us to combine some patterns that onl

RE: [PATCH][ivopts]: use affine_tree when comparing IVs during candidate selection [PR114932]

> -Original Message- > From: Richard Biener > Sent: Wednesday, June 19, 2024 12:55 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; bin.ch...@linux.alibaba.com > Subject: Re: [PATCH][ivopts]: use affine_tree when comparing IVs during > candidate > selection [PR114932] > > On

Re: [RFC/RFA] [PATCH 08/12] Add a new pass for naive CRC loops detection

On Sun, Jun 9, 2024 at 1:48 AM Jeff Law wrote: > > > On 6/4/24 7:41 AM, Mariam Arutunian wrote: > >/Mariam, your thoughts on whether or not those two phases could handle a > > loop with two CRC calculations inside, essentially creating two calls to > > our new builtins? / > > > > / > > / > > > >

Re: [PATCH v2] RISC-V: Remove float vector eqne pattern

OK. Thanks for adding the test. Regards Robin

Re: [PATCH v2] RISC-V: Remove float vector eqne pattern

On 6/19/24 6:30 AM, demin.han wrote: We can unify eqne and other comparison operations. Tested on RV32 and RV64 gcc/ChangeLog: * config/riscv/riscv-vector-builtins-bases.cc: Remove eqne cond * config/riscv/vector.md (@pred_eqne_scalar): Remove patterns (*pred_eqne_sc

Re: [PATCH] middle-end/114070 - folding breaking VEC_COND expansion

Hi, I have found that this patch has introduced a regression in the arm-none-eabi toolchain for a testcase, which was previously passing: PASS->FAIL: gcc.dg/tree-ssa/andnot-2.c scan-tree-dump-not forwprop3 "_expr" The toolchain was built with: Build = x86_64-none-linux-gnu Host = x86_64-none-li

RE: [PATCH][ivopts]: use affine_tree when comparing IVs during candidate selection [PR114932]

Hello, On Wed, 19 Jun 2024, Tamar Christina wrote: > So this is where we compare different IV expressions to determine which > IVs compute the same thing and thus can be in the same group. > > The STRIP_NOPS don't work because while the incoming types are the same > the casts are different. So:

Re: [PATCH] [testsuite] [arm] [vect] adjust mve-vshr test [PR113281]

On 13/06/2024 10:23, Alexandre Oliva wrote: > > The test was too optimistic, alas. We used to vectorize shifts > involving 8-bit and 16-bit integral types by clamping the shift count > at the highest in-range shift count, but that was not correct: such > narrow shifts expect integral promotion, s

RE: [PATCH][ivopts]: use affine_tree when comparing IVs during candidate selection [PR114932]

> -Original Message- > From: Michael Matz > Sent: Wednesday, June 19, 2024 3:46 PM > To: Tamar Christina > Cc: Richard Biener ; gcc-patches@gcc.gnu.org; nd > ; bin.ch...@linux.alibaba.com > Subject: RE: [PATCH][ivopts]: use affine_tree when comparing IVs during > candidate > selection [P

Re: [PATCH v2] ARM: thumb1: Use LDMIA/STMIA for DI/DF loads/stores

ср, 19 июн. 2024 г. в 15:19, Richard Earnshaw (lists) : > > On 18/06/2024 19:14, Siarhei Volkau wrote: > > If the address register is dead after load/store operation it looks > > beneficial to use LDMIA/STMIA instead of pair of LDR/STR instructions, > > at least if optimizing for size. > > > > Chan

Re: [RFC/RFA] [PATCH 06/12] aarch64: Implement new expander for efficient CRC computation

On Sat, Jun 8, 2024 at 3:41 PM Richard Sandiford wrote: > Mariam Arutunian writes: > > This patch introduces two new expanders for the aarch64 backend, > > dedicated to generate optimized code for CRC computations. > > The new expanders are designed to leverage specific hardware capabilities > >

Re: [RFC/RFA] [PATCH 08/12] Add a new pass for naive CRC loops detection

On Sun, Jun 9, 2024 at 2:00 AM Jeff Law wrote: > > > On 5/29/24 5:12 AM, Mariam Arutunian wrote: > > > > > IIRC we looked at the problem of canonicalizing the loop into a form > > where we didn't necessarily have conditional blocks, instead we had > > branchless sequences for the cond

Re: [PATCH v2] ARM: thumb1: Use LDMIA/STMIA for DI/DF loads/stores

On 19/06/2024 16:11, Siarhei Volkau wrote: > ср, 19 июн. 2024 г. в 15:19, Richard Earnshaw (lists) > : >> >> On 18/06/2024 19:14, Siarhei Volkau wrote: >>> If the address register is dead after load/store operation it looks >>> beneficial to use LDMIA/STMIA instead of pair of LDR/STR instructions,

[PATCH] MIPS: Use Reg0 instead of const0_rtx for TRAP

MIPSr6 removes condition trap instructions with imm, so the instruction like `teq $2,imm` will be converted to li $at, imm teq $2, $at The current version of Gas cannot detect if imm is zero, and output teq $2, $0 Let's do it in GCC. gcc * config/mips/mips.cc(mips_expand_conditional

[PATCH ver2] rs6000, altivec-2-runnable.c update the require-effective-target

GCC maintainers: version 2: Updated per the feedback from Peter, Kewen and Segher. Note, Peter suggested the -mdejagnu-cpu= value must be power7. The test fails if -mdejagnu-cpu= is set to power7, needs to be power8. Patch has been retested on a Power 10 box, it succeeds with 2 passes and n

Re: [PATCH ver3] rs6000, altivec-2-runnable.c update the require-effective-target

Everyone, Oops, this should be version 3 not 2. Sorry. Carl On 6/19/24 09:13, Carl Love wrote: > GCC maintainers: > > version 2: Updated per the feedback from Peter, Kewen and Segher. Note, > Peter suggested the -mdejagnu-cpu= value must be power7. > The test fails if -m

[PATCH] rs6000, altivec-1-runnable.c update the require-effective-target

GCC maintainers: The dg options for this test should be the same as for altivec-2-runnable.c. This patch updates the dg options to match the settings in altivec-2-runnable.c. The patch has been tested on Power 10 with no regression failures. Please let me know if this patch is acceptable for

[committed] libstdc++: Add conditional noexcept to std::pair default ctor

Tested x86_64-linux. Pushed to trunk. -- >8 -- Most of std::pair constructors implemented using C++20 concepts have a conditional noexcept-specifier, but the default constructor doesn't. This fixes that. libstdc++-v3/ChangeLog: * include/bits/stl_pair.h [__cpp_lib_concepts] (pair()): Ad

[committed] libstdc++: Add noexcept to some std::promise shared state internals

Tested x86_64-linux. Pushed to trunk. -- >8 -- Making the state ready for a std::promise only needs to move a unique_ptr, which cannot throw. Make its call operator noexcept. Similarly, making the state ready by storing an exception_ptr also can't throw, so make that call operator noexcept too.

[committed] libstdc++: Consistently indent with tabs

Whitespace only. Tested x86_64-linux. Pushed to trunk. -- >8 -- libstdc++-v3/ChangeLog: * include/std/future: Adjust whitespace to use tabs for indentation. --- libstdc++-v3/include/std/future | 328 1 file changed, 164 insertions(+), 164 deletio

[PATCH] libstdc++: Fix std::to_array for trivial-ish types [PR115522]

Tested x86_64-linux. Not pushed yet. backports will be needed too. -- >8 -- Due to PR c++/85723 the std::is_trivial trait is true for types with a deleted default constructor, so the use of std::is_trivial in std::to_array is not sufficient to ensure the type can be trivially default constructed

Re: [gcc r15-1436] build: Fix missing variable quotes

On Wed, 19 Jun 2024, YunQiang Su via Gcc-cvs wrote: > diff --git a/configure b/configure > index 51576a41f303..6e95b27d9df4 100755 > --- a/configure > +++ b/configure > @@ -8994,15 +8994,15 @@ if test "$ac_res" != no; then : > fi > > > -if test $ac_cv_search_dlopen = -ldl; then > +if test "$a

Re: [PATCH] xtensa: Eliminate double MEMW insertions for volatile memory

On Tue, Jun 18, 2024 at 10:00 PM Takayuki 'January June' Suwa wrote: > > This patch makes avoid inserting a MEMW instruction before a load/store > nstruction with volatile memory reference if there is already a MEMW > immediately before it. > > gcc/ChangeLog: > > * config/xtensa/xtensa.cc

[PATCH] MIPS: Implement vcond_mask optabs for MSA

Currently, we have `mips_expand_vec_cond_expr`, which calculate cmp_res first. We can just add a new extra argument to ask it to use operands[3] as cmp_res instead of calculating from operands[4] and operands[5]. gcc * config/mips/mips.cc(mips_expand_vec_cond_expr): Add extra argu

Re: [PATCH] MIPS: Use Reg0 instead of const0_rtx for TRAP

On Wed, 19 Jun 2024, YunQiang Su wrote: > MIPSr6 removes condition trap instructions with imm, so the instruction > like `teq $2,imm` will be converted to > li $at, imm > teq $2, $at > > The current version of Gas cannot detect if imm is zero, and output > teq $2, $0 > Let's do it in GCC.

Re: [C PATCH] Fix ICE related to incomplete structures in C23 [PR114930,PR115502].

On Wed, Jun 19, 2024 at 09:26:00AM +0200, Martin Uecker wrote: > Ok. Then should it, instead of > > TYPE_CANONICAL (x) > = build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS (x)); > > be > > tree c = build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS (x)); > TYPE_CANONICAL (x) = TREE

Welcome to the Chinese WOS, Scopus Journal (Multidisciplinary)

Journal of Hunan University Natural Sciences p{ margin:10px 0; padding:0; } table{ border-collapse:collapse; } h1,h2,h3,h4,h5,h6{ display:block; margin:0; padding:0; } img,a img{ border:0; height:auto; outline:none; text-decoration:none; } body,#bodyTable,#bodyCell{ height:100%; margin:0; pa

Re: [C PATCH] Fix ICE related to incomplete structures in C23 [PR114930,PR115502].

On Wed, Jun 19, 2024 at 07:32:28PM +0200, Jakub Jelinek wrote: > Ok, I've tried that, but that doesn't work, it ICEs on the > pr114574-2.c testcase. The following works on quick testing of dg.exp=pr11[45]*.c but haven't bootstrapped/regtested it yet. 2024-06-19 Jakub Jelinek Martin

Re: [PATCH] [x86_64]: Zhaoxin shijidadao enablement

On Tue, Jun 18, 2024 at 9:21 AM mayshao-oc wrote: > > > > On 5/28/24 14:15, Uros Bizjak wrote: > > > > > > > > On Mon, May 27, 2024 at 10:33 AM MayShao wrote: > >> > >> From: mayshao > >> > >> Hi all: > >> This patch enables -march/-mtune=shijidadao, costs and tunings are > >> set accordin

Re: [PATCH][v2] Enhance if-conversion for automatic arrays

On 6/17/24 16:05, Richard Biener wrote: Automatic arrays that are not address-taken should not be subject to store data races. This applies to OMP SIMD in-branch lowered functions result array which for the testcase otherwise prevents vectorization with SSE and for AVX and AVX512 ends up with s

[PATCH] libcpp: Add support for gnu::base64 #embed parameter

Hi! The following patch adds another extension, gnu::base64. As mentioned in the documentation, this extension is primarily intended for use by the preprocessor, so that for the larger (say 32+ or 64+ bytes long embeds it doesn't have to emit tens of thousands or millions of comma separated string

[PATCH] bitint: Fix up lowering of COMPLEX_EXPR [PR115544]

Hi! We don't really support _Complex _BitInt(N), the only place we use bitint complex types is for the .{ADD,SUB,MUL}_OVERFLOW internal function results and COMPLEX_EXPR in the usual case should be either not present yet because the ifns weren't folded and will be lowered, or optimized into someth

Re: [PATCH][v2] Enhance if-conversion for automatic arrays

> Am 19.06.2024 um 20:25 schrieb Toon Moene : > > On 6/17/24 16:05, Richard Biener wrote: > >> Automatic arrays that are not address-taken should not be subject to >> store data races. This applies to OMP SIMD in-branch lowered >> functions result array which for the testcase otherwise preve

Re: [PATCH] bitint: Fix up lowering of COMPLEX_EXPR [PR115544]

> Am 19.06.2024 um 20:44 schrieb Jakub Jelinek : > > Hi! > > We don't really support _Complex _BitInt(N), the only place we use > bitint complex types is for the .{ADD,SUB,MUL}_OVERFLOW internal function > results and COMPLEX_EXPR in the usual case should be either not present > yet because t

Re: [Fortran, Patch, PR 96992] Fix Class arrays of different ranks are rejected as storage association argument

Hi Andre, Am 19.06.24 um 09:07 schrieb Andre Vehreschild: Hi Harald, thank you for the investigation and useful tips. I had to figure what went wrong here, but I now figured, that the array needs repacking when a negative stride is used (or at least a call to that routine, which then fixes "stu

Re: [PATCH][v2] Enhance if-conversion for automatic arrays

On 6/19/24 21:06, Richard Biener wrote: Am 19.06.2024 um 20:25 schrieb Toon Moene : On 6/17/24 16:05, Richard Biener wrote: Automatic arrays that are not address-taken should not be subject to store data races. This applies to OMP SIMD in-branch lowered functions result array which for th

  1   2   >