Re: [PATCH v6 0/4] P1689R5 support

On Fri, Jun 16, 2023 at 3:49 PM Ben Boeckel wrote: > > On Thu, Jun 08, 2023 at 21:59:13 +0400, Maxim Kuvyrkov wrote: > > This patch series causes ICEs on arm-linux-gnueabihf. Would you > > please investigate? Please let me know if you need any in reproducing > > these. > > Finally back at it. I

Re: [PATCH] simplify-rtx: Simplify VEC_CONCAT of SUBREG and VEC_CONCAT from same vector

On 6/16/23 03:06, Kyrylo Tkachov via Gcc-patches wrote: Hi all, In the testcase for this patch we try to vec_concat the lowpart and highpart of a vector, but the lowpart is expressed as a subreg. simplify-rtx.cc does not recognise this and combine ends up trying to match: Trying 7 -> 8:

Re: [PATCH v3] RISC-V: Add autovec FP binary operations.

On 6/16/23 07:43, juzhe.zhong wrote: lgtm ACK for the trunk. jeff

Re: [PATCH v3] RISC-V: Add autovec FP unary operations.

On 6/16/23 07:44, juzhe.zhong wrote: lgtm Which is good enough for me. Ok for the trunk. jeff

Re: [PATCH] RISC-V: Add autovec FP unary operations.

On 6/14/23 15:15, 钟居哲 wrote: Hi, Jeff.  Thanks for quick approval. When I reviewed the patch: (define_expand "2"   [(set (match_operand:VF 0 "register_operand")     (any_float_unop_nofrm:VF      (match_operand:VF 1 "register_operand")))] "TARGET_VECTOR" {   insn_code icode = code_for_pred

Re: [PATCH v2] RISC-V: Implement vec_set and vec_extract.

On 6/16/23 07:55, 钟居哲 wrote: LGTM OK for the trunk. Sorry for the delays. jeff

RE: [PATCH v2] RISC-V: Bugfix for RVV integer reduction in ZVE32/64.

Committed, thanks Jeff. Pan -Original Message- From: Jeff Law Sent: Friday, June 16, 2023 11:56 PM To: juzhe.zh...@rivai.ai; Li, Pan2 ; gcc-patches Cc: Robin Dapp ; Wang, Yanzhang ; kito.cheng Subject: Re: [PATCH v2] RISC-V: Bugfix for RVV integer reduction in ZVE32/64. On 6/16/2

RE: [PATCH] RISC-V: Fix VL operand bug in VSETVL PASS[PR110264]

Committed, thanks Jeff. Pan -Original Message- From: Gcc-patches On Behalf Of Jeff Law via Gcc-patches Sent: Friday, June 16, 2023 11:53 PM To: Juzhe-Zhong ; gcc-patches@gcc.gnu.org Cc: kito.ch...@gmail.com; kito.ch...@sifive.com; pal...@dabbelt.com; pal...@rivosinc.com; rdapp@gmai

Re: [PATCH] tree-optimization/110278 - uns < (typeof uns)(uns != 0) is always false

On Fri, Jun 16, 2023 at 4:14 PM Andrew Pinski wrote: > > On Fri, Jun 16, 2023 at 4:46 AM Richard Biener via Gcc-patches > wrote: > > > > The following adds two patterns simplifying comparisons, > > uns < (typeof uns)(uns != 0) is always false and x != (typeof x)(x == 0) > > is always true. > > A

Re: [PATCH v6 0/4] P1689R5 support

On Fri, Jun 16, 2023 at 15:48:59 -0400, Ben Boeckel wrote: > On Thu, Jun 08, 2023 at 21:59:13 +0400, Maxim Kuvyrkov wrote: > > This patch series causes ICEs on arm-linux-gnueabihf. Would you > > please investigate? Please let me know if you need any in reproducing > > these. > > Finally back at

Re: [PATCH] tree-optimization/110278 - uns < (typeof uns)(uns != 0) is always false

On Fri, Jun 16, 2023 at 4:46 AM Richard Biener via Gcc-patches wrote: > > The following adds two patterns simplifying comparisons, > uns < (typeof uns)(uns != 0) is always false and x != (typeof x)(x == 0) > is always true. A few more that should be done (I will file a bug in a few minutes): `x =

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

On Fri, 16 Jun 2023, Qing Zhao via Gcc-patches wrote: > > So for > > > > struct foo { int c; int buf[(struct { int d; }){ .d = .c }]; }; > > > > one knows during parsing that the .d is a designator > > and that .c is not. > > Therefore, the above should be invalid based on this rule since .c i

Re: [committed] libgomp: Fix OMP_TARGET_OFFLOAD=mandatory

Hi Tobias! On 2023-06-16T17:57:10+0200, Tobias Burnus wrote: > Found an order problem caused by my r14-1801-g18c8b56c7d67a9 due to > ordering issues related to the offloading initialization > (gomp_init_targets_once). > > The testsuite did test various ways but only code such paths that > initial

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

> On Jun 16, 2023, at 1:07 PM, Martin Uecker wrote: > > Am Freitag, dem 16.06.2023 um 16:21 + schrieb Joseph Myers: >> On Fri, 16 Jun 2023, Martin Uecker via Gcc-patches wrote: >> Note that no expressions can start with the '.' token at present. As soon as you invent a new kin

[r14-1873 Regression] FAIL: 25_algorithms/set_union/constrained.cc (test for excess errors) on Linux/x86_64

On Linux/x86_64, 6a2e8dcbbd4bab374b27abea375bf7a921047800 is the first bad commit commit 6a2e8dcbbd4bab374b27abea375bf7a921047800 Author: Manolis Tsamis Date: Thu May 25 13:44:41 2023 +0200 cprop_hardreg: Enable propagation of the stack pointer if possible caused FAIL: 25_algorithms/set_

Re: [PATCH v6 0/4] P1689R5 support

On Thu, Jun 08, 2023 at 21:59:13 +0400, Maxim Kuvyrkov wrote: > This patch series causes ICEs on arm-linux-gnueabihf. Would you > please investigate? Please let me know if you need any in reproducing > these. Finally back at it. I tried on aarch64, but wasn't able to reproduce the errors (alas,

Re: [PATCH] ipa-sra: Disable candidates with no known callers (PR 110276)

> Hi, > > In IPA-SRA we use can_be_local_p () predicate rather than just plain > local call graph flag in order to figure out whether the node is a > part of an external API that we cannot change. Although there are > cases where this can allow more transformations, it also means we can > analyze

Re: [PATCH zero-call-used-regs] Add leafy mode for zero-call-used-regs

Hi, Alexandre, > On Jun 16, 2023, at 3:26 AM, Alexandre Oliva wrote: > > Hello, Qing, > > On Oct 27, 2022, Qing Zhao wrote: > > >> On Oct 26, 2022, at 5:29 PM, Alexandre Oliva wrote: >>> I'm sure there are other scenarios i

libgo patch committed: Add benchmarks and examples to test list

In https://go.dev/cl/384695 (https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590289.html) I simplified the code that built lists of benchmarks, examples, and fuzz tests, and managed to break it. This patch corrects the code to once again make the benchmarks available, and to run the example

[PATCH ver 5] rs6000: Add builtins for IEEE 128-bit floating point values

Kewen, GCC maintainers: Version 5, Tested the patch on P9 BE per request. Fixed up test case to get the correct expected values for BE and LE. Fixed typos. Updated the doc/extend.texi to clarify the vector arguments. Changed test file names per request. Moved builtin defs next to related defi

Re: [PATCH ver 4] rs6000: Add builtins for IEEE 128-bit floating point values

On Thu, 2023-06-15 at 14:23 +0800, Kewen.Lin wrote: > Hi Carl, > > on 2023/6/15 04:37, Carl Love wrote: > > Kewen, GCC maintainers: > > > > Version 4, added missing cases for new xxexpqp, xsxexpdp and > > xsxsigqp > > cases to rs6000_expand_builtin. Merged the new define_insn > > definitions > >

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

Am Freitag, dem 16.06.2023 um 16:21 + schrieb Joseph Myers: > On Fri, 16 Jun 2023, Martin Uecker via Gcc-patches wrote: > > > > Note that no expressions can start with the '.' token at present. As > > > soon > > > as you invent a new kind of expression that can start with that token, > > >

Re: [PATCH] builtins: Add support for clang compatible __builtin_{add, sub}c{, l, ll} [PR79173]

> Am 16.06.2023 um 16:34 schrieb Jakub Jelinek : > > Hi! > > While the design of these builtins in clang is questionable, > rather than being say > unsigned __builtin_addc (unsigned, unsigned, bool, bool *) > so that it is clear they add two [0, 0x] range numbers > plus one [0, 1] ran

Re: [PATCH] tree-ssa-math-opts: Fix up uaddc/usubc pattern matching [PR110271]

> Am 16.06.2023 um 16:23 schrieb Jakub Jelinek : > > Hi! > > The following testcase ICEs, because I misremembered what the return value > from match_arith_overflow is. It isn't true if __builtin_*_overflow was > matched, but it is true only in the BIT_NOT_EXPR case if stmt was removed. > >

Re: [PATCH 1/2] go: update usage of TARGET_AIX to TARGET_AIX_OS

On Fri, Jun 16, 2023 at 9:00 AM Paul E. Murphy via Gcc-patches wrote: > > TARGET_AIX is defined to a non-zero value on linux and maybe other > powerpc64le targets. This leads to unexpected behavior such as > dropping the .go_export section when linking a shared library > on linux/powerpc64le. > >

[x86_64 PATCH] Two minor tweaks to ix86_expand_move.

This patch splits out two (independent) minor changes to i386-expand.cc's ix86_expand_move from a larger patch, given that it's better to review and commit these independent pieces separately from a more complex patch. The first change is to test for CONST_WIDE_INT_P before calling ix86_convert_c

Re: [wwwdocs] gcc-14/changes.htm - Offloading: -lm/-lgfortran is autolinked

On Fri, 16 Jun 2023, Tobias Burnus wrote: > Thomas recently improved the offload experience by avoiding to use, e.g. > > gfortran -O3 -fopenmp qcd.f90 -lblas -foffload-options="-lgfortran -lm" > > as libm and libgfortran now automatically get linked as 'gfortran' links > -lgfortran and -lm on t

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

On Fri, 16 Jun 2023, Martin Uecker via Gcc-patches wrote: > > Note that no expressions can start with the '.' token at present. As soon > > as you invent a new kind of expression that can start with that token, you > > have syntactic ambiguity. > > > > struct s1 { int c; char a[(struct s2 { in

[PATCH] ipa-sra: Disable candidates with no known callers (PR 110276)

Hi, In IPA-SRA we use can_be_local_p () predicate rather than just plain local call graph flag in order to figure out whether the node is a part of an external API that we cannot change. Although there are cases where this can allow more transformations, it also means we can analyze functions whi

[patch] OpenMP (C/C++): Keep pointer value of unmapped ptr with default mapping [PR110270]

This fixes an issue related to OpenMP C/C++'s default mapping of pointer variables. (That's 'defaultmap(default:pointer)' – which is possibly surprisingly *not* the same as 'defaultmap(firstprivate:pointer)'). Namely, OpenMP supports the following: int *ptr = malloc(sizeof(int)*5); #pragma omp

[PATCH] Regenerate some autotools generated files (Was: Re: [PATCH v3] configure: Implement --enable-host-pie)

On Fri, Jun 16 2023, Marek Polacek wrote: > On Fri, Jun 16, 2023 at 12:26:23PM +0200, Martin Jambor wrote: >> Hello, >> >> On Thu, Jun 15 2023, Marek Polacek via Gcc-patches wrote: >> > On Mon, Jun 05, 2023 at 09:06:43PM -0600, Jeff Law wrote: >> >> >> >> >> >> On 6/5/23 10:18, Marek Polacek via

[PATCH 1/2] go: update usage of TARGET_AIX to TARGET_AIX_OS

TARGET_AIX is defined to a non-zero value on linux and maybe other powerpc64le targets. This leads to unexpected behavior such as dropping the .go_export section when linking a shared library on linux/powerpc64le. Instead, use TARGET_AIX_OS to toggle AIX specific behavior. Fixes golang/go#60798.

[PATCH 2/2] rust: update usage of TARGET_AIX to TARGET_AIX_OS

This was noticed when fixing the gccgo usage of the macro, the rust usage is very similar. TARGET_AIX is defined as a non-zero value on linux/powerpc64le which may cause unexpected behavior. TARGET_AIX_OS should be used to toggle AIX specific behavior. gcc/rust/ChangeLog: * rust-object-

[committed] libgomp: Fix OMP_TARGET_OFFLOAD=mandatory

Found an order problem caused by my r14-1801-g18c8b56c7d67a9 due to ordering issues related to the offloading initialization (gomp_init_targets_once). The testsuite did test various ways but only code such paths that initialized the library before ... Committed as Rev. r14-1893-g8216ca85037be9.

Re: [PATCH v2] RISC-V: Bugfix for RVV integer reduction in ZVE32/64.

On 6/16/23 02:10, juzhe.zh...@rivai.ai wrote: LGTM. Thanks for fix this bug. Let's wait for Jeff's final approve. OK. jeff

Re: [PATCH] RISC-V: Fix VL operand bug in VSETVL PASS[PR110264]

On 6/16/23 02:02, Juzhe-Zhong wrote: This patch fixes this issue happens on both GCC-13 and GCC-14. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110264 The testcase is too big and I failed to reduce it so I didn't append test into this patch. This patch should not only land into GCC-14 but a

[pushed] [RA] [PR110215] Ignore conflicts for some pseudos from insns throwing a final exception

The following patch solves https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110215 The patch was successfully tested and bootstrapped on x86-64, aarch64, and ppc64le. It is difficult to make a stable test for the PR.  So there is not test in the patch. commit 154c69039571c66b3a6d16ecfa9e6ff229

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

> On Jun 16, 2023, at 3:21 AM, Martin Uecker wrote: > > Am Donnerstag, dem 15.06.2023 um 16:55 + schrieb Joseph Myers: >> On Thu, 15 Jun 2023, Qing Zhao via Gcc-patches wrote: >> > ... >>> 1. Update the routine “c_parser_postfix_expression” (is this the right >>> place? ) to accept the ne

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

> On Jun 15, 2023, at 6:48 PM, Joseph Myers wrote: > > On Thu, 15 Jun 2023, Qing Zhao via Gcc-patches wrote: > >> B. The argument of the new attribute “counted_by” is an identifier that can >> be >> accepted by “c_parser_attribute_arguments”: >> >> struct trailing_array_B { >> Int count; >>

[PATCH] builtins: Add support for clang compatible __builtin_{add,sub}c{,l,ll} [PR79173]

Hi! While the design of these builtins in clang is questionable, rather than being say unsigned __builtin_addc (unsigned, unsigned, bool, bool *) so that it is clear they add two [0, 0x] range numbers plus one [0, 1] range carry in and give [0, 0x] range return plus [0, 1] range ca

Re: [PATCH v3] c++: Accept elaborated-enum-base with pedwarn

On 16/06/2023 09:07, Jason Merrill wrote: > On 6/16/23 07:58, Alex Coplan wrote: > > Hi, > > > > This is a v3 patch addressing feedback for: > > https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621714.html > > > > The only change since the previous version is that the new option is > > documen

[PATCH] tree-ssa-math-opts: Fix up uaddc/usubc pattern matching [PR110271]

Hi! The following testcase ICEs, because I misremembered what the return value from match_arith_overflow is. It isn't true if __builtin_*_overflow was matched, but it is true only in the BIT_NOT_EXPR case if stmt was removed. So, if match_arith_overflow matches something, gsi_stmt (gsi) will not

Re: [PATCH v2] RISC-V: Implement vec_set and vec_extract.

LGTM juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-06-16 21:41 To: Jeff Law; gcc-patches; palmer; Kito Cheng; juzhe.zh...@rivai.ai CC: rdapp.gcc Subject: [PATCH v2] RISC-V: Implement vec_set and vec_extract. Hi, with the recent changes that we also pass the return value via stack this is

Re: [PATCH] c++: diagnostic ICE b/c of empty TPARMS_PRIMARY_TEMPLATE [PR109655]

On 6/9/23 11:19, Patrick Palka wrote: When defining a previously declared class template, we neglect to set TPARMS_PRIMARY_TEMPLATE for the in-scope template parameters, which the class members go on to inherit, and so the members' DECL_TEMPLATE_PARMS will have empty TPARMS_PRIMARY_TEMPLATE at th

[wwwdocs] gcc-14/changes.htm - Offloading: -lm/-lgfortran is autolinked

Thomas recently improved the offload experience by avoiding to use, e.g. gfortran -O3 -fopenmp qcd.f90 -lblas -foffload-options="-lgfortran -lm" as libm and libgfortran now automatically get linked as 'gfortran' links -lgfortran and -lm on the host (only those libraries, not others). Thus, the

[PATCH v2] RISC-V: Implement vec_set and vec_extract.

Hi, with the recent changes that we also pass the return value via stack this is can go forward now. Changes in V2: - Remove redundant force_reg. - Change target selectors to those introduced in the binop patch. Regards Robin This implements the vec_set and vec_extract patterns for integer

[PATCH v3] RISC-V: Add autovec FP unary operations.

Hi, changes from V2: - No longer dependent on testsuite changes. - Add zvfhmin-1.c unary test cases. Regards Robin This patch adds floating-point autovec expanders for vfneg, vfabs as well as vfsqrt and the accompanying tests. Similary to the binop tests, there are flavors for zvfh now. gcc

[PATCH v3] RISC-V: Add autovec FP binary operations.

Hi, changes in v3: - No longer "dependent" on testsuite changes. Just the zvfh run testcases use riscv_zvfh_hw, i.e. require that we can compile, link the code as well as execute the resulting binary. - Renamed rounding modes (floating_point_rounding_mode feels a bit long-winded but well...)

RE: [x86 PATCH] Convert ptestz of pandn into ptestc.

Hi Uros, Here's an updated version of this patch incorporating your comments. It uses emit_insn (target, const1_rtx), bt_comparison operator to combine the sete/setne to setc/setnc, and je/jne to jc/jnc patterns, uses scan-assembler-times in the test cases, and cleans up the silly cut'n'paste issu

Re: [PATCH v2] Add MinGW option -mcrtdll= for choosing C RunTime DLL library

On 6/14/23 16:09, Pali Rohár wrote: It adjust preprocess, compile and link flags, which allows to change default -lmsvcrt library by another provided by MinGW runtime. gcc/ * config/i386/mingw-w64.h (CPP_SPEC): Adjust for -mcrtdll=. (REAL_LIBGCC_SPEC): New define. * config/i386

[PATCH][4/5] aarch64: [US]Q(R)SHR(U)N2 refactoring

This patch is large in lines of code, but it is a fairly regular extension of the first patch as it converts the high-half patterns to standard RTL codes in the same fashion as the first patch did for the low-half ones. This now allows us to remove the unspec codes for these instructions as there a

Re: [PATCH v3] c++: Accept elaborated-enum-base with pedwarn

On 6/16/23 07:58, Alex Coplan wrote: Hi, This is a v3 patch addressing feedback for: https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621714.html The only change since the previous version is that the new option is documented in invoke.texi (and the description in c.opt was shortened as requ

[PATCH][0/5][committed] aarch64: Reimplement [US]Q(R)SHR(U)N(2) patterns with standard RTL codes

Hi all, This patch series reimplements the MD patterns for the instructions that perform narrowing right shifts with optional rounding and saturation using standard RTL codes rather than unspecs. This includes the scalar forms and the *2 forms that write to the high half of the result vector. Thi

[PATCH][2/5] aarch64: [US]Q(R)SHR(U)N scalar forms refactoring

Some instructions from the previous patch have scalar forms: SQSHRN,SQRSHRN,UQSHRN,UQRSHRN,SQSHRUN,SQRSHRUN. This patch converts the patterns for these to use standard RTL codes. Their MD patterns deviate slightly from the vector forms mostly due to things like operands being scalar rather than vec

[PATCH][5/5] aarch64: Handle ASHIFTRT in patterns for shrn2

Similar to the low-half patterns, we want to match both ashiftrt and lshiftrt with the truncate for SHRN2. We reuse the SHIFTRT iterator and the AARCH64_VALID_SHRN_OP check to help, but because we expand the high-half patterns by their gen_* names we need to disambiguate all the different trunc+sh

[PATCH][3/5] aarch64: Add ASHIFTRT handling for shrn pattern

The first patch in the series has some fallout in the testsuite, particularly gcc.target/aarch64/shrn-combine-2.c. Our previous patterns for SHRN matched both (truncate (ashiftrt (x) (N))) and (truncate (lshiftrt (x) (N)) as these are equivalent for the shift amounts involved. In our refactoring, h

[PATCH][1/5] aarch64: Reimplement [US]Q(R)SHR(U)N patterns with RTL codes

This patch reimplements the MD patterns for the instructions that perform narrowing right shifts with optional rounding and saturation using standard RTL codes rather than unspecs. There are four groups of patterns involved: * Simple narrowing shifts with optional signed or unsigned truncation: S

Re: [PATCH v2] RISC-V: Add autovec FP binary operations.

> Why do we need '-ffast-math' with the tests? Normally we would use the COND_ADD to mask out possibly trapping vector elements and the likes but COND_ADD works with normal vector masking. What we currently have is no masking but the LEN_LOAD/LEN_STORE machinery i.e. length-controlled loops. Ther

[PATCH] tree-optimization/110243 - kill off IVOPTs split_offset

IVOPTs has strip_offset which suffers from the same issues regarding integer overflow that split_constant_offset did but the latter was fixed quite some time ago. The following implements strip_offset in terms of split_constant_offset, removing the redundant and incorrect implementation. The impl

Re: [PATCH v3] configure: Implement --enable-host-pie

On Fri, Jun 16, 2023 at 12:26:23PM +0200, Martin Jambor wrote: > Hello, > > On Thu, Jun 15 2023, Marek Polacek via Gcc-patches wrote: > > On Mon, Jun 05, 2023 at 09:06:43PM -0600, Jeff Law wrote: > >> > >> > >> On 6/5/23 10:18, Marek Polacek via Gcc-patches wrote: > >> > Ping. Anyone have any f

Re: [PATCH] libatomic: Enable lock-free 128-bit atomics on AArch64 [PR110061]

ping From: Wilco Dijkstra Sent: 02 June 2023 18:28 To: GCC Patches Cc: Richard Sandiford ; Kyrylo Tkachov Subject: [PATCH] libatomic: Enable lock-free 128-bit atomics on AArch64 [PR110061]   Enable lock-free 128-bit atomics on AArch64.  This is backwards compatible with existing binaries, g

[PATCH] [contrib] validate_failures.py: Don't consider summary line in wrong place

When parsing a summary or manifest file, if we're not either after a tool line (e.g. "=== gdb tests ===") or before a summary line (e.g., "=== gdb Summary ===") then the current line can't be a valid result line so ignore it. This addresses a problem we're seeing when running the GDB testsuite in

[PATCH v3] c++: Accept elaborated-enum-base with pedwarn

Hi, This is a v3 patch addressing feedback for: https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621714.html The only change since the previous version is that the new option is documented in invoke.texi (and the description in c.opt was shortened as requested). -- macOS SDK headers usin

RE: [PATCH v1] RISC-V: Fix one warning of maybe-uninitialized in riscv-vsetvl.cc

Committed, thanks Robin. Pan -Original Message- From: Robin Dapp Sent: Friday, June 16, 2023 7:41 PM To: Li, Pan2 ; gcc-patches@gcc.gnu.org Cc: rdapp@gmail.com; juzhe.zh...@rivai.ai; jeffreya...@gmail.com; Wang, Yanzhang ; kito.ch...@gmail.com Subject: Re: [PATCH v1] RISC-V: Fix on

[PATCH] tree-optimization/110278 - uns < (typeof uns)(uns != 0) is always false

The following adds two patterns simplifying comparisons, uns < (typeof uns)(uns != 0) is always false and x != (typeof x)(x == 0) is always true. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/110278 * match.pd (uns < (typeof uns)(uns != 0) -> fa

Re: [PATCH v1] RISC-V: Fix one warning of maybe-uninitialized in riscv-vsetvl.cc

> This patch would like to fix one maybe-uninitialized warning. Aka: > > riscv-vsetvl.cc:4354:3: error: 'vsetvl_rinsn' may be used uninitialized > [-Werror=maybe-uninitialized] > > Signed-off-by: Pan Li IMHO obvious enough that it doesn't need a maintainer's OK, so go ahead. We should make su

RE: [PATCH V2] RISC-V: Rework Phase 5 && Phase 6 of VSETVL PASS

Sorry for inconvenient, file one PATCH for this as below. https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621980.html Pan -Original Message- From: Andreas Schwab Sent: Friday, June 16, 2023 6:55 PM To: juzhe.zh...@rivai.ai Cc: gcc-patches@gcc.gnu.org; kito.ch...@gmail.com; kito.ch.

[PATCH v1] RISC-V: Fix one warning of maybe-uninitialized in riscv-vsetvl.cc

From: Pan Li This patch would like to fix one maybe-uninitialized warning. Aka: riscv-vsetvl.cc:4354:3: error: 'vsetvl_rinsn' may be used uninitialized [-Werror=maybe-uninitialized] Signed-off-by: Pan Li gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (pass_vsetvl::global_elim

Re: [PATCH V2] RISC-V: Rework Phase 5 && Phase 6 of VSETVL PASS

Why didn't you test that?? ../../gcc/config/riscv/riscv-vsetvl.cc: In member function 'bool pass_vsetvl::global_eliminate_vsetvl_insn(const rtl_ssa::bb_info*) const': ../../gcc/config/riscv/riscv-vsetvl.cc:4354:3: error: 'vsetvl_rinsn' may be used uninitialized [-Werror=maybe-uninitialized] 435

Re: Re: [PATCH V4] VECT: Support LEN_MASK_{LOAD,STORE} ifn && optabs

Address comments and send V6. juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-06-16 18:10 To: juzhe.zh...@rivai.ai; gcc-patches CC: rdapp.gcc; rguenther; richard.sandiford Subject: Re: [PATCH V4] VECT: Support LEN_MASK_{LOAD,STORE} ifn && optabs > <= (operand 2 + operand 4) are used." S

[PATCH V6] VECT: Support LEN_MASK_{LOAD,STORE} ifn && optabs

From: Ju-Zhe Zhong This patch bootstrap pass on X86, ok for trunk ? Accoding to comments from Richi, split the first patch to add ifn && optabs of LEN_MASK_{LOAD,STORE} only, we don't apply them into vectorizer in this patch. And also add BIAS argument for possible s390's future use. The descri

Re: [PATCH v3] configure: Implement --enable-host-pie

Hello, On Thu, Jun 15 2023, Marek Polacek via Gcc-patches wrote: > On Mon, Jun 05, 2023 at 09:06:43PM -0600, Jeff Law wrote: >> >> >> On 6/5/23 10:18, Marek Polacek via Gcc-patches wrote: >> > Ping. Anyone have any further comments? >> Given this was approved before, but got reverted due to iss

[Ping] Re: [PATCH] avr: Set param_min_pagesize to 0 [PR105523]

On Fri, 2023-06-02 at 12:32 +0530, Senthil Kumar Selvaraj wrote: > On Mon, 2023-05-22 at 14:05 +0200, Richard Biener wrote: > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > > content is safe > > > > On Fri, May 19, 2023 at 7:58 AM wrote: > > > On 26/04/23, 5:51 PM

Re: [PATCH V3 1/4] rs6000: build constant via li;rotldi

Hi! On Fri, Jun 16, 2023 at 04:34:12PM +0800, Jiufu Guo wrote: > +/* Check if value C can be built by 2 instructions: one is 'li', another is > + rotldi. > + > + If so, *SHIFT is set to the shift operand of rotldi(rldicl), and *MASK > + is set to -1, and return true. Return false otherwise.

Re: [PATCH V4] VECT: Support LEN_MASK_{LOAD,STORE} ifn && optabs

> <= (operand 2 + operand 4) are used." Sorry it's really minor (and my mistake) but it should be < and not <=, right? Mask index 0 is inactive when the length is 0. > +Perform a masked store (operand 2 + operand 4) Even more minor but as mentioned the "of" is still missing ;) Same with the

Re: Re: [PATCH V4] VECT: Support LEN_MASK_{LOAD,STORE} ifn && optabs

Thanks Robin. I have sent V5 for future merge convenience. I didn't change len_load/len_store description since I think it should be another separate patch. This patch is adding len_maskload/len_maskstore. I will wait for Richard S the final comments. juzhe.zh...@rivai.ai From: Robin Dapp D

[PATCH V5] VECT: Support LEN_MASK_{LOAD,STORE} ifn && optabs

From: Ju-Zhe Zhong This patch bootstrap pass on X86, ok for trunk ? Accoding to comments from Richi, split the first patch to add ifn && optabs of LEN_MASK_{LOAD,STORE} only, we don't apply them into vectorizer in this patch. And also add BIAS argument for possible s390's future use. The descri

Re: [PATCH V4] VECT: Support LEN_MASK_{LOAD,STORE} ifn && optabs

Hi Juzhe, > +@cindex @code{len_maskload@var{m}@var{n}} instruction pattern > +@item @samp{len_maskload@var{m}@var{n}} > +Perform a masked load (operand 2 - operand 4) elements from vector memory > +operand 1 into vector register operand 0, setting the other elements of > +operand 0 to undefined va

Re: [PATCH, OpenACC 2.7] Implement host_data must have use_device clause requirement

Hi Chung-Lin! On 2023-06-06T23:10:37+0800, Chung-Lin Tang wrote: > this patch implements the OpenACC 2.7 change requiring the host_data construct > to have at least one use_device clause. Thanks! > This patch started out with a simple check during gimplify (much smaller > patch), Heh, thanks

Re: Re: [PATCH V4] VECT: Support LEN_MASK_{LOAD,STORE} ifn && optabs

Thanks a lot! I will wait for Richard final approve. juzhe.zh...@rivai.ai From: Richard Biener Date: 2023-06-16 17:04 To: Ju-Zhe Zhong CC: gcc-patches; richard.sandiford; rdapp.gcc Subject: Re: [PATCH V4] VECT: Support LEN_MASK_{LOAD,STORE} ifn && optabs On Thu, 15 Jun 2023, juzhe.zh...@rivai.

[PATCH] simplify-rtx: Simplify VEC_CONCAT of SUBREG and VEC_CONCAT from same vector

Hi all, In the testcase for this patch we try to vec_concat the lowpart and highpart of a vector, but the lowpart is expressed as a subreg. simplify-rtx.cc does not recognise this and combine ends up trying to match: Trying 7 -> 8: 7: r93:V2SI=vec_select(r95:V4SI,parallel) 8: r97:V4SI=vec

Re: [PATCH V4] VECT: Support LEN_MASK_{LOAD,STORE} ifn && optabs

On Thu, 15 Jun 2023, juzhe.zh...@rivai.ai wrote: > From: Ju-Zhe Zhong > > This patch bootstrap pass on X86, ok for trunk ? OK with me, please give Richard S. a chance to comment before pushing. Thanks, Richard. > Accoding to comments from Richi, split the first patch to add ifn && optabs > of

[PATCH 2/2][v2] AVX512 fully masked vectorization

Compared to v1 this drops the first patch of the series which inlined vect_get_max_nscalars_per_iter. I was able to simplify this final patch to no longer require a hash-map of rgroup_controls but can re-use the existing vector which makes the function meaningful (although unused) for AVX512 as

[PATCH] tree-optimization/110279- Check for nested FMA chains in reassoc

This patch is to fix the regressions found in SPEC2017 fprate cases on aarch64. 1. Reused code in pass widening_mul to check for nested FMA chains (those connected by MULT_EXPRs), since re-writing to parallel generates worse codes. 2. Avoid re-arrange to produce less FMA chains that can be slo

Re: [PATCH] Check SCALAR_INT_MODE_P in try_const_anchors

On Fri, 16 Jun 2023, Jiufu Guo wrote: > Hi, > > The const_anchor in cse.cc supports integer constants only. > There is a "gcc_assert (SCALAR_INT_MODE_P (mode))" in > try_const_anchors. > > In the latest code, some non-integer modes are used with const int. > For examples: > "set (mem/c:BLK (xx)

Re: [PATCH v5] MIPS: Add speculation_barrier support

On Fri, 2023-06-16 at 15:53 +0800, YunQiang Su wrote: > Ohh, sorry. I forget it. I commented there. > I have no permission to close this bug report. Can you help to close > it? Modify the email address of your Bugzilla account to your @gcc.gnu.org address, then you should be able to close it. --

[PATCH V3 1/4] rs6000: build constant via li;rotldi

Hi, If a constant is possible to be rotated to/from a positive or negative value from "li", then "li;rotldi" can be used to build the constant. Compare with the previous version, those one-line abstraction codes are removed. https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621001.html Bootstr

[PATCH] tree-optimization/110269 - restore missed condition folding

The following makes sure we optimize x != 0 using range info via tree_expr_nonzero_p via match.pd. Bootstrapped and tested on x86_64-unknown-linux-gnu. This causes FAIL: gcc.dg/tree-ssa/pr103257-1.c scan-tree-dump-times optimized "link_error" 0 because we now improve early folding the followin

RE: [PATCH v2] RISC-V: Bugfix for RVV integer reduction in ZVE32/64.

Thanks Juzhe for reviewing, will take care of the FP and widen part soon. Pan From: juzhe.zh...@rivai.ai Sent: Friday, June 16, 2023 4:11 PM To: Li, Pan2 ; gcc-patches Cc: Robin Dapp ; jeffreyalaw ; Li, Pan2 ; Wang, Yanzhang ; kito.cheng Subject: Re: [PATCH v2] RISC-V: Bugfix for RVV integer

[PATCH] Check SCALAR_INT_MODE_P in try_const_anchors

Hi, The const_anchor in cse.cc supports integer constants only. There is a "gcc_assert (SCALAR_INT_MODE_P (mode))" in try_const_anchors. In the latest code, some non-integer modes are used with const int. For examples: "set (mem/c:BLK (xx) (const_int 0 [0])" occur in md files of rs6000, i386, arm

Re: [PATCH v2] RISC-V: Bugfix for RVV integer reduction in ZVE32/64.

LGTM. Thanks for fix this bug. Let's wait for Jeff's final approve. Thanks. juzhe.zh...@rivai.ai From: pan2.li Date: 2023-06-16 16:09 To: gcc-patches CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng Subject: [PATCH v2] RISC-V: Bugfix for RVV integer reduction in ZVE3

[PATCH v2] RISC-V: Bugfix for RVV integer reduction in ZVE32/64.

From: Pan Li The rvv integer reduction has 3 different patterns for zve128+, zve64 and zve32. They take the same iterator with different attributions. However, we need the generated function code_for_reduc (code, mode1, mode2). The implementation of code_for_reduc may look like below. code_for_r

Re: [PATCH] mips: Fix overaligned function arguments [PR109435]

Jovan Dmitrovic 于2023年6月7日周三 18:29写道： > > I see what you mean now, so I've made adjustment in order for testcase to work > on assembly. Following is the updated patch. > > Regards, > Jovan > > From 2744357b5232c61bf1f780c4915d47b19d71f993 Mon Sep 17 00:00:00 2001 > From: Jovan Dmitrovic > Date: F

Re: [PATCH] Introduce hardbool attribute for C

On Jun 16, 2023, Thomas Koenig wrote: > So, such a type would be incompatible with vanilla LOGICAL variables > and with C interop logical variables. Yeah, it would. It's something else, and if you choose to use such a type in an interface, it would need to be handled as such. Presumably, absen

[PATCH] RISC-V: Fix VL operand bug in VSETVL PASS[PR110264]

This patch fixes this issue happens on both GCC-13 and GCC-14. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110264 The testcase is too big and I failed to reduce it so I didn't append test into this patch. This patch should not only land into GCC-14 but also should backport to GCC-13. PR

[PATCH] RISC-V: Fix PR 110264

This patch fixes this issue happens on both GCC-13 and GCC-14. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110264 The testcase is too big and I failed to reduce it so I didn't append test into this patch. This patch should not only land into GCC-14 but also should backport to GCC-13. gcc/Change

RE: [PATCH v1] RISC-V: Bugfix for RVV integer reduction in ZVE32/64.

VECTOR_FLOAT_MODE_P referenced from expand, will remove it as it will be removed shortly. Pan From: juzhe.zh...@rivai.ai Sent: Friday, June 16, 2023 3:48 PM To: Li, Pan2 ; gcc-patches Cc: Robin Dapp ; jeffreyalaw ; Li, Pan2 ; Wang, Yanzhang ; kito.cheng Subject: Re: [PATCH v1] RISC-V: Bugfi

Re: [PATCH v5] MIPS: Add speculation_barrier support

Richard Earnshaw (lists) via Gcc-patches 于2023年6月8日周四 20:36写道： > > > On 01/06/2023 05:26, YunQiang Su wrote: > > speculation_barrier for MIPS needs sync+jr.hb (r2+), > > so we implement __speculation_barrier in libgcc, like arm32 does. > > > > gcc/ChangeLog: > > * config/mips/mips-protos.h (

Re: [PATCH v1] RISC-V: Bugfix for RVV integer reduction in ZVE32/64.

+/* Nonzero if MODE is a vector float mode. */ +#define VECTOR_FLOAT_MODE_P(MODE) \ + (GET_MODE_CLASS (MODE) == MODE_VECTOR_FLOAT) Why you add this? Remove it. Otherwise, LGTM. juzhe.zh...@rivai.ai From: pan2.li Date: 2023-06-16 15:28 To: gcc-patches CC: juzhe.zhong; rd

Re: [PATCH 2/2] Refined 256/512-bit vpacksswb/vpackssdw patterns.

On Fri, Jun 16, 2023 at 4:12 AM liuhongt wrote: > > The packing in vpacksswb/vpackssdw is not a simple concat, it's an > interweave from src1 and src2 for every 128 bit(or 64-bit for the > ss_truncate result). > > .i.e. > > dst[192-255] = ss_truncate (src2[128-255]) > dst[128-191] = ss_truncate (s

  1   2   >