[PATCH] testsuite work-around compound-assignment-1.c C++ failures on various targets [PR111377]

On Mon, Sep 11, 2023 at 11:11:30PM +0200, Jakub Jelinek via Gcc-patches wrote: > On Mon, Sep 11, 2023 at 07:27:57PM +0200, Benjamin Priour via Gcc-patches > wrote: > > Thanks for the report, > > > > After investigation it seems the location of the new dejagnu directive for > > C++ differs dependi

Re: [Patch] OpenMP (C only): omp allocate - extend parsing support, improve diagnostic

Hi Jakub, thanks for the further suggestions; updated patch attached. On 11.09.23 15:34, Jakub Jelinek wrote: On Mon, Sep 11, 2023 at 03:21:54PM +0200, Tobias Burnus wrote: + if (TREE_STATIC (var)) +{ + if (allocator == NULL_TREE && allocator_loc == UNKNOWN_LOCATION) +err

Re: [Linaro-TCWG-CI] gcc patch #75674: FAIL: 68 regressions

Hi Everyone, Normally, notifications from Linaro TCWG precommit CI are sent only to patch author and patch submitter. In this case the sender was rewritten to "Benjamin Priour via Gcc-patches ", which was detected by Patchwork [1] as patch submitter. Hi Mark, Is "From:" re-write on gcc-patch

Re: [Patch] OpenMP (C only): omp allocate - extend parsing support, improve diagnostic

On Tue, Sep 12, 2023 at 09:04:16AM +0200, Tobias Burnus wrote: > Done now. What's not caught is, e.g., a value change by calling a > function which modifies its parameter: > > omp_allocator_t a = ...; int v; foo(a); #pragma omp allocate(v) allocator(a) > > as the current check is only whether 'a'

[PING ^0] [PATCH] rs6000: unnecessary clear after vctzlsbb in vec_first_match_or_eos_index

Ping! Forwarded Message Subject: [PATCH] rs6000: unnecessary clear after vctzlsbb in vec_first_match_or_eos_index Date: Thu, 31 Aug 2023 16:14:46 +0530 From: Ajit Agarwal via Gcc-patches Reply-To: Ajit Agarwal To: gcc-patches CC: Peter Bergner , Segher Boessenkool This

[PING ^0][PATCH 3/4] Improve functionality of ree pass.

Ping! Forwarded Message Subject: [PATCH 3/4] Improve functionality of ree pass. Date: Mon, 4 Sep 2023 13:27:42 +0530 From: Ajit Agarwal via Gcc-patches Reply-To: Ajit Agarwal To: Jeff Law , gcc-patches CC: Peter Bergner , Segher Boessenkool Hello Jeff: This patch elimin

[PATCH v2] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV intrinsic

From: Pan Li Update in v2: * Add get_non_overloaded_instance for function instance. * Fix overload check for policy function. * Enrich the test cases check. Original log: This patch would like add the framework to support the RVV overloaded intrinsic API in riscv-xxx-xxx-gcc, like riscv-xxx-xx

[PING^5] PATCH v5 4/4] ree: Improve ree pass for rs6000 target using defined ABI interfaces.

Ping! Forwarded Message Subject: [PING^4] PATCH v5 4/4] ree: Improve ree pass for rs6000 target using defined ABI interfaces. Date: Mon, 21 Aug 2023 12:16:44 +0530 From: Ajit Agarwal To: gcc-patches CC: Jeff Law , Richard Biener , Segher Boessenkool , Peter Bergner , rashm

[PATCH 0/2] Optimize is_member_object_pointer trait performance

This patch series optimizes is_member_object_pointer trait performance. The first patch implements __is_member_object_pointer built-in trait. The second patch optimizes is_member_object_pointer trait performance by using __is_member_object_pointer built-in trait if available. The performance impro

[PATCH 1/2] c++: Implement __is_member_object_pointer built-in trait

This patch implements built-in trait for std::is_member_object_pointer. gcc/cp/ChangeLog: * cp-trait.def (IS_MEMBER_OBJECT_POINTER): Define __is_member_object_pointer. * constraint.cc (diagnose_trait_expr): Handle CPTK_IS_MEMBER_OBJECT_POINTER. * semantics.

[PATCH 2/2] libstdc++: Optimize is_member_object_pointer trait performance

This patch optimizes the performance of the is_member_object_pointer trait by dispatching to the new __is_member_object_pointer built-in trait. libstdc++-v3/ChangeLog: * include/std/type_traits (is_member_object_pointer): Use __is_member_object_pointer built-in trait. (is_

[PING^3] [PATCH v8] tree-ssa-sink: Improve code sinking pass.

Ping! Forwarded Message Subject: [PING^2] [PATCH v8] tree-ssa-sink: Improve code sinking pass. Date: Mon, 21 Aug 2023 12:14:03 +0530 From: Ajit Agarwal To: gcc-patches CC: Richard Biener , Jeff Law , Segher Boessenkool , Peter Bergner , rashmi.srid...@ibm.com Ping! -

Re: [PATCH v2] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV intrinsic

I think it's better to move 'get_non_overloaded_instance' into function_base. + /* To avoid API conflicting, we use void return type and void argument + for the overloaded function register, like aarch64-sve. */ Plz rewrite the comments, don't mention aarch64 sve. Could you run your rvv in

RE: [PATCH v2] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV intrinsic

>I think it's better to move 'get_non_overloaded_instance' into function_base. Sure. > Plz rewrite the comments, don't mention aarch64 sve. Sure >Could you run your rvv intrinsic api ci with this patch? >I am worrying that the resolve stuff will destroy the existing APi support. This patch only e

Re: [PATCH 2/2] libstdc++: Add dg-require-thread-fence in several tests

On Mon, 11 Sept 2023 at 18:11, Jonathan Wakely wrote: > On Mon, 11 Sept 2023 at 16:40, Christophe Lyon > wrote: > > > > > > > > On Mon, 11 Sept 2023 at 17:22, Jonathan Wakely > wrote: > >> > >> On Mon, 11 Sept 2023 at 14:57, Christophe Lyon > >> wrote: > >> > > >> > > >> > > >> > On Mon, 11 Se

Re: [PATCH V4] RISC-V: Support Dynamic LMUL Cost model

Hi Juzhe, > +max_number_of_live_regs (const basic_block bb, > + const hash_map &live_ranges, > + unsigned int max_point, machine_mode biggest_mode, > + int lmul) > +{ > + unsigned int max_nregs = 0; > + unsigned int i; > + unsigned

Re: [PATCH] Improve rewrite_to_defined_overflow for lhs already the correct type

On Sun, Sep 3, 2023 at 6:19 PM Andrew Pinski via Gcc-patches wrote: > > This improves rewrite_to_defined_overflow slightly if we already > have an unsigned type. The only place where this seems to show up > is ifcombine. It removes one extra statement which gets added and > then later on removed.

testsuite: Port 'check-function-bodies' to nvptx

Hi! On 2023-09-05T15:28:20+0100, Richard Sandiford via Gcc-patches wrote: > Thomas Schwinge writes: >> On 2023-09-04T23:05:05+0200, I wrote: >>> On 2019-07-16T15:04:49+0100, Richard Sandiford >>> wrote: This patch therefore adds a new check-function-bodies dg-final test >> The regex

[PATCH v3] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV intrinsic

From: Pan Li Update in v3: * Rewrite comment for overloaded function add. * Move get_non_overloaded_instance to function_base. Update in v2: * Add get_non_overloaded_instance for function instance. * Fix overload check for policy function. * Enrich the test cases check. Original log: This pa

Re: [Patch] OpenMP (C only): omp allocate - extend parsing support, improve diagnostic

Seems as if I missed a 'git add -u' yesterday evening + missed this when rechecking this morning. Now included as separate patch :-/ Unless there are comments, I intent to commit it very soon. Namely, the actual c-parse.cc update was missing and only the updated tests were included. In particula

Re: [PATCH v3] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV intrinsic

It looks reasonable to me now. But let's wait for kito's more comments. juzhe.zh...@rivai.ai From: pan2.li Date: 2023-09-12 16:46 To: gcc-patches CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng Subject: [PATCH v3] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV intrinsic From: Pan Li

[PATCH] RISC-V: Add missed cond autovec testcases

This patch adds all missed cond autovec testcases. For not support cond patterns, the following patches will be sent to fix it. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/cond/cond_arith-1.c: Add vrem op. * gcc.target/riscv/rvv/autovec/cond/cond_arith-2.c: Ditto.

Re: [PATCH] ssa_name_has_boolean_range vs signed-boolean:31 types

On Sat, Sep 2, 2023 at 4:33 AM Andrew Pinski via Gcc-patches wrote: > > This turns out to be a latent bug in ssa_name_has_boolean_range > where it would return true for all boolean types but all of the > uses of ssa_name_has_boolean_range was expecting 0/1 as the range > rather than [-1,0]. > So w

nvptx 'TARGET_USE_LOCAL_THUNK_ALIAS_P', 'TARGET_SUPPORTS_ALIASES' (was: [committed][nvptx] Use .alias directive for mptx >= 6.3)

Hi! On 2022-12-02T12:24:58+0100, I wrote: > On 2022-03-22T14:41:46+0100, Tom de Vries via Gcc-patches > wrote: >> Starting with ptx isa version 6.3, a ptx directive .alias is available. >> Use this directive to support symbol aliases, as far as possible. >> >> The alias support is off by default

Re: [PATCH] RISC-V: Add missed cond autovec testcases

LGTM. juzhe.zh...@rivai.ai From: Lehua Ding Date: 2023-09-12 16:57 To: gcc-patches CC: juzhe.zhong; kito.cheng; rdapp.gcc; palmer; jeffreyalaw; lehua.ding Subject: [PATCH] RISC-V: Add missed cond autovec testcases This patch adds all missed cond autovec testcases. For not support cond patterns

Re: [PATCH] RISC-V: Add missed cond autovec testcases

LGTM On Tue, Sep 12, 2023 at 4:58 PM Lehua Ding wrote: > > This patch adds all missed cond autovec testcases. For not support > cond patterns, the following patches will be sent to fix it. > > gcc/testsuite/ChangeLog: > > * gcc.target/riscv/rvv/autovec/cond/cond_arith-1.c: Add vrem op. >

Re: [PATCH] RISC-V: Add missed cond autovec testcases

Committed, thanks Kito and Juzhe. On 2023/9/12 17:02, Kito Cheng via Gcc-patches wrote: LGTM On Tue, Sep 12, 2023 at 4:58 PM Lehua Ding wrote: This patch adds all missed cond autovec testcases. For not support cond patterns, the following patches will be sent to fix it. gcc/testsuite/Change

Re: [PATCH 2/2] libstdc++: Add dg-require-thread-fence in several tests

On Tue, 12 Sept 2023 at 08:59, Christophe Lyon wrote: > > > > On Mon, 11 Sept 2023 at 18:11, Jonathan Wakely wrote: >> >> On Mon, 11 Sept 2023 at 16:40, Christophe Lyon >> wrote: >> > >> > >> > >> > On Mon, 11 Sept 2023 at 17:22, Jonathan Wakely wrote: >> >> >> >> On Mon, 11 Sept 2023 at 14:57,

Re: Re: [PATCH V4] RISC-V: Support Dynamic LMUL Cost model

Thanks Robin. I have tried your codes. It works fine and tests passes. Does your code O(nlogn) complexity ? juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-09-12 16:19 To: Juzhe-Zhong; gcc-patches CC: rdapp.gcc; kito.cheng; kito.cheng; jeffreyalaw Subject: Re: [PATCH V4] RISC-V: Support Dyn

Re: [PATCH V4] RISC-V: Support Dynamic LMUL Cost model

I did some benchmarks and, at least for calculix the differences are miniscule. I'd say we can stick with the current approach and improve as needed. However, I noticed ICEs here: + gcc_assert (biggest_size >= mode_size); and here: + mode = TYPE_MODE (TREE_TYPE (lhs)); when compiling calcul

[PATCH v6] RISC-V:Optimize the MASK opt generation

New patch add some comments and update docs for this new usage. --- Accoring to Kito's advice, using "MASK(name) Var(other_flag_name)" to generate MASK and TARGET MACRO automatically. This patch improve the MACRO generation of MASK_* and TARGET_*. Due to the more and more riscv extensions are added

Re: Re: [PATCH V4] RISC-V: Support Dynamic LMUL Cost model

Is calculix big ? Could you give me the testcase to reproduce it? For + gcc_assert (biggest_size >= mode_size); I currently don't have an idea to fix it. But for + mode = TYPE_MODE (TREE_TYPE (lhs)); I think I can fix it. if (!gimple_store_p (stmt)) { tree l

Re: [PATCH V4] RISC-V: Support Dynamic LMUL Cost model

> Is calculix big ? It's 7 nested for loops IIRC and, when unrolling, can get pretty nasty. I tested with -Ofast -funroll-loops. I think wrf is even larger, maybe I can run a full comparison test tonight to have good coverage. > Could you give me the testcase to reproduce it? OK, I will try to

Re: [PATCH-1v2, rs6000] Enable SImode in FP registers on P7 [PR88558]

Hi Haochen, on 2023/9/4 13:33, HAO CHEN GUI wrote: > Hi, > This patch enables SImode in FP registers on P7. Instruction "fctiw" > stores its integer output in an FP register. So SImode in FP register > needs be enabled on P7 if we want support "fctiw" on P7. > > The test case is in the second

Re: [PATCH-2v2, rs6000] Implement 32bit inline lrint [PR88558]

Hi Haochen, on 2023/9/4 13:33, HAO CHEN GUI wrote: > Hi, > This patch implements 32bit inline lrint by "fctiw". It depends on > the patch1 to do SImode move from FP registers on P7. > > Compared to last version, the main change is to add tests for "lrintf" > and adjust the count of correspond

Pass 'SYSROOT_CFLAGS_FOR_TARGET' down to target libraries [PR109951] (was: Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR109951])

Hi! On 2023-06-02T11:52:04+0200, I wrote: > On 2020-01-14T21:31:13+0800, Chung-Lin Tang wrote: >> I understand your situation with --with-build-sysroot/--without-sysroot, >> [...] >> >> Can you test if the attached patch works for you? The patch exports the >> build sysroot >> setting from the

libgomp: Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR91884, PR109951] (was: Consider '--with-build-sysroot=[...]' for target lib

Hi! On 2023-06-03T21:32:57+0100, "Maciej W. Rozycki" wrote: >> Will you, Maciej, please test that this doesn't break your setting? > > Umm, this was implemented for my Western Digital development environment, > which I don't have access to anymore. I'll see what I can do, but it may > be neithe

Re: Re: [PATCH V4] RISC-V: Support Dynamic LMUL Cost model

This is first version of dynamic LMUL. I didn't test it with full GCC testsuite. My plan is to first pass all GCC testsuite (including vect.exp) with default LMUL = M1. Then enable dynamic LMUL to test it. Maybe we could tolerate this ICE issue for now. Then we can test it with full GCC testsui

Re: [PATCH] rs6000: unnecessary clear after vctzlsbb in vec_first_match_or_eos_index

Hi Ajit, on 2023/8/31 18:44, Ajit Agarwal via Gcc-patches wrote: > > This patch removes zero extension from vctzlsbb as it already zero extends. > Bootstrapped and regtested on powerpc64-linux-gnu. > > Thanks & Regards > Ajit > > rs6000: unnecessary clear after vctzlsbb in vec_first_match_or_eo

Re: [PATCH] ggc, jit: forcibly clear GTY roots in jit

On Wed, Sep 6, 2023 at 3:41 PM David Malcolm via Gcc-patches wrote: > > As part of Antoyo's work on supporting LTO in rustc_codegen_gcc, he > noticed an ICE inside libgccjit when compiling certain rust files. > > Debugging libgccjit showed that outdated information from a previous > in-memory comp

Re: Re: [PATCH V4] RISC-V: Support Dynamic LMUL Cost model

Then you don't need to waste time on reduce the case from SPEC. juzhe.zh...@rivai.ai From: juzhe.zh...@rivai.ai Date: 2023-09-12 17:36 To: Robin Dapp; gcc-patches CC: Robin Dapp; kito.cheng; Kito.cheng; jeffreyalaw Subject: Re: Re: [PATCH V4] RISC-V: Support Dynamic LMUL Cost model This is fir

Re: [PATCH v2 2/2] riscv: Add support for str(n)cmp inline expansion

Applied to master. Thanks! Philipp. On Tue, 12 Sept 2023 at 05:34, Jeff Law wrote: > > > > On 9/6/23 10:07, Christoph Muellner wrote: > > From: Christoph Müllner > > > > This patch implements expansions for the cmpstrsi and cmpstrnsi > > builtins for RV32/RV64 for xlen-aligned strings if Zbb or

Re: [PATCH v2 1/2] riscv: Add support for strlen inline expansion

Applied to master. Thanks! Philipp. On Wed, 6 Sept 2023 at 18:07, Christoph Muellner wrote: > > From: Christoph Müllner > > This patch implements the expansion of the strlen builtin for RV32/RV64 > for xlen-aligned aligned strings if Zbb or XTheadBb instructions are > available. > The inserted

Re: [PATCH] ssa_name_has_boolean_range vs signed-boolean:31 types

> Does Ada have signed booleans that are BOOLEAN_TYPE but do _not_ > have [-1, 0] as range? I think documenting [0, 1] for (single-bit > precision?) unsigned BOOLEAN_TYPE and [-1, 1] for signed BOOLEAN_TYPE would > be conservative. All BOOLEAN_TYPEs are unsigned in Ada but may have precision > 1,

Re: [PATCH] Checking undefined_p before using the vr

On Thu, 7 Sep 2023, Jiufu Guo wrote: > Hi, > > As discussed in PR111303: > > For pattern "(X + C) / N": "div (plus@3 @0 INTEGER_CST@1) INTEGER_CST@2)", > Even if "X" has value-range and "X + C" does not overflow, "@3" may still > be undefined. Like below example: > > _3 = _2 + -5; > if (0 != 0)

Re: [PATCH] Tweak language choice in config-list.mk

On Thu, Sep 7, 2023 at 11:30 AM Richard Sandiford via Gcc-patches wrote: > > When I tried to use config-list.mk, the build for every triple except > the build machine's failed for m2. This is because, unlike other > languages, m2 builds target objects during all-gcc. The build will > therefore f

Re: [MAINTAINERS/KERNEL SUMMIT] Trust and maintenance of file systems

On Thu, Sep 7, 2023 at 2:32 PM Segher Boessenkool wrote: > > On Thu, Sep 07, 2023 at 02:23:00PM +0300, Dan Carpenter wrote: > > On Thu, Sep 07, 2023 at 06:04:09AM -0500, Segher Boessenkool wrote: > > > On Thu, Sep 07, 2023 at 12:48:25PM +0300, Dan Carpenter via Gcc-patches > > > wrote: > > > > I

Re: [PATCH] math-opts: Add dbgcounter for FMA formation

On Thu, Sep 7, 2023 at 6:47 PM Martin Jambor wrote: > > Hello, > > This patch is a simple addition of a debug counter to FMA formation in > tree-ssa-math-opts.cc. Given that issues with FMAs do occasionally > pop up, it seems genuinely useful. > > I simply added an if right after the initial chec

[PATCH v2 0/11] Native complex operations

I have updated the series of patches. Most changes consist of bug fixes. However 2 new patches add features: PATCH 9/11: Remove useless special cases This patch remove two special cases for complex which are now fairly enough handled by the general case. Don't hesitate to tell me if you

[PATCH v2 01/11] Native complex ops : Conditional lowering

Summary: Allow the cplxlower pass to identify if an operation does not need to be lowered through optabs. In this case, lowering is not performed. The cplxlower pass now has to handle a mix of lowered and non-lowered operations. A quick access to both parts of a complex constant is also implemented

[PATCH v2 03/11] Native complex ops: Add gen_rtx_complex hook

Summary: Add a new target hook for complex element creation during the expand pass, called gen_rtx_complex. The default implementation calls gen_rtx_CONCAT like before. Then calls to gen_rtx_CONCAT for complex handling are replaced by calls to targetm.gen_rtx_complex. gcc/ChangeLog: * tar

[PATCH v2 02/11] Native complex ops: Move functions to hooks

Summary: Move read_complex_part and write_complex_part to target hooks. Their signature also change because of the type of argument part is now complex_part_t. Calls to theses functions are updated accordingly. gcc/ChangeLog: * target.def: Define hooks for read_complex_part and wr

[PATCH v2 08/11] Native complex ops: Add explicit vector of complex

Summary: Allow the creation and usage of builtins vectors of complex in C, using __attribute__ ((vector_size ())) gcc/c-family/ChangeLog: * c-attribs.cc (vector_mode_valid_p): Add cases for vectors of complex (handle_mode_attribute): Likewise (type_valid_for_vector

[PATCH v2 06/11] Native complex ops: Update how complex rotations are handled

Summary: Catch complex rotation by 90° and 270° in fold-const.cc like before, but now convert them into the new COMPLEX_ROT90 and COMPLEX_ROT270 internal functions. Also add crot90 and crot270 optabs to expose these operation the backends. So conditionnaly lower COMPLEX_ROT90/COMPLEX_ROT270 by chec

[PATCH v2 10/11] Native complex ops: Add a fast complex multiplication pattern

Summary: Add a new fast_mult_optab to define a pattern corresponding to the fast path of a IEEE compliant multiplication. Indeed, the backend programmer can change the fast path without having to handle manually the IEEE checks. gcc/ChangeLog: * internal-fn.def: Add a FAST_MULT internal f

[PATCH v2 04/11] Native complex ops: Allow native complex regs and ops in rtl

Summary: Support registers of complex types in rtl. Also adapt the functions called during the expand pass to support native complex operations. gcc/ChangeLog: * explow.cc (trunc_int_for_mode): Allow complex int modes * expr.cc (emit_move_complex_parts): Move both parts at the

[PATCH v2 09/11] Native complex ops: remove useless special cases

Summary: Remove two special cases which are now useless with the new complex handling. gcc/ChangeLog: * tree-ssa-forwprop.cc (pass_forwprop::execute): Remove two special cases --- gcc/tree-ssa-forwprop.cc | 133 +-- 1 file changed, 3 insertions(+), 1

[PATCH v2 11/11] Native complex ops: Experimental support in x86 backend

Summary: Add an experimental support for native complex operation handling in the x86 backend. For now it only support add, sub, mul, conj, neg, mov in SCmode (complex float). Performance gains are still marginal on this target because there are no particular instructions to speedup complex operati

[PATCH v2 05/11] Native complex ops: Add the conjugate op in optabs

Summary: Add an optab and rtl operation for the conjugate, called conj, to expand CONJ_EXPR. gcc/ChangeLog: * rtl.def: Add a conj operation in rtl * optabs.def: Add a conj optab * optabs-tree.cc (optab_for_tree_code): use the conj_optab to convert a CONJ_EXPR

[PATCH v2 07/11] Native complex ops: Vectorization of native complex operations

Summary: Add vectors of complex types to vectorize native operations. Because of the vectorize was designed to work with scalar elements, several functions and target hooks have to be adapted or duplicated to support complex types. After that, the vectorization of native complex operations follows

Re: [PATCH] match: Don't sink comparisons into vec_cond operands.

On Fri, Sep 8, 2023 at 7:55 PM Robin Dapp via Gcc-patches wrote: > > Hi, > > on riscv gcc.dg/pr70252.c ICEs at gimple-isel.cc:283. This is because > we created the gimple statement > > mask__7.36_170 = VEC_COND_EXPR }>; > > during vrp2. > > What happens is that, starting with > maskdest = (v

Re: [PATCH v5] Implement new RTL optimizations pass: fold-mem-offsets.

On Tue, Sep 12, 2023 at 3:47 AM Jeff Law wrote: > > > > On 9/9/23 02:46, Manolis Tsamis wrote: > > This is a new RTL pass that tries to optimize memory offset calculations > > by moving them from add immediate instructions to the memory loads/stores. > > For example it can transform this: > > > >

Re: [PATCH] sccvn: Avoid ICEs on _BitInt load BIT_AND_EXPR mask [PR111338]

On Mon, 11 Sep 2023, Jakub Jelinek wrote: > Hi! > > The following testcase ICEs, because vn_walk_cb_data::push_partial_def > uses a fixed size buffer (64 target bytes) for its > construction/deconstruction of partial stores and fails if larger precision > than that is needed, and the PR93582 chan

Re: [PATCH] small _BitInt tweaks

On Mon, 11 Sep 2023, Jakub Jelinek wrote: > Hi! > > When discussing PR111369 with Andrew Pinski, I've realized that > I haven't added BITINT_TYPE handling to range_check_type. Right now > (unsigned) max + 1 == (unsigned) min for signed _BitInt,l so I think we > don't need to do the extra hops fo

Re: [PATCH] MATCH: Simplify (a CMP1 b) ^ (a CMP2 b)

On Tue, Sep 12, 2023 at 6:22 AM Andrew Pinski via Gcc-patches wrote: > > This adds the missing optimizations here. > Note we don't need to match where CMP1 and CMP2 are complements of each > other as that is already handled elsewhere. > > I added a new executable testcase to make sure we optimize

Re: [PATCH V4] RISC-V: Support Dynamic LMUL Cost model

> This is first version of dynamic LMUL. > I didn't test it with full GCC testsuite. > > My plan is to first pass all GCC testsuite (including vect.exp) with default > LMUL = M1. > Then enable dynamic LMUL to test it. > > Maybe we could tolerate this ICE issue for now. Then we can test it > wi

libffi: Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR109951] (was: [PATCH v5 GCC] libffi/test: Fix compilation for build sysroot)

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 the tool being different from one the > library has been built with, and causing a catastrophic failure from the >

[PATCH V5] RISC-V: Support Dynamic LMUL Cost model

This patch support dynamic LMUL cost modeling with --param=riscv-autovec-lmul=dynamic. Consider this following case: void foo (int32_t *__restrict a, int32_t *__restrict b,int32_t *__restrict c, int32_t *__restrict a2, int32_t *__restrict b2, int32_t *__restrict c2, int32_t *__res

libatomic: Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR109951] (was: [PATCH v4 1/5] libatomic/test: Fix compilation for build sy

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 the tool being different from one the > library has been built with, and causing a catastrophic failure from the

Re: [PATCH V5] RISC-V: Support Dynamic LMUL Cost model

LGTM. We should just keep in mind the restrictions discussed in the other thread. Regards Robin

libgo: Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR109951] (was: [PATCH 3/4] libgo/test: Fix compilation for build sysroot)

Hi! On 2019-11-11T18:12:44+, "Maciej W. Rozycki" wrote: > Fix a problem with the libgo testsuite using a method to determine the > compiler to use resulting in the tool being different from one the > library has been built with, and causing a catastrophic failure from the > lack of a suitable

Re: [PATCH] small _BitInt tweaks

On Tue, Sep 12, 2023 at 10:27:18AM +, Richard Biener wrote: > On Mon, 11 Sep 2023, Jakub Jelinek wrote: > > And, also I think it is undesirable when being asked for signed_type_for > > of unsigned _BitInt(1) (which is valid) to get signed _BitInt(1) (which is > > invalid, the standard only allo

RE: [PATCH V5] RISC-V: Support Dynamic LMUL Cost model

Committed, thanks Robin. Pan -Original Message- From: Gcc-patches On Behalf Of Robin Dapp via Gcc-patches Sent: Tuesday, September 12, 2023 7:07 PM To: Juzhe-Zhong ; gcc-patches@gcc.gnu.org Cc: kito.ch...@sifive.com; kito.ch...@gmail.com Subject: Re: [PATCH V5] RISC-V: Support Dynamic L

[committed] libstdc++: Format Python code according to PEP8

Tested x86_64-linux. Pushed to trunk. -- >8 -- These files were filtered through autopep8 to reformat them more conventionally. libstdc++-v3/ChangeLog: * python/libstdcxx/v6/printers.py: Reformat. * python/libstdcxx/v6/xmethods.py: Likewise. --- libstdc++-v3/python/libstdcxx/v6

[committed] contrib: Quote variable in test expression [PR111360]

Committed as obvious. -- >8 -- Without the quotes some shells will always return true and some will print an error. It should be quoted so that a null variable works as intended. contrib/ChangeLog: PR other/111360 * gcc_update: Quote variable. --- contrib/gcc_update | 2 +- 1 f

Re: [PATCH 1/3] libstdc++: Remove std::bind_front specialization for no bound args

On Mon, 11 Sep 2023, Patrick Palka wrote: > This specialization for the case of no bound args, added by > r13-4214-gcbd05ca5ab1231, seems to be mostly obsoleted by > r13-5033-ge2eab3c4edb6aa which added [[no_unique_address]] to the > main template's data members. And the compile time advantage of

[PATCH v1] RISC-V: Remove unused structure in cost model

From: Pan Li The struct range is unused, remove it. gcc/ChangeLog: * config/riscv/riscv-vector-costs.h (struct range): Removed. Signed-off-by: Pan Li --- gcc/config/riscv/riscv-vector-costs.h | 7 --- 1 file changed, 7 deletions(-) diff --git a/gcc/config/riscv/riscv-vector-cost

Re: [PATCH 00/13] libstdc++: Add support for running tests with multiple -std options

On Mon, 11 Sept 2023 at 17:37, Jonathan Wakely via Libstdc++ wrote: > > This patch series replicates the behaviour of the g++ testsuite, so that > libstdc++ tests can easily be run for multiple different -std options in > a single testsuite run. As described in the updated docs, the -std > option

Re: [PATCH v1] RISC-V: Remove unused structure in cost model

On 9/12/23 07:02, Pan Li via Gcc-patches wrote: From: Pan Li The struct range is unused, remove it. gcc/ChangeLog: * config/riscv/riscv-vector-costs.h (struct range): Removed. OK jeff

Re: [PATCH 1/3] libstdc++: Remove std::bind_front specialization for no bound args

On Tue, 12 Sept 2023 at 13:46, Patrick Palka via Libstdc++ wrote: > > On Mon, 11 Sep 2023, Patrick Palka wrote: > > > This specialization for the case of no bound args, added by > > r13-4214-gcbd05ca5ab1231, seems to be mostly obsoleted by > > r13-5033-ge2eab3c4edb6aa which added [[no_unique_addre

Re: [PATCH 2/3] libstdc++: Fix std::bind_front perfect forwarding [PR111327]

On Tue, 12 Sept 2023 at 02:09, Patrick Palka via Libstdc++ wrote: > > In order to properly implement a perfect forwarding call wrapper > (before 'deducing this' at least) we need a total of 8 operator() > overloads, 4 main ones and 4 deleted ones for each const/ref qual pair, > as described in sec

Re: [PATCH 3/3] libstdc++: Fix std::not_fn perfect forwarding [PR111327]

On Tue, 12 Sept 2023 at 02:11, Patrick Palka via Libstdc++ wrote: > > The previous patch fixed perfect forwarding for std::bind_front. > This patch fixes the same issue for std::not_fn. > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk and > perhaps 13? Yes for both, thanks. > >

[PATCH] RISC-V: Support VECTOR BOOL vcond_mask optab[PR111337]

As this PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337 We support VECTOR BOOL vcond_mask to fix this following ICE: 0x1a9e309 gimple_expand_vec_cond_expr ../../../../gcc/gcc/gimple-isel.cc:283 0x1a9ea56 execute ../../../../gcc/gcc/gimple-isel.cc:390 gcc/ChangeLog:

RE: [PATCH v1] RISC-V: Remove unused structure in cost model

Committed, thanks Jeff. Pan -Original Message- From: Jeff Law Sent: Tuesday, September 12, 2023 9:12 PM To: Li, Pan2 ; gcc-patches@gcc.gnu.org Cc: Wang, Yanzhang ; kito.ch...@gmail.com; juzhe.zh...@rivai.ai Subject: Re: [PATCH v1] RISC-V: Remove unused structure in cost model On 9/1

Re: [PATCH] RISC-V: Support VECTOR BOOL vcond_mask optab[PR111337]

Maybe you want to add PR target/111337 to the changelog? The rest LGTM. Regards Robin

[PATCH V2] RISC-V: Support VECTOR BOOL vcond_mask optab[PR111337]

PR target/111337 As this PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337 We support VECTOR BOOL vcond_mask to fix this following ICE: 0x1a9e309 gimple_expand_vec_cond_expr ../../../../gcc/gcc/gimple-isel.cc:283 0x1a9ea56 execute ../../../../gcc/gcc/gimple-isel.cc:390 g

Re: Re: [PATCH] RISC-V: Support VECTOR BOOL vcond_mask optab[PR111337]

Ok add it in V2: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630048.html juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-09-12 21:29 To: Juzhe-Zhong; gcc-patches CC: rdapp.gcc; kito.cheng; kito.cheng; jeffreyalaw Subject: Re: [PATCH] RISC-V: Support VECTOR BOOL vcond_mask optab

Re: [PATCH V2] RISC-V: Support VECTOR BOOL vcond_mask optab[PR111337]

The PR thing needs to be moved but I can commit it. Regards Robin

[PATCH 14/13] libstdc++: Re-initialize static data files used by tests

This fixes the problem observed with some filebuf tests. The "@require@" string seems a bit hacky, as I don't know why that string is in the tests in the first palce ... but it is there, so this works. -- > 8-- Some tests rely on text files with specific content being present in the test directo

[PATCH] libgomp, nvptx, amdgcn: parallel reverse offload

Hi all, This patch implements parallel execution of OpenMP reverse offload kernels. The first problem was that GPU device kernels may request reverse offload (via the "ancestor" clause) once for each running offload thread -- of which there may be thousands -- and the existing implementation

gcc-patches From rewriting mailman settings (Was: [Linaro-TCWG-CI] gcc patch #75674: FAIL: 68 regressions)

Hi Maxim, Adding Jeff to CC who is the official gcc-patches mailinglist admin. On Tue, 2023-09-12 at 11:08 +0400, Maxim Kuvyrkov wrote: > Normally, notifications from Linaro TCWG precommit CI are sent only to > patch author and patch submitter. In this case the sender was rewritten > to "Benjami

[PATCH 00/19] aarch64: Fix -fstack-protector issue

This series of patches fixes deficiencies in GCC's -fstack-protector implementation for AArch64 when using dynamically allocated stack space. This is CVE-2023-4039. See: https://developer.arm.com/Arm%20Security%20Center/GCC%20Stack%20Protector%20Vulnerability%20AArch64 https://github.com/metaredt

[PATCH 01/19] aarch64: Use local frame vars in shrink-wrapping code

aarch64_layout_frame uses a shorthand for referring to cfun->machine->frame: aarch64_frame &frame = cfun->machine->frame; This patch does the same for some other heavy users of the structure. No functional change intended. gcc/ * config/aarch64/aarch64.cc (aarch64_save_callee_saves): U

[PATCH 05/19] aarch64: Add bytes_below_hard_fp to frame info

Following on from the previous bytes_below_saved_regs patch, this one records the number of bytes that are below the hard frame pointer. This eventually replaces below_hard_fp_saved_regs_size. If a frame pointer is not needed, the epilogue adds final_adjust to the stack pointer before restoring re

[PATCH 07/19] aarch64: Only calculate chain_offset if there is a chain

After previous patches, it is no longer necessary to calculate a chain_offset in cases where there is no chain record. gcc/ * config/aarch64/aarch64.cc (aarch64_expand_prologue): Move the calculation of chain_offset into the emit_frame_chain block. --- gcc/config/aarch64/aarch64.c

[PATCH 12/19] aarch64: Simplify top of frame allocation

After previous patches, it no longer really makes sense to allocate the top of the frame in terms of varargs_and_saved_regs_size and saved_regs_and_above. gcc/ * config/aarch64/aarch64.cc (aarch64_layout_frame): Simplify the allocation of the top of the frame. --- gcc/config/aarch

[PATCH 02/19] aarch64: Avoid a use of callee_offset

When we emit the frame chain, i.e. when we reach Here in this statement of aarch64_expand_prologue: if (emit_frame_chain) { // Here ... } the stack is in one of two states: - We've allocated up to the frame chain, but no more. - We've allocated the whole frame, and the fra

[PATCH 06/19] aarch64: Tweak aarch64_save/restore_callee_saves

aarch64_save_callee_saves and aarch64_restore_callee_saves took a parameter called start_offset that gives the offset of the bottom of the saved register area from the current stack pointer. However, it's more convenient for later patches if we use the bottom of the entire frame as the reference po

[PATCH 1/2] MATCH: [PR111364] Add some more minmax cmp operand simplifications

This adds a few more minmax cmp operand simplifications which were missed before. `MIN(a,b) < a` -> `a > b` `MIN(a,b) >= a` -> `a <= b` `MAX(a,b) > a` -> `a < b` `MAX(a,b) <= a` -> `a >= b` OK? Bootstrapped and tested on x86_64-linux-gnu. Note gcc.dg/pr96708-negative.c needed to updated to remov

[PATCH 09/19] aarch64: Rename hard_fp_offset to bytes_above_hard_fp

Similarly to the previous locals_offset patch, hard_fp_offset was described as: /* Offset from the base of the frame (incomming SP) to the hard_frame_pointer. This value is always a multiple of STACK_BOUNDARY. */ poly_int64 hard_fp_offset; which again took an “upside-down” view: h

  1   2   >