Re: [PATCH] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000.

On Tue, 2023-02-21 at 15:20 +0800, Lulu Cheng wrote: > Like la264 only has 40 effective bits of virtual address space. I'm OK with the change. But the VA length is configurable building the kernel. Is there any specific reason LA264 has to use the 40-bit configuration, or should we reword the

Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types

On Mon, Feb 20, 2023 at 5:23 PM Tobias Burnus wrote: > > Hi Richard, hi all, > > On 20.02.23 13:46, Richard Biener wrote: > > + /* TODO: A more middle-end friendly alternative would be to use > > NULL_TREE > > +as upper bound and store the value, e.g. as GFC_DECL_STRING_LEN. > > +

[PATCH] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000.

Like la264 only has 40 effective bits of virtual address space. When TRY_EMPTY_VM_SPACE is set to 0x80, it just exceeds the range of 40-bit virtual address, causing the mmap mapping to fail, thus causing the pch function to fail. To be compatible with this situation set the macro to

Re: [PATCH] Fortran: improve checking of character length specification [PR96025]

Hi Harald, the attached patch fixes an ICE on invalid (non-integer) specification expressions for character length in function declarations. It appears that the error handling was already in place (mostly) and we need to essentially prevent run-on errors. Regtested on x86_64-pc-linux-gnu. OK

RE: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

Hi, Kindly reminder for this PR. Pan -Original Message- From: Li, Pan2 Sent: Friday, February 17, 2023 4:39 PM To: richard.sandif...@arm.com; juzhe.zhong Cc: incarnation.p@outlook.com; gcc-patches@gcc.gnu.org; kito.ch...@sifive.com; Richard Biener Subject: RE: [PATCH] RISC-V:

[PATCH] MIPS: Account for LWL/LWR in store_by_pieces_p.

From: Matthew Fortune --- gcc/config/mips/mips.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc index 590c311e98c..bb9f4e19c22 100644 --- a/gcc/config/mips/mips.cc +++ b/gcc/config/mips/mips.cc @@ -8853,7 +8853,7 @@

[PATCH] Testsuite: Disable micromips for MSA tests

From: Matthew Fortune --- gcc/testsuite/gcc.target/mips/mips.exp | 1 + 1 file changed, 1 insertion(+) diff --git a/gcc/testsuite/gcc.target/mips/mips.exp b/gcc/testsuite/gcc.target/mips/mips.exp index 81e19f39853..bf32fe0c93f 100644 --- a/gcc/testsuite/gcc.target/mips/mips.exp +++

Re: [PATCH] xtensa: Enforce return address saving when -Og is specified

On Fri, Feb 17, 2023 at 8:54 PM Takayuki 'January June' Suwa wrote: > > Leaf function often omits saving its return address to the stack slot, > and this feature often makes debugging very confusing, especially for > stack dump analysis. > > gcc/ChangeLog: > > * config/xtensa/xtensa.cc

Re: [PATCH] rs6000: mark tieable between INT and FLOAT

Hi, Gently Ping: https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609504.html BR, Jeff (Jiufu) Jiufu Guo writes: > Hi, > > During discussing/review patches in maillist, we find more modes are > tieable, e.g. DI<->DF. With some discussion, I drafted this patch > to mark more tieable

[PATCH] i386: Introduce general_x64constmem_operand predicate

Instructions that use high-part QImode registers can not be encoded with REX prefix. To avoid REX prefix, operand constraints allow only legacy QImode registers, immediates and constant memory operands. The patch introduces matching predicate, so invalid operands are not combined into instruction

[committed] powerpc: Another umaddditi4 fix [PR108862]

Hi! The following testcase is miscompiled on powerpc64le-linux with -O2 -mcpu=power9. The problem is that gen_umaddditi4 is called with the same TImode register for both op0 and op3, and maddlddi4 overwrites the low half of op0 before the low half of op3 is read, so when they are the same

[PATCH] Fortran: improve checking of character length specification [PR96025]

Dear all, the attached patch fixes an ICE on invalid (non-integer) specification expressions for character length in function declarations. It appears that the error handling was already in place (mostly) and we need to essentially prevent run-on errors. Regtested on x86_64-pc-linux-gnu. OK

[PATCH] c++: constant non-copy-init is manifestly constant [PR108243]

According to [basic.start.static]/2 and [expr.const]/2, a variable with static storage duration initialized with a constant initializer has constant initialization, and such an initializer is manifestly constant-evaluated. We're already getting this right with copy initialization because in that

Re: [PATCH] Fixing PR107411

> On Feb 20, 2023, at 10:17 AM, Jakub Jelinek wrote: > > On Mon, Feb 20, 2023 at 03:04:51PM +, Qing Zhao via Gcc-patches wrote: >> >> >>> On Feb 17, 2023, at 5:35 PM, Jakub Jelinek wrote: >>> >>> On Fri, Feb 17, 2023 at 10:26:03PM +, Qing Zhao via Gcc-patches wrote: +

Re: [PATCH RFC 1/3] c++: add __is_deducible trait [PR105841]

On Sat, 18 Feb 2023, Jason Merrill via Gcc-patches wrote: > Tested x86_64-pc-linux-gnu. Since this is fixing experimental (C++20) > functionality, I think it's reasonable to apply now; I'm interested in other > opinions, and thoughts about the user-facing functionality. I'm thinking to > make

Re: [committed] libstdc++: Fix uses of non-reserved names in simd header

On Mon, 20 Feb 2023 at 16:32, Matthias Kretz via Libstdc++ wrote: > > Tested x86_64-pc-linux. Pushed to trunk. OK for all relevant branches, thanks.

[committed] libstdc++: Fix uses of non-reserved names in simd header

Tested x86_64-pc-linux. Pushed to trunk. -- >8 -- Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: * include/experimental/bits/simd.h (__extract_part, split): Use reserved name for template parameter. --- libstdc++-v3/include/experimental/bits/simd.h | 22

Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types

Hi Richard, hi all, On 20.02.23 13:46, Richard Biener wrote: + /* TODO: A more middle-end friendly alternative would be to use NULL_TREE +as upper bound and store the value, e.g. as GFC_DECL_STRING_LEN. +Caveat: this requires some cleanup throughout the code to consistently

RE: [PATCH] [arm] disable aes-1742098 mitigation for a72 combine tests

Hi Alexandre, > -Original Message- > From: Alexandre Oliva > Sent: Friday, February 17, 2023 7:06 AM > To: gcc-patches@gcc.gnu.org > Cc: ni...@redhat.com; Richard Earnshaw ; > ramana@gmail.com; Kyrylo Tkachov > Subject: [PATCH] [arm] disable aes-1742098 mitigation for a72 combine

[committed] RISC-V: prefetch.* only take base register with zero-offset for the address

Catched by running gcc.c-torture/execute/builtin-prefetch-2.c with -march=rv64gc_zicbop. gcc/ChangeLog: * config/riscv/riscv.md (prefetch): Use r instead of p for the address operand. (riscv_prefetchi_): Ditto. --- gcc/config/riscv/riscv.md | 4 ++-- 1 file changed, 2

Re: [PATCH] Fixing PR107411

On Mon, Feb 20, 2023 at 03:04:51PM +, Qing Zhao via Gcc-patches wrote: > > > > On Feb 17, 2023, at 5:35 PM, Jakub Jelinek wrote: > > > > On Fri, Feb 17, 2023 at 10:26:03PM +, Qing Zhao via Gcc-patches wrote: > >> +else if (!DECL_NAME (lhs_var)) > >> + { > >> +

Re: [PATCH] Fixing PR107411

> On Feb 17, 2023, at 5:35 PM, Jakub Jelinek wrote: > > On Fri, Feb 17, 2023 at 10:26:03PM +, Qing Zhao via Gcc-patches wrote: >> + else if (!DECL_NAME (lhs_var)) >> +{ >> + char *lhs_var_name_str >> += xasprintf ("D.%u", DECL_UID

Prototype 'GOMP_enable_pinned_mode' (was: [PATCH 08/17] openmp: -foffload-memory=pinned)

Hi! On 2022-07-07T23:18:03+0100, Andrew Stubbs wrote: > On 07/07/2022 12:54, Tobias Burnus wrote: >> On 07.07.22 12:34, Andrew Stubbs wrote: >>> Implement the -foffload-memory=pinned option such that libgomp is >>> instructed to enable fully-pinned memory at start-up. The option is >>> intended

Re: [PATCH] libstdc++: Update baseline symbols for riscv64-linux

On Mon, 20 Feb 2023 at 12:10, Andreas Schwab via Libstdc++ wrote: > > libstdc++-v3/ > * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update. Looks good, thanks.

[og12] Attempt to not just register but allocate OpenMP pinned memory using a device (was: [og12] Attempt to register OpenMP pinned memory using a device instead of 'mlock')

Hi! On 2023-02-20T09:48:53+, Andrew Stubbs wrote: > On 17/02/2023 08:12, Thomas Schwinge wrote: >> On 2023-02-16T23:06:44+0100, I wrote: >>> On 2023-02-16T16:17:32+, "Stubbs, Andrew via Gcc-patches" >>> wrote: The mmap implementation was not optimized for a lot of small

Rust: Don't depend on unused 'target-libffi', 'target-libbacktrace' (was: [PATCH Rust front-end v2 32/37] gccrs: Add config-lang.in)

Hi! On 2022-08-24T12:59:51+0100, herron.phi...@googlemail.com wrote: > From: Philip Herron > > This was a copy paste from gccgo front-end, we do not use any of the > target_libs yet but we will need these when we support the libpanic crate. > --- /dev/null > +++ b/gcc/rust/config-lang.in >

Re: RISC-V: Add divmod instruction support

On Mon, 20 Feb 2023, Richard Biener via Gcc-patches wrote: > On Sun, Feb 19, 2023 at 2:15 AM Maciej W. Rozycki wrote: > > > > > The problem is you don't see it as a divmod in expand_divmod unless you > > > expose > > > a divmod optab. See tree-ssa-mathopts.cc's divmod handling. > > > >

Re: [PATCH] [arm] adjust tests for quotes around +cdecp

Hi Alexandre, On 2/17/23 08:17, Alexandre Oliva via Gcc-patches wrote: Back when quotes were added around "+cdecp" in the "coproc must be a constant immediate" error in arm-builtins.cc, tests for that message lagged behind. Fixed thusly. Regstrapped on x86_64-linux-gnu. Tested on

[PATCH] tree-optimization/108793 - niter compute type mismatch

When computing the number of iterations until wrap types are mixed up, eventually leading to checking ICEs with a pointer bitwise inversion. The following uses niter_type for the calculation. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/108793

Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types

On Mon, Feb 20, 2023 at 12:57 PM Jakub Jelinek wrote: > > On Mon, Feb 20, 2023 at 12:48:38PM +0100, Tobias Burnus wrote: > > On 20.02.23 12:15, Jakub Jelinek wrote: > > > On Mon, Feb 20, 2023 at 12:07:43PM +0100, Tobias Burnus wrote: > > > > As mentioned in the TODO for 'deferred', I think we

[PATCH] libstdc++: Update baseline symbols for riscv64-linux

libstdc++-v3/ * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update. --- .../riscv64-linux-gnu/baseline_symbols.txt| 98 ++- 1 file changed, 97 insertions(+), 1 deletion(-) diff --git a/libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt

Re: [PATCH] libstdc++: Add missing functions to [PR79700]

On Mon, 20 Feb 2023 at 11:57, Nathaniel Shead wrote: > > On Mon, Feb 20, 2023 at 10:30 PM Jonathan Wakely wrote: > > > > On Mon, 20 Feb 2023 at 11:23, Nathaniel Shead via Libstdc++ > > wrote: > > > > > > The comments on PR79700 mentioned that it was somewhat ambiguous whether > > > these

Re: [PATCH] libstdc++: Add missing functions to [PR79700]

On Mon, Feb 20, 2023 at 10:30 PM Jonathan Wakely wrote: > > On Mon, 20 Feb 2023 at 11:23, Nathaniel Shead via Libstdc++ > wrote: > > > > The comments on PR79700 mentioned that it was somewhat ambiguous whether > > these functions were supposed to exist for C++11 or not. I chose to add > > them

Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types

On Mon, Feb 20, 2023 at 12:48:38PM +0100, Tobias Burnus wrote: > On 20.02.23 12:15, Jakub Jelinek wrote: > > On Mon, Feb 20, 2023 at 12:07:43PM +0100, Tobias Burnus wrote: > > > As mentioned in the TODO for 'deferred', I think we really want > > > to have NULL as upper value for the domain for the

[PATCH] libstdc++: Some baseline_symbols.txt updates

Hi! This updates baseline_symbols.txt for the Fedora 39 arches. Most of the added symbols are added to all 6 files, exceptions are DF16_ rtti stuff (only added on x86 and aarch64 which supports those), DF16b rtti stuff (only x86 right now), _M_replace_cold (m vs. j differences), DF128_ charconv

Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types

On 20.02.23 12:15, Jakub Jelinek wrote: On Mon, Feb 20, 2023 at 12:07:43PM +0100, Tobias Burnus wrote: As mentioned in the TODO for 'deferred', I think we really want to have NULL as upper value for the domain for the type, but that requires literally hundred of changes to the compiler, which I

Re: [PATCH] libstdc++: Add missing functions to [PR79700]

On Mon, 20 Feb 2023 at 11:23, Nathaniel Shead via Libstdc++ wrote: > > The comments on PR79700 mentioned that it was somewhat ambiguous whether > these functions were supposed to exist for C++11 or not. I chose to add > them there, since other resources (such as cppreference) seem to think > that

[PATCH] libstdc++: Add missing functions to [PR79700]

The comments on PR79700 mentioned that it was somewhat ambiguous whether these functions were supposed to exist for C++11 or not. I chose to add them there, since other resources (such as cppreference) seem to think that C++11 should be the standard these functions were introduced, and I don't

Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types

On Mon, Feb 20, 2023 at 12:07:43PM +0100, Tobias Burnus wrote: > As mentioned in the TODO for 'deferred', I think we really want > to have NULL as upper value for the domain for the type, but that > requires literally hundred of changes to the compiler, which > I do not want to due during Stage 4,

Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types

On 20.02.23 11:41, Richard Biener wrote: Generally SAVE_EXPR is used to make sure an expression is only evaluated once. It's DECL_EXPR that ensures something is evaluated early and available. So generally "unwrapping" a SAVE_EXPR looks dangerous to me unless the SAVE_EXPR is really never

Re: [PATCH] Update baseline symbols for m68k-linux

On Sat, 18 Feb 2023 at 19:23, Andreas Schwab wrote: > > libstdc++-v3/: > * config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Update. All the additions (and the one change) look correct, thanks.

[PATCH] tree-optimization/108816 - vect versioning check split confusion

The split of the versioning condition assumes the definition is in the condition block which is ensured by the versioning code. But that only works when we actually have to insert any statements for the versioning condition. The following adjusts the guard accordingly and asserts this condition.

Re: [PATCH 1/2] Support get_range_query with a nullptr argument

On Fri, Feb 17, 2023 at 10:46 PM Andrew Pinski via Gcc-patches wrote: > > get_range_query didn't support a nullptr argument > before and would crash. > See also the thread at > https://inbox.sourceware.org/gcc/4f6718af-e17a-41ef-a886-f45e4ac3d...@redhat.com/T/ > > OK? Bootstrapped and tested on

Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types

On Mon, Feb 20, 2023 at 11:05 AM Tobias Burnus wrote: > > On 17.02.23 17:27, Steve Kargl wrote: > > On Fri, Feb 17, 2023 at 12:13:52PM +0100, Tobias Burnus wrote: > >> OK for mainline? > > Short version: no. > > Would you mind to write a reasoning beyond only a single word? > > >> subroutine

Re: [PATCH] rust: Fix rust-tree.cc compilation on SPARC

Thanks Rainer! Ok for trunk :) Kindly, -- Arthur On 2/20/23 11:36, Rainer Orth wrote: This patch commit 27a89f84c458ae938bc3eb92ad0d594c06fc3b42 Author: Thomas Schwinge Date: Fri Feb 17 23:36:20 2023 +0100 '#include "tm_p.h"' in 'gcc/rust/backend/rust-tree.cc' broke rust bootstrap

[PATCH] rust: Fix rust-tree.cc compilation on SPARC

This patch commit 27a89f84c458ae938bc3eb92ad0d594c06fc3b42 Author: Thomas Schwinge Date: Fri Feb 17 23:36:20 2023 +0100 '#include "tm_p.h"' in 'gcc/rust/backend/rust-tree.cc' broke rust bootstrap on SPARC: In file included from ./tm_p.h:4, from

[PATCH] Allow front ends to register spec functions gcc/{gcc.cc,gcc.h} [PR108261]

Hello, bootstrapped on gcc master x86_64 and no extra failures generated on all front ends. Would this be ok for trunc? regards, Gaius Allow front ends to register spec functions gcc/{gcc.cc,gcc.h} [PR108261] This patch allows front ends to register spec functions. It is motivated by

[pushed] wwwdocs: *: Add a comma after "In addition" when used as transition

As promised yesterday, this not only improves the one case that triggered NightStrike's note, but all cases I found in wwwdocs. Pushed. Gerald -- wwwdocs: *: Add a comma after "In addition" when used as transition On the way reduce one use and simplify a sentence. ---

[PATCH V3 4/5] RISC-V: Implement ZKNH extension

This patch supports Zknh extension. It includes instruction's machine description and built-in funtions. gcc/ChangeLog: * config/riscv/crypto.md (riscv_sha256sig0_): Add ZKNH's instructions. (riscv_sha256sig1_): (riscv_sha256sum0_): (riscv_sha256sum1_):

[PATCH V3 2/5] RISC-V: Implement ZBKB, ZBKC and ZBKX extensions

This patch supports Zkbk, Zbkc and Zkbx extension. It includes instruction's machine description and built-in funtions. It is worth mentioning that this patch only adds instructions in Zbkb but no longer in Zbb. If any instructions both in Zbb and Zbkb, they will be generated by code generator

[PATCH V3 3/5] RISC-V: Implement ZKND and ZKNE extensions

This patch supports Zkne and Zknd extension. It includes instruction's machine description and built-in funtions. gcc/ChangeLog: * config/riscv/constraints.md (D03): Add constants of bs and rnum. (DsA): * config/riscv/crypto.md (riscv_aes32dsi): Add ZKND's and ZKNE's

[PATCH V3 1/5] RISC-V: Add prototypes for RISC-V Crypto built-in functions

This patch adds prototypes for RISC-V Crypto built-in functions. gcc/ChangeLog: * config/riscv/riscv-builtins.cc (RISCV_FTYPE_NAME2): (RISCV_FTYPE_NAME3): (RISCV_ATYPE_QI): (RISCV_ATYPE_HI): (RISCV_FTYPE_ATYPES2): (RISCV_FTYPE_ATYPES3): *

[PATCH V3 0/5] RISC-V: Implement Scalar Cryptography Extension

This series adds basic support for the Scalar Cryptography extensions: * Zbkb * Zbkc * Zbkx * Zknd * Zkne * Zknh * Zksed * Zksh The implementation follows the version Scalar Cryptography v1.0.0 of the specification, which can be found here:

[PATCH V3 5/5] RISC-V: Implement ZKSH and ZKSED extensions

This patch supports Zksh and Zksed extension. It includes instruction's machine description and built-in funtions. gcc/ChangeLog: * config/riscv/crypto.md (riscv_sm3p0_): Add ZKSED's and ZKSH's instructions. (riscv_sm3p1_): (riscv_sm4ed_): (riscv_sm4ks_):

[PATCH] tree-optimization/108819 - niter analysis ICE with unexpected constant

The following makes sure we do not ICE on unfolded stmts like _1 = 1 & 1. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/108819 * tree-ssa-loop-niter.cc (number_of_iterations_cltz): Check we have an SSA name as iv_2 as expected.

Re: [PATCH] [PR104882] [arm] require mve hw for mve run test

Alexandre Oliva via Gcc-patches writes: > The pr104882.c test is an execution test, but arm_v8_1m_mve_ok only > tests for compile-time support. Add a requirement for mve hardware. > > Regstrapped on x86_64-linux-gnu. > Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk). Ok to install? > >

Re: RISC-V: Add divmod instruction support

On Sun, Feb 19, 2023 at 2:15 AM Maciej W. Rozycki wrote: > > On Sat, 18 Feb 2023, Jeff Law wrote: > > > > Barring the fusion case, which indeed asks for a dedicated `divmod' > > > pattern (and then I suppose a post-reload splitter or a peephole so that > > > where one of the two results

[pushed] wwwdocs: index: Remove link to Nick's blog

Nick has not been able to update his blog for a while and confirmed we should remove this link. Pushed. Gerald (who is missing those nice updates) --- htdocs/index.html | 1 - 1 file changed, 1 deletion(-) diff --git a/htdocs/index.html b/htdocs/index.html index 80730c06..3d0f8700 100644 ---

[PATCH] Allow front ends to register spec functions gcc/{gcc.cc,gcc.h} [PR108261]

Hello, bootstrapped on gcc master x86_64 and no extra failures generated on all front ends. Would this be ok for trunc? regards, Gaius Allow front ends to register spec functions gcc/{gcc.cc,gcc.h} [PR108261] This patch allows front ends to register spec functions. It is motivated by

[PATCH] tree-optimization/108825 - checking ICE with unroll-and-jam

The issue is that unroll-and-jam applies RPO VN on the transformed body but that leaves the IL in "indetermined" state (it returns a TODO to make it valid again). But unroll-and-jam then continues to transform another loop and in using the tree_unroll_loop helper runs into

Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types

On 17.02.23 17:27, Steve Kargl wrote: On Fri, Feb 17, 2023 at 12:13:52PM +0100, Tobias Burnus wrote: OK for mainline? Short version: no. Would you mind to write a reasoning beyond only a single word? subroutine foo(n) integer :: n integer :: array(n*5) integer :: my_len ...

[PATCH] RISC-V: Add RVV reduction C/C++ intrinsics support

From: Ju-Zhe Zhong gcc/ChangeLog: * config/riscv/riscv-vector-builtins-bases.cc (class reducop): New class. (class widen_reducop): Ditto. (class freducop): Ditto. (class widen_freducop): Ditto. (BASE): Ditto. *

Re: [PATCH V3] rs6000: Load high and low part of 64bit constant independently

Hi, I would like to ping this patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609373.html BR, Jeff (Jiufu) Jiufu Guo writes: > Hi, > > Compare with previous version, this patch updates the comments only. > https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608293.html > >

Re: [PATCH] Skip module_cmi_p and related unsupported module test

On 2/17/23 22:55, Alexandre Oliva wrote: When a multi-source module is found to be unsupported, we fail module_cmi_p and subsequent sources. Override proc unsupported to mark the result in module_do, and test it to skip module_cmp_p and subsequent related tests. Hmm, I guess the problem that

Re: RISC-V: Add divmod instruction support

On Sat, Feb 18, 2023 at 1:30 PM Palmer Dabbelt wrote: > > On Sat, 18 Feb 2023 13:06:02 PST (-0800), jeffreya...@gmail.com wrote: > > > > > > On 2/18/23 11:26, Palmer Dabbelt wrote: > >> On Fri, 17 Feb 2023 06:02:40 PST (-0800), gcc-patches@gcc.gnu.org wrote: > >>> Hi all, > >>> If we have

Re: [PATCH 1/2] c++: factor out TYPENAME_TYPE substitution

On 2/15/23 12:11, Patrick Palka wrote: On Wed, 15 Feb 2023, Jason Merrill wrote: On 2/15/23 09:21, Patrick Palka wrote: On Tue, 14 Feb 2023, Jason Merrill wrote: On 2/13/23 09:23, Patrick Palka wrote: [N.B. this is a corrected version of

Re: [og12] Un-break nvptx libgomp build (was: [OG12][committed] amdgcn: OpenMP low-latency allocator)

On 16/02/2023 21:11, Thomas Schwinge wrote: --- /dev/null +++ b/libgomp/basic-allocator.c +#ifndef BASIC_ALLOC_YIELD +#deine BASIC_ALLOC_YIELD +#endif In file included from [...]/libgomp/config/nvptx/allocator.c:49: [...]/libgomp/config/nvptx/../../basic-allocator.c:52:2: error:

Re: [PATCH] c++: ICE with -fno-elide-constructors and trivial fn [PR101073]

On 2/15/23 13:37, Marek Polacek wrote: On Wed, Feb 15, 2023 at 02:39:16PM -0500, Jason Merrill wrote: On 2/9/23 09:39, Marek Polacek wrote: In constexpr-nsdmi3.C, with -fno-elide-constructors, we don't elide the Y::Y(const Y&) call used to initialize o.c. So store_init_value ->

Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types

On Mon, Feb 20, 2023 at 07:56:14AM +0100, Tobias Burnus wrote: > On 17.02.23 17:27, Steve Kargl wrote: > > On Fri, Feb 17, 2023 at 12:13:52PM +0100, Tobias Burnus wrote: > > > OK for mainline? > > Short version: no. > > Would you mind to write a reasoning beyond only a single word? > > > >

Ping [PATCH, rs6000] Split TImode for logical operations in expand pass [PR100694]

Hi, Gently ping this: https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611550.html Gui Haochen Thanks 在 2023/2/8 13:08, HAO CHEN GUI 写道: > Hi, > The logical operations for TImode is split after reload pass right now. Some > potential optimizations miss as the split is too late. This

Ping^^ [PATCH V4 2/2] rs6000: use li;x?oris to build constant

Hi, Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608292.html BR, Jeff (Jiufu) Jiufu Guo via Gcc-patches writes: > Hi, > > I would like to have a ping on this patch: > https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608292.html > > > BR, > Jeff (Jiufu) > > >

[PATCH, rs6000] Merge two vector shift when their sources are the same

Hi, This patch merges two "vsldoi" insns when their sources are the same. Particularly, it is simplified to be one move if the total shift is multiples of 16 bytes. Bootstrapped and tested on powerpc64-linux BE and LE with no regressions. Thanks Gui Haochen ChangeLog 2023-02-20 Haochen

Re: [og12] Attempt to register OpenMP pinned memory using a device instead of 'mlock' (was: [PATCH] libgomp, openmp: pinned memory)

On 17/02/2023 08:12, Thomas Schwinge wrote: Hi Andrew! On 2023-02-16T23:06:44+0100, I wrote: On 2023-02-16T16:17:32+, "Stubbs, Andrew via Gcc-patches" wrote: The mmap implementation was not optimized for a lot of small allocations, and I can't see that issue changing here That's

Re: [PATCH] rs6000: Fix vector parity support [PR108699]

Hi Segher, Thanks for the comments! on 2023/2/19 20:12, Segher Boessenkool wrote: > Hi! > > On Fri, Feb 17, 2023 at 11:33:16AM +0800, Kewen.Lin wrote: >> on 2023/2/16 23:10, Segher Boessenkool wrote: >>> No, you are right that the semantics are pretty much the same. Please >>> just keep

Re: [PATCH] [arm] complete vmsr/vmrs blank and case adjustments

Alexandre Oliva writes: > Back in September last year, some of the vmsr and vmrs patterns had an > extraneous blank removed, and the case of register names lowered, but > another instance remained, and so did a few testcases. [...] Hi Alexandre, I'm not approver but LGTM, thanks for fixing

Re: [PATCH 0/4] rs6000: build constant via li/lis;rldicX

Hi, Gental ping these patches: https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611286.html BR, Jeff (Jiufu) Jiufu Guo writes: > Hi, > > For a given constant, it would be profitable if we can use 2 insns to build. > This patch enables more constants building through 2 insns: one is

Re: [PATCH v3] c++: ICE with redundant capture [PR108829]

On 2/17/23 14:42, Marek Polacek wrote: On Fri, Feb 17, 2023 at 04:32:50PM -0500, Patrick Palka wrote: On Fri, 17 Feb 2023, Patrick Palka wrote: On Fri, 17 Feb 2023, Marek Polacek wrote: On Fri, Feb 17, 2023 at 03:00:39PM -0500, Patrick Palka wrote: On Fri, 17 Feb 2023, Marek Polacek via

Re: [PATCH] rs6000: Fix vector parity support [PR108699]

Hi! On Fri, Feb 17, 2023 at 11:33:16AM +0800, Kewen.Lin wrote: > on 2023/2/16 23:10, Segher Boessenkool wrote: > > No, you are right that the semantics are pretty much the same. Please > > just keep UNSPEC_PARITY everywhere. > > OK, since it has UNSPEC, I would hope the reader can realize it's