[pushed] doc: Update Cygwin web link

2024-06-12 Thread Gerald Pfeifer
gcc: PR target/69374 * doc/install.texi (Specific) <*-*-cygwin>: Update web link. --- gcc/doc/install.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi index 621c874d268..165d48c02f8 100644 --- a/gcc/doc/install.tex

Re: [PATCH] tree-optimization/115385 - handle more gaps with peeling of a single iteration

2024-06-12 Thread Richard Biener
On Tue, 11 Jun 2024, Richard Sandiford wrote: > Don't think it makes any difference, but: > > Richard Biener writes: > > @@ -2151,7 +2151,16 @@ get_group_load_store_type (vec_info *vinfo, > > stmt_vec_info stmt_info, > > access excess elements. > > ??? Enhance

Re: [PATCH] [libstdc++] [testsuite] xfail double-prec from_chars for float128_t

2024-06-12 Thread Jonathan Wakely
On Wed, 12 Jun 2024, 02:14 Alexandre Oliva, wrote: > > Tests involving float128_t were xfailed or otherwise worked around for > vxworks on aarch64. The same issue came up on rtems. This patch > adjusts them similarly. > > Regstrapping on x86_64-linux-gnu. Also tested with gcc-13 on > aarch64-r

Re: [PATCH] [libstdc++] [testsuite] require cmath for c++23 cmath tests

2024-06-12 Thread Jonathan Wakely
On Wed, 12 Jun 2024, 02:17 Alexandre Oliva, wrote: > > Some c++23 tests fail on targets that don't satisfy dg-require-cmath, > because referenced math functions don't get declared in std. Are they present on the target at all? Is not declaring them in std the underlying bug here? Add the >

Re: [PATCH 2/2] RISC-V: Move mode assertion out of conditional branch in emit_insn

2024-06-12 Thread Robin Dapp
Hi Edwin, this LGTM but I just remembered I intended to turn the assert into a more descriptive error. The attached patch has been sitting on my local branch for a while. Maybe we should rather fold yours into it? Regards Robin >From d164403ef577917f905c1690f2199fab330f05e2 Mon Sep 17 00:00:0

Re: [PATCH 1/2] RISC-V: Fix vwsll combine on rv32 targets

2024-06-12 Thread Robin Dapp
Hi Edwin, this is OK but did you check if we can get rid of the subreg condition now that we have gen_lowpart? Regards Robin

[pushed] wwwdocs: news: Remove reference to /java

2024-06-12 Thread Gerald Pfeifer
This is a left-over that redirects to our main page; we removed all our Java material years ago. --- htdocs/news.html | 1 - 1 file changed, 1 deletion(-) diff --git a/htdocs/news.html b/htdocs/news.html index de92bdf6..4a24a4ad 100644 --- a/htdocs/news.html +++ b/htdocs/news.html @@ -1799,7 +179

Re: [PATCH v4] rs6000: Fix incorrect RTL for Power LE when removing the UNSPECS [PR106069]

2024-06-12 Thread Kewen.Lin
Hi, on 2023/2/10 10:59, Xionghu Luo wrote: > Resend this patch... > > v4: Update per comments. > v3: rename altivec_vmrghb_direct_le to altivec_vmrglb_direct_le to match > the actual output ASM vmrglb. Likewise for all similar xxx_direct_le > patterns. > v2: Split the direct pattern to be and le

Re: [PATCH-1v3] fwprop: Replace rtx_cost with insn_cost in try_fwprop_subst_pattern [PR113325]

2024-06-12 Thread Richard Sandiford
HAO CHEN GUI writes: > Hi, > This patch replaces rtx_cost with insn_cost in forward propagation. > In the PR, one constant vector should be propagated and replace a > pseudo in a store insn if we know it's a duplicated constant vector. > It reduces the insn cost but not rtx cost. In this case, t

Re: [PATCH] ifcvt: Clarify if_info.original_cost.

2024-06-12 Thread Robin Dapp
> Hmm, ok. The bit that confused me most was: > > if (last_needs_comparison != -1) > { > end_sequence (); > start_sequence (); > ... > } > > which implied that the second attempt was made conditionally. > It seems like it's always used and is an inherent part of the >

Re: [PATCH] rust: Do not link with libdl and libpthread unconditionally

2024-06-12 Thread Uros Bizjak
On Tue, Jun 11, 2024 at 11:21 AM Arthur Cohen wrote: > > Thanks Richi! > > Tested again and pushed on trunk. This patch introduced a couple of errors during ./configure: checking for library containing dlopen... none required checking for library containing pthread_create... none required /git/

Re: [PATCH v2] fix PowerPC < 7 w/ Altivec not to default to power7

2024-06-12 Thread René Rebe
Hey, > On Jun 12, 2024, at 00:27, René Rebe wrote: > > Hi! > >> On Jun 12, 2024, at 00:15, Segher Boessenkool >> wrote: >> >> Hi! >> >> What does "powerpc < 7" mean? Something before POWER ISA 2.06? > > PowerPC ISA level 7 or whatever you like to call it. > >> On Tue, Jun 11, 2024 at 04:

Re: [PATCH v2 0/4] Libatomic: Cleanup ifunc selector and aliasing

2024-06-12 Thread Richard Sandiford
Victor Do Nascimento writes: > Changes in V2: > > As explained in patch v2 1/4, it has become clear that the current > approach of querying assembler support for newer architectural > extensions at compile time is undesirable both from a maintainability > as well as a consistency standpoint - Diff

Re: arm: Add .type and .size to __gnu_cmse_nonsecure_call [PR115360]

2024-06-12 Thread Andre Vieira (lists)
On 06/06/2024 12:53, Richard Earnshaw (lists) wrote: On 05/06/2024 17:07, Andre Vieira (lists) wrote: Hi, This patch adds missing assembly directives to the CMSE library wrapper to call functions with attribute cmse_nonsecure_call.  Without the .type directive the linker will fail to produ

Re: [PATCH] aarch64: Use bitreverse rtl code instead of unspec [PR115176]

2024-06-12 Thread Richard Sandiford
Andrew Pinski writes: > Bitreverse rtl code was added with r14-1586-g6160572f8d243c. So let's > use it instead of an unspec. This is just a small cleanup but it does > have one small fix with respect to rtx costs which didn't handle vector modes > correctly for the UNSPEC and now it does. > This i

Re: [PATCH] tree-optimization/115385 - handle more gaps with peeling of a single iteration

2024-06-12 Thread Richard Biener
On Wed, 12 Jun 2024, Richard Biener wrote: > On Tue, 11 Jun 2024, Richard Sandiford wrote: > > > Don't think it makes any difference, but: > > > > Richard Biener writes: > > > @@ -2151,7 +2151,16 @@ get_group_load_store_type (vec_info *vinfo, > > > stmt_vec_info stmt_info, > > >

[PATCH 1/3][v3] tree-optimization/114107 - avoid peeling for gaps in more cases

2024-06-12 Thread Richard Biener
The following refactors the code to detect necessary peeling for gaps, in particular the PR103116 case when there is no gap but the group size is smaller than the vector size. The testcase in PR114107 shows we fail to SLP for (int i=0; i

[PATCH 2/3][v3] tree-optimization/115385 - handle more gaps with peeling of a single iteration

2024-06-12 Thread Richard Biener
The following makes peeling of a single scalar iteration handle more gaps, including non-power-of-two cases. This can be done by rounding up the remaining access to the next power-of-two which ensures that the next scalar iteration will pick at least the number of excess elements we access. I've

[PATCH 3/3][v3] Improve code generation of strided SLP loads

2024-06-12 Thread Richard Biener
This avoids falling back to elementwise accesses for strided SLP loads when the group size is not a multiple of the vector element size. Instead we can use a smaller vector or integer type for the load. For stores we can do the same though restrictions on stores we handle and the fact that store-

Re: [PATCH 06/52] m2: Replace uses of {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE

2024-06-12 Thread Kewen.Lin
Hi Gaius, >> static tree >> build_m2_short_real_node (void) >> { >> - tree c; >> - >> - /* Define `REAL'. */ >> - >> - c = make_node (REAL_TYPE); >> - TYPE_PRECISION (c) = FLOAT_TYPE_SIZE; >> - layout_type (c); >> - return c; >> + /* Define `SHORTREAL'. */ >> + layout_type (float_type

Re: [PATCH 04/52] go: Replace uses of {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE

2024-06-12 Thread Kewen.Lin
Hi, Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653387.html BR, Kewen on 2024/6/3 11:00, Kewen Lin wrote: > Joseph pointed out "floating types should have their mode, > not a poorly defined precision value" in the discussion[1], > as he and Richi suggested, the existing mac

PING^1 [PATCH 05/52] rust: Replace uses of {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE

2024-06-12 Thread Kewen.Lin
Hi, Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653339.html BR, Kewen on 2024/6/3 11:00, Kewen Lin wrote: > Joseph pointed out "floating types should have their mode, > not a poorly defined precision value" in the discussion[1], > as he and Richi suggested, the existing mac

PING^1 [PATCH 08/52] vms: Replace use of LONG_DOUBLE_TYPE_SIZE

2024-06-12 Thread Kewen.Lin
Hi, Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653342.html BR, Kewen on 2024/6/3 11:00, Kewen Lin wrote: > Joseph pointed out "floating types should have their mode, > not a poorly defined precision value" in the discussion[1], > as he and Richi suggested, the existing mac

Re: [PATCH] tree-optimization/115385 - handle more gaps with peeling of a single iteration

2024-06-12 Thread Richard Sandiford
Richard Biener writes: > On Wed, 12 Jun 2024, Richard Biener wrote: > >> On Tue, 11 Jun 2024, Richard Sandiford wrote: >> >> > Don't think it makes any difference, but: >> > >> > Richard Biener writes: >> > > @@ -2151,7 +2151,16 @@ get_group_load_store_type (vec_info *vinfo, >> > > stmt_vec_in

Re: [PATCH] LoongArch: Use bstrins for "value & (-1u << const)"

2024-06-12 Thread Lulu Cheng
LGTM! Thanks! 在 2024/6/9 下午9:48, Xi Ruoyao 写道: A move/bstrins pair is as fast as a (addi.w|lu12i.w|lu32i.d|lu52i.d)/and pair, and twice fast as a srli/slli pair. When the src reg and the dst reg happens to be the same, the move instruction can be optimized away. gcc/ChangeLog: * conf

Re: [PATCH] [APX CCMP] Use ctestcc when comparing to const 0

2024-06-12 Thread Uros Bizjak
On Wed, Jun 12, 2024 at 5:12 AM Hongyu Wang wrote: > > Hi, > > For CTEST, we don't have conditional AND so there's no optimization > opportunity to write a new ctest pattern. Emit ctest when ccmp did > comparison to const 0 to save bytes. > > Bootstrapped & regtested under x86-64-pc-linux-gnu. > >

Re: [PATCH] [APX CCMP] Use ctestcc when comparing to const 0

2024-06-12 Thread Uros Bizjak
On Wed, Jun 12, 2024 at 12:00 PM Uros Bizjak wrote: > > On Wed, Jun 12, 2024 at 5:12 AM Hongyu Wang wrote: > > > > Hi, > > > > For CTEST, we don't have conditional AND so there's no optimization > > opportunity to write a new ctest pattern. Emit ctest when ccmp did > > comparison to const 0 to sa

[PATCH 0/3] Remove ia64*-*-linux from the list of obsolete targets

2024-06-12 Thread Rene Rebe
Hey there, I wanted to come back to maintaining the ia64 port as discussed preciously the other month on the gcc list. It has been some days as we were busy releasing the biggest release of our Embdded T2/Linux distribution [0] and we obviously did not want to propose to enable LRA for IA-64 in t

Re: [PATCH v2] Arm: Fix disassembly error in Thumb-1 relaxed load/store [PR115188]

2024-06-12 Thread Richard Earnshaw (lists)
On 11/06/2024 17:35, Wilco Dijkstra wrote: > Hi Christophe, > >> PR target/115153 > I guess this is typo (should be 115188) ? > > Correct. > >> +/* { dg-options "-O2 -mthumb" } */-mthumb is included in arm_arch_v6m, so I >> think you don't need to add it > here? > > Indeed, it's not s

Re: [PATCH] tree-optimization/115385 - handle more gaps with peeling of a single iteration

2024-06-12 Thread Richard Biener
On Wed, 12 Jun 2024, Richard Sandiford wrote: > Richard Biener writes: > > On Wed, 12 Jun 2024, Richard Biener wrote: > > > >> On Tue, 11 Jun 2024, Richard Sandiford wrote: > >> > >> > Don't think it makes any difference, but: > >> > > >> > Richard Biener writes: > >> > > @@ -2151,7 +2151,16 @

[PATCH 1/3] Remove ia64*-*-linux from the list of obsolete targets

2024-06-12 Thread Rene Rebe
The following un-deprecates ia64*-*-linux for GCC 15. Since we plan to support this for some years to come. gcc/ * config.gcc: Only exlicitly list ia64*-*-(hpux|vms|elf) in the list of obsoleted targets. contrib/ * config-list.mk (LIST): no --enable-obsolete for ia64*-*-

[PATCH 3/3] MAINTAINERS: Add myself as IA-64 maintainer.

2024-06-12 Thread Rene Rebe
MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index e2870eef2ef..4328ca5f84c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -78,6 +78,7 @@ i386 port Jan Hubicka i386 port Uros Bizjak i386 vector ISA ext

[PATCH 2/3] Enabled LRA for ia64.

2024-06-12 Thread Rene Rebe
gcc/ * config/ia64/ia64.cc: Enable LRA for ia64. * config/ia64/ia64.md: Likewise. * config/ia64/predicates.md: Likewise. --- gcc/config/ia64/ia64.cc | 7 ++- gcc/config/ia64/ia64.md | 4 ++-- gcc/config/ia64/predicates.md | 2 +- 3 files changed, 5 insertion

Re: [PATCH v2] Arm: Fix disassembly error in Thumb-1 relaxed load/store [PR115188]

2024-06-12 Thread Richard Earnshaw
On 12/06/2024 11:35, Richard Earnshaw (lists) wrote: > On 11/06/2024 17:35, Wilco Dijkstra wrote: >> Hi Christophe, >> >>> PR target/115153 >> I guess this is typo (should be 115188) ? >> >> Correct. >> >>> +/* { dg-options "-O2 -mthumb" } */-mthumb is included in arm_arch_v6m, so >>>

Re: [PATCH 2/3] Enabled LRA for ia64.

2024-06-12 Thread Richard Biener
On Wed, 12 Jun 2024, Rene Rebe wrote: > > gcc/ > * config/ia64/ia64.cc: Enable LRA for ia64. > * config/ia64/ia64.md: Likewise. > * config/ia64/predicates.md: Likewise. That looks simple enough. I cannot find any copyright assignment on file with the FSF so you probably wa

RE: [Committed] RISC-V: Add basic Zaamo and Zalrsc support

2024-06-12 Thread Li, Pan2
Do we need to upgrade the binutils of the riscv-gnu-toolchain repo? Or we may have unknown prefixed ISA extension `zaamo' when building. Pan -Original Message- From: Patrick O'Neill Sent: Wednesday, June 12, 2024 1:08 AM To: Jeff Law ; gcc-patches@gcc.gnu.org Cc: kito.ch...@gmail.com;

Re: [Committed] RISC-V: Add basic Zaamo and Zalrsc support

2024-06-12 Thread Andreas Schwab
On Jun 12 2024, Li, Pan2 wrote: > Do we need to upgrade the binutils of the riscv-gnu-toolchain repo? Or we may > have unknown prefixed ISA extension `zaamo' when building. There needs to be a configure check if binutils can grok the extension. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG

[PATCH v5 1/6] libgomp: change alloc-pinned tests failure mode

2024-06-12 Thread Andrew Stubbs
The feature doesn't work on non-Linux hosts, at present, so skip the tests entirely. On Linux systems that have insufficient lockable memory configured we still need to fail or else the feature won't be getting tested when we think it is, but now there's a message to explain why. libgomp/ChangeLo

[PATCH v5 0/6] libgomp: OpenMP pinned memory for omp_alloc

2024-06-12 Thread Andrew Stubbs
This patch series is a rework of the v4 series I posted in May: https://patchwork.sourceware.org/project/gcc/list/?series=34587&state=%2A&archive=both This adds a new patch (1/6) that adjusts criticisms of the testcases that were already committed. The same issues have been fixed in the new testc

[PATCH v5 3/6] openmp: Add -foffload-memory

2024-06-12 Thread Andrew Stubbs
Add a new option. It's inactive until I add some follow-up patches. gcc/ChangeLog: * common.opt: Add -foffload-memory and its enum values. * coretypes.h (enum offload_memory): New. * doc/invoke.texi: Document -foffload-memory. --- gcc/common.opt | 16 +++

[PATCH v5 2/6] libgomp, openmp: Add ompx_gnu_pinned_mem_alloc

2024-06-12 Thread Andrew Stubbs
Compared to the previous v4 (1/5) posting of this patch: - The enumeration of the ompx allocators have been moved (again) to 200 (as 100 is already in use by another toolchain vendor and this seems like a possible source of confusion). - The "ompx" has also been changed to "ompx_gnu" to highlig

[PATCH v5 5/6] libgomp, nvptx: Cuda pinned memory

2024-06-12 Thread Andrew Stubbs
This patch was already approved, in the v3 posting by Tobias Burnus (with one caveat about initialization location), but wasn't committed at that time as I didn't want to disentangle it from the textual dependencies on the other patches in the series. -- Use Cuda to pin memory, instead of Lin

[PATCH v5 4/6] openmp: -foffload-memory=pinned

2024-06-12 Thread Andrew Stubbs
Implement the -foffload-memory=pinned option such that libgomp is instructed to enable fully-pinned memory at start-up. The option is intended to provide a performance boost to certain offload programs without modifying the code. This feature only works on Linux, at present, and simply calls mloc

[PATCH v5 6/6] libgomp: fine-grained pinned memory allocator

2024-06-12 Thread Andrew Stubbs
This patch introduces a new custom memory allocator for use with pinned memory (in the case where the Cuda allocator isn't available). In future, this allocator will also be used for Unified Shared Memory. Both memories are incompatible with the system malloc because allocated memory cannot share

Re: [PATCH] aarch64: Add vector popcount besides QImode [PR113859]

2024-06-12 Thread Richard Sandiford
Pengxuan Zheng writes: > This patch improves GCC’s vectorization of __builtin_popcount for aarch64 > target > by adding popcount patterns for vector modes besides QImode, i.e., HImode, > SImode and DImode. > > With this patch, we now generate the following for HImode: > cnt v1.16b, v.16b >

Re: [PATCH v3 2/2] testsuite: Fix expand-return CMSE test for Armv8.1-M [PR115253]

2024-06-12 Thread Torbjorn SVENSSON
On 2024-06-11 16:00, Richard Earnshaw (lists) wrote: On 10/06/2024 15:04, Torbjörn SVENSSON wrote: For Armv8.1-M, the clearing of the registers is handled differently than for Armv8-M, so update the test case accordingly. gcc/testsuite/ChangeLog: PR target/115253 * gcc.targe

Re: [PATCH v3 1/2] arm: Zero/Sign extends for CMSE security on Armv8-M.baseline [PR115253]

2024-06-12 Thread Torbjorn SVENSSON
On 2024-06-11 15:59, Richard Earnshaw (lists) wrote: On 10/06/2024 15:04, Torbjörn SVENSSON wrote: Properly handle zero and sign extension for Armv8-M.baseline as Cortex-M23 can have the security extension active. Currently, there is an internal compiler error on Cortex-M23 for the epilog pro

Re: Frontend access to target features (was Re: [PATCH] libgccjit: Add ability to get CPU features)

2024-06-12 Thread Antoni Boucher
David: Ping. Le 2024-04-26 à 09 h 51, Antoni Boucher a écrit : Now that we have a more general way to check if target-dependent types are supported (see this commit: https://github.com/rust-lang/gcc/commit/1c9a9b2f1fd914cad911467ec1d29f158643c2ce#diff-018089519ab2b14a34313ded0ae1a2f9fcab5f7bcb2

Re: [PATCH 04/52] go: Replace uses of {FLOAT, {, LONG_}DOUBLE}_TYPE_SIZE

2024-06-12 Thread Ian Lance Taylor
"Kewen.Lin" writes: > Hi, > > Gentle ping: > > https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653387.html > > BR, > Kewen > > on 2024/6/3 11:00, Kewen Lin wrote: >> Joseph pointed out "floating types should have their mode, >> not a poorly defined precision value" in the discussion[1], >> as

[PATCH v2] libatomic: Add rcpc3 128-bit atomic operations for AArch64

2024-06-12 Thread Victor Do Nascimento
The introduction of the optional RCPC3 architectural extension for Armv8.2-A upwards provides additional support for the release consistency model, introducing the Load-Acquire RCpc Pair Ordered, and Store-Release Pair Ordered operations in the form of LDIAPP and STILP. These operations are single

[PATCH v1] Match: Support more forms for the scalar unsigned .SAT_SUB

2024-06-12 Thread pan2 . li
From: Pan Li After we support the scalar unsigned form 1 and 2, we would like to introduce more forms include the branch and branchless. There are forms 3-10 list as below: Form 3: #define SAT_SUB_U_3(T) \ T sat_sub_u_3_##T (T x, T y) \ { \ return x > y ? x - y : 0; \ } Form 4:

Re: [PATCH v2] [PR100106] Reject unaligned subregs when strict alignment is required

2024-06-12 Thread Maciej W. Rozycki
On Thu, 5 May 2022, Alexandre Oliva via Gcc-patches wrote: > [PR100106] Reject unaligned subregs when strict alignment is required > > From: Alexandre Oliva > > The testcase for pr100106, compiled with optimization for 32-bit > powerpc -mcpu=604 with -mstrict-align expands the initialization of

Re: [PATCH v5 1/6] libgomp: change alloc-pinned tests failure mode

2024-06-12 Thread Tobias Burnus
Andrew Stubbs wrote: The feature doesn't work on non-Linux hosts, at present, so skip the tests entirely. On Linux systems that have insufficient lockable memory configured we still need to fail or else the feature won't be getting tested when we think it is, but now there's a message to explain

Re: [PATCH v5 2/6] libgomp, openmp: Add ompx_gnu_pinned_mem_alloc

2024-06-12 Thread Tobias Burnus
Andrew Stubbs wrote: Compared to the previous v4 (1/5) posting of this patch: - The enumeration of the ompx allocators have been moved (again) to 200 (as 100 is already in use by another toolchain vendor and this seems like a possible source of confusion). - The "ompx" has also been changed

Re: [PATCH v2] middle-end: Drop __builtin_prefetch calls in autovectorization [PR114061]

2024-06-12 Thread Richard Biener
On Tue, Jun 11, 2024 at 11:46 AM Victor Do Nascimento wrote: > > At present the autovectorizer fails to vectorize simple loops > involving calls to `__builtin_prefetch'. A simple example of such > loop is given below: > > void foo(double * restrict a, double * restrict b, int n){ > int i; > f

Re: [PATCH 2/3] Enabled LRA for ia64.

2024-06-12 Thread René Rebe
Hi, > On Jun 12, 2024, at 13:01, Richard Biener wrote: > > On Wed, 12 Jun 2024, Rene Rebe wrote: >> >> gcc/ >>* config/ia64/ia64.cc: Enable LRA for ia64. >>* config/ia64/ia64.md: Likewise. >>* config/ia64/predicates.md: Likewise. > > That looks simple enough. I cannot

Re: [PATCH] match: Improve gimple_bitwise_equal_p and gimple_bitwise_inverted_equal_p for truncating casts [PR115449]

2024-06-12 Thread Richard Biener
On Wed, Jun 12, 2024 at 6:39 AM Andrew Pinski wrote: > > As mentioned by Jeff in r15-831-g05daf617ea22e1d818295ed2d037456937e23530, we > don't handle > `(X | Y) & ~Y` -> `X & ~Y` on the gimple level when there are some different > signed > (but same precision) types dealing with matching `~Y` wi

Re: [PATCH 2/3] Enabled LRA for ia64.

2024-06-12 Thread Richard Biener
On Wed, 12 Jun 2024, René Rebe wrote: > Hi, > > > On Jun 12, 2024, at 13:01, Richard Biener wrote: > > > > On Wed, 12 Jun 2024, Rene Rebe wrote: > >> > >> gcc/ > >>* config/ia64/ia64.cc: Enable LRA for ia64. > >>* config/ia64/ia64.md: Likewise. > >>* config/ia64/predica

Re: [PATCH v2] Target-independent store forwarding avoidance.

2024-06-12 Thread Manolis Tsamis
On Mon, Jun 10, 2024 at 9:27 PM Philipp Tomsich wrote: > > On Mon, 10 Jun 2024 at 20:03, Jeff Law wrote: > > > > > > > > On 6/10/24 1:55 AM, Manolis Tsamis wrote: > > > > >> > > > There was an older submission of a load-pair specific pass but this is > > > a complete reimplementation and indeed s

[PATCH] configure: adjustments for building with in-tree binutils

2024-06-12 Thread Jan Beulich
For one setting ld_ver in a conditional (no in-tree ld) when it's used, for x86 at least, in unconditional ways can't be quite right. And then prefixing relative paths to binaries with ${objdir}/, when ${objdir} nowadays resolves to just .libs, can at best be a leftover that wasn't properly cleaned

Re: [patch, rs6000, middle-end 0/1] v1: Add implementation for different targets for pair mem fusion

2024-06-12 Thread Ajit Agarwal
Hello Richard: On 12/06/24 3:02 am, Richard Sandiford wrote: > Ajit Agarwal writes: >> Hello Richard: >> >> On 11/06/24 9:41 pm, Richard Sandiford wrote: >>> Ajit Agarwal writes: >> Thanks a lot. Can I know what should we be doing with neg (fma) >> correctness failures with load fusion.

Re: [PATCH 2/3] Enabled LRA for ia64.

2024-06-12 Thread René Rebe
On Jun 12, 2024, at 15:00, Richard Biener wrote: > > On Wed, 12 Jun 2024, René Rebe wrote: > >> Hi, >> >>> On Jun 12, 2024, at 13:01, Richard Biener wrote: >>> >>> On Wed, 12 Jun 2024, Rene Rebe wrote: gcc/ * config/ia64/ia64.cc: Enable LRA for ia64. * config

Re: arm: Add .type and .size to __gnu_cmse_nonsecure_call [PR115360]

2024-06-12 Thread Richard Earnshaw (lists)
On 12/06/2024 09:53, Andre Vieira (lists) wrote: > > > On 06/06/2024 12:53, Richard Earnshaw (lists) wrote: >> On 05/06/2024 17:07, Andre Vieira (lists) wrote: >>> Hi, >>> >>> This patch adds missing assembly directives to the CMSE library wrapper to >>> call functions with attribute cmse_nonsec

[pushed 3/3] pretty_printer: convert chunk_info into a class

2024-06-12 Thread David Malcolm
No functional change intended. Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Successful run of analyzer integration tests on x86_64-pc-linux-gnu. Pushed to trunk as r15-1210-g1cae1a5ce088c1. gcc/cp/ChangeLog: * error.cc (append_formatted_chunk): Move part of body into

[pushed 2/3] pretty_printer: make all fields private

2024-06-12 Thread David Malcolm
No functional change intended. Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Successful run of analyzer integration tests on x86_64-pc-linux-gnu. Pushed to trunk as r15-1209-gc5e3be456888aa. gcc/analyzer/ChangeLog: * access-diagram.cc (access_range::dump): Update for fiel

Re: [patch, rs6000, middle-end 0/1] v1: Add implementation for different targets for pair mem fusion

2024-06-12 Thread Ajit Agarwal
Hello Richard: On 12/06/24 3:02 am, Richard Sandiford wrote: > Ajit Agarwal writes: >> Hello Richard: >> >> On 11/06/24 9:41 pm, Richard Sandiford wrote: >>> Ajit Agarwal writes: >> Thanks a lot. Can I know what should we be doing with neg (fma) >> correctness failures with load fusion.

[PATCH] Move cexpr_stree tree string build into utility function

2024-06-12 Thread Andi Kleen
No semantics changes. gcc/cp/ChangeLog: * cp-tree.h (extract): Add new overload to return tree. * parser.cc (cp_parser_asm_string_expression): Use tree extract. * semantics.cc (cexpr_str::extract): Add new overload to return tree. --- gcc/cp/cp-tree.h| 1 +

Re: [PATCH 2/3] Enabled LRA for ia64.

2024-06-12 Thread Frank Scheiner
Hi all, On 12.06.24 15:19, René Rebe wrote: On Jun 12, 2024, at 15:00, Richard Biener wrote: On Wed, 12 Jun 2024, René Rebe wrote: On Jun 12, 2024, at 13:01, Richard Biener wrote: On Wed, 12 Jun 2024, Rene Rebe wrote: not sure how you exactly did this though?  I've never tried testing of a

Re: [PATCH 2/3] Enabled LRA for ia64.

2024-06-12 Thread Frank Scheiner
Dear Richard, On 12.06.24 13:01, Richard Biener wrote: [...] I can find two gcc-testresult postings, one appearantly with LRA and one without? Both from May: https://sourceware.org/pipermail/gcc-testresults/2024-May/816422.html https://sourceware.org/pipermail/gcc-testresults/2024-May/816346.h

Re: [PATCH v3 2/2] C++: Support constexpr strings for asm statements

2024-06-12 Thread Jason Merrill
On 6/11/24 23:53, Andi Kleen wrote: Sorry I must have misunderstood you. I thought the patch was already approved earlier and I did commit. I can revert or do additional changes. I only meant to approve the refactoring patch, but no worries. On Tue, Jun 11, 2024 at 04:31:30PM -0400, Jason Me

Re: [PATCH v2] Target-independent store forwarding avoidance.

2024-06-12 Thread Jeff Law
On 6/12/24 12:47 AM, Richard Biener wrote: One of the points I wanted to make is that sched1 can make quite a difference as to the relative distance of the store and load and we have the instruction window the pass considers when scanning (possibly driven by target uarch details). So doing

Re: [PATCH] regenerate-opt-urls.py: fix transposed values for "vax" and "v850"

2024-06-12 Thread Maciej W. Rozycki
On Mon, 3 Jun 2024, David Malcolm wrote: > >  Thank you for fixing this up.  Is this a new requirement now for > > .opt > > file changes?   > > Yes, as of GCC 14. > > I posted the objectives here: > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636060.html Thank you for the pointer.

Re: [PATCH] Move cexpr_stree tree string build into utility function

2024-06-12 Thread Jason Merrill
On 6/12/24 10:02, Andi Kleen wrote: No semantics changes. gcc/cp/ChangeLog: * cp-tree.h (extract): Add new overload to return tree. * parser.cc (cp_parser_asm_string_expression): Use tree extract. * semantics.cc (cexpr_str::extract): Add new overload to return

[committed] libstdc++: Do not use memset in _Hashtable::clear()

2024-06-12 Thread Jonathan Wakely
Tested x86_64-linux. Pushed to trunk. -- >8 -- Using memset is incorrect if the __bucket_ptr type is non-trivial, or does not use an all-zero bit pattern for its null value. Replace the three uses of memset with std::fill_n to set the pointers to nullptr. libstdc++-v3/ChangeLog: * incl

[committed] libstdc++: Fix std::tr2::dynamic_bitset shift operations [PR115399]

2024-06-12 Thread Jonathan Wakely
Tested x86_64-linux. Pushed to trunk. -- >8 -- The shift operations for dynamic_bitset fail to zero out words where the non-zero bits were shifted to a completely different word. For a right shift we don't need to sanitize the unused bits in the high word, because we know they were already clear

Re: [PATCH] rtlanal: Correct cost regularization in pattern_cost

2024-06-12 Thread Richard Sandiford
Richard Biener writes: > On Fri, May 10, 2024 at 4:25 AM HAO CHEN GUI wrote: >> >> Hi, >>The cost return from set_src_cost might be zero. Zero for >> pattern_cost means unknown cost. So the regularization converts the zero >> to COSTS_N_INSNS (1). >> >>// pattern_cost >>cost = set_src

Re: [PATCH v4 5/6] bpf,btf: enable BTF pruning by default for BPF

2024-06-12 Thread Jose E. Marchesi
Hi Faust. Thanks for the patch. Please see a question below. > This patch enables -gprune-btf by default in the BPF backend when > generating BTF information, and fixes BPF CO-RE generation when using > -gprune-btf. > > When generating BPF CO-RE information, we must ensure that types used > in C

Re: [Committed] RISC-V: Add basic Zaamo and Zalrsc support

2024-06-12 Thread Patrick O'Neill
On 6/12/24 04:21, Andreas Schwab wrote: On Jun 12 2024, Li, Pan2 wrote: Do we need to upgrade the binutils of the riscv-gnu-toolchain repo? Or we may have unknown prefixed ISA extension `zaamo' when building. There needs to be a configure check if binutils can grok the extension. Ack. I'l

Re: [Committed] RISC-V: Add basic Zaamo and Zalrsc support

2024-06-12 Thread Palmer Dabbelt
On Wed, 12 Jun 2024 10:09:06 PDT (-0700), Patrick O'Neill wrote: On 6/12/24 04:21, Andreas Schwab wrote: On Jun 12 2024, Li, Pan2 wrote: Do we need to upgrade the binutils of the riscv-gnu-toolchain repo? Or we may have unknown prefixed ISA extension `zaamo' when building. There needs to be

[PATCH 1/3] Remove const char * support for asm constexpr

2024-06-12 Thread Andi Kleen
asm constexpr now only accepts the same string types as C++26 assert, e.g. string_view and string. Adjust test suite and documentation. gcc/cp/ChangeLog: * parser.cc (cp_parser_asm_string_expression): Remove support for const char * for asm constexpr. gcc/ChangeLog: *

[PATCH 2/3] Parse close paren even when constexpr extraction fails

2024-06-12 Thread Andi Kleen
To get better error recovery. gcc/cp/ChangeLog: * parser.cc (cp_parser_asm_string_expression): Parse close parent when constexpr extraction fails. --- gcc/cp/parser.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc index 98

[PATCH 3/3] Fix error message

2024-06-12 Thread Andi Kleen
gcc/cp/ChangeLog: * parser.cc (cp_parser_asm_string_expression): Use correct error message. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/constexpr-asm-3.C: Adjust for new message. --- gcc/cp/parser.cc | 2 +- gcc/testsuite/g++.dg/cpp1z/constexpr-as

Re: [PATCH v4 5/6] bpf,btf: enable BTF pruning by default for BPF

2024-06-12 Thread David Faust
On 6/12/24 09:55, Jose E. Marchesi wrote: > > Hi Faust. > Thanks for the patch. > Please see a question below. > >> This patch enables -gprune-btf by default in the BPF backend when >> generating BTF information, and fixes BPF CO-RE generation when using >> -gprune-btf. >> >> When generating B

[PATCH] c++: ICE w/ ambig and non-strictly-viable cands [PR115239]

2024-06-12 Thread Patrick Palka
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? -- >8 -- Here during overload resolution we have two strictly viable ambiguous candidates #1 and #2, and two non-strictly viable candidates #3 and #4 which we hold on to ever since r14-6522. These latter candidate

Re: [PATCH] c++: ICE w/ ambig and non-strictly-viable cands [PR115239]

2024-06-12 Thread Patrick Palka
On Wed, 12 Jun 2024, Patrick Palka wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > trunk/14? > > -- >8 -- > > Here during overload resolution we have two strictly viable ambiguous > candidates #1 and #2, and two non-strictly viable candidates #3 and #4 > which

Re: [PATCH v2] Test: Move target independent test cases to gcc.dg/torture

2024-06-12 Thread Jeff Law
On 6/11/24 8:53 AM, pan2...@intel.com wrote: From: Pan Li The test cases of pr115387 are target independent, at least x86 and riscv are able to reproduce. Thus, move these cases to the gcc.dg/torture. The below test suites are passed. 1. The rv64gcv fully regression test. 2. The x86 full

Re: [PATCH 0/3] RISC-V: Amo testsuite cleanup

2024-06-12 Thread Jeff Law
On 6/11/24 12:03 PM, Patrick O'Neill wrote: This series moves the atomic-related riscv testcases into their own folder and fixes some minor bugs/rigidity of existing testcases. This series is OK. jeff

Re: [PATCH v2 2/3] RISC-V: Add Zalrsc and Zaamo testsuite support

2024-06-12 Thread Jeff Law
On 6/11/24 12:21 PM, Patrick O'Neill wrote: I made the whitespace cleanup patch (trailing whitespace, leading groups of 8 spaces -> tabs) for target-supports.exp and got a diff of 584 lines. Is this still worth doing or will it be too disruptive for rebasing/ other people's development?

Re: [RFC][PATCH] PR tree-optimization/109071 - -Warray-bounds false positive warnings due to code duplication from jump threading

2024-06-12 Thread Qing Zhao
An update on this task. (Also need more suggestions -:) I have an initial implemenation locally, with this gcc, I can get the following message with the testing case in PR109071: [ 109071]$ cat t.c extern void warn(void); static inline void assign(int val, int *regs, int *index) { if (*index >

[Committed] RISC-V: Amo testsuite cleanup

2024-06-12 Thread Patrick O'Neill
On 6/12/24 11:12, Jeff Law wrote: On 6/11/24 12:03 PM, Patrick O'Neill wrote: This series moves the atomic-related riscv testcases into their own folder and fixes some minor bugs/rigidity of existing testcases. This series is OK. jeff Committed, thanks. Patrick

[PATCH] c++: undeclared identifier in requires-clause [PR99678]

2024-06-12 Thread Patrick Palka
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? -- >8 -- Since the terms of a requires-clause are grammatically primary-expressions rather than e.g. postfix-expressions, it seems we need to explicitly handle and diagnose the case where a term parses to bare unre

[pushed] pretty_printer: unbreak build on aarch64 [PR115465]

2024-06-12 Thread David Malcolm
I missed this target-specific usage of pretty_printer::buffer when making the fields private in r15-1209-gc5e3be456888aa; sorry. Verified that this fixes the build breakage with --target=aarch64-unknown-linux-gnu. Pushed as r15-1220-ge35f4eab68773b. gcc/ChangeLog: PR bootstrap/115465

Re: [PATCH 1/3] Remove ia64*-*-linux from the list of obsolete targets

2024-06-12 Thread Jonathan Wakely
On 12/06/24 12:42 +0200, Rene Rebe wrote: The following un-deprecates ia64*-*-linux for GCC 15. Since we plan to support this for some years to come. gcc/ * config.gcc: Only exlicitly list ia64*-*-(hpux|vms|elf) in the list of obsoleted targets. contrib/ * config-list.mk

Re: [PATCH 0/3] Remove ia64*-*-linux from the list of obsolete targets

2024-06-12 Thread Jonathan Wakely
On 12/06/24 12:33 +0200, Rene Rebe wrote: Hey there, I wanted to come back to maintaining the ia64 port as discussed preciously the other month on the gcc list. It has been some days as we were busy releasing the biggest release of our Embdded T2/Linux distribution [0] and we obviously did not

Re: [PATCH v4 5/6] bpf,btf: enable BTF pruning by default for BPF

2024-06-12 Thread Jose E. Marchesi
> On 6/12/24 09:55, Jose E. Marchesi wrote: >> >> Hi Faust. >> Thanks for the patch. >> Please see a question below. >> >>> This patch enables -gprune-btf by default in the BPF backend when >>> generating BTF information, and fixes BPF CO-RE generation when using >>> -gprune-btf. >>> >>> When g

[PATCH] Whitespace cleanup for target-supports.exp

2024-06-12 Thread Patrick O'Neill
This patch removes trailing whitespace and replaces leading groups of 8-16 spaces with tabs. gcc/testsuite/ChangeLog: * lib/target-supports.exp: Cleanup whitespace. Signed-off-by: Patrick O'Neill --- Pre-approved here: https://inbox.sourceware.org/gcc-patches/3312c6a8-8f34-43f0-8562-99

Re: [PATCH 1/3] Remove ia64*-*-linux from the list of obsolete targets

2024-06-12 Thread Jonathan Wakely
On 12/06/24 19:40 +0100, Jonathan Wakely wrote: On 12/06/24 12:42 +0200, Rene Rebe wrote: The following un-deprecates ia64*-*-linux for GCC 15. Since we plan to support this for some years to come. gcc/ * config.gcc: Only exlicitly list ia64*-*-(hpux|vms|elf) in the "exlicitly"

[PATCH] c++: visibility wrt concept-id as targ [PR115283]

2024-06-12 Thread Patrick Palka
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- It seems we don't maintain visibility flags for concepts either, so min_vis_expr_r should ignore them for now, otherwise after r14-6789 we incorrectly give function templates that use a concept-id in their si

Re: [PATCH 2/3] Enabled LRA for ia64.

2024-06-12 Thread Jonathan Wakely
On 12/06/24 16:09 +0200, Frank Scheiner wrote: Dear Richard, On 12.06.24 13:01, Richard Biener wrote: [...] I can find two gcc-testresult postings, one appearantly with LRA and one without? Both from May: https://sourceware.org/pipermail/gcc-testresults/2024-May/816422.html https://sourceware

Re: [PATCH 3/3] Add power11 tests

2024-06-12 Thread Michael Meissner
On Wed, Jun 12, 2024 at 02:23:18PM +0800, Kewen.Lin wrote: > Hi Mike, > > > +# Return 1 if this is a PowerPC target supporting -mcpu=power11. > > + > > +proc check_effective_target_power11_ok { } { > > +if { ([istarget powerpc*-*-*]) } { > > + return [check_no_compiler_messages power11_ok ob

  1   2   >