[PATCH] Document refactoring of the option -fcf-protection=x.

To override -fcf-protection, -fcf-protection=none needs to be added and then with -fcf-protection=xxx. --- htdocs/gcc-14/changes.html | 6 ++ 1 file changed, 6 insertions(+) diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index e3a68998..72b0d291 100644 --- a/htdocs/gcc-1

[PATCH] i386: Add AVX10.1 related macros

Hi all, This patch aims to add AVX10.1 related macros for libgomp's request. The request comes following: https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642025.html Ok for trunk? Thx, Haochen gcc/ChangeLog: PR target/113288 * config/i386/i386-c.cc (ix86_target_macros_i

Re：Re：[PATCH v5] RISC-V: Handle differences between XTheadvector and Vector

I'm confused why I cannot add new shapes. I think adding new shapes is the basic part in implementation for new intrinsics. -- 发件人：juzhe.zh...@rivai.ai 发送时间：2024年1月10日(星期三) 15:17 收件人："cooper.joshua"; "gcc-patches" 抄　送：Jim Wils

回复：Re：[PATCH v5] RISC-V: Handle differences between XTheadvector and Vector

For example +/* th_loadstore_width_def class. */ +struct th_loadstore_width_def : public build_base +{ + void build (function_builder &b, + const function_group_info &group) const override + { +/* Report an error if there is no xtheadvector. */ +if (!TARGET_XTHEADVECTOR) +

[PATCH v1] LoongArch: testsuite:Fixed a bug that added a target check error.

After the code is committed in r14-6948, GCC regression testing on some architectures will produce the following error: "error executing dg-final: unknown effective target keyword `loongarch*-*-*'" gcc/testsuite/ChangeLog: * lib/target-supports.exp: Removed an issue with "target keyword"

[PATCH v2] LoongArch: testsuite:Added support for loongarch.

The function of this test is to check that the compiler supports vectorization using SLP and vec_{load/store/*}_lanes. However, vec_{load/store/*}_lanes are not supported on LoongArch, such as the corresponding "st4/ld4" directives on aarch64. gcc/testsuite/ChangeLog: * gcc.dg/vect/slp-21

RE: [PATCH] RISC-V: Refine unsigned avg_floor/avg_ceil

Committed, thanks Kito. Pan -Original Message- From: Kito Cheng Sent: Wednesday, January 10, 2024 3:12 PM To: Juzhe-Zhong Cc: gcc-patches@gcc.gnu.org; kito.ch...@sifive.com; jeffreya...@gmail.com; rdapp@gmail.com Subject: Re: [PATCH] RISC-V: Refine unsigned avg_floor/avg_ceil LGT

Re: Re：[PATCH v5] RISC-V: Handle differences between XTheadvector and Vector

Why do you need to invade existing shapes ? juzhe.zh...@rivai.ai 发件人： joshua 发送时间： 2024-01-10 15:16 收件人： juzhe.zh...@rivai.ai; gcc-patches 抄送： Jim Wilson; palmer; andrew; philipp.tomsich; jeffreyalaw; christoph.muellner; jinma; cooper.qu 主题： Re：Re：[PATCH v5] RISC-V: Handle differences betwee

Re：Re：[PATCH v5] RISC-V: Handle differences between XTheadvector and Vector

These xttheadvector speical intrinsics are different from rvv1.0 in determining function name from base name. We cannot directly reuse the existing shapes. In order not to invade existing shapes, we add new shapes for new functions. Also, we create new thead-vector-builtins.cc for xtheadvector fun

Re: [PATCH] RISC-V: Refine unsigned avg_floor/avg_ceil

LGTM! On Wed, Jan 10, 2024 at 1:05 PM Juzhe-Zhong wrote: > > This patch is inspired by LLVM patches: > https://github.com/llvm/llvm-project/pull/76550 > https://github.com/llvm/llvm-project/pull/77473 > > Use vaaddu for AVG vectorization. > > Before this patch: > > vsetivlizero,8,

[PATCH][wwwdoc] gcc-14: Add arm cortex-m52 cpu support

Hi Gerald, The Arm Cortex-M52 CPU has been added to the upstream: https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642230.html I would like to document this on the gcc-14 changes.html page. Attached is the patch for gcc-wwwdocs repository. Is it OK? Regards, jasonwucjFrom 2513e83f0749045

Re: Re：[PATCH v5] RISC-V: Handle differences between XTheadvector and Vector

Why do you add theadvector shapes ? I think you can reuse the current existing shapes. +thead-vector-builtins.o: \ + $(srcdir)/config/riscv/thead-vector-builtins.cc \ + $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) $(RTL_H) \ + $(TM_P_H) memmodel.h insn-codes.h $(OPTABS_H) $(RECOG_H) \

Re: Re：[PATCH v5] RISC-V: Handle differences between XTheadvector and Vector

https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641733.html This patch is ok from my side. juzhe.zh...@rivai.ai 发件人： joshua 发送时间： 2024-01-10 10:57 收件人： juzhe.zh...@rivai.ai; gcc-patches 抄送： Jim Wilson; palmer; andrew; philipp.tomsich; jeffreyalaw; christoph.muellner; jinma; cooper.qu

Re: [PATCH v5] RISC-V: Fix register overlap issue for some xtheadvector instructions

LGTM from myside. Give another a few more days that some one want to chime in. juzhe.zh...@rivai.ai From: Jun Sha (Joshua) Date: 2024-01-10 14:51 To: gcc-patches CC: jim.wilson.gcc; palmer; andrew; philipp.tomsich; jeffreyalaw; christoph.muellner; juzhe.zhong; Jun Sha (Joshua); Jin Ma; Xianmi

[PATCH v5] RISC-V: Fix register overlap issue for some xtheadvector instructions

For th.vmadc/th.vmsbc as well as narrowing arithmetic instructions and floating-point compare instructions, an illegal instruction exception will be raised if the destination vector register overlaps a source vector register group. To handle this issue, we use "group_overlap" and "enabled" attribu

Re: [PATCH v5] RISC-V: Fix register overlap issue for some xtheadvector instructions

+ (and (eq_attr "group_overlap" "th") + (match_test "TARGET_XTHEADVECTOR")) + (const_string "no") + + (and (eq_attr "group_overlap" "rvv") + (match_test "TARGET_VECTOR && !TARGET_XTHEADVECTOR")) + (const_string "no") + ] Change it into: + (and (eq_attr "group_overlap" "thv_disabled")

[PATCH v5] RISC-V: Fix register overlap issue for some xtheadvector instructions

For th.vmadc/th.vmsbc as well as narrowing arithmetic instructions and floating-point compare instructions, an illegal instruction exception will be raised if the destination vector register overlaps a source vector register group. To handle this issue, we use "group_overlap" and "enabled" attribu

Re: [PATCH] strub: Only unbias stack point for SPARC_STACK_BOUNDARY_HACK [PR113100]

on 2024/1/8 19:44, Richard Biener wrote: > On Mon, Jan 8, 2024 at 3:35 AM Kewen.Lin wrote: >> >> Hi, >> >> As PR113100 shows, the unbiasing introduced by r14-6737 can >> cause the scrubbing to overrun and screw some critical data >> on stack like saved toc base consequently cause segfault on >> Po

[PATCH] RISC-V: Refine unsigned avg_floor/avg_ceil

This patch is inspired by LLVM patches: https://github.com/llvm/llvm-project/pull/76550 https://github.com/llvm/llvm-project/pull/77473 Use vaaddu for AVG vectorization. Before this patch: vsetivlizero,8,e8,mf2,ta,ma vle8.v v3,0(a1) vle8.v v2,0(a2) vwadd

RE: [PATCH v3] RISC-V: Bugfix for doesn't honor no-signed-zeros option

Thanks Jeff and Richard for confirmation and comments. It looks like firstly we should address the issue of the original commits in v4 and then back to if there is something we need to deal with option no-signed-zero for the riscv. Pan -Original Message- From: Jeff Law Sent: Wednesda

Re:[pushed] [PATCH v2 0/4] Adjust option handling code

Pushed to r14-7085...r14-7088 在 2024/1/8 上午9:14, Yang Yujie 写道: This patchset performs some code cleanup, and is bootstrapped and regtested on loongarch64-linux-gnu. Changes from v1 -> v2: * Replaced all TARGET_ macros from .opt. * Fixed definition of ISA_HAS_LAMCAS. Yang Yujie (4): LoongAr

[PATCH V2] RISC-V: Minor tweak dynamic cost model

v2 update: Robostify tests. While working on cost model, I notice one case that dynamic lmul cost doesn't work well. Before this patch: foo: lui a4,%hi(.LANCHOR0) li a0,1953 li a1,63 addia4,a4,%lo(.LANCHOR0) li a3,64 vsetvli

Re: Re：[PATCH v5] RISC-V: Handle differences between XTheadvector and Vector

;; We don't use early-clobber for LMUL <= 1 to get better codegen. (define_insn "*pred_cmp" - [(set (match_operand: 0 "register_operand""=vr, vr, vr, vr") + [(set (match_operand: 0 "register_operand""=vr, vr, vr, vr, &vr, &vr, &vr, &vr")

Re：Re: [PATCH v4] RISC-V: Adds the prefix "th." for the instructions of XTheadVector.

Hi Kito, Thank you for your support again. I believe we can get all our xtheadvector patches ready before the end of Feb. May I please ping the arch patch again? https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641801.html This is the patch that all the following patches rely on. Joshua

Re：[PATCH v5] RISC-V: Handle differences between XTheadvector and Vector

Hi Juzhe, Thank you for so many useful comments for this patch! There are some more patches to support xtheadvector special instrinsics as well as handle register overlap issue and rewrite assembly output. https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641774.html https://gcc.gnu.org/pip

Re: [PATCH v5] RISC-V: Handle differences between XTheadvector and Vector

Thanks for your patience. LGTM from myside. I think it's pretty clean now. I can image in the future when some day the theadvector is no longer used, we can remove it very easily. And also, the theadvector won't affect our RVV1.0 maintain since it's isolated cleanly. But I'd like to wait fo

[PATCH] Add -mevex512 into invoke.texi

Hi Richard, It seems that I send out a not updated patch. This patch should what I want to send. Thx, Haochen gcc/ChangeLog: * doc/invoke.texi: Add -mevex512. --- gcc/doc/invoke.texi | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/gcc/doc/invoke.texi b/gcc/doc

[PATCH v5] RISC-V: Handle differences between XTheadvector and Vector

This patch is to handle the differences in instruction generation between Vector and XTheadVector. In this version, we only support partial xtheadvector instructions that leverage directly from current RVV1.0 with simple adding "th." prefix. For different name xtheadvector instructions but share sa

[PATCH] config: delete unused CYG_AC_PATH_LIBERTY macro

Nothing uses this, so delete it to avoid confusion. config/ChangeLog: * acinclude.m4 (CYG_AC_PATH_LIBERTY): Delete. --- config/acinclude.m4 | 22 -- 1 file changed, 22 deletions(-) diff --git a/config/acinclude.m4 b/config/acinclude.m4 index 0abccafa0353..f18f0d6e8c7

[PATCH] Update documents for fcf-protection=

After r14-2692-g1c6231c05bdcca, the option is defined as EnumSet and -fcf-protection=branch won't unset any others bits since they're in different groups. So to override -fcf-protection, an explicit -fcf-protection=none needs to be added and then with -fcf-protection=XXX Bootstrapped and regtested

Re: [PATCH 0/5] RISC-V: Relax the -march string for accept any order

On Tue, Jan 9, 2024 at 4:59 PM Kito Cheng wrote: > > Oops, I should leave more context here: > > Actually we discussed that years ago, and most people agree with that, but I > guess we are just missing that, and also the ISA string isn't so terribly > long yet at that moment, however...the numbe

[PATCH] RISC-V: Minor tweak dynamic cost model

While working on cost model, I notice one case that dynamic lmul cost doesn't work well. Before this patch: foo: lui a4,%hi(.LANCHOR0) li a0,1953 li a1,63 addia4,a4,%lo(.LANCHOR0) li a3,64 vsetvli a2,zero,e32,mf2,ta,ma

Re: [PATCH v3] LoongArch: testsuite:Added support for vector object detection.

在 2024/1/10 上午3:51, Andreas Schwab 写道: gcc: gcc.dg/vect/vect-outer-4a-big-array.c -flto -ffat-lto-objects: error executing dg-final: unknown effective target keyword `loongarch*-*-*' gcc: gcc.dg/vect/vect-outer-4a-big-array.c: error executing dg-final: unknown effective target keyword `loonga

[PATCH, rs6000] Refactor expand_compare_loop and split it to two functions

Hi, This patch refactors function expand_compare_loop and split it to two functions. One is for fixed length and another is for variable length. These two functions share some low level common help functions. Besides above changes, the patch also does: 1. Don't generate load and compare loop w

[PATCH V2 3/4][RFC] RISC-V: Use default cost model for insn scheduling for tests affected in PR113249

Use default cost model scheduling on these test cases. All these tests introduce scan dump failures with -mtune generic-ooo. Since the vector cost models are the same across all three tunes, some of the tests in PR113249 will be fixed with this patch series. Unfortunately, 40 unique testsuite fail

[PATCH V2 1/4][RFC] RISC-V: Add non-vector types to dfa pipelines

This patch adds non-vector related insn reservations and updates/creates new insn reservations so all non-vector typed instructions have a reservation. gcc/ChangeLog: * config/riscv/generic-ooo.md (generic_ooo_sfb_alu): Add reservation (generic_ooo_branch): ditto * config/

[PATCH V2 4/4][RFC] RISC-V: Enable assert for insn_has_dfa_reservation

Enables assert that every typed instruction is associated with a dfa reservation gcc/ChangeLog: * config/riscv/riscv.cc (riscv_sched_variable_issue): enable assert Signed-off-by: Edwin Lu --- V2: - No changes --- gcc/config/riscv/riscv.cc | 6 -- 1 file changed, 4 insertions(+), 2

[PATCH V2 0/4][RFC] RISC-V: Associate typed insns to dfa reservation

This series is a prototype for adding all typed instructions to a dfa scheduling pipeline. This is what I currently have for cleaning up the cost models. Adding the vector insns to the dfa pipelines changes the expected output of a lot of test cases as expected. Should I update the expected outp

[PATCH V2 2/4][RFC] RISC-V: Add vector related reservations

This patch copies the vector reservations from generic-ooo.md and inserts them into generic.md and sifive.md. Creates new vector crypto related insn reservations. gcc/ChangeLog: * config/riscv/generic-ooo.md (generic_ooo_crypto_aes): create reservation (generic_ooo_crypto_sha): d

[Committed] RISC-V: Robostify dynamic lmul test

While working on refining the cost model, I notice this test will generate unexpected scalar xor instructions if we don't tune cost model carefully. Add more assembler to avoid future regression. Committed. gcc/testsuite/ChangeLog: * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-7.c: A

Re: [PATCH 0/5] RISC-V: Relax the -march string for accept any order

Oops, I should leave more context here: Actually we discussed that years ago, and most people agree with that, but I guess we are just missing that, and also the ISA string isn't so terribly long yet at that moment, however...the number of extensions are growth so fast in last year, so I think it'

Re: [PATCH v8 1/4] c++: P0847R7 (deducing this) - prerequisite changes. [PR102609]

On Tuesday, January 9th, 2024 at 3:52 PM, Jason Merrill wrote: > > > On 1/9/24 17:34, waffl3x wrote: > > > On Tuesday, January 9th, 2024 at 2:56 PM, Jason Merrill ja...@redhat.com > > wrote: > > > > > > Is the type of an implicit object parameter specified elsewhere? I have > > look

[PATCH v2] rs6000: Fix ASAN linker errors for Power ELF V1 ABI [PR113284]

v1: https://inbox.sourceware.org/gcc-patches/20240109105253.332676-1-...@linux.ibm.com/ v1 -> v2: Move the .LASANPC label to the .text section (Jakub). Jakub okay-ed this version in the GCC Bugzilla. Bootstrap and regtest running on ppc64le-redhat-linux and powerpc64-linux-gnu. Ok for

[committed] libstdc++: Fix Unicode property detection functions

Tested x86_64-linux. Pushed to trunk. -- >8 -- Fix some copy & pasted logic in __is_extended_pictographic. This function should yield false for the values before the first edge, not true. Also add a missing boundary condition check in __incb_property. Also Fix an off-by-one error in _Utf_iterato

[r14-7033 Regression] FAIL: g++.dg/gomp/bad-array-section-4.C -std=c++98 at line 37 (test for warnings, line 35) on Linux/x86_64

On Linux/x86_64, 1413af02d62182bc1e19698aaa4dae406f8f13bf is the first bad commit commit 1413af02d62182bc1e19698aaa4dae406f8f13bf Author: Julian Brown Date: Mon Sep 12 17:11:29 2022 + OpenMP: lvalue parsing for map/to/from clauses (C++) caused FAIL: g++.dg/gomp/array-section-1.C -st

Re: [PATCH 1/8] OpenMP: lvalue parsing for map/to/from clauses (C++)

Hi Julian! On 2024-01-07T16:04:37+0100, Tobias Burnus wrote: > Am 05.01.24 um 13:23 schrieb Julian Brown: >> Here's a rebased/retested version [...] > LGTM - [...] Got pushed as commit r14-7033-g1413af02d62182bc1e19698aaa4dae406f8f13bf "OpenMP: lvalue parsing for map/to/from clauses (C++)". So

Re: [PATCH v8 1/4] c++: P0847R7 (deducing this) - prerequisite changes. [PR102609]

On 1/9/24 17:34, waffl3x wrote: On Tuesday, January 9th, 2024 at 2:56 PM, Jason Merrill wrote: On 1/9/24 15:58, Jason Merrill wrote: On 1/6/24 19:00, waffl3x wrote: Bootstrapped and tested on x86_64-linux with no regressions. I'm considering this finished, I have CWG2586 working but I have

Re: [PATCH] PR target/112886, Add %S to print_operand for vector pair support

On 1/5/24 4:18 PM, Michael Meissner wrote: > @@ -14504,13 +14504,17 @@ print_operand (FILE *file, rtx x, int code) > print_operand (file, x, 0); >return; > > +case 'S': > case 'x': > - /* X is a FPR or Altivec register used in a VSX context. */ > + /* X is a FPR

Re: Re: [PATCH v4] RISC-V: Adds the prefix "th." for the instructions of XTheadVector.

Yes. I aggree with you that we should wait until all theadvector are acccepted. Thanks. juzhe.zh...@rivai.ai From: Jeff Law Date: 2024-01-10 01:49 To: 钟居哲; cooper.joshua; gcc-patches CC: jim.wilson.gcc; palmer; andrew; philipp.tomsich; Christoph Müllner; jinma; Cooper Qu Subject: Re: [PATCH

Re: [PATCH v8 1/4] c++: P0847R7 (deducing this) - prerequisite changes. [PR102609]

On Tuesday, January 9th, 2024 at 2:56 PM, Jason Merrill wrote: > > > On 1/9/24 15:58, Jason Merrill wrote: > > > On 1/6/24 19:00, waffl3x wrote: > > > > > Bootstrapped and tested on x86_64-linux with no regressions. > > > > > > I'm considering this finished, I have CWG2586 working bu

Re: [PATCH] Fix spurious match in extract_symvers

On Tue, 9 Jan 2024 at 21:47, Andreas Schwab wrote: > > Tighten the regex to find the start of the .dynsym symtab in the readelf > output to avoid matching the section symbol in the normal symtab. OK, thanks. > > libstdc++-v3: > * scripts/extract_symvers.in: Require final colon to only ma

[PATCH] libstdc++: Prefer posix_memalign for aligned-new [PR113258]

Does anybody see any problem with making this change, so that we avoid the problem described in the PR? -- >8 -- As described in PR libstdc++/113258 there are old versions of tcmalloc which replace malloc and related APIs, but do not repalce aligned_alloc because it didn't exist at the time they

Re: [PATCH v8 1/4] c++: P0847R7 (deducing this) - prerequisite changes. [PR102609]

On 1/9/24 15:58, Jason Merrill wrote: On 1/6/24 19:00, waffl3x wrote: Bootstrapped and tested on x86_64-linux with no regressions. I'm considering this finished, I have CWG2586 working but I have not included it in this version of the patch. I was not happy with the amount of work I had done on

[PATCH] Fix spurious match in extract_symvers

Tighten the regex to find the start of the .dynsym symtab in the readelf output to avoid matching the section symbol in the normal symtab. libstdc++-v3: * scripts/extract_symvers.in: Require final colon to only match .dsynsym in the header of the dynamic symtab. --- libstdc++-v3/s

Re: [PATCH v8 1/4] c++: P0847R7 (deducing this) - prerequisite changes. [PR102609]

On Tuesday, January 9th, 2024 at 1:58 PM, Jason Merrill wrote: > > > On 1/6/24 19:00, waffl3x wrote: > > > Bootstrapped and tested on x86_64-linux with no regressions. > > > > I'm considering this finished, I have CWG2586 working but I have not > > included it in this version of the patch.

Re: [PATCH v8 1/4] c++: P0847R7 (deducing this) - prerequisite changes. [PR102609]

On 1/6/24 19:00, waffl3x wrote: Bootstrapped and tested on x86_64-linux with no regressions. I'm considering this finished, I have CWG2586 working but I have not included it in this version of the patch. I was not happy with the amount of work I had done on it. I will try to get it finished befo

Re: [PATCH v4] AArch64: Cleanup memset expansion

Hi Richard, >> +#define MAX_SET_SIZE(speed) (speed ? 256 : 96) > > Since this isn't (AFAIK) a standard macro, there doesn't seem to be > any need to put it in the header file.  It could just go at the head > of aarch64.cc instead. Sure, I've moved it in v4. >> +  if (len <= 24 || (aarch64_tune_p

Re: [PATCH] aarch64: Fix dwarf2cfi ICEs due to recent CFI note changes [PR113077]

Alex Coplan writes: > Hi, > > In r14-6604-gd7ee988c491cde43d04fe25f2b3dbad9d85ded45 we changed the CFI notes > attached to callee saves (in aarch64_save_callee_saves). That patch changed > the ldp/stp representation to use unspecs instead of PARALLEL moves. This > meant > that we needed to atta

[PATCH] Fix debug info for enumeration types with reverse Scalar_Storage_Order

Hi, this is not really a regression but the patch was written last week and is quite straightforward, so hopefully can nevertheless be OK. It implements the support of DW_AT_endianity for enumeration types because they are scalar and, therefore, reverse Scalar_Storage_Order is supported for th

Re: [PATCH 6/4] libbacktrace: Add loaded dlls after initialize

Am 07.01.2024 um 18:03 schrieb Eli Zaretskii: Date: Sun, 7 Jan 2024 17:07:06 +0100 Cc: i...@google.com, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org From: Björn Schäpers That was about GetModuleHandle, not about GetModuleHandleEx. For the latter, all Windows versions that support it also support

Re: [PATCH] Add support for function attributes and variable attributes

On Wed, 2023-11-15 at 17:53 +0100, Guillaume Gomez wrote: > Hi, > > This patch adds the (incomplete) support for function and variable > attributes. The added attributes are the ones we're using in > rustc_codegen_gcc but all the groundwork is done to add more (and we > will very likely add more a

Re: [PATCH v3] LoongArch: testsuite:Added support for vector object detection.

gcc: gcc.dg/vect/vect-outer-4a-big-array.c -flto -ffat-lto-objects: error executing dg-final: unknown effective target keyword `loongarch*-*-*' gcc: gcc.dg/vect/vect-outer-4a-big-array.c: error executing dg-final: unknown effective target keyword `loongarch*-*-*' gcc: gcc.dg/vect/vect-outer-4a.c

Re: [PATCH] vect: Fix ICE in vect_analyze_loop_costing [PR113210]

On 1/6/24 01:59, Jakub Jelinek wrote: Hi! The following testcase ICEs (on ARM/RISCV with certain options), because niters analysis computes number of latch executions for the loop as (short unsigned int) (a.0_1 + 255) + 1 > 256 ? ~(short unsigned int) (a.0_1 + 255) : 0 where a.0_1 is unsign

Re: [PATCH v2 2/2] asan: Align .LASANPC on function boundary

On Tue, 2024-01-09 at 11:55 -0700, Jeff Law wrote: > > > On 1/2/24 12:41, Ilya Leoshkevich wrote: > > GCC can emit code between the function label and the .LASANPC > > label, > > making the latter unaligned.  Some architectures cannot load > > unaligned > > labels directly and require literal poo

Re: [RFC] Either fix or disable SME feature for `aarch64-w64-mingw32` target?

Hello. I forgot to add the target maintainers to the CC. My apologies for that. Furthermore, I am adding also relevant changes in `libgcc/config/aarch64/lse.S` file to the patch. Originally we wanted to submit those changes separately but after the feedback from Andrew Pinski, it makes sense to

Re: [PATCH] c++: reference variable as default targ [PR101463]

On 1/5/24 15:01, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Here during default template argument substitution we wrongly consider the (substituted) default arguments v and vt as value-dependent[1] which ultimately leads to dedu

Re: [PATCH v2 2/2] asan: Align .LASANPC on function boundary

On 1/2/24 12:41, Ilya Leoshkevich wrote: GCC can emit code between the function label and the .LASANPC label, making the latter unaligned. Some architectures cannot load unaligned labels directly and require literal pool entries, which is inefficient. Move the invocation of asan_function_sta

Re: [PATCH v3] EXPR: Emit an truncate if 31+ bits polluted for SImode

On 1/3/24 16:39, Richard Sandiford wrote: YunQiang Su writes: On TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true platforms, if 31 or above bits is polluted by an bitops, we will need an truncate. Let's emit one, and mark let's use the same hardreg as in and out, the RTL may like: (i

Re: [PATCH] Keep track of the FUNCTION_BEG note

On 1/5/24 09:28, Richard Sandiford wrote: function.cc emits a NOTE_FUNCTION_BEG after all arguments have been copied to pseudos. It then records this note in parm_birth_insn. Various other pieces of code use this insn as a convenient place to insert things at the start of the function. Howev

Re: [PATCH v5 1/1] RISC-V: Add support for XCVbi extension in CV32E40P

On 1/8/24 06:14, Mary Bennett wrote: Spec: github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md Contributors: Mary Bennett Nandni Jamnadas Pietra Ferreira Charlie Keaney Jessica Mills Craig Blackmore Simon Cook Jeremy Bennett Hele

Re: [PATCH 0/5] RISC-V: Relax the -march string for accept any order

On 1/8/24 06:47, Kito Cheng wrote: Do you know how to build a ISA string with following extension? - g - c - zba - zbs - svnapot - zve64d - zvl128b Don't trial and error with your gcc and don't read RISC-V ISA spec! OK, I believe it's impossible for most people, even I work for RISC-V so ma

Re: [PATCH] c-family: copy attribute diagnostic fixes [PR113262]

On 1/9/24 01:52, Jakub Jelinek wrote: Hi! The copy attributes is allowed on decls as well as types and even has checks whether decl (set to *node) is DECL_P or TYPE_P, but for diagnostics unconditionally uses DECL_SOURCE_LOCATION (decl), which obviously only works if it applies to a decl. Th

Re: [PATCH v2] RISC-V: T-HEAD: Add support for the XTheadInt ISA extension

On 11/17/23 00:33, Jin Ma wrote: The XTheadInt ISA extension provides acceleration interruption instructions as defined in T-Head-specific: * th.ipush * th.ipop Ref: https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.3.0/xthead-2023-11-10-2.3.0.pdf gcc/ChangeLog:

Re: [PATCH v4] RISC-V: Adds the prefix "th." for the instructions of XTheadVector.

On 1/8/24 16:04, 钟居哲 wrote: This patch looks ok from myside. Likewise. So I think the only question for this specific patch is whether or not it makes sense to include it now or wait for more of the thead bits to get to acceptance. I tend to think it should wait since I don't think it ha

Re: [PATCH v3] RISC-V: Bugfix for doesn't honor no-signed-zeros option

On 1/8/24 03:45, Richard Biener wrote: On Tue, Jan 2, 2024 at 2:37 PM wrote: From: Pan Li According to the sematics of no-signed-zeros option, the backend like RISC-V should treat the minus zero -0.0f as plus zero 0.0f. Consider below example with option -fno-signed-zeros. void test (fl

[committed] Adding missing prototype for __clzhi2 to xstormy port

xstormy16 has failed since the c99 transition due to a missing prototype for __clzhi2 in the implementation of storm16_count_loaading_zeros. This fixes the missing prototype. Pushed to the trunk. jeffcommit 9f7afa99c67f039e43019ebd08d14a7f01e2d89c Author: Jeff Law Date: Tue Jan 9 10:21:28 2

[committed] libstdc++: Simplify some chrono formatters

Tested aarch64-linux. Pushed to trunk. -- >8 -- I don't remember exactly why I made these bits of code reserve space in a COW string and append to it, rather than just use the string returned from std::format (which will undergo copy elision). The _Str_sink type used by std::format means the stri

[committed] Fix minor bug in epiphany port

So I consider this port dead as it semi-randomly fails in reload due to unrelated changes earlier in the gimple and RTL pipelines. Regardless Richard S's late-combine work did show a very obvious error in the port that we should go ahead and fix as long as the port is in-tree. The epiphany

[committed] Fix minor bug on mn103 port

Richard Sandiford debugged a failure on the mn103 port with his late-combine patches down to the subdi3 pattern not specifying the isa on alternatives which required newer variants of the chip family. This patch adds the missing isa attribute and the port now works with his late-combine patc

Re: [PATCH 3/7] Lockfile.

Hi, > You do not implement GCOV_LINKED_WITH_LOCKING patch, does locking work > with mingw? Or we only build gcc with cygwin emulation layer these days? I tried to test _locking implementation with both mingw and msys2, in both cases fcntl was present and _locking was not. Admittedly I was unable t

[PATCH 2/7 v2] lto: Remove random_seed from section name.

This patch removes suffixes from section names during LTO linking. These suffixes were originally added for ld -r to work (PR lto/44992). They were added to all LTO object files, but are only useful before WPA. After that they waste space, and if kept random, make LTO caching impossible. Bootstra

Re: [wwwdocs] gcc-14/changes.html: OpenMP - improve wording

Ups - now attached. Thanks Martin! Martin Jambor wrote: On Mon, Jan 08 2024, Tobias Burnus wrote: The attached patch there was no patch attached to your message. Martin does a tiny updated to the OpenMP features (AMD GCN now also has an optimized memcpy_rect not only nvptx), but the main c

[PATCH] hwasan: Check if Intel LAM_U57 is enabled

When -fsanitize=hwaddress is used, libhwasan will try to enable LAM_U57 in the startup code. Update the target check to enable hwaddress tests if LAM_U57 is enabled. Also compile hwaddress tests with -mlam=u57 on x86-64 since hwasan requires LAM_U57 on x86-64. * lib/hwasan-dg.exp (check_

Re: [PATCH] libgccjit: Add missing builtins needed by optimizations

On Fri, 2023-12-22 at 09:39 -0500, Antoni Boucher wrote: > Hi. > This patch adds missing builtins needed by optimizations. > Thanks for the review. The patch looks good to me. Thanks! Dave

Re: [PATCH] libgccjit: Implement sizeof operator

On Fri, 2023-12-22 at 10:25 -0500, Antoni Boucher wrote: > Hi. > This patch adds the support of the sizeof operator. > I was wondering if this new API entrypoint should take a location as > a > parameter. What do you think? I'd prefer it if it did (even if it's currently ignored internally), but i

[PATCH][committed]middle-end: removed unused variable in vectorizable_live_operation_1

Hi All, It looks like the previous patch had an unused variable. It's odd that my bootstrap didn't catch it (I'm assuming -Werror is still on for O3 bootstraps) but this fixes it. Committed to fix bootstrap. Thanks, Tamar gcc/ChangeLog: * tree-vect-loop.cc (vectorizable_live_operation_

Re: [PATCH V3 0/3] RISC-V: Add intrinsics for Bitmanip and Scalar Crypto extensions

The tests still fail. gcc: Unexpected fails for rv64gc lp64d medlow FAIL: gcc.target/riscv/scalar_bitmanip_intrinsic-32.c -O0 (test for excess errors) FAIL: gcc.target/riscv/scalar_bitmanip_intrinsic-32.c -O1 (test for excess errors) FAIL: gcc.target/riscv/scalar_bitmanip_intrinsic-32.c -O

Re: [PATCH]middle-end: check if target can do extract first for early breaks [PR113199]

On Tue, Jan 9, 2024 at 8:10 AM Tamar Christina wrote: > > Hmm I'm confused as to why It didn't break mine.. just did one again.. anyway > I'll remove the unused variable. Can you also make vectorizable_live_operation_1 static? > > -Original Message- > > From: Rainer Orth > > Sent: Tues

RE: [PATCH]middle-end: check if target can do extract first for early breaks [PR113199]

Hmm I'm confused as to why It didn't break mine.. just did one again.. anyway I'll remove the unused variable. > -Original Message- > From: Rainer Orth > Sent: Tuesday, January 9, 2024 4:06 PM > To: Richard Biener > Cc: Tamar Christina ; gcc-patches@gcc.gnu.org; nd > ; j...@ventanamicro

Re: [PATCH]middle-end: check if target can do extract first for early breaks [PR113199]

Richard Biener writes: > On Tue, 9 Jan 2024, Tamar Christina wrote: > >> > > - >> > > - gimple_seq_add_seq (&stmts, tem); >> > > - >> > > - scalar_res = gimple_build (&stmts, CFN_EXTRACT_LAST, scalar_type, >> > > - mask, vec_lhs_phi); >> > > +scal

Re: [PATCH]middle-end: check if target can do extract first for early breaks [PR113199]

On Tue, Jan 9, 2024 at 4:13 AM Richard Biener wrote: > > On Tue, 9 Jan 2024, Tamar Christina wrote: > > > > > - > > > > - gimple_seq_add_seq (&stmts, tem); > > > > - > > > > - scalar_res = gimple_build (&stmts, CFN_EXTRACT_LAST, scalar_type, > > > > - mask, vec_l

Re: [PATCH] libgccjit: Support signed char flag

On Thu, 2023-12-21 at 08:42 -0500, Antoni Boucher wrote: > Hi. > This patch adds support for the -fsigned-char flag. Thanks. The patch looks correct to me. > I'm not sure how to test it since I stumbled upon this bug when I > found > this other bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1

[PATCH] aarch64: Fix dwarf2cfi ICEs due to recent CFI note changes [PR113077]

Hi, In r14-6604-gd7ee988c491cde43d04fe25f2b3dbad9d85ded45 we changed the CFI notes attached to callee saves (in aarch64_save_callee_saves). That patch changed the ldp/stp representation to use unspecs instead of PARALLEL moves. This meant that we needed to attach CFI notes to all frame-related p

Re: [PATCH] SECURITY.txt: Drop "exploitable" in reference to hardening issues

> Am 09.01.2024 um 16:13 schrieb Siddhesh Poyarekar : > > On 2023-12-18 09:35, Siddhesh Poyarekar wrote: >> The "exploitable vulnerability" may lead to a misunderstanding that missed >> hardening issues are considered vulnerabilities, just that they're not >> exploitable. This is not true,

Re: [PATCH] SECURITY.txt: Drop "exploitable" in reference to hardening issues

On 2023-12-18 09:35, Siddhesh Poyarekar wrote: The "exploitable vulnerability" may lead to a misunderstanding that missed hardening issues are considered vulnerabilities, just that they're not exploitable.  This is not true, since while hardening bugs may be security-relevant, the absence of ha

Re: [PATCH] RISC-V: Also handle sign extension in branch costing

On 1/7/24 17:06, Maciej W. Rozycki wrote: Complement commit c1e8cb3d9f94 ("RISC-V: Rework branch costing model for if-conversion") and also handle extraneous sign extend operations that are sometimes produced by `noce_try_cmove_arith' instead of zero extend operations, making branch costing co

Re: [Committed] RISC-V: Use MAX instead of std::max [VSETVL PASS]

On 1/7/24 16:07, 钟居哲 wrote: Since in the previous review from Robin, he have ever asked me change std::max into MAX, I thought the policy is preferring MAX instead of std::max. I change the codes to make them consistent but it seems I am wrong. So is it reasonable that I change all RVV-rela

Re: [PATCH] arm/aarch64: Add bti for all functions [PR106671]

Andrea Corallo writes: > Feng Xue OS via Gcc-patches writes: > >> This patch extends option -mbranch-protection=bti with an optional argument >> as bti[+all] to force compiler to unconditionally insert bti for all >> functions. Because a direct function call at the stage of compiling might be >>

Re: [PATCH] c-family: copy attribute diagnostic fixes [PR113262]

On Tue, Jan 09, 2024 at 09:52:17AM +0100, Jakub Jelinek wrote: > Hi! > > The copy attributes is allowed on decls as well as types and even has > checks whether decl (set to *node) is DECL_P or TYPE_P, but for diagnostics > unconditionally uses DECL_SOURCE_LOCATION (decl), which obviously only work

RE: [PATCH]middle-end: Fix dominators updates when peeling with multiple exits [PR113144]

On Tue, 9 Jan 2024, Tamar Christina wrote: > > -Original Message- > > From: Richard Biener > > Sent: Tuesday, January 9, 2024 1:51 PM > > To: Tamar Christina > > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com > > Subject: RE: [PATCH]middle-end: Fix dominators updates when peelin

  1   2   >