[committed] docs: Fix 2 typos

Hi! When looking into PR113572, I've noticed a typo in VECTOR_CST documentation and grep found pasto of it elsewhere. Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as obvious. 2024-01-25 Jakub Jelinek * doc/generic.texi (VECTOR_CST): Fix typo - petterns ->

[PATCH] convert: Fix test for out of bounds shift count [PR113574]

Hi! The following patch is miscompiled, because convert_to_integer_1 for LSHIFT_EXPR tests if the INTEGER_CST shift count is too high, but incorrectly compares it against TYPE_SIZE rather than TYPE_PRECISION. The type in question is unsigned _BitInt(1), which has TYPE_PRECISION 1, TYPE_SIZE 8, and

[Committed] RISC-V: Remove redundant full available computation [NFC]

Notice full available is computed evey round of earliest fusion which is redundant. Actually we only need to compute it once in phase 3. It's NFC patch and tested no regression. Committed. gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (pre_vsetvl::compute_vsetvl_def_data): Remove redu

Re: [PATCH] Fix a few vect gimple testcases for LLP64 targets (e.g. mingw) [PR113548]

On Thu, Jan 25, 2024 at 1:46 AM Andrew Pinski wrote: > > This fixes of the vect testcases which uses the gimple FE for LLP64 targets. > The testcases use directly `unsigned long` for the addition to pointers > when they should be using `__SIZETYPE__`. This changes to use that instead. OK > gcc/t

Re: [PATCH v2 5/5] Add documentation for musttail attribute

On Thu, Jan 25, 2024 at 07:51:21AM +0100, rep.dot@gmail.com wrote: > On 24 January 2024 20:30:45 CET, Andi Kleen wrote: > >--- > > gcc/doc/extend.texi | 16 > > 1 file changed, 16 insertions(+) > > > >diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi > >index 0bc586d120e7.

[PATCH] RISC-V: Add LCM delete block predecessors dump information

While looking into PR113469, I notice the LCM delete a vsetvl incorrectly. This patch add dump information of all predecessors for LCM delete vsetvl block for better debugging. Tested no regression. gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (get_all_predecessors): New function.

Re: [PATCH] convert: Fix test for out of bounds shift count [PR113574]

On Thu, 25 Jan 2024, Jakub Jelinek wrote: > Hi! > > The following patch is miscompiled, because convert_to_integer_1 for > LSHIFT_EXPR tests if the INTEGER_CST shift count is too high, but > incorrectly compares it against TYPE_SIZE rather than TYPE_PRECISION. > The type in question is unsigned _

Re: [PATCH] RISC-V: Add LCM delete block predecessors dump information

LGTM, it's always good to improve some debug for vsetvli insertion pass, it's really non-trivial optimization. On Thu, Jan 25, 2024 at 4:59 PM Juzhe-Zhong wrote: > > While looking into PR113469, I notice the LCM delete a vsetvl incorrectly. > > This patch add dump information of all predecessors

Re: [middle-end PATCH] Prefer PLUS over IOR in RTL expansion of multi-word shifts/rotates.

On Wed, Jan 24, 2024 at 4:50 PM Georg-Johann Lay wrote: > > > > Am 22.01.24 um 08:45 schrieb Richard Biener: > > On Fri, Jan 19, 2024 at 5:06 PM Georg-Johann Lay wrote: > >> > >> > >> > >> Am 18.01.24 um 20:54 schrieb Roger Sayle: > >>> > >>> This patch tweaks RTL expansion of multi-word shifts a

Re: Repost [PATCH 3/6] PowerPC: Add support for accumulators in DMR registers.

Hi Mike, on 2024/1/6 07:38, Michael Meissner wrote: > The MMA subsystem added the notion of accumulator registers as an optional > feature of ISA 3.1 (power10). In ISA 3.1, these accumulators overlapped with > the traditional floating point registers 0..31, but logically the accumulator > registe

Re: [PATCH] jit, Darwin: Implement library exports list.

Hi David, > On 24 Jan 2024, at 18:31, David Malcolm wrote: > > On Tue, 2024-01-16 at 11:10 +, Iain Sandoe wrote: >> Tested on x86_64, i686 Darwin and x86_64 Linux, >> OK for trunk? when ? >> thanks, >> Iain > > Hi Iain, thanks for the patch. > > I'll have to defer to your Darwin expertise

Re: [patch] gcn/mkoffload.cc: Fix SRAM_ECC and XNACK handling [PR111966]

On 24/01/2024 22:12, Tobias Burnus wrote: This patch fixes "-g" debug compilation for gfx1100 and gfx1030, which fail to link when "-g" is specified. The reason is: When using gfx1100 and compiling with '-g' I was running into an error because the eflags used for the debugger file has additional

[PATCH] Make gcc.target/arm/bics_3.c testcase a bit more generic [PR113542]

After fwprop improvement in r14-8319-g86de9b66480, codegen in bics_3.c test changed from "bics" to "bic" instruction, with the overall instruction stream remaining at the same quality. This patch makes the scan-assembler directive accept both "bics" and "bic". BEFORE r14-8319-g86de9b66480:

Re: [PATCH] tree-optimization/113576 - non-empty latch and may_be_zero vectorization

> On Jan 24, 2024, at 18:40, Richard Biener wrote: > > We can't support niters with may_be_zero when we end up with a > non-empty latch due to early exit peeling. At least not in > the simplistic way the vectorizer handles this now. Disallow > it again for exits that are not the last one. > >

Re: [PATCH] Make gcc.target/arm/bics_3.c testcase a bit more generic [PR113542]

On 25/01/2024 10:29, Maxim Kuvyrkov wrote: > After fwprop improvement in r14-8319-g86de9b66480, codegen in > bics_3.c test changed from "bics" to "bic" instruction, with > the overall instruction stream remaining at the same quality. > > This patch makes the scan-assembler directive accept both >

[pushed] aarch64: Avoid paradoxical subregs in UXTL split [PR113485]

g:74e3e839ab2d36841320 handled the UXTL{,2}-ZIP[12] optimisation in split1. The UXTL input is a 64-bit vector of N-bit elements and the result is a 128-bit vector of 2N-bit elements. The corresponding ZIP1 operates on 128-bit vectors of N-bit elements. This meant that the ZIP1 input had to be a

Re: [PATCH] aarch64: Fix movv8di for overlapping register and memory load [PR113550]

Andrew Pinski writes: > The split for movv8di is not ready to handle the case where the setting > register overlaps with the address of the memory that is being load. > Fixing the split than just making the output constraint as an early clobber > for this alternative. The split would first need to

[pushed] aarch64: Fix out-of-bounds ENCODED_ELT access [PR113572]

When generalising vector_cst_all_same, I'd forgotten to update VECTOR_CST_ENCODED_ELT to VECTOR_CST_ELT. The check deliberately looks at implicitly encoded elements in some cases. Tested on aarch64-linux-gnu & pushed. Richard gcc/ PR target/113572 * config/aarch64/aarch64-sve-b

[PATCH v1] C++: Support constexpr strings for asm statements

Some programing styles use a lot of inline assembler, and it is common to use very complex preprocessor macros to generate the assembler strings for the asm statements. In C++ there would be a typesafe alternative using templates and constexpr to generate the assembler strings, but unfortunately th

[PATCH] RISC-V: Fix incorrect LCM delete bug [VSETVL PASS]

This patch fixes the recent noticed bug in RV32 glibc. We incorrectly deleted a vsetvl: ... and a4,a4,a3 vmv.v.i v1,0 ---> Missed vsetvl cause illegal instruction report. vse8.v v1,0(a5) The root cause the laterin in LCM is incorrect.

[patch] gcn: Add missing space to ASM_SPEC in gcn-hsa.h

This patch avoids assembler warnings for gfx908 and gfx90a such as '-xnack-mattr=-sramecc' is not a recognized feature for this target(ignoring feature) as we pass -mattr=-xnack-mattr=-sramecc to the llvm-mc assembler. Solution: Add a space before the second '-mattr='. OK for mainline? To

Re: [PATCH] libgccjit: Allow comparing array types

Thanks. Can we please agree on some wording to use so I know when the patch can be pushed. Especially since we're now in stage 4, it would help me if you say something like "you can push to master". Regards. On Wed, 2024-01-24 at 12:14 -0500, David Malcolm wrote: > On Fri, 2024-01-19 at 16:55 -050

[PATCH] RISC-V: remove param riscv-vector-abi. [PR113538]

From: Yanzhang Wang Also adjust some of the tests for scan-assembly. The behavior is the same as --param=riscv-vector-abi before. gcc/ChangeLog: * config/riscv/riscv.cc (riscv_get_arg_info): Remove the flag. (riscv_fntype_abi): Ditto. * config/riscv/riscv.opt: Ditto. gc

[PATCH v2] RISC-V: remove param riscv-vector-abi. [PR113538]

From: Yanzhang Wang Also adjust some of the tests for scan-assembly. The behavior is the same as --param=riscv-vector-abi before. gcc/ChangeLog: * config/riscv/riscv.cc (riscv_get_arg_info): Remove the flag. (riscv_fntype_abi): Ditto. * config/riscv/riscv.opt: Ditto. gc

Re: [PATCH v2] RISC-V: remove param riscv-vector-abi. [PR113538]

lgtm Replied Message Fromyanzhang.w...@intel.comDate01/25/2024 21:06 Togcc-patches@gcc.gnu.org Ccjuzhe.zh...@rivai.ai,kito.ch...@sifive.com,pan2...@intel.com,yanzhang.w...@intel.comSubject[PATCH v2] RISC-V: remove param riscv-vector-abi. [PR113538]

RE: [PATCH v2] RISC-V: remove param riscv-vector-abi. [PR113538]

Committed, thanks Juzhe. Pan From: juzhe.zhong Sent: Thursday, January 25, 2024 9:08 PM To: Wang, Yanzhang Cc: gcc-patches@gcc.gnu.org; kito.ch...@sifive.com; Li, Pan2 ; Wang, Yanzhang Subject: Re: [PATCH v2] RISC-V: remove param riscv-vector-abi. [PR113538] lgtm Replied Message Fr

Re: [PATCH] RISC-V: Fix incorrect LCM delete bug [VSETVL PASS]

Use this reduced testcase, but please verify this in your end again. For the code change part, I would like to let other to review :P struct a { int b; int c : 1; int : 1; } d(); typedef struct { int e; struct { int f; }; } g; int i; char k, l, n; void *m; char *o; void h(); char *j(); vo

Re: [PATCH v3 0/2] RISC-V: Support CORE-V XCVSIMD extension

It's stage 4, so I think it would be great to not disturb code base too much, and adding intrinsic without adding VLS modes should be better way to go, and here is not really something serious coding style issue, just few minor indentation issue, so I gonna run regression to make not break anythin

[PATCH v2] aarch64: Fix eh_return for -mtrack-speculation [PR112987]

Recent commit introduced a conditional branch in eh_return epilogues that is not compatible with speculation tracking: commit 426fddcbdad6746fe70e031f707fb07f55dfb405 Author: Szabolcs Nagy CommitDate: 2023-11-27 15:52:48 + aarch64: Use br instead of ret for eh_return Refactor th

[PATCH v3 0/1] RISC-V: Support CORE-V XCVMEM extension

This patch series presents the comprehensive implementation of the MEM extension for CORE-V. Tested with riscv-gnu-toolchain on binutils, ld, gas and gcc testsuites to ensure its correctness and compatibility with the existing codebase. However, your input, reviews, and suggestions are invaluable

[PATCH v3 1/1] RISC-V: Add support for XCVmem extension in CV32E40P

XCVmem adds more loads and stores. To prevent non-XCVmem loads and stores from generating illegal XCVmem specific operands, constraint 'm' was redefined. 'm' does not accept POST_MODIFY or reg + reg addresses. Spec: github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md

[PATCH v4 1/1] RISC-V: Add support for XCVbitmanip extension in CV32E40P

Spec: github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md Contributors: Mary Bennett Nandni Jamnadas Pietra Ferreira Charlie Keaney Jessica Mills Craig Blackmore Simon Cook Jeremy Bennett Helene Chelin gcc/ChangeLog: * common/config/

[PATCH v4 0/1] RISC-V: Support CORE-V XCVBITMAIP extension

This patch series presents the comprehensive implementation of the BITMANIP extension for CORE-V. Tested with riscv-gnu-toolchain on binutils, ld, gas and gcc testsuites to ensure its correctness and compatibility with the existing codebase. However, your input, reviews, and suggestions are invalu

Re: [PATCH v2] aarch64: Fix eh_return for -mtrack-speculation [PR112987]

Szabolcs Nagy writes: > Recent commit introduced a conditional branch in eh_return epilogues > that is not compatible with speculation tracking: > > commit 426fddcbdad6746fe70e031f707fb07f55dfb405 > Author: Szabolcs Nagy > CommitDate: 2023-11-27 15:52:48 + > > aarch64: Use br inst

Re: [patch] gcn: Add missing space to ASM_SPEC in gcn-hsa.h

On 25/01/2024 12:44, Tobias Burnus wrote: This patch avoids assembler warnings for gfx908 and gfx90a such as '-xnack-mattr=-sramecc' is not a recognized feature for this target(ignoring feature) as we pass -mattr=-xnack-mattr=-sramecc to the llvm-mc assembler. Solution: Add a space before

Re: [PATCH v3 0/2] RISC-V: Support CORE-V XCVSIMD extension

pushed :) On Thu, Jan 25, 2024 at 9:53 PM Kito Cheng wrote: > > It's stage 4, so I think it would be great to not disturb code base > too much, and adding intrinsic without adding VLS modes should be > better way to go, and here is not really something serious coding > style issue, just few mino

[pushed] analyzer: fix defaults in compound assignments from non-zero offsets [PR112969]

Confusion in binding_cluster::maybe_get_compound_binding about whether offsets are relative to the start of the region or to the start of the cluster was leading to incorrect handling of default values, leading to false positives from -Wanalyzer-use-of-uninitialized-value, from -Wanalyzer-exposure-

Re: [PATCH] [testsuite] Fix pretty printers regexps for GDB output

On Wed, 24 Jan 2024 at 12:02, Jonathan Wakely wrote: > > On Wed, 24 Jan 2024 at 10:48, Christophe Lyon wrote: > > > > GDB emits end of lines as \r\n, we currently match the reverse \n\r, > > We currently match [\n\r]+ which should match any of \n, \r, \n\r or \r\n > Hmm, right, sorry I had this p

Re: [PATCH] RISC-V: Fix incorrect LCM delete bug [VSETVL PASS]

The non-test parts are OK IMHO. Regards Robin

Re: [PATCH] aarch64: Fix function multiversioning mangling

Andrew Carlotti writes: > It would be neater if the middle end for target_clones used a target > hook for version name mangling, so we only do version name mangling > once. However, that would require more intrusive refactoring that will > have to wait till Stage 1. > > > This patch builds upon t

Re: [PATCH] AArch64: Add -mcpu=cobalt-100

Hi, >> Add support for -mcpu=cobalt-100 (Neoverse N2 with a different implementer >> ID). >> >> Passes regress, OK for commit? > > Ok. Also OK to backport to GCC 13, 12 and 11? Cheers, Wilco

Re: [PATCH V3 1/4] RISC-V: Add non-vector types to dfa pipelines

LGTM, thanks. Regards Robin

Re: [PATCH V3 2/4] RISC-V: Add vector related pipelines

Thanks, that looks better IMHO. > +;; Copyright (C) 2011-2024 Free Software Foundation, Inc. > +;; Contributed by Andrew Waterman (and...@sifive.com). > +;; Based on MIPS target for GNU compiler. You might want to change that, as well as the date. While at it you can also fix the broken date in

Re: [PATCH V3 3/4] RISC-V: Use default cost model for insn scheduling

> Use default cost model scheduling on these test cases. All these tests > introduce scan dump failures with -mtune generic-ooo. Since the vector > cost models are the same across all three tunes, some of the tests > in PR113249 will be fixed with this patch series. This is OK, thanks. > 39 addit

Re: [PATCH V3 4/4] RISC-V: Enable assert for insn_has_dfa_reservation

>/* If we ever encounter an insn without an insn reservation, trip > an assert so we can find and fix this problem. */ > -#if 0 > + if (! insn_has_dfa_reservation_p (insn)) { > +print_rtl(stderr, insn); > +fprintf(stderr, "%d", get_attr_type (insn)); > + } >gcc_assert (insn

RE: [PATCH] AArch64: Add -mcpu=cobalt-100

> -Original Message- > From: Wilco Dijkstra > Sent: Thursday, January 25, 2024 5:00 PM > To: Kyrylo Tkachov ; GCC Patches patc...@gcc.gnu.org> > Cc: Richard Earnshaw ; Richard Sandiford > > Subject: Re: [PATCH] AArch64: Add -mcpu=cobalt-100 > > Hi, > > >> Add support for -mcpu=cobal

Re: [PATCH v4 1/4] libatomic: atomic_16.S: Improve ENTRY, END and ALIAS macro interface

Victor Do Nascimento writes: > The introduction of further architectural-feature dependent ifuncs > for AArch64 makes hard-coding ifunc `_i' suffixes to functions > cumbersome to work with. It is awkward to remember which ifunc maps > onto which arch feature and makes the code harder to maintain

Re: [libatomic PATCH] Fix testsuite regressions on ARM [raspberry pi].

On 1/11/24 15:55, Roger Sayle wrote: Hi Richard, As you've recommended, this issue has now been filed in bugzilla as PR other/113336. As explained in the new PR, libatomic's testsuite used to pass on armv6 (raspberry pi) in previous GCC releases, but the code was incorrect/non-synchronous; t

Re: [PATCH v4 2/4] libatomic: Add support for __ifunc_arg_t arg in ifunc resolver

Victor Do Nascimento writes: > With support for new atomic features in Armv9.4-a being indicated by > HWCAP2 bits, Libatomic's ifunc resolver must now query its second > argument, of type __ifunc_arg_t*. > > We therefore make this argument known to libatomic, allowing us to > query hwcap2 bits in

Re: [PATCH v4 3/4] libatomic: Enable LSE128 128-bit atomics for armv9.4-a

Victor Do Nascimento writes: > The armv9.4-a architectural revision adds three new atomic operations > associated with the LSE128 feature: > > * LDCLRP - Atomic AND NOT (bitclear) of a location with 128-bit > value held in a pair of registers, with original data loaded into > the same 2 regi

Re: [PATCH v4 4/4] aarch64: Add explicit checks for implicit LSE/LSE2 requirements.

Victor Do Nascimento writes: > At present, Evaluation of both `has_lse2(hwcap)' and > `has_lse128(hwcap)' may require issuing an `mrs' instruction to query > a system register. This instruction, when issued from user-space > results in a trap by the kernel which then returns the value read in > b

[PATCH 0/2] aarch64, bitint: Add support for _BitInt for AArch64 Little Endian

Hi, This patch series adds support for _BitInt for AArch64 when compiling for Little Endian. The first patch in the series fixes an issue that arises with support for AArch64, the second patch adds the backend support for it. Andre Vieira (2): bitint: Use TARGET_ARRAY_MODE for large bitints where

[PATCH 1/2] bitint: Use TARGET_ARRAY_MODE for large bitints where target supports it

This patch ensures we use TARGET_ARRAY_MODE to determine the storage mode of large bitints that are represented as arrays in memory. This is required to support such bitints for aarch64 and potential other targets with similar bitint specifications. Existing tests like gcc.dg/torture/bitint-25.c

[PATCH 2/2] aarch64: Add support for _BitInt

This patch adds support for C23's _BitInt for the AArch64 port when compiling for little endianness. Big Endianness requires further target-agnostic support and we therefor disable it for now. gcc/ChangeLog: * config/aarch64/aarch64.cc (TARGET_C_BITINT_TYPE_INFO): Declare MACRO.

Re: [RFC] Either fix or disable SME feature for `aarch64-w64-mingw32` target?

The 01/15/2024 17:21, Radek Barton wrote: v4-0001-Ifdef-.hidden-.type-and-.size-pseudo-ops-for-aarc.patch Description: v4-0001-Ifdef-.hidden-.type-and-.size-pseudo-ops-for-aarc.patch

Re: [RFC] Either fix or disable SME feature for `aarch64-w64-mingw32` target?

this patch added double notes on crt*.o and lse derived objects. (which does not seem to cause build break but some linkers may not like it) after #include "aarch64-asm.h" all gnu-stack and gnu-property related stuff should be removed since the header takes care of it.

[committed] MAINTAINERS: Update my email address

Updated my email address. Thanks, Chung-Lin From ffeab69e1ffc0405da3a9222c7b9f7a000252702 Mon Sep 17 00:00:00 2001 From: Chung-Lin Tang Date: Thu, 25 Jan 2024 18:20:43 + Subject: [PATCH] MAINTAINERS: Update my work email address * MAINTAINERS: Update my work email address. --- MAIN

RE: [x86 PATCH] PR target/106060: Improved SSE vector constant materialization.

Hi Hongtao, Many thanks for the review. Here's a revised version of my patch that addresses (most of) the issues you've raised. Firstly the handling of zero and all_ones in this function is mostly for completeness/documentation, these standard_sse_constant_p values are (currently/normally) hand

[PATCH] c++: Fix up build_m_component_ref [PR113599]

Hi! The following testcase reduced from GDB is miscompiled starting with r14-5503 PR112427 change. The problem is in the build_m_component_ref hunk, which changed - datum = fold_build_pointer_plus (fold_convert (ptype, datum), component); + datum = cp_convert (ptype, datum, complain); +

[PATCH] c++: problematic assert in reference_binding [PR113141]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/13? This isn't a very satisfactory fix, but at least it safely fixes these testcases I guess. Note that there's implementation disagreement about the second testcase, GCC always accepted it but Clang/MSVC/icc reject it

Re: [PATCH] c++: Fix up build_m_component_ref [PR113599]

On Thu, 25 Jan 2024, Jakub Jelinek wrote: > Hi! > > The following testcase reduced from GDB is miscompiled starting with > r14-5503 PR112427 change. > The problem is in the build_m_component_ref hunk, which changed > - datum = fold_build_pointer_plus (fold_convert (ptype, datum), > componen

Re: [PATCH] c++: Fix up build_m_component_ref [PR113599]

On Thu, 25 Jan 2024, Patrick Palka wrote: > On Thu, 25 Jan 2024, Jakub Jelinek wrote: > > > Hi! > > > > The following testcase reduced from GDB is miscompiled starting with > > r14-5503 PR112427 change. > > The problem is in the build_m_component_ref hunk, which changed > > - datum = fold_b

Re: [PATCH 2/2] aarch64: Add support for _BitInt

Andre Vieira writes: > This patch adds support for C23's _BitInt for the AArch64 port when compiling > for little endianness. Big Endianness requires further target-agnostic > support and we therefor disable it for now. > > gcc/ChangeLog: > > * config/aarch64/aarch64.cc (TARGET_C_BITINT_TYP

[pushed][PR113526][LRA]: Fixing asm-flag-1.c failure on ARM

The following patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113526 The patch was successfully bootstrapped and tested on x86-64, ppc64le, and aarch64. commit 5c617df410602d0e51d61c84d1ae7e9b3f51efa4 Author: Vladimir N. Makarov Date: Thu Jan 25 14:41:17 2024 -0500 [PR113526]

Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls

Am 23.01.2024 um 23:37 schrieb Ian Lance Taylor: On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote: Am 03.01.2024 um 00:12 schrieb Björn Schäpers: Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor: On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote: From: Björn Schäpers Fixes https://

[PATCH] aarch64: Fix undefinedness while testing the J constraint [PR100204]

The J constraint can invoke undefined behavior due to it taking the negative of the ival if ival was HWI_MIN. The fix is simple as casting to `unsigned HOST_WIDE_INT` before doing the negative of it. This does that. Committed as obvious after build/test for aarch64-linux-gnu. gcc/ChangeLog:

Re: [PATCH v2 3/5] C: Implement musttail attribute for returns

On Wed, 24 Jan 2024, Andi Kleen wrote: > Implement a C23 clang compatible musttail attribute similar to the earlier > C++ implementation in the C parser. I'd expect diagnostics, and associated tests of those diagnostics, for: * musttail attribute used with any arguments, even empty [[gnu::mustt

Re: [PATCH v4 0/4]New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

Thanks a lot for the testing. Yes, I can repeat the issue with the following small example: #include #include #include #define MAX(a, b) ((a) > (b) ? (a) : (b)) struct untracked { int size; int array[] __attribute__((counted_by (size))); } *a; struct untracked * alloc_buf (in

[pushed] c++: co_await and initializer_list [PR109227]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Here we end up with an initializer_list of 'aa', a type with a non-trivial destructor, and need to destroy it. The code called build_special_member_call for cleanups, but that doesn't work for arrays, so use cxx_maybe_build_cleanup instead.

[pushed] c++: array of PMF [PR113598]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Here AGGREGATE_TYPE_P includes pointers to member functions, which is not what we want. Instead we should use class||array, as elsewhere in the function. PR c++/113598 gcc/cp/ChangeLog: * init.cc (build_vec_init): Don't u

Re: [PATCH v2 3/5] C: Implement musttail attribute for returns

On Thu, Jan 25, 2024 at 08:08:23PM +, Joseph Myers wrote: > On Wed, 24 Jan 2024, Andi Kleen wrote: > > > Implement a C23 clang compatible musttail attribute similar to the earlier > > C++ implementation in the C parser. > > I'd expect diagnostics, and associated tests of those diagnostics, fo

Re: [PATCH] libgccjit: Fix float playback for cross-compilation

Thanks for the review! On Wed, 2024-01-24 at 13:10 -0500, David Malcolm wrote: > On Thu, 2024-01-11 at 18:42 -0500, Antoni Boucher wrote: > > Hi. > > This patch fixes the bug 113343. > > I'm wondering if there's a better solution than using mpfr. > > The only other solution I found is real_from_st

[PATCH] Fortran: NULL actual to optional dummy with VALUE attribute [PR113377]

Dear all, this is the third patch in a series that addresses dummy arguments with the VALUE attribute, now handling the passing of NULL actual arguments. It is based on the refactoring in the previous patch and reuses the handling of absent arguments. Regtested on x86_64-pc-linux-gnu. OK for ma

ping: [PATCH] diagnostics: Fix behavior of permerror options after diagnostic pop [PR111918]

May I please ask again about this one? It's just a couple lines, and I think it fixes an important gap in the logic for #pragma GCC diagnostic. The PR was not reported by me so I think at least one other person does care about it :). Thanks! https://gcc.gnu.org/pipermail/gcc-patches/2023-November/

Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls

On Thu, Jan 25, 2024 at 11:53 AM Björn Schäpers wrote: > > Am 23.01.2024 um 23:37 schrieb Ian Lance Taylor: > > On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote: > >> > >> Am 03.01.2024 um 00:12 schrieb Björn Schäpers: > >>> Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor: > On Fri, Jan 2

ping: [PATCH] c-family: Fix ICE with large column number after restoring a PCH [PR105608]

Hello- May I please ping this small patch? Thanks https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639467.html -Lewis On Wed, Dec 20, 2023 at 8:02 PM Lewis Hyatt wrote: > > Hello- > > May I please ping this PCH patch? Thanks! > https://gcc.gnu.org/pipermail/gcc-patches/2023-December/

[patch] gcn/gcn-hsa.h: Always pass --amdhsa-code-object-version= in ASM_SPEC

When targeting AMD GPUs, the LLVM assembler (and linker) are used. Two days ago LLVM changed the default for theAMDHSA code object version (COV) from 4 to 5. In principle, we do not care which COV is used as long as it works; unfortunately, "mkoffload.cc" also generates an object file directly,

Re: [PATCH] c++: Fix up build_m_component_ref [PR113599]

On 1/25/24 14:14, Jakub Jelinek wrote: Hi! The following testcase reduced from GDB is miscompiled starting with r14-5503 PR112427 change. The problem is in the build_m_component_ref hunk, which changed - datum = fold_build_pointer_plus (fold_convert (ptype, datum), component); + datum

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

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, the kind of destination operand (

[Patch-2, rs6000] Eliminate unnecessary byte swaps for duplicated constant vector store [PR113325]

Hi, This patch creates an insn_and_split pattern which helps the duplicated constant vector replace the source pseudo of store insn in fwprop pass. Thus the store can be implemented by a single stxvd2x and it eliminates the unnecessary byte swap insn on P8 LE. The test case shows the optimization

Re: [x86 PATCH] PR target/106060: Improved SSE vector constant materialization.

On Fri, Jan 26, 2024 at 3:03 AM Roger Sayle wrote: > > > Hi Hongtao, > Many thanks for the review. Here's a revised version of my patch > that addresses (most of) the issues you've raised. Firstly the > handling of zero and all_ones in this function is mostly for > completeness/documentation, th

Re: [PATCH v2] c++: avoid -Wdangling-reference for std::span-like classes [PR110358]

Better version: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Real-world experience shows that -Wdangling-reference triggers for user-defined std::span-like classes a lot. We can easily avoid that by considering classes like template struct Span { T* data_;

[PATCH] c++: implement [[gnu::non_owning]] [PR110358]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Since -Wdangling-reference has false positives that can't be prevented, we should offer an easy way to suppress the warning. Currently, that is only possible by using a #pragma, either around the enclosing class or around the ca

[PATCH] c++: #pragma doesn't disable -Wunused-label [PR113582]

Low prio and not a regression. Feel free to ignore till GCC 15. Bootstrapped/regtested on x86_64-pc-linux-gnu. -- >8 -- The PR complains that void do_something(){ #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wunused-label" start:; #pragma GCC diagnostic pop }

[PATCH v4] c++/modules: Emit definitions of ODR-used static members imported from modules [PR112899]

On Wed, Jan 24, 2024 at 03:24:42PM -0500, Jason Merrill wrote: > On 1/20/24 05:45, Nathaniel Shead wrote: > > I also included > > your change to only add class variable templates to 'pending_statics' > > (and the normal 'static_decl's for non-class otherwise) as otherwise I > > could imagine that t

Re: [PATCH] c++: implement [[gnu::non_owning]] [PR110358]

On Thu, Jan 25, 2024 at 08:37:36PM -0500, Marek Polacek wrote: > +/* Handle a "non_owning" attribute; arguments as in > + struct attribute_spec.handler. */ > + > +tree > +handle_non_owning_attribute (tree *node, tree name, tree args, int, > + bool *no_add_attrs) I overl

Re: [PATCH v2] c++: avoid -Wdangling-reference for std::span-like classes [PR110358]

On 1/25/24 20:36, Marek Polacek wrote: Better version: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Real-world experience shows that -Wdangling-reference triggers for user-defined std::span-like classes a lot. We can easily avoid that by considering classes like

Re: [PATCH v4] c++/modules: Emit definitions of ODR-used static members imported from modules [PR112899]

On 1/25/24 21:28, Nathaniel Shead wrote: On Wed, Jan 24, 2024 at 03:24:42PM -0500, Jason Merrill wrote: On 1/20/24 05:45, Nathaniel Shead wrote: I also included your change to only add class variable templates to 'pending_statics' (and the normal 'static_decl's for non-class otherwise) as other

[PATCH] testsuite/vect: Fix pr25413a.c expectations [PR109705]

The 2 loops in octfapg_universe can and will be vectorized now after r14-333-g6d4b59a9356ac4 on targets that support multiplication in the long type. But the testcase does not check vect_long_mult for that, so this patch corrects that error and now the testcase passes correctly on aarch64-linux-gnu

[PATCH] aarch64: Fix/avoid undefinedness in aarch64_classify_index [PR100212]

The problem here is we don't check the return value of exact_log2 and always use that result as shifter. This fixes the issue by avoiding the shift if the value was `-1` (which means the value was not exact a power of 2); in this case we could either check if the values was equal to -1 or not equa

[PATCH v3] LoongArch: testsuite:Added additional vectorization "-mlsx" option.

gcc/testsuite/ChangeLog: * gcc.dg/signbit-2.c: Added additional "-mlsx" compilation options. * gfortran.dg/graphite/vect-pr40979.f90: Dito. * gfortran.dg/vect/fast-math-mgrid-resid.f: Dito. --- gcc/testsuite/gcc.dg/signbit-2.c | 1 + gcc/testsuite/gfo

[Committed V2] RISC-V: Fix incorrect LCM delete bug [VSETVL PASS]

This patch fixes the recent noticed bug in RV32 glibc. We incorrectly deleted a vsetvl: ... and a4,a4,a3 vmv.v.i v1,0 ---> Missed vsetvl cause illegal instruction report. vse8.v v1,0(a5) The root cause the laterin in LCM is incorrect.

Re: [Committed] RISC-V: Add regression test for vsetvl bug pr113429

This patch causes the following regression: FAIL: gcc.target/riscv/rvv/vsetvl/pr113429.c -O0 (test for excess errors) FAIL: gcc.target/riscv/rvv/vsetvl/pr113429.c -O1 (test for excess errors) FAIL: gcc.target/riscv/rvv/vsetvl/pr113429.c -O2 (test for excess errors) FAIL: gcc.target/riscv/

Re: [patch] gcn/gcn-hsa.h: Always pass --amdhsa-code-object-version= in ASM_SPEC

On Fri, Jan 26, 2024 at 12:04 AM Tobias Burnus wrote: > > When targeting AMD GPUs, the LLVM assembler (and linker) are used. > > Two days ago LLVM changed the default for the AMDHSA code object > version (COV) from 4 to 5. > > In principle, we do not care which COV is used as long as it works; > u

Re: [PATCH] testsuite/vect: Fix pr25413a.c expectations [PR109705]

On Fri, Jan 26, 2024 at 6:01 AM Andrew Pinski wrote: > > The 2 loops in octfapg_universe can and will be vectorized now > after r14-333-g6d4b59a9356ac4 on targets that support multiplication > in the long type. But the testcase does not check vect_long_mult for > that, so this patch corrects that

Re: [PATCH v3] LoongArch: testsuite:Added additional vectorization "-mlsx" option.

On Fri, Jan 26, 2024 at 7:23 AM chenxiaolong wrote: > > gcc/testsuite/ChangeLog: OK > * gcc.dg/signbit-2.c: Added additional "-mlsx" compilation options. > * gfortran.dg/graphite/vect-pr40979.f90: Dito. > * gfortran.dg/vect/fast-math-mgrid-resid.f: Dito. > --- > gcc/test

[PATCH v4 0/4] When cmodel=extreme, add macro support and only support macros.

v3 -> v4: 1. Add macro support for TLS symbols 2. Added support for loading __get_tls_addr symbol address using call36. 3. Merge template got_load_tls_{ld/gd/le/ie}. 4. Enable explicit reloc for extreme TLS GD/LD with -mexplicit-relocs=auto. v2 -> v3: 1. Modify the detection rules of a

[PATCH v4 3/4] LoongArch: Enable explicit reloc for extreme TLS GD/LD with -mexplicit-relocs=auto.

Binutils does not support relaxation using four instructions to obtain symbol addresses gcc/ChangeLog: * config/loongarch/loongarch.cc (loongarch_explicit_relocs_p): When the code model of the symbol is extreme and -mexplicit-relocs=auto, the macro instruction loading symb

[PATCH v4 4/4] LoongArch: Added support for loading __get_tls_addr symbol address using call36.

gcc/ChangeLog: * config/loongarch/loongarch.cc (loongarch_call_tls_get_addr): Add support for call36. gcc/testsuite/ChangeLog: * gcc.target/loongarch/explicit-relocs-medium-call36-auto-tls-ld-gd.c: New test. --- gcc/config/loongarch/loongarch.cc | 20 +++

[PATCH v4 2/4] LoongArch: Add the macro implementation of mcmodel=extreme.

gcc/ChangeLog: * config/loongarch/loongarch-protos.h (loongarch_symbol_extreme_p): Add function declaration. * config/loongarch/loongarch.cc (loongarch_symbolic_constant_p): For SYMBOL_PCREL64, non-zero addend of "la.local $rd,$rt,sym+addend" is not allowed

  1   2   >