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

Pushed to r14-4939. 在 2023/10/23 下午5:46, Jiahao Xu 写道: 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. * conf

[PATCH] Darwin: Handle the fPIE option specially.

Testing the fhardened patch prompted checking of what the Xcode tools actually emit for -fPIE. This patch makes the GCC port follow the same pattern. Tested on x86_64, i686-darwin, pushed to trunk, thanks, Iain --- 8< --- For Darwin, PIE requires PIC codegen, but otherwise is only a link-time c

RE: Re: [PATCH] RISC-V: Add AVL propagation PASS for RVV auto-vectorization

Just apply v2 version for RV32 with spike riscv-sim for confirmation. This patch only increased 2 popcount run failures as well as 2 dump failures, and the mask_gather_load_run-11.c is PASS within spike. Pan -Original Message- From: juzhe.zh...@rivai.ai Sent: Thursday, October 26, 202

Re: RE: [PATCH] RISC-V: Add AVL propagation PASS for RVV auto-vectorization

Yes. I just checked again. Before this patch: FAIL: gcc.target/riscv/rvv/autovec/unop/popcount-run-1.c execution test FAIL: gcc.target/riscv/rvv/autovec/unop/popcount-run-1.c execution test FAIL: gcc.target/riscv/rvv/autovec/unop/popcount-run-1.c execution test FAIL: gcc.target/riscv/rvv/autovec/u

Re: [PATCH] RISC-V: Add AVL propagation PASS for RVV auto-vectorization

> Increased FAILS are LMUL = M4. I have analyzed the codegen. Looks > reasonable. > > Moreover, When I removed 'popcount_64' and test, all passed no matter > apply this patch or not. > > I think it is because popcount64 is buggy in RV32, this patch trigger > LMUL = 4 bug already existed that we

Re: [PATCH V2] RISC-V: Add AVL propagation PASS for RVV auto-vectorization

LGTM, Thanks, it's really awesome - the implementation is simpler than I expected, it's another great improvement for RISC-V GCC! Just make sure Patrick gives a green light on the testing before committing the patch :) On Wed, Oct 25, 2023 at 8:05 PM Juzhe-Zhong wrote: > > This patch addresse

[Ready to commit V3] RISC-V: Add AVL propagation PASS for RVV auto-vectorization

This patch addresses the redundant AVL/VL toggling in RVV partial auto-vectorization which is a known issue for a long time and I finally find the time to address it. Consider a simple vector addition operation: https://godbolt.org/z/7hfGfEjW3 void foo (int *__restrict a, int *__restrict

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

Am Mittwoch, dem 25.10.2023 um 15:32 -0700 schrieb Kees Cook: > On Wed, Oct 25, 2023 at 10:27:41PM +, Qing Zhao wrote: > > > > > > > On Oct 25, 2023, at 6:06 PM, Kees Cook wrote: > > > > > > On Wed, Oct 25, 2023 at 01:27:29PM +, Qing Zhao wrote: > > > > A. Add an additional argument, t

Re: Re: [PATCH V2] RISC-V: Add AVL propagation PASS for RVV auto-vectorization

Thanks Kito. I have sent V3 with adapting testcases (2 additional dump FAILs detected by both Pan Li and Patrick). No need to review. I will wait for patrick is ok to ignore popcount FAILs for now then commit it. juzhe.zh...@rivai.ai From: Kito Cheng Date: 2023-10-26 15:51 To: Juzhe-Zhong C

Re: [PATCH v2 2/4] libgrust: Add libproc_macro and build system

Hi! First, I've pushed into GCC upstream Git branch devel/rust/libgrust-v2 the "v2" libgrust changes as posted by Arthur, so that people can easily test this before it getting into Git master branch. I'll myself later try this for GCN and nvptx targets -- in their current form where they don't su

Re: [PATCH V2 1/2] Pass type of comparison operands instead of comparison result to truth_type_for in build_vec_cmp.

On Thu, Oct 26, 2023 at 3:15 AM liuhongt wrote: > > >I think it's indeed on purpose that the result of v1 < v2 is a signed > >integer vector type. > >But build_vec_cmp should not use the truth type for the result but instead > >the > >truth type for the comparison, so > > Change build_vec_cmp in

Re: [PATCH V2] RISC-V: Add AVL propagation PASS for RVV auto-vectorization

> I have sent V3 with adapting testcases (2 additional dump FAILs detected by > both Pan Li and Patrick). > No need to review. > > I will wait for patrick is ok to ignore popcount FAILs for now then commit it. Just to confirm: I can now also reproduce the popcount fail on my machine without you

Re: [PATCH v2] VECT: Remove the type size restriction of vectorizer

On Thu, Oct 26, 2023 at 4:18 AM wrote: > > From: Pan Li > > Update in v2: > > * Fix one ICE of type assertion. > * Adjust some test cases for aarch64 sve and riscv vector. > > Original log: > > The vectoriable_call has one restriction of the size of data type. > Aka DF to DI is allowed but SF to

[PATCH] tree-optimization/109334: Improve computation for access attribute

Hi Sid and Jakub, here is the patch discussed in PR 109334. Martin tree-optimization/109334: Improve computation for access attribute The fix for PR104970 restricted size computations to the case where the access attribute was specified explicitly (no VLA). It also rest

Re: Re: [PATCH V2] RISC-V: Add AVL propagation PASS for RVV auto-vectorization

Oh. It's surprising. I think current RVV GCC is not stable and buggy so that different FAILs in different machines. Currently, we have 2 middle-end bugs: 1. COND_LEN_XXX: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760 2. Gather load bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970

Re: [PATCH] internal-fn: Add VCOND_MASK_LEN.

> Yeah. I think Robin may need this : > > TREE_CODE (else_val) == SSA_NAAME > && SSA_NAME_IS_DEFAULT_DEF (else_val) > && VAR_P (SSA_NAME_VAR (else_val)) > > to differentiate whether the ELSE VALUE is uninitialized SSA or not. I think we are talking about a different simplification now. This

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

On Wed, Oct 25, 2023 at 8:16 PM Martin Uecker wrote: > > Am Mittwoch, dem 25.10.2023 um 13:13 +0200 schrieb Richard Biener: > > > > > Am 25.10.2023 um 12:47 schrieb Martin Uecker : > > > > > > Am Mittwoch, dem 25.10.2023 um 06:25 -0400 schrieb Siddhesh Poyarekar: > > > > > On 2023-10-25 04:16, Ma

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

Hi! On Wed, 20 Sept 2023 at 06:12, 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! > > -Lewis > >

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

On Thu, Oct 26, 2023 at 7:22 AM Jakub Jelinek wrote: > > On Wed, Oct 25, 2023 at 07:03:43PM +, Qing Zhao wrote: > > For the code generation impact: > > > > turning the original x.buf > > to a builtin function call > > __builtin_with_access_and_size(x,buf, x.L,-1) > > > > might inhibit some op

RE: [PATCH-1v4, expand] Enable vector mode for compare_by_pieces [PR111449]

> -Original Message- > From: Jiang, Haochen > Sent: Wednesday, October 25, 2023 4:47 PM > To: Richard Sandiford ; HAO CHEN GUI > > Cc: gcc-patches > Subject: RE: [PATCH-1v4, expand] Enable vector mode for compare_by_pieces > [PR111449] > > > -Original Message- > > From: Richard S

Re: [PATCH v2] bpf: Improvements in CO-RE builtins implementation.

Hi David, Please find the new version inline right after the inline reply. >> gcc/ChangeLog: >> * config/bpf/bpf-passes.def (pass_lower_bpf_core): Added pass. > > It may only be due to how the patch is formatted in the attachment > (everything above the first diff seems to be ind

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

Am Donnerstag, dem 26.10.2023 um 10:45 +0200 schrieb Richard Biener: > On Wed, Oct 25, 2023 at 8:16 PM Martin Uecker wrote: > > > > Am Mittwoch, dem 25.10.2023 um 13:13 +0200 schrieb Richard Biener: > > > > > > > Am 25.10.2023 um 12:47 schrieb Martin Uecker : > > > > > > > > Am Mittwoch, dem 2

Re: [x86 PATCH] PR target/110511: Fix reg allocation for widening multiplications.

On Wed, Oct 25, 2023 at 4:41 PM Roger Sayle wrote: > > Hi Uros, > > I've tried your suggestions to see what would happen. > Alas, allowing both operands to (i386's) widening multiplications > to be nonimmediate_operand results in 90 additional testsuite > unexpected failures", and 41 unresolved t

Re: [PATCH] match: Simplify `a != C1 ? abs(a) : C2` when C2 == abs(C1) [PR111957]

On Wed, Oct 25, 2023 at 5:37 AM Andrew Pinski wrote: > > This adds a match pattern for `a != C1 ? abs(a) : C2` which gets simplified > to `abs(a)`. if C1 was originally *_MIN then change it over to use absu > instead > of abs. > > Bootstrapped and tested on x86_64-linux-gnu with no regressions. >

Re: [PATCH] DOC: Update COND_LEN document

Juzhe-Zhong writes: > As Richard's suggested. We need to adapt doc for cond_len operations. > > gcc/ChangeLog: > > * doc/md.texi: Update document. Thanks for addressing my comment. I was thinking about the pseudo code though. Currently it is: for (i = 0; i < ops[4] + ops[5]; i++) op0[i

Re: [PATCH] Improve tree_expr_nonnegative_p by using the ranger [PR111959]

On Wed, Oct 25, 2023 at 5:51 AM Andrew Pinski wrote: > > I noticed we were missing optimizing `a / (1 << b)` when > we know that a is nonnegative but only due to ranger information. > This adds the use of the global ranger to tree_single_nonnegative_warnv_p > for SSA_NAME. > I didn't extend tree_s

Re: [PATCH] [x86_64]: Zhaoxin yongfeng enablement

On Wed, Oct 25, 2023 at 8:43 AM mayshao wrote: > > Hi all: > This patch enables -march/-mtune=yongfeng, costs and tunings are set > according to the characteristics of the processor. We add a new md file to > describe yongfeng processor. > > Bootstrapped /regtested X86_64. > > Ok for

Re: [PATCH 2/5] Support for CodeView debugging format

On Mon, Oct 23, 2023 at 2:57 AM Mark Harmstone wrote: > > This patch and the following add initial support for Microsoft's > CodeView debugging format, as used by MSVC, to mingw targets. A high-level question - it seems there's almost no information in the codeview sections, so is that debug form

Re: [PATCH, OpenACC 2.7, v2] readonly modifier support in front-ends

Hi! On 2023-08-07T21:58:27+0800, Chung-Lin Tang wrote: > here's the updated v2 of the readonly modifier front-end patch. Thanks. +++ b/gcc/c/c-parser.cc @@ -14059,7 +14059,8 @@ c_parser_omp_variable_list (c_parser *parser, static tree c_parser_omp_var_list_parens (

Re: Re: [PATCH] DOC: Update COND_LEN document

Hi, Richard. I tried your pseudo code, but report a warning: ../../../../gcc/gcc/doc/invoke.texi:20243: warning: `.' or `,' must follow @xref, not ) I have tried several changes, still failed to eliminate this warning. juzhe.zh...@rivai.ai From: Richard Sandiford Date: 2023-10-26 17:25 To:

[PATCH V2] DOC: Update COND_LEN document

gcc/ChangeLog: * doc/md.texi: Adapt COND_LEN pseudo code. --- gcc/doc/md.texi | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi index daa318ee3da..fab2513105a 100644 --- a/gcc/doc/md.texi +++ b/gcc/doc/md.texi @@ -73

Re: Re: [PATCH] DOC: Update COND_LEN document

Oh. I made a mistake here. Forget about my last email. https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634376.html Here is the V2 address comments as you suggested. Could you take a look ? Thanks. juzhe.zh...@rivai.ai From: Richard Sandiford Date: 2023-10-26 17:25 To: Juzhe-Zhong C

Re: [PATCH V2] DOC: Update COND_LEN document

Juzhe-Zhong writes: > gcc/ChangeLog: > > * doc/md.texi: Adapt COND_LEN pseudo code. OK. Given your earlier message, I'd justed finished writing & testing the same patch. Richard > --- > gcc/doc/md.texi | 18 -- > 1 file changed, 12 insertions(+), 6 deletions(-) > > diff

Re: Re: [PATCH V2] DOC: Update COND_LEN document

Thanks Richard. Committed. juzhe.zh...@rivai.ai From: Richard Sandiford Date: 2023-10-26 17:56 To: Juzhe-Zhong CC: gcc-patches; rguenther Subject: Re: [PATCH V2] DOC: Update COND_LEN document Juzhe-Zhong writes: > gcc/ChangeLog: > > * doc/md.texi: Adapt COND_LEN pseudo code. OK. Given your

Re: [PATCH v2 3/4] build: Add libgrust as compilation modules

Hi Thomas, On 10/25/23 23:40, Thomas Schwinge wrote: Hi! On 2023-10-25T13:06:48+0200, Arthur Cohen wrote: From: Pierre-Emmanuel Patry Define the libgrust directory as a host compilation module as well as for targets. I don't see a response to Richard's comments:

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

Am Donnerstag, dem 26.10.2023 um 11:20 +0200 schrieb Martin Uecker: > Am Donnerstag, dem 26.10.2023 um 10:45 +0200 schrieb Richard Biener: > > On Wed, Oct 25, 2023 at 8:16 PM Martin Uecker wrote: > > > > > > Am Mittwoch, dem 25.10.2023 um 13:13 +0200 schrieb Richard Biener: > > > > > > > > > Am

Re: [PATCH][_Hashtable] Use RAII to restore Rehash state

On Thu, 26 Oct 2023 at 06:18, François Dumont wrote: > libstdc++: [_Hashtable] Use RAII type to manage rehash functor state > > Replace usage of __try/__catch with a RAII type to restore rehash > functor > state when needed. > I'm reviewing this now, but could I request that you a

Re: [PATCH][_Hashtable] Use RAII to restore Rehash state

On 26/10/23 07:18 +0200, François Dumont wrote:     libstdc++: [_Hashtable] Use RAII type to manage rehash functor state     Replace usage of __try/__catch with a RAII type to restore rehash functor     state when needed. Generally I really like replacing try-catch with RAII but I have some

Re: [PATCH] Fortran: Fix incompatible types between INTEGER(8) and TYPE(c_ptr)

Hi Tobias, Please see the updated patch attached incorporating your input and details below. On 24/10/2023 18:12, you wrote: On 20.10.23 16:02, Paul-Antoine Arras wrote: gcc/fortran/ChangeLog:   * interface.cc (gfc_compare_types): Return true in this situation. That's a bad descriptio

[PATCH] VECT: Support SLP MASK_LEN_GATHER_LOAD with conditional mask

This patch leverage current MASK_GATHER_LOAD to support SLP MASK_LEN_GATHER_LOAD with condtional mask. Unconditional MASK_LEN_GATHER_LOAD (base, offset, scale, zero, -1) SLP is not included in this patch since it seems that we can't support it in the middle-end (due to PR44306). May be we shoul

Re: [PATCH] tree-optimization/109334: Improve computation for access attribute

On 2023-10-26 04:37, Martin Uecker wrote: Hi Sid and Jakub, here is the patch discussed in PR 109334. I can't approve, but here's a review: Martin tree-optimization/109334: Improve computation for access attribute The fix for PR104970 restricted size computations to the

Re: [PATCH v3] bpf: Improvements in CO-RE builtins implementation.

Changes from v2: - Reversed return value for bpf_const_not_ok_for_debug_p function. commit 3a0b09273727a49fab7461d059d504899bb6556d Author: Cupertino Miranda Date: Tue Aug 8 09:22:41 2023 +0100 bpf: Improvements in CO-RE builtins implementation. This patch moved the processing

RE: [PATCH v2] VECT: Remove the type size restriction of vectorizer

Thanks Richard for comments. > Can you explain why this is necessary? In particular what is lhs_rtx > mode vs ops[0].value mode? For testcase gcc.target/aarch64/sve/popcount_1.c, the rtl are list as below. The lhs_rtx is (reg:VNx2SI 98 [ vect__5.36 ]). The ops[0].value is (reg:VNx2DI 104). The

Re: [PATCH] match: Simplify `a != C1 ? abs(a) : C2` when C2 == abs(C1) [PR111957]

On Thu, Oct 26, 2023 at 2:24 AM Richard Biener wrote: > > On Wed, Oct 25, 2023 at 5:37 AM Andrew Pinski wrote: > > > > This adds a match pattern for `a != C1 ? abs(a) : C2` which gets simplified > > to `abs(a)`. if C1 was originally *_MIN then change it over to use absu > > instead > > of abs. >

Re: [PATCH] Fortran: Fix incompatible types between INTEGER(8) and TYPE(c_ptr)

Hi Paul-Antoine, On 26.10.23 13:24, Paul-Antoine Arras wrote: Please see the updated patch attached incorporating your input and details below. ... Is this latest revision ready to commit? LGTM. Thanks, Tobias - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfs

[PATCH] testsuite: Allow general skips/requires in PCH tests

dg-pch.exp handled dg-require-effective-target pch_supported_debug as a special case, by grepping the source code. This patch tries to generalise it to other dg-require-effective-targets, and to dg-skip-if. There also seemed to be some errors in check-flags. It used: lappend $args [list ]

Re: [PATCH] RISC-V: Pass abi to g++ rvv testsuite

On 10/25/23 18:13, Patrick O'Neill wrote: On rv32gcv testcases like g++.target/riscv/rvv/base/bug-22.C fail with: FAIL: g++.target/riscv/rvv/base/bug-22.C (test for excess errors) Excess errors: cc1plus: error: ABI requires '-march=rv32' This patch adds the -mabi argument to g++ rvv tests. g

Re: [PING] libffi: Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR109951]

On 10/25/23 02:30, Thomas Schwinge wrote: Hi! Ping. Grüße Thomas On 2023-09-12T12:58:27+0200, I wrote: Hi! On 2020-04-20T14:18:40+0100, "Maciej W. Rozycki via Gcc-patches" wrote: Fix a problem with the libffi testsuite using a method to determine the compiler to use resulting in th

Re: [PING] libatomic: Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR109951]

On 10/25/23 02:32, Thomas Schwinge wrote: Hi! Ping. Grüße Thomas On 2023-09-12T13:03:28+0200, I wrote: Hi! On 2020-04-04T00:00:44+0100, "Maciej W. Rozycki via Gcc-patches" wrote: Fix a problem with the libatomic testsuite using a method to determine the compiler to use resulting in

Re: [PATCH] match: Simplify `a != C1 ? abs(a) : C2` when C2 == abs(C1) [PR111957]

> Am 26.10.2023 um 14:21 schrieb Andrew Pinski : > > On Thu, Oct 26, 2023 at 2:24 AM Richard Biener > wrote: >> >>> On Wed, Oct 25, 2023 at 5:37 AM Andrew Pinski wrote: >>> >>> This adds a match pattern for `a != C1 ? abs(a) : C2` which gets simplified >>> to `abs(a)`. if C1 was originally

Re: [PATCH v2] VECT: Remove the type size restriction of vectorizer

> Am 26.10.2023 um 13:59 schrieb Li, Pan2 : > > Thanks Richard for comments. > >> Can you explain why this is necessary? In particular what is lhs_rtx >> mode vs ops[0].value mode? > > For testcase gcc.target/aarch64/sve/popcount_1.c, the rtl are list as below. > > The lhs_rtx is (reg:VNx2

[pushed] [RA]: Modify cost calculation for dealing with pseudo equivalences

This is the second attempt to improve RA cost calculation for pseudos with equivalences.  The patch explanation is in the log message. The patch was successfully bootstrapped and tested on x86-64, aarch64, and ppc64le.  The patch was also benchmarked on x86-64 spec2017.  specfp2017 performance

Re: [PATCH] internal-fn: Add VCOND_MASK_LEN.

Ok, next try. Now without dubious pattern and with direct optab but still dedicated expander function. This will cause one riscv regression in cond_widen_reduc-2.c that we can deal with later. It is just a missed optimization where we do not combine something that we used to because of the now-p

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

> Am 26.10.2023 um 12:14 schrieb Martin Uecker : > > Am Donnerstag, dem 26.10.2023 um 11:20 +0200 schrieb Martin Uecker: >>> Am Donnerstag, dem 26.10.2023 um 10:45 +0200 schrieb Richard Biener: >>> On Wed, Oct 25, 2023 at 8:16 PM Martin Uecker wrote: Am Mittwoch, dem 25.10.2023 um

Re: [PATCH GCC13 backport] Avoid compile time hog on vect_peel_nonlinear_iv_init for nonlinear induction vec_step_op_mul when iteration count is too big.

> Am 24.10.2023 um 13:22 schrieb liuhongt : > > This is the backport patch for releases/gcc-13 branch, the original patch > for main trunk > is at [1]. > The only difference between this backport patch and [1] is GCC13 doesn't > support auto_mpz, > So this patch manually use mpz_init/mpz_cle

[PATCH] aarch64: Add basic target_print_operand support for CONST_STRING

Motivated by the need to print system register names in output assembly, this patch adds the required logic to `aarch64_print_operand' to accept rtxs of type CONST_STRING and process these accordingly. Consequently, an rtx such as: (set (reg/i:DI 0 x0) (unspec:DI [(const_string ("s3_3_

Re: Re: [PATCH] internal-fn: Add VCOND_MASK_LEN.

+(define_expand "vcond_mask_len_" + [(match_operand:V_VLS 0 "register_operand") +(match_operand: 3 "nonmemory_operand") +(match_operand:V_VLS 1 "nonmemory_operand") +(match_operand:V_VLS 2 "autovec_else_operand") +(match_operand 4 "autovec_length_operand") +(match_operand 5 "co

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

> On Oct 26, 2023, at 1:21 AM, Jakub Jelinek wrote: > > On Wed, Oct 25, 2023 at 07:03:43PM +, Qing Zhao wrote: >> For the code generation impact: >> >> turning the original x.buf >> to a builtin function call >> __builtin_with_access_and_size(x,buf, x.L,-1) >> >> might inhibit some opti

RE: [PATCH v2] VECT: Remove the type size restriction of vectorizer

> But I think this shows we mid-selected the optab, a convert_move is certainly > not correct unconditionally here (the target might not support that) Make sense, we can wait a while for the confirmation from Richard S. If convert_move is not designed for Vector (looks like mostly up to a point)

Re: [PATCH V2 2/7] aarch64: Add support for aarch64-sys-regs.def

On 10/18/23 22:07, Richard Sandiford wrote: Victor Do Nascimento writes: This patch defines the structure of a new .def file used for representing the aarch64 system registers, what information it should hold and the basic framework in GCC to process this file. Entries in the aarch64-system

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

> On Oct 26, 2023, at 4:56 AM, Richard Biener > wrote: > > On Thu, Oct 26, 2023 at 7:22 AM Jakub Jelinek wrote: >> >> On Wed, Oct 25, 2023 at 07:03:43PM +, Qing Zhao wrote: >>> For the code generation impact: >>> >>> turning the original x.buf >>> to a builtin function call >>> __built

Re: [PATCH V2 5/7] aarch64: Implement system register r/w arm ACLE intrinsic functions

On 10/18/23 21:39, Richard Sandiford wrote: Victor Do Nascimento writes: Implement the aarch64 intrinsics for reading and writing system registers with the following signatures: uint32_t __arm_rsr(const char *special_register); uint64_t __arm_rsr64(const char *special_regist

[PATCH v4] bpf: Improvements in CO-RE builtins implementation.

Changes from v1: - Fixed Davids remarks on initial patch. - Fixed mistake with deleted '*'. Changes from v2: - Reversed return value for bpf_const_not_ok_for_debug_p function. Changes from v3: - Fixed ICE in two bpf-next tests: - if (!wi->is_lhs) - core_mark_as_access_in

[pushed] Darwin: Make metadata symbol lables linker-visible for GNU objc.

Tested on x86_64-darwin, x86_64-linux-gnu, pushed to trunk, thanks Iain --- 8< --- Now we have shifted to using the same relocation mechanism as clang for objective-c typeinfo the static linker needs to have a linker-visible symbol for metadata names (this is only needed for GNU objective C, for

Re: [PATCH V2 7/7] aarch64: Add system register duplication check selftest

On 10/18/23 22:30, Richard Sandiford wrote: Victor Do Nascimento writes: Add a build-time test to check whether system register data, as imported from `aarch64-sys-reg.def' has any duplicate entries. Duplicate entries are defined as any two SYSREG entries in the .def file which share the sa

Re: [PATCH V2 2/7] aarch64: Add support for aarch64-sys-regs.def

Thanks for the updates. Victor Do Nascimento writes: > On 10/18/23 22:07, Richard Sandiford wrote: >> Victor Do Nascimento writes: >>> This patch defines the structure of a new .def file used for >>> representing the aarch64 system registers, what information it should >>> hold and the basic fra

Re: [PATCH V2 5/7] aarch64: Implement system register r/w arm ACLE intrinsic functions

Victor Do Nascimento writes: > On 10/18/23 21:39, Richard Sandiford wrote: >> Victor Do Nascimento writes: >>> Implement the aarch64 intrinsics for reading and writing system >>> registers with the following signatures: >>> >>> uint32_t __arm_rsr(const char *special_register); >>> uint64_

Re: [PATCH] testsuite: Allow general skips/requires in PCH tests

On Oct 26, 2023, at 5:34 AM, Richard Sandiford wrote: > dg-pch.exp handled dg-require-effective-target pch_supported_debug > as a special case, by grepping the source code. This patch tries > to generalise it to other dg-require-effective-targets, and to > dg-skip-if. > > There also seemed to b

Re: [PATCH V2 7/7] aarch64: Add system register duplication check selftest

Victor Do Nascimento writes: > On 10/18/23 22:30, Richard Sandiford wrote: >> Victor Do Nascimento writes: >>> Add a build-time test to check whether system register data, as >>> imported from `aarch64-sys-reg.def' has any duplicate entries. >>> >>> Duplicate entries are defined as any two SYSREG

Re: [PATCH] aarch64: Add basic target_print_operand support for CONST_STRING

Victor Do Nascimento writes: > Motivated by the need to print system register names in output > assembly, this patch adds the required logic to > `aarch64_print_operand' to accept rtxs of type CONST_STRING and > process these accordingly. > > Consequently, an rtx such as: > > (set (reg/i:DI 0 x0

hardcfr: support checking at abnormal edges [PR111943]

Control flow redundancy may choose abnormal edges for early checking, but that breaks because we can't insert checks on such edges. Introduce conditional checking on the dest block of abnormal edges, and leave it for the optimizer to drop the conditional. Also, oops, I noticed the new files wen

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

> Am 26.10.2023 um 16:58 schrieb Qing Zhao : > >  > >> On Oct 26, 2023, at 4:56 AM, Richard Biener >> wrote: >> >>> On Thu, Oct 26, 2023 at 7:22 AM Jakub Jelinek wrote: >>> >>> On Wed, Oct 25, 2023 at 07:03:43PM +, Qing Zhao wrote: For the code generation impact: turn

Re: [PATCH] tree-optimization/109334: Improve computation for access attribute

> Am 26.10.2023 um 13:51 schrieb Siddhesh Poyarekar : > > On 2023-10-26 04:37, Martin Uecker wrote: >> Hi Sid and Jakub, >> here is the patch discussed in PR 109334. > > I can't approve, but here's a review: Ok Thanks for the review, Richard >> Martin >> tree-optimization/109334: Impr

Re: [PATCH v3] gcc: Introduce -fhardened

> Am 24.10.2023 um 21:09 schrieb Marek Polacek : > > On Tue, Oct 24, 2023 at 09:22:25AM +0200, Richard Biener wrote: >>> On Mon, Oct 23, 2023 at 9:26 PM Marek Polacek wrote: >>> >>> On Thu, Oct 19, 2023 at 02:24:11PM +0200, Richard Biener wrote: On Wed, Oct 11, 2023 at 10:48 PM Marek Po

Re: [PATCH V2 5/7] aarch64: Implement system register r/w arm ACLE intrinsic functions

On 10/26/23 16:23, Richard Sandiford wrote: Victor Do Nascimento writes: On 10/18/23 21:39, Richard Sandiford wrote: Victor Do Nascimento writes: Implement the aarch64 intrinsics for reading and writing system registers with the following signatures: uint32_t __arm_rsr(const char

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

On Thu, Oct 26, 2023 at 10:15:10AM +0200, Martin Uecker wrote: > but not this: > > char *p = &x->buf; > x->count = 1; > p[10] = 1; // ! This seems fine to me -- it's how I'd expect it to work: "10" is beyond "1". > (because the pointer is passed around the > store to the counter) > > and also h

Re: [PATCH] Fortran: Fix incompatible types between INTEGER(8) and TYPE(c_ptr)

Hi! On 2023-10-26T13:24:04+0200, Paul-Antoine Arras wrote: > --- /dev/null > +++ b/gcc/testsuite/gfortran.dg/c_ptr_tests_20.f90 > @@ -0,0 +1,57 @@ > +! { dg-do compile } > +! { dg-additional-options "-fopenmp" } > +[...] > --- /dev/null > +++ b/gcc/testsuite/gfortran.dg/c_ptr_tests_21.f90 > @@ -

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

Am Donnerstag, dem 26.10.2023 um 17:48 +0200 schrieb Richard Biener: > > > Am 26.10.2023 um 16:58 schrieb Qing Zhao : > > > >  > > > > > On Oct 26, 2023, at 4:56 AM, Richard Biener > > > wrote: > > > > > > > On Thu, Oct 26, 2023 at 7:22 AM Jakub Jelinek wrote: > > > > > > > > On Wed, Oct 2

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

On Thu, Oct 26, 2023 at 4:49 AM Christophe Lyon wrote: > We have noticed that the new tests fail on aarch64 with: > .../aarch64-unknown-linux-gnu/libc/usr/lib/crt1.o: in function `_start': > .../sysdeps/aarch64/start.S:110:(.text+0x38): undefined reference to `main' > > Looking at the test, I'd sa

[Committed] RISC-V: Pass abi to g++ rvv testsuite

On 10/26/23 06:30, Jeff Law wrote: On 10/25/23 18:13, Patrick O'Neill wrote: On rv32gcv testcases like g++.target/riscv/rvv/base/bug-22.C fail with: FAIL: g++.target/riscv/rvv/base/bug-22.C (test for excess errors) Excess errors: cc1plus: error: ABI requires '-march=rv32' This patch adds th

Re: [PATCH] Fortran: Fix incompatible types between INTEGER(8) and TYPE(c_ptr)

Hi Thomas, On 26/10/2023 18:16, you wrote: Hi! On 2023-10-26T13:24:04+0200, Paul-Antoine Arras wrote: --- /dev/null +++ b/gcc/testsuite/gfortran.dg/c_ptr_tests_20.f90 @@ -0,0 +1,57 @@ +! { dg-do compile } +! { dg-additional-options "-fopenmp" } +[...] --- /dev/null +++ b/gcc/testsuite/gfor

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

> On Oct 26, 2023, at 5:20 AM, Martin Uecker wrote: > > Am Donnerstag, dem 26.10.2023 um 10:45 +0200 schrieb Richard Biener: >> On Wed, Oct 25, 2023 at 8:16 PM Martin Uecker wrote: >>> >>> Am Mittwoch, dem 25.10.2023 um 13:13 +0200 schrieb Richard Biener: > Am 25.10.2023 um 12:47 sc

Re: [PATCH] Improve tree_expr_nonnegative_p by using the ranger [PR111959]

Le 26/10/2023 à 11:29, Richard Biener a écrit : On Wed, Oct 25, 2023 at 5:51 AM Andrew Pinski wrote: diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc index 40767736389..2a2a90230f5 100644 --- a/gcc/fold-const.cc +++ b/gcc/fold-const.cc @@ -15047,15 +15047,33 @@ tree_single_nonnegative_warnv_p

Re: [PATCH v4] bpf: Improvements in CO-RE builtins implementation.

On 10/26/23 08:08, Cupertino Miranda wrote: > > Changes from v1: > - Fixed Davids remarks on initial patch. > - Fixed mistake with deleted '*'. > > Changes from v2: > - Reversed return value for bpf_const_not_ok_for_debug_p function. Hmm.. > +static bool > +bpf_const_not_ok_for_debug_p (r

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

Am Donnerstag, dem 26.10.2023 um 09:13 -0700 schrieb Kees Cook: > On Thu, Oct 26, 2023 at 10:15:10AM +0200, Martin Uecker wrote: > > but not this: > > x->count = 11; > > char *p = &x->buf; > > x->count = 1; > > p[10] = 1; // ! > > This seems fine to me -- it's how I'd expect it to work: "10" is

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

On Thu, 26 Oct 2023 at 18:18, Lewis Hyatt wrote: > > On Thu, Oct 26, 2023 at 4:49 AM Christophe Lyon > wrote: > > We have noticed that the new tests fail on aarch64 with: > > .../aarch64-unknown-linux-gnu/libc/usr/lib/crt1.o: in function `_start': > > .../sysdeps/aarch64/start.S:110:(.text+0x38):

Re: [PATCH] Fortran: Fix incompatible types between INTEGER(8) and TYPE(c_ptr)

Hi PA! On 2023-10-26T18:28:07+0200, Paul-Antoine Arras wrote: > On 26/10/2023 18:16, you wrote: >> On 2023-10-26T13:24:04+0200, Paul-Antoine Arras >> wrote: >>> --- /dev/null >>> +++ b/gcc/testsuite/gfortran.dg/c_ptr_tests_20.f90 >>> @@ -0,0 +1,57 @@ >>> +! { dg-do compile } >>> +! { dg-additio

[COMMITTED] [range-ops] Remove unneeded parameters from rv_fold.

Now that the floating point version of rv_fold calculates its result in an frange, we can remove the superfluous LB, UB, and MAYBE_NAN arguments. gcc/ChangeLog: * range-op-float.cc (range_operator::fold_range): Remove superfluous code. (range_operator::rv_fold): Remove unn

[COMMITTED] [range-ops] Add frange& argument to rv_fold.

The floating point version of rv_fold returns its result in 3 pieces: the lower bound, the upper bound, and a maybe_nan bit. It is cleaner to return everything in an frange, thus bringing the floating point version of rv_fold in line with the integer version. This first patch adds an frange argum

[PATCH] [range-op] Remove unused variable in fold_range.

Missed this... gcc/ChangeLog: * range-op-float.cc (range_operator::fold_range): Delete unused variable. --- gcc/range-op-float.cc | 1 - 1 file changed, 1 deletion(-) diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc index ffa3dec133e..75816942f8c 100644 --- a/gcc/range

Re: [PATCH] Fortran: Fix incompatible types between INTEGER(8) and TYPE(c_ptr)

Missed that, sorry. Please move the test to gfortran.dg/gomp/ — those tests are automatically compiled with -fopenmp, hence, no need for dg-(additional-)options. Not applicable here, but tests that use omp.h or "use omp_lib" or the runtime have to be under libgomp/testsuite - or, for compile ch

[PING][PATCH] Include safe-ctype.h after C++ standard headers, to avoid over-poisoning

Ping. It would be nice to get this QoL fix in. -Dimitry > On 28 Sep 2023, at 18:37, Dimitry Andric wrote: > > Ref: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 > > When building gcc's C++ sources against recent libc++, the poisoning of > the ctype macros due to including safe-ctype.h be

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

Am Donnerstag, dem 26.10.2023 um 16:41 + schrieb Qing Zhao: > > > On Oct 26, 2023, at 5:20 AM, Martin Uecker wrote: > > > > Am Donnerstag, dem 26.10.2023 um 10:45 +0200 schrieb Richard Biener: > > > On Wed, Oct 25, 2023 at 8:16 PM Martin Uecker wrote: > > > > > > > > Am Mittwoch, dem 25.10

[PATCH htdocs] bugs: Mention -D_GLIBCXX_ASSERTIONS and -D_GLIBCXX_DEBUG

These options both enabled more checking within the C++ standard library and can expose errors in submitted code. -D_GLIBCXX_DEBUG is mentioned separately because while we want people to try it, it's not always feasible because it requires the whole program and any used libraries to also be built

[Patch, fortran] PR104625 ICE in fixup_array_ref, at fortran/resolve.cc:9275 since r10-2912-g70570ec192745095

Hi All, The attached patch fixes the original problem, in which parentheses around the selector in select type constructs caused ICES. Stacked parentheses caused problems in trans-stmt.cc. Rather than tracking this down, the redundant parentheses were removed on resolution of the selector expressi

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

> Am 26.10.2023 um 19:05 schrieb Martin Uecker : > > Am Donnerstag, dem 26.10.2023 um 16:41 + schrieb Qing Zhao: >> On Oct 26, 2023, at 5:20 AM, Martin Uecker wrote: >>> >>> Am Donnerstag, dem 26.10.2023 um 10:45 +0200 schrieb Richard Biener: On Wed, Oct 25, 2023 at 8:16 PM Ma

Ping^2: [PATCH v2 0/2] Replace intl/ with out-of-tree GNU gettext

Ping^2 It'd be nice to get this patch into 14 (given the intended C strictness changes, especially). Have a lovely evening. -- Arsen Arsenović signature.asc Description: PGP signature

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

On Thu, Oct 26, 2023 at 12:48 PM Christophe Lyon wrote: > > On Thu, 26 Oct 2023 at 18:18, Lewis Hyatt wrote: > > > > On Thu, Oct 26, 2023 at 4:49 AM Christophe Lyon > > wrote: > > > We have noticed that the new tests fail on aarch64 with: > > > .../aarch64-unknown-linux-gnu/libc/usr/lib/crt1.o:

Re: [PATCH v2] VECT: Remove the type size restriction of vectorizer

Richard Biener writes: >> Am 26.10.2023 um 13:59 schrieb Li, Pan2 : >> >> Thanks Richard for comments. >> >>> Can you explain why this is necessary? In particular what is lhs_rtx >>> mode vs ops[0].value mode? >> >> For testcase gcc.target/aarch64/sve/popcount_1.c, the rtl are list as below.

[PATCH] c++: simplify build_new_1 when in a template context

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Since when in a template context we end up just discarding the result of build_new_1, we don't have to bother with much of the code generation it performs. This patch makes the function exit early, returning

  1   2   >