Re: [PATCH][v2] Handle NULL stmt in SLP_TREE_SCALAR_STMTS

On Wed, 3 Jul 2024, Richard Sandiford wrote: > Richard Biener writes: > > The following starts to handle NULL elements in SLP_TREE_SCALAR_STMTS > > with the first candidate being the two-operator nodes where some > > lanes are do-not-care and also do not have a scalar stmt computing > > the resul

[PATCH] [committed] Use __builtin_cpu_support instead of __get_cpuid_count.

>> Hmm, now all avx512 tests SIGILL when testing with -m32: >> >> Dump of assembler code for function __get_cpuid_count: >> => 0x08049500 <+0>:     kmovd  %eax,%k2 >>    0x08049504 <+4>:     kmovd  %edx,%k1 >>    0x08049508 <+8>:     pushf >>    0x08049509 <+9>:     pushf >>    0x0804950a <+10>:  

Ping^5: [PATCH 0/2] Fix two test failures with --enable-default-pie [PR70150]

Ping^5 https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650763.html On Mon, 2024-05-06 at 12:45 +0800, Xi Ruoyao wrote: > In GCC 14.1-rc1, there are two new (comparing to GCC 13) failures if > the build is configured --enable-default-pie.  Let's fix them. > > Tested on x86_64-linux-gnu.  Ok for

Re: [PATCH v2] RISC-V: use fclass insns to implement isfinite and isnormal builtins

On Sun, 2024-06-30 at 17:47 -0700, Vineet Gupta wrote: >   - Don't hardcode SI in patterns, try to keep X to avoid potential >     sign extension pitfalls. Implementation wise requires skipping >     :MODE specifier in match_operand which is flagged as missing mode >     warning. I'm unsure about

[PATCH V2] fsra: gimple final sra pass for paramters and returns

Hi, There are a few PRs (meta-bug PR101926) about accessing aggregate param/returns which are passed through registers. We could use the current SRA pass in a special mode right before RTL expansion for the incoming/outgoing part, as the talked at: https://gcc.gnu.org/pipermail/gcc-patches/2023-N

Support bitwise and/andnot/abs/neg/copysign/xorsign op for V8BF/V16BF/V32BF

This patch extends support for BF16 vector operations in GCC, including bitwise AND, ANDNOT, ABS, NEG, COPYSIGN, and XORSIGN for V8BF, V16BF, and V32BF modes. Bootstrapped and tested on x86_64-linux-gnu. ok for trunk? gcc/ChangeLog: * config/i386/i386-expand.cc (ix86_expand_fp_absneg_ope

[committed] Fix newlib build failure with rx as well as several dozen testsuite failures

The rx port has been failing to build newlib for a bit over a week. I can't remember if it was the late-combine work or the IRA costing twiddle, regardless the real bug is in the rx backend. Basically dwarf2cfi is blowing up because of inconsistent state caused by the failure to mark a stack

Re: [PATCH] [APX PPX] Avoid generating unmatched pushp/popp in pro/epilogue

On Tue, Jul 2, 2024 at 11:24 AM Hongyu Wang wrote: > > Hi, > > According to APX spec, the pushp/popp pairs should be matched, > otherwise the PPX hint cannot take effect and cause performance loss. > > In the ix86_expand_epilogue, there are several optimizations that may > cause the epilogue using

RE: [PATCH v2] RISC-V: Implement the .SAT_TRUNC for scalar

> But if you look at what the hardware can actually support, it doesn't > have HImode or QImode operations other than load/store and for rv64 > there are no SImode logicals. > That's what WORD_REGISTER_OPERATIONS is designed to support. Regardless > of what happens at the source level, the gen

[pushed] c++: CTAD and trait built-ins

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- While poking at 101232 I noticed that we started trying to parse __is_invocable(_Fn, _Args...) as a functional cast to a CTAD placeholder type; we shouldn't consider CTAD for a template that shares a name (reserved for the implementation) wi

[pushed] c++: OVERLOAD in diagnostics

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- In modules we can get an OVERLOAD around a non-function, so let's tail recurse instead of falling through. As a result we start printing the template header in this testcase. gcc/cp/ChangeLog: * error.cc (dump_decl) [OVERLOAD]: Re

Re: [PATCH][committed] Move runtime check into a separate function and guard it with target ("no-avx")

On Thu, Jul 4, 2024 at 9:41 AM H.J. Lu wrote: > > > On Thu, Jul 4, 2024, 9:12 AM Hongtao Liu wrote: >> >> On Thu, Jul 4, 2024 at 6:17 AM H.J. Lu wrote: >> > >> > >> > On Wed, Jul 3, 2024, 9:37 PM Richard Biener >> > wrote: >> >> >> >> On Wed, Jul 3, 2024 at 9:25 AM liuhongt wrote: >> >> > >>

Re: [PATCH v2] RISC-V: Implement the .SAT_TRUNC for scalar

On 7/3/24 6:48 PM, Li, Pan2 wrote: Thanks Jeff for comments. I would expect that QI/HI shouldn't be happening in practice due to the definition of WORD_REGISTER_OPERATIONS. Sorry I don't get the point here, I suppose there may be 6 kinds of truncation for scalar. uint64_t => uint32_t ui

Re: [PATCH][committed] Move runtime check into a separate function and guard it with target ("no-avx")

On Thu, Jul 4, 2024, 9:12 AM Hongtao Liu wrote: > On Thu, Jul 4, 2024 at 6:17 AM H.J. Lu wrote: > > > > > > On Wed, Jul 3, 2024, 9:37 PM Richard Biener > wrote: > >> > >> On Wed, Jul 3, 2024 at 9:25 AM liuhongt wrote: > >> > > >> > The patch can avoid SIGILL on non-AVX512 machine due to kmovd

[PATCH V2] x86: Update branch hint for Redwood Cove.

From: "H.J. Lu" >The above reads like it would be worth splitting branc_prediction_hits >into branch_prediction_hints_taken and branch_prediction_hints_not_taken >given not-taken is the default and thus will just increase code size? >According to Intel® 64 and IA-32 Architectures Optimization Ref

Re: [PATCH][committed] Move runtime check into a separate function and guard it with target ("no-avx")

On Thu, Jul 4, 2024 at 6:17 AM H.J. Lu wrote: > > > On Wed, Jul 3, 2024, 9:37 PM Richard Biener > wrote: >> >> On Wed, Jul 3, 2024 at 9:25 AM liuhongt wrote: >> > >> > The patch can avoid SIGILL on non-AVX512 machine due to kmovd is >> > generated in dynamic check. >> > >> > Committed as an obv

RE: [PATCH v2] RISC-V: Implement the .SAT_TRUNC for scalar

Thanks Jeff for comments. > I would expect that QI/HI shouldn't be happening in practice due to the > definition of WORD_REGISTER_OPERATIONS. Sorry I don't get the point here, I suppose there may be 6 kinds of truncation for scalar. uint64_t => uint32_t uint64_t => uint16_t uint64_t => uin

Re: [RFC/PATCH] libgcc: sh: Use soft-fp for non-hosted SH3/SH4

Hi! On Wed, 2024-07-03 at 19:28 +0200, Sébastien Michelland wrote: > On 2024-07-03 17:59, Jeff Law wrote: > > On 7/3/24 3:59 AM, Sébastien Michelland wrote: > > > libgcc's fp-bit.c is quite slow and most modern/developed architectures > > > have switched to using the soft-fp library. This patch do

Re: [PATCH 13/13 ver4] rs6000, remove vector set and vector init built-ins

Kewen: On 6/18/24 20:04, Kewen.Lin wrote: Hi Carl, on 2024/6/14 03:40, Carl Love wrote: GCC maintainers: The patch has been updated per the feedback from version 3. Please let me know it the patch is acceptable for mainline. Thanks. Carl --

Re: [PATCH 13/13 ver5] rs6000, remove vector set and vector init built-ins.

 GCC maintainers: The patch has been updated to remove the customized vec_init built-in code.  Specfivically the init identifier, the related generated code for the init built-in attribute bit, function altivec_expand_vec_init_builtin and calls to the function. Please let me know if the patc

Re: [PATCH 4/13 ver5] rs6000, extend the current vec_{un, }signed{e, o} built-ins

GCC maintainers: I moved the removal of built-ins __builtin_vsx_xvcvdpsxws and __builtin_vsx_xvcvdpuxws from patch 4 to  patch patch 2. I fixed various issues with the ChangeLog wording, spaces and descriptions. Fixed the comments in file gcc/config/rs6000/vsx.md. Updated the built-in desc

Re: [PATCH] testsuite: Fix pr115278.cc test when uint32_t isn't unsigned int

Thiago Jung Bauermann writes: > --- a/gcc/testsuite/g++.dg/vect/pr115278.cc > +++ b/gcc/testsuite/g++.dg/vect/pr115278.cc > @@ -2,6 +2,7 @@ > // { dg-require-effective-target c++11 } > // { dg-additional-options "-fdump-tree-optimized" } > > +#include > #include > > const int runs = 92;

Re: [PATCH 2/13 ver5] rs6000, __builtin_vsx_xvcv{sp{sx,u}ws,dpuxds_uns}

GCC maintainers: Per the comments on patch 2 from version 4, I have moved the removal of built-ins __builtin_vsx_xvcvdpsxws and __builtin_vsx_xvcvdpuxws from patch 4 to this patch. Please let me know if this patch is acceptable. Thanks. Carl -

Re: [PATCH 3/3] [x86] Enable flate-combine.

On Wed, Jul 3, 2024 at 4:25 PM Iain Sandoe wrote: > > > > > On 28 Jun 2024, at 07:03, Uros Bizjak wrote: > > > > On Fri, Jun 28, 2024 at 7:29 AM liuhongt wrote: > >> > >> Move pass_stv2 and pass_rpad after pre_reload pass_late_combine, also > >> define target_insn_cost to prevent post_reload pas

Re: [PATCH 3/3] [x86] Enable flate-combine.

> On 28 Jun 2024, at 07:03, Uros Bizjak wrote: > > On Fri, Jun 28, 2024 at 7:29 AM liuhongt wrote: >> >> Move pass_stv2 and pass_rpad after pre_reload pass_late_combine, also >> define target_insn_cost to prevent post_reload pass_late_combine to >> revert the optimziation did in pass_rpad. >

[PATCH] testsuite: Fix pr115278.cc test when uint32_t isn't unsigned int

On arm-none-eabi, g++.dg/vect/pr115278.cc fails with: FAIL: g++.dg/vect/pr115278.cc -std=c++14 (test for excess errors) Excess errors: /path/to/gcc.git/gcc/testsuite/g++.dg/vect/pr115278.cc:24:28: error: invalid conversion from 'volatile unsigned int*' to 'volatile uint32_t*' {aka 'volatile lon

[PATCH 0/13 ver5] rs6000, built-in cleanup patch series

GCC maintainers: The following is the updates to the three patches that have yet to be approved. Patches 1, 3, 5, 6, 8, 9, 10, and 12 were approved in the version 3 or earlier. Patches 7 and 11 from version 4 were approved with minor nits fixed. This leaves patches 2, 4 and 13 still to be appr

Re: [PATCH][committed] Move runtime check into a separate function and guard it with target ("no-avx")

On Wed, Jul 3, 2024, 9:37 PM Richard Biener wrote: > On Wed, Jul 3, 2024 at 9:25 AM liuhongt wrote: > > > > The patch can avoid SIGILL on non-AVX512 machine due to kmovd is > > generated in dynamic check. > > > > Committed as an obvious fix. > > Hmm, now all avx512 tests SIGILL when testing with

[OG14] Fortran/OpenMP: Support mapping of DT with allocatable components: disable 'generate_callback_wrapper' for nvptx target (was: [Patch][Stage 1] Fortran/OpenMP: Support mapping of DT with allocat

Hi Tobias! I've compared test results for nvptx target for GCC 14 vs. the new OG14, and ran into a number of unexpected regressions: thousands of compilation PASS -> FAIL in the Fortran testsuite. The few that I looked at were all like: ptxas /tmp/ccAMr7D9.o, line 63; error : Illegal opera

Re: [PATCH] RISC-V: Add basic support for the Zacas extension

Regarding the amocas.q follow-up patch: I'm having trouble with matching any TImode compare-and-swap patterns. Here's the RTL I'm trying: (define_mode_iterator SUPERGPR [SI DI TI]) (define_insn "zacas_atomic_cas_value" [(set (match_operand:SUPERGPR 0 "register_operand" "=&r") (match_ope

Re: [PATCH v2] c++: remove Concepts TS code

On 6/14/24 12:56 PM, Marek Polacek wrote: On Mon, Jun 10, 2024 at 10:23:37PM -0400, Jason Merrill wrote: On 6/10/24 11:13, Marek Polacek wrote: On Mon, Jun 10, 2024 at 10:22:11AM -0400, Patrick Palka wrote: On Fri, 7 Jun 2024, Marek Polacek wrote: @@ -3940,9 +3936,6 @@ find_parameter_packs_r

[patch,avr] Implement PR90616: Improve adding symbols that are 256-byte aligned

Address computation (usually add) with symbols that are aligned to 256 bytes does not require to add the lo8() part as it is zero. This patch adds a new combine insn that performs a widening add from QImode plus such a symbol. The case when such an aligned symbol is added to a reg that's already

Re: [patch,avr] PR87376: Disable -ftree-ter

Am 03.07.24 um 21:39 schrieb Jeff Law: On 7/3/24 1:26 PM, Georg-Johann Lay wrote: Am 02.07.24 um 15:48 schrieb Richard Biener: On Tue, Jul 2, 2024 at 3:43 PM Georg-Johann Lay wrote: Hi Jeff, This is a patch to get correct code out of 64-bit loads from address-space __memx. The AVR a

Re: [patch,avr] PR87376: Disable -ftree-ter

On 7/3/24 1:26 PM, Georg-Johann Lay wrote: Am 02.07.24 um 15:48 schrieb Richard Biener: On Tue, Jul 2, 2024 at 3:43 PM Georg-Johann Lay wrote: Hi Jeff, This is a patch to get correct code out of 64-bit loads from address-space __memx. The AVR address-spaces may require that move insns

Re: [patch,avr] PR87376: Disable -ftree-ter

Am 02.07.24 um 15:48 schrieb Richard Biener: On Tue, Jul 2, 2024 at 3:43 PM Georg-Johann Lay wrote: Hi Jeff, This is a patch to get correct code out of 64-bit loads from address-space __memx. The AVR address-spaces may require that move insns issue calls to library support functions, a fa

Re: [PATCH v2] diagnostics: Follow DECL_ORIGIN in lhd_decl_printable_name [PR102061]

3 Jul 2024 3:10:14 pm Peter Damianov : Currently, if a warning references a cloned function, the name of the cloned function will be emitted in the "In function 'xyz'" part of the diagnostic, which users aren't supposed to see. This patch follows the DECL_ORIGIN link to get the name of the or

Re: [PATCH] RISC-V: use fclass insns to implement isfinite and isnormal builtins

On Fri, 2024-06-28 at 17:53 -0700, Vineet Gupta wrote: > I was also hoping to get __builtin_inf() done but unforutnately it > requires little more rtl foo/bar to implement a tri-modal return. Hmm do we really need to care the symbol? The generic __builtin_isinf does not care the symbol anyway: ht

Re: [PATCH] [i386] restore recompute to override opts after change [PR113719]

Hi Alexandre, > On Jun 27, 2024, Hongtao Liu wrote: > >> LGTM, thanks. > >> On Thu, Jun 13, 2024 at 3:32 PM Alexandre Oliva wrote: > >>> for gcc/ChangeLog >>> >>> PR target/113719 >>> * config/i386/i386-options.cc >>> (ix86_override_options_after_change_1): Add opts and opts_set >>> parms, ope

Re: [PATCH][v2] Handle NULL stmt in SLP_TREE_SCALAR_STMTS

Richard Biener writes: > The following starts to handle NULL elements in SLP_TREE_SCALAR_STMTS > with the first candidate being the two-operator nodes where some > lanes are do-not-care and also do not have a scalar stmt computing > the result. I originally added SLP_TREE_SCALAR_STMTS to two-oper

[committed] Fix previously latent bug in reorg affecting cris port

The late-combine patch has triggered a previously latent bug in reorg. Basically we have a sequence like this in the middle of reorg before we start relaxing delay slots (cris-elf, gcc.dg/torture/pr98289.c) (insn 67 49 18 (sequence [ (jump_insn 50 49 52 (set (pc)

[PATCH] RISC-V: Add basic support for the Zacas extension

From: Gianluca Guida This patch adds support for amocas.{b|h|w|d}. Support for amocas.q (64/128 bit cas for rv32/64) will be added in a future patch. Extension: https://github.com/riscv/riscv-zacas Ratification: https://jira.riscv.org/browse/RVS-680 gcc/ChangeLog: * common/config/riscv

Re: [PATCH v5] c++: fix constained auto deduction in templ spec scopes [PR114915]

On Fri, 14 Jun 2024, Seyed Sajad Kahani wrote: > When deducing auto for `adc_return_type`, `adc_variable_type`, and > `adc_decomp_type` contexts (at the usage time), we try to resolve the > outermost > template arguments to be used for satisfaction. This is done by one of the > following, dependi

Re: [PATCH] rs6000, update vec_ld, vec_lde, vec_st and vec_ste, documentation

On 7/3/24 2:36 AM, Kewen.Lin wrote: Hi Carl, on 2024/6/27 01:05, Carl Love wrote: GCC maintainers: The following patch updates the user documentation for the vec_ld, vec_lde, vec_st and vec_ste built-ins to make it clearer that there are data alignment requirements for these built-ins. If

Re: [PATCH][c++ frontend]: check for missing condition for novector [PR115623]

On 6/27/24 11:25 AM, Tamar Christina wrote: -Original Message- From: Jason Merrill Sent: Tuesday, June 25, 2024 10:24 PM To: Tamar Christina Cc: gcc-patches@gcc.gnu.org; nd ; nat...@acm.org Subject: Re: [PATCH][c++ frontend]: check for missing condition for novector [PR115623] On 6/25/

Re: [RFC/PATCH] libgcc: sh: Use soft-fp for non-hosted SH3/SH4

On 2024-07-03 17:59, Jeff Law wrote: On 7/3/24 3:59 AM, Sébastien Michelland wrote: libgcc's fp-bit.c is quite slow and most modern/developed architectures have switched to using the soft-fp library. This patch does so for free-standing/unknown-OS SH3/SH4 builds, using soft-fp's default paramet

Re: [PATCH] c++: array new with value-initialization [PR115645]

On 7/2/24 4:43 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/branches? OK. -- >8 -- This extends the r11-5179 fix which doesn't work with multidimensional arrays. In particular, struct S { explicit S() { } }; auto p = new S[1][1](); shou

Re: [PATCH] c++, v2: Implement C++26 CWG2819 - Allow cv void * null pointer value conversion to object types in constant expressions

On 7/3/24 11:56 AM, Jakub Jelinek wrote: On Wed, Jul 03, 2024 at 11:35:26AM -0400, Jason Merrill wrote: This patch should also remove the integer_zerop diagnostic lower in the function, which becomes dead code with this change. So like this? Passed quick testing, ok if it passes full bootstrap

Re: [PATCH] c++, libstdc++: Implement C++26 P2747R2 - constexpr placement new [PR115744]

On Wed, 3 Jul 2024 at 16:51, Jakub Jelinek wrote: > > On Wed, Jul 03, 2024 at 11:41:58AM -0400, Jason Merrill wrote: > > On 7/3/24 10:37 AM, Jakub Jelinek wrote: > > > +#if __cpp_lib_constexpr_new >= 202406L > > > +# define _GLIBCXX_PLACEMENT_CONSTEXPR constexpr > > > +#else > > > +# define _GLIBCX

[Committed] RISC-V: Describe -march behavior for dependent extensions

Committed. Patrick On 7/2/24 18:29, Kito Cheng wrote: LGTM, BTW, based on the discussion[1], my understanding is: depend == require == imply for the RISC-V ISA spec. [1] https://github.com/riscv/riscv-v-spec/issues/723#issuecomment-922153867 On Wed, Jul 3, 2024 at 9:21 AM Patrick O'Neill

[Committed] RISC-V: Add support for Zabha extension

Committed w/ fixup to changelog to add missing: * lib/target-supports.exp: Add zabha testsuite infra support. Patrick On 7/2/24 18:05, Patrick O'Neill wrote: From: Gianluca Guida The Zabha extension adds support for subword Zaamo ops. Extension: https://github.com/riscv/riscv-zabha.git Ratif

Re: [RFC/PATCH] libgcc: sh: Use soft-fp for non-hosted SH3/SH4

On 7/3/24 3:59 AM, Sébastien Michelland wrote: libgcc's fp-bit.c is quite slow and most modern/developed architectures have switched to using the soft-fp library. This patch does so for free-standing/unknown-OS SH3/SH4 builds, using soft-fp's default parameters for the most part, most notably

[PATCH] c++, v2: Implement C++26 CWG2819 - Allow cv void * null pointer value conversion to object types in constant expressions

On Wed, Jul 03, 2024 at 11:35:26AM -0400, Jason Merrill wrote: > This patch should also remove the integer_zerop diagnostic lower in the > function, which becomes dead code with this change. So like this? Passed quick testing, ok if it passes full bootstrap/regtest? 2024-07-03 Jakub Jelinek

Re: [PATCH] c++, libstdc++: Implement C++26 P2747R2 - constexpr placement new [PR115744]

On Wed, Jul 03, 2024 at 11:41:58AM -0400, Jason Merrill wrote: > On 7/3/24 10:37 AM, Jakub Jelinek wrote: > > +#if __cpp_lib_constexpr_new >= 202406L > > +# define _GLIBCXX_PLACEMENT_CONSTEXPR constexpr > > +#else > > +# define _GLIBCXX_PLACEMENT_CONSTEXPR inline > > +#endif > > I'm a bit curious

Re: [PATCH] ARC: Update gcc.target/arc/pr9001184797.c test

On 7/3/24 8:24 AM, Luis Silva wrote: ... to comply with new standards due to stricter analysis in the latest GCC versions. gcc/testsuite/ChangeLog: * gcc.target/arc/pr9001184797.c: (Fix compiler warnings) I fixed the ChangeLog entry and pushed this to the trunk for you. I guess we

Re: [PATCH] c++, libstdc++: Implement C++26 P2747R2 - constexpr placement new [PR115744]

On 7/3/24 10:37 AM, Jakub Jelinek wrote: +#if __cpp_lib_constexpr_new >= 202406L +# define _GLIBCXX_PLACEMENT_CONSTEXPR constexpr +#else +# define _GLIBCXX_PLACEMENT_CONSTEXPR inline +#endif I'm a bit curious why you want constexpr *or* inline rather than leaving the inline keyword on the decl

Re: [PATCH 1/3] libstdc++: Use RAII in

On Wed, 3 Jul 2024 at 18:33, Jonathan Wakely wrote: > > On Thu, 27 Jun 2024 at 11:52, Jonathan Wakely wrote: > > > > This refactoring to use RAII doesn't seem to make any difference in > > benchmarks, although the generated code for some std::vector operations > > seems to be slightly larger. Mayb

Re: [PATCH] c++: Implement C++26 CWG2819 - Allow cv void * null pointer value conversion to object types in constant expressions

On 7/3/24 10:39 AM, Jakub Jelinek wrote: Hi! The following patch implements CWG2819 (which wasn't a DR because it changes behavior of C++26 only). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-07-03 Jakub Jelinek * constexpr.cc (cxx_eval_constant_express

Re: [PATCH 1/3] libstdc++: Use RAII in

On Thu, 27 Jun 2024 at 11:52, Jonathan Wakely wrote: > > This refactoring to use RAII doesn't seem to make any difference in > benchmarks, although the generated code for some std::vector operations > seems to be slightly larger. Maybe it will be faster (or slower) in some > cases I didn't test? >

[PING*2][PATCH v2] rs6000: ROP - Do not disable shrink-wrapping for leaf functions [PR114759]

Ping * 2. [Message-ID: <1e003d78-3b2e-4263-830a-7c00a3e9d...@linux.ibm.com>] Segher, this resolves the issues you mentioned in your review. Peter On 6/18/24 5:59 PM, Peter Bergner wrote: > Updated patch. This passed bootstrap and regtesting on powerpc64le-linux > with no regressions. Ok fo

Re: [PATCH v2] RISC-V: Implement the .SAT_TRUNC for scalar

On 7/2/24 7:16 PM, Li, Pan2 wrote: Thanks Jeff for comments. Why are you using Pmode? Pmode is for pointers. This stuff looks like basic integer ops, so I don't see why Pmode is appropriate. The incoming operand may be HI/QI/SImode, so we need to prompt the mode. So there we should take

Re: [PATCH] rs6000: ROP - Emit hashst and hashchk insns on Power8 and later [PR114759]

On 7/3/24 4:01 AM, Kewen.Lin wrote: >> - if (TARGET_POWER10 >> + if (TARGET_POWER8 >>&& info->calls_p >>&& DEFAULT_ABI == ABI_ELFv2 >>&& rs6000_rop_protect) > > Nit: I noticed that this is the only place to change > info->rop_hash_size to non-zero, and ... > >> @@ -3277,

Re: [PATCH] c++, libstdc++: Implement C++26 P2747R2 - constexpr placement new [PR115744]

On Wed, 3 Jul 2024 at 15:37, Jakub Jelinek wrote: > > Hi! > > With the PR115754 fix in, constexpr placement new mostly just works, > so this patch just adds constexpr keyword to the placement new operators > in , adds FTMs and testsuite coverage. > > There is one accepts-invalid though, the > new

RE: [PATCH v1] RISC-V: Bugfix vfmv insn honor zvfhmin for FP16 SEW [PR115763]

Committed, thanks Juzhe and Kito. Let’s wait for a while before backport to 14. I suspect there may be similar cases for other insn(s), will double check and fix first. Pan From: Kito Cheng Sent: Wednesday, July 3, 2024 10:32 PM To: juzhe.zh...@rivai.ai Cc: Li, Pan2 ; gcc-patches@gcc.gnu.org;

[PATCH] c++: Implement C++26 CWG2819 - Allow cv void * null pointer value conversion to object types in constant expressions

Hi! The following patch implements CWG2819 (which wasn't a DR because it changes behavior of C++26 only). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-07-03 Jakub Jelinek * constexpr.cc (cxx_eval_constant_expression): CWG2819 - Allow cv void * nul

[PATCH] c++, libstdc++: Implement C++26 P2747R2 - constexpr placement new [PR115744]

Hi! With the PR115754 fix in, constexpr placement new mostly just works, so this patch just adds constexpr keyword to the placement new operators in , adds FTMs and testsuite coverage. There is one accepts-invalid though, the new (p + 1) int[]{2, 3}; // error (in this paper) case from the pa

Re: [PATCH v1] RISC-V: Bugfix vfmv insn honor zvfhmin for FP16 SEW [PR115763]

LGTM and ok for gcc 14 as well, btw an idea is that actually could passed via gpr, I mean fpr->gpr and then vmv.v.x, but it's not block commend for this patch. 钟居哲 於 2024年7月3日 週三 22:18 寫道： > LGTM。 > > -- > juzhe.zh...@rivai.ai > > > *From:* pan2.li > *Date:* 2024-07-

[PATCH] ARC: Update gcc.target/arc/pr9001184797.c test

... to comply with new standards due to stricter analysis in the latest GCC versions. gcc/testsuite/ChangeLog: * gcc.target/arc/pr9001184797.c: (Fix compiler warnings) --- gcc/testsuite/ChangeLog | 4 gcc/testsuite/gcc.target/arc/pr9001184797.c | 4 +++- 2 files

Re: [RFC][PATCH v1] Provide more contexts for -Warray-bounds warning messages

> On Jul 2, 2024, at 18:02, David Malcolm wrote: > > On Tue, 2024-07-02 at 16:17 +, Qing Zhao wrote: >> due to code duplication from jump threading [PR109071] >> Control this with a new option -fdiagnostic-try-to-explain-harder. > > The name -fdiagnostic-try-to-explain-harder seems a littl

Re: [PATCH v1] RISC-V: Bugfix vfmv insn honor zvfhmin for FP16 SEW [PR115763]

LGTM。 juzhe.zh...@rivai.ai From: pan2.li Date: 2024-07-03 22:17 To: gcc-patches CC: juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; Pan Li Subject: [PATCH v1] RISC-V: Bugfix vfmv insn honor zvfhmin for FP16 SEW [PR115763] From: Pan Li According to the ISA, the zvfhmin sub extension shoul

[PATCH v1] RISC-V: Bugfix vfmv insn honor zvfhmin for FP16 SEW [PR115763]

From: Pan Li According to the ISA, the zvfhmin sub extension should only contain convertion insn. Thus, the vfmv insn acts on FP16 should not be present when only the zvfhmin option is given. This patch would like to fix it by split the pred_broadcast define_insn into zvfhmin and zvfh part.

[PATCH v2] diagnostics: Follow DECL_ORIGIN in lhd_decl_printable_name [PR102061]

Currently, if a warning references a cloned function, the name of the cloned function will be emitted in the "In function 'xyz'" part of the diagnostic, which users aren't supposed to see. This patch follows the DECL_ORIGIN link to get the name of the original function. gcc/ChangeLog: PR d

RE: [MAINTAINERS] Update my email address

Sorry, forgot to attach diff. -Original Message- From: Prathamesh Kulkarni Sent: Wednesday, July 3, 2024 7:04 PM To: gcc-patches@gcc.gnu.org Subject: [MAINTAINERS] Update my email address External email: Use caution opening links or attachments Pushing to trunk. Signed-off-by: Prath

Re: [PATCH][committed] Move runtime check into a separate function and guard it with target ("no-avx")

On Wed, Jul 3, 2024 at 9:25 AM liuhongt wrote: > > The patch can avoid SIGILL on non-AVX512 machine due to kmovd is > generated in dynamic check. > > Committed as an obvious fix. Hmm, now all avx512 tests SIGILL when testing with -m32: Dump of assembler code for function __get_cpuid_count: => 0x

[MAINTAINERS] Update my email address

Pushing to trunk. Signed-off-by: Prathamesh Kulkarni Thanks, Prathamesh

RE: [PATCH v1] Vect: Distribute truncation into .SAT_SUB operands

Thanks Richard for comments. > Isn't bound < otype_max OK as well? Yes, less than or equal is OK as well. > Given your example I wonder if you instead want to use > vect_look_through_possible_promotion? Because ... > .. if you do it like this the widened op is still there and vectorized > and

RE: [PATCH v2] Vect: Support IFN SAT_TRUNC for unsigned vector int

> OK. Committed, thanks Richard. Pan -Original Message- From: Richard Biener Sent: Wednesday, July 3, 2024 5:06 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 Subject: Re: [P

[PATCH 4/5] Support group-size of three in SLP load permutation lowering

The following adds support for group-size three in SLP load permutation lowering to match the non-SLP capabilities. This is done by using the non-interleaving fallback code which then creates at VF == 4 from { { a0, b0, c0 }, { a1, b1, c1 }, { a2, b2, c2 }, { a3, b3, c3 } } the intermediate vector

[PATCH 5/5] RISC-V: Support group size of three in SLP store permute lowering

The following implements the group-size three scheme from vect_permute_store_chain in SLP grouped store permute lowering and extends it to power-of-two multiples of group size three. The scheme goes from vectors A, B and C to { A[0], B[0], C[0], A[1], B[1], C[1], ... } by first producing { A[0], B

[PATCH 3/5] Handle gaps in SLP load permutation lowering

The following adds handling of gaps by representing them with NULL entries in SLP_TREE_SCALAR_STMTS for the unpermuted load node. The SLP discovery changes could be elided if we manually build the load node instead. * tree-vect-slp.cc (vect_build_slp_tree_1): Handle NULL stmt. (ve

[PATCH 2/5] extend SLP load permutation lowering

The following extends the SLP load permutation to single-level interleaving to handle the case we need multiple levels and adding a fallback handling when the required permutes do not match interleaving but would need three vectors to implement (and thus fail). With the change all single-lane SLP

RE: [PATCH v1] Match: Allow more types truncation for .SAT_TRUNC

> OK. Committed, thanks Richard. Pan -Original Message- From: Richard Biener Sent: Wednesday, July 3, 2024 5:04 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 Subject: Re: [P

[PATCH 1/5] lower SLP load permutation to interleaving

The following emulates classical interleaving for SLP load permutes that we are unlikely handling natively. This is to handle cases where interleaving (or load/store-lanes) is the optimal choice for vectorizing even when we are doing that within SLP. An example would be void foo (int * __restric

[PATCH 0/5][v2] SLP load and store permute lowering

This completes (functionality wise) the work bringing non-SLP "interleaving" group vectorization to SLP. I've chosen to keep [1/5] exactly the same as posted last time but it might confuse things as [2/5] largely refactors it. The series is how it worked out development wise with [2/5] completi

Re: [PATCH] match.pd: Fold x/sqrt(x) to sqrt(x)

> On 3 Jul 2024, at 14:22, Richard Biener wrote: > > External email: Use caution opening links or attachments > > > On Wed, 3 Jul 2024, Jennifer Schmitz wrote: > >> > > OK. I’ve pushed the patch on Jennifer’s behalf with 8dc5ad3ce8d4d2cd6cc2b7516d282395502fdf7d . One thing I noticed is t

Re: [PATCH] middle-end/115426 - wrong gimplification of "rm" asm output operand

On Wed, Jul 03, 2024 at 02:37:12PM +0200, Richard Biener wrote: > > So maybe instead of the assert just do your new handling just for allows_reg > > && allows_mem and leave the rest as before. > > But "=mi" would be a valid constraint (even if a literal immediate > would be never OK there)? I'd s

Re: [PATCH] middle-end/115426 - wrong gimplification of "rm" asm output operand

On Wed, 3 Jul 2024, Jakub Jelinek wrote: > On Wed, Jul 03, 2024 at 02:24:19PM +0200, Jakub Jelinek wrote: > > > >From 40023cac83562a1451aba550533d042fec1c144e Mon Sep 17 00:00:00 2001 > > > From: Richard Biener > > > Date: Tue, 11 Jun 2024 13:11:08 +0200 > > > Subject: [PATCH] middle-end/115426 -

Re: [PATCH] middle-end/115426 - wrong gimplification of "rm" asm output operand

On Wed, Jul 03, 2024 at 02:24:19PM +0200, Jakub Jelinek wrote: > > >From 40023cac83562a1451aba550533d042fec1c144e Mon Sep 17 00:00:00 2001 > > From: Richard Biener > > Date: Tue, 11 Jun 2024 13:11:08 +0200 > > Subject: [PATCH] middle-end/115426 - wrong gimplification of "rm" asm output > > operan

Re: [PATCH] middle-end/115426 - wrong gimplification of "rm" asm output operand

On Wed, Jul 03, 2024 at 02:21:25PM +0200, Richard Biener wrote: > I'm re-testing the following. > > Richard. > > >From 40023cac83562a1451aba550533d042fec1c144e Mon Sep 17 00:00:00 2001 > From: Richard Biener > Date: Tue, 11 Jun 2024 13:11:08 +0200 > Subject: [PATCH] middle-end/115426 - wrong gim

Re: [PATCH] match.pd: Fold x/sqrt(x) to sqrt(x)

On Wed, 3 Jul 2024, Jennifer Schmitz wrote: > OK. Thanks, Richard. > > On 2 Jul 2024, at 15:01, Richard Biener wrote: > > > > External email: Use caution opening links or attachments > > > > > > On Tue, 2 Jul 2024, Jennifer Schmitz wrote: > > > >> This patch adds a pattern in match.pd fol

Re: [PATCH] middle-end/115426 - wrong gimplification of "rm" asm output operand

On Wed, 3 Jul 2024, Jakub Jelinek wrote: > On Tue, Jun 11, 2024 at 01:20:50PM +0200, Richard Biener wrote: > > When the operand is gimplified to an extract of a register or a > > register we have to disallow memory as we otherwise fail to > > gimplify it properly. Instead of > > > > __asm__(""

[PATCH] Remove redundant vector permute dump

The following removes redundant dumping in vect permute vectorization. Bootstrap and regtest running on x86_64-unknown-linux-gnu. * tree-vect-slp.cc (vectorizable_slp_permutation_1): Remove redundant dump. --- gcc/tree-vect-slp.cc | 10 -- 1 file changed, 10 deletions(-)

Re: [PATCH] middle-end/115426 - wrong gimplification of "rm" asm output operand

On Tue, Jun 11, 2024 at 01:20:50PM +0200, Richard Biener wrote: > When the operand is gimplified to an extract of a register or a > register we have to disallow memory as we otherwise fail to > gimplify it properly. Instead of > > __asm__("" : "=rm" __imag ); > > we want > > __asm__("" : "=

Re: [PATCH] match.pd: Fold x/sqrt(x) to sqrt(x)

> On 2 Jul 2024, at 15:01, Richard Biener wrote: > > External email: Use caution opening links or attachments > > > On Tue, 2 Jul 2024, Jennifer Schmitz wrote: > >> This patch adds a pattern in match.pd folding x/sqrt(x) to sqrt(x) for >> -funsafe-math-optimizations. Test cases were added f

Re: [PATCH] RISC-V: Use tu policy for first-element vec_set [PR115725].

Ok for trunk and gcc 14 juzhe.zh...@rivai.ai 於 2024年7月3日 週三 17:43 寫道： > LGTM > > -- > juzhe.zh...@rivai.ai > > > *From:* Robin Dapp > *Date:* 2024-07-03 17:39 > *To:* gcc-patches > *CC:* rdapp.gcc ; palmer ; Kito > Cheng ; juzhe.zh...@rivai.ai; jeffreyalaw > ; Li, P

Re: [PATCH] [i386] restore recompute to override opts after change [PR113719]

On Jun 27, 2024, Hongtao Liu wrote: > LGTM, thanks. > On Thu, Jun 13, 2024 at 3:32 PM Alexandre Oliva wrote: >> for gcc/ChangeLog >> >> PR target/113719 >> * config/i386/i386-options.cc >> (ix86_override_options_after_change_1): Add opts and opts_set >> parms, operate on them, after factorin

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

Hi Harald, I am sorry for the long delay, but fixing the negative stride lead from one issue to the next. I finally got a version that does not regress. Please have a look. This patch has two parts: 1. The runtime library part in pr96992_3p1.patch and 2. the compiler changes in pr96992_3p2.patch.

Re: [PATCH v1 0/2] Aarch64: addp NEON big-endian fix [PR114890]

Hi Kyrill, Okay noted for future! Yes happy someone to commit this. Kind regards, Alfie Sent from Outlook for iOS From: Kyrylo Tkachov Sent: Wednesday, July 3, 2024 11:23:37 AM To: Alfie Richards Cc: gcc-patches@gcc.gnu.org Subject: Re:

[PATCH, FYI] [debug] Avoid dropping bits from num/den in fixed-point types

We used to use an unsigned 128-bit type to hold the numerator and denominator used to represent the delta of a fixed-point type in debug information, but there are cases in which that was not enough, and more significant bits silently overflowed and got omitted from debug information. Introduce

[PATCH v2] [FYI] Deduplicate explicitly-sized types (was: Re: [FYI] map packed field type to unpacked for debug info)

On Jun 13, 2024, Alexandre Oliva wrote: > I'll be back with an improved version. When make_type_from_size is called with a biased type, for an entity that isn't explicitly biased, we may refrain from reusing the given type because it doesn't seem to match, and then proceed to create an exact cop

Re: [PATCH v1 0/2] Aarch64: addp NEON big-endian fix [PR114890]

Hi Alfie, > On 3 Jul 2024, at 12:10, alfie.richa...@arm.com wrote: > > External email: Use caution opening links or attachments > > > From: Alfie Richards > > Hi All, > > This fixes a case where the operands for the addp NEON intrinsic were > erroneously swapped. > > Regtested on aarch64-u

  1   2   >