[PATCH] lower-bitint, v2: Make temporarily wrong IL less wrong [PR112843]

On Tue, Dec 05, 2023 at 08:21:15AM +0100, Jakub Jelinek wrote: > The reason I tweaked the lhs first is that it then just uses gimple_op and > iterates over all ops, if that is done before lhs it would need to special > case which op to skip because it is lhs (I'm using gimple_get_lhs for the > lhs,

[PATCH 1/5][V3][ifcvt] optimize x=c ? (y op z) : y by RISC-V Zicond like insns

op=[PLUS, MINUS, IOR, XOR] Conditional op, if zero rd = (rc == 0) ? (rs1 op rs2) : rs1 --> czero.nez rd, rs2, rc op rd, rs1, rd Conditional op, if non-zero rd = (rc != 0) ? (rs1 op rs2) : rs1 --> czero.eqz rd, rs2, rc op rd, rs1, rd Co-authored-by: Xiao Zeng gcc/ChangeLog: * ifcvt.cc (

[PATCH 2/5] [ifcvt] optimize x=c ? (y shift_op z):y by RISC-V Zicond like insns

op=[ASHIFT, ASHIFTRT, LSHIFTRT, ROTATE, ROTATERT] Conditional op, if zero rd = (rc == 0) ? (rs1 op rs2) : rs1 --> czero.nez rd, rs2, rc op rd, rs1, rd Conditional op, if non-zero rd = (rc != 0) ? (rs1 op rs2) : rs1 --> czero.eqz rd, rs2, rc op rd, rs1, rd Co-authored-by: Xiao Zeng gcc/ChangeLog

[PATCH 3/5] [ifcvt] optimize x=c ? (y AND z) : y by RISC-V Zicond like insns

Take the following case for example. CFLAGS: -march=rv64gc_zbb_zicond -mabi=lp64d -O2 long test_AND_ceqz (long x, long y, long z, long c) { if (c) x = y & z; else x = y; return x; } Before patch: and a2,a1,a2 czero.eqz a0,a2,a3 czero.nez a3,a1,a3 or a0,a3,a0 r

[PATCH 4/5] [ifcvt] optimize x=c ? (y op const_int) : y by RISC-V Zicond like insns

op=[PLUS, MINUS, IOR, XOR, ASHIFT, ASHIFTRT, LSHIFTRT, ROTATE, ROTATERT, AND] Co-authored-by: Xiao Zeng gcc/ChangeLog: * ifcvt.cc (noce_cond_zero_shift_op_supported): check if OP is shift like operation (noce_cond_zero_binary_op_supported): restructure & call noce_cond_zero_shi

[PATCH 5/5] [ifcvt] optimize extension for x=c ? (y op z) : y by RISC-V Zicond like insns

SIGN_EXTEND, ZERO_EXTEND and SUBREG has been considered to support SImode in 64-bit machine. Co-authored-by: Xiao Zeng gcc/ChangeLog: * ifcvt.cc (noce_cond_zero_binary_op_supported): add support for extension (noce_bbs_ok_for_cond_zero_arith): likewise (noce_try_cond_zer

RE: [PATCH] tree-optimization/112827 - corrupt SCEV cache during SCCP

On Tue, 5 Dec 2023, Li, Pan2 wrote: > Hi Richard, > > It looks like this patch result in one ICE for RISC-V backend for case > tree-ssa.exp=ssa-sink-16.c, could you please help to double check about it? > Any more information required please feel free to let me know. Thanks. I have pushed a fix

Re: [PATCH] lower-bitint: Make temporarily wrong IL less wrong [PR112843]

On Tue, 5 Dec 2023, Jakub Jelinek wrote: > Hi! > > As discussed in the PR, for the middle (on x86-64 65..128 bit) _BitInt > types like > _1 = x_4(D) * 5; > where _1 and x_4(D) have _BitInt(128) type and x is PARM_DECL, the bitint > lowering pass wants to replace this with > _13 = (int128_t) x

[PATCH] RISC-V: FAIL:g++.dg/torture/vshuf-v[2|4]di.C -Os (execution test) on RV32

From: xuli This patch fixs the issue of g++.dg/torture/vshuf-v2di.C and g++.dg/torture/vshuf-v4di.C -Os execution failure with -march=rv32gcv -mabi=ilp32d. Consider the following code: typedef unsigned long long V __attribute__((vector_size(16))); .LC0: 0xc1c2c3c4c5c6c7c8 before this patch: l

Re: [PATCH] RISC-V: FAIL:g++.dg/torture/vshuf-v[2|4]di.C -Os (execution test) on RV32

+ if (!TARGET_64BIT + && maybe_gt (GET_MODE_SIZE (scalar_mode), GET_MODE_SIZE (Pmode))) I think if (maybe_gt (GET_MODE_SIZE (scalar_mode), GET_MODE_SIZE (Pmode))) should be enough. Thanks for fixing it. juzhe.zh...@rivai.ai From: Li Xu Date: 2023-12-05 16:22 To: gcc-patches CC: kito.c

[PATCH] tree-optimization/112843 - update_stmt doing wrong things

The following removes range_query::update_stmt and its single invocation from update_stmt_operands. That function is not supposed to look beyond the raw stmt contents of the passed stmt since there's no guarantee about the rest of the IL. I've successfully bootstrapped & tested the update_stmt_op

Re: Re: [PATCH 2/4] [ifcvt] optimize x=c ? (y op z) : y by RISC-V Zicond like insns

On 2023-11-29 19:09  Fei Gao wrote: > >On 2023-11-29 13:26  Jeff Law wrote: >> >> >> >>On 11/27/23 19:32, Fei Gao wrote: >>> op=[PLUS, MINUS, IOR, XOR, ASHIFT, ASHIFTRT, LSHIFTRT, ROTATE, ROTATERT] >>> >>> SIGN_EXTEND, ZERO_EXTEND and SUBREG has been considered >>> to support SImode in 64-bit m

[PATCH v2] RISC-V: FAIL:g++.dg/torture/vshuf-v[2|4]di.C -Os (execution test) on RV32

From: xuli This patch fixs the issue of g++.dg/torture/vshuf-v2di.C and g++.dg/torture/vshuf-v4di.C -Os execution failure with -march=rv32gcv -mabi=ilp32d. Consider the following code: typedef unsigned long long V __attribute__((vector_size(16))); .LC0: 0xc1c2c3c4c5c6c7c8 before this patch: l

Re: [PATCH v2] RISC-V: FAIL:g++.dg/torture/vshuf-v[2|4]di.C -Os (execution test) on RV32

LGTM. Thanks. juzhe.zh...@rivai.ai From: Li Xu Date: 2023-12-05 16:38 To: gcc-patches CC: kito.cheng; palmer; juzhe.zhong; xuli Subject: [PATCH v2] RISC-V: FAIL:g++.dg/torture/vshuf-v[2|4]di.C -Os (execution test) on RV32 From: xuli This patch fixs the issue of g++.dg/torture/vshuf-v2di.C

Re: Re: [PATCH v2] RISC-V: FAIL:g++.dg/torture/vshuf-v[2|4]di.C -Os (execution test) on RV32

Committed, thanks juzhe. xu...@eswincomputing.com From: juzhe.zh...@rivai.ai Date: 2023-12-05 16:41 To: Li Xu; gcc-patches CC: kito.cheng; palmer; Li Xu Subject: Re: [PATCH v2] RISC-V: FAIL:g++.dg/torture/vshuf-v[2|4]di.C -Os (execution test) on RV32 LGTM. Thanks. juzhe.zh...@rivai.ai Fr

Re: [RFC PATCH 1/1] nix: add a simple flake nix shell

On Tue, Dec 5, 2023 at 5:26 AM Eli Schwartz wrote: > > On 12/4/23 9:01 PM, Vincenzo Palazzo wrote: > > On Tue, Dec 5, 2023 at 2:54 AM Jeff Law wrote: > >> Distro build procedures are not something the GCC project generally gets > >> involved with. > > > > I see, but to me, this do not look like a

Re: [PATCH v1] LoongArch: Modify the check type of the vector builtin function.

在 2023-12-04一的 20:38 +0800，Xi Ruoyao写道： > On Mon, 2023-12-04 at 20:31 +0800, Xi Ruoyao wrote: > > On Mon, 2023-12-04 at 20:14 +0800, chenxiaolong wrote: > > > On LoongArch architecture, using the latest gcc14 in regression > > > test, > > > it is found that the vector test cases in vector directory

[pushed] Allow prologues and epilogues to be inserted later

Jeff approved this patch last year (thanks!): https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606723.html I ended up not pushing it then because the things that used it didn't go in. Now pushed after retesting on aarch64-linux-gnu. --- Arm's SME adds a new processor mode called streaming

[v2] c: Turn -Wimplicit-function-declaration into a permerror: Fix 'gcc.dg/gnu23-builtins-no-dfp-1.c' (was: [committed] Fix gnu23-builtins-no-dfp)

Hi! On 2023-12-03T13:57:36-0700, Jeff Law wrote: > On 12/3/23 05:23, Thomas Schwinge wrote: >> On 2023-12-03T08:41:59+0100, Florian Weimer wrote: >> >> "c: Turn -Wimplicit-function-declaration into a permerror: Fix >> 'gcc.

Modula-2: Support '-isysroot [...]'

Hi! OK to push the attached "Modula-2: Support '-isysroot [...]'"? This greatly improves test results for the cross configurations I've tested, but I don't know if any real handling needs to be implemented, or this should be done differently altogether? Grüße Thomas - Siemens

[PATCH] Add a target hook for sibcall epilogues

Jeff approved this patch last year (thanks!): https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606362.html I ended up not pushing it then because the things that used it didn't go in. Now pushed after retesting on aarch64-linux-gnu. --- Epilogues for sibling calls are generated using the

Re: [PATCH v3 10/11] c: Turn -Wincompatible-pointer-types into a permerror

(I think it's this patch, not one of the others in the series). This breaks building libgfortran with newlib on arm and aarch64: /work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/list_read.c:2208:46: error: pointer type mismatch in conditional expression [-Wincompatible-pointer-ty

[PATCH] Add a new target hook: TARGET_START_CALL_ARGS

Richi approved this patch last year (thanks!): https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606698.html I ended up not pushing it then because the things that used it didn't go in. Now pushed after retesting on aarch64-linux-gnu. --- We have the following two hooks into the call expan

Re: [PATCH v3 10/11] c: Turn -Wincompatible-pointer-types into a permerror

* Richard Earnshaw: > (I think it's this patch, not one of the others in the series). > > This breaks building libgfortran with newlib on arm and aarch64: > > > /work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/list_read.c:2208:46: > error: pointer type mismatch in conditional expressi

Re: [PATCH] RISC-V: Check if zcd conflicts with zcmt and zcmp

committed to trunk, thanks :) On Mon, Dec 4, 2023 at 5:21 PM Christoph Müllner wrote: > > On Mon, Dec 4, 2023 at 8:48 AM Kito Cheng wrote: > > LGTM > > I've double-checked this in the Zc-1.0.4-3.pdf: > * Zcmp is incompatible with Zcd > * Zcmp depends on Zca > * Zcmt is incompatible with Zcd > *

[pushed] Allow targets to add USEs to asms

Jeff approved this patch last year (thanks!): https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605892.html I ended up not pushing it then because the things that used it didn't go in. Now pushed after retesting on aarch64-linux-gnu. --- Arm's SME has an array called ZA that for inline asm

Re: [PATCH v3 10/11] c: Turn -Wincompatible-pointer-types into a permerror

On 05/12/2023 09:46, Florian Weimer wrote: * Richard Earnshaw: (I think it's this patch, not one of the others in the series). This breaks building libgfortran with newlib on arm and aarch64: /work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/list_read.c:2208:46: error: pointer

[pushed v2 01/25] aarch64: Generalise require_immediate_lane_index

require_immediate_lane_index previously hard-coded the assumption that the group size is determined by the argument immediately before the index. However, for SME, there are cases where it should be determined by an earlier argument instead. gcc/ * config/aarch64/aarch64-sve-builtins.h:

[pushed v2 03/25] aarch64: Make AARCH64_FL_SVE requirements explicit

So far, all intrinsics covered by the aarch64-sve-builtins* framework have (naturally enough) required at least SVE. However, arm_sme.h defines a couple of intrinsics that can be called by any code. It's therefore necessary to make the implicit SVE requirement explicit. gcc/ * config/aarc

[pushed v2 02/25] aarch64: Use SVE's RDVL instruction

We didn't previously use SVE's RDVL instruction, since the CNT* forms are preferred and provide most of the range. However, there are some cases that RDVL can handle and CNT* can't, and using RDVL-like instructions becomes important for SME. gcc/ * config/aarch64/aarch64-protos.h (aarch64

[pushed v2 04/25] aarch64: Add group suffixes to SVE intrinsics

The SME2 ACLE adds a new "group" suffix component to the naming convention for SVE intrinsics. This is also used in the new tuple forms of the svreinterpret intrinsics. This patch adds support for group suffixes and defines the x2, x3 and x4 suffixes that are needed for the svreinterprets. gcc/

[pushed v2 00/25] aarch64: Add support for SME

This is the version of the SME support that I pushed to trunk. The only significant difference from the original version: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637049.html is that it includes some tweaks to the C overload resolution code, since it turned out that the current c

[pushed v2 09/25] aarch64: Tweak error message for (tuple, vector) pairs

SME2 adds more intrinsics that take a tuple of vectors followed by a single vector, with the two arguments expected to have the same element type. Unlike with the existing svset* intrinsics, the size of the tuple is not fixed by the overloaded function name. This patch adds an error message that

[pushed v2 05/25] aarch64: Add sve_type to SVE builtins code

Until now, the SVE ACLE code had mostly been able to represent individual SVE arguments with just an element type suffix (s32, u32, etc.). However, the SME2 ACLE provides many overloaded intrinsics that operate on tuples rather than single vectors. This patch therefore adds a new type (sve_type)

[pushed v2 08/25] aarch64: Make more use of sve_type in ACLE code

This patch makes some functions operate on sve_type, rather than just on type suffixes. It also allows an overload to be resolved based on a mode and sve_type. In this case the sve_type is used to derive the group size as well as a type suffix. This is needed for the SME2 intrinsics and the new

[pushed v2 10/25] aarch64: Add tuple forms of svreinterpret

SME2 adds a number of intrinsics that operate on tuples of 2 and 4 vectors. The ACLE therefore extends the existing svreinterpret intrinsics to handle tuples as well. gcc/ * config/aarch64/aarch64-sve-builtins-base.cc (svreinterpret_impl::fold): Punt on tuple forms. (svrei

[pushed v2 07/25] aarch64: Replace vague "previous arguments" message

If an SVE ACLE intrinsic requires two arguments to have the same type, the C resolver would report mismatches as "argument N has type T2, but previous arguments had type T1". This patch makes the message say which argument had type T1. This is needed to give decent error messages for some SME cas

[pushed v2 22/25] aarch64: Add support for __arm_locally_streaming

This patch adds support for the __arm_locally_streaming attribute, which allows a function to use SME internally without changing the function's ABI. The attribute is valid but redundant for __arm_streaming functions. gcc/ * config/aarch64/aarch64.cc (aarch64_arm_attribute_table): Add

[pushed v2 06/25] aarch64: Generalise some SVE ACLE error messages

The current SVE ACLE function-resolution diagnostics assume that a function has a fixed choice between vectors or tuples of vectors. If an argument was not an SVE type at all, the error message said the function "expects an SVE vector type" or "expects an SVE tuple type". This patch generalises t

[pushed v2 11/25] aarch64: Add arm_streaming(_compatible) attributes

This patch adds support for recognising the SME arm::streaming and arm::streaming_compatible attributes. These attributes respectively describe whether the processor is definitely in "streaming mode" (PSTATE.SM==1), whether the processor is definitely not in streaming mode (PSTATE.SM==0), or wheth

[pushed v2 17/25] aarch64: Add a register class for w12-w15

Some SME instructions use w12-w15 to index ZA. This patch adds a register class for that range. gcc/ * config/aarch64/aarch64.h (W12_W15_REGNUM_P): New macro. (W12_W15_REGS): New register class. (REG_CLASS_NAMES, REG_CLASS_CONTENTS): Add entries for it. * config/aa

[pushed v2 18/25] aarch64: Add a VNx1TI mode

Although TI isn't really a native SVE element mode, it's convenient for SME if we define VNx1TI anyway, so that it can be used to distinguish .Q ZA operations from others. It's purely an RTL convenience and isn't (yet) a valid storage mode. gcc/ * config/aarch64/aarch64-modes.def: Add VNx

[pushed v2 15/25] aarch64: Switch PSTATE.SM around calls

This patch adds support for switching to the appropriate SME mode for each call. Switching to streaming mode requires an SMSTART SM instruction and switching to non-streaming mode requires an SMSTOP SM instruction. If the call is being made from streaming-compatible code, these switches are condi

[pushed v2 12/25] aarch64: Add +sme

This patch adds the +sme ISA feature and requires it to be present when compiling arm_streaming code. (arm_streaming_compatible code does not necessarily assume the presence of SME. It just has to work when SME is present and streaming mode is enabled.) gcc/ * doc/invoke.texi: Document S

[pushed v2 13/25] aarch64: Distinguish streaming-compatible AdvSIMD insns

The vast majority of Advanced SIMD instructions are not available in streaming mode, but some of the load/store/move instructions are. This patch adds a new target feature macro called TARGET_BASE_SIMD for this streaming-compatible subset. The vector-to-vector move instructions are not streaming-

[pushed v2 16/25] aarch64: Add support for SME ZA attributes

SME has an array called ZA that can be enabled and disabled separately from streaming mode. A status bit called PSTATE.ZA indicates whether ZA is currently enabled or not. In C and C++, the state of PSTATE.ZA is controlled using function attributes. There are four attributes that can be attached

[pushed v2 19/25] aarch64: Generalise unspec_based_function_base

Until now, SVE intrinsics that map directly to unspecs have always used type suffix 0 to distinguish between signed integers, unsigned integers, and floating-point values. SME adds functions that need to use type suffix 1 instead. This patch generalises the classes accordingly. gcc/ * conf

[pushed v2 23/25] aarch64: Handle PSTATE.SM across abnormal edges

PSTATE.SM is always off on entry to an exception handler, and on entry to a nonlocal goto receiver. Those entry points need to switch PSTATE.SM back to the appropriate state for the current function. In the case of streaming-compatible functions, they need to restore the mode that the caller was o

[pushed v2 24/25] aarch64: Enforce inlining restrictions for SME

A function that has local ZA state cannot be inlined into its caller, since we only support managing ZA switches at function scope. A function whose body directly clobbers ZA state cannot be inlined into a function with ZA state. A function whose body requires a particular PSTATE.SM setting can o

[pushed v2 20/25] aarch64: Generalise _m rules for SVE intrinsics

In SVE there was a simple rule that unary merging (_m) intrinsics had a separate initial argument to specify the values of inactive lanes, whereas other merging functions took inactive lanes from the first operand to the operation. That rule began to break down in SVE2, and it continues to do so i

[pushed v2 25/25] aarch64: Update sibcall handling for SME

We only support tail calls between functions with the same PSTATE.ZA setting ("private-ZA" to "private-ZA" and "shared-ZA" to "shared-ZA"). Only a normal non-streaming function can tail-call another non-streaming function, and only a streaming function can tail-call another streaming function. An

[pushed v2 21/25] aarch64: Add support for

This adds support for the SME parts of arm_sme.h. gcc/ * doc/invoke.texi: Document +sme-i16i64 and +sme-f64f64. * config.gcc (aarch64*-*-*): Add arm_sme.h to the list of headers to install and aarch64-sve-builtins-sme.o to the list of objects to build. * con

Re: [PATCH] expmed: Perform mask extraction via QImode [PR112773].

> But how do we know BImode fits in QImode? I was kind of hoping that a "bit" always fits in a "byte"/unit but yeah, I guess we don't always know :/ > I think the issue is more that we try to extract an element from > the mask vector? How is element extraction defined for VLA vectors > anyway?

[pushed v2 1/5] aarch64: Add +sme2

gcc/ * doc/invoke.texi: Document +sme2. * doc/sourcebuild.texi: Document aarch64_sme2. * config/aarch64/aarch64-option-extensions.def (AARCH64_OPT_EXTENSION): Add sme2. * config/aarch64/aarch64.h (AARCH64_ISA_SME2, TARGET_SME2): New macros. gcc/testsuite/

[pushed v2 3/5] aarch64: Add svboolx2_t

SME2 has some instructions that operate on pairs of predicates. The SME2 ACLE defines an svboolx2_t type for the associated intrinsics. The patch uses a double-width predicate mode, VNx32BI, to represent the contents, similarly to how data vector tuples work. At present there doesn't seem to be a

[pushed v2 2/5] aarch64: Add svcount_t

Some SME2 instructions interpret predicates as counters, rather than as bit-per-byte masks. The SME2 ACLE defines an svcount_t type for this interpretation. I don't think we have a better way of representing counters than the VNx16BI that we use for masks. The patch therefore doesn't add a new m

[pushed v2 0/5] aarch64: Add support for SME2

This is the version of the SME support that I pushed to trunk. The only significant differences from the original version: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637072.html are: - it extends svget2, svset2, svcreate2 and svundef2 to the new svboolx2_t type, which I forgot t

[pushed v2 4/5] aarch64: Add ZT0

SME2 adds a 512-bit lookup table called ZT0. It is enabled and disabled by PSTATE.ZA, just like ZA itself. This patch adds support for the register, including saving and restoring contents. The code reuses the V8DI that was added for LS64, including the associated memory classification rules. (

[PATCH] libgfortran: Fix -Wincompatible-pointer-types errors

Hi! On Tue, Dec 05, 2023 at 10:46:02AM +0100, Florian Weimer wrote: > Presumably the fixes will look like this? > > diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c > index db3330060ce..4fcc77dbf83 100644 > --- a/libgfortran/io/list_read.c > +++ b/libgfortran/io/list_read.c >

Re: [RFC PATCH 1/1] nix: add a simple flake nix shell

Hi all, >Generally we have various stuff in contrib/, one of it scripts like gcc_build. IMHO the flake.nix file (or a script to create it) could be put there as well. I was not sure about that, I will try to see what if I can put in there >But you can do the same with various other distro buil

Re: [PATCH 02/17] [APX NDD] Restrict TImode register usage when NDD enabled

On Tue, Dec 5, 2023 at 3:29 AM Hongyu Wang wrote: > > Under APX NDD, previous TImode allocation will have issue that it was > originally allocated using continuous pair, like rax:rdi, rdi:rdx. > > This will cause issue for all TImode NDD patterns. For NDD we will not > assume the arithmetic operat

Re: [PATCH] libgfortran: Fix -Wincompatible-pointer-types errors

On 05/12/2023 10:33, Jakub Jelinek wrote: Hi! On Tue, Dec 05, 2023 at 10:46:02AM +0100, Florian Weimer wrote: Presumably the fixes will look like this? diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c index db3330060ce..4fcc77dbf83 100644 --- a/libgfortran/io/list_read.c

Re: [PATCH] libgfortran: Fix -Wincompatible-pointer-types errors

On Tue, Dec 05, 2023 at 10:47:34AM +, Richard Earnshaw wrote: > > The following patch makes libgfortran build on i686-linux after hacking up > > --- kinds.h.xx 2023-12-05 00:23:00.133365064 +0100 > > +++ kinds.h 2023-12-05 11:19:24.409679808 +0100 > > @@ -10,8 +10,8 @@ typedef GFC_INTEGER_

[PATCH v2 06/11] aarch64: Fix up aarch64_print_operand xzr/wzr case

Hi, This is a v2 of: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637612.html v1 was approved as-is, but this version pulls out the test into a helper function which is used by later patches in the series. Bootstrapped/regtested as a series on aarch64-linux-gnu, OK for trunk? Thanks

Re: [PATCH] libgfortran: Fix -Wincompatible-pointer-types errors

On 05/12/2023 10:51, Jakub Jelinek wrote: On Tue, Dec 05, 2023 at 10:47:34AM +, Richard Earnshaw wrote: The following patch makes libgfortran build on i686-linux after hacking up --- kinds.h.xx 2023-12-05 00:23:00.133365064 +0100 +++ kinds.h 2023-12-05 11:19:24.409679808 +0100 @@ -10

[PATCH] driver: Fix bootstrap with --enable-default-pie

Hi! On IRC Iain mentioned bootstrap is broken for him presumably since r14-5791 -fhardened addition. I think it is only a problem with --enable-default-pie when the case OPT_pie: wants to fall through into case OPT_r: and warns. Before the patch validated = true; was set up if ENABLE_DEFAULT_PIE

[PATCH v2 09/11] aarch64: Rewrite non-writeback ldp/stp patterns

Hi, This is a v2 version which addresses feedback from Richard's review here: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637648.html I'll reply inline to address specific comments. Bootstrapped/regtested on aarch64-linux-gnu, OK for trunk? Thanks, Alex -- >8 -- This patch overha

Re: [PATCH] libgfortran: Fix -Wincompatible-pointer-types errors

On Tue, Dec 05, 2023 at 10:57:50AM +, Richard Earnshaw wrote: > On 05/12/2023 10:51, Jakub Jelinek wrote: > > On Tue, Dec 05, 2023 at 10:47:34AM +, Richard Earnshaw wrote: > > > > The following patch makes libgfortran build on i686-linux after hacking > > > > up > > > > --- kinds.h.xx 202

Re: [PATCH] libgfortran: Fix -Wincompatible-pointer-types errors

* Richard Earnshaw: > On 05/12/2023 10:51, Jakub Jelinek wrote: >> On Tue, Dec 05, 2023 at 10:47:34AM +, Richard Earnshaw wrote: The following patch makes libgfortran build on i686-linux after hacking up --- kinds.h.xx 2023-12-05 00:23:00.133365064 +0100 +++ kinds.h2

Re: [PATCH 09/11] aarch64: Rewrite non-writeback ldp/stp patterns

Thanks for the review, I've posted a v2 here which addresses this feedback: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639361.html On 21/11/2023 16:04, Richard Sandiford wrote: > Alex Coplan writes: > > This patch overhauls the load/store pair patterns with two main goals: > > > > 1.

RE: [PATCH] aarch64: Add an early RA for strided registers

Hi Richard, > -Original Message- > From: Richard Sandiford > Sent: Monday, November 20, 2023 12:16 PM > To: gcc-patches@gcc.gnu.org > Subject: [PATCH] aarch64: Add an early RA for strided registers > > [Yeah, I just missed the stage1 deadline, sorry. But this is gated > behind several

Re: [PATCH 03/17] [APX NDD] Support APX NDD for optimization patterns of add

On Tue, Dec 5, 2023 at 3:29 AM Hongyu Wang wrote: > > From: Kong Lingling > > gcc/ChangeLog: > > * config/i386/i386.md: (addsi_1_zext): Add new alternatives for > NDD and adjust output templates. > (*add_2): Likewise. > (*addsi_2_zext): Likewise. > (*add_3)

[PATCH v2 08/11] aarch64: Generalize writeback ldp/stp patterns

Hi, This is a v2 patch which implements the requested changes from the previous review here: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637642.html the patch was pre-approved with those changes, but this patch additionally makes use of the new aarch64_const_zero_rtx_p predicate in a

Re: [PATCH 05/17] [APX NDD] Support APX NDD for adc insns

On Tue, Dec 5, 2023 at 3:29 AM Hongyu Wang wrote: > > From: Kong Lingling > > Legacy adc patterns are commonly adopted to TImode add, when extending TImode > add to NDD version, operands[0] and operands[1] can be different, so extra > move > should be emitted if those patterns have optimization

Re: [PATCH v3 1/3] libgomp, nvptx: low-latency memory allocator

Hi Andrew, I now looked at the whole series - and the series LGTM, except for some testcase issues, as outlined below. First, I notice that there is no call to: omp_destroy_allocator (gpu_lowlat); While it might make sense to leave some of the testcases without that call for testing purpose,

Re: [PATCH] i386: Fix -fcf-protection -Os ICE due to movabsq peephole2 [PR112845]

On Tue, Dec 5, 2023 at 8:28 AM Jakub Jelinek wrote: > > Hi! > > The following testcase ICEs in the movabsq $(i32 << shift), r64 peephole2 > I've added a while back to use smaller code than movabsq if possible. > If i32 is 0xfa1e0ff3 and shift is not divisible by 8, then it creates > an invalid ins

[PATCH 0/2] RISC-V: Add intrinsics for Bitmanip and Scalar Crypto extensions.

It's a little patch add just provides a mapping from the RV intrinsics to the builtin names within GCC. Liao Shihua (2): Add C intrinsics of Scalar Crypto Extension Add C intrinsics of Bitmanip Extension gcc/config.gcc| 2 +- gcc/config/riscv/riscv-built

[PATCH 1/2] RISC-V: Add C intrinsics of Scalar Crypto Extension

This patch adds C intrinsics for Scalar Crypto Extension. gcc/ChangeLog: * config.gcc: Add riscv_crypto.h. * config/riscv/riscv_crypto.h: New file. gcc/testsuite/ChangeLog: * gcc.target/riscv/scalar_crypto_intrinsic-1.c: New test. * gcc.target/riscv/scalar_cryp

[PATCH 2/2] RISC-V: Add C intrinsics of Bitmanip Extension

This patch adds C intrinsics for Bitmanip Extension. RISCV_BUILTIN_NO_PREFIX is a new riscv_builtin_description like RISCV_BUILTIN. But it uses CODE_FOR_##INSN rather than CODE_FOR_riscv_##INSN. Some of the instructions are different to spec, see https://github.com/riscv-non-isa/riscv-c-api-doc/

Re: [PATCH] expmed: Perform mask extraction via QImode [PR112773].

On Tue, 5 Dec 2023, Robin Dapp wrote: > > But how do we know BImode fits in QImode? > > I was kind of hoping that a "bit" always fits in a "byte"/unit > but yeah, I guess we don't always know :/ But the "bit" is of constant size, so we could choose a fitting mode? > > I think the issue is more

Re: [PATCH] driver: Fix bootstrap with --enable-default-pie

On Tue, 5 Dec 2023, Jakub Jelinek wrote: > Hi! > > On IRC Iain mentioned bootstrap is broken for him presumably since > r14-5791 -fhardened addition. I think it is only a problem with > --enable-default-pie when the case OPT_pie: wants to fall through > into case OPT_r: and warns. > Before the p

Re: [gcc15] nested functions in C

On 2023-12-04 16:31, Martin Uecker wrote: If (assuming from them being called lambdas) they are primarily for small functions without side-effects then it's already a significantly stronger specification than what we have right now with C nested functions. That would end up enforcing what you de

Re: [RFC PATCH 1/1] nix: add a simple flake nix shell

On 12/5/23 5:35 AM, Vincenzo Palazzo wrote: >>> I see, but to me, this do not look like a distro build procedure, >>> because you can use >>> with any kind of system (OSX/UNIX) by using nix. >> >> But you can do the same with various other distro build procedures too? >> e.g. Gentoo Prefix allows y

Re: [PATCH v1] LoongArch: Modify the check type of the vector builtin function.

On Tue, 2023-12-05 at 17:21 +0800, chenxiaolong wrote: > According to your suggestion, the check of the built-in function was > modifiedin the simd_correctness_check.h file, and the types of the actual > parameters > of the built-in function were inconsistent with those of the formal > parameter

[PATCH] RISC-V: Block VLSmodes according to TARGET_MAX_LMUL and BITS_PER_RISCV_VECTOR

This patch fixes ICE mentioned on PR112851 and PR112852. Actually these ICEs happens many times in full coverage testing. The ICE happens on: bug.c:84:1: internal compiler error: in partial_subreg_p, at rtl.h:3187 84 | } | ^ 0x11a7271 partial_subreg_p(machine_mode, machine_mode)

[PATCH] tree-optimization/112856 - fix LC SSA after loop header copying

When loop header copying unloops loops we have to possibly fixup LC SSA. I've take the opportunity to streamline the unloop_loops API, removing the use of a ivcanon local global variable. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/109689 PR

[PATCH] middle-end/112830 - avoid gimplifying non-default addr-space assign to memcpy

The following avoids turning aggregate copy involving non-default address-spaces to memcpy since that is not prepared for that. GIMPLE verification no longer accepts WITH_SIZE_EXPR in aggregate copies, the following re-allows that for the RHS. I also needed to adjust one assert in DCE. get_memor

Re: [PATCH] middle-end/112830 - avoid gimplifying non-default addr-space assign to memcpy

On Tue, Dec 05, 2023 at 02:11:27PM +0100, Richard Biener wrote: > The following avoids turning aggregate copy involving non-default > address-spaces to memcpy since that is not prepared for that. > > GIMPLE verification no longer accepts WITH_SIZE_EXPR in aggregate > copies, the following re-allow

Re: [PATCH] libgfortran: Fix -Wincompatible-pointer-types errors

Hi all, the patch submission looks confusing as the context is a bit unclear (aarch64 having two integer types?) and the slightly unmotivated 'long' change (as explained in later emails: used as trick to find all locations that should be changed and not being part of actually proposed patch). Ho

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

Hello Kewen: On 04/12/23 7:31 am, Kewen.Lin wrote: > Hi Ajit, > > on 2023/12/1 17:10, Ajit Agarwal wrote: >> Hello Kewen: >> >> On 24/11/23 3:01 pm, Kewen.Lin wrote: >>> Hi Ajit, >>> >>> Don't forget to CC David (CC-ed) :), some comments are inlined below. >>> >>> on 2023/10/8 03:04, Ajit Agarwal

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

On Tue, Dec 5, 2023 at 1:05 PM Liao Shihua wrote: > > > It's a little patch add just provides a mapping from the RV intrinsic to the > builtin > names within GCC. Thanks for working on this! I checked with ./contrib/check_GNU_style, which found a two issues: * Trailing whitespace (most likely c

[PATCH] ipa/92606 - IPA ICF merging variables in different address-space

The following aovids merging variables that are put in different address-spaces. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR ipa/92606 * ipa-icf.cc (sem_variable::equals_wpa): Compare address-spaces. --- gcc/ipa-icf.cc | 4 1 file changed, 4 insertions(+)

[PATCH] sanitizer/111736 - skip ASAN for globals in alternate address-space

Bootstrapped and tested on x86_64-unknown-linux-gnu, OK? Thanks, Richard. PR sanitizer/111736 * asan.cc (asan_protect_global): Do not protect globals in non-generic address-space. --- gcc/asan.cc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/gcc/asan.cc b/gcc/asan

[ARC PATCH] Add *extvsi_n_0 define_insn_and_split for PR 110717.

This patch improves the code generated for bitfield sign extensions on ARC cpus without a barrel shifter. Compiling the following test case: int foo(int x) { return (x<<27)>>27; } with -O2 -mcpu=em, generates two loops: foo:mov lp_count,27 lp 2f add r0,r0,r0

Re: [PATCH] sanitizer/111736 - skip ASAN for globals in alternate address-space

On Tue, Dec 05, 2023 at 02:55:05PM +0100, Richard Biener wrote: > Bootstrapped and tested on x86_64-unknown-linux-gnu, OK? > > Thanks, > Richard. > > PR sanitizer/111736 > * asan.cc (asan_protect_global): Do not protect globals > in non-generic address-space. Ok. > diff --git

[PATCH] middle-end/112860 - -fgimple can skip ISEL

The following makes sure we don't skip ISEL. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. Will push, Richard. PR middle-end/112860 * passes.cc (should_skip_pass_p): Do not skip ISEL. --- gcc/passes.cc | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc

[PATCH v5] aarch64: New RTL optimization pass avoid-store-forwarding.

This is an RTL pass that detects store forwarding from stores to larger loads (load pairs). This optimization is SPEC2017-driven and was found to be beneficial for some benchmarks, through testing on ampere1/ampere1a machines. For example, it can transform cases like str d5, [sp, #320] fmul d

Re: [PATCH v4] aarch64: New RTL optimization pass avoid-store-forwarding.

Hi Richard, the patch is working correctly with the four lines deleted and "get_addr" on "load_mem" inlined on "rtx_equal_for_cselib_1" call. Also changed store_info to str_info to avoid a warning of duplicate names on bootstrap (one definition rule). Rebased on top of your sme2 changes and submi

Re: [PATCH] RISC-V: Block VLSmodes according to TARGET_MAX_LMUL and BITS_PER_RISCV_VECTOR

Yes, makes sense. Just one clarifying question. > +{ > + if (GET_MODE_CLASS (vls_mode) != MODE_VECTOR_BOOL > + && !ordered_p (TARGET_MAX_LMUL * BITS_PER_RISCV_VECTOR, > + GET_MODE_PRECISION (vls_mode))) > + /* We enable VLS modes which are aligned with TARGE

Re: [PATCH] c++: Fix parsing [[]][[]];

On Tue, Dec 05, 2023 at 08:51:51AM +0100, Jakub Jelinek wrote: > Hi! > > When working on the previous patch I put [[]] [[]] asm (""); into a > testcase, but was surprised it wasn't parsed. By wasn't parsed you mean we gave an error, right? I only see an error with block-scope [[]] [[]];. > The

  1   2   3   >