[Committed] RISC-V: Fix typo[VSETVL PASS]

When fixing an issue, I find there is a typo in VSETVL PASS. Change 'use_by' into 'used_by'. Committed it as it is very obvious. gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (pre_vsetvl::fuse_local_vsetvl_info): Fix typo. (pre_vsetvl::pre_global_vsetvl_info): Ditto. --- gcc/

[PATCH 0/4] RISC-V: Fix 'Zicbop'-related bugs (fix ICE and remove broken built-in)

Hello, As I explained earlier: , the builtin function for RISC-V "__builtin_riscv_zicbop_cbo_prefetchi" is completely broken and should be removed. Also, I noted that:

[PATCH 1/4] RISC-V: Recategorize "prefetch" availabilities

From: Tsukasa OI Because they are for all prefetch instructions, "prefetch" fits better than "prefetchi". gcc/ChangeLog: * config/riscv/riscv-builtins.cc: Rename availabilities "prefetchi{32,64}" to "prefetch{32,64}". * config/riscv/riscv-cmo.def (__builtin_riscv

[PATCH 2/4] RISC-V: Remove broken __builtin_riscv_zicbop_cbo_prefetchi

From: Tsukasa OI __builtin_riscv_zicbop_cbo_prefetchi (corresponding "prefetch.i" instruction from the 'Zicbop' extension) is completely broken (not even functional) and should be removed rather than fixing it because it has no good way to "fix" this built-in function. gcc/ChangeLog: *

[PATCH 3/4] RISC-V: Add not broken RW prefetch RTL instructions without offsets

From: Tsukasa OI To prepare adding new not broken prefetch built-in functions and fixing an ICE in __builtin_prefetch, this commit adds two new instructions, each corresponding a 'Zicbop' prefetch hint instruction, but with no specifiable offset field for simplicity. This commit also excludes ne

[PATCH 4/4] RISC-V: Fix ICE by expansion and register coercion

From: Tsukasa OI A "prefetch" instruction on RISC-V GCC emits a machine hint instruction directly when the 'Zicbop' extension is enabled but it could cause an ICE when the address argument of __builtin_prefetch is an integral constant (such like 0 [NULL] or some other [but possibly not all] fixed

Pushed: [PATCH 0/5] LoongArch: Better balance between relaxation and scheduling

Pushed r14-{4848..4852}. On Thu, 2023-10-19 at 22:02 +0800, Xi Ruoyao wrote: > For relaxation we are now generating assembler macros for symbolic > addresses everywhere, but this is limiting scheduling and there are > known situations where the relaxation cannot improve the code. > > 1. When we a

Re: [PATCH] convert_to_complex vs invalid_conversion [PR111903]

On Sat, Oct 21, 2023 at 8:07 PM Andrew Pinski wrote: > > convert_to_complex when creating a COMPLEX_EXPR does > not currently check if either the real or imag parts > was not error_mark_node. This later on confuses the gimpilfier > when there was a SAVE_EXPR wrapped around that COMPLEX_EXPR. > The

Re: [PATCHv2] move the (a-b) CMP 0 ? (a-b) : (b-a) optimization from fold_cond_expr_with_comparison to match

On Sun, Oct 22, 2023 at 2:13 AM Andrew Pinski wrote: > > From: Andrew Pinski > > This patch moves the `(a-b) CMP 0 ? (a-b) : (b-a)` optimization > from fold_cond_expr_with_comparison to match. > > Bootstrapped and tested on x86_64-linux-gnu. OK. > Changes in: > v2: Removes `(a == b) ? 0 : (b -

Re: [PATCH] Use error_mark_node after error in convert

On Mon, Oct 23, 2023 at 12:22 AM Andrew Pinski wrote: > > While working on PR c/111903, I Noticed that > convert will convert integer_zero_node to that > type after an error instead of returning error_mark_node. > From what I can tell this was the old way of not having > error recovery since other

Re: [PATCH 1/5] Remove obsolete debugging formats from names list

On Mon, Oct 23, 2023 at 2:56 AM Mark Harmstone wrote: > > STABS and xcoff have been removed, but are still in debug_type_names, > which ought to match debug_type_masks. This results in the following > minor bug with GCC 13: > > $ x86_64-pc-linux-gnu-gcc -gvms -c tmp.c > cc1: error: target system d

[PATCH v1] RISC-V: Bugfix for merging undef tmp register for trunc

From: Pan Li For trunc function autovec, there will be one step like below take MU for the merge operand. rtx tmp = gen_reg_rtx (vec_int_mode); emit_vec_cvt_x_f_rtz (tmp, op_1, mask, vec_fp_mode); The MU will leave the tmp (aka dest register) register unmasked elements unchanged and it is undef

Re: [PATCH v1] RISC-V: Bugfix for merging undef tmp register for trunc

LGTM。 juzhe.zh...@rivai.ai From: pan2.li Date: 2023-10-23 15:53 To: gcc-patches CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng Subject: [PATCH v1] RISC-V: Bugfix for merging undef tmp register for trunc From: Pan Li For trunc function autovec, there will be one step like below take MU

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On Fri, Oct 20, 2023 at 10:41 PM Qing Zhao wrote: > > > > > On Oct 20, 2023, at 3:10 PM, Siddhesh Poyarekar wrote: > > > > On 2023-10-20 14:38, Qing Zhao wrote: > >> How about the following: > >> Add one more parameter to __builtin_dynamic_object_size(), i.e > >> __builtin_dynamic_object_size (

RE: [PATCH v1] RISC-V: Bugfix for merging undef tmp register for trunc

Committed, thanks Juzhe. Pan From: juzhe.zh...@rivai.ai Sent: Monday, October 23, 2023 3:56 PM To: Li, Pan2 ; gcc-patches Cc: Li, Pan2 ; Wang, Yanzhang ; kito.cheng Subject: Re: [PATCH v1] RISC-V: Bugfix for merging undef tmp register for trunc LGTM。 juzhe.z

Re: [PATCH] [PR111520] set hardcmp eh probs (was: rename make_eh_edges to make_eh_edge)

On Sat, Oct 21, 2023 at 9:17 AM Alexandre Oliva wrote: > > On Oct 20, 2023, Richard Biener wrote: > > >> * tree-eh.h (make_eh_edges): Rename to... > >> (make_eh_edge): ... this. > >> * tree-eh.cc: Likewise. Adjust all callers. > > Once the above goes in (it depends on the strub monster patch), t

Re: [PATCH 01/22] Add condition coverage profiling

On Sat, 21 Oct 2023, J?rgen Kvalsvik wrote: > On 05/10/2023 22:39, J?rgen Kvalsvik wrote: > > On 05/10/2023 21:59, Jan Hubicka wrote: > >>> > >>> Like Wahlen et al this implementation records coverage in fixed-size > >>> bitsets which gcov knows how to interpret. This is very fast, but > >>> intro

Re: [PATCH] middle-end: don't keep .MEM guard nodes for PHI nodes who dominate loop [PR111860]

On Fri, 20 Oct 2023, Tamar Christina wrote: > Hi All, > > The previous patch tried to remove PHI nodes that dominated the first loop, > however the correct fix is to only remove .MEM nodes. > > This patch thus makes the condition a bit stricter and only tries to remove > MEM phi nodes. > > I co

[PING ^1][PATCH v2] rs6000: Add new pass for replacement of contiguous addresses vector load lxv with lxvp

Ping ^1. Forwarded Message Subject: [PING ^0][PATCH v2] rs6000: Add new pass for replacement of contiguous addresses vector load lxv with lxvp Date: Sun, 15 Oct 2023 17:43:24 +0530 From: Ajit Agarwal To: gcc-patches CC: Segher Boessenkool , Kewen.Lin , Peter Bergner Hell

[PATCH v2] gcc.c-torture/execute/builtins/fputs.c: fputs_unlocked prototype

Current glibc headers only declare fputs_unlocked for _GNU_SOURCE, so define it to obtain an official prototype. Add a fallback prototype declaration for other systems that do not have fputs_unlocked. This seems to the most straightforward approach to avoid an implicit function declaration, witho

Re: [PATCH] gcc.c-torture/execute/builtins/fputs.c: Define _GNU_SOURCE

* Andrew Pinski: > On Sun, Oct 22, 2023 at 12:47 AM Florian Weimer wrote: >> >> Current glibc headers only declare fputs_unlocked for _GNU_SOURCE. >> Defining the macro avoids an implicit function declaration. > > This does not help targets that don't use glibc though. > Note for builtins testsui

[PATCH] Support vec_cmpmn/vcondmn for v2hf/v4hf.

Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. Ready push to trunk. gcc/ChangeLog: PR target/103861 * config/i386/i386-expand.cc (ix86_expand_sse_movcc): Handle V2HF/V2BF/V4HF/V4BFmode. * config/i386/mmx.md (vec_cmpv4hfqi): New expander. (vcondv4

[PATCH] RISC-V: Fix ICE for the fusion case from vsetvl to scalar move[PR111927]

ICE: during RTL pass: vsetvl : In function 'riscv_lms_f32': :240:1: internal compiler error: in merge, at config/riscv/riscv-vsetvl.cc:1997 240 | } In general compatible_p (avl_equal_p) has: if (next.has_vl () && next.vl_used_by_non_rvv_insn_p ()) return false; Don't fuse AVL of vs

Re: [PATCH] rust: build failure after NON_DEPENDENT_EXPR removal [PR111899]

Hi Patrick! On 2023-10-20T13:36:30-0400, Patrick Palka wrote: > Built on x86_64-pc-linux-gnu, pushed to trunk as obvious (hopefully). > > -- >8 -- > > This patch removes stray NON_DEPENDENT_EXPR checks following the removal > of this tree code from the C++ FE. (Since this restores the build I >

[PATCH] LoongArch:Enable vcond_mask_mn expanders for SF/DF modes.

If the vcond_mask patterns don't support fp modes, the vector FP comparison instructions will not be generated. gcc/ChangeLog: * config/loongarch/lasx.md (vcond_mask_): Change to (vcond_mask_): this. * config/loongarch/lsx.md (vcond_mask_): Change to

Re: [PATCH] RISC-V: Fix ICE for the fusion case from vsetvl to scalar move[PR111927]

Few minor comments: On Mon, Oct 23, 2023 at 5:04 PM Juzhe-Zhong wrote: > > ICE: > > during RTL pass: vsetvl > : In function 'riscv_lms_f32': > :240:1: internal compiler error: in merge, at > config/riscv/riscv-vsetvl.cc:1997 > 240 | } > > In general compatible_p (avl_equal_p) has: > > if (

[PATCH V2] RISC-V: Fix ICE for the fusion case from vsetvl to scalar move[PR111927]

ICE: during RTL pass: vsetvl : In function 'riscv_lms_f32': :240:1: internal compiler error: in merge, at config/riscv/riscv-vsetvl.cc:1997 240 | } In general compatible_p (avl_equal_p) has: if (next.has_vl () && next.vl_used_by_non_rvv_insn_p ()) return false; Don't fuse AVL of vs

[PATCH] LoongArch:Enable vcond_mask_mn expanders for SF/DF modes.

If the vcond_mask patterns don't support fp modes, the vector FP comparison instructions will not be generated. gcc/ChangeLog: * config/loongarch/lasx.md (vcond_mask_): Change to (vcond_mask_): this. * config/loongarch/lsx.md (vcond_mask_): Change to

Re: [PATCH V2] RISC-V: Fix ICE for the fusion case from vsetvl to scalar move[PR111927]

LGTM Juzhe-Zhong 於 2023年10月23日 週一 17:41 寫道： > ICE: > > during RTL pass: vsetvl > : In function 'riscv_lms_f32': > :240:1: internal compiler error: in merge, at > config/riscv/riscv-vsetvl.cc:1997 > 240 | } > > In general compatible_p (avl_equal_p) has: > > if (next.has_vl () && next.vl_use

[PATCH v1] RISC-V: Remove unnecessary asm check for vec cvt

From: Pan Li The vsetvl asm check is unnecessary for the vector convert. We should be focus for constrait and leave the vsetvl test to the vsetvl pass. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/unop/cvt-0.c: Remove the vsetvl asm check from func body. * gcc

Re: [PATCH v1] RISC-V: Remove unnecessary asm check for vec cvt

LGTM。 juzhe.zh...@rivai.ai From: pan2.li Date: 2023-10-23 17:54 To: gcc-patches CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng Subject: [PATCH v1] RISC-V: Remove unnecessary asm check for vec cvt From: Pan Li The vsetvl asm check is unnecessary for the vector convert. We should be focu

RE: [PATCH v1] RISC-V: Remove unnecessary asm check for vec cvt

Committed, thanks Juzhe. Pan From: juzhe.zh...@rivai.ai Sent: Monday, October 23, 2023 5:57 PM To: Li, Pan2 ; gcc-patches Cc: Li, Pan2 ; Wang, Yanzhang ; kito.cheng Subject: Re: [PATCH v1] RISC-V: Remove unnecessary asm check for vec cvt LGTM。 juzhe.zh...@ri

[PATCH] LoongArch:Enable vcond_mask_mn expanders for SF/DF modes.

If the vcond_mask patterns don't support fp modes, the vector FP comparison instructions will not be generated. gcc/ChangeLog: * config/loongarch/lasx.md (vcond_mask_): Change to (vcond_mask_): this. * config/loongarch/lsx.md (vcond_mask_): Change to

RE: [PATCH V2] RISC-V: Fix ICE for the fusion case from vsetvl to scalar move[PR111927]

Committed, thanks Kito. Pan From: Kito Cheng Sent: Monday, October 23, 2023 5:50 PM To: Juzhe-Zhong Cc: GCC Patches ; Kito Cheng ; Jeff Law ; Robin Dapp Subject: Re: [PATCH V2] RISC-V: Fix ICE for the fusion case from vsetvl to scalar move[PR111927] LGTM Juzhe-Zhong mailto:juzhe.zh...@riva

[PATCH] LoongArch:Enable vcond_mask_mn expanders for SF/DF modes.

If the vcond_mask patterns don't support fp modes, the vector FP comparison instructions will not be generated. gcc/ChangeLog: * config/loongarch/lasx.md (vcond_mask_): Change to (vcond_mask_): this. * config/loongarch/lsx.md (vcond_mask_): Change to

[PATCH V12 4/4] ree: Improve ree pass using defined abi interfaces

Hello Vineet, Jeff and Bernhard: This version 11 of the patch uses abi interfaces to remove zero and sign extension elimination. Bootstrapped and regtested on powerpc-linux-gnu. In this version (version 11) of the patch following review comments are incorporated. a) Removal of hard code zero_e

Re: [PING][PATCH 2/2] arm: Add support for MVE Tail-Predicated Low Overhead Loops

Ping for Jeff or another global maintainer to review the target agnostic bits of this, that's: loop-doloop.cc df-core.{c,h} I do have a nitpick myself that I missed last time around: /* We expect the condition to be of the form (reg != 0) */ cond = XEXP (SET_SRC (cmp), 0); -

[PATCH] tree-optimization/111917 - bougs IL after guard hoisting

The unswitching code to hoist guards inserts conditions in wrong places. The following fixes this, simplifying code. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/111917 * tree-ssa-loop-unswitch.cc (hoist_guard): Always insert new condi

Re: [PATCH] vect: Don't set excess bits in unform masks

On Fri, 20 Oct 2023, Andrew Stubbs wrote: > This patch fixes a wrong-code bug on amdgcn in which the excess "ones" in the > mask enable extra lanes that were supposed to be unused and are therefore > undefined. > > Richi suggested an alternative approach involving narrower types and then a > zero

Re: [PATCH] ifcvt/vect: Emit COND_ADD for conditional scalar reduction.

On Thu, 19 Oct 2023, Robin Dapp wrote: > Ugh, I didn't push yet because with a rebased trunk I am > seeing different behavior for some riscv testcases. > > A reduction is not recognized because there is yet another > "double use" occurrence in check_reduction_path. I guess it's > reasonable to l

Re: [PATCH][WIP] libiberty: Support for relocation output

> This patch teaches libiberty to output X86-64 Relocations. Hello, for actual patch submission you will need to add changelog :) > diff --git a/libiberty/simple-object-elf.c b/libiberty/simple-object-elf.c > index 86b7a27dc74..0bbaf4b489f 100644 > --- a/libiberty/simple-object-elf.c > +++ b/libibe

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On 2023-10-23 03:57, Richard Biener wrote: On Fri, Oct 20, 2023 at 10:41 PM Qing Zhao wrote: On Oct 20, 2023, at 3:10 PM, Siddhesh Poyarekar wrote: On 2023-10-20 14:38, Qing Zhao wrote: How about the following: Add one more parameter to __builtin_dynamic_object_size(), i.e __builtin_d

Re: [PATCH 10/11] aarch64: Fix branch-protection error message tests

The 10/13/2023 11:29, Richard Earnshaw (lists) wrote: > On 05/09/2023 16:00, Richard Sandiford via Gcc-patches wrote: > > Szabolcs Nagy writes: > >> @@ -4,19 +4,19 @@ void __attribute__ ((target("branch-protection=leaf"))) > >> foo1 () > >> { > >> } > >> -/* { dg-error {invalid protection type

Re: [PATCH] Support vec_cmpmn/vcondmn for v2hf/v4hf.

On Mon, Oct 23, 2023 at 10:48 AM liuhongt wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. > Ready push to trunk. vcond and vcondeq shouldn't be necessary if there's vcond_mask and vcmp support which is the "modern" way of handling vcond. Unless the ISA really can do compare

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On Mon, Oct 23, 2023 at 1:27 PM Siddhesh Poyarekar wrote: > > On 2023-10-23 03:57, Richard Biener wrote: > > On Fri, Oct 20, 2023 at 10:41 PM Qing Zhao wrote: > >> > >> > >> > >>> On Oct 20, 2023, at 3:10 PM, Siddhesh Poyarekar > >>> wrote: > >>> > >>> On 2023-10-20 14:38, Qing Zhao wrote: > >>

[PATCH] libgcc: make heap-based trampolines conditional on libc presence

From: Sergei Trofimovich To build `libc` for a target one needs to build `gcc` without `libc` support first. Commit r14-4823-g8abddb187b3348 "libgcc: support heap-based trampolines" added unconditional `libc` dependency and broke libc-less `gcc` builds. An example failure on `x86_64-unknown-linu

Re: [PATCH][WIP] dwarf2out: extend to output debug section directly to object file during debug_early phase

Hello, thanks for the patch. Overall it looks in right direction except for the code duplication in output_die and friends. > +/* Given a die and id, produce the appropriate abbreviations > + directly to lto object file */ > + > +static void > +output_die_abbrevs_to_object_file(unsigned long abb

Re: [PATCH] libgcc: make heap-based trampolines conditional on libc presence

hi Sergei, > On 23 Oct 2023, at 13:43, Sergei Trofimovich wrote: > > From: Sergei Trofimovich > > To build `libc` for a target one needs to build `gcc` without `libc` > support first. Commit r14-4823-g8abddb187b3348 "libgcc: support > heap-based trampolines" added unconditional `libc` dependen

Re: [PATCH][WIP] libiberty: Support for relocation output

On Mon, 23 Oct 2023 at 16:30, Jan Hubicka wrote: > > This patch teaches libiberty to output X86-64 Relocations. > Hello, > for actual patch submission you will need to add changelog :) > I know, right :). > > diff --git a/libiberty/simple-object-elf.c > b/libiberty/simple-object-elf.c > > index

Re: [PATCH][WIP] dwarf2out: extend to output debug section directly to object file during debug_early phase

On Mon, 23 Oct 2023 at 18:18, Jan Hubicka wrote: > Hello, > thanks for the patch. > > Overall it looks in right direction except for the code duplication in > output_die and friends. > > +/* Given a die and id, produce the appropriate abbreviations > > + directly to lto object file */ > > + > >

[pushed] configure, libquadmath: Remove unintended AC_CHECK_LIBM [PR111928]

This is a partial reversion of r14-4825-g6a6d3817afa02b to remove an unintended change. Tested with x86_64-linux X arm-none-eabi (and x86_64-darwin X arm-non-eabi and native x86_64-darwin bootstrap. Also reported by the OP to fix the issue, pushed to trunk, apologies for the breakage, Iain ---

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On 2023-10-23 08:34, Richard Biener wrote: A related issue is that assignment to the field and storage allocation are not tied together - if there's no use of the size data we might remove the store of it as dead. Maybe the trick then is to treat the size data as volatile? That ought to discou

[SH][committed] Fix PR 111001

The attached patch fixes PR 111001. Committed to master, cherry-picked to GCC-13, GCC-12 and GCC-11. Sanity tested with 'make all-gcc'. Bootstrapped on GCC-13 sh4-linux by Adrian. Cheers, Oleg gcc/ChangeLog: PR target/111001 * config/sh/sh_treg_combine.cc (sh_tre

[PATCH] ipa/111914 - perform parameter init after remapping types

The following addresses a mismatch in SSA name vs. symbol when we emit a dummy assignment when not optimizing. The temporary we create is not remapped by initialize_inlined_parameters because we have no easy way to get at it. The following instead emits the additional statement after we have rema

[PATCH] tree-optimization/111915 - mixing grouped and non-grouped accesses

The change to allow SLP of non-grouped accesses failed to check for the case of mixing with grouped accesses. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/111915 * tree-vect-slp.cc (vect_build_slp_tree_1): Check all accesses are either

Backport PR106878 fixes to GCC 12

Hi, I'd like to submit the attached three patches from Jakub for backporting to GCC 12. These are the backports proposed at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106878#c18 i.e.: r13-2658-g645ef01a463f15fc230e2155719c7a12cec89acf without the gimple verifier changes. r13-2709-g9ac9fde961

[PATCH] tree-optimization/111916 - SRA of BIT_FIELD_REF of constant pool entries

The following adjusts a leftover BIT_FIELD_REF special-casing to only cover the cases general code doesn't handle. Boostrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/111916 * tree-sra.cc (sra_modify_assign): Do not lower all BIT_FIELD_REF read

Re: [PATCH v1 1/1] gcc: config: microblaze: fix cpu version check

Not sure if this will work, but there is a strverscmp function in libiberty that I think will work. So the microblaze version compare could be done as: #define MICROBLAZE_VERSION_COMPARE(VA,VB) strvercmp(VA, VB) (I've not tried this, just remembered doing something similar in the past.) --Mar

Re: [PATCH v9 4/4] ree: Improve ree pass for rs6000 target using defined ABI interfaces

On Mon, 23 Oct 2023 12:16:18 +0530 Ajit Agarwal wrote: > Hello All: > > Addressed below review comments in the version 11 of the patch. > Please review and please let me know if its ok for trunk. s/satisified/satisfied/ > > As said, I don't see why the below was not cleaned up before the V1 >

Re: [PATCH] libcpp: Improve the diagnostic for poisoned identifiers [PR36887]

On Wed, 2023-09-20 at 00:12 -0400, Lewis Hyatt wrote: > Hello- > > This patch implements the PR's request to add more information to the > diagnostic issued for using a poisoned identifier. Bootstrapped + > regtested > all languages on x86-64 Linux. Does it look OK please? Thanks! Thanks! Patch

[x86 PATCH] Fine tune STV register conversion costs for -Os.

The eagle-eyed may have spotted that my recent testcases for DImode shifts on x86_64 included -mno-stv in the dg-options. This is because the Scalar-To-Vector (STV) pass currently transforms these shifts to use SSE vector operations, producing larger code even with -Os. The issue is that the com

Re: [PATCH v1 1/1] gcc: config: microblaze: fix cpu version check

Hi Mark, > Le 23 oct. 2023 à 16:07, Hatle, Mark a écrit : > > Not sure if this will work, but there is a strverscmp function in libiberty > that I think will work. > > So the microblaze version compare could be done as: > > #define MICROBLAZE_VERSION_COMPARE(VA,VB) strvercmp(VA, VB) > > (I'

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> On Oct 23, 2023, at 3:57 AM, Richard Biener > wrote: > > On Fri, Oct 20, 2023 at 10:41 PM Qing Zhao wrote: >> >> >> >>> On Oct 20, 2023, at 3:10 PM, Siddhesh Poyarekar wrote: >>> >>> On 2023-10-20 14:38, Qing Zhao wrote: How about the following: Add one more parameter to __b

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> On Oct 23, 2023, at 8:34 AM, Richard Biener > wrote: > > On Mon, Oct 23, 2023 at 1:27 PM Siddhesh Poyarekar > wrote: >> >> On 2023-10-23 03:57, Richard Biener wrote: >>> On Fri, Oct 20, 2023 at 10:41 PM Qing Zhao wrote: > On Oct 20, 2023, at 3:10 PM, Siddhesh Poyare

Re: [PATCH v5 2/5] libcpp: add a function to determine UTF-8 validity of a C string

On Wed, Jan 25, 2023 at 4:09 PM Ben Boeckel via Gcc wrote: > > This simplifies the interface for other UTF-8 validity detections when a > simple "yes" or "no" answer is sufficient. > > libcpp/ > > * charset.cc: Add `_cpp_valid_utf8_str` which determines whether > a C string is vali

Re: [PATCH][WIP] dwarf2out: extend to output debug section directly to object file during debug_early phase

> > > + output_data_to_object_file (1, 0); > > > + output_data_to_object_file (1, 0); > > > > So this basically renames dw2_asm_output_data to > > output_data_to_object_file and similarly for other output functions. > > > > What would be main problems of making dw2_asm_* functions to do the > > r

Re: [PATCH v5 2/5] libcpp: add a function to determine UTF-8 validity of a C string

On 10/23/23 11:16, David Malcolm wrote: On Wed, Jan 25, 2023 at 4:09 PM Ben Boeckel via Gcc wrote: This simplifies the interface for other UTF-8 validity detections when a simple "yes" or "no" answer is sufficient. libcpp/ * charset.cc: Add `_cpp_valid_utf8_str` which determines whe

Re: [PATCH v5 2/5] libcpp: add a function to determine UTF-8 validity of a C string

On Mon, 2023-10-23 at 11:24 -0400, Jason Merrill wrote: > On 10/23/23 11:16, David Malcolm wrote: > > On Wed, Jan 25, 2023 at 4:09 PM Ben Boeckel via Gcc > > wrote: > > > > > > This simplifies the interface for other UTF-8 validity detections > > > when a > > > simple "yes" or "no" answer is suff

Re: [PATCH] rust: build failure after NON_DEPENDENT_EXPR removal [PR111899]

On 10/23/23 05:10, Thomas Schwinge wrote: Hi Patrick! On 2023-10-20T13:36:30-0400, Patrick Palka wrote: Built on x86_64-pc-linux-gnu, pushed to trunk as obvious (hopefully). -- >8 -- This patch removes stray NON_DEPENDENT_EXPR checks following the removal of this tree code from the C++ FE.

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> Am 23.10.2023 um 16:56 schrieb Qing Zhao : > >  > >> On Oct 23, 2023, at 3:57 AM, Richard Biener >> wrote: >> >>> On Fri, Oct 20, 2023 at 10:41 PM Qing Zhao wrote: >>> >>> >>> On Oct 20, 2023, at 3:10 PM, Siddhesh Poyarekar wrote: On 2023-10-20 14:38, Qing Zhao

[PATCH] internal-fn: Add VCOND_MASK_LEN.

The attached patch introduces a VCOND_MASK_LEN, helps for the riscv cases that were broken before and looks unchanged on x86, aarch64 and power bootstrap and testsuites. I only went with the minimal number of new match.pd patterns and did not try stripping the length of a COND_LEN_OP in order to s

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> On Oct 23, 2023, at 11:57 AM, Richard Biener > wrote: > > > >> Am 23.10.2023 um 16:56 schrieb Qing Zhao : >> >>  >> >>> On Oct 23, 2023, at 3:57 AM, Richard Biener >>> wrote: >>> On Fri, Oct 20, 2023 at 10:41 PM Qing Zhao wrote: > On Oct 20, 2023, at 3:10

Re: [PATCH v1 1/1] gcc: config: microblaze: fix cpu version check

On 10/22/23 22:48, Neal Frager wrote: There is a microblaze cpu version 10.0 included in versal. If the minor version is only a single digit, then the version comparison will fail as version 10.0 will appear as 100 compared to version 6.00 or 8.30 which will calculate to values 600 and 830. The

Re: [PATCH] libgcc: make heap-based trampolines conditional on libc presence

On Mon, 23 Oct 2023 13:54:01 +0100 Iain Sandoe wrote: > hi Sergei, > > > On 23 Oct 2023, at 13:43, Sergei Trofimovich wrote: > > > > From: Sergei Trofimovich > > > > To build `libc` for a target one needs to build `gcc` without `libc` > > support first. Commit r14-4823-g8abddb187b3348 "libgc

Re: [PATCH v23 31/33] libstdc++: Optimize std::is_pointer compilation performance

On Sun, 22 Oct 2023, Ken Matsui wrote: > Hi Patrick, > > There is an issue with the code in > libstdc++-v3/include/bits/cpp_type_traits.h. Specifically, Clang 16 > does not accept the code, while Clang 17 does. Given that we aim to > support the last two versions of Clang, we need to ensure that

Re: [PATCH v24 33/33] libstdc++: Optimize std::is_invocable compilation performance

On Fri, Oct 20, 2023 at 12:22 PM Ken Matsui wrote: > > This patch optimizes the compilation performance of std::is_invocable > by dispatching to the new __is_invocable built-in trait. > > libstdc++-v3/ChangeLog: > > * include/std/type_traits (is_invocable): Use __is_invocable > bui

Re: [PATCH v23 31/33] libstdc++: Optimize std::is_pointer compilation performance

On Mon, Oct 23, 2023 at 10:00 AM Patrick Palka wrote: > On Sun, 22 Oct 2023, Ken Matsui wrote: > > > Hi Patrick, > > > > There is an issue with the code in > > libstdc++-v3/include/bits/cpp_type_traits.h. Specifically, Clang 16 > > does not accept the code, while Clang 17 does. Given that we aim

Re: [PATCH v24 33/33] libstdc++: Optimize std::is_invocable compilation performance

On Mon, Oct 23, 2023 at 10:05 AM Patrick Palka wrote: > On Fri, Oct 20, 2023 at 12:22 PM Ken Matsui wrote: > > > > This patch optimizes the compilation performance of std::is_invocable > > by dispatching to the new __is_invocable built-in trait. > > > > libstdc++-v3/ChangeLog: > > > > *

Re: [PATCH v24 33/33] libstdc++: Optimize std::is_invocable compilation performance

On Mon, 23 Oct 2023, Ken Matsui wrote: > On Mon, Oct 23, 2023 at 10:05 AM Patrick Palka wrote: > On Fri, Oct 20, 2023 at 12:22 PM Ken Matsui wrote: > > > > This patch optimizes the compilation performance of std::is_invocable > > by dispatching to the new __is_invocable b

Re: [PATCH v24 33/33] libstdc++: Optimize std::is_invocable compilation performance

On Mon, Oct 23, 2023 at 10:39 AM Patrick Palka wrote: > > On Mon, 23 Oct 2023, Ken Matsui wrote: > > > On Mon, Oct 23, 2023 at 10:05 AM Patrick Palka wrote: > > On Fri, Oct 20, 2023 at 12:22 PM Ken Matsui > > wrote: > > > > > > This patch optimizes the compilation performance

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

Am Montag, dem 23.10.2023 um 16:37 + schrieb Qing Zhao: > > > On Oct 23, 2023, at 11:57 AM, Richard Biener > > wrote: > > > > > > > > > Am 23.10.2023 um 16:56 schrieb Qing Zhao : > > > > > >  > > > > > > > On Oct 23, 2023, at 3:57 AM, Richard Biener > > > > wrote: > > > > > > > > >

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On Mon, 23 Oct 2023, Qing Zhao wrote: > I prefer to implement this in gimplification phase since I am more > familiar with the code there.. (I think that implementing it in > gimplification should be very similar as implementing it in FE? Or do I > miss anything here?) > > Joseph, if implement

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

> On Oct 20, 2023, at 3:54 PM, Martin Uecker wrote: > > Am Freitag, dem 20.10.2023 um 18:48 + schrieb Qing Zhao: >> >>> On Oct 20, 2023, at 2:34 PM, Kees Cook wrote: >>> >>> On Fri, Oct 20, 2023 at 11:50:11AM +0200, Martin Uecker wrote: Am Donnerstag, dem 19.10.2023 um 16:33 -0700 s

Re: [PATCH V3 00/11] Refactor and cleanup vsetvl pass

Hi Lehua, This patch causes a build failure with newlib 4.1.0 with -march=rv64gv_zbb. I've creduced the failure here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111941 Thanks, Patrick On 10/19/23 20:58, Lehua Ding wrote: Committed, thanks Patrick and Juzhe. On 2023/10/20 2:04, Patrick O'Ne

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

Am Montag, dem 23.10.2023 um 20:06 +0200 schrieb Martin Uecker: > Am Montag, dem 23.10.2023 um 16:37 + schrieb Qing Zhao: > > > > > On Oct 23, 2023, at 11:57 AM, Richard Biener > > > wrote: > > > > > > > > > > > > > Am 23.10.2023 um 16:56 schrieb Qing Zhao : > > > > > > > >  > > > > >

Re: [PATCH v9 4/4] ree: Improve ree pass for rs6000 target using defined ABI interfaces

On 10/22/23 23:46, Ajit Agarwal wrote: Hello All: Addressed below review comments in the version 11 of the patch. Please review and please let me know if its ok for trunk. Thanks & Regards Ajit Again you are not paying attention to prior comments about fixing your submission practice and

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> On Oct 23, 2023, at 2:06 PM, Martin Uecker wrote: > > Am Montag, dem 23.10.2023 um 16:37 + schrieb Qing Zhao: >> >>> On Oct 23, 2023, at 11:57 AM, Richard Biener >>> wrote: >>> >>> >>> Am 23.10.2023 um 16:56 schrieb Qing Zhao :  > On Oct 23, 2023, at 3:57

Re: [PATCH v1 1/1] gcc: config: microblaze: fix cpu version check

> Le 23 oct. 2023 à 18:40, Michael Eager a écrit : > > On 10/22/23 22:48, Neal Frager wrote: >> There is a microblaze cpu version 10.0 included in versal. If the >> minor version is only a single digit, then the version comparison >> will fail as version 10.0 will appear as 100 compared to ve

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On 2023-10-23 14:06, Martin Uecker wrote: We should aim for a good integration with the BDOS pass, so that it can propagate the information further, e.g. the following should work: struct { int L; char buf[] __counted_by(L) } x; x.L = N; x.buf = ...; char *p = &x->f; __bdos(p) -> N So we need t

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

Am Montag, dem 23.10.2023 um 14:43 -0400 schrieb Siddhesh Poyarekar: > On 2023-10-23 14:06, Martin Uecker wrote: > > We should aim for a good integration with the BDOS pass, so > > that it can propagate the information further, e.g. the > > following should work: > > > > struct { int L; char buf[]

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> On Oct 23, 2023, at 2:31 PM, Martin Uecker wrote: > > Am Montag, dem 23.10.2023 um 20:06 +0200 schrieb Martin Uecker: >> Am Montag, dem 23.10.2023 um 16:37 + schrieb Qing Zhao: >>> On Oct 23, 2023, at 11:57 AM, Richard Biener wrote: > Am 23.10.2023 um 16

[PATCH v3] gcc: Introduce -fhardened

On Thu, Oct 19, 2023 at 02:24:11PM +0200, Richard Biener wrote: > On Wed, Oct 11, 2023 at 10:48 PM Marek Polacek wrote: > > > > On Tue, Sep 19, 2023 at 10:58:19AM -0400, Marek Polacek wrote: > > > On Mon, Sep 18, 2023 at 08:57:39AM +0200, Richard Biener wrote: > > > > On Fri, Sep 15, 2023 at 5:09 

Re: [PATCH v1 1/1] gcc: config: microblaze: fix cpu version check

On 10/23/23 11:37, Frager, Neal wrote: Le 23 oct. 2023 à 18:40, Michael Eager a écrit : On 10/22/23 22:48, Neal Frager wrote: There is a microblaze cpu version 10.0 included in versal. If the minor version is only a single digit, then the version comparison will fail as version 10.0 will

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

Am Montag, dem 23.10.2023 um 19:00 + schrieb Qing Zhao: > > > On Oct 23, 2023, at 2:31 PM, Martin Uecker wrote: > > > > Am Montag, dem 23.10.2023 um 20:06 +0200 schrieb Martin Uecker: > > > Am Montag, dem 23.10.2023 um 16:37 + schrieb Qing Zhao: > > > > > > > > > On Oct 23, 2023, at 11:

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> On Oct 23, 2023, at 2:43 PM, Siddhesh Poyarekar wrote: > > On 2023-10-23 14:06, Martin Uecker wrote: >> We should aim for a good integration with the BDOS pass, so >> that it can propagate the information further, e.g. the >> following should work: >> struct { int L; char buf[] __counted_by(L

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

On Fri, Oct 20, 2023 at 09:54:05PM +0200, Martin Uecker wrote: > Am Freitag, dem 20.10.2023 um 18:48 + schrieb Qing Zhao: > > > > > On Oct 20, 2023, at 2:34 PM, Kees Cook wrote: > > > > > > On Fri, Oct 20, 2023 at 11:50:11AM +0200, Martin Uecker wrote: > > > > Am Donnerstag, dem 19.10.2023 u

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

Am Montag, dem 23.10.2023 um 12:52 -0700 schrieb Kees Cook: > On Fri, Oct 20, 2023 at 09:54:05PM +0200, Martin Uecker wrote: > > Am Freitag, dem 20.10.2023 um 18:48 + schrieb Qing Zhao: > > > > > > > On Oct 20, 2023, at 2:34 PM, Kees Cook wrote: > > > > > > > > On Fri, Oct 20, 2023 at 11:50:

RE: [PATCH 12/19]middle-end: implement loop peeling and IV updates for early break.

> -Original Message- > From: Richard Biener > Sent: Friday, July 14, 2023 2:35 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com > Subject: RE: [PATCH 12/19]middle-end: implement loop peeling and IV > updates for early break. > > On Thu, 13 Jul 2023, Tama

Re: [PATCH v23 02/33] c-family, c++: Look up built-in traits via identifier node

On 10/20/23 09:53, Ken Matsui wrote: Since RID_MAX soon reaches 255 and all built-in traits are used approximately once in a C++ translation unit, this patch removes all RID values for built-in These two lines are too long; please wrap at 75 columns so they don't go over 80 when git log adds 4

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> On Oct 23, 2023, at 3:37 PM, Martin Uecker wrote: > > Am Montag, dem 23.10.2023 um 19:00 + schrieb Qing Zhao: >> >>> On Oct 23, 2023, at 2:31 PM, Martin Uecker wrote: >>> >>> Am Montag, dem 23.10.2023 um 20:06 +0200 schrieb Martin Uecker: Am Montag, dem 23.10.2023 um 16:37 + s

  1   2   >