[PATCH] Arm: Fix incorrect tailcall-generation for indirect calls [PR113780]

This patch fixes a bug that causes indirect calls in PAC-enabled functions to be tailcalled incorrectly when all argument registers R0-R3 are used. Tested on arm-none-eabi for armv8.1-m.main. OK for trunk? 2024-02-07 Tejas Belagod PR target/113780 * gcc/config/arm.cc

Re: [PATCH] wide-int: Fix mul_internal overflow handling [PR113753]

On Tue, 6 Feb 2024, Jakub Jelinek wrote: > Hi! > > As the following testcases show, the overflow (needs_overflow) and high > handling in wi::mul_internal seem to only work correctly for either > small precisions (less than or equal to 32, that is handled by earlier > simpler code, not the full

Re: Repost [PATCH 4/6] PowerPC: Make MMA insns support DMR registers.

On Sun, Feb 04, 2024 at 11:21:49AM +0800, Kewen.Lin wrote: > Hi Mike, > > > --- a/gcc/config/rs6000/mma.md > > +++ b/gcc/config/rs6000/mma.md > > @@ -559,190 +559,249 @@ (define_insn "*mma_disassemble_acc_dm" > >"dmxxextfdmr256 %0,%1,2" > >[(set_attr "type" "mma")]) > > > >

[PATCH RFA] build: drop target libs from LD_LIBRARY_PATH [PR105688]

Tested x86_64-pc-linux-gnu. Any thoughts? -- 8< -- The patch for PR22340 (r104978) moved the adding of TARGET_LIB_PATH to RPATH_ENVVAR from POSTSTAGE1_HOST_EXPORTS to HOST_EXPORTS, but didn't mention that in the ChangeLog; it also wasn't part of the patch that was sent to gcc-patches. I

Re: [PATCH] c++: Don't ICE for unknown parameter to constexpr'd switch-statement, PR113545

> Date: Mon, 22 Jan 2024 14:33:59 -0500 > From: Marek Polacek > On Mon, Jan 22, 2024 at 06:02:32PM +0100, Hans-Peter Nilsson wrote: > > I don't really know whether this is the right way to treat > > CONVERT_EXPR as below, but... Regtested native > > x86_64-linux-gnu. Ok to commit? > > Thanks

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

On Thu, Jan 25, 2024 at 05:28:49PM +0800, Kewen.Lin wrote: > 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

Ping*2 PATCH: testcase for "ICE for unknown parameter to constexpr'd switch-statement, PR113545"

> From: Hans-Peter Nilsson > Date: Tue, 30 Jan 2024 06:18:45 +0100 > Ping for the xfailed testsuite patch below the review > (actual constexpr.cc patch to be handled separately): Ping*2. Again, this is for the xfailed test-case only. > > > From: Hans-Peter Nilsson > > Date: Tue, 23 Jan 2024

[PATCH RFA] gdbhooks: regex syntax error

Briefly tested that break-on-pass completion works. Oddly, it also works without the patch, but the fix still seems worthwhile. OK for trunk? -- 8< -- Recent python complains about this pattern with SyntaxWarning: invalid escape sequence '\s' because \s in a regular string just means 's';

[PATCH] c++: NTTP type CTAD w/ tmpl from current inst [PR113649]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Since template argument coercion happens relative to the most general template (for a class template at least), during NTTP type CTAD we might need to consider outer arguments particularly if the CTAD

Re: [PATCH] c++: Disallow this specifier except for parameter declarations [PR113788]

On 2/6/24 15:45, Marek Polacek wrote: On Tue, Feb 06, 2024 at 09:37:44PM +0100, Jakub Jelinek wrote: Hi! The deducing this patchset added parsing of this specifier to cp_parser_decl_specifier_seq unconditionally, but in the C++ grammar this[opt] only appears in the parameter-declaration

[PATCH] wide-int: Fix mul_internal overflow handling [PR113753]

Hi! As the following testcases show, the overflow (needs_overflow) and high handling in wi::mul_internal seem to only work correctly for either small precisions (less than or equal to 32, that is handled by earlier simpler code, not the full Knuth's multiplication algorithm) or for precisions

Re: [PATCH] Fix disabling of year 2038 support on 32-bit hosts by default

Hello Andrew, Andrew Pinski writes: > On Mon, Feb 5, 2024 at 10:40 AM Thiago Jung Bauermann > wrote: >> >> >> Thiago Jung Bauermann writes: >> >> > Hello Luis, >> > >> > Luis Machado writes: >> >> >> >> Approved-By: Luis Machado >> > >> > Thanks! Since this is a patch for the repository

[PATCH] Fix disabling of year 2038 support on 32-bit hosts by default

Commit e5f2f7d901ee ("Disable year 2038 support on 32-bit hosts by default") fixed a mismatch between 64-bit time_t in GDB and system headers and 32-bit time_t in BFD. However, since commit 862776f26a59 ("Finalized intl-update patches") gnulib's year 2038 support has been accidentally re-enabled

Re: [PATCH] c++: Disallow this specifier except for parameter declarations [PR113788]

On Tue, Feb 06, 2024 at 09:37:44PM +0100, Jakub Jelinek wrote: > Hi! > > The deducing this patchset added parsing of this specifier to > cp_parser_decl_specifier_seq unconditionally, but in the C++ grammar > this[opt] only appears in the parameter-declaration non-terminal, so > rather than

[PATCH] range-op: Fix up ABSU_EXPR handling [PR113756]

Hi! ABSU_EXPR unary expr is special because it has a signed integer argument and unsigned integer result (of the same precision). The following testcase is miscompiled since ABSU_EXPR handling has been added to range-op because it uses widest_int::from with the result sign (i.e. UNSIGNED) rather

[PATCH] c++: Disallow this specifier except for parameter declarations [PR113788]

Hi! The deducing this patchset added parsing of this specifier to cp_parser_decl_specifier_seq unconditionally, but in the C++ grammar this[opt] only appears in the parameter-declaration non-terminal, so rather than checking in all the callers of cp_parser_decl_specifier_seq except for

Re: [PATCH] x86-64: Return 10_REG if there is no scratch register

On Tue, Feb 06, 2024 at 10:57:24AM -0800, H.J. Lu wrote: > If we can't find a scratch register for large model profiling, return > R10_REG. > > PR target/113689 > * config/i386/i386.cc (x86_64_select_profile_regnum): Return > R10_REG after sorry. Ok, thanks. Jakub

[PATCH] x86-64: Return 10_REG if there is no scratch register

If we can't find a scratch register for large model profiling, return R10_REG. PR target/113689 * config/i386/i386.cc (x86_64_select_profile_regnum): Return R10_REG after sorry. --- gcc/config/i386/i386.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH] RISC-V: Add support for B standard extension

On Tue, Feb 6, 2024 at 9:39 AM Edwin Lu wrote: > > This patch adds support for recognizing the B standard extension to be the > collection of Zba, Zbb, Zbs extensions for consistency and conciseness across > toolchains > > * https://github.com/riscv/riscv-b/tags Note this is/was recorded as PR

[PATCH] RISC-V: Add support for B standard extension

This patch adds support for recognizing the B standard extension to be the collection of Zba, Zbb, Zbs extensions for consistency and conciseness across toolchains * https://github.com/riscv/riscv-b/tags gcc/ChangeLog: * common/config/riscv/riscv-common.cc: Add imply rules for B

Re: [PATCH] libsanitizer: workaround libtool error when building in Yocto Kirkstone

Thanks for quick reply! If it's an inappropriate patch for GCC, should I try to send it to Yocto then? Alibek.

[PATCH] testsuite: Pattern does not match when using --specs=nano.specs

Ok for trunk and releases/gcc-13? --- When running the testsuite for newlib nano, the --specs=nano.specs option is used. This option prepends cpp_unique_options with "-isystem =/include/newlib-nano" so that the newlib nano header files override the newlib standard ones. As the -isystem option

Re: [PATCH] libsanitizer: workaround libtool error when building in Yocto Kirkstone

On Tue, Feb 6, 2024 at 8:53 AM Alibek Omarov wrote: > > Some libtool versions require --tag to be set and won't run compiler > without it, throwing an `unable to infer tagged configuration` error. > > I'm not sure whether it's a good idea to tag assembly files as a C source, > but it helps to

[PATCH] libsanitizer: workaround libtool error when building in Yocto Kirkstone

Some libtool versions require --tag to be set and won't run compiler without it, throwing an `unable to infer tagged configuration` error. I'm not sure whether it's a good idea to tag assembly files as a C source, but it helps to avoid the issue. Signed-off-by: Alibek Omarov ---

[pushed] c++: add fixed test [PR94231]

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- I was suprised to find out that r14-8759 fixed this accepts-invalid. clang version 17.0.6 rejects the test as well; clang version 19.0.0git crashes for which I opened . PR

Re: [PATCH] testsuite: Add a test case for negating FP vectors containing zeros

On Tue, 2024-02-06 at 17:55 +0800, Xi Ruoyao wrote: > Recently I've fixed two wrong FP vector negate implementation which > caused wrong sign bits in zeros in targets (r14-8786 and r14-8801).  To > prevent a similar issue from happening again, add a test case. > > Tested on x86_64 (with SSE2,

LoongArch: Backport r14-4674 "LoongArch: Delete macro definition ASM_OUTPUT_ALIGN_WITH_NOP."?

Hi Lulu, I'm proposing to backport r14-4674 "LoongArch: Delete macro definition ASM_OUTPUT_ALIGN_WITH_NOP." to releases/gcc-12 and releases/gcc-13. The reasons: 1. Strictly speaking, the old ASM_OUTPUT_ALIGN_WITH_NOP macro may cause a correctness issue. For example, a developer may use

New Chinese (simplified) PO file for 'gcc' (version 13.2.0)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Chinese (simplified) team of translators. The file is available at: https://translationproject.org/latest/gcc/zh_CN.po (This file,

[committed] aarch64: Fix build against libc++ in c++11 mode [PR113763]

Hi! std::pair ctor used in tiles constexpr variable is only constexpr in C++14 and later, it works with libstdc++ because it is marked constexpr there even in C++11 mode. The following patch fixes it by using an unnamed local class instead of std::pair, and additionally changes the first element

[committed] aarch64: Fix function multiversioning mangling

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. I've made the changes Richard Sandiford requested, and merged

Re: [PATCH]middle-end: fix ICE when moving statements to empty BB [PR113731]

On Tue, 6 Feb 2024, Jakub Jelinek wrote: > On Mon, Feb 05, 2024 at 03:31:20PM +0100, Richard Biener wrote: > > On Mon, 5 Feb 2024, Tamar Christina wrote: > > > > It looks like LOOP_VINFO_EARLY_BRK_STORES is "reverse"? Is that > > > > why you are doing gsi_move_before + gsi_prev? Why do gsi_prev

Re: [PATCH]middle-end: fix ICE when moving statements to empty BB [PR113731]

On Mon, Feb 05, 2024 at 03:31:20PM +0100, Richard Biener wrote: > On Mon, 5 Feb 2024, Tamar Christina wrote: > > > It looks like LOOP_VINFO_EARLY_BRK_STORES is "reverse"? Is that > > > why you are doing gsi_move_before + gsi_prev? Why do gsi_prev > > > at all? > > > > > > > As discussed on

Re: [PATCH 0/4] Add DF_LIVE_SUBREG data and apply to IRA and LRA

On 2/5/24 11:10, Jeff Law wrote: On 2/5/24 00:01, Lehua Ding wrote: For SPEC INT 2017, when using upstream GCC (whitout these patches), I get a coredump when training the peak case, so no data yet. The cause of the core dump still needs to be investigated. Typo, SPEC INT 2017 -> SPEC FP

[PATCH] AArch64: Update system register database.

With the release of Binutils 2.42, this brings the level of system-register support in GCC in line with the current state-of-the-art in Binutils, ensuring everything available in Binutils is plainly accessible from GCC. Where Binutils uses a more detailed description of which features are

Re: [PATCH] RISC-V: Allow LICM hoist POLY_INT configuration code sequence

> The root cause is this following RTL pattern, after fwprop1: > > (insn 82 78 84 9 (set (reg:DI 230) >         (sign_extend:DI (minus:SI (subreg/s/v:SI (reg:DI 150 [ niters.10 ]) 0) >                 (subreg:SI (reg:DI 221) 0 13 {subsi3_extended} >      (expr_list:REG_EQUAL (sign_extend:DI

Re: [PATCH] libgccjit: Add ability to get CPU features

David: Ping. On Tue, 2024-01-30 at 10:50 -0500, Antoni Boucher wrote: > David: I'm unsure what to do here. It seems we cannot find a > reviewer. > Would it help if I show you the code in gccrs that is similar? > Would it help if I ask someone from gccrs to review this code? > > On Sat,

RE: [PATCH v1] RISC-V: Bugfix for RVV overloaded intrinisc ICE when empty args

All passed, include overloaded and non-overloaded. # of expected passes10885 Pan From: Li, Pan2 Sent: Tuesday, February 6, 2024 4:17 PM To: juzhe.zh...@rivai.ai; gcc-patches Cc: Wang, Yanzhang ; kito.cheng Subject: RE: [PATCH v1] RISC-V: Bugfix for RVV overloaded intrinisc ICE

Re: [PATCH] RISC-V: Fix infinite compilation of VSETVL PASS

> Testing is running. Ok for trunk if I passed the testing with no > regression ? OK. Regards Robin

[PATCH] ranger: Grow BBs in relation oracle as needed [PR113735]

The relation oracle grows the internal vector of SSAs as needed, but due to an oversight was not growing the basic block vector. This fixes the oversight. OK for trunk? PR tree-optimization/113735 gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/pr113735.c: New test. gcc/ChangeLog:

Re: [PATCH] asan: Don't fold some strlens with -fsanitize=address [PR110676]

On Tue, 6 Feb 2024, Jakub Jelinek wrote: > Hi! > > The UB on the following testcase isn't diagnosed by -fsanitize=address, > because we see that the array has a single element and optimize the > strlen to 0. I think it is fine to assume e.g. for range purposes the > lower bound for the strlen

Re: [PATCH] lower-bitint: Encode address space qualifiers in VIEW_CONVERT_EXPRs [PR113736]

On Tue, 6 Feb 2024, Jakub Jelinek wrote: > Hi! > > As discussed in the PR, e.g. build_fold_addr_expr needs TYPE_ADDR_SPACE > on the outermost reference rather than just on the base, so the > following patch makes sure to propagate the address space from > the accessed var to the MEM_REFs and/or

Re: [PATCH] tree-ssa-math-opts: Fix up convert_{mult, plusminus}_to_widen [PR113759]

On Tue, 6 Feb 2024, Jakub Jelinek wrote: > Hi! > > On the following testcase we emit invalid stmt: > error: type mismatch in ?widen_mult_plus_expr? > 6 | foo (int c, int b) > | ^~~ > unsigned long > int > unsigned int > unsigned long > _31 = WIDEN_MULT_PLUS_EXPR ; > > The recent

[PATCH] middle-end/113576 - avoid out-of-bound vector element access

The following avoids accessing out-of-bound vector elements when native encoding a boolean vector with sub-BITS_PER_UNIT precision elements. The error was basing the number of elements to extract on the rounded up total byte size involved and the patch bases everything on the total number of

[PATCH v5 RESEND] C, ObjC: Add -Wunterminated-string-initialization

Warn about the following: char s[3] = "foo"; Initializing a char array with a string literal of the same length as the size of the array is usually a mistake. Rarely is the case where one wants to create a non-terminated character sequence from a string literal. In some cases, for writing

Re: [PATCH] libssp: Fix gets-chk.c compilation on Solaris

On Tue, Feb 06, 2024 at 11:33:17AM +0100, Rainer Orth wrote: > 2023-12-07 Rainer Orth > > libssp: > * configure.ac (AC_CHECK_DECLS): Check for gets. > * configure, config.h.in: Regenerate. > * gets-chk.c (gets): Guard declaration with !HAVE_DECL_GETS. Ok, thanks.

Re: [PATCH] libssp: Fix gets-chk.c compilation on Solaris

Hi Jakub, sorry for dropping the ball on this. > On Mon, Dec 04, 2023 at 11:42:09AM +0100, Rainer Orth wrote: >> The recent warning patches broke the libssp build on Solaris: >> >> /vol/gcc/src/hg/master/local/libssp/gets-chk.c: In function '__gets_chk': >>

[PATCH] asan: Don't fold some strlens with -fsanitize=address [PR110676]

Hi! The UB on the following testcase isn't diagnosed by -fsanitize=address, because we see that the array has a single element and optimize the strlen to 0. I think it is fine to assume e.g. for range purposes the lower bound for the strlen as long as we don't try to optimize strlen (str) where

[PATCH] lower-bitint: Encode address space qualifiers in VIEW_CONVERT_EXPRs [PR113736]

Hi! As discussed in the PR, e.g. build_fold_addr_expr needs TYPE_ADDR_SPACE on the outermost reference rather than just on the base, so the following patch makes sure to propagate the address space from the accessed var to the MEM_REFs and/or VIEW_CONVERT_EXPRs used to access those.

[PATCH] tree-ssa-math-opts: Fix up convert_{mult, plusminus}_to_widen [PR113759]

Hi! On the following testcase we emit invalid stmt: error: type mismatch in ‘widen_mult_plus_expr’ 6 | foo (int c, int b) | ^~~ unsigned long int unsigned int unsigned long _31 = WIDEN_MULT_PLUS_EXPR ; The recent PR113560 r14-8680 changes tweaked convert_mult_to_widen, but didn't

Re: [PATCH V1] RISC-V: Add mininal support for zabha extension.

I am not sure it's worth adding a dedicated instruction pattern for those instructions? In theory those instructions should just be used by those atomic builin when zabha has enabled, but I think that would be kinda of a bigger work item. On Tue, Feb 6, 2024 at 5:18 PM wrote: > > From: yulong >

[PATCH] testsuite: Add a test case for negating FP vectors containing zeros

Recently I've fixed two wrong FP vector negate implementation which caused wrong sign bits in zeros in targets (r14-8786 and r14-8801). To prevent a similar issue from happening again, add a test case. Tested on x86_64 (with SSE2, AVX, AVX2, and AVX512F), AArch64, MIPS (with MSA), LoongArch

Re: [PATCH v2] openmp, fortran: Add Fortran support for indirect clause on the declare target directive

Oops. I thought exactly the same thing yesterday, but forgot to add the changes to my commit! Here is the updated version. Kwok On 06/02/2024 9:03 am, Tobias Burnus wrote: LGTM. I just wonder whether there should be a value test and not just a does-not-crash-when-called test for the latter

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

ping? On Thu, 25 Jan 2024 at 16:54, Christophe Lyon wrote: > > 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]+

[PATCH V1] RISC-V: Add mininal support for zabha extension.

From: yulong This patch add the mininal support for zabha extension. The doc url as follow: https://github.com/riscv/riscv-zabha/blob/v1.0-rc1/zabha.adoc There are have no amocas.[b|h] instructions, because the zacas extension is not merged. gcc/ChangeLog: *

Re: Ping: Re: [PATCH] libgcc: fix SEH C++ rethrow semantics [PR113337]

On 2/6/24 05:31, NightStrike wrote: On Mon, Feb 5, 2024, 06:53 Matteo Italia wrote: Il 31/01/24 04:24, LIU Hao ha scritto: 在 2024-01-31 08:08, Jonathan Yong 写道: On 1/24/24 15:17, Matteo Italia wrote: Ping! That's a one-line fix, and you can find all the details in the bugzilla entry. Also,

Re: [PATCH] libgcc: Export i386 symbols added after GCC_7.0.0 on Solaris [PR113700]

On Tue, Feb 06, 2024 at 10:00:18AM +0100, Rainer Orth wrote: > 2024-02-01 Rainer Orth > > libgcc: > * config/i386/libgcc-sol2.ver (GCC_14.0.0): Added all symbols from > i386/libgcc-glibc.ver (GCC_12.0.0, GCC_13.0.0, GCC_14.0.0). > * config/i386/libgcc-glibc.ver: Request

Re: [PATCH v2] openmp, fortran: Add Fortran support for indirect clause on the declare target directive

Kwok Cheung Yeung wrote: As previously discussed, this version of the patch adds code to emit a warning when a directive like this: !$omp declare target indirect(.true.) is encountered (i.e. a target directive containing at least one clause, but no to/enter clause, which appears to violate

[PATCH] libgcc: Export i386 symbols added after GCC_7.0.0 on Solaris [PR113700]

As reported in the PR, all libgcc x86 symbol versions added after GCC_7.0.0 were only added to i386/libgcc-glibc.ver, missing all of libgcc-sol2.ver, libgcc-bsd.ver, and libgcc-darwin.ver. This patch fixes this for Solaris/x86, adding all of them (GCC_1[234].0.0) as GCC_14.0.0 to not

Re: [PATCH 2/2] rtl-optimization/113255 - avoid re-associating REG_POINTER MINUS

On Mon, 5 Feb 2024, Jeff Law wrote: > > > On 2/5/24 01:15, Richard Biener wrote: > > >>> > >>> PR rtl-optimization/113255 > >>> * simplify-rtx.cc (simplify_context::simplify_binary_operation_1): > >>> Do not re-associate a MINUS with a REG_POINTER op0. > >> Nasty little set of problems.

Re: [PATCH] libstdc++: /dev/null is not accessible on Windows

On 2/5/24 19:38, Jonathan Wakely wrote: On Mon, 5 Feb 2024, 19:07 Torbjörn SVENSSON, wrote: Ok for trunk and releases/gcc-13? OK, thanks Done, pushed to master and releases/gcc-13.

RE: [PATCH v1] RISC-V: Bugfix for RVV overloaded intrinisc ICE when empty args

Not yet. It is long time since last round run, will make sure there is no surprises from that. Pan From: juzhe.zh...@rivai.ai Sent: Tuesday, February 6, 2024 4:11 PM To: Li, Pan2 ; gcc-patches Cc: Li, Pan2 ; Wang, Yanzhang ; kito.cheng Subject: Re: [PATCH v1] RISC-V: Bugfix for RVV

Re: [PATCH v1] RISC-V: Bugfix for RVV overloaded intrinisc ICE when empty args

Did you run the C compiler compile C++ intrinsic test ? juzhe.zh...@rivai.ai From: pan2.li Date: 2024-02-06 16:09 To: gcc-patches CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng Subject: [PATCH v1] RISC-V: Bugfix for RVV overloaded intrinisc ICE when empty args From: Pan Li There is

[PATCH v1] RISC-V: Bugfix for RVV overloaded intrinisc ICE when empty args

From: Pan Li There is one corn case when similar as below example: void test (void) { __riscv_vfredosum_tu (); } It will meet ICE because of the implement details of overloaded function in gcc. According to the rvv intrinisc doc, we have no such overloaded function with empty args.