[PATCH] c++, v2: Fix up decltype of non-dependent structured binding decl in template [PR92687]

On Thu, Feb 29, 2024 at 12:50:47PM +0100, Jakub Jelinek wrote: > finish_decltype_type uses DECL_HAS_VALUE_EXPR_P (expr) check for > DECL_DECOMPOSITION_P (expr) to determine if it is > array/struct/vector/complex etc. subobject proxy case vs. structured > binding using std::tuple_{size,element}. >

Re: [PATCH] calls: Fix up TYPE_NO_NAMED_ARGS_STDARG_P handling [PR107453]

On Fri, Mar 01, 2024 at 01:53:54AM -0300, Alexandre Oliva wrote: > On Feb 27, 2024, Richard Earnshaw wrote: > > > This one has been festering for a while; both Alexandre and Torbjorn > > have attempted to fix it recently, but I'm not sure either is really > > right... > > *nod* xref

Re:[PATCH 5/5] RISC-V: Support vmsxx.vx for autovec comparison of vec and imm

Hi, han. My comment for this patch is same as [PATCH 3/5] RISC-V: Support vmfxx.vf for autovec comparison of vec and imm --Original-- From: "demin.han"

Re:[PATCH 3/5] RISC-V: Support vmfxx.vf for autovec comparison of vec and imm

Hi, han. I understand you are trying to support optimize vector-splat_vector into vector-scalar in "expand" stage, that is, vv - vx or vv - vf. It's a known issue that we know for a long time. This patch is trying to transform vv-vf when the splat vector is duplicate from a constant (by

Re:[PATCH 4/5] RISC-V: Remove integer vector eqne pattern

Hi, han. My review comment of this patch is same as I said in: [PATCH 1/5] RISC-V: Remove float vector eqne pattern --Original-- From: "demin.han"

Re:[PATCH 2/5] RISC-V: Refactor expand_vec_cmp

LGTM. But please commit it with adding [NFC] into the title of this patch: RISC-V: Refactor expand_vec_cmp [NFC] --Original-- From: "demin.han"

Re:[PATCH 1/5] RISC-V: Remove float vector eqne pattern

Hello, han. Thanks for trying to optimize the codes. But I believe those vector-scalar patterns (eq/ne) you remove in this patch are necessary. This is the story: 1. For commutative RTL code in GCC like plus, eq, ne, ... etc, we known in semantic Both (eq: (reg) (vec_duplicate ... ) and

RE: [PATCH 0/5] RISC-V: Support vf and vx for autovec comparison of

Sorry for the unexpected truncation. Hi, vf and vx are not supported well when comparing vector and immediate in current autovec. For example, following insts generated for float type: flw vsetvli vfmv.v.f ... vmfxx.vv Two issues: 1. Additional vsetvl and vfmv instructions

[PATCH 4/5] RISC-V: Remove integer vector eqne pattern

We can unify eqne and other comparison operations. Tested on RV32 and RV64. gcc/ChangeLog: * config/riscv/predicates.md (comparison_except_eqge_operator): Only exclue ge (comparison_except_ge_operator): Ditto * config/riscv/riscv-string.cc (expand_rawmemchr): Use

[PATCH 3/5] RISC-V: Support vmfxx.vf for autovec comparison of vec and imm

Currently, following instructions generated in autovector: flw vsetvli vfmv.v.f ... vmfxx.vv Two issues: 1. Additional vsetvl and vfmv instructions 2. Occupy one vector register and may results in smaller lmul We expect: flw ... vmfxx.vf Tested on RV32 and

[PATCH 2/5] RISC-V: Refactor expand_vec_cmp

There are two expand_vec_cmp functions. They have same structure and similar code. We can use default arguments instead of overloading. Tested on RV32 and RV64. gcc/ChangeLog: * config/riscv/riscv-protos.h (expand_vec_cmp): Change proto * config/riscv/riscv-v.cc

[PATCH 5/5] RISC-V: Support vmsxx.vx for autovec comparison of vec and imm

Similar to previous float change, vmsxx.vx is needed. 1. Only those which can't match vi should use vx. 2. DImode is processed by sew64_scalar_helper. Tested on RV32 and RV64. gcc/ChangeLog: * config/riscv/riscv-v.cc (get_cmp_insn_code): Select scalar pattern (expand_vec_cmp):

[PATCH 1/5] RISC-V: Remove float vector eqne pattern

We can unify eqne and other comparison operations. Tested on RV32 and RV64 gcc/ChangeLog: * config/riscv/riscv-vector-builtins-bases.cc: Remove eqne cond * config/riscv/vector.md (@pred_eqne_scalar): Remove patterns (*pred_eqne_scalar_merge_tie_mask): Ditto

[PATCH 0/5] RISC-V: Support vf and vx for autovec comparison of

We expect: flw ... vmfxx.vf For simplicity of supporting vx and vf, two refactors completed first. 1. remove eqne pattern; any special case or reason for eqne when first added? 2. refactor duplicate code. demin.han (5): RISC-V: Remove float vector eqne pattern RISC-V: Refactor

Re: [PATCH] calls: Fix up TYPE_NO_NAMED_ARGS_STDARG_P handling [PR107453]

On Feb 27, 2024, Richard Earnshaw wrote: > This one has been festering for a while; both Alexandre and Torbjorn > have attempted to fix it recently, but I'm not sure either is really > right... *nod* xref https://gcc.gnu.org/pipermail/gcc-patches/2024-March/646926.html The patch I proposed was

Re: [PATCH] arm: fix c23 0-named-args caller-side stdarg

Hello, Matthew, Thanks for the review. On Feb 26, 2024, Matthew Malcomson wrote: > I think you're right that the AAPCS32 requires all arguments to be passed in > registers for this testcase. > (Nit on the commit-message: It says that your reading of the AAPCS32 > suggests > that the *caller*

Re: [PATCH] combine: Don't simplify paradoxical SUBREG on WORD_REGISTER_OPERATIONS [PR113010]

On 2/26/24 17:17, Greg McGary wrote: The sign-bit-copies of a sign-extending load cannot be known until runtime on WORD_REGISTER_OPERATIONS targets, except in the case of a zero-extending MEM load. See the fix for PR112758. 2024-02-22 Greg McGary PR rtl-optimization/113010

Re: [PATCH] LoongArch: Allow s9 as a register alias

在 2024/2/29 下午3:14, Xi Ruoyao 写道: The psABI allows using s9 as an alias of r22. gcc/ChangeLog: * config/loongarch/loongarch.h (ADDITIONAL_REGISTER_NAMES): Add s9 as an alias of r22. --- Bootstrapped and regtested on loongarch64-linux-gnu. Ok for trunk? I think a test is

libbacktrace patch committed: Read symbol table of debuginfo file

This patch to libbacktrace reads symbol tables from debuginfo files. These become another symbol table to search. This is needed if people use --strip-all rather than --strip-debug when adding a debuglink section. This fixes https://github.com/ianlancetaylor/libbacktrace/issues/113. Bootstrapped

[PATCH, rs6000] Add subreg patterns for SImode rotate and mask insert

Hi, This patch fixes regression cases in gcc.target/powerpc/rlwimi-2.c. In combine pass, SImode (subreg from DImode) lshiftrt is converted to DImode lshiftrt with an out AND. It matches a DImode rotate and mask insert on rs6000. Trying 2 -> 7: 2: r122:DI=r129:DI REG_DEAD r129:DI

Re: [PATCH] RISC-V: Add riscv_vector_cc function attribute

Ping. xu...@eswincomputing.com From: Li Xu Date: 2024-02-27 09:17 To: gcc-patches CC: kito.cheng; palmer; juzhe.zhong; zhengyu; xuli Subject: [PATCH] RISC-V: Add riscv_vector_cc function attribute From: xuli Standard vector calling convention variant will only enabled when function has

Re: [PATCH gcc] Hurd x86_64: add unwind support for signal trampoline code

Flavio Cruz, le mer. 28 févr. 2024 22:59:09 -0500, a ecrit: > Tested with some simple toy examples where an exception is thrown in the > signal handler. > > libgcc/ChangeLog: > * config/i386/gnu-unwind.h: Support unwinding x86_64 signal frames. > > Signed-off-by: Flavio Cruz Reviewed-by:

[PATCH] c++/modules: Stream definitions for implicit instantiations [PR114170]

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- An implicit instantiation has an initializer depending on whether DECL_INITIALIZED_P is set (like normal VAR_DECLs) which needs to be written to ensure that consumers of header modules properly emit definitions for these

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

On 2/29/24 19:12, Marek Polacek wrote: On Wed, Feb 28, 2024 at 06:03:54PM -0500, Jason Merrill wrote: Hmm, if we're also going to allow the attribute to be applied to a function, the name doesn't make so much sense. For a class, it says that the class refers to its initializer; for a

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

On Wed, Feb 28, 2024 at 06:03:54PM -0500, Jason Merrill wrote: > On 2/21/24 19:35, Marek Polacek wrote: > > On Fri, Jan 26, 2024 at 04:04:35PM -0500, Jason Merrill wrote: > > > On 1/25/24 20:37, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > >

[pushed] analyzer: fix ICE in call summarization [PR114159]

PR analyzer/114159 reports an ICE inside playback of call summaries for very low values of --param=analyzer-max-svalue-depth=VAL. Root cause is that call_summary_edge_info's ctor tries to evaluate the function ptr of a gimple call stmt and assumes it gets a function *, but with low values of

Re: [committed] Set num_threads to 50 on 32-bit hppa in two libgomp loop tests

On 2024-02-29 6:02 p.m., Thomas Schwinge wrote: Hi! On 2024-02-01T19:20:57+, John David Anglin wrote: Tested on hppa-unknown-linux-gnu. Committed to trunk. Set num_threads to 50 on 32-bit hppa in two libgomp loop tests We support a maximum of 50 threads on 32-bit hppa. What happens if

Re: [committed] Set num_threads to 50 on 32-bit hppa in two libgomp loop tests

Hi! On 2024-02-01T19:20:57+, John David Anglin wrote: > Tested on hppa-unknown-linux-gnu. Committed to trunk. > Set num_threads to 50 on 32-bit hppa in two libgomp loop tests > > We support a maximum of 50 threads on 32-bit hppa. What happens if you go higher? Curious, what/why is that

Re: [PATCH 1/3] Change 'v1' float and int code to fall back to v0

> "Jeff" == Jeff Law writes: >> I don't know how to fix this. Jeff> Me neither, but I can suggest a hacky workaround. FTR, I asked Jakub on irc and he fixed it, so thankfully I didn't have to resort to the hack :-) thanks, Tom

Re: [PATCH] Fortran: improve checks of NULL without MOLD as actual argument [PR104819]

On 2/29/24 12:56 PM, Harald Anlauf wrote: Dear all, here's a first patch addressing issues with NULL as actual argument: if the dummy is assumed-rank or assumed length, MOLD shall be present. There is also an interp on interoperability of c_sizeof and NULL pointers, for which we have a

Re: [PATCH] libgccjit: Add option to allow special characters in function names

Hi and thanks for the review. I thought it would be a bit weird to have an option to change which characters are allowed, but I can't think of a better solution. Here's the updated patch that now allow arbitrary characters. Le 2024-02-20 à 16 h 05, Iain Sandoe a écrit : On 20 Feb 2024, at

Re: [PATCH V3 2/2] rs6000: Load store fusion for rs6000 target using common infrastructure

Hi! On Mon, Feb 19, 2024 at 04:24:37PM +0530, Ajit Agarwal wrote: > --- a/gcc/config.gcc > +++ b/gcc/config.gcc > @@ -518,7 +518,7 @@ or1k*-*-*) > ;; > powerpc*-*-*) > cpu_type=rs6000 > - extra_objs="rs6000-string.o rs6000-p8swap.o rs6000-logue.o" > +

[PATCH] c++: Ensure DECL_CONTEXT is set for temporary vars [PR114005]

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? Alternatively we could update 'DECL_CONTEXT' only for 'make_temporary_var_for_ref_to_temp' in call.cc, as a more targetted fix, but I felt that this way it'd also fix any other similar issues that have gone uncaught so far. -- >8

Re: [PATCH] libgccjit: Add support for creating temporary variables

Hi and thanks for the review! Here's the updated patch. Le 2024-01-24 à 09 h 54, David Malcolm a écrit : On Fri, 2024-01-19 at 16:54 -0500, Antoni Boucher wrote: Hi. This patch adds a new way to create local variable that won't generate debug info: it is to be used for compiler-generated

[PATCH] c++/modules: depending local enums [PR104919, PR106009]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- For local enums defined in a non-template function or a function template instantiation it seems we neglect to make the function depend on the enum definition, which ultimately causes streaming to fail due

[PATCH] Fortran: improve checks of NULL without MOLD as actual argument [PR104819]

Dear all, here's a first patch addressing issues with NULL as actual argument: if the dummy is assumed-rank or assumed length, MOLD shall be present. There is also an interp on interoperability of c_sizeof and NULL pointers, for which we have a partially incorrect testcase

[PATCH] libstdc++-v3: Fix cmath math declarations and stub support for hppa64-*-hpux11*

This change fixes the C99 math function support in on hppa64-*-hpux11*. Tested on hppa64-hp-hpux11.11 and x86_64-linux-gnu. See: https://gcc.gnu.org/pipermail/gcc-testresults/2024-February/809158.html https://gcc.gnu.org/pipermail/gcc-testresults/2024-February/809101.html Okay for trunk? Dave

[PATCH v1 00/13] Add aarch64-w64-mingw32 target

Thank you for the initial review for v1! Work on refactoring, rebasing, and validating "[PATCH v2] Add aarch64-w64-mingw32 target" is in progress. The v2 x64 mingw target will also be fully tested to avoid regression due to refactoring. Please provide feedback if anything is missing. Changes

Re: [PATCH] c++: auto(x) partial substitution [PR110025, PR114138]

On Wed, 28 Feb 2024, Jason Merrill wrote: > On 2/27/24 15:48, Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > > OK for trunk and perhaps 13? > > > > -- >8 -- > > > > In r12-6773-g09845ad7569bac we gave CTAD placeholders a level of 0 and > > ensured

[PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

Thursday, February 29, 2024 6:56 PM Andrew Pinski (QUIC) wrote: > Looking at these results, this port is not in any shape or form to be > upstreamed > right now. Even simple -g will cause failures. > Note we don't need a clean testsuite run but the patch series is not even > allowing enabling

Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat

On Thu, Feb 29, 2024 at 09:36:43AM -0800, Jerry D wrote: > On 2/29/24 1:47 AM, Bernhard Reutner-Fischer wrote: > > > And, just for my own education, the length limitation of iomsg to 255 > > chars is not backed by the standard AFAICS, right? It's just our > > STRERR_MAXSZ? > > Yes, its what we

Re: [PATCH v1 00/13] Add aarch64-w64-mingw32 target

On Thu, Feb 29, 2024 at 11:26 AM Evgeny Karpov wrote: > > Monday, February 26, 2024 2:30 AM > NightStrike wrote: > > > To be clear, because of the refactoring, it will affect x86/x64 Windows > > targets. > > Can you do a testsuite run before and after and see that it doesn't get > > worse? > >

Re: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

On 29/02/2024 17:55, Andrew Pinski (QUIC) wrote: >> -Original Message- >> From: Maxim Kuvyrkov >> Sent: Thursday, February 29, 2024 9:46 AM >> To: Andrew Pinski (QUIC) >> Cc: Evgeny Karpov ; Andrew Pinski >> ; Richard Sandiford ; gcc- >> patc...@gcc.gnu.org; 10wa...@gmail.com;

Re: [PATCH] calls: Further fixes for TYPE_NO_NAMED_ARGS_STDARG_P handling [PR107453]

On Thu, Feb 29, 2024 at 05:51:03PM +, Richard Earnshaw (lists) wrote: > Oh, but wait! Perhaps that now falls into the initial 'if' clause and we > never reach the point where you pick zero. So perhaps I'm worrying about > nothing. If you are worried about the + else if

RE: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

> -Original Message- > From: Maxim Kuvyrkov > Sent: Thursday, February 29, 2024 9:46 AM > To: Andrew Pinski (QUIC) > Cc: Evgeny Karpov ; Andrew Pinski > ; Richard Sandiford ; gcc- > patc...@gcc.gnu.org; 10wa...@gmail.com; m...@harmstone.com; Zac > Walker ; Ron Riddle > ; Radek Barton >

[committed] libstdc++: Fix std::basic_format_arg::handle for BasicFormatters

Tested x86_64-linux. Pushed to trunk. -- >8 -- std::basic_format_arg::handle is supposed to format its value as const if that is valid, to reduce the number of instantiations of the formatter's format function. I made a silly typo so that it checks formattable_with not formattable_with, which

[committed] libstdc++: Fix conditions for using memcmp in std::lexicographical_compare_three_way [PR113960]

Tested aarch64-linux, powerpc-linux (power 7 BE), x86_64-linux. The bug reporter tested it on s390x too. Pushed to trunk. This should be backported too. -- >8 -- The change in r11-2981-g2f983fa69005b6 meant that std::lexicographical_compare_three_way started to use memcmp for unsigned integers

Re: [PATCH] calls: Further fixes for TYPE_NO_NAMED_ARGS_STDARG_P handling [PR107453]

On 29/02/2024 17:38, Jakub Jelinek wrote: > On Thu, Feb 29, 2024 at 05:23:25PM +, Richard Earnshaw (lists) wrote: >> On 29/02/2024 15:55, Jakub Jelinek wrote: >>> On Thu, Feb 29, 2024 at 02:14:05PM +, Richard Earnshaw wrote: > I tried the above on arm, aarch64 and x86_64 and that seems

Re: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

> On Feb 29, 2024, at 21:35, Andrew Pinski (QUIC) > wrote: > > > >> -Original Message- >> From: Evgeny Karpov >> Sent: Thursday, February 29, 2024 8:46 AM >> To: Andrew Pinski >> Cc: Richard Sandiford ; gcc- >> patc...@gcc.gnu.org; 10wa...@gmail.com; Maxim Kuvyrkov >> ;

[patch,avr,applied] PR target/114132: Sets up a frame without need

The condition when a frame pointer is required because arguments are passe on the stack was not exact, and there were situations when a frame was set up without a need for it. Johann -- AVR: target/114132 - Code sets up a frame pointer without need. The condition CUMULATIVE_ARGS.nregs == 0 in

Re: [PATCH] calls: Further fixes for TYPE_NO_NAMED_ARGS_STDARG_P handling [PR107453]

On Thu, Feb 29, 2024 at 05:23:25PM +, Richard Earnshaw (lists) wrote: > On 29/02/2024 15:55, Jakub Jelinek wrote: > > On Thu, Feb 29, 2024 at 02:14:05PM +, Richard Earnshaw wrote: > >>> I tried the above on arm, aarch64 and x86_64 and that seems fine, > >>> including the new testcase you

Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat

On 2/29/24 1:47 AM, Bernhard Reutner-Fischer wrote: On Wed, 28 Feb 2024 21:29:06 -0800 Jerry D wrote: The attached patch adds the error checks similar to the first patch previously committed. I noticed a redundancy in some defines MSGLEN and IOMSG_LEN so I consolidated this to one define in

RE: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

> -Original Message- > From: Evgeny Karpov > Sent: Thursday, February 29, 2024 8:46 AM > To: Andrew Pinski > Cc: Richard Sandiford ; gcc- > patc...@gcc.gnu.org; 10wa...@gmail.com; Maxim Kuvyrkov > ; m...@harmstone.com; Zac Walker > ; Ron Riddle ; Radek > Barton ; Andrew Pinski (QUIC) >

Re: [Patch] OpenMP/C++: Fix (first)private clause with member variables [PR110347] [was: [RFA/RFC] C++/OpenMP: Supporting (first)private for member variables [PR110347] - or VALUE_EXPR and gimplify]

On Sat, Feb 17, 2024 at 12:35:48AM +0100, Tobias Burnus wrote: > Hence, I now use this code, but also pass a flag to distinguish target > regions (→ map) from shared usage, assuming that it is needed for the > latter (otherwise, there wouldn't be that code). > > The issue only showed up for a

Re: [PATCH] calls: Further fixes for TYPE_NO_NAMED_ARGS_STDARG_P handling [PR107453]

On 29/02/2024 15:55, Jakub Jelinek wrote: > On Thu, Feb 29, 2024 at 02:14:05PM +, Richard Earnshaw wrote: >>> I tried the above on arm, aarch64 and x86_64 and that seems fine, >>> including the new testcase you added. >>> >> >> I should mention though, that INIT_CUMULATIVE_ARGS on arm ignores

Re: [PATCH] lto, Darwin: Fix offload section names.

Hi Iain, hello world, Thomas Schwinge wrote: On 2024-01-16T15:00:16+, Iain Sandoe wrote: ... diff --git a/gcc/lto-section-names.h b/gcc/lto-section-names.h index a743deb4efb..1cdadf36ec0 100644 --- a/gcc/lto-section-names.h +++ b/gcc/lto-section-names.h ... @@ -35,8 +39,14 @@ extern

[PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

Wednesday, February 28, 2024 2:00 AM Andrew Pinski wrote: > What does this mean with respect to C++ exceptions? Or you using SJLJ > exceptions support or the dwarf unwinding ones without SEH support? > I am not sure if SJLJ exceptions is well tested any more in GCC either. > > Also I have a

[PATCH v1 00/13] Add aarch64-w64-mingw32 target

Monday, February 26, 2024 2:30 AM NightStrike wrote: > To be clear, because of the refactoring, it will affect x86/x64 Windows > targets. > Can you do a testsuite run before and after and see that it doesn't get worse? > The full testsuite for all languages for Windows isn't in great shape, but

Re: [PATCH] i386: For noreturn functions save at least the bp register if it is used [PR114116]

Hello, On Tue, 27 Feb 2024, Jakub Jelinek wrote: > On Tue, Feb 27, 2024 at 10:13:14AM +0100, Jakub Jelinek wrote: > > For __libc_start_main, glibc surely just could use no_callee_saved_registers > > attribute, because that is typically the outermost frame in backtrace, > > there is no need to

[PATCH] calls: Further fixes for TYPE_NO_NAMED_ARGS_STDARG_P handling [PR107453]

On Thu, Feb 29, 2024 at 02:14:05PM +, Richard Earnshaw wrote: > > I tried the above on arm, aarch64 and x86_64 and that seems fine, > > including the new testcase you added. > > > > I should mention though, that INIT_CUMULATIVE_ARGS on arm ignores > n_named_args entirely, it doesn't need it

Re: [PATCH] lto, Darwin: Fix offload section names.

Hi Thomas, > On 29 Feb 2024, at 14:37, Thomas Schwinge wrote: > On 2024-01-16T15:00:16+, Iain Sandoe wrote: >> Currently, these section names have wrong syntax for Mach-O. >> Although they were added some time ago; recently added tests are >> now emitting them leading to new fails on

Re: [PATCH] libgccjit: Allow comparing array types

David: Ping. On Thu, 2024-01-25 at 07:52 -0500, Antoni Boucher wrote: > 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

[PATCH v1 00/13] Add aarch64-w64-mingw32 target

Friday, February 23, 2024 7:00 PM Richard Sandiford wrote: > Seconded. :) Thanks also for the very clear organisation of the series, and > for > commonising code rather than cut-&-pasting it. Thank you, Richard, for the valuable feedback. It is great to hear that the series structure is easy

Re: [PATCH] RISC-V: Update test expectancies with recent scheduler change

On Wed, 28 Feb 2024 02:24:40 PST (-0800), Robin Dapp wrote: I suggest specify -fno-schedule-insns to force tests assembler never change for any scheduling model. We already do that and that's the point - as I mentioned before, no scheduling is worse than default scheduling here (for some

Re: [PATCH] libgccjit: Add support for machine-dependent builtins

David: Ping. On Thu, 2024-02-15 at 09:32 -0500, Antoni Boucher wrote: > David: Ping > > On Thu, 2024-02-08 at 08:59 -0500, Antoni Boucher wrote: > > David: Ping. > > > > On Wed, 2024-01-10 at 18:58 -0500, Antoni Boucher wrote: > > > Here it is:

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

David: Ping. Iain: Ping. On Tue, 2024-02-13 at 13:37 -0500, Antoni Boucher wrote: > David: Ping. > > On Tue, 2024-02-06 at 07:54 -0500, Antoni Boucher wrote: > > 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

Re: [PATCH] i386: Guard noreturn no-callee-saved-registers optimization with -mnoreturn-no-callee-saved-registers [PR38534]

> On Thu, Feb 29, 2024 at 03:15:30PM +0100, Jan Hubicka wrote: > > I am not wed to the idea (just it appeared to me as an option to > > disabling this optimization by default). I still think it may make sense. > > Maybe I misunderstood your idea. > So, you are basically suggesting to go in a

Re: [PATCH] tree-profile: Don't instrument an IFUNC resolver nor its callees

On Thu, Feb 29, 2024 at 7:06 AM Jan Hubicka wrote: > > > > I am worried about scenario where ifunc selector calls function foo > > > defined locally and foo is also used from other places possibly in hot > > > loops. > > > > > > > > > So it is not really reliable fix (though I guess it will work

Re: [PATCH] i386: Guard noreturn no-callee-saved-registers optimization with -mnoreturn-no-callee-saved-registers [PR38534]

On Thu, Feb 29, 2024 at 03:15:30PM +0100, Jan Hubicka wrote: > I am not wed to the idea (just it appeared to me as an option to > disabling this optimization by default). I still think it may make sense. Maybe I misunderstood your idea. So, you are basically suggesting to go in a completely

Re: [PATCH] tree-profile: Don't instrument an IFUNC resolver nor its callees

> > I am worried about scenario where ifunc selector calls function foo > > defined locally and foo is also used from other places possibly in hot > > loops. > > > > > > > So it is not really reliable fix (though I guess it will work a lot of > > > > common code). I wonder what would be

Re: [PATCH] tree-profile: Don't instrument an IFUNC resolver nor its callees

On Thu, Feb 29, 2024 at 6:34 AM Jan Hubicka wrote: > > > On Thu, Feb 29, 2024 at 5:39 AM Jan Hubicka wrote: > > > > > > > We can't instrument an IFUNC resolver nor its callees as it may require > > > > TLS which hasn't been set up yet when the dynamic linker is resolving > > > > IFUNC symbols.

Re: [PATCH] lto, Darwin: Fix offload section names.

Hi Iain! On 2024-01-16T15:00:16+, Iain Sandoe wrote: > Currently, these section names have wrong syntax for Mach-O. > Although they were added some time ago; recently added tests are > now emitting them leading to new fails on Darwin. > > This adds a Mach-O variant for each. >

Re: [PATCH] tree-profile: Don't instrument an IFUNC resolver nor its callees

> On Thu, Feb 29, 2024 at 5:39 AM Jan Hubicka wrote: > > > > > We can't instrument an IFUNC resolver nor its callees as it may require > > > TLS which hasn't been set up yet when the dynamic linker is resolving > > > IFUNC symbols. Add an IFUNC resolver caller marker to symtab_node to > > >

Re: [PATCH] i386: Guard noreturn no-callee-saved-registers optimization with -mnoreturn-no-callee-saved-registers [PR38534]

On Thu, Feb 29, 2024 at 6:15 AM Jan Hubicka wrote: > > > On Thu, Feb 29, 2024 at 02:31:05PM +0100, Jan Hubicka wrote: > > > I agree that debugability of user core dumps is important here. > > > > > > I guess an ideal solution would be to change codegen of noreturn functions > > > to callee save

Re: [PATCH] i386: Guard noreturn no-callee-saved-registers optimization with -mnoreturn-no-callee-saved-registers [PR38534]

> On Thu, Feb 29, 2024 at 02:31:05PM +0100, Jan Hubicka wrote: > > I agree that debugability of user core dumps is important here. > > > > I guess an ideal solution would be to change codegen of noreturn functions > > to callee save all registers. Performance of prologue of noreturn > > function

Re: [PATCH] calls: Fix up TYPE_NO_NAMED_ARGS_STDARG_P handling [PR107453]

On 29/02/2024 14:10, Richard Earnshaw (lists) wrote: > On 27/02/2024 17:25, Jakub Jelinek wrote: >> On Tue, Feb 27, 2024 at 04:41:32PM +, Richard Earnshaw wrote: 2023-01-09 Jakub Jelinek PR target/107453 * calls.cc (expand_call): For calls with

Re: [PATCH] tree-profile: Don't instrument an IFUNC resolver nor its callees

On Thu, Feb 29, 2024 at 5:39 AM Jan Hubicka wrote: > > > We can't instrument an IFUNC resolver nor its callees as it may require > > TLS which hasn't been set up yet when the dynamic linker is resolving > > IFUNC symbols. Add an IFUNC resolver caller marker to symtab_node to > > avoid recursive

Re: [PATCH] calls: Fix up TYPE_NO_NAMED_ARGS_STDARG_P handling [PR107453]

On 27/02/2024 17:25, Jakub Jelinek wrote: > On Tue, Feb 27, 2024 at 04:41:32PM +, Richard Earnshaw wrote: >>> 2023-01-09 Jakub Jelinek >>> >>> PR target/107453 >>> * calls.cc (expand_call): For calls with >>> TYPE_NO_NAMED_ARGS_STDARG_P (funtype) use zero for n_named_args. >>>

Re: [PATCH] i386: Guard noreturn no-callee-saved-registers optimization with -mnoreturn-no-callee-saved-registers [PR38534]

On Thu, Feb 29, 2024 at 02:31:05PM +0100, Jan Hubicka wrote: > I agree that debugability of user core dumps is important here. > > I guess an ideal solution would be to change codegen of noreturn functions > to callee save all registers. Performance of prologue of noreturn > function is not too

Re: [PATCH] tree-profile: Don't instrument an IFUNC resolver nor its callees

> We can't instrument an IFUNC resolver nor its callees as it may require > TLS which hasn't been set up yet when the dynamic linker is resolving > IFUNC symbols. Add an IFUNC resolver caller marker to symtab_node to > avoid recursive checking. > > gcc/ChangeLog: > > PR

Re: [PATCH] i386: Guard noreturn no-callee-saved-registers optimization with -mnoreturn-no-callee-saved-registers [PR38534]

> > > > The problem is that it doesn't help in this case. > > If some optimization makes debugging of some function harder, normally it is > > enough to recompile the translation unit that defines it with -O0/-Og, or > > add optimize attribute on the function. > > While in this case, the

Re: [PATCH v2] DSE: Bugfix ICE after allow vector type in get_stored_val

On 2/29/24 02:38, Li, Pan2 wrote: >> So it's going to check if V2SF can be tied to DI and V4QI with SI. I >> suspect those are going to fail for RISC-V as those aren't tieable. > > Yes, you are right. Different REG_CLASS are not allowed to be tieable in > RISC-V. > > static bool >

Re: [PATCH] tree-optimization/114151 - handle POLY_INT_CST in get_range_pos_neg

On Thu, Feb 29, 2024 at 02:08:19PM +0100, Richard Biener wrote: > > So, wouldn't it be better to outline what you have above + POLY_INT_CST > > handling into a helper function, which similarly to get_range_pos_neg > > returns a bitmask, but rather than 1 bit for may be [0, max] and another > >

Re: [PATCH] i386: Guard noreturn no-callee-saved-registers optimization with -mnoreturn-no-callee-saved-registers [PR38534]

On Thu, Feb 29, 2024 at 1:47 PM Jakub Jelinek wrote: > > On Thu, Feb 29, 2024 at 04:26:00AM -0800, H.J. Lu wrote: > > > > Adding Hongtao and Honza into the loop as the ones who acked the > > > > original > > > > patch. > > > > > > > > The no_callee_saved_registers by default for noreturn

Re: [PATCH v3] RISC-V: Introduce gcc option mrvv-vector-bits for RVV

> I think it makes more sense to remove the whole > --param=riscv-autovec-preference since we should use > -fno-tree-vectorize instead of --param=riscv-autovec-preference=none > which is more reasonable compile option for users. > > --param is just a internal testing option that we added before,

Re: [PATCH] tree-optimization/114151 - handle POLY_INT_CST in get_range_pos_neg

On Thu, 29 Feb 2024, Jakub Jelinek wrote: > On Thu, Feb 29, 2024 at 09:21:02AM +0100, Richard Biener wrote: > > The following switches the logic in chrec_fold_multiply to > > get_range_pos_neg since handling POLY_INT_CST possibly mixed with > > non-poly ranges will make the open-coding awkward

Re: [PATCH] i386: Guard noreturn no-callee-saved-registers optimization with -mnoreturn-no-callee-saved-registers [PR38534]

On Thu, Feb 29, 2024 at 04:26:00AM -0800, H.J. Lu wrote: > > > Adding Hongtao and Honza into the loop as the ones who acked the original > > > patch. > > > > > > The no_callee_saved_registers by default for noreturn functions change can > > > break in-process backtrace(3) or backtraces from

Re: [PATCH] s390: Fix TARGET_SECONDARY_RELOAD for non-SYMBOL_REFs

On Thu, Feb 29, 2024 at 01:26:54PM +0100, Andreas Schwab wrote: > On Feb 29 2024, Stefan Schulze Frielinghaus wrote: > > > RTX X must not necessarily be a SYMBOL_REF and may e.g. be an > > False friend: s/must not/need not/ Argh I always fall for this ;-) Thanks for pointing this out. Changed

[PATCH v2] libstdc++: Add more nodiscard uses in

We need to add [[nodiscard]] to the comparison ops in too, which I missed in the v1 patch. Tested aarch64-linux. Pushed to trunk (yesterday). commit 26d6a714b29eeef77591f136f5162622a549d8fd Author: Jonathan Wakely Date: Mon Feb 26 13:09:02 2024 libstdc++: Add more nodiscard uses in

Re: [PATCH] i386: Guard noreturn no-callee-saved-registers optimization with -mnoreturn-no-callee-saved-registers [PR38534]

On Wed, Feb 28, 2024 at 10:20 PM Hongtao Liu wrote: > > On Wed, Feb 28, 2024 at 4:54 PM Jakub Jelinek wrote: > > > > Hi! > > > > Adding Hongtao and Honza into the loop as the ones who acked the original > > patch. > > > > The no_callee_saved_registers by default for noreturn functions change can

Re: [PATCH] s390: Fix TARGET_SECONDARY_RELOAD for non-SYMBOL_REFs

On Feb 29 2024, Stefan Schulze Frielinghaus wrote: > RTX X must not necessarily be a SYMBOL_REF and may e.g. be an False friend: s/must not/need not/ -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something

[PATCH] s390: Fix test vector/long-double-to-i64.c

Starting with r14-8319-g86de9b66480b71 fwprop improved so that vpdi is no longer required. gcc/testsuite/ChangeLog: * gcc.target/s390/vector/long-double-to-i64.c: Fix scan assembler directive. --- .../gcc.target/s390/vector/long-double-to-i64.c | 13 + 1 file

[PATCH] s390: Fix tests rosbg_si_srl and rxsbg_si_srl

Starting with r14-2047-gd0e891406b16dc two SI mode tests are optimized into DI mode. Thus, the scan-assembler directives fail. For example RTL expression (ior:SI (subreg:SI (lshiftrt:DI (reg:DI 69) (const_int 2 [0x2])) 4) (subreg:SI (reg:DI 68) 4)) is optimized into (ior:DI

[PATCH] s390: Fix TARGET_SECONDARY_RELOAD for non-SYMBOL_REFs

RTX X must not necessarily be a SYMBOL_REF and may e.g. be an UNSPEC_GOTENT for which SYMBOL_FLAG_NOTALIGN2_P fails. gcc/ChangeLog: * config/s390/s390.cc (s390_secondary_reload): Guard SYMBOL_FLAG_NOTALIGN2_P. --- gcc/config/s390/s390.cc | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH] dwarf2out: Don't move variable sized aggregates to comdat [PR114015]

Hi! The following testcase ICEs, because we decide to move that struct { char a[n]; } DW_TAG_structure_type into .debug_types section / DW_UT_type DWARF5 unit, but refer from there to a DW_TAG_variable (created artificially for the array bounds). Even with non-bitint, I think it is just wrong to

[PATCH] c++: Fix up decltype of non-dependent structured binding decl in template [PR92687]

Hi! finish_decltype_type uses DECL_HAS_VALUE_EXPR_P (expr) check for DECL_DECOMPOSITION_P (expr) to determine if it is array/struct/vector/complex etc. subobject proxy case vs. structured binding using std::tuple_{size,element}. For non-templates or when templates are already instantiated, that

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

On Thu, 2024-02-29 at 15:09 +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,

Re: [PATCH] middle-end/114070 - VEC_COND_EXPR folding

On Thu, Feb 29, 2024 at 11:16:54AM +0100, Richard Biener wrote: > That said, the quick experiment shows this isn't anything for stage4. The earlier the vector lowering is moved in the pass list, the higher are the possibilities that match.pd or some other optimization reintroduces unsupportable

Re: [PATCH] tree-optimization/114151 - handle POLY_INT_CST in get_range_pos_neg

On Thu, Feb 29, 2024 at 09:21:02AM +0100, Richard Biener wrote: > The following switches the logic in chrec_fold_multiply to > get_range_pos_neg since handling POLY_INT_CST possibly mixed with > non-poly ranges will make the open-coding awkward and while not > a perfect fit it should work. > > In

Re: [PATCH] middle-end/114070 - VEC_COND_EXPR folding

On Thu, 29 Feb 2024, Richard Biener wrote: > The following amends the PR114070 fix to optimistically allow > the folding when we cannot expand the current vec_cond using > vcond_mask and we're still before vector lowering. This leaves > a small window between vectorization and lowering where we

  1   2   >