Re: [PATCH] RISC-V: Disable misaligned vector access in hook riscv_slow_unaligned_access

> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc > index 61fa74e9322..87270fd7af4 100644 > --- a/gcc/config/riscv/riscv.cc > +++ b/gcc/config/riscv/riscv.cc > @@ -10271,7 +10271,7 @@ riscv_cannot_copy_insn_p (rtx_insn *insn) > static bool > riscv_slow_unaligned_access (machine

Re: [PATCH] Add function filtering to gcov

On 7/10/24 23:59, Jeff Law wrote: On 7/10/24 3:18 PM, Jørgen Kvalsvik wrote: On 7/10/24 21:54, Jeff Law wrote: On 7/10/24 1:30 PM, Jørgen Kvalsvik wrote: Thanks you -- before I move forward, I would like some feedback on adding this diff to the patch: diff --git a/gcc/gcov.cc b/gcc/

Re: [PATCH] rs6000: Error on CPUs and ABIs that don't support the ROP, protection insns [PR114759]

on 2024/7/11 11:36, Peter Bergner wrote: > On 7/10/24 1:01 AM, Kewen.Lin wrote: >>> + if (rs6000_rop_protect) >>> +{ >>> + /* Disallow CPU targets we don't support. */ >>> + if (!TARGET_POWER8) >>> + error ("%<-mrop-protect%> requires %<-mcpu=power8%> or later"); >>> + >>> +

[PATCH, rs6000] Add TARGET_FLOAT128_HW guard for quad-precision insns

Hi, This patch adds TARGET_FLOAT128_HW into pattern conditions for quad- precision insns. Also it removes FLOAT128_IEEE_P check from pattern conditions if the mode of pattern is IEEE128 as the mode iterator - IEEE128 already checks with FLOAT128_IEEE_P. For test case float128-cmp2-runnable.c,

[PATCH] RISC-V: Disable misaligned vector access in hook riscv_slow_unaligned_access

From: xuli The reason is that in the following code, icode = movmisalignv8si has already been rejected by TARGET_VECTOR_MISALIGN_SUPPORTED, but it is allowed by targetm.slow_unaligned_access,which is contradictory. (((icode = optab_handler (movmisalign_optab, mode)) != CODE_FOR_nothin

Re: [PATCH] rs6000: Error on CPUs and ABIs that don't support the ROP, protection insns [PR114759]

On 7/10/24 1:01 AM, Kewen.Lin wrote: >> + if (rs6000_rop_protect) >> +{ >> + /* Disallow CPU targets we don't support. */ >> + if (!TARGET_POWER8) >> +error ("%<-mrop-protect%> requires %<-mcpu=power8%> or later"); >> + >> + /* Disallow ABI targets we don't support. */ >>

Re: [PATCH v2] Fix Xcode 16 build break with NULL != nullptr

On Wed, 2024-07-10 at 09:43 +, Daniel Bertalan wrote: > As of Xcode 16 beta 2 with the macOS 15 SDK, each re-inclusion of the > stddef.h header causes the NULL macro in C++ to be re-defined to an > integral constant (__null). This makes the workaround in d59a576b8 > ("Redefine NULL to nullptr")

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

On Wed, Jul 10, 2024 at 10:10 PM Victor Do Nascimento wrote: > > 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. The patch LGTM. BTW you can use existing instead of new

[MAINTAINERS] Update my email address and move to DCO

Pushing to trunk. Thanks, Kugan Signed-off-by: Kugan Vivekanandarajah 2024-07-11 Kugan Vivekanandarajah * MAINTAINERS: Update my email address. diff --git a/MAINTAINERS b/MAINTAINERS index 762b91256c4..d27640708c5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -704,7 +704,7 @@ Alex

RE: [PATCH v3] Vect: Optimize truncation for .SAT_SUB operands

> OK. Committed, thanks Richard. Pan -Original Message- From: Richard Biener Sent: Wednesday, July 10, 2024 7:26 PM To: Li, Pan2 Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@gmail.com; tamar.christ...@arm.com; jeffreya...@gmail.com; rdapp@gmail.com; Liu, Hongtao

RE: [PATCH v1] Vect: Promote unsigned .SAT_ADD constant operand for vectorizable_call

> I think that's a bug. Do you say __builtin_add_overflow fails to promote > (constant) arguments? Thanks Richard. Not very sure which part result in type mismatch, will take a look and keep you posted. Pan -Original Message- From: Richard Biener Sent: Wednesday, July 10, 2024 7:36 P

Re: [PATCH, expand] Add const0 move checking for CLEAR_BY_PIECES optabs

On 1/15/24 7:04 PM, HAO CHEN GUI wrote: Hi, This patch adds const0 move checking for CLEAR_BY_PIECES. The original vec_duplicate handles duplicates of non-constant inputs. But 0 is a constant. So even a platform doesn't support vec_duplicate, it could still do clear by pieces if it supports

Re: [PING] [PATCH v4 3/3] [RFC] ifcvt: Handle multiple rewired regs and refactor noce_convert_multiple_sets

On 6/3/24 5:34 AM, Manolis Tsamis wrote: The existing implementation of need_cmov_or_rewire and noce_convert_multiple_sets_1 assumes that sets are either REG or SUBREG. This commit enchances them so they can handle/rewire arbitrary set statements. To do that a new helper struct noce_multiple_

Re: [PING] [PATCH v4 2/3] [RFC] ifcvt: Allow more operations in multiple set if conversion

On 6/3/24 5:34 AM, Manolis Tsamis wrote: Currently the operations allowed for if conversion of a basic block with multiple sets are few, namely REG, SUBREG and CONST_INT (as controlled by bb_ok_for_noce_convert_multiple_sets). This commit allows more operations (arithmetic, compare, etc) to p

Re: [PING] [PATCH v4 1/3] [RFC] ifcvt: handle sequences that clobber flags in noce_convert_multiple_sets

On 6/3/24 5:34 AM, Manolis Tsamis wrote: This is an extension of what was done in PR106590. Currently if a sequence generated in noce_convert_multiple_sets clobbers the condition rtx (cc_cmp or rev_cc_cmp) then only seq1 is used afterwards (sequences that emit the comparison itself). Since th

Re: [PATCH] recog: Avoid validate_change shortcut for groups [PR115782]

On 7/9/24 11:15 PM, Richard Sandiford wrote: In this PR, due to the -f flags, we ended up with: bb1: r10=r10 ... bb2: r10=r10 ... bb3: ...=r10 with bb1->bb2 and bb1->bb3. late-combine successfully combined the bb1->bb2 def-use and set the insn code to NOOP_MOVE_INSN_CODE. The bb1->bb3 c

Re: [PATCH] Add function filtering to gcov

On 7/10/24 3:18 PM, Jørgen Kvalsvik wrote: On 7/10/24 21:54, Jeff Law wrote: On 7/10/24 1:30 PM, Jørgen Kvalsvik wrote: Thanks you -- before I move forward, I would like some feedback on adding this diff to the patch: diff --git a/gcc/gcov.cc b/gcc/gcov.cc index 9cdef19c461..055fa7e

Re: [PATCH] Add function filtering to gcov

On 7/10/24 21:54, Jeff Law wrote: On 7/10/24 1:30 PM, Jørgen Kvalsvik wrote: Thanks you -- before I move forward, I would like some feedback on adding this diff to the patch: diff --git a/gcc/gcov.cc b/gcc/gcov.cc index 9cdef19c461..055fa7e78ba 100644 --- a/gcc/gcov.cc +++ b/gcc/gcov.c

[committed] libstdc++: Make std::basic_format_context non-copyable [PR114387]

Tested x86_64-linux. Pushed to trunk. Probably a good idea to backport it to 13 and 14, for consistency. -- >8 -- Users are not supposed to create objects of this type, and there's no reason it needs to be copyable. LWG 4061 makes it non-copyable and non-default constructible. libstdc++-v3/Chang

[committed] libstdc++: Minor optimization for std::locale::encoding()

Tested x86_64-linux. Pushed to trunk. -- >8 -- For the C locale we know the encoding is ASCII, so we can avoid using newlocale and nl_langinfo_l. Similarly, for an unnamed locale, we aren't going to get a useful answer, so we can just use a default-constrcuted std::text_encoding representing an u

Re: [r15-1936 Regression] FAIL: gcc.target/i386/avx512vl-vpmovuswb-2.c execution test on Linux/x86_64

On Wed, Jul 10, 2024 at 3:42 PM haochen.jiang wrote: > > On Linux/x86_64, > > 80e446e829d818dc19daa6e671b9626e93ee4949 is the first bad commit > commit 80e446e829d818dc19daa6e671b9626e93ee4949 > Author: Pan Li > Date: Fri Jul 5 20:36:35 2024 +0800 > > Match: Support form 2 for the .SAT_TRUN

[committed] libstdc++: Use direct-initialization for std::vector's allocator [PR115854]

Tested x86_64-linux. Pushed to trunk. Backports could follow. -- >8 -- The consensus in the standard committee is that this change shouldn't be necessary, and the Allocator requirements should require conversions between rebound allocators to be implicit. But we can make it work for now anyway.

Re: [PATCH] libstdc++: ranges::find needs explicit conversion to size_t [PR115799]

Pushed to trunk. On Mon, 8 Jul 2024 at 20:44, Jonathan Wakely wrote: > > This fixes another problem with my recent changes to use memchr in > std::find. > > Tested x86_64-linux. > > -- >8 -- > > For an integer-class type we need to use an explicit conversion to size_t. > > libstdc++-v3/ChangeLog:

[committed] i386: Swap compare operands in ustrunc patterns

A last minute change led to a wrong operand order in the compare insn. gcc/ChangeLog: * config/i386/i386.md (ustruncdi2): Swap compare operands. (ustruncsi2): Ditto. (ustrunchiqi2): Ditto. Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}. Uros. diff --git a/gcc/config

Re: [PATCH v2] Fix Xcode 16 build break with NULL != nullptr

Hi Daniel, Thanks for patching the Rust frontend as well. Looks great to me. Best, Arthur On 7/10/24 11:43, Daniel Bertalan wrote: As of Xcode 16 beta 2 with the macOS 15 SDK, each re-inclusion of the stddef.h header causes the NULL macro in C++ to be re-defined to an integral constant (__nul

Re: [PATCH] Add function filtering to gcov

On 7/10/24 1:30 PM, Jørgen Kvalsvik wrote: Thanks you -- before I move forward, I would like some feedback on adding this diff to the patch: diff --git a/gcc/gcov.cc b/gcc/gcov.cc index 9cdef19c461..055fa7e78ba 100644 --- a/gcc/gcov.cc +++ b/gcc/gcov.cc @@ -1613,6 +1613,12 @@ process_all_

Re: [RFC 1/2] libbacktrace: add FDPIC support

On Sun, May 26, 2024 at 11:51 PM Max Filippov wrote: > > diff --git a/libbacktrace/internal.h b/libbacktrace/internal.h > index 4fa0af8cb6c9..456911166026 100644 > --- a/libbacktrace/internal.h > +++ b/libbacktrace/internal.h > @@ -323,10 +323,22 @@ struct dwarf_sections > > struct dwarf_data; >

Re: [PATCH] Add function filtering to gcov

On 7/10/24 01:50, Jeff Law wrote: On 6/25/24 1:56 AM, Jørgen Kvalsvik wrote: Add the --include and --exclude flags to gcov to control what functions to report on. This is meant to make gcov more practical as an when writing test suites or performing other coverage experiments, which tends to f

Re: Lower zeroing array assignment to memset for allocatable arrays

Hi Prathamesh, Am 10.07.24 um 13:22 schrieb Prathamesh Kulkarni: Hi, The attached patch lowers zeroing array assignment to memset for allocatable arrays. For example: subroutine test(z, n) implicit none integer :: n real(4), allocatable :: z(:,:,:) allocate(z(n, 8192, 2048

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

Hi Andre, Am 10.07.24 um 10:45 schrieb Andre Vehreschild: Hi Harald, thanks for the review. I totally agree, that this patch has gotten bigger than I expected (and wanted). But things are as they are. About the coding style: I have worked in so many projects, that I consider a consistent codin

Re: [PATCH 1/3] expr: Allow same precision modes conversion between {ibm_extended, ieee_quad}_format [PR112993]

"Kewen.Lin" writes: > Hi Richard, > > on 2024/7/8 19:14, Richard Sandiford wrote: >> "Kewen.Lin" writes:[snip...] This part looks good to me FWIW, but what's the correct behaviour of: if (GET_MODE_PRECISION (from_mode) == GET_MODE_PRECISION (to_mode)) {

Re: [PATCH 3/3] RISC-V: load and store-lanes with SLP

Richard Biener writes: > The following is a prototype for how to represent load/store-lanes > within SLP. I've for now settled with having a single load node > with multiple permute nodes acting as selection, one for each loaded lane > and a single store node fed from all stored lanes. For > >

[to-be-committed][RISC-V] Eliminate unnecessary sign extension after inlined str[n]cmp

This patch eliminates an unnecessary sign extension for scalar inlined string comparisons on rv64. Conceptually this is pretty simple. Prove all the paths which "return" a value from the inlined string comparison already have sign extended values. FINAL_LABEL is the point after the calculat

Re: [to-be-committed][RISC-V][V3] DCE analysis for extension elimination

On 7/10/24 11:42 AM, Adhemerval Zanella Netto wrote: On 02/07/24 16:40, Jeff Law wrote: [ Actually attaching the patch this time... ] The pre-commit testing showed that making ext-dce only active at -O2 and above would require minor edits to the tests.  In some cases we had specified -O1

Re: [to-be-committed][RISC-V][V3] DCE analysis for extension elimination

On 02/07/24 16:40, Jeff Law wrote: > [ Actually attaching the patch this time... ] > > The pre-commit testing showed that making ext-dce only active at -O2 and > above would require minor edits to the tests.  In some cases we had specified > -O1 in the test or specified no optimization level

[PATCH 3/3] Add power11 tests

This patch is a modification of the patch posted on June 4th. It only does a compile of the tests, and not an assemble as suggested by Kewen.Lin. I have removed the power11 target support option that was previously added. This patch adds some simple tests for -mcpu=power11 support. I have boots

[REPOST 2/3] Add tuning support for power11

[This is a repost of the June 4th patch] This patch makes -mtune=power11 use the same tuning decisions as -mtune=power10. This patch makes -mtune=power11 use the same tuning decisions as -mtune=power10. It needs the previous patch to be applied. I have bootstrapped these patches on both little

[REPOST 1/3] Add support for -mcpu=power11

[This is a repost of the June 4th patch] This patch adds the power11 option to the -mcpu= and -mtune= switches. This patch treats the power11 like a power10 in terms of costs and reassociation width. This patch issues a ".machine power11" to the assembly file if you use -mcpu=power11. This patc

[REPOST 0/3] Add support for -mcpu=power11

Note, this is a repost of the 3 patches I posted on June 4th. The first two patches are the same. The third patch modifies the power11 tests to do a compile instead of assemble, and I removed the power11 specific target support that was posted as suggested by Kewen.Lin. The following 3 patches a

[PATCH 2/2] PR 115800: Fix libstdc++-v3 on little endian powerpc using --with-cpu=power5

If you build a little endian compiler and select a default CPU of power5 (i.e. --with-cpu=power5), GCC cannot be built. The reason is that both the libgfortran and libstdc++-v3 libraries assume that all little endian powerpc builds support IEEE 128-bit floating point. However, if the default cpu

[PATCH 1/2] PR 115800: Fix libgfortran build using --with-cpu=power5

If you build a little endian compiler and select a default CPU of power5 (i.e. --with-cpu=power5), GCC cannot be built. The reason is that both the libgfortran and libstdc++-v3 libraries assume that all little endian powerpc builds support IEEE 128-bit floating point. However, if the default cpu

[PATCH] PR 115800: Allow builds of little endian powerpc using --with-cpu=power5

The following two patches will allow GCC to be built with a little endian target where the default CPU is power5. In particular, both of the libstc++-v3 and libgfortran libraries assumeed that any little endian powerpc system would support IEEE 128-bit. However, to support IEEE 128-bit, you need

Re: [PATCH] internal-fn: Reuse SUBREG_PROMOTED_VAR_P handling

On 7/10/24 10:48 AM, Richard Sandiford wrote: Thanks for the review. Jeff Law writes: On 7/10/24 9:44 AM, Richard Sandiford wrote: expand_fn_using_insn has code to handle SUBREG_PROMOTED_VAR_P destinations. Specifically, for: (subreg/v:M1 (reg:M2 R) ...) it creates a new temporary r

Re: [PATCH] testsuite: Align testcase with implementation [PR105090]

On 2024-07-10 18:41, Richard Earnshaw (lists) wrote: On 10/07/2024 17:26, Torbjörn SVENSSON wrote: Is this ok for the following branches? - trunk - releases/gcc-14 - releases/gcc-13 -- Since r13-1006-g2005b9b888eeac, the test case copysign_softfloat_1.c no longer contains any lsr istruction,

Re: [Committed V2 1/2] RISC-V: Add support for B standard extension

Committed! Edwin On 7/9/2024 12:07 PM, Jeff Law wrote: On 7/9/24 11:44 AM, Edwin Lu wrote: This patch adds support for recognizing the B standard extension to be the collection of Zba, Zbb, Zbs extensions for consistency and conciseness across toolchains * https://github.com/riscv/riscv-b

Re: [PATCH] internal-fn: Reuse SUBREG_PROMOTED_VAR_P handling

Thanks for the review. Jeff Law writes: > On 7/10/24 9:44 AM, Richard Sandiford wrote: >> expand_fn_using_insn has code to handle SUBREG_PROMOTED_VAR_P >> destinations. Specifically, for: >> >>(subreg/v:M1 (reg:M2 R) ...) >> >> it creates a new temporary register T, uses it for the output

Re: [PATCH] testsuite: Align testcase with implementation [PR105090]

On 10/07/2024 17:26, Torbjörn SVENSSON wrote: > Is this ok for the following branches? > - trunk > - releases/gcc-14 > - releases/gcc-13 > > -- > > Since r13-1006-g2005b9b888eeac, the test case copysign_softfloat_1.c > no longer contains any lsr istruction, so drop the check as per > comment 9 in

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

Mariam Arutunian writes: > 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

[PATCH] testsuite: Align testcase with implementation [PR105090]

Is this ok for the following branches? - trunk - releases/gcc-14 - releases/gcc-13 -- Since r13-1006-g2005b9b888eeac, the test case copysign_softfloat_1.c no longer contains any lsr istruction, so drop the check as per comment 9 in PR105090. gcc/testsuite/ChangeLog: PR target/105090

Re: [PATCH] internal-fn: Reuse SUBREG_PROMOTED_VAR_P handling

On 7/10/24 9:44 AM, Richard Sandiford wrote: expand_fn_using_insn has code to handle SUBREG_PROMOTED_VAR_P destinations. Specifically, for: (subreg/v:M1 (reg:M2 R) ...) it creates a new temporary register T, uses it for the output operand, then sign- or zero-extends the M1 lowpart of T t

Re: [PATCH] RISC-V: c implies zca, and conditionally zcf & zcd

On 7/10/24 4:12 AM, Fei Gao wrote: According to Zc-1.0.4-3.pdf from https://github.com/riscvarchive/riscv-code-size-reduction/releases/tag/v1.0.4-3 The rule is that: - C always implies Zca - C+F implies Zcf (RV32 only) - C+D implies Zcd Signed-off-by: Fei Gao gcc/ChangeLog: * common

[PATCH] opts: allow -gctf, -gbtf, -gdwarf simultaneously

[This is a resend of a patch previously sent as: PATCH v4 6/6 opts: allow any combination of DWARF,CTF,BTF https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654253.html] Previously it was not supported to generate both CTF and BTF debug info in the same compiler run, as both formats made i

Re: [PATCH] fixincludes: skip stdio_stdarg_h on darwin

Hi FX, > On 10 Jul 2024, at 16:25, FX Coudert wrote: > > I found another useless fixincludes on darwin, but this one was a bit harder > to diagnose. GCC trunk applies a fix to on modern Darwin: it is > stdio_stdarg_h. That fix is actually part of a pair, along with > stdio_va_list, and they

[PATCH] internal-fn: Reuse SUBREG_PROMOTED_VAR_P handling

expand_fn_using_insn has code to handle SUBREG_PROMOTED_VAR_P destinations. Specifically, for: (subreg/v:M1 (reg:M2 R) ...) it creates a new temporary register T, uses it for the output operand, then sign- or zero-extends the M1 lowpart of T to M2, storing the result in R. This patch splits t

Re: [PATCH] recog: Handle some mode-changing hardreg propagations

On 7/10/24 9:32 AM, Richard Sandiford wrote: insn_propagation would previously only replace (reg:M H) with X for some hard register H if the uses of H were also in mode M. This patch extends it to handle simple mode punning too. The original motivation was to try to get rid of the execution f

[PATCH] recog: Handle some mode-changing hardreg propagations

insn_propagation would previously only replace (reg:M H) with X for some hard register H if the uses of H were also in mode M. This patch extends it to handle simple mode punning too. The original motivation was to try to get rid of the execution frequency test in aarch64_split_simd_shift_p, but d

[PATCH] fixincludes: skip stdio_stdarg_h on darwin

I found another useless fixincludes on darwin, but this one was a bit harder to diagnose. GCC trunk applies a fix to on modern Darwin: it is stdio_stdarg_h. That fix is actually part of a pair, along with stdio_va_list, and they appear to work around issues with some old Unix (or BSD?) headers

Re: [PATCH] c++, contracts: Fix ICE in create_tmp_var [PR113968]

On 7/10/24 5:37 AM, Nina Dinka Ranns wrote: On Tue, 9 Jul 2024 at 22:50, Jason Merrill > wrote: On 7/9/24 6:41 AM, Nina Dinka Ranns wrote: > On Mon, 8 Jul 2024 at 16:01, Jason Merrill mailto:ja...@redhat.com> >

Re: [PATCH] fixincludes: add bypass to darwin_objc_runtime_1

Thanks, pushed as https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8326956159053b215b5cfe6cd41bfceff413491e FX

Re: mve: Fix vsetq_lane for 64-bit elements with lane 1 [PR 115611]

On 26/06/2024 13:20, Andre Vieira (lists) wrote: > This patch fixes the backend pattern that was printing the wrong input > scalar register pair when inserting into lane 1. > > Added a new test to force float-abi=hard so we can use scan-assembler to check > correct codegen. > > Regression tested

Re: [PATCH] fixincludes: add bypass to darwin_objc_runtime_1

> On 10 Jul 2024, at 14:09, FX Coudert wrote: > > The header that this fix applies to has been fixed in macOS > 15 beta SDK. Therefore, we can include a bypass. shame it’s not fixed earlier :( > Tested on aarch64-apple-darwin24. OK to push? yes OK for tunk (and backports perhaps once mac

[PATCH 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 00/10] Make `dot_prod' a convert-type optab

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 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): Deleted. (usdot_prodv2siv8qi): New. (sdot_prod

[PATCH 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): Deleted. (sdot_prodsiv2hi): New. (udot_prodv

[PATCH 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 08/10] altivec: 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/rs6000/altivec.md (udot_prod): Deleted. (udot_prodv4si): New. (sdot_prodv8hi

[PATCH 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): Deleted. (sdot_prodsiv2hi): New. --- gcc/config/c6x/c6x

[PATCH 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): Deleted. (sdot_prodv2siv4hi): New. --- gcc/co

[PATCH 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 target, for a given architecture, different relationships between output modes and input modes. This is made clearer by way of example. Previously, on AArch64, the following loop was

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

Re: Ping^3 [PATCH-1v3] Value Range: Add range op for builtin isinf

On Wed, 2024-07-10 at 21:54 +0800, Xi Ruoyao wrote: > On Mon, 2024-07-01 at 09:11 +0800, HAO CHEN GUI wrote: > > Hi, > >   Gently ping it. > > https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653096.html > > I guess you can add PR114678 into the subject and the ChangeLog, and > also mention the

RE: [PATCH]middle-end: Implement conditonal store vectorizer pattern [PR115531]

Sorry missed a review comment to change !DR_IS_WRITE into DR_IS_READ. Updated patch: Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. Ok for master? Thanks, Tamar gcc/ChangeLog: PR tree-optimization/115531 * tree-vect-patterns.cc (vect_cond_store_pattern_same_re

Re: Ping^3 [PATCH-1v3] Value Range: Add range op for builtin isinf

On Mon, 2024-07-01 at 09:11 +0800, HAO CHEN GUI wrote: > Hi, >   Gently ping it. > https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653096.html I guess you can add PR114678 into the subject and the ChangeLog, and also mention the patch in the bugzilla. -- Xi Ruoyao School of Aerospace Scienc

Re: testsuite: Remove no_fsanitize_address install directory dependency

On 7/10/24 13:42, Rainer Orth wrote: N.b. one alternative would be to remove this effective target and try to move all tests which currently use this into directories which run their tests between calls to `asan_finish` and `asan_init`. This seems like it might ensure a clearer division of "asan

[r15-1936 Regression] FAIL: gcc.target/i386/avx512vl-vpmovuswb-2.c execution test on Linux/x86_64

On Linux/x86_64, 80e446e829d818dc19daa6e671b9626e93ee4949 is the first bad commit commit 80e446e829d818dc19daa6e671b9626e93ee4949 Author: Pan Li Date: Fri Jul 5 20:36:35 2024 +0800 Match: Support form 2 for the .SAT_TRUNC caused FAIL: gcc.target/i386/avx512f-vpmovusqb-2.c execution test

[PATCH 1/1] AArch64: Add LUTI ACLE for SVE2

This patch introduces support for LUTI2/LUTI4 ACLE for SVE2. LUTI instructions are used for efficient table lookups with 2-bit or 4-bit indices. LUTI2 reads indexed 8-bit or 16-bit elements from the low 128 bits of the table vector using packed 2-bit indices, while LUTI4 can read from the low 128

[PATCH 0/1] AArch64: LUTI2/LUTI4 ACLE for SVE2

From: Vladimir Miloserdov Hi All, This patch introduces support for LUTI2/LUTI4 ACLE for SVE2. LUTI instructions are used for efficient table lookups with 2-bit or 4-bit indices. LUTI2 reads indexed 8-bit or 16-bit elements from the low 128 bits of the table vector using packed 2-bit indices, w

[PATCH] fixincludes: add bypass to darwin_objc_runtime_1

The header that this fix applies to has been fixed in macOS 15 beta SDK. Therefore, we can include a bypass. Tested on aarch64-apple-darwin24. OK to push? FX 0001-fixincludes-add-bypass-to-darwin_objc_runtime_1.patch Description: Binary data

Re: [Fortran, Patch, PR82904] Fix [11/12/13/14/15 Regression][Coarray] ICE in make_ssa_name_fn, at tree-ssanames.c:261

On Wed, 10 Jul 2024, Andre Vehreschild wrote: > Hi all, > > the patch attached fixes the use of an uninitialized variable for the string > length in the declaration of the char[1:_len] type (the _len!). The type for > save'd deferred length char arrays is now char*, so that there is no need for >

[Fortran, Patch, PR82904] Fix [11/12/13/14/15 Regression][Coarray] ICE in make_ssa_name_fn, at tree-ssanames.c:261

Hi all, the patch attached fixes the use of an uninitialized variable for the string length in the declaration of the char[1:_len] type (the _len!). The type for save'd deferred length char arrays is now char*, so that there is no need for the length in the type declaration anymore. The length is

RE: [PATCH 2/3] Support group-size of three in SLP load permutation lowering

On Wed, 10 Jul 2024, Tamar Christina wrote: > > -Original Message- > > From: Richard Biener > > Sent: Wednesday, July 10, 2024 10:04 AM > > To: gcc-patches@gcc.gnu.org > > Subject: [PATCH 2/3] Support group-size of three in SLP load permutation > > lowering > > > > The following adds su

Re: testsuite: Remove no_fsanitize_address install directory dependency

Hi Matthew, > The current no_fsanitize_address effective target check (implemented in > target-supports.exp rather than in asan.exp) has some problems with the > link path. > > Because it is not called from in between asan_init and asan_finish the > link paths of the compiler are not changed to po

Re: testsuite: Remove no_fsanitize_address install directory dependency

... Oops, just after sending I noticed that `check_effective_target_fsanitize_address_compilation` is caching its result under the same name as the original `check_effective_target_fsanitize_address` in `asan-dg.exp`. Attaching an updated patch (with updated cover letter) that adjusts the pro

Re: [PATCH] Add gcc.gnu.org account names to MAINTAINERS

On Wed, Jul 10, 2024 at 12:36:15PM +0100, Richard Sandiford wrote: > The account names in the file were taken from a trawl of the > gcc-cvs archives, with a very small number of manual edits for > ambiguities. There are a handful of names that I couldn't find; > the new column has "-" for those.

[PATCH] tree-optimization/115825 - improve unroll estimates for volatile accesses

The loop unrolling code assumes that one third of all volatile accesses can be possibly optimized away which is of course not true. This leads to excessive unrolling in some cases. The following tracks the number of stmts with side-effects as those are not eliminatable later and only assumes one

testsuite: Remove no_fsanitize_address install directory dependency

The current no_fsanitize_address effective target check (implemented in target-supports.exp rather than in asan.exp) has some problems with the link path. Because it is not called from in between asan_init and asan_finish the link paths of the compiler are not changed to point at the build directo

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

On Mon, Jun 10, 2024 at 05:08:21PM +0100, Andrew Carlotti wrote: > > On Tue, Apr 30, 2024 at 05:10:45PM +0100, Andrew Carlotti wrote: > > Add target_version attribute to Common Function Attributes and update > > target and target_clones documentation. Move shared detail and examples > > to the

[committed] arm: cleanup legacy ARM_PE code

The arm 'pe' target was removed back in 2012 when the FPA support was removed, but in a small number of places some conditional code was accidentally left behind. It's no-longer needed, so remove it. gcc/ChangeLog: * config/arm/arm-protos.h (arm_dllexport_name_p): Remove prototype.

Re: [PATCH 2/2]AArch64: implement TARGET_VECTORIZE_CONDITIONAL_OPERATION_IS_EXPENSIVE [PR115531].

Tamar Christina writes: > Hi All, > > This implements the new target hook indicating that for AArch64 when possible > we prefer masked operations for any type vs doing LOAD + SELECT or > SELECT + STORE. > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > > Ok for master? > > Than

RE: [PATCH 2/3] Support group-size of three in SLP load permutation lowering

> -Original Message- > From: Richard Biener > Sent: Wednesday, July 10, 2024 10:04 AM > To: gcc-patches@gcc.gnu.org > Subject: [PATCH 2/3] Support group-size of three in SLP load permutation > lowering > > The following adds support for group-size three in SLP load permutation > lowering

[PATCH] aarch64: Avoid alloca in target attribute parsing

The handling of the target attribute used alloca to allocate a copy of unverified user input, which could exhaust the stack if the input is too long. This patch converts it to auto_vecs instead. I wondered about converting it to use std::string, which we already use elsewhere, but that would be m

Re: [PATCH v1] Vect: Promote unsigned .SAT_ADD constant operand for vectorizable_call

On Wed, Jul 10, 2024 at 11:28 AM wrote: > > From: Pan Li > > The .SAT_ADD has 2 operand and one of the operand may be INTEGER_CST. > For example _1 = .SAT_ADD (_2, 9) comes from below sample code. > > Form 3: > #define DEF_VEC_SAT_U_ADD_IMM_FMT_3(T, IMM) \ > T __attri

Re: [match.pd PATCH] PR tree-optimization/114661: Generalize MULT_EXPR recognition.

On Wed, Jul 10, 2024 at 12:28 AM Roger Sayle wrote: > > > This patch resolves PR tree-optimization/114661, by generalizing the set > of expressions that we canonicalize to multiplication. This extends the > optimization(s) contributed (by me) back in July 2021. > https://gcc.gnu.org/pipermail/gcc

Re: [PATCH v3] Vect: Optimize truncation for .SAT_SUB operands

On Tue, Jul 9, 2024 at 6:03 AM wrote: > > From: Pan Li > > To get better vectorized code of .SAT_SUB, we would like to avoid the > truncated operation for the assignment. For example, as below. > > unsigned int _1; > unsigned int _2; > unsigned short int _4; > _9 = (unsigned short int).SAT_SUB

Lower zeroing array assignment to memset for allocatable arrays

Hi, The attached patch lowers zeroing array assignment to memset for allocatable arrays. For example: subroutine test(z, n) implicit none integer :: n real(4), allocatable :: z(:,:,:) allocate(z(n, 8192, 2048)) z = 0 end subroutine results in following call to memset instead

Re: [RFC] Proposal to support Packed Boolean Vector masks.

On Wed, Jul 10, 2024 at 12:44 PM Richard Sandiford wrote: > > Tejas Belagod writes: > > On 7/10/24 2:38 PM, Richard Biener wrote: > >> On Wed, Jul 10, 2024 at 10:49 AM Tejas Belagod > >> wrote: > >>> > >>> On 7/9/24 4:22 PM, Richard Biener wrote: > On Tue, Jul 9, 2024 at 11:45 AM Tejas Bel

Re: [PATCH v2] Fix Xcode 16 build break with NULL != nullptr

On Wed, Jul 10, 2024 at 12:23 PM Iain Sandoe wrote: > > Hello Daniel, > > Thanks for the patch! > > > On 10 Jul 2024, at 10:43, Daniel Bertalan wrote: > > > > As of Xcode 16 beta 2 with the macOS 15 SDK, each re-inclusion of the > > stddef.h header causes the NULL macro in C++ to be re-defined to

[PATCH 2/2]AArch64: implement TARGET_VECTORIZE_CONDITIONAL_OPERATION_IS_EXPENSIVE [PR115531].

Hi All, This implements the new target hook indicating that for AArch64 when possible we prefer masked operations for any type vs doing LOAD + SELECT or SELECT + STORE. Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. Ok for master? Thanks, Tamar gcc/ChangeLog: PR tree-

  1   2   >