Re: [RFC][PATCH] SVE intrinsics: Fold svdiv (svptrue, x, x) to ones

> On 7 Aug 2024, at 15:09, Richard Sandiford wrote: > > External email: Use caution opening links or attachments > > > This has been an active recent discussion on irc. I'll try to summarise > my position there here: > > Ramana Radhakrishnan writes: >>> On 6 Aug 2024, at 4:14 PM, Richard S

Re: [optc-save-gen.awk] Fix streaming of command line options for offloading

> Am 13.08.2024 um 08:37 schrieb Andrew Pinski : > > On Mon, Aug 12, 2024 at 10:36 PM Prathamesh Kulkarni > wrote: >> >> Hi, >> As mentioned in: >> https://gcc.gnu.org/pipermail/gcc/2024-August/244581.html >> >> AArch64 cl_optimization_stream_out streams out target-specific optimization >>

Re: [WG14] Request for document number; _Lengthof

On Tue, Aug 13, 2024 at 01:34:58AM GMT, Alejandro Colomar wrote: > Hi David, I obviously meant Daniel. :-) > > I want to send an updated version of n2529. The original author didn't > respond to my mail, so I'll take over. I've been preparing a GCC patch > set for adding the feature to GCC, a

Re: Re: [PATCH v2 1/1] RISC-V: Support BF16 interfaces in libgcc

On Tue, Aug 13, 2024 at 11:14:47AM +0800, Xiao Zeng wrote: > Thank you very much for the in-depth discussion between Jakub Jelinek and > jeff. > My knowledge is narrow, and I am not familiar with architectures other than > RISCV. > At the same time, my understanding of libraries such as libc and

RE: [PATCH] Re-add calling emit_clobber in lower-subreg.cc's resolve_simple_move.

Hi Xianmiao, I have no objection to reverting that original patch, if it was indeed made obsolete by later changes to the i386 backend. The theory at the time was that it was possible for backends to define mov instructions that emitted clobbers if necessary, but it's very difficult for a backen

Re: [RFC][PATCH] SVE intrinsics: Fold svdiv (svptrue, x, x) to ones

Kyrylo Tkachov writes: >> On 7 Aug 2024, at 15:09, Richard Sandiford wrote: >> Also, gimple sometimes carries assumptions about undefined behaviour, >> such as undefined overflow, whereas the intrinsics are defined to behave >> in the same way as the underlying instructions. For example, INT_MIN

[COMMITTED] Regenerate avr.opt.urls

avr added an -mlra option, but the avr.opt.url file wasn't regenerated. Note that commit 149a23ee2568 ("AVR: -mlra is not documeted in TEXI.") did add the Undocumented flag, but that still needs the avr.op.urls file to be updated. Fixes: 09a87ea666b2 ("AVR: ad target/113934 - Add option -mlra to

Re: [committed][rtl-optimization/116244] Don't create bogus regs in alter_subreg

Jeff Law writes: > On 8/12/24 4:02 PM, Richard Sandiford wrote: >> Jeff Law writes: >>> On 8/12/24 1:49 PM, Richard Sandiford wrote: >>> > > - regno = subreg_regno (x); > + /* A paradoxical should always be REGNO (y) + 0. Using subreg_regno > + for something like (su

Re: [PATCH v2] Internal-fn: Handle vector bool type for type strict match mode [PR116103]

"Li, Pan2" writes: > Hi Richard S, > > Please feel free to let me know if there is any further comments in v2. > Thanks a lot. Looks good to me too. Sorry, didn't realise you were waiting for a second ack. Thanks, Richard > > Pan > > > -Original Message- > From: Li, Pan2 > Sent: Thur

Re: [PATCH/RFC] LRA: Don't emit move for substituted CONSTATNT_P operand [PR116170]

on 2024/8/12 21:05, Vladimir Makarov wrote: > On 8/11/24 21: 50, Kewen. Lin wrote: diff --git a/gcc/lra-constraints. cc > b/gcc/lra-constraints. cc index 92b343fa99a. . f355c6c6168 100644 --- > a/gcc/lra-constraints. cc +++ b/gcc/lra-constraints. cc @@ -4742,7 +4742,9 @@ > curr_insn_transform (b

[PATCH 1/2] rs6000: Fix vsx_le_perm_store_* splitters for !reload_completed

Hi, For vsx_le_perm_store_* we have two splitters, one is for !reload_completed and the other is for reload_completed. As Richard pointed out in [1], operand 1 here is a pure input for DF and most passes, but it could be used as the vector rotation (64 bit) destination of itself, so we re-compute

Re: [patch, fortran] First part of Fortran's unsigned implementation

Hi Thomas, may I ask you to run contrib/check_GNU_style.py on your patch? At least on my system more than lines 50 are reported. I am drawn to this style issues and find it hard to digest the beef of the patch. That's my personal OCD unfortunately. Furthermore (Sorry, I inserted your w/o cite and

[PATCH 2/2] rs6000: Remove "+" constraint modifier from *vsx_le_perm_store_* insns

Hi, Since *vsx_le_perm_store_* can be split into vector permute and vector store, after reload_completed, we reuse the operand 1 as the destination of vector permute, so we set operand 1 with constraint modifier "+". But since it's taken as pure input in DF and most passes as Richard pointed out

Re: [PATCH/RFC] LRA: Don't emit move for substituted CONSTATNT_P operand [PR116170]

on 2024/8/12 21:02, Richard Sandiford wrote: > "Kewen.Lin" writes: >> Hi Richard, >> >> Thanks for the comments! >> >> on 2024/8/12 16:55, Richard Sandiford wrote: >>> "Kewen.Lin" writes: Hi, Commit r15-2084 exposes one ICE in LRA. Firstly, before r15-2084 KFmode has 126 bit

Re: [PATCH/RFC] LRA: Don't emit move for substituted CONSTATNT_P operand [PR116170]

"Kewen.Lin" writes: > on 2024/8/12 21:02, Richard Sandiford wrote: >> "Kewen.Lin" writes: >>> Hi Richard, >>> >>> Thanks for the comments! >>> >>> on 2024/8/12 16:55, Richard Sandiford wrote: "Kewen.Lin" writes: > Hi, > > Commit r15-2084 exposes one ICE in LRA. Firstly, before

[Fortran, Patch, PR116292, v1] Fix 15-regression in move_alloc

Hi all, attached patch fixes a regression introduced by my previous patch on handling _vptr's more consistently. The patch gets the _vptr only of a derived or class type now and not of every type. Regression tested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline? Regards, Andre P

RE: [PATCH v2] Internal-fn: Handle vector bool type for type strict match mode [PR116103]

> Looks good to me too. Sorry, didn't realise you were waiting for a second > ack. Never mind, thanks Richard S for confirmation and suggestions. Pan -Original Message- From: Richard Sandiford Sent: Tuesday, August 13, 2024 5:25 PM To: Li, Pan2 Cc: gcc-patches@gcc.gnu.org; juzhe.zh.

[PATCH] testsuite: Avoid running neon test on Cortex-M55

Ok for trunk and releases/gcc-14? -- Cortex-M55 supports VFP, but does not contain neon, so the test is invalid in this context. Without this patch, the following error can be seen in the logs: .../attr-neon-builtin-fail2.c: In function 'foo': .../attr-neon-builtin-fail2.c:13:27: error: implici

Re: [Fortran, Patch, PR116292, v1] Fix 15-regression in move_alloc

Hi Andre, attached patch fixes a regression introduced by my previous patch on handling _vptr's more consistently. The patch gets the _vptr only of a derived or class type now and not of every type. Regression tested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline? OK (and looks obviou

[PATCH] ifcvt: Fix force_operand ICE due to noce_convert_multiple_sets [PR116353]

Now that more operations are allowed for noce_convert_multiple_sets, we need to check noce_can_force_operand on the sequence before calling try_emit_cmove_seq. Otherwise an inappropriate argument may be given to copy_to_mode_reg and result in an ICE. Fix-up for the recent ifcvt commit 72c9b5f438f2

[PATCH V2 02/10] autovectorizer: Add basic support for convert optabs

Given the shift from modeling dot products as direct optabs to treating them as conversion optabs, we make necessary changes to the autovectorizer code to ensure that given the relevant tree code, together with the input and output data modes, we can retrieve the relevant optab and subsequently the

[PATCH V2 01/10] optabs: Make all `*dot_prod_optab's modeled as conversions

Given the specification in the GCC internals manual defines the {u|s}dot_prod standard name as taking "two signed elements of the same mode, adding them to a third operand of wider mode", there is currently ambiguity in the relationship between the mode of the first two arguments and that of the th

[PATCH V2 03/10] aarch64: Fix aarch64 backend-use of (u|s|us)dot_prod patterns

Given recent changes to the dot_prod standard pattern name, this patch fixes the aarch64 back-end by implementing the following changes: 1. Add 2nd mode to all (u|s|us)dot_prod patterns in .md files. 2. Rewrite initialization and function expansion mechanism for simd builtins. 3. Fix all direct ca

[PATCH V2 09/10] c6x: Adjust dot-product backend patterns

Following the migration of the dot_prod optab from a direct to a conversion-type optab, ensure all back-end patterns incorporate the second machine mode into pattern names. gcc/ChangeLog: * config/c6x/c6x.md (sdot_prodv2hi): Renamed to... (sdot_prodsiv2hi): ...this. --- gcc/confi

[PATCH V2 06/10] arc: Adjust dot-product backend patterns

Following the migration of the dot_prod optab from a direct to a conversion-type optab, ensure all back-end patterns incorporate the second machine mode into pattern names. gcc/ChangeLog: * config/arc/simdext.md (sdot_prodv2hi): Renamed to... (sdot_prodsiv2hi): ...this. (u

[PATCH V2 00/10] optabs: Make all `*dot_prod_optab's modeled as conversions

Changes in this revision: * Remove features that classified as feature creep (Gimple folding and rewriting the aarch64/arm dotprod builtin initialization routines). These will be submitted separately later. * Add missing second mode to arm-backend pattern missed in original. * Add implementation f

[PATCH V2 04/10] arm: Fix arm backend-use of (u|s|us)dot_prod patterns

gcc/ChangeLog: * config/arm/arm-builtins.cc (enum arm_builtins): Add new ARM_BUILTIN_* enum values: SDOTV8QI, SDOTV16QI, UDOTV8QI, UDOTV16QI, USDOTV8QI, USDOTV16QI. (arm_init_dotprod_builtins): New. (arm_init_builtins): Add call to `arm_init_dotprod_builtins

[PATCH V2 05/10] i386: Fix dot_prod backend patterns for mmx and sse targets

Following the migration of the dot_prod optab from a direct to a conversion-type optab, ensure all back-end patterns incorporate the second machine mode into pattern names. gcc/ChangeLog: * config/i386/mmx.md (usdot_prodv8qi): Renamed to... (usdot_prodv2siv8qi): ...this. (

[PATCH V2 08/10] rs6000: Adjust altivec dot-product backend patterns

Following the migration of the dot_prod optab from a direct to a conversion-type optab, ensure all back-end patterns incorporate the second machine mode into pattern names. gcc/ChangeLog: * config/rs6000/altivec.md (udot_prod): Renamed to... (udot_prodv4si): ...this. (sdot

[PATCH V2 07/10] mips: Adjust dot-product backend patterns

Following the migration of the dot_prod optab from a direct to a conversion-type optab, ensure all back-end patterns incorporate the second machine mode into pattern names. gcc/ChangeLog: * config/mips/loongson-mmi.md (sdot_prodv4hi): Renamed to... (sdot_prodv2siv4hi): ...this. --

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

On Mon, Aug 5, 2024 at 6:25 PM Sergey Fedorov wrote: > > On Thu, Jul 25, 2024 at 4:47 PM FX Coudert wrote: > >> Can you post an updated version of the patch, following the first round >> of review? >> >> FX > > If you got some time, please review this. I will likely be away from my PowerPC har

[PATCH V2 10/10] autovectorizer: Test autovectorization of different dot-prod modes.

From: Victor Do Nascimento Given the novel treatment of the dot product optab as a conversion, we are now able to targe different relationships between output modes and input modes. This is made clearer by way of example. Previously, on AArch64, the following loop was vectorizable: uint32_t udo

[Fortran, Patch, PR102973, v1] Reset flag for parsing proc_ptrs in associate in error case

Hi all, attached patch is the last one the meta-bug 87477 ASSOCIATE depends on. The resolution was already given in the PR, so I just beautified it and made patch for it. I tried to come up with a testcase as well as Harald has, but had no luck with it. I see less harm in reseting the flag in the

[PATCH] PR tree-optimization/101390: Vectorize modulo operator

This patch adds a new vectorization pattern that detects the modulo operation where the second operand is a variable. It replaces the statement by division, multiplication, and subtraction. The patch was bootstrapped and regtested on aarch64-linux-gnu, no regression. Ok for mainline? Signed-off-b

Re: [PATCH] c++/coroutines: fix passing *this to promise type, again [PR116327]

Hi Patrick > On 13 Aug 2024, at 03:01, Patrick Palka wrote: > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14? > > -- >8 -- > > In r15-2210 we got rid of the unnecessary cast to lvalue reference when > passing *this to the promise type ctor, and as a drive-by change we also > s

[Committed 2/3] RISC-V: Fix non-obvious comment typos

On 8/5/24 15:29, Patrick O'Neill wrote: This fixes the remainder of the typos I found when reading various parts of the RISC-V backend. gcc/ChangeLog: * config/riscv/riscv-v.cc (legitimize_move): extrac -> extract. (expand_vec_cmp_float): Remove duplicate vmnor.mm. * c

Re: [PATCH 05/15] arm: [MVE intrinsics] add vcvt shape

"Andre Vieira (lists)" writes: > On 11/07/2024 22:42, Christophe Lyon wrote: >> + bool >> + check (function_checker &c) const override >> + { >> +if (c.mode_suffix_id == MODE_none) >> + return true; >> + >> +unsigned int bits = c.type_suffix (0).element_bits; >> +return c.requi

v2.1 Draft for a lengthof paper

Hi, On Tue, Aug 13, 2024 at 01:34:58AM GMT, Alejandro Colomar wrote: > I want to send an updated version of n2529. The original author didn't > respond to my mail, so I'll take over. I've been preparing a GCC patch > set for adding the feature to GCC, and have informed Clang developers > about i

Ping: [PATCH] testsuite: Fix struct size check [PR116155]

I stumbled on this being a regression for cris-elf as well; the patch expectedly fixes the test-case for CRIS as well. It's been a week since the patch was posted and as I see no replies, I'm pinging this in behalf of Dimitar. > From: Dimitar Dimitrov > Date: Mon, 5 Aug 2024 21:29:35 +0300 > Th

Re: [PATCH v1 2/4] dwarf2: add hooks for architecture-specific CFIs

Matthieu Longo writes: > Architecture-specific CFI directives are currently declared an processed > among others architecture-independent CFI directives in gcc/dwarf2* files. > This approach creates confusion, specifically in the case of DWARF > instructions in the vendor space and using the same

Re: [PATCH v1 1/4] Rename REG_CFA_TOGGLE_RA_MANGLE to REG_CFA_NEGATE_RA_STATE

Matthieu Longo writes: > The current name REG_CFA_TOGGLE_RA_MANGLE is not representative of what > it really is, i.e. a register to represent several states, not only a > binary one. Same for dwarf2out_frame_debug_cfa_toggle_ra_mangle. > > gcc/ChangeLog: > > * combine-stack-adj.cc >

[PATCH v1] Provide new GCC builtin __builtin_get_counted_by [PR116016]

With the addition of the 'counted_by' attribute and its wide roll-out within the Linux kernel, a use case has been found that would be very nice to have for object allocators: being able to set the counted_by counter variable without knowing its name. For example, given: struct foo { ...

RE: [nvptx] Pass -m32/-m64 to host_compiler if it has multilib support

Hi Prathamesh! On 2024-08-12T07:50:07+, Prathamesh Kulkarni wrote: >> From: Thomas Schwinge >> Sent: Friday, August 9, 2024 12:55 AM >> On 2024-08-08T06:46:25-0700, Andrew Pinski wrote: >> > On Thu, Aug 8, 2024 at 6:11 AM Prathamesh Kulkarni >> > wrote: >> >> After differing NUM_POLY_INT_

Re: [PATCH v1 3/4] aarch64 testsuite: explain expectections for pr94515* tests

Matthieu Longo writes: > gcc/testsuite/ChangeLog: > > * g++.target/aarch64/pr94515-1.C: Improve test documentation. > * g++.target/aarch64/pr94515-2.C: Same. The patch is OK as-is, since it's clearly a strict improvement over the status quo. But a suggestion below: > --- > gcc/

Re: [PATCH v1 4/4] dwarf2: store the RA state in CFI row

Matthieu Longo writes: > On AArch64, the RA state informs the unwinder whether the return address > is mangled and how, or not. This information is encoded in a boolean in > the CFI row. This binary approach prevents from expressing more complex > configuration, as it is the case with PAuth_LR int

Re: [PATCH] testsuite: Avoid running neon test on Cortex-M55

I'm not a maintainer but I'd argue the entire test is bogus. The error reporting in this area seems to be somewhat fragile, if you compile it with '-march=armv7-a -mfloat-abi=soft', you also don't get the error this is testing for.  I'd argue this kind of user friendly error message should jus

Re: [Fortran, Patch, PR102973, v1] Reset flag for parsing proc_ptrs in associate in error case

Hi Andre, Am 13.08.24 um 15:15 schrieb Andre Vehreschild: Hi all, attached patch is the last one the meta-bug 87477 ASSOCIATE depends on. The resolution was already given in the PR, so I just beautified it and made patch for it. I tried to come up with a testcase as well as Harald has, but had

Re: [nvptx] Pass -m32/-m64 to host_compiler if it has multilib support

> Am 13.08.2024 um 17:48 schrieb Thomas Schwinge : > > Hi Prathamesh! > > On 2024-08-12T07:50:07+, Prathamesh Kulkarni > wrote: >>> From: Thomas Schwinge >>> Sent: Friday, August 9, 2024 12:55 AM > >>> On 2024-08-08T06:46:25-0700, Andrew Pinski wrote: On Thu, Aug 8, 2024 at 6:11

rtl: Enable the use of rtx values with int and mode attributes

Hi, The 'code' part of a 'define_code_attr' refers to the type of the key, in other words, it uses a code_iterator to pick the value from their (key "value") pair list. Though it seems rtx_alloc_for_name requires a code_attribute to be used when the 'value' needs to be a type. In other words,

Re: [PATCH] ifcvt: Fix force_operand ICE due to noce_convert_multiple_sets [PR116353]

Manolis Tsamis writes: > Now that more operations are allowed for noce_convert_multiple_sets, we need > to > check noce_can_force_operand on the sequence before calling > try_emit_cmove_seq. > Otherwise an inappropriate argument may be given to copy_to_mode_reg and > result > in an ICE. > > Fi

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

Hi, > I dropped a change to the test file, since you have fixed it appropriately, > and switched to Apple libm convention for flags, as you have suggested. > Please let me know if I should do anything further to improve it and make it > acceptable for a merge. The patch itself is OK. Please add

[PATCH v2] genoutput: Accelerate the place_operands function.

With the increase in the number of modes and patterns for some backend architectures, the place_operands function becomes a bottleneck int the speed of genoutput, and may even become a bottleneck int the overall speed of building the GCC project. This patch aims to accelerate the place_operands fun

Re: rtl: Enable the use of rtx values with int and mode attributes

"Andre Vieira (lists)" writes: > Hi, > > The 'code' part of a 'define_code_attr' refers to the type of the key, > in other words, it uses a code_iterator to pick the value from their > (key "value") pair list. > Though it seems rtx_alloc_for_name requires a code_attribute to be used > when the

Re: [PATCH v2] genoutput: Accelerate the place_operands function.

On Wed, Aug 14, 2024 at 01:01:35AM +0800, Xianmiao Qu wrote: > static void scan_operands (class data *, rtx, int, int); > -static int compare_operands (struct operand_data *, > - struct operand_data *); > static void place_operands (class data *); Oh, there is an mistake

Re: [PATCH v2] genoutput: Accelerate the place_operands function.

Xianmiao Qu writes: > On Wed, Aug 14, 2024 at 01:01:35AM +0800, Xianmiao Qu wrote: >> static void scan_operands (class data *, rtx, int, int); >> -static int compare_operands (struct operand_data *, >> - struct operand_data *); >> static void place_operands (class data *

Re: Ping: [PATCH] testsuite: Fix struct size check [PR116155]

Hans-Peter Nilsson writes: > I stumbled on this being a regression for cris-elf as well; > the patch expectedly fixes the test-case for CRIS as well. > It's been a week since the patch was posted and as I see no > replies, I'm pinging this in behalf of Dimitar. I can't formally approve it but I

[PING^4][PATCH v2] docs: Update function multiversioning documentation

I'm still waiting for review for this patch. I've asked Richard Sandiford about it, and he'd like a docs maintainer to review the patch (so I've cc'd the rest of them now as well). On Wed, Jul 10, 2024 at 01:09:41PM +0100, Andrew Carlotti wrote: > > On Mon, Jun 10, 2024 at 05:08:21PM +0100, Andr

[PATCH v3] genoutput: Accelerate the place_operands function.

With the increase in the number of modes and patterns for some backend architectures, the place_operands function becomes a bottleneck int the speed of genoutput, and may even become a bottleneck int the overall speed of building the GCC project. This patch aims to accelerate the place_operands fun

Re: Ping^4 [PATCH-2v4] Value Range: Add range op for builtin isfinite

Hi Hao Gui, Can you commit this soon - some of the arch patches might be waiting on this. Thx, -Vineet On 8/5/24 07:59, Jeff Law wrote: > On 7/21/24 8:10 PM, HAO CHEN GUI wrote: >> Hi, >>Gently ping it. >> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653094.html > OK. Sorry for the de

[PATCH] Fortran: reject array constructor value of abstract type [PR114308]

Dear all, the attached patch checks whether the declared type of an array constructor value is abstract, which is forbidden by the standard. Steve found the relevant constraint in F2023, but it exists already in F2018. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald From 9988

Re: Ping: [PATCH] testsuite: Fix struct size check [PR116155]

> From: Sam James > Date: Tue, 13 Aug 2024 18:17:29 +0100 > Hans-Peter Nilsson writes: > > > I stumbled on this being a regression for cris-elf as well; > > the patch expectedly fixes the test-case for CRIS as well. > > It's been a week since the patch was posted and as I see no > > replies, I'

[PING] [PATCH v2] Support if conversion for switches

Andi Kleen writes: I wanted to ping this patch. I believe Richard ok'ed most of it earlier but need an ok for the changes resulting from his review too (but they were mostly only test suite and comment fixes apart from some minor tweaks) -Andi > The gimple-if-to-switch pass converts if statemen

Re: [PATCH v3] genoutput: Accelerate the place_operands function.

Xianmiao Qu writes: > With the increase in the number of modes and patterns for some > backend architectures, the place_operands function becomes a > bottleneck int the speed of genoutput, and may even become a > bottleneck int the overall speed of building the GCC project. > This patch aims to ac

[PATCH v4] genoutput: Accelerate the place_operands function.

With the increase in the number of modes and patterns for some backend architectures, the place_operands function becomes a bottleneck int the speed of genoutput, and may even become a bottleneck int the overall speed of building the GCC project. This patch aims to accelerate the place_operands fun

Re: [PATCH v4] genoutput: Accelerate the place_operands function.

Xianmiao Qu writes: > With the increase in the number of modes and patterns for some > backend architectures, the place_operands function becomes a > bottleneck int the speed of genoutput, and may even become a > bottleneck int the overall speed of building the GCC project. > This patch aims to a

Re: Ping: [PATCH] testsuite: Fix struct size check [PR116155]

Hans-Peter Nilsson writes: >> From: Sam James >> Date: Tue, 13 Aug 2024 18:17:29 +0100 > >> Hans-Peter Nilsson writes: >> >> > I stumbled on this being a regression for cris-elf as well; >> > the patch expectedly fixes the test-case for CRIS as well. >> > It's been a week since the patch was p

Re: [PATCH] Fortran: reject array constructor value of abstract type [PR114308]

Pushed after an OK by Steve in the PR as r15-2902-g9988d7e004796ab531df7bcda45788a7aa9276d7 Am 13.08.24 um 19:25 schrieb Harald Anlauf: Dear all, the attached patch checks whether the declared type of an array constructor value is abstract, which is forbidden by the standard. Steve found the r

[PATCH] Fortran: fix minor frontend GMP leaks

Dear all, while running f951 under valgrind on testcase gfortran.dg/sizeof_6.f90 I found two minor memleaks with GMP variables that were not cleared. Regtested on x86_64-pc-linux-gnu. I intend to commit to mainline soon unless there are comments. (And no, this does not address the recent interm

Re: [PATCH 3/8] tree-ifcvt: Enforce zero else value after maskload.

On 8/11/24 3:00 PM, Robin Dapp wrote: When predicating a load we implicitly assume that the else value is zero. In order to formalize this this patch queries the target for its supported else operand and uses that for the maskload call. Subsequently, if the else operand is nonzero, a cond_exp

Re: [PATCH] ifcvt: Fix force_operand ICE due to noce_convert_multiple_sets [PR116353]

On Tue, Aug 13, 2024 at 4:57 AM Manolis Tsamis wrote: > > Now that more operations are allowed for noce_convert_multiple_sets, we need > to > check noce_can_force_operand on the sequence before calling > try_emit_cmove_seq. > Otherwise an inappropriate argument may be given to copy_to_mode_reg a

Re: [PATCH] ifcvt: Fix force_operand ICE due to noce_convert_multiple_sets [PR116353]

On 8/13/24 5:57 AM, Manolis Tsamis wrote: Now that more operations are allowed for noce_convert_multiple_sets, we need to check noce_can_force_operand on the sequence before calling try_emit_cmove_seq. Otherwise an inappropriate argument may be given to copy_to_mode_reg and result in an ICE.

Re: [PATCH] ifcvt: Fix force_operand ICE due to noce_convert_multiple_sets [PR116353]

Applied to master, thanks. --Philipp. On Tue, 13 Aug 2024 at 21:48, Jeff Law wrote: > > > On 8/13/24 5:57 AM, Manolis Tsamis wrote: > > Now that more operations are allowed for noce_convert_multiple_sets, we > need to > > check noce_can_force_operand on the sequence before calling > try_emit_cmo

Re: [PATCH] ifcvt: Fix force_operand ICE due to noce_convert_multiple_sets [PR116353]

"H.J. Lu" writes: > On Tue, Aug 13, 2024 at 4:57 AM Manolis Tsamis > wrote: >> >> Now that more operations are allowed for noce_convert_multiple_sets, we need >> to >> check noce_can_force_operand on the sequence before calling >> try_emit_cmove_seq. >> Otherwise an inappropriate argument may

Re: [PATCH] ifcvt: Fix force_operand ICE due to noce_convert_multiple_sets [PR116353]

On Tue, Aug 13, 2024 at 12:40:35PM -0700, H.J. Lu wrote: > > --- /dev/null > > +++ b/gcc/testsuite/gcc.target/i386/pr116353.c > > Does this test contain x86 specific code? Guess int32plus dependent at least (on 16-bit int *in++ << 16 would be out of bounds shift). Jakub

Re: [committed][rtl-optimization/116244] Don't create bogus regs in alter_subreg

On 8/13/24 3:19 AM, Richard Sandiford wrote: And the inconsistency was driving me bananas as my mental model is that (reg:DI N) covers N and N+1 and all that changes in the order based on endianness. ie, if we have (set (reg:DI 0) (...)) that changes d0/d1. But maybe that's just 20 year

Re: Ping: [PATCH] testsuite: Fix struct size check [PR116155]

On Tue, Aug 13, 2024 at 07:34:09PM +0200, Hans-Peter Nilsson wrote: > > From: Sam James > > Date: Tue, 13 Aug 2024 18:17:29 +0100 > > > Hans-Peter Nilsson writes: > > > > > I stumbled on this being a regression for cris-elf as well; > > > the patch expectedly fixes the test-case for CRIS as wel

Re: [PATCH v2] c++: ICE with NSDMIs and fn arguments [PR116015]

On 8/12/24 7:21 PM, Marek Polacek wrote: On Fri, Aug 09, 2024 at 05:15:05PM -0400, Jason Merrill wrote: On 8/9/24 4:21 PM, Marek Polacek wrote: On Fri, Aug 09, 2024 at 12:58:34PM -0400, Jason Merrill wrote: On 8/8/24 1:37 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu,

Re: [PATCH] c++/coroutines: fix passing *this to promise type, again [PR116327]

On 8/12/24 10:01 PM, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14? -- >8 -- In r15-2210 we got rid of the unnecessary cast to lvalue reference when passing *this to the promise type ctor, and as a drive-by change we also simplified the code to use cp_build_

Re: Ping: [PATCH] testsuite: Fix struct size check [PR116155]

> On Aug 13, 2024, at 17:05, Dimitar Dimitrov wrote: > > On Tue, Aug 13, 2024 at 07:34:09PM +0200, Hans-Peter Nilsson wrote: >>> From: Sam James >>> Date: Tue, 13 Aug 2024 18:17:29 +0100 >> >>> Hans-Peter Nilsson writes: >>> I stumbled on this being a regression for cris-elf as well;

Re: v2.1 Draft for a lengthof paper

I have been overseeing these last emails - thank you very much for your efforts, Alex! I did not reply until now because I do not have prior experience with gcc internals, so my feedback would probably have not been that useful. Those emails from 2020 were in fact discussing two completely differe

Re: v2.1 Draft for a lengthof paper

Hi Xavier, On Wed, Aug 14, 2024 at 12:38:53AM GMT, Xavier Del Campo Romero wrote: > I have been overseeing these last emails - Ahhh, good to know; thanks! :) > thank you very much for your > efforts, Alex! :-) > I did not reply until now because I do not have prior > experience with gcc inter

Re: [PATCH] c++/coroutines: fix passing *this to promise type, again [PR116327]

On Tue, 13 Aug 2024, Jason Merrill wrote: > On 8/12/24 10:01 PM, Patrick Palka wrote: > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14? > > > > -- >8 -- > > > > In r15-2210 we got rid of the unnecessary cast to lvalue reference when > > passing *this to the promise type ctor, an

RE: [PATCH V2 05/10] i386: Fix dot_prod backend patterns for mmx and sse targets

> -Original Message- > From: Victor Do Nascimento > Sent: Tuesday, August 13, 2024 8:42 PM > To: gcc-patches@gcc.gnu.org > Cc: tamar.christ...@arm.com; claz...@gmail.com; Liu, Hongtao > ; s...@gcc.gnu.org; bernds_...@t-online.de; > al...@redhat.com; Victor Do Nascimento > Subject: [PAT

Re: [PATCH] Move ix86_align_loops into a separate pass and insert the pass after pass_endbr_and_patchable_area.

On Mon, Aug 12, 2024 at 10:10 PM liuhongt wrote: > > > Are there any assumptions that BB_HEAD must be a note or label? > > Maybe we should move ix86_align_loops into a separate pass and insert > > the pass just before pass_final. > The patch inserts .p2align after endbr pass, it can also fix the i

[PATCH] [x86] Movement between GENERAL_REGS and SSE_REGS for TImode doesn't need secondary reload.

It results in 2 failures for x86_64-pc-linux-gnu{\ -march=cascadelake}; gcc: gcc.target/i386/extendditi3-1.c scan-assembler cqt?o gcc: gcc.target/i386/pr113560.c scan-assembler-times \tmulq 1 For pr113560.c, now GCC generates mulx instead of mulq with -march=cascadelake, which should be optimal,

RE: [PATCH 1/4] i386: Optimization for APX NDD is always zero-uppered for ADD

Hi, Gently ping. Thanks, Lingling From: kong lingling Sent: Monday, August 12, 2024 3:10 PM To: gcc-patches@gcc.gnu.org Cc: H. J. Lu ; Kong, Lingling ; Liu, Hongtao Subject: [PATCH 1/4] i386: Optimization for APX NDD is always zero-uppered for ADD For APX instruction with an NDD, the destin

Re: [PATCH 1/4] i386: Optimization for APX NDD is always zero-uppered for ADD

On Mon, Aug 12, 2024 at 3:10 PM kong lingling wrote: > > For APX instruction with an NDD, the destination GPR will get the > instruction’s result in bits [OSIZE-1:0] and, if OSIZE < 64b, have its upper > bits [63:OSIZE] zeroed. Now supporting other NDD instructions. > > > Bootstrapped and regtes

Re: [PATCH 2/4] i386: Optimization for APX NDD is always zero-uppered for sub/adc/sbb

On Mon, Aug 12, 2024 at 3:12 PM kong lingling wrote: > > gcc/ChangeLog: > > > >PR target/113729 > >* config/i386/i386.md (*subqi_1_zext): New > >define_insn. > >(*subhi_1_zext): Ditto. > >(*addqi3_carry_zext): Ditto. >

Re: [PATCH 3/4] i386: Optimization for APX NDD is always zero-uppered for logic

On Mon, Aug 12, 2024 at 3:12 PM kong lingling wrote: > > gcc/ChangeLog: > > >PR target/113729 > >* config/i386/i386.md (*andqi_1_zext): > >New define_insn. > >(*andhi_1_zext): Ditto. > >(*qi_1_zext): Ditto. > >

Re: [PATCH 4/4] i386: Optimization for APX NDD is always zero-uppered for shift

On Mon, Aug 12, 2024 at 3:12 PM kong lingling wrote: > > gcc/ChangeLog: > > > PR target/113729 > >* config/i386/i386.md (*ashlqi3_1_zext): > >New define_insn. > >(*ashlhi3_1_zext): Ditto. > >(*qi3_1_zext): Ditto. > >

[PATCH] i386: Fix some vex insns that prohibit egpr

Although these vex insn have evex counterpart, but when it uses the displayed vex prefix should not support APX EGPR. Like TARGET_AVXVNNI, TARGET_IFMA and TARGET_AVXNECONVERT. Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. Ok for trunk? gcc/ChangeLog: * config/i386/sse.md (vp

RE: [PATCH] i386: Fix some vex insns that prohibit egpr

> -Original Message- > From: Kong, Lingling > Sent: Wednesday, August 14, 2024 9:38 AM > To: gcc-patches@gcc.gnu.org > Cc: Liu, Hongtao ; Jiang, Haochen > > Subject: [PATCH] i386: Fix some vex insns that prohibit egpr > > Although these vex insn have evex counterpart, but when it uses

[PATCH] aarch64: Improve vector constant generation using SVE INDEX instruction [PR113328]

SVE's INDEX instruction can be used to populate vectors by values starting from "base" and incremented by "step" for each subsequent value. We can take advantage of it to generate vector constants if TARGET_SVE is available and the base and step values are within [-16, 15]. For example, with the f

Re: [PATCH/RFC] LRA: Don't emit move for substituted CONSTATNT_P operand [PR116170]

on 2024/8/13 18:02, Richard Sandiford wrote: > "Kewen.Lin" writes: >> on 2024/8/12 21:02, Richard Sandiford wrote: >>> "Kewen.Lin" writes: Hi Richard, Thanks for the comments! on 2024/8/12 16:55, Richard Sandiford wrote: > "Kewen.Lin" writes: >> Hi, >> >>

[PATCH] PR target/89213 - Enhance V2DI/V2DF constant shifts

This patch fixes PR target/89213 to allow better code to be generated to do constant shifts of V2DI/V2DF vectors. Previously GCC would do constant shifts of vectors with 64-bit elements by using: XXSPLTIB 32,4 VEXTSB2D 0,0 VSRAD 2,2,0 I.e., the PowerPC does not have a VSP

Re: [PATCH v4] genoutput: Accelerate the place_operands function.

On Tue, Aug 13, 2024 at 06:57:40PM +0100, Sam James wrote: > > /* No instruction can have more operands than this. Sorry for this > > arbitrary limit, but what machine will have an instruction with > > @@ -112,6 +113,8 @@ static int next_operand_number = 1; > > struct operand_data > > { > >

[PATCH v5] genoutput: Accelerate the place_operands function.

With the increase in the number of modes and patterns for some backend architectures, the place_operands function becomes a bottleneck int the speed of genoutput, and may even become a bottleneck int the overall speed of building the GCC project. This patch aims to accelerate the place_operands fun

RE: [PATCH v2] RISC-V: Support IMM for operand 0 of ussub pattern

This Patch may requires rebase, will send v3 for conflict resolving. Pan -Original Message- From: Li, Pan2 Sent: Sunday, August 4, 2024 7:48 PM To: gcc-patches@gcc.gnu.org Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; jeffreya...@gmail.com; rdapp@gmail.com; Li, Pan2 Subject: [PA

Re: [PATCH v5] genoutput: Accelerate the place_operands function.

Xianmiao Qu writes: > With the increase in the number of modes and patterns for some > backend architectures, the place_operands function becomes a > bottleneck int the speed of genoutput, and may even become a > bottleneck int the overall speed of building the GCC project. > This patch aims to a

Re: [PATCH v2] RISC-V: Support IMM for operand 0 of ussub pattern

On 8/13/24 8:23 PM, Li, Pan2 wrote: This Patch may requires rebase, will send v3 for conflict resolving. Pan -Original Message- From: Li, Pan2 Sent: Sunday, August 4, 2024 7:48 PM To: gcc-patches@gcc.gnu.org Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; jeffreya...@gmail.com; rda

  1   2   >