Re: [committed] i386: Fix grammar typo in diagnostic

On Wed, 23 Aug 2023, 06:15 Hongtao Liu via Libstdc++, wrote: > On Wed, Aug 23, 2023 at 7:28 AM Hongtao Liu wrote: > > > > On Tue, Aug 8, 2023 at 5:22 AM Marek Polacek via Libstdc++ > > wrote: > > > > > > On Mon, Aug 07, 2023 at 10:12:35PM +0100, Jonathan Wakely via > Gcc-patches wrote: > > > >

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 22, 2023 at 4:36 PM Hongtao Liu wrote: > > On Tue, Aug 22, 2023 at 9:54 PM Jakub Jelinek wrote: > > > > On Tue, Aug 22, 2023 at 09:35:44PM +0800, Hongtao Liu wrote: > > > Ok, then we can't avoid TARGET_AVX10_1 in those existing 256/128-bit > > > evex instruction patterns. > > > > Why?

RE: Intel AVX10.1 Compiler Design and Support

> -Original Message- > From: Richard Biener > Sent: Wednesday, August 23, 2023 3:32 PM > To: Hongtao Liu > Cc: Jakub Jelinek ; Jiang, Haochen > ; ZiNgA BuRgA ; gcc- > patc...@gcc.gnu.org > Subject: Re: Intel AVX10.1 Compiler Design and Support > > On Tue, Aug 22, 2023 at 4:36 PM Hongtao

Re: [committed] i386: Fix grammar typo in diagnostic

On Wed, Aug 23, 2023 at 3:02 PM Jonathan Wakely wrote: > > > > On Wed, 23 Aug 2023, 06:15 Hongtao Liu via Libstdc++, > wrote: >> >> On Wed, Aug 23, 2023 at 7:28 AM Hongtao Liu wrote: >> > >> > On Tue, Aug 8, 2023 at 5:22 AM Marek Polacek via Libstdc++ >> > wrote: >> > > >> > > On Mon, Aug 07,

Re: Intel AVX10.1 Compiler Design and Support

On Wed, Aug 23, 2023 at 01:57:59AM +, Jiang, Haochen wrote: > > > Let's assume there's no detla now, AVX10.1-512 is equal to > > > AVX512{F,VL,BW,DQ,CD,BF16,FP16,VBMI,VBMI2,VNNI,IFMA,BITALG,VPOPCNTDQ} > > > > other stuff. > > > > The current common/config/i386/i386-common.cc OPTION_MASK_ISA*SET

Re: Intel AVX10.1 Compiler Design and Support

On Wed, Aug 23, 2023 at 3:33 PM Richard Biener wrote: > > On Tue, Aug 22, 2023 at 4:36 PM Hongtao Liu wrote: > > > > On Tue, Aug 22, 2023 at 9:54 PM Jakub Jelinek wrote: > > > > > > On Tue, Aug 22, 2023 at 09:35:44PM +0800, Hongtao Liu wrote: > > > > Ok, then we can't avoid TARGET_AVX10_1 in tho

Re: Intel AVX10.1 Compiler Design and Support

On Wed, Aug 23, 2023 at 4:16 PM Jakub Jelinek wrote: > > On Wed, Aug 23, 2023 at 01:57:59AM +, Jiang, Haochen wrote: > > > > Let's assume there's no detla now, AVX10.1-512 is equal to > > > > AVX512{F,VL,BW,DQ,CD,BF16,FP16,VBMI,VBMI2,VNNI,IFMA,BITALG,VPOPCNTDQ} > > > > > other stuff. > > > > >

Re: Intel AVX10.1 Compiler Design and Support

On Wed, Aug 23, 2023 at 08:03:58AM +, Jiang, Haochen wrote: > We could first work on -mevex512 then further discuss -mavx10.1-256/512 since > these -mavx10.1-256/512 is quite controversial. > > Just to clarify, -mno-evex512 -mavx512f should not enable 512 bit vector > right? I think it shoul

Re: Loop-ch improvements, part 3

> We seem to peel one iteration for no good reason. The loop is > a do-while loop already. The key is we see the first iteration > exit condition is known not taken and then: Hi, this is patch fixing wrong return value in should_duplicate_loop_header_p. Doing so uncovered suboptimal decisions on

Re: [PATCH V2] RISC-V: Add conditional unary neg/abs/not autovec patterns

OK, thanks. Regards Robin

Re: Intel AVX10.1 Compiler Design and Support

On Wed, Aug 23, 2023 at 4:31 PM Jakub Jelinek wrote: > > On Wed, Aug 23, 2023 at 08:03:58AM +, Jiang, Haochen wrote: > > We could first work on -mevex512 then further discuss -mavx10.1-256/512 > > since > > these -mavx10.1-256/512 is quite controversial. > > > > Just to clarify, -mno-evex512

Re: Loop-ch improvements, part 3

On Wed, 23 Aug 2023, Jan Hubicka wrote: > > We seem to peel one iteration for no good reason. The loop is > > a do-while loop already. The key is we see the first iteration > > exit condition is known not taken and then: > Hi, > this is patch fixing wrong return value in should_duplicate_loop_he

Fix profile update in tree-ssa-reassoc

Hi, this patch adds missing profile update to maybe_optimize_range_tests. Jakub, I hope I got the code right: I think it basically analyzes the chain of conditionals, finds some basic blocks involved in the range testing and then puts all the test into first BB. The patch fixes gcc.dg/tree-ssa/upd

Re: [PATCH V2] RISC-V: Add conditional unary neg/abs/not autovec patterns

Committed, thanks. On 2023/8/23 16:45, Robin Dapp wrote: OK, thanks. Regards Robin -- Best, Lehua

Re: [PATCH 03/11] aarch64: Use br instead of ret for eh_return

Szabolcs Nagy writes: > The expected way to handle eh_return is to pass the stack adjustment > offset and landing pad address via > > EH_RETURN_STACKADJ_RTX > EH_RETURN_HANDLER_RTX > > to the epilogue that is shared between normal return paths and the > eh_return paths. EH_RETURN_HANDLER_RTX

[PATCH] rtl: use rtx_code for gen_ccmp_first and gen_ccmp_next

Note, this patch is dependent on the patch I posted yesterday to forward declare rtx_code in coretypes.h. -- Now that we have a forward declaration of rtx_code in coretypes.h, we can adjust these hooks to take rtx_code arguments rather than an int. gcc/ChangeLog: * target.def (gen_cc

[PATCH] RISC-V: Add conditional sign/zero extension and truncation autovec patterns

Hi, This patch adds conditional sign/zero extension and truncation autovec patterns by combining EXTENSION/TRUNCATION and VCOND_MASK patterns. For quad truncation, two vncvt instructions are generated. This patch combine the second vncvt and vmerge to form a masked vncvt, while the first vncvt re

[PATCH] RISC-V: Add conditional convert autovec patterns between FPs

Hi, This patch add conditional FP extendsion and truncation autovec patterns. This patch depend on other patch https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628235.html . Best, Lehua gcc/ChangeLog: * config/riscv/autovec-opt.md (*cond_extend): Add combine pattern.

[PATCH V2] RISC-V: Refactor Phase 3 (Demand fusion) of VSETVL PASS

This patch refactors the Phase 3 (Demand fusion) and rename it into Earliest fusion. I do the refactor for the following reasons: 1. Current implementation of phase 3 is doing too many things which makes the code quality quite messy and not easy to maintain. 2. The demand fusion I do

[PATCH] RISC-V:add a more appropriate type attribute

Due to the more accurate type attribute added to the clz, ctz, and pcnt operations in https://github.com/gcc-mirror/gcc/commit/07e2576d6f3 the same type attribute should be used here. gcc/ChangeLog: * config/riscv/bitmanip.md:add a more appropriate type attribute --- gcc/config/riscv/bi

Re: Re: [PATCH] RISC-V: Refactor Phase 3 (Demand fusion) of VSETVL PASS

I have reorder the functions so that we won't mess up deleted functions and new functions. V2 patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628237.html >> Why need this exception? Because we have this piece code here for fusion in "EMPTY" block: new_info = expr.merge (expr, GLOBA

[PATCH v5] c++: extend cold, hot attributes to classes

On Tue, Aug 22, 2023 at 7:50 PM Jason Merrill wrote: > You still need an update to doc/extend.texi for this additional use of > the attribute. Sorry I didn't think of that before. I should have caught that too, many thanks. Also addressed the formatting comments. Patch attached. Signed-off-by:

[PATCH] tree-optimization/111115 - SLP of masked stores

The following adds the capability to do SLP on .MASK_STORE, I do not plan to add interleaving support. Bootstrapped and tested on x86_64-unknown-linux-gnu, OK? Thanks, Richard. PR tree-optimization/15 gcc/ * tree-vectorizer.h (vect_slp_child_index_for_operand): New. *

[PATCH] RISC-V: Add initial pipeline description for an out-of-order core.

Hi, this adds a pipeline description for a generic out-of-order core. Latency and units are not based on any real processor but more or less educated guesses what such a processor could look like. For the lack of a better name, I called the -mtune parameter "generic-ooo". In order to account for

Re: [PATCH] RISC-V:add a more appropriate type attribute

On 8/23/23 06:28, Zhangjin Liao wrote: Due to the more accurate type attribute added to the clz, ctz, and pcnt operations inhttps://github.com/gcc-mirror/gcc/commit/07e2576d6f3 the same type attribute should be used here. gcc/ChangeLog: * config/riscv/bitmanip.md:add a more approp

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

This patch series is a rework of part of the series I posted about a year ago: https://patchwork.sourceware.org/project/gcc/list/?series=10748&state=%2A&archive=both The series depends on the low-latency patch series I posted a few weeks ago: https://patchwork.sourceware.org/project/gcc/list/?se

[PATCH v2 2/6] libgomp, openmp: Add ompx_pinned_mem_alloc

This creates a new predefined allocator as a shortcut for using pinned memory with OpenMP. The name uses the OpenMP extension space and is intended to be consistent with other OpenMP implementations currently in development. The allocator is equivalent to using a custom allocator with the pinned

[PATCH v2 1/6] libgomp: basic pinned memory on Linux

Implement the OpenMP pinned memory trait on Linux hosts using the mlock syscall. Pinned allocations are performed using mmap, not malloc, to ensure that they can be unpinned safely when freed. This implementation will work OK for page-scale allocations, and finer-grained allocations will be impl

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

Use Cuda to pin memory, instead of Linux mlock, when available. There are two advantages: firstly, this gives a significant speed boost for NVPTX offloading, and secondly, it side-steps the usual OS ulimit/rlimit setting. The design adds a device independent plugin API for allocating pinned memo

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

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

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

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

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

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

[PING][PATCH 1/2] Ada: Synchronized private extensions are always limited

From: Richard Wai Sent: Thursday, August 10, 2023 12:55 AM To: 'gcc-patches@gcc.gnu.org' Cc: 'Eric Botcazou' ; 'Arnaud Charlet' ; 'Stephen Baird' Subject: [PATCH 1/2] Ada: Synchronized private extensions are always limited GNAT currently considers a synchronized private extension that de

[PATCH 2/2 v2] Ada: Finalization of constrained subtypes of unconstrained synchronized private extensions

Somehow an error worked its way into the original diff (the diff itself), making the previous patch fail to apply. Fixed version attached. Richard Wai ANNEXI-STRAYLINE From: Richard Wai Sent: Thursday, August 10, 2023 1:27 AM To: 'gcc-patches@gcc.gnu.org' Cc: 'Eric Botcazou' ; 'Arna

Re: [PATCH v1] Mode-Switching: Add optional EMIT_AFTER hook

On 8/23/23 00:03, Li, Pan2 wrote: Thanks Jeff for comments, and sorry for late response. The background comes from the CALL insn. For the RISC-V dynamic rounding mode we need to 1. restore the frm BEFORE call, to avoid the static rounding mode pollute the call. 2. Backup the frm AFTER call

Re: [PATCH] RISC-V: Add initial pipeline description for an out-of-order core.

Does this patch fix these 2 following PR: 108271 – Missed RVV cost model (gnu.org) 108412 – RISC-V: Negative optimization of GCSE && LOOP INVARIANTS (gnu.org) If yes, plz append these 2 cases into testsuite and indicate those 2 PR are fixed. So that we can close them. juzhe.zh...@rivai.ai Fr

[PATCH] AArch64: Fix MOPS memmove operand corruption [PR111121]

A MOPS memmove may corrupt registers since there is no copy of the input operands to temporary registers. Fix this by calling aarch64_expand_cpymem which does this. Also fix an issue with STRICT_ALIGNMENT being ignored if TARGET_MOPS is true, and avoid crashing or generating a huge expansion

[committed] i386: Fix register spill failure with concat RTX [PR111010]

Disable (=&r,m,m) alternative for 32-bit targets. The combination of two memory operands (possibly with complex addressing mode), early clobbered output, frame pointer and PIC registers uses too many registers on a register constrained 32-bit target. Also merge two similar patterns using DWIH mode

RE: [PATCH v1] Mode-Switching: Add optional EMIT_AFTER hook

Thanks Jeff for comments. > Understood. So the natural question is why does x86/sh not need this > for its mode switching? Don't all the same issues exist on those > targets as well? AFAIK, it comes from the different design principle between the risc-v and x86/arm intrinsic API. The risc-v

Re: [PATCH] RISC-V: Add initial pipeline description for an out-of-order core.

> Does this patch fix these 2 following PR: > 108271 – Missed RVV cost model (gnu.org) > > 108412 – RISC-V: Negative optimization of GCSE && LOOP INVARIANTS (gnu.org) > > > If yes, plz app

Patch ping Re: [PATCH 6/12] i386: Enable _BitInt on x86-64 [PR102989]

Hi! Now that Richi has acked all the middle-end _BitInt patches (but am deferring committing those until also the C FE and libgcc patches are approved), I'd like to ping this patch. Thanks! On Wed, Aug 09, 2023 at 08:19:41PM +0200, Jakub Jelinek via Gcc-patches wrote: > The following patch enabl

Re: [PATCH] AArch64: Fix MOPS memmove operand corruption [PR111121]

Wilco Dijkstra writes: > A MOPS memmove may corrupt registers since there is no copy of the input > operands to temporary > registers. Fix this by calling aarch64_expand_cpymem which does this. Also > fix an issue with > STRICT_ALIGNMENT being ignored if TARGET_MOPS is true, and avoid crashing

Re: [PATCH 6/12] i386: Enable _BitInt on x86-64 [PR102989]

On Wed, Aug 9, 2023 at 8:19 PM Jakub Jelinek wrote: > > Hi! > > The following patch enables _BitInt support on x86-64, the only > target which has _BitInt specified in psABI. > > 2023-08-09 Jakub Jelinek > > PR c/102989 > * config/i386/i386.cc (classify_argument): Handle BITINT_

[PATCH] [frange] Relax floating point relational folding.

[Jakub/Andrew: I've been staring at this for far too long and could use another pair of eyes.] This patch implements a new frelop_early_resolve() that handles the NAN special cases instead of calling into the integer version which can break for some combinations. Relaxing FP conditional folding i

Re: [PATCH] rtl: Forward declare rtx_code

Richard Earnshaw via Gcc-patches writes: > Now that we require C++ 11, we can safely forward declare rtx_code > so that we can use it in target hooks. > > gcc/ChangeLog > * coretypes.h (rtx_code): Add forward declaration. > * rtl.h (rtx_code): Make compatible with forward declaration.

Re: [PATCH] rtl: use rtx_code for gen_ccmp_first and gen_ccmp_next

Richard Earnshaw via Gcc-patches writes: > Note, this patch is dependent on the patch I posted yesterday to > forward declare rtx_code in coretypes.h. > > -- > Now that we have a forward declaration of rtx_code in coretypes.h, we > can adjust these hooks to take rtx_code arguments rather than

[RFC] libstdc++: Make --enable-libstdcxx-backtrace=auto default to yes

Any objections to this? It's a C++23 feture, so should be enabled by default. -- >8 -- This causes libstdc++_libbacktrace.a to be built by default. This might fail on some targets, in which case we can make the 'auto' choice expand to either 'yes' or 'no' depending on the target. libstdc++-v3/Ch

Re: [PATCH] rtl: Forward declare rtx_code

On 23/08/2023 16:49, Richard Sandiford via Gcc-patches wrote: > Richard Earnshaw via Gcc-patches writes: >> Now that we require C++ 11, we can safely forward declare rtx_code >> so that we can use it in target hooks. >> >> gcc/ChangeLog >> * coretypes.h (rtx_code): Add forward declaration. >>

Re: [PATCH] rtl: Forward declare rtx_code

"Richard Earnshaw (lists)" writes: > On 23/08/2023 16:49, Richard Sandiford via Gcc-patches wrote: >> Richard Earnshaw via Gcc-patches writes: >>> Now that we require C++ 11, we can safely forward declare rtx_code >>> so that we can use it in target hooks. >>> >>> gcc/ChangeLog >>> * coretype

Re: Another bug for __builtin_object_size? (Or expected behavior)

> On Aug 18, 2023, at 12:00 PM, Qing Zhao via Gcc-patches > wrote: > > > >> On Aug 17, 2023, at 5:32 PM, Siddhesh Poyarekar wrote: >> >> On 2023-08-17 17:25, Qing Zhao wrote: It's not exactly the same issue, the earlier discussion was about choosing sizes in the same pass while

Re: [PATCH] Fix tests sensitive to internal library allocations

On 21/08/2023 23:26, Jonathan Wakely wrote: On Mon, 21 Aug 2023 at 21:20, François Dumont wrote: Here is the updated and tested patch. OK for trunk, thanks. We could consider it for the branches too (I'm going to remove the global strings on the gcc-13 branch tomorrow). It's not fixing an

Re: [PATCH] AArch64: Fix MOPS memmove operand corruption [PR111121]

Hi Richard, (that's quick!) > + if (size > max_copy_size || size > max_mops_size) > +return aarch64_expand_cpymem_mops (operands, is_memmove); > > Could you explain this a bit more? If I've followed the logic correctly, > max_copy_size will always be 0 for movmem, so this "if" condition wil

[PATCH][_GLIBCXX_INLINE_VERSION] Fix friend declarations

Hi The few tests that are failing in versioned namespace mode are due to those friend declarations. This is a fix proposal even if I considered 2 other options: 1. Make __format::_Arg_store a struct and so do not bother with friend declarations. 2. Consider it as a compiler bug and do noth

Re: [PATCH V4] Add warning options -W[no-]compare-distinct-pointer-types

On Thu, Aug 17, 2023 at 05:37:03PM +0200, Jose E. Marchesi via Gcc-patches wrote: > > > On Thu, 17 Aug 2023, Jose E. Marchesi via Gcc-patches wrote: > > > >> +@opindex Wcompare-distinct-pointer-types > >> +@item -Wcompare-distinct-pointer-types > > > > This @item should say @r{(C and Objective-C

Re: [PATCH] AArch64: Fix MOPS memmove operand corruption [PR111121]

Wilco Dijkstra writes: > Hi Richard, > > (that's quick!) > >> + if (size > max_copy_size || size > max_mops_size) >> +return aarch64_expand_cpymem_mops (operands, is_memmove); >> >> Could you explain this a bit more? If I've followed the logic correctly, >> max_copy_size will always be 0 for

[COMMITTED 1/2] Phi analyzer - Do not create phi groups with a single phi.

Rangers Phi Analyzer was creating a group consisting of a single PHI, which was problematic.  It didn't really help anything, and it prevented larger groups from including those PHIs and stopped some useful things from happening. Bootstrapped on x86_64-pc-linux-gnu  with no regressions. Pushed

[COMMITTED 2/2] tree-optimization/110918 - Phi analyzer - Initialize with a range instead of a tree.

Rangers PHI analyzer currently only allows a single initializing value to a group. This patch changes that to use an initialization range, which is cumulative of all integer constants, plus a single symbolic value.  There were many times when there were multiple constants feeding into PHIs and t

[PATCH] Fix for bug libstdc++/111102 pointer arithmetic on nullptr

This fixes pointer arithmetic made on a null pointer, which I found through fuzzing. Tested on debian/amd64. Thanks, Paul commit 78ac41590432f4f01036797fd9d661f6ed80cf37 (HEAD -> master) Author: Paul Dreik Date: Tue Aug

[PATCH] Fortran: improve diagnostic message for COMMON with automatic object [PR32986]

Dear all, here's a simple patch for a very old PR that suggests a more helpful error message for an automatic object in a COMMON. The patch also suppresses the less helpful old error message after the new one has been emitted. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald

Re: [PATCH v7 1/4] driver: add a spec function to join arguments

On 7/2/23 12:32, Ben Boeckel wrote: When passing `-o` flags to other options, the typical `-o foo` spelling leaves a leading whitespace when replacing elsewhere. This ends up creating flags spelled as `-some-option-with-arg= foo.ext` which doesn't parse properly. When attempting to make a spec fu

Re: [PATCH] Fortran: improve diagnostic message for COMMON with automatic object [PR32986]

On Wed, Aug 23, 2023 at 09:16:08PM +0200, Harald Anlauf via Fortran wrote: > > here's a simple patch for a very old PR that suggests a more helpful > error message for an automatic object in a COMMON. The patch also > suppresses the less helpful old error message after the new one has > been emit

Re: [PATCH v7 2/4] p1689r5: initial support

On 7/2/23 12:32, Ben Boeckel wrote: This patch implements support for [P1689R5][] to communicate to a build system the C++20 module dependencies to build systems so that they may build `.gcm` files in the proper order. Support is communicated through the following three new flags: - `-fdeps-for

Re: [PATCH] debug/111080 - avoid outputting debug info for unused restrict qualified type

On 8/21/23 05:11, Richard Biener wrote: The following applies some maintainance with respect to type qualifiers and kinds added by later DWARF standards to prune_unused_types_walk. The particular case in the bug is not handling (thus marking required) all restrict qualified type DIEs. I've found

Re: [PATCH v4 4/8] diagnostics: Support obtaining source code lines from generated data buffers

On Tue, Aug 15, 2023 at 04:08:47PM -0400, Lewis Hyatt wrote: > On Tue, Aug 15, 2023 at 3:46 PM David Malcolm wrote: > > > > On Tue, 2023-08-15 at 14:15 -0400, Lewis Hyatt wrote: > > > On Tue, Aug 15, 2023 at 12:15:15PM -0400, David Malcolm wrote: > > > > On Wed, 2023-08-09 at 18:14 -0400, Lewis Hy

Re: [PATCH] c++: refine CWG 2369 satisfaction vs non-dep convs [PR99599]

On 8/21/23 21:51, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look like a reasonable approach? I didn't observe any compile time/memory impact of this change. -- >8 -- As described in detail in the PR, CWG 2369 has the surprising consequence of introducing

[PATCH] c++: implement P2564, consteval needs to propagate up [PR107687]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This patch implements P2564, described at , whereby certain functions are promoted to consteval. For example: consteval int id(int i) { return i; } template constexpr int f(T t) { return t + id(t); // id causes

Re: [PATCH] RISC-V: Enable Hoist to GCSE simple constants

On 8/9/23 18:30, Vineet Gupta wrote: Hoist want_to_gcse_p () calls rtx_cost () to compute max distance for hoist candidates . For a const with cost 1 backend currently returns 0, causing Hoist to bail and elide GCSE. Note that constants requiring more than 1 insns to setup were working alread

[committed] Improve quality of code from LRA register elimination

This is primarily Jivan's work, I'm mostly responsible for the write-up and coordinating with Vlad on a few questions. On targets with limitations on immediates usable in arithmetic instructions, LRA's register elimination phase can construct fairly poor code. This example (from the GCC test

Re: [PATCH] c++: Fix up mangling of function/block scope static structured bindings [PR111069]

On 8/22/23 04:12, Jakub Jelinek wrote: As can be seen on the testcase, we weren't correctly mangling static/thread_local structured bindings (C++20 feature) at function/block scope. The following patch fixes that by using what write_local_name does for those cases (note, structured binding mandl

Re: [committed] Improve quality of code from LRA register elimination

On 8/23/23 14:13, Jeff Law wrote: This is primarily Jivan's work, I'm mostly responsible for the write-up and coordinating with Vlad on a few questions. On targets with limitations on immediates usable in arithmetic instructions, LRA's register elimination phase can construct fairly poor co

Re: [PATCH v4 3/8] diagnostics: Refactor class file_cache_slot

On Tue, Aug 15, 2023 at 03:39:40PM -0400, David Malcolm wrote: > On Tue, 2023-08-15 at 13:58 -0400, Lewis Hyatt wrote: > > On Tue, Aug 15, 2023 at 11:43:05AM -0400, David Malcolm wrote: > > > On Wed, 2023-08-09 at 18:14 -0400, Lewis Hyatt wrote: > > > > Class file_cache_slot in input.cc is used to

Re: [PATCH v7 1/4] driver: add a spec function to join arguments

On Wed, 23 Aug 2023, Jason Merrill via Gcc-patches wrote: > Joseph, any thoughts on these issues or the workaround? I don't have any comments here. -- Joseph S. Myers jos...@codesourcery.com

[PATCH] MATCH: [PR111109] Fix bit_ior(cond, cond) when comparisons are fp

The patterns that were added in r13-4620-g4d9db4bdd458, missed that (a > b) and (a <= b) are not inverse of each other for floating point comparisons (if NaNs are supported). Even though there was a check for intergal types, it was only for the result of the cond rather for the type of what is bein

Re: [PATCH] RISC-V: Add initial pipeline description for an out-of-order core.

On 8/23/23 08:56, Robin Dapp wrote: Does this patch fix these 2 following PR: 108271 – Missed RVV cost model (gnu.org) 108412 – RISC-V: Negative optimization of GCSE && LOOP INVARIANTS (gnu.org)

Re: [PATCH v1] Mode-Switching: Add optional EMIT_AFTER hook

On 8/23/23 08:54, Li, Pan2 wrote: Thanks Jeff for comments. Understood. So the natural question is why does x86/sh not need this for its mode switching? Don't all the same issues exist on those targets as well? AFAIK, it comes from the different design principle between the risc-v and

Re: [PATCH] RISC-V: Enable Hoist to GCSE simple constants

On 8/23/23 13:04, Jeff Law wrote: Thanks for your patience on this.  I needed a bit of time to gather my thoughts and review some code. No worries at all. index 8b7256108157..1802eef908fc 100644 --- a/gcc/config/riscv/riscv.cc +++ b/gcc/config/riscv/riscv.cc @@ -2464,14 +2464,9 @@ riscv_rtx

[PATCH V5 1/4] rs6000: build constant via li;rotldi

Hi, If a constant is possible to be rotated to/from a positive or negative value which "li" can generated, then "li;rotldi" can be used to build the constant. Compare with the previous version: https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623528.html This patch just did minor changes to th

[committed] testsuite: Xfail gcc.dg/tree-ssa/update-threading.c for CRIS, PR110628

Oops, looks like the PR title annotation didn't work and I forgot the classic changelog annotation. Anyway, after fixing a testsuite inconsistency, this test fails for *some* architectures and shows up as a regression; see the PR. -- >8 -- * gcc.dg/tree-ssa/update-threading.c: Xfail for

Re: [PATCH] rs6000: Disable PCREL for unsupported targets [PR111045]

On 8/21/23 8:51 PM, Kewen.Lin wrote: >> The following patch has been bootstrapped and regtested on powerpc64-linux. > > I think we should test this on powerpc64le-linux P8 or P9 (no P10) as well. That's a good idea! > I think this should be moved to be with the hunk on PCREL: > > /* If the

[PATCH] VECT: Apply LEN_FOLD_EXTRACT_LAST into loop vectorizer

Hi. This patch is apply LEN_FOLD_EXTRACT_LAST into loop vectorizer. Consider this following case: #include #define N 32 /* Simple condition reduction. */ int __attribute__ ((noinline, noclone)) condition_reduction (int *a, int min_v) { int last = 66; /* High start value. */ for (int i

[PATCH] RISC-V: Support LEN_FOLD_EXTRACT_LAST auto-vectorization

Consider this following case: int __attribute__ ((noinline, noclone)) condition_reduction (int *a, int min_v) { int last = 66; /* High start value. */ for (int i = 0; i < 4; i++) if (a[i] < min_v) last = i; return last; } --param=riscv-autovec-preference=fixed-vlmax --param=risc

[PATCH] MATCH: remove negate for 1bit types

For 1bit types, negate is either undefined or don't change the value. In either cases we want to remove them. This patch adds a match pattern to do that. Also converting to a 1bit type we can remove the negate just like we already do for `&1` so this patch adds that too. OK? Bootstrapped and teste

[PATCH] testsuite: aarch64: Adjust SVE ACLE tests to new generated code

Since commit e7a36e4715c7 "[PATCH] RISC-V: Support simplify (-1-x) for vector." these tests fail on aarch64-linux: === g++ tests === Running g++:g++.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp ... FAIL: gcc.target/aarch64/sve/acle/asm/subr_s8.c -std=gnu++98 -O2 -fno-schedule

[PATCH v5 0/6] Add Loongson SX/ASX instruction support to LoongArch target.

This is an update of: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627413.html Changes since last version of patch set: - Fix regression test fail of pr54346.c with RUNTESTFLAGS="--target_board=unix/-mlsx". This is caused by the code simplification of loongarch_expand_vec_perm_const_2

[PATCH v5 4/6] LoongArch: Add Loongson ASX vector directive compilation framework.

From: Lulu Cheng gcc/ChangeLog: * config/loongarch/genopts/loongarch-strings: Add compilation framework. * config/loongarch/genopts/loongarch.opt.in: Ditto. * config/loongarch/loongarch-c.cc (loongarch_cpu_cpp_builtins): Ditto. * config/loongarch/loongarch-def.c:

[PATCH v5 1/6] LoongArch: Add Loongson SX vector directive compilation framework.

From: Lulu Cheng gcc/ChangeLog: * config/loongarch/genopts/loongarch-strings: Add compilation framework. * config/loongarch/genopts/loongarch.opt.in: Ditto. * config/loongarch/loongarch-c.cc (loongarch_cpu_cpp_builtins): Ditto. * config/loongarch/loongarch-def.c:

PING^2: [PATCH] rtl-optimization/110939 Really fix narrow comparison of memory and constant

Ping again. On Fri, 2023-08-18 at 13:04 +0200, Stefan Schulze Frielinghaus via Gcc-patches wrote: > Ping.  Since this fixes bootstrap problem PR110939 for Loongarch I'm > pingen this one earlier. > > On Thu, Aug 10, 2023 at 03:04:03PM +0200, Stefan Schulze Frielinghaus wrote: > > In the former f

Re: [committed] i386: Fix grammar typo in diagnostic

On Wed, Aug 23, 2023 at 4:08 PM Hongtao Liu wrote: > > On Wed, Aug 23, 2023 at 3:02 PM Jonathan Wakely wrote: > > > > > > > > On Wed, 23 Aug 2023, 06:15 Hongtao Liu via Libstdc++, > > wrote: > >> > >> On Wed, Aug 23, 2023 at 7:28 AM Hongtao Liu wrote: > >> > > >> > On Tue, Aug 8, 2023 at 5:22 

Re: [PATCH] Fix target_clone ("arch=graniterapids-d") and target_clone ("arch=arrowlake-s")

On Wed, Aug 23, 2023 at 12:31 PM liuhongt wrote: > > Both "graniterapid-d" and "graniterapids" are attached with > PROCESSOR_GRANITERAPID in processor_alias_table but mapped to > different __cpu_subtype in get_intel_cpu. > > And get_builtin_code_for_version will try to match the first > PROCESSOR_

Re: [PATCH v5 0/6] Add Loongson SX/ASX instruction support to LoongArch target.

On Thu, 2023-08-24 at 11:13 +0800, Chenghui Pan wrote: > - Add dg-skip-if for loongarch*-*-* in vshuf test in g++.dg/torture, because >   vshuf/xvshuf insn's result is undefined when 6 or 7 bit of vector's element > is set, >   and insns with this condition are generated in these testcases. I'm a

Re: [PATCH v5 0/6] Add Loongson SX/ASX instruction support to LoongArch target.

On Thu, 2023-08-24 at 11:40 +0800, Xi Ruoyao via Gcc-patches wrote: > On Thu, 2023-08-24 at 11:13 +0800, Chenghui Pan wrote: > > - Add dg-skip-if for loongarch*-*-* in vshuf test in g++.dg/torture, because > >   vshuf/xvshuf insn's result is undefined when 6 or 7 bit of vector's > > element is set

[PATCH v1] RISC-V: Support rounding mode for VFMADD/VFMACC autovec

From: Pan Li There will be a case like below for intrinsic and autovec combination vfadd RTZ <- intrinisc static rounding vfmadd <- autovec/autovec-opt The autovec generated vfmadd should take DYN mode, and the frm must be restored before the vfmadd insn. This patch would like to fix thi

RE: [PATCH v1] Mode-Switching: Add optional EMIT_AFTER hook

Thanks Jeff. > That implies a save/restore pair around the call (possibly optimized so > that we minimize the number of save/restores). I would have expected > x86 to already be doing this. But maybe there's some ABI thing around > mmx vs x86 state that allows it to be avoided Very simil

RE: [PATCH v1] RISC-V: Refactor RVV class by frm_op_type template arg

> So in the expand method, you added a case for OP_TYPE_vx. Actually this patch doesn't add a case OP_TYPE_vx, there are two classes binop_frm and binop before this patch. Binop_frm doesn't have OP_TYPE_vx while binop has OP_TYPE_vx. When delete the whole binop_frm, the git diff demo It looks l

Re: [PATCH] rs6000: Disable PCREL for unsupported targets [PR111045]

Hi Peter, on 2023/8/24 10:07, Peter Bergner wrote: > On 8/21/23 8:51 PM, Kewen.Lin wrote: >>> The following patch has been bootstrapped and regtested on powerpc64-linux. >> >> I think we should test this on powerpc64le-linux P8 or P9 (no P10) as well. > > That's a good idea! > > > >> I think t

Re: [committed] i386: Fix grammar typo in diagnostic

On Thu, 24 Aug 2023, 04:38 Hongtao Liu, wrote: > On Wed, Aug 23, 2023 at 4:08 PM Hongtao Liu wrote: > > > > On Wed, Aug 23, 2023 at 3:02 PM Jonathan Wakely > wrote: > > > > > > > > > > > > On Wed, 23 Aug 2023, 06:15 Hongtao Liu via Libstdc++, < > libstd...@gcc.gnu.org> wrote: > > >> > > >> On W

Re: [PATCH] MATCH: [PR111109] Fix bit_ior(cond, cond) when comparisons are fp

On Wed, Aug 23, 2023 at 11:51 PM Andrew Pinski via Gcc-patches wrote: > > The patterns that were added in r13-4620-g4d9db4bdd458, missed that > (a > b) and (a <= b) are not inverse of each other for floating point > comparisons (if NaNs are supported). Even though there was a check for > intergal

Re: [PATCH] VECT: Apply LEN_FOLD_EXTRACT_LAST into loop vectorizer

On Thu, 24 Aug 2023, Juzhe-Zhong wrote: > Hi. > > This patch is apply LEN_FOLD_EXTRACT_LAST into loop vectorizer. > > Consider this following case: > #include > > #define N 32 > > /* Simple condition reduction. */ > > int __attribute__ ((noinline, noclone)) > condition_reduction (int *a, in

Re: [PATCH] MATCH: remove negate for 1bit types

On Thu, Aug 24, 2023 at 4:39 AM Andrew Pinski via Gcc-patches wrote: > > For 1bit types, negate is either undefined or don't change the value. > In either cases we want to remove them. > This patch adds a match pattern to do that. > Also converting to a 1bit type we can remove the negate just like