[PATCH 3/3] Emit a warning when AVX10 options conflict in vector width

gcc/ChangeLog: * config/i386/driver-i386.cc (host_detect_local_cpu): Do not append -mno-avx10-max-512bit for -march=native. * common/config/i386/i386-common.cc (ix86_check_avx10_vector_width): New function to check isa_flags to emit a warning when there is a

Re: Re: [PATCH v2] LoongArch:Implement 128-bit floating point functions in gcc.

Ok, thanks for the advice. I have modified __builtin_nanq("") and __builtin_nansq("") in gcc according to the functionality of the function, and the implementation is shown in the following code. >>> __float128 __nanq (const char * str) { union _FP_UNION_Q nan; nan.bits.frac0 = 0; nan.bits

[PATCH 2/3] Emit a warning when disabling AVX512 with AVX10 enabled or disabling AVX10 with AVX512 enabled

gcc/ChangeLog: * config/i386/driver-i386.cc (host_detect_local_cpu): Do not append -mno-avx10.1 for -march=native. * config/i386/i386-options.cc (ix86_check_avx10): New function to check isa_flags and isa_flags_explicit to emit warning when AVX10 is enabled

[PATCH 1/3] Initial support for AVX10.1

gcc/ChangeLog: * common/config/i386/cpuinfo.h (get_available_features): Add avx10_set and version and detect avx10.1. (cpu_indicator_init): Handle avx10.1-512. * common/config/i386/i386-common.cc (OPTION_MASK_ISA2_AVX10_512BIT_SET): New. (OPTION_MASK

[PATCH 1/6] Support AVX10.1 for AVX512DQ+AVX512VL intrins

gcc/ChangeLog: * config/i386/avx512vldqintrin.h: Remove target attribute. * config/i386/i386-builtin.def (BDESC): Add OPTION_MASK_ISA2_AVX10_1. * config/i386/i386-builtins.cc (def_builtin): Handle AVX10_1. * config/i386/i386-expand.cc (ix86_check_bui

[PATCH 2/6] Support AVX10.1 for AVX512DQ+AVX512VL intrins

gcc/testsuite/ChangeLog: * gcc.target/i386/avx10_1-vandnpd-1.c: New test. * gcc.target/i386/avx10_1-vandnps-1.c: Ditto. * gcc.target/i386/avx10_1-vbroadcastf32x2-1.c: Ditto. * gcc.target/i386/avx10_1-vbroadcastf64x2-1.c: Ditto. * gcc.target/i386/avx10_1-vbro

[PATCH 3/6] Support AVX10.1 for AVX512DQ+AVX512VL intrins

gcc/ChangeLog: * config/i386/avx512vldqintrin.h: Remove target attribute. * config/i386/i386-builtin.def (BDESC): Add OPTION_MASK_ISA2_AVX10_1. * config/i386/i386.cc (standard_sse_constant_opcode): Add TARGET_AVX10_1. * config/i386/i386.md: Add new isa attr

[PATCH 5/6] Support AVX10.1 for AVX512DQ+AVX512VL intrins

gcc/ChangeLog: * config/i386/avx512vldqintrin.h: Remove target attribute. * config/i386/i386-builtin.def (BDESC): Add OPTION_MASK_ISA2_AVX10_1. * config/i386/sse.md (VF_AVX512VLDQ_AVX10_1): New. (VFH_AVX512VLDQ_AVX10_1): Ditto. (VF1_AVX512VLDQ_AVX10_

[PATCH 4/6] Support AVX10.1 for AVX512DQ+AVX512VL intrins

gcc/testsuite/ChangeLog: * gcc.target/i386/avx10_1-abs-copysign-1.c: New test. * gcc.target/i386/avx10_1-vandpd-1.c: Ditto. * gcc.target/i386/avx10_1-vandps-1.c: Ditto. * gcc.target/i386/avx10_1-vcvtps2qq-1.c: Ditto. * gcc.target/i386/avx10_1-vcvtps2uqq-1.c:

[PATCH 6/6] Support AVX10.1 for AVX512DQ+AVX512VL intrins

gcc/testsuite/ChangeLog: * gcc.target/i386/avx10_1-vextractf64x2-1.c: New test. * gcc.target/i386/avx10_1-vextracti64x2-1.c: Ditto. * gcc.target/i386/avx10_1-vfpclasspd-1.c: Ditto. * gcc.target/i386/avx10_1-vfpclassps-1.c: Ditto. * gcc.target/i386/avx10_1-vi

Re: [PATCH V1] RISC-V: Fix a bug that causes an error insn.

OK for trunk and GCC 13 :) On Tue, Aug 8, 2023 at 2:46 PM juzhe.zh...@rivai.ai wrote: > > LGTM. Thanks for fixing it. > > @kito: Hi, kito. This is the bug also exists in GCC-13, can we backport to > GCC-13? > > > > juzhe.zh...@rivai.ai > > From: shiyulong > Date: 2023-08-08 12:12 > To: gcc-patch

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 08, 2023 at 03:13:09PM +0800, Haochen Jiang via Gcc-patches wrote: > We will send out our initial support of AVX10 and some sample patches in this > mailing thread. And there will be more coming up afterwards. Therefore, we > would > like to share our proposed AVX10 design in GCC. > >

Re: [PATCH] MATCH: [PR110937/PR100798] (a ? ~b : b) should be optimized to b ^ -(a)

On Tue, Aug 8, 2023 at 2:55 AM Andrew Pinski via Gcc-patches wrote: > > This adds a simple match pattern for this case. > I noticed it a couple of different places. > One while I was looking at code generation of a parser and > also while I was looking at locations where bitwise_inverted_equal_p >

RE: [PATCH V1] RISC-V: Fix a bug that causes an error insn.

Committed to both the trunk and gcc-13, thanks Kito and Juzhe. Pan -Original Message- From: Kito Cheng Sent: Tuesday, August 8, 2023 3:40 PM To: juzhe.zh...@rivai.ai Cc: yulong ; gcc-patches ; Kito.cheng ; wuwei2016 ; jiawei ; shihua ; chenyixuan ; Li, Pan2 Subject: Re: [PATCH V1] R

Re: [PATCH v2] Mode-Switching: Fix SET_SRC ICE when USE or CLOBBER

On Tue, Aug 8, 2023 at 5:10 AM Pan Li via Gcc-patches wrote: > > From: Pan Li > > In same cases, like gcc/testsuite/gcc.dg/pr78148.c in RISC-V, there will > be only 1 operand when SET_SRC in create_pre_exit. For example as below. > > (insn 13 9 14 2 (clobber (reg/i:TI 10 a0)) > "gcc/testsuite/gc

Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.

On Mon, 7 Aug 2023, Qing Zhao wrote: > Hi, > > This is the 2nd version of the patch. > Comparing to the 1st version, the only change is to address Richard's > comment on refering a warning option for diagnosing deprecated behavior. > > > Okay for committing? OK. > thanks. > > Qing > > =

Re: [PATCH] VR-VALUES [PR28794]: optimize compare assignments also

On Mon, Aug 7, 2023 at 4:46 PM Andrew Pinski via Gcc-patches wrote: > > This patch fixes the oldish (2006) bug where VRP was not > optimizing the comparison for assignments while handling > them for GIMPLE_COND only. > It just happens to also solves PR 103281 due to allowing > to optimize `c < 1`

[PATCH] [X86] Workaround possible CPUID bug in Sandy Bridge.

Don't access leaf 7 subleaf 1 unless subleaf 0 says it is supported via EAX. Intel documentation says invalid subleaves return 0. We had been relying on that behavior instead of checking the max sublef number. It appears that some Sandy Bridge CPUs return at least the subleaf 0 EDX value for subl

Re: [PATCH] [X86] Workaround possible CPUID bug in Sandy Bridge.

On Tue, Aug 08, 2023 at 03:56:00PM +0800, liuhongt via Gcc-patches wrote: > + /* According to document, when subleaf is invliad, EAX,EBX,ECX,EDX > should s/invliad/invalid/ Jakub

Re: [RFC PATCH] i386: Do not sanitize upper part of V2SFmode reg with -fno-trapping-math [PR110832]

On Mon, 7 Aug 2023, Uros Bizjak wrote: > On Mon, Jul 31, 2023 at 11:40?AM Richard Biener wrote: > > > > On Sun, 30 Jul 2023, Uros Bizjak wrote: > > > > > Also introduce -m[no-]mmxfp-with-sse option to disable trapping V2SF > > > named patterns in order to avoid generation of partial vector V4SFmo

RE: Intel AVX10.1 Compiler Design and Support

Hi Jakub, > So, what does this imply for the current ISAs? AVX10 will imply AVX2 on the ISA level. And we suppose AVX10 is an independent ISA feature set. Although sharing the same instructions and encodings, AVX10 and AVX512 are conceptual independent features, which means they are orthogonal.

Re: [RFC] GCC Security policy

On Mon, Aug 7, 2023 at 7:30 PM David Edelsohn via Gcc-patches wrote: > > FOSS Best Practices recommends that projects have an official Security > policy stated in a SECURITY.md or SECURITY.txt file at the root of the > repository. GLIBC and Binutils have added such documents. > > Appended is a pr

Re: [PATCH] vect: Add a popcount fallback.

> Looks reasonable to me - I couldn't read from above whether you did > testing on riscv and thus verified the runtime correctness of the fallback? > If not may I suggest to force matching the pattern on a target you can > test for this purpose? I tested on riscv (manually and verified the run tes

Re: [RFC PATCH] i386: Do not sanitize upper part of V2SFmode reg with -fno-trapping-math [PR110832]

On Tue, Aug 8, 2023 at 10:07 AM Richard Biener wrote: > > On Mon, 7 Aug 2023, Uros Bizjak wrote: > > > On Mon, Jul 31, 2023 at 11:40?AM Richard Biener wrote: > > > > > > On Sun, 30 Jul 2023, Uros Bizjak wrote: > > > > > > > Also introduce -m[no-]mmxfp-with-sse option to disable trapping V2SF > >

RE: [PATCH v2] Mode-Switching: Fix SET_SRC ICE when USE or CLOBBER

Hi Richard B, Thanks for comments. Looks this SH4 parts existed in lcm.c from day 1 about 19 years ago, see this commit https://github.com/gcc-mirror/gcc/commit/cf99f196e2e18b62becbb660761fc2a586b85d78. As you said, the problem exists from the original commit. Aks the return_copy_pat can be e

Re: [PATCH v2] Mode-Switching: Fix SET_SRC ICE when USE or CLOBBER

> Could you please help to share how to enable checks here? Build with --enable-checking or rather --enable-checking=extra. Regards Robin

Re: [RFC] [v2] Extend fold_vec_perm to handle VLA vectors

Prathamesh Kulkarni writes: > On Fri, 4 Aug 2023 at 20:36, Richard Sandiford > wrote: >> >> Full review this time, sorry for the skipping the tests earlier. > Thanks for the detailed review! Please find my responses inline below. >> >> Prathamesh Kulkarni writes: >> > diff --git a/gcc/fold-const

Re: [PATCH] vect: Add a popcount fallback.

On Tue, Aug 8, 2023 at 10:55 AM Robin Dapp wrote: > > > Looks reasonable to me - I couldn't read from above whether you did > > testing on riscv and thus verified the runtime correctness of the fallback? > > If not may I suggest to force matching the pattern on a target you can > > test for this p

Re: [RFC PATCH] i386: Do not sanitize upper part of V2SFmode reg with -fno-trapping-math [PR110832]

On Tue, 8 Aug 2023, Uros Bizjak wrote: > On Tue, Aug 8, 2023 at 10:07?AM Richard Biener wrote: > > > > On Mon, 7 Aug 2023, Uros Bizjak wrote: > > > > > On Mon, Jul 31, 2023 at 11:40?AM Richard Biener wrote: > > > > > > > > On Sun, 30 Jul 2023, Uros Bizjak wrote: > > > > > > > > > Also introduce

Re: [PATCH] aarch64: enable mixed-types for aarch64 simdclones

"Andre Vieira (lists)" writes: > Hi, > > This patch enables the use of mixed-types for simd clones for AArch64 > and adds aarch64 as a target_vect_simd_clones. > > Bootstrapped and regression tested on aarch64-unknown-linux-gnu > > gcc/ChangeLog: > > * config/aarch64/aarch64.cc (currentl

Re: [RFC PATCH] i386: Do not sanitize upper part of V2SFmode reg with -fno-trapping-math [PR110832]

On Tue, Aug 8, 2023 at 12:08 PM Richard Biener wrote: > > > > > > Also introduce -m[no-]mmxfp-with-sse option to disable trapping V2SF > > > > > > named patterns in order to avoid generation of partial vector > > > > > > V4SFmode > > > > > > trapping instructions. > > > > > > > > > > > > The new

Re: [PATCH V4] VECT: Support CALL vectorization for COND_LEN_*

Hi, Richard and Richi. This patch added + else if (reduc_idx >= 0) + gcc_unreachable (); as Richi's suggested. And I was trying to produce a case that can happen with reduc_idx >= 0 for a few days but I failed. This patch is fully tested with RISC-V pending patch: https://gcc.gnu.or

[PATCH] RISC-V: Allow CONST_VECTOR for VLS modes.

This patch enables COSNT_VECTOR for VLS modes. void foo1 (int * __restrict a) { for (int i = 0; i < 16; i++) a[i] = 8; } void foo2 (int * __restrict a) { for (int i = 0; i < 16; i++) a[i] = i; } Compile option: -O3 --param=riscv-autovec-preference=scalable Before this patch:

Re: [PATCH] vect: Add a popcount fallback.

> Well, not sure how VECT_COMPARE_COSTS can help here, we either > get the pattern or vectorize the original function. There's no special > handling > for popcount in vectorizable_call so all special cases are handled via > patterns. > I was thinking of popcounthi via popcountsi and zero-extend

[PATCH] RISC-V: Fix error combine of pred_mov pattern

Hi, This patch fix PR110943 which will produce some error code. This is because the error combine of some pred_mov pattern. Consider this code: ``` #include void foo9 (void *base, void *out, size_t vl) { int64_t scalar = *(int64_t*)(base + 100); vint64m2_t v = __riscv_vmv_v_x_i64m2 (0,

[PATCH] tree-optimization/110924 - fix vop liveness for noreturn const CFG parts

The virtual operand live problem used by sinking assumes we have virtual uses at each end point of the CFG but as shown in the PR this isn't true for parts for example ending in __builtin_unreachable. The following removes the optimization made possible by this and now requires marking backedges.

Re: [PATCH V4] VECT: Support CALL vectorization for COND_LEN_*

On Tue, 8 Aug 2023, juzhe.zh...@rivai.ai wrote: > Hi, Richard and Richi. > > This patch added > + else if (reduc_idx >= 0) > + gcc_unreachable (); > as Richi's suggested. > > And I was trying to produce a case that can happen with reduc_idx >= 0 for a > few days but I failed. > > Thi

Re: [RFC] GCC Security policy

On 2023-08-08 04:16, Richard Biener wrote: On Mon, Aug 7, 2023 at 7:30 PM David Edelsohn via Gcc-patches wrote: FOSS Best Practices recommends that projects have an official Security policy stated in a SECURITY.md or SECURITY.txt file at the root of the repository. GLIBC and Binutils have add

RE: [PATCH V4] VECT: Support CALL vectorization for COND_LEN_*

Committed, thanks Richard. Pan -Original Message- From: Gcc-patches On Behalf Of Richard Biener via Gcc-patches Sent: Tuesday, August 8, 2023 8:28 PM To: juzhe.zh...@rivai.ai Cc: gcc-patches ; richard.sandiford Subject: Re: [PATCH V4] VECT: Support CALL vectorization for COND_LEN_* O

Re: [PATCH] [X86] Workaround possible CPUID bug in Sandy Bridge.

On Tue, Aug 8, 2023 at 9:58 AM liuhongt wrote: > > Don't access leaf 7 subleaf 1 unless subleaf 0 says it is > supported via EAX. > > Intel documentation says invalid subleaves return 0. We had been > relying on that behavior instead of checking the max sublef number. > > It appears that some Sand

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 8, 2023 at 10:15 AM Jiang, Haochen via Gcc-patches wrote: > > Hi Jakub, > > > So, what does this imply for the current ISAs? > > AVX10 will imply AVX2 on the ISA level. And we suppose AVX10 is an > independent ISA feature set. Although sharing the same instructions and > encodings, AVX

Re: [PATCH] vect: Add a popcount fallback.

On Tue, Aug 8, 2023 at 1:37 PM Robin Dapp wrote: > > > Well, not sure how VECT_COMPARE_COSTS can help here, we either > > get the pattern or vectorize the original function. There's no special > > handling > > for popcount in vectorizable_call so all special cases are handled via > > patterns.

Re: [PATCH] RISC-V: Allow CONST_VECTOR for VLS modes.

Hi Juzhe, just some nits. > - else if (rtx_equal_p (step, constm1_rtx) && poly_int_rtx_p (base, &value) > + else if (rtx_equal_p (step, constm1_rtx) > +&& poly_int_rtx_p (base, &value) Looks like just a line-break change and the line is not too long? > - rtx ops[] = {dest, vid, g

Re: [RFC] GCC Security policy

On Tue, Aug 8, 2023 at 2:33 PM Siddhesh Poyarekar wrote: > > On 2023-08-08 04:16, Richard Biener wrote: > > On Mon, Aug 7, 2023 at 7:30 PM David Edelsohn via Gcc-patches > > wrote: > >> > >> FOSS Best Practices recommends that projects have an official Security > >> policy stated in a SECURITY.md

Re: [PATCH 0/3 v4] genmatch: Speed up recompilation after changes to match.pd

On Mon, Aug 7, 2023 at 12:04 PM Andrzej Turko wrote: > > The following reduces the number of object files that need to be rebuilt > after match.pd has been modified. Right now a change to match.pd which > adds/removes a line almost always forces recompilation of all files that > genmatch generates

Re: [RFC] GCC Security policy

On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc-patches wrote: > There's probably external tools to do this, not sure if we should replicate > things in the driver for this. > > But sure, I think the driver is the proper point to address any of such > issues - iff we want to addre

[PATCH][GCC] aarch64: Add support for Cortex-A520 CPU

This patch adds support for the Cortex-A520 CPU to GCC. No regressions on aarch64-none-elf. Ok for master? gcc/ChangeLog:     * config/aarch64/aarch64-cores.def (AARCH64_CORE): Add Cortex-A520 CPU.     * config/aarch64/aarch64-tune.md: Regenerate.     * doc/invoke.texi: Document

Re: [PATCH] vect: Add a popcount fallback.

> Hmm, the conversion should be a separate statement so I wonder > why it would go wrong? It is indeed. Yet, lhs_type is the lhs type of the conversion and not the call and consequently we compare the precision of the converted type with the popcount input. So we should probably rather do someth

RE: Re: [PATCH V2] RISC-V: Support CALL conditional autovec patterns

Committed, thanks Robin. Pan -Original Message- From: Gcc-patches On Behalf Of ??? Sent: Thursday, August 3, 2023 8:48 PM To: rdapp.gcc ; gcc-patches Cc: rdapp.gcc ; kito.cheng ; kito.cheng ; Jeff Law Subject: Re: Re: [PATCH V2] RISC-V: Support CALL conditional autovec patterns No.

RE: [PATCH v1] RISC-V: Enhance the test case for RVV vfsub/vfrsub rounding

Kindly ping. Pan -Original Message- From: Li, Pan2 Sent: Wednesday, August 2, 2023 3:59 PM To: gcc-patches@gcc.gnu.org Cc: juzhe.zh...@rivai.ai; kito.ch...@sifive.com; Li, Pan2 ; Wang, Yanzhang Subject: [PATCH v1] RISC-V: Enhance the test case for RVV vfsub/vfrsub rounding From: Pan

Re: [PATCH] match.pd: Implement missed optimization ((x ^ y) & z) | x -> (z & y) | x [PR109938]

On Fri, Aug 4, 2023 at 11:49 PM Drew Ross via Gcc-patches wrote: > > Adds a simplification for ((x ^ y) & z) | x to be folded into > (z & y) | x. Merges this simplification with ((x | y) & z) | x -> (z & y) | x > to prevent duplicate pattern. Tested successfully on x86_64 and x86 targets. OK. >

Re: [RFC] GCC Security policy

On Tue, Aug 8, 2023 at 3:01 PM Jakub Jelinek wrote: > > On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc-patches > wrote: > > There's probably external tools to do this, not sure if we should replicate > > things in the driver for this. > > > > But sure, I think the driver is the

Re: [RFC] GCC Security policy

Hello, On Tue, 8 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > What I'd really like to avoid is having all compiler bugs (primarily ICEs) > considered to be security bugs (e.g. DoS category), it would be terrible to > release every week a new compiler because of the "security" issues. > Runnin

Re: [PATCH] vect: Add a popcount fallback.

On Tue, Aug 8, 2023 at 3:06 PM Robin Dapp wrote: > > > Hmm, the conversion should be a separate statement so I wonder > > why it would go wrong? > > It is indeed. Yet, lhs_type is the lhs type of the conversion > and not the call and consequently we compare the precision of > the converted type w

Re: [RFC] GCC Security policy

> On Aug 8, 2023, at 9:01 AM, Jakub Jelinek via Gcc-patches > wrote: > > On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc-patches > wrote: >> There's probably external tools to do this, not sure if we should replicate >> things in the driver for this. >> >> But sure, I think

Re: [RFC] GCC Security policy

On Tue, Aug 8, 2023 at 6:02 AM Jakub Jelinek via Gcc-patches wrote: > > On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc-patches > wrote: > > There's probably external tools to do this, not sure if we should replicate > > things in the driver for this. > > > > But sure, I think th

Re: [PATCH 11/24] Disable year 2038 support on 32-bit hosts by default

On 8/7/23 18:45, Jeff Law wrote: > > > On 8/7/23 04:32, Arsen Arsenović via Gcc-patches wrote: >> From: Luis Machado >> >> With a recent import of gnulib, code has been pulled that tests and enables >> 64-bit time_t by default on 32-bit hosts that support it. >> >> Although gdb can use the gnuli

[PATCH] testsuite: Add runtime _BitInt stdatomic.h tests [PR102989]

Hi! On Thu, Aug 03, 2023 at 05:19:54PM +, Joseph Myers wrote: > It would be good to have execution tests for these operations (so probably > in gcc.dg/atomic so that libatomic is linked in automatically as needed). Ok, following patch does that, tested on x86_64-linux. 2023-08-08 Jakub Jel

RE: [PATCH v2] Mode-Switching: Fix SET_SRC ICE when USE or CLOBBER

Thanks Robin, will have a try without this PATCH. Pan -Original Message- From: Robin Dapp Sent: Tuesday, August 8, 2023 5:43 PM To: Li, Pan2 ; Richard Biener Cc: rdapp@gmail.com; gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@sifive.com; Wang, Yanzhang ; jeffreya...@gm

Re: Re: [PATCH] RISC-V: Allow CONST_VECTOR for VLS modes.

>> Looks like just a line-break change and the line is not too long? Yes. >> This seems a bit inconsistent from a caller's perspective >> as we also do emit_insn (gen_vec_series, ...) without extra move >> at another spot. Can we handle this directly in expand_vec_series? I'am not sure. I change

Re: [RFC] GCC Security policy

On Tue, Aug 8, 2023 at 3:35 PM Ian Lance Taylor wrote: > > On Tue, Aug 8, 2023 at 6:02 AM Jakub Jelinek via Gcc-patches > wrote: > > > > On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc-patches > > wrote: > > > There's probably external tools to do this, not sure if we should >

Re: [RFC] GCC Security policy

On 2023-08-08 10:04, Richard Biener wrote: On Tue, Aug 8, 2023 at 3:35 PM Ian Lance Taylor wrote: On Tue, Aug 8, 2023 at 6:02 AM Jakub Jelinek via Gcc-patches wrote: On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc-patches wrote: There's probably external tools to do this,

Re: [PATCH v1] RISC-V: Enhance the test case for RVV vfsub/vfrsub rounding

On 8/2/23 01:59, Pan Li via Gcc-patches wrote: From: Pan Li This patch would like to enhance the vfsub/vfrsub rounding API test for below 2 purposes. * The non-rm API has no frm related insn generated. * The rm API has the frm backup/restore/set insn generated. Signed-off-by: Pan Li gcc/

Re: [RFC] GCC Security policy

On Tue, Aug 8, 2023 at 10:07 AM Siddhesh Poyarekar wrote: > On 2023-08-08 10:04, Richard Biener wrote: > > On Tue, Aug 8, 2023 at 3:35 PM Ian Lance Taylor wrote: > >> > >> On Tue, Aug 8, 2023 at 6:02 AM Jakub Jelinek via Gcc-patches > >> wrote: > >>> > >>> On Tue, Aug 08, 2023 at 02:52:57PM +02

Re: [PATCH] vect: Add a popcount fallback.

On 8/8/23 02:55, Robin Dapp via Gcc-patches wrote: Looks reasonable to me - I couldn't read from above whether you did testing on riscv and thus verified the runtime correctness of the fallback? If not may I suggest to force matching the pattern on a target you can test for this purpose? I t

Re: [PATCH] vect: Add a popcount fallback.

> Presumably this is an alternative to the approach Juzhe posted a week > or two ago and ultimately dropped? Yeah, I figured having a generic fallback could help more targets. We can still have a better expander if we see the need. Regards Robin

RE: [PATCH v1] RISC-V: Enhance the test case for RVV vfsub/vfrsub rounding

Committed, thanks Jeff. Pan -Original Message- From: Jeff Law Sent: Tuesday, August 8, 2023 10:10 PM To: Li, Pan2 ; gcc-patches@gcc.gnu.org Cc: juzhe.zh...@rivai.ai; kito.ch...@sifive.com; Wang, Yanzhang Subject: Re: [PATCH v1] RISC-V: Enhance the test case for RVV vfsub/vfrsub round

Re: [committed][RISC-V]Don't reject constants in cmov condition

On 8/7/23 17:42, Vineet Gupta wrote: On 8/7/23 13:36, Jeff Law wrote: Fixes several missed conditional moves with the trunk. I'm curious, how do you know what's missing. Does ifc have some stats like autovec which explicitly reports missed opportunities ? Xiao's testcases :-) I haven't

Re: [RFC] GCC Security policy

On 2023-08-08 10:14, David Edelsohn wrote: On Tue, Aug 8, 2023 at 10:07 AM Siddhesh Poyarekar > wrote: On 2023-08-08 10:04, Richard Biener wrote: > On Tue, Aug 8, 2023 at 3:35 PM Ian Lance Taylor mailto:i...@google.com>> wrote: >> >> On Tue, Aug 8,

Re: [RFC] GCC Security policy

On Tue, Aug 08, 2023 at 10:30:10AM -0400, Siddhesh Poyarekar wrote: > > Do you have a suggestion for the language to address libgcc, libstdc++, > > etc. and libiberty, libbacktrace, etc.? > > I'll work on this a bit and share a draft. BTW, I think we should perhaps differentiate between productio

Re: [RFC] GCC Security policy

On 2023-08-08 10:37, Jakub Jelinek wrote: On Tue, Aug 08, 2023 at 10:30:10AM -0400, Siddhesh Poyarekar wrote: Do you have a suggestion for the language to address libgcc, libstdc++, etc. and libiberty, libbacktrace, etc.? I'll work on this a bit and share a draft. BTW, I think we should perh

Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

I am sure this has been discussed before, but seeing that you test for a specific formula, let me point out the following: There at least three different size expression which could make sense. Consider short foo { int a; short b; char t[]; };  Most people seem to use sizeof(struct foo) + N

[PATCH] testsuite: Fix gcc.dg/analyzer/allocation-size-multiline-[123].c [PR 110426]

For 32-bit newlib targets (e.g. arm-eabi) int32_t is "long int". Like previous patches in these tests, update the matching regexps to match "aka (long )?int". Tested on arm-eabi and aarch64-linux-gnu. 2023-08-08 Christophe Lyon gcc/testsuite/ PR analyzer/110426 * gcc

Re: RISC-V: Added support for CRC.

On Thu, 3 Aug 2023, Jeff Law wrote: > The end goal here is to actually detect bitwise CRC implementations in the > gimple optimizers and turn them into table lookups or carryless multiplies in > RTL. > > Mariam has that working end-to-end and has proposed a talk for the Cauldron on > the topic.

Re: RISC-V: Added support for CRC.

On 8/8/23 09:22, Alexander Monakov wrote: Jeff, as I understand this all is happening only because Coremark contains use of bitwise CRC that affects benchmark scores. In another universe where - Coremark was careful to checksum outputs outside of timed sections, or - implemented CRC in a man

Re: [RFC] GCC Security policy

On Tue, 2023-08-08 at 09:33 -0400, Paul Koning via Gcc-patches wrote: > > > > On Aug 8, 2023, at 9:01 AM, Jakub Jelinek via Gcc-patches > > wrote: > > > > On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc- > > patches wrote: > > > There's probably external tools to do this, not s

Re: [RFC] GCC Security policy

On 2023-08-08 11:48, David Malcolm wrote: On Tue, 2023-08-08 at 09:33 -0400, Paul Koning via Gcc-patches wrote: On Aug 8, 2023, at 9:01 AM, Jakub Jelinek via Gcc-patches wrote: On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc- patches wrote: There's probably external tools

Re: [PATCH] RISC-V: Fix error combine of pred_mov pattern

On 8/8/23 05:57, Lehua Ding wrote: Hi, This patch fix PR110943 which will produce some error code. This is because the error combine of some pred_mov pattern. Consider this code: ``` #include void foo9 (void *base, void *out, size_t vl) { int64_t scalar = *(int64_t*)(base + 100);

Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

Hello, On Tue, 8 Aug 2023, Martin Uecker via Gcc-patches wrote: > There at least three different size expression which could > make sense. Consider > > short foo { int a; short b; char t[]; };  > > Most people seem to use > > sizeof(struct foo) + N * sizeof(foo->t); > > which for N == 3 yield

Re: [RFC] GCC Security policy

On 08/08/2023 15:40, Siddhesh Poyarekar wrote: On 2023-08-08 10:37, Jakub Jelinek wrote: On Tue, Aug 08, 2023 at 10:30:10AM -0400, Siddhesh Poyarekar wrote: Do you have a suggestion for the language to address libgcc, libstdc++, etc. and libiberty, libbacktrace, etc.? I'll work on this a bit

Re: [RFC] GCC Security policy

> On Aug 8, 2023, at 11:55 AM, Siddhesh Poyarekar wrote: > > On 2023-08-08 11:48, David Malcolm wrote: >> On Tue, 2023-08-08 at 09:33 -0400, Paul Koning via Gcc-patches wrote: >>> >>> On Aug 8, 2023, at 9:01 AM, Jakub Jelinek via Gcc-patches wrote: On Tue, Aug 08, 2023

Re: RISC-V: Added support for CRC.

On Tue, 8 Aug 2023, Jeff Law wrote: > That was my thinking at one time. Then we started looking at the distros and > found enough crc implementations in there to change my mind about the overall > utility. The ones I'm familiar with are all table-based and look impossible to pattern-match (and

Re: [PATCH] rtl-optimization/110587 - speedup find_hard_regno_for_1

On 8/7/23 09:18, Richard Biener wrote: On Wed, 2 Aug 2023, Richard Biener wrote: On Mon, 31 Jul 2023, Jeff Law wrote: On 7/31/23 04:54, Richard Biener via Gcc-patches wrote: On Tue, 25 Jul 2023, Richard Biener wrote: The following applies a micro-optimization to find_hard_regno_for_1, r

Re: [PATCH] rtl-optimization/110587 - speedup find_hard_regno_for_1

On 8/8/23 10:49, Vladimir Makarov wrote: On 8/7/23 09:18, Richard Biener wrote: On Wed, 2 Aug 2023, Richard Biener wrote: On Mon, 31 Jul 2023, Jeff Law wrote: On 7/31/23 04:54, Richard Biener via Gcc-patches wrote: On Tue, 25 Jul 2023, Richard Biener wrote: The following applies a mi

Re: [PATCH] Add -Wdisabled-optimization warning for not optimizing sibling calls

On Tue, 2023-08-08 at 08:05 +0200, Richard Biener wrote: > On Mon, Aug 7, 2023 at 9:04 PM Bradley Lucier > wrote: > > > > Thank you for your comments.  I have a few questions. > > > > > I don't think this specific case qualifies for -Wdisabled- > > > optimization. > > > The diagnostic is for cas

[committed] i386: Do not sanitize upper part of V2SFmode reg with -fno-trapping-math [PR110832]

Also introduce -m[no-]partial-vector-fp-math option to disable trapping V2SF named patterns in order to avoid generation of partial vector V4SFmode trapping instructions. The new option is enabled by default, because even with sanitization, a small but consistent speed up of 2 to 3% with Polyhedro

RV64 Zicond ICE (was Re: [committed][RISC-V]Don't reject constants in cmov condition)

Hi Jeff, On 8/7/23 13:36, Jeff Law wrote: This test is too aggressive.  Constants have VOIDmode, so we need to let the through this phase of conditional move support. Fixes several missed conditional moves with the trunk. Committed to the trunk, As discussed this morning, this triggers an

[PATCH] bpf: Fixed GC mistakes in BPF builtins code.

Hi everyone, This patch fixes BPF CO-RE builtins support that missed information for garbage collector (GC). The BPF CO-RE implementation defines several data structures that keep builtin information throught all of the compilation flow aside from code. This intentionally avoids having the buil

Re: [RFC] GCC Security policy

On Tue, Aug 8, 2023 at 7:37 AM Jakub Jelinek wrote: > > BTW, I think we should perhaps differentiate between production ready > libraries (e.g. libgcc, libstdc++, libgomp, libatomic, libgfortran, > libquadmath, > libssp) vs. e.g. the sanitizer libraries which are meant for debugging and > I belie

Re: [RFC] GCC Security policy

On Tue, Aug 8, 2023 at 1:36 PM Ian Lance Taylor wrote: > On Tue, Aug 8, 2023 at 7:37 AM Jakub Jelinek wrote: > > > > BTW, I think we should perhaps differentiate between production ready > > libraries (e.g. libgcc, libstdc++, libgomp, libatomic, libgfortran, > libquadmath, > > libssp) vs. e.g. t

Re: RV64 Zicond ICE (was Re: [committed][RISC-V]Don't reject constants in cmov condition)

On 8/8/23 11:21, Vineet Gupta wrote: Hi Jeff, On 8/7/23 13:36, Jeff Law wrote: This test is too aggressive.  Constants have VOIDmode, so we need to let the through this phase of conditional move support. Fixes several missed conditional moves with the trunk. Committed to the trunk, As

Re: [PATCH] bpf: Fixed GC mistakes in BPF builtins code.

Hi Cuper. OK. Hopefully all the roots are marked now to avoid these nodes being collected. Thanks. > Hi everyone, > > This patch fixes BPF CO-RE builtins support that missed information for > garbage collector (GC). > > The BPF CO-RE implementation defines several data structures that keep >

Re: [PATCH] MATCH: [PR110937/PR100798] (a ? ~b : b) should be optimized to b ^ -(a)

On Tue, Aug 8, 2023 at 12:44 AM Richard Biener via Gcc-patches wrote: > > On Tue, Aug 8, 2023 at 2:55 AM Andrew Pinski via Gcc-patches > wrote: > > > > This adds a simple match pattern for this case. > > I noticed it a couple of different places. > > One while I was looking at code generation of

Re: [PATCH][GCC] aarch64: Add support for Cortex-A520 CPU

Richard Ball writes: > This patch adds support for the Cortex-A520 CPU to GCC. > > No regressions on aarch64-none-elf. > > Ok for master? > > > gcc/ChangeLog: > >     * config/aarch64/aarch64-cores.def (AARCH64_CORE): Add > Cortex-A520 CPU. >     * config/aarch64/aarch64-tune.md: Regene

Re: [PATCH] bpf: Fixed GC mistakes in BPF builtins code.

Thanks! Pushed to master. Jose E. Marchesi writes: > Hi Cuper. > > OK. Hopefully all the roots are marked now to avoid these nodes being > collected. > > Thanks. > >> Hi everyone, >> >> This patch fixes BPF CO-RE builtins support that missed information for >> garbage collector (GC). >> >> The

Re: [PATCH] c++: follow DR 2386 and update implementation of get_tuple_size [PR110216]

On 8/6/23 14:15, gnaggnoyil wrote: DR 2386 updated the tuple_size requirements for structured binding and it now requires tuple_size to be considered only if std::tuple_size names a complete class type with member value. GCC before this patch does not follow the updated requrements, and this patc

Re: [RFC] GCC Security policy

On 8/8/23 13:46, David Edelsohn wrote: > I believe that upstream projects for components that are imported > into GCC should be responsible for their security policy, including > libgo, gofrontend, libsanitizer (other than local patches), zlib, > libtool, libphobos, libcody, libffi, eventually Rust

Re: [PATCH 00/24] Sync shared build infrastructure with binutils-gdb

On Tue, 8 Aug 2023, Arsen Arsenović via Gcc-patches wrote: > Yes. Libtool was forked over a decade ago. My next project is syncing > upstream and us back up. Unsure about pkg.m4. Note as per previous discussions that libtool commit 3334f7ed5851ef1e96b052f2984c4acdbf39e20c will need reverting

Re: Intel AVX10.1 Compiler Design and Support

Do you have any comments on the interaction of AVX10 with the micro-architecture levels defined in the ABI (and supported with glibc-hwcaps directories in glibc)? Given that the levels are cumulative, should we take it that any future levels will be ones supporting 512-bit vector width for AVX

Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On Tue, Aug 08, 2023 at 04:54:46PM +0200, Martin Uecker wrote: > > > I am sure this has been discussed before, but seeing that you > test for a specific formula, let me point out the following: > > There at least three different size expression which could > make sense. Consider > > short foo {

  1   2   >