Re: [PATCH 2/3] Flip default to LRA for targets with -mlra

Hello Richard, On Fri, 2025-05-02 at 12:12 +0200, Richard Biener wrote: > This flips the default to LRA for targets with an -mlra option not > using Mask(..). > > * config/avr/avr.opt (mlra): Flip to default on. > * config/m68k/m68k.opt (mlra): Likewise. > * config/pa/pa.opt (ml

Re: [PATCH 2/3] Flip default to LRA for targets with -mlra

Hi, On Sun, 2025-05-04 at 11:18 +0200, John Paul Adrian Glaubitz wrote: > On Fri, 2025-05-02 at 12:12 +0200, Richard Biener wrote: > > This flips the default to LRA for targets with an -mlra option not > > using Mask(..). > > > > * config/avr/avr.opt (mlra): Flip to default on. > > * conf

Re: [PATCH] Fortran: array subreferences and components of derived types [PR119986]

Hi Harald, This looks good to me both for mainline and backporting as far back as you wish. Thanks Paul On Sat, 3 May 2025 at 19:51, Harald Anlauf wrote: > Dear all, > > the attached, semi-obvious patch fixes bugging issues with passing of > array subreferences when either an inquiry referen

Re: [patch, Fortran] Fix PR 119928, rejects-valid 15/16 regression

Hi Harald, It appears that something is not right and generates wrong code with the check enabled.  Can you have another look? The problem was indeed that generating a formal from an actual arglist is a bad idea when classes are involved. Fixed in the attached patch. I think it still makes s

Re: [PATCH 0/3][RFC] Remove TARGET_LRA_P hook

On Sun, 4 May 2025, John Paul Adrian Glaubitz wrote: > > I only have non-BWX hardware and I'm not interested in decommissioning it > > or upgrading. There appear to be a few users around, but I seem to be the > > last GCC developer remaining who is willing to do anything about the port. > >

Re: [PATCH 0/3][RFC] Remove TARGET_LRA_P hook

Hi Maciej, On Sun, 2025-05-04 at 12:11 +0100, Maciej W. Rozycki wrote: > > What exactly is broken with the QEMU emulation in Alpha? I don't know of any > > bugs, but it could be that you have run into the nasty stack alignment issue > > in the kernel that was fixed in Linux 6.14. > > This was wi

[RFC PATCH 2/2] Add target_clones profile option support

This patch adds support for target_clones profile option. The target_clones profile option allows users to specify multiple versions of a function and select the version at runtime based on the specified profile. The profile is formatted as a string of ':' separated pairs of assembler name and tar

[RFC PATCH 1/2] Fortran: Do not make_decl_rtl in trans_function_start

This patch is a preparation for the function multi-versioning support in Fortran. The function multi-versioning support requires changing the change_decl_assembler_name to add the target suffix, which is not allowed after make_decl_rtl is called, since the assembler name will be in the constant poo

[RFC PATCH 0/2] Add target_clones profile option support

Hi everyone, This patch series introduces support for the target_clones profile option in GCC. This option enables users to specify target_clones attributes in a separate file, allowing GCC to generate multiple versions of the function with different ISA extensions based on the specified profile.

[PATCH 1/4] Loop-IM: Don't unconditional move conditional stmts during first LIM

While fixing up how rewrite_to_defined_overflow works, gcc.dg/Wrestrict-22.c started to fail. This is because `d p+ 2` would moved by LIM and then be rewritten not using pointer plus. The rewriting part is correct behavior. It only recently started to be moved out; due to r16-190-g6901d56fea2132

[PATCH 2/4] gimple: Add gimple_with_undefined_signed_overflow and use it [PR111276]

While looking into the ifcombine, I noticed that rewrite_to_defined_overflow was rewriting already defined code. In the previous attempt at fixing this, the review mentioned we should not be calling rewrite_to_defined_overflow in those cases. The places which called rewrite_to_defined_overflow didn

[PATCH 4/4] phiopt: Use rewrite_to_defined_overflow in move_stmt [PR116938]

As mentioned previously the rewrite in move_stmt should be using rewrite_to_defined_overflow/gimple_with_undefined_signed_overflow instead of just rewriting the VCE. This moves move_stmt over to that. A few testcases needed to be updated due to ABS_EXPR rewrite that happens. Bootstrapped and test

[PATCH 3/4] Rewrite VCEs of integral types [PR116939]

Like the patch to phiopt (r15-4033-g1f619fe25925a5f7), this adds rewriting of VCE to gimple_with_undefined_signed_overflow/rewrite_to_defined_overflow. I have not seen a case yet for needing this rewrite but this step is needed to use gimple_with_undefined_signed_overflow/rewrite_to_defined_overflo

RE: [PATCH] cobol: Rewrite exception handling. Partially refactor subscript/refmod calculations.

I know it's the weekend. But this has been niggling at me, so I decided to push it. > -Original Message- > From: Robert Dubner > Sent: Saturday, May 3, 2025 10:19 > To: gcc-patches@gcc.gnu.org > Cc: 'Jakub Jelinek' ; 'James K. Lowden' > > Subject: [PATCH] cobol: Rewrite exception handli

Re: [PATCH] PR tree-optimization/120048 - Allow IPA_CP to handle UNDEFINED as VARYING.

On Sat, May 3, 2025 at 4:42 PM Andrew MacLeod wrote: > > > On 5/3/25 07:41, Richard Biener wrote: > > On Sat, May 3, 2025 at 12:39 AM Andrew MacLeod wrote: > >> On trunk I'll eventually do something different.. but it will be more > >> invasive than I think is reasonable for a backport. > >> > >>

Re: [PATCH 1/4] Loop-IM: Don't unconditional move conditional stmts during first LIM

On Mon, May 5, 2025 at 3:42 AM Andrew Pinski wrote: > > While fixing up how rewrite_to_defined_overflow works, gcc.dg/Wrestrict-22.c > started > to fail. This is because `d p+ 2` would moved by LIM and then be rewritten > not using > pointer plus. The rewriting part is correct behavior. It only

Re: [PATCH 2/4] gimple: Add gimple_with_undefined_signed_overflow and use it [PR111276]

On Mon, May 5, 2025 at 3:42 AM Andrew Pinski wrote: > > While looking into the ifcombine, I noticed that rewrite_to_defined_overflow > was rewriting already defined code. In the previous attempt at fixing this, > the review mentioned we should not be calling rewrite_to_defined_overflow > in those

[PATCH 2/3] x86: Add a pass to fold tail call

x86 conditional branch (jcc) target can be either a label or a symbol. Add a pass to fold tail call with jcc by turning: jcc .L6 ... .L6: jmp tailcall into: jcc tailcall Immediately before the pass which turning REG_EH_REGION notes back into NOTE_INSN_EH_REGI

[PATCH 0/3] x86: Add a pass to fold tail call

Conditional and unconditional branch targets can be either a label or a symbol. For conditional jump: (jump_insn 7 6 14 2 (set (pc) (if_then_else (eq (reg:CCZ 17 flags) (const_int 0 [0])) (label_ref:DI 23) (pc))) "x.c":8:5 1458 {jcc} (expr_list

[PATCH 1/3] Support symbol reference in jump label and jump table

Conditional and unconditional branch targets can be either a label or a symbol. For conditional jump: (jump_insn 7 6 14 2 (set (pc) (if_then_else (eq (reg:CCZ 17 flags) (const_int 0 [0])) (label_ref:DI 23) (pc))) "x.c":8:5 1458 {jcc} (expr_list

[PATCH 3/3] x86: Fold sibcall targets into jump table

Enhance fold sibcall pass to fold sibcall targets into jump table by turning: foo: .cfi_startproc cmpl$4, %edi ja .L1 movl%edi, %edi jmp *.L4(,%rdi,8) .section.rodata .L4: .quad .L8 .quad .L7 .quad

Re: [PATCH 3/4] Rewrite VCEs of integral types [PR116939]

On Mon, May 5, 2025 at 3:45 AM Andrew Pinski wrote: > > Like the patch to phiopt (r15-4033-g1f619fe25925a5f7), this adds rewriting > of VCE to gimple_with_undefined_signed_overflow/rewrite_to_defined_overflow. > I have not seen a case yet for needing this rewrite but this step is needed > to use g

[to-be-committed][RISC-V] Adjust rvv tests after recent jump threading change

[ Resending with RISC-V tag. ] Richi's jump threading patch is resulting in new jump threading opportunities triggering in various vsetvl related tests. When those new threading opportunities are realized on vector code we usually end up with a different number of vsetvls due to the inherent

Re: [PATCH] RISC-V: Implment H modifier for printing the next register name

On 4/27/25 1:28 AM, Jin Ma wrote: For RV32 inline assembly, when handling 64-bit integer data, it is often necessary to process the lower and upper 32 bits separately. Unfortunately, we can only output the current register name (lower 32 bits) but not the next register name (upper 32 bits). T

[to-be-committed] Adjust rvv tests after recent jump threading change

Richi's jump threading patch is resulting in new jump threading opportunities triggering in various vsetvl related tests. When those new threading opportunities are realized on vector code we usually end up with a different number of vsetvls due to the inherent block copying. At first I was a

Re: [PATCH] Fortran: array subreferences and components of derived types [PR119986]

Hi Paul, Am 04.05.25 um 11:33 schrieb Paul Richard Thomas: Hi Harald, This looks good to me both for mainline and backporting as far back as you wish. thanks for the review! Committed as r16-376-gfceb6022798b58 so far. Will wait a week or so before starting a backport. Cheers, Harald Than

Re: [patch, Fortran] Fix PR 119928, rejects-valid 15/16 regression

Hi Thomas, Am 04.05.25 um 12:10 schrieb Thomas Koenig: Hi Harald, It appears that something is not right and generates wrong code with the check enabled.  Can you have another look? The problem was indeed that generating a formal from an actual arglist is a bad idea when classes are involved

[PATCH] RISC-V: Fix gcc.target/riscv/predef-19.c [PR120054]

gcc/testsuite/ChangeLog: PR target/120054 * gcc.target/riscv/predef-19.c: Adjust testcase. --- gcc/testsuite/gcc.target/riscv/predef-19.c | 4 1 file changed, 4 deletions(-) diff --git a/gcc/testsuite/gcc.target/riscv/predef-19.c b/gcc/testsuite/gcc.target/riscv/predef-19.c

Re: [PATCH v6 1/2] RISC-V: Add intrinsics support for SiFive Xsfvcp extensions.

Hi Mark: Thanks for notifying me, fixed on the trunk :) [1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d3651f07bbf56837f019e366b75d01f197dab2f1 On Fri, May 2, 2025 at 4:31 AM Mark Wielaard wrote: > Hi Kito, > > Unfortunately this breaks bootstrap for riscv: > > ../../gcc/gcc/config/riscv/ge

[PATCH v2] Use incoming small integer argument value as if promoted

On Wed, Apr 30, 2025 at 2:43 PM Richard Biener wrote: > > On Tue, Apr 29, 2025 at 3:53 PM H.J. Lu wrote: > > > > On Tue, Apr 29, 2025 at 9:34 PM Richard Biener > > wrote: > > > > > > On Tue, Apr 29, 2025 at 2:33 PM H.J. Lu wrote: > > > > > > > > On Tue, Apr 29, 2025 at 6:46 PM Richard Biener >

[PATCH] RISC-V: Use vclmul for CRC expansion if available

If the vector version of clmul (vclmul) is available and the scalar one is not, use it for CRC expansion. gcc/Changelog: * config/riscv/bitmanip.md (crc_rev4): Check TARGET_ZVBC. (crc4): Likewise. * config/riscv/riscv.cc (expand_crc_using_clmul): Emit code using

Re: [PATCH] i386: Implement Thread Local Storage on Windows

gcc bootstrap works on my end pretty well, but you know what they say, no one likes an "It works on my device" developer :) In all seriousness, no observable problems were seen on my end, apart from all the existing ucrt64 programs failing to run because of the libstdc++ issue. I believe Liu Hao's

Re: [PATCH] RISC-V: Implment H modifier for printing the next register name

On Sun, 4 May 2025 08:45:25 -0600, Jeff Law wrote: > > > On 4/27/25 1:28 AM, Jin Ma wrote: > > For RV32 inline assembly, when handling 64-bit integer data, it is > > often necessary to process the lower and upper 32 bits separately. > > Unfortunately, we can only output the current register name

[V2][to-be-committed][RISC-V] Trivial permutation constant derivation

This is a patch from late 2024 (just before stage1 freeze), but I never pushed hard to the change, and thus never integrated it. It's mostly unchanged except for updating insn in the hash table after finding an optimizable case. We were holding the deleted insn in the hash table rather than t

Re: [PATCH][gcc13] PR tree-optimization/117287 - Backport new assume implementation

And now another PR was opened  (120887).  so perhaps I should apply it. If I don't hear a dissenting opinion, I'll Apply it monday PM to GCC 13. It is completely self contained to uses of complex ASSUME's as Jakub suggests it is... Andrew On 3/28/25 05:25, Jakub Jelinek wrote: On Fri, Mar 2

Re: [PATCH 0/3][RFC] Remove TARGET_LRA_P hook

On Sun, 4 May 2025, John Paul Adrian Glaubitz wrote: > > > What exactly is broken with the QEMU emulation in Alpha? I don't know of > > > any > > > bugs, but it could be that you have run into the nasty stack alignment > > > issue > > > in the kernel that was fixed in Linux 6.14. > > > > This