Re: [PATCH 3/4] gcov: Add gen_counter_update()

On Tue, Nov 14, 2023 at 11:08:24PM +0100, Sebastian Huber wrote: > Move the counter update to the new gen_counter_update() helper function. Use > it in gimple_gen_edge_profiler() and gimple_gen_time_profiler(). The > resulting > gimple instructions should be identical with the exception of the r

[PATCH 2/3] OpenMP: Unify representation of name-list properties.

Previously, name-list properties specified as identifiers were stored in the TREE_PURPOSE/OMP_TP_NAME slot, while those specified as strings were stored in the TREE_VALUE/OMP_TP_VALUE slot. This patch puts both representations in OMP_TP_VALUE with a magic cookie in OMP_TP_NAME. gcc/ChangeLog

[PATCH 1/3] OpenMP: Introduce accessor macros and constructors for context selectors.

This patch hides the underlying nested TREE_LIST structure of context selectors behind accessor macros that have more meaningful names than the generic TREE_PURPOSE/TREE_VALUE accessors. There is a slight change to the representation in that the score expression in trait-selectors has a distinguis

[PATCH 0/3] OpenMP: Improve data abstractions for context selectors

While trying to track down some bugs in the metadirective patches (currently on the OG13 branch), I found that I was getting totally lost in the undocumented data structures for context selectors; the multiple levels of TREE_PURPOSE and TREE_VALUE that don't hint at what kind of object is being acc

[PATCH 3/3] OpenMP: Use enumerators for names of trait-sets and traits

This patch introduces enumerators to represent trait-set names and trait names, which makes it easier to use tables to control other behavior and for switch statements to dispatch on the tags. The tags are stored in the same place in the TREE_LIST structure (OMP_TSS_ID or OMP_TS_ID) and are encode

[PATCH] RISC-V: Remove duplicate `order_operator' predicate

Remove our RISC-V-specific `order_operator' predicate, which is exactly the same as generic `ordered_comparison_operator' one. gcc/ * config/riscv/predicates.md (order_operator): Remove predicate. * config/riscv/riscv.cc (riscv_rtx_costs): Update accordingly. * con

[PATCH] testsuite: Fix subexpressions with `scan-assembler-times'

We have an issue with `scan-assembler-times' handling expressions using subexpressions as produced by capturing parentheses `()' in an odd way, and one that is inconsistent with `scan-assembler', `scan-assembler-not', etc. The problem comes from calling `regexp' with `-inline -all', which caus

Re: Propagate value ranges of return values

Jan Hubicka writes: > Hi, > this patch implements very basic propaation of return value ranges from VRP > pass. This helps std::vector's push_back since we work out value range of > allocated block. This propagates only within single translation unit. I > hoped > we will also do the propaga

[pushed] libcpp: split decls out to rich-location.h

The various decls relating to rich_location are in libcpp/include/line-map.h, but they don't relate to line maps. Split them out to their own header: libcpp/include/rich-location.h No functional change intended. Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r1

Re: [PATCH v3 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609]

Funny enough I ended up removing the ones I was thinking about, seems to always happen when I ask style questions but I'm glad to hear it's okay going forward. I'm having trouble fixing this bug, based on what Gasper said in PR102609 I am pretty sure I know what the semantics should be. Since the

[Committed V2] RISC-V: Optimize constant AVL for LRA pattern

This optimization was discovered in the tuple move splitted bug fix patch. Before this patch: vsetivlizero,4,e16,mf2,ta,ma lhu a3,96(a5) vlseg8e16.v v1,(a5) lw a4,%lo(e)(a2) vsetvli a6,zero,e64,m2,ta,ma addia0,a7,8 vse16.v v

[PATCH v2 2/3] LoongArch: Use standard pattern name and RTX code for LSX/LASX muh instructions

Removes unnecessary UNSPECs and make the muh instructions useful with GNU vectors or auto vectorization. gcc/ChangeLog: * config/loongarch/simd.md (muh): New code attribute mapping any_extend to smul_highpart or umul_highpart. (mul3_highpart): New define_insn. * co

[PATCH v2 3/3] LoongArch: Use standard pattern name and RTX code for LSX/LASX rotate shift

Remove unnecessary UNSPECs and make the [x]vrotr[i] instructions useful with GNU vectors and auto vectorization. gcc/ChangeLog: * config/loongarch/lsx.md (bitimm): Move to ... (UNSPEC_LSX_VROTR): Remove. (lsx_vrotr_): Remove. (lsx_vrotri_): Remove. * config

[PATCH v2 0/3] LoongArch: SIMD fixes and optimizations

The [1/3] patch is the PR112578 fix at https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637097.html unchanged. As I've made other two patches depending on the simd.md file introduced by it, resend it as a part of this series. As many LASX instructions are only differentiated from the corre

[PATCH v2 1/3] LoongArch: Fix usage of LSX and LASX frint/ftint instructions [PR112578]

The usage LSX and LASX frint/ftint instructions had some problems: 1. These instructions raises FE_INEXACT, which is not allowed with -fno-fp-int-builtin-inexact for most C2x section F.10.6 functions (the only exceptions are rint, lrint, and llrint). 2. The "frint" instruction without explic

Re: Propagate value ranges of return values

> > +Wsuggest-attribute=returns_nonnull > > - or _? > > (If changing it, needs adjustment in rest of patch too.) I was thinking of this and I am not sure what is better. Sure _ in command line option looks odd, but this is an identifier and it is returns_nonnull and not returns-nonnull. I am not

Re: [PATCH 3/4] gcov: Add gen_counter_update()

Hello Dimitar, On 19.11.23 10:00, Dimitar Dimitrov wrote: On Tue, Nov 14, 2023 at 11:08:24PM +0100, Sebastian Huber wrote: Move the counter update to the new gen_counter_update() helper function. Use it in gimple_gen_edge_profiler() and gimple_gen_time_profiler(). The resulting gimple instruc

Re: Propagate value ranges of return values

Hi, this is updated version which also adds testuiste compensation I lost earlier while maintaining the patch in my testing tree. There are quite few testcases that use constant return values to hide something from optimizer. Bootstrapped/regtested x86_64-linux. gcc/ChangeLog: * cgraph.cc

Re: [PATCH] RISC-V: Remove duplicate `order_operator' predicate

On 11/19/23 04:24, Maciej W. Rozycki wrote: Remove our RISC-V-specific `order_operator' predicate, which is exactly the same as generic `ordered_comparison_operator' one. gcc/ * config/riscv/predicates.md (order_operator): Remove predicate. * config/riscv/riscv.cc (ris

Re: [PATCH] testsuite: scev: expect fail on ilp32

On 11/19/23 00:30, Alexandre Oliva wrote: I've recently patched scev-3.c and scev-5.c because it only passed by accident on ia32. It also fails on some (but not all) arm-eabi variants. It seems hard to characterize the conditions in which the optimization is supposed to pass, but expecting

Re: [PATCH] testsuite: analyzer: expect alignment warning with -fshort-enums

On 11/19/23 00:36, Alexandre Oliva wrote: On targets that have -fshort-enums enabled by default, the type casts in the pr108251 analyzer tests warn that the byte-aligned enums may not be sufficiently aligned to be a struct connection *. The function can't know better, the warning is reasonab

Re: [PATCH v3 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609]

On 11/19/23 08:39, waffl3x wrote: Funny enough I ended up removing the ones I was thinking about, seems to always happen when I ask style questions but I'm glad to hear it's okay going forward. I'm having trouble fixing this bug, based on what Gasper said in PR102609 I am pretty sure I know what

Re: [PATCH 15/44] RISC-V/testsuite: Add branched cases for GEU and LEU cond-move operations

On 11/18/23 22:38, Maciej W. Rozycki wrote: Verify, for Ventana and Zicond targets and the GEU and LEU conditional-move operations, that if-conversion does *not* trigger at `-mbranch-cost=3' setting, which makes original branched code sequences cheaper than their branchless equivalents if-conv

Re: [PATCH 17/44] RISC-V: Avoid extraneous EQ or NE operation in cond-move expansion

On 11/18/23 22:38, Maciej W. Rozycki wrote: In the non-zero case there is no need for the conditional value used by Ventana and Zicond integer conditional operations to be specifically 1. Regardless we canonicalize it by producing an extraneous conditional-set operation, such as with the seque

Re: [PATCH 18/44] RISC-V/testsuite: Add branched cases for equality cond-move operations

On 11/18/23 22:38, Maciej W. Rozycki wrote: Verify, for Ventana and Zicond targets and the equality conditional-move operations, that if-conversion does *not* trigger at the respective sufficiently low `-mbranch-cost=' settings that make original branched code sequences cheaper than their bran

Re: [PATCH 19/44] RISC-V/testsuite: Add branchless cases for equality cond-move operations

On 11/18/23 22:39, Maciej W. Rozycki wrote: Verify, for Ventana and Zicond targets and the equality conditional-move operations, that if-conversion triggers via `noce_try_cmove' at the respective sufficiently high `-mbranch-cost=' settings that make branchless code sequences produced by if-con

Re: [PATCH 20/44] RISC-V: Also accept constants for T-Head cond-move comparison operands

On 11/18/23 22:39, Maciej W. Rozycki wrote: There is no need for the requirement for conditional-move comparison operands to be stricter for T-Head targets than for other targets and limit them to registers only. Constants will be reloaded if required just as with branches or other-target con

Re: [PATCH 21/44] RISC-V: Also accept constants for T-Head cond-move data input operands

On 11/18/23 22:39, Maciej W. Rozycki wrote: There is no need for the requirement for conditional-move data input operands to be stricter for T-Head targets than for short forward branch targets and limit them to registers only. They are keyed according to the `sfb_alu_operand' predicate, whic

Re: [PATCH 23/44] RISC-V/testsuite: Add branched cases for T-Head non-equality cond moves

On 11/18/23 22:40, Maciej W. Rozycki wrote: Verify, for T-Head targets and the non-equality integer conditional-move operations, that if-conversion does *not* trigger at `-mbranch-cost=1' setting, which makes original branched code sequences cheaper than their branchless equivalents if-convers

Re: [PATCH 24/44] RISC-V/testsuite: Add branchless cases for T-Head non-equality cond moves

On 11/18/23 22:40, Maciej W. Rozycki wrote: Verify, for T-Head targets and the non-equality integer conditional-move operations, that if-conversion triggers via `noce_try_cmove' at `-mbranch-cost=2' setting, which makes branchless code sequences produced by if-conversion cheaper than their ori

Re: [PATCH 25/44] RISC-V: Implement `riscv_emit_unary' helper

On 11/18/23 22:40, Maciej W. Rozycki wrote: Add a `riscv_emit_unary' helper for unary operations, complementing `riscv_emit_binary'. gcc/ * config/riscv/riscv-protos.h (riscv_emit_unary): New prototype. * config/riscv/riscv.cc (riscv_emit_unary): New function. OK jeff

Re: [PATCH 26/44] RISC-V: Add `movMODEcc' implementation for generic targets

On 11/18/23 22:40, Maciej W. Rozycki wrote: Provide RTL expansion of conditional-move operations for generic targets using a suitable sequence of base integer machine instructions according to cost evaluation by if-conversion. Add `-mmovcc' command line option to enable this transformation, o

Re: [PATCH 27/44] RISC-V/testsuite: Add branched cases for generic integer cond moves

On 11/18/23 22:40, Maciej W. Rozycki wrote: Verify, for generic integer conditional-move operations, if-conversion *not* to trigger at the respective sufficiently low `-mbranch-cost=' settings that make original branched code sequences cheaper than their branchless equivalents if-conversion wo

Re: [PATCH 28/44] RISC-V/testsuite: Add branchless cases for generic integer cond moves

On 11/18/23 22:41, Maciej W. Rozycki wrote: Verify, for generic integer conditional-move operations, if-conversion to trigger via `noce_try_cmove' at the respective sufficiently high `-mbranch-cost=' settings that make branchless code sequences produced by if-conversion cheaper than their orig

Re: [PATCH 29/44] RISC-V: Add `addMODEcc' implementation for generic targets

On 11/18/23 22:41, Maciej W. Rozycki wrote: Provide RTL expansion of conditional-add operations for generic targets using a suitable sequence of base integer machine instructions according to cost evaluation by if-conversion. Use existing `-mmovcc' command line option to enable this transform

Re: [PATCH 30/44] RISC-V/testsuite: Add branched cases for generic integer cond adds

On 11/18/23 22:41, Maciej W. Rozycki wrote: Verify, for generic integer conditional-add operations, if-conversion *not* to trigger at the respective sufficiently low `-mbranch-cost=' settings that make original branched code sequences cheaper than their branchless equivalents if-conversion wou

Re: [PATCH 31/44] RISC-V/testsuite: Add branchless cases for generic integer cond adds

On 11/18/23 22:41, Maciej W. Rozycki wrote: Verify, for generic integer conditional-add operations, if-conversion to trigger via `noce_try_addcc' at the respective sufficiently high `-mbranch-cost=' settings that make branchless code sequences produced by if-conversion cheaper than their origi

Re: [PATCH 32/44] RISC-V: Only use SUBREG if applicable in `riscv_expand_float_scc'

On 11/18/23 22:42, Maciej W. Rozycki wrote: A subsequent change to enable the processing of conditional moves on a floating-point condition by `riscv_expand_conditional_move' will cause `riscv_expand_float_scc' to be called for word-mode target RTX with RV64 targets. In that case an invalid i

Re: [PATCH 33/44] RISC-V: Also allow FP conditions in `riscv_expand_conditional_move'

On 11/18/23 22:42, Maciej W. Rozycki wrote: In `riscv_expand_conditional_move' we only let integer conditions through at the moment, even though code has already been prepared to handle floating-point conditions as well. Lift this restriction and only bail out if a non-word-mode integer condi

Re: [PATCH 22/44] RISC-V: Fold all the cond-move variants together

On 11/18/23 22:40, Maciej W. Rozycki wrote: Code in `riscv_expand_conditional_move' for Ventana and Zicond targets seems like bolted on as an afterthought rather than properly merged so as to handle all the cases together. You could characterize it that way. It was mostly a desire to not muck

Re: [PATCH v3 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609]

On Sunday, November 19th, 2023 at 9:31 AM, Jason Merrill wrote: > > > On 11/19/23 08:39, waffl3x wrote: > > > Funny enough I ended up removing the ones I was thinking about, seems > > to always happen when I ask style questions but I'm glad to hear it's > > okay going forward. > > > > I'm havin

Re: [PATCH 09/44] RISC-V: Rework branch costing model for if-conversion

On 11/18/23 22:36, Maciej W. Rozycki wrote: The generic branch costing model for if-conversion assumes a fixed cost of COSTS_N_INSNS (2) for a conditional branch, and that one half of that cost comes from a preceding condition-set instruction, such as with MODE_CC targets, and then the other h

[committed] Fix missing mode on a few unspec/unspec_volatile operands

This is fix for a minor problem Jivan and I found while testing the ext-dce work originally from Joern. The ext-dce pass will transform zero/sign extensions into subreg accesses when the upper bits are actually unused. So it's more likely with the ext-dce work to get a sequence like this prio

Re: [PATCH v2 1/3] LoongArch: Fix usage of LSX and LASX frint/ftint instructions [PR112578]

On Sun, 2023-11-19 at 22:30 +0800, Xi Ruoyao wrote: > +;; All these are controlled by -ffp-int-builtin-inexact. > +(define_int_attr simd_frint_pattern > +  [(UNSPEC_SIMD_FRINTRP "ceil") > +   (UNSPEC_SIMD_FRINTRZ "btrunc") > +   (UNSPEC_SIMD_FRINT"nearbyint

Re: [PATCH 34/44] RISC-V: Provide FP conditional-branch instructions for if-conversion

On 11/18/23 22:42, Maciej W. Rozycki wrote: Do not expand floating-point conditional-branch RTL instructions right away that use a comparison operation that is either directly available as a machine conditional-set instruction or is NE, which can be emulated by EQ. This is so that if-conversi

Re: [PATCH 35/44] RISC-V: Avoid extraneous integer comparison for FP comparisons

On 11/18/23 22:42, Maciej W. Rozycki wrote: We have floating-point coditional-set machine instructions for a subset of FP comparisons, so avoid going through a comparison against constant zero in `riscv_expand_float_scc' where not necessary, preventing an extraneous RTL instruction from being

Re: [PATCH 36/44] RISC-V/testsuite: Add branched cases for generic FP cond moves

On 11/18/23 22:42, Maciej W. Rozycki wrote: Verify, for generic floating-point conditional-move operations that have a corresponding conditional-set machine instruction, that if-conversion does *not* trigger at `-mbranch-cost=4' setting, which makes original branched code sequences cheaper tha

Re: [PATCH 37/44] RISC-V/testsuite: Add branchless cases for generic FP cond moves

On 11/18/23 22:43, Maciej W. Rozycki wrote: Verify, for generic floating-point conditional-move operations that have a corresponding conditional-set machine instruction, that if-conversion triggers (via `cond_move_convert_if_block', which doesn't report) at `-mbranch-cost=5' setting, which mak

Re: [PATCH 38/44] RISC-V/testsuite: Add branched cases for generic FP cond adds

On 11/18/23 22:43, Maciej W. Rozycki wrote: Verify, for generic floating-point conditional-add operations that have a corresponding conditional-set machine instruction, that if-conversion does *not* trigger at `-mbranch-cost=2' setting, which makes original branched code sequences cheaper than

Re: [PATCH 39/44] RISC-V/testsuite: Add branchless cases for generic FP cond adds

On 11/18/23 22:43, Maciej W. Rozycki wrote: Verify, for generic floating-point conditional-add operations that have a corresponding conditional-set machine instruction, that if-conversion triggers via `noce_try_addcc' at `-mbranch-cost=3' setting, which makes branchless code sequences emitted

Re: building GNU gettext on AIX

I wrote in : > > The latest issue is that a few files in gettext ignore --disable-pthreads > > and creates a dependency on pthread_mutex. > ... > * If no, then the simple solution would be to pass the configure option > --

Re: [PATCH 40/44] RISC-V: Handle FP NE operator via inversion in cond-operation expansion

On 11/18/23 22:43, Maciej W. Rozycki wrote: We have no FNE.fmt machine instructions, but we can emulate them for the purpose of conditional-move and conditional-add operations by using the respective FEQ.fmt instruction and then swapping the data input operands or complementing the mask for th

Re: [PATCH v3 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609]

On 11/19/23 13:36, waffl3x wrote: I'm having trouble fixing the error for this case, the control flow when the functions are overloaded is much more complex. struct S { void f(this S&) {} void f(this S&, int) void g() { void (*fp)(S&) = &f; } }; This seemed to have fixed the n

[PATCH, v2] Fortran: restrictions on integer arguments to SYSTEM_CLOCK [PR112609]

Hi Steve, On 11/19/23 01:04, Steve Kargl wrote: On Sat, Nov 18, 2023 at 11:12:55PM +0100, Harald Anlauf wrote: Regtested on x86_64-pc-linux-gnu. OK for mainline? Not in its current form. { + int first_int_kind = -1; + bool f2023 = ((gfc_option.allow_std & GFC_STD_F2023) != 0 +

[committed] RISC-V: Infrastructure for instruction fusion

I've been meaning to extract this and upstream it for a long time. The work is primarily Philipp from VRULL with one case added by Raphael and light bugfixing on my part. Essentially there's 10 distinct fusions supported and they can be selected individually by building a suitable mask in

Re: [PATCH] RISC-V: Implement -mmemcpy-strategy= options[PR112537]

On 11/16/23 22:12, Li Xu wrote: From: xuli https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112537 -mmemcpy-strategy=[auto|libcall|scalar|vector] auto: Current status, use scalar or vector instructions. libcall: Always use a library call. scalar: Only use scalar instructions. vector: Only use v

Re: [PATCH v3 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609]

On Sunday, November 19th, 2023 at 1:34 PM, Jason Merrill wrote: > > > On 11/19/23 13:36, waffl3x wrote: > > > I'm having trouble fixing the error for this case, the control flow > > when the functions are overloaded is much more complex. > > > > struct S { > > void f(this S&) {} > > v

Re: [PATCH v2 2/5] c-family: Simplify attribute exclusion handling

On 11/16/23 19:53, Andrew Carlotti wrote: This patch changes the handling of mutual exclusions involving the target and target_clones attributes to use the generic attribute exclusion lists. Additionally, the duplicate handling for the always_inline and noinline attribute exclusion is removed

Re: [PATCH] c++: Set DECL_CONTEXT for __cxa_thread_atexit [PR99187]

On 11/16/23 16:39, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu. I don't have write access. -- >8 -- Modules streaming requires DECL_CONTEXT to be set on declarations that are streamed. This ensures that __cxa_thread_atexit is given translation unit context much like

Re: [PATCH 1/5] Add register filter operand to define_register_constraint

On 11/12/23 07:52, Richard Sandiford wrote: The main way of enforcing registers to be aligned is through HARD_REGNO_MODE_OK. But this is a global property that applies to all operands. A given (regno, mode) pair is either globally valid or globally invalid. This patch instead adds a way of

Re: [PATCH 2/5] recog: Handle register filters

On 11/12/23 07:52, Richard Sandiford wrote: The main (but simplest) part of this patch makes constrain_operands take register filters into account. The rest of the patch adds register filter information to operand_alternative. Generally, if two register constraints have different register fi

Re: [PATCH 5/5] Add an aligned_register_operand predicate

On 11/12/23 07:52, Richard Sandiford wrote: This patch adds a target-independent aligned_register_operand predicate, for use with register constraints that use filters to impose an alignment. The definition deliberately jetisons some of the historical baggage in general_operand. gcc/

libstdc++: Speed up push_back

Hi, this patch speeds up the push_back at -O3 significantly by making the reallocation to be inlined by default. _M_realloc_insert is general insertion that takes iterator pointing to location where the value should be inserted. As such it contains code to move other entries around that is quite

Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext

David Edelsohn wrote: > --disable-threads currently does not completely disable threads. Bruno is > suggesting --enable-threads=isoc that relies on mtx mutex functions in libc. Unfortunately, as said in the other mail today, relying only on mtx_* functions did not drop the dependency towards libp

Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext

I wrote: > you (Arsen) should state in the documentation > (gcc/doc/install.texi) that for --disable-threads to have this effect, > one needs gettext version 0.22.4 or newer. Not in gcc/doc/install.texi, but elsewhere. This topic is not relevant to the average user who installs GCC from a tarball

Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext

On Sun, Nov 19, 2023 at 3:01 PM Bruno Haible wrote: > > I wrote: > > you (Arsen) should state in the documentation > > (gcc/doc/install.texi) that for --disable-threads to have this effect, > > one needs gettext version 0.22.4 or newer. > > Not in gcc/doc/install.texi, but elsewhere. This topic is

Re: [PATCH] testsuite: Fix subexpressions with `scan-assembler-times'

On 11/19/23 04:27, Maciej W. Rozycki wrote: We have an issue with `scan-assembler-times' handling expressions using subexpressions as produced by capturing parentheses `()' in an odd way, and one that is inconsistent with `scan-assembler', `scan-assembler-not', etc. The problem comes from cal

[PATCH v3 0/5] LoongArch: SIMD fixes and optimizations

The [1/5] patch is the PR112578 fix at https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637097.html. It has been changed to remove the nearbyint pattern (because nearbyint should not raise FE_INEXACT even if -ffp-int-builtin-inexact). As other patches depending on the simd.md file introduced

[PATCH v3 1/5] LoongArch: Fix usage of LSX and LASX frint/ftint instructions [PR112578]

The usage LSX and LASX frint/ftint instructions had some problems: 1. These instructions raises FE_INEXACT, which is not allowed with -fno-fp-int-builtin-inexact for most C2x section F.10.6 functions (the only exceptions are rint, lrint, and llrint). 2. The "frint" instruction without explic

[PATCH v3 2/5] LoongArch: Use standard pattern name and RTX code for LSX/LASX muh instructions

Removes unnecessary UNSPECs and make the muh instructions useful with GNU vectors or auto vectorization. gcc/ChangeLog: * config/loongarch/simd.md (muh): New code attribute mapping any_extend to smul_highpart or umul_highpart. (mul3_highpart): New define_insn. * co

[PATCH v3 3/5] LoongArch: Use standard pattern name and RTX code for LSX/LASX rotate shift

Remove unnecessary UNSPECs and make the [x]vrotr[i] instructions useful with GNU vectors and auto vectorization. gcc/ChangeLog: * config/loongarch/lsx.md (bitimm): Move to ... (UNSPEC_LSX_VROTR): Remove. (lsx_vrotr_): Remove. (lsx_vrotri_): Remove. * config

[PATCH v3 4/5] LoongArch: Remove lrint_allow_inexact

No functional change, just a cleanup. gcc/ChangeLog: * config/loongarch/loongarch.md (lrint_allow_inexact): Remove. (2): Check if == UNSPEC_FTINT instead of . --- gcc/config/loongarch/loongarch.md | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/gc

[PATCH v3 5/5] LoongArch: Use LSX for scalar FP rounding with explicit rounding mode

In LoongArch FP base ISA there is only the frint.{s/d} instruction which reads the global rounding mode. Utilize LSX for explicit rounding mode even if the operand is scalar. It seems wasting the CPU power, but still much faster than calling the library function. gcc/ChangeLog: * config

[RFA] New pass for sign/zero extension elimination

This is work originally started by Joern @ Embecosm. There's been a long standing sense that we're generating too many sign/zero extensions on the RISC-V port. REE is useful, but it's really focused on a relatively narrow part of the extension problem. What Joern's patch does is introduce a

Re: [pushed][PATCH v2] LoongArch: Add code generation support for call36 function calls.

在 2023/11/19 上午1:24, Xi Ruoyao 写道: On Sat, 2023-11-18 at 16:16 +0800, chenglulu wrote: Pushed to r14-5567. 在 2023/11/16 下午3:27, Lulu Cheng 写道: When compiling with '-mcmodel=medium', the function call is made through 'pcaddu18i+jirl' if binutils supports call36, otherwise the native implement

Re: Re: [PATCH] RISC-V: Implement -mmemcpy-strategy= options[PR112537]

I've tested it and there are no issues with regression testing. Thanks, Li Xu xu...@eswincomputing.com From: Jeff Law Date: 2023-11-20 05:42 To: Li Xu; gcc-patches CC: kito.cheng; palmer; juzhe.zhong Subject: Re: [PATCH] RISC-V: Implement -mmemcpy-strategy= options[PR112537] On 11/16/23 2

Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext

On Sun, Nov 19, 2023 at 5:15 PM Bruno Haible wrote: > David Edelsohn wrote: > > --disable-threads currently does not completely disable threads. Bruno > is > > suggesting --enable-threads=isoc that relies on mtx mutex functions in > libc. > > Unfortunately, as said in the other mail today, relyi

Re: [RFA] New pass for sign/zero extension elimination

On Sun, 2023-11-19 at 17:47 -0700, Jeff Law wrote: > This is work originally started by Joern @ Embecosm. > > There's been a long standing sense that we're generating too many > sign/zero extensions on the RISC-V port. REE is useful, but it's really > focused on a relatively narrow part of th

Re: [pushed][PATCH v2] LoongArch: Add code generation support for call36 function calls.

On Mon, 2023-11-20 at 09:09 +0800, chenglulu wrote: > > 在 2023/11/19 上午1:24, Xi Ruoyao 写道: > > On Sat, 2023-11-18 at 16:16 +0800, chenglulu wrote: > > > Pushed to r14-5567. > > > > > > 在 2023/11/16 下午3:27, Lulu Cheng 写道: > > > > When compiling with '-mcmodel=medium', the function call is made thr

Re: Re: [PATCH] RISC-V: Implement -mmemcpy-strategy= options[PR112537]

Jeff has approved your patch. You can commit it now. Btw, CC Robin to let him know this patch. Since he will support strcpy/strlenetc builtin with RVV instruction sequence. He will definitely needs compile option like this patch introduce. Thanks. juzhe.zh...@rivai.ai From: Li Xu Date: 2

Re: [pushed][PATCH v2] LoongArch: Add code generation support for call36 function calls.

在 2023/11/20 上午9:51, Xi Ruoyao 写道: On Mon, 2023-11-20 at 09:09 +0800, chenglulu wrote: 在 2023/11/19 上午1:24, Xi Ruoyao 写道: On Sat, 2023-11-18 at 16:16 +0800, chenglulu wrote: Pushed to r14-5567. 在 2023/11/16 下午3:27, Lulu Cheng 写道: When compiling with '-mcmodel=medium', the function call is

Re: [committed] libstdc++: Fix aligned formatting of stacktrace_entry and thread::id [PR112564]

> From: Jonathan Wakely > Date: Thu, 16 Nov 2023 17:20:09 + > PR libstdc++/112564 > * include/std/stacktrace (formatter::format): Format according > to format-spec. > * include/std/thread (formatter::format): Use _Align_right as > default. > * testsuite/19_

Re: [RFA] New pass for sign/zero extension elimination

On Sun, 2023-11-19 at 17:47 -0700, Jeff Law wrote: > This is work originally started by Joern @ Embecosm. > > There's been a long standing sense that we're generating too many > sign/zero extensions on the RISC-V port.  REE is useful, but it's really > focused on a relatively narrow part of the

Re:[pushed and backport] [PATCH] LoongArch: Modify MUSL_DYNAMIC_LINKER.

pushed to r14-5601 backport to r13-8085 and r12-9995. r12 and r13 simultaneously synchronized the patch that changed '/lib64' to '/lib'. 在 2023/11/18 上午11:15, Lulu Cheng 写道: Use no suffix at all in the musl dynamic linker name for hard float ABI. Use -sf and -sp suffixes in musl dynamic link

gcc-patches@gcc.gnu.org

I got spurious fails of tests that required arm_thumb1_movt_ok on a target cpu that did not support movt. Looking into it, I found the arm_movt property to have been cut&pasted into various procs that checked for different properties. They shouldn't share the same test results cache entry, so I

[PATCH #2/4] c++: mark short-enums as packed

Unlike C, C++ doesn't mark enums shortened by -fshort-enums as packed. This makes for undesirable warning differences between C and C++, e.g. c-c++-common/analyzer/null-deref-pr108251-smp_fetch_ssl_fc_has_early*.c triggers a warning about a type cast from a pointer to enum that, when packed, migh

Re: [PATCH #3/4] warn on cast of pointer to packed plus constant

c-c++-common/analyzer/null-deref-pr108251-smp-fetch_ssl_fc_has_early.c gets an unaligned pointer value warning on -fshort-enums targets in C, but not in C++. The former simplifies the offset-and-cast expression enough that check_and_warn_address_or_pointer_of_packed_member finds no more than a t

[PATCH #4/4] testsuite: discard c++ exclusion on underaligned pointer warning

Having extended check_and_warn_address_or_pointer_of_packed_member to find the packed (short) enum pointer in the cast expression coming from the C++ front-end, and amended the C++ front end to mark short enums as TYPE_PACKED, C++ issues the same warning that C does for c-c++-common/analyzer/null

Re: [RFA] New pass for sign/zero extension elimination

On 11/19/23 18:22, Oleg Endo wrote: On Sun, 2023-11-19 at 17:47 -0700, Jeff Law wrote: This is work originally started by Joern @ Embecosm. There's been a long standing sense that we're generating too many sign/zero extensions on the RISC-V port. REE is useful, but it's really focused on a

Re: Re: [PATCH] RISC-V: Implement -mmemcpy-strategy= options[PR112537]

Committed, thanks jeff and juzhe. Thanks, Li Xu xu...@eswincomputing.com From: juzhe.zh...@rivai.ai Date: 2023-11-20 09:55 To: Li Xu; jeffreyalaw; gcc-patches CC: kito.cheng; palmer; Robin Dapp Subject: Re: Re: [PATCH] RISC-V: Implement -mmemcpy-strategy= options[PR112537] Jeff has approved yo

Re: [RFA] New pass for sign/zero extension elimination

On 11/19/23 19:23, Xi Ruoyao wrote: On Sun, 2023-11-19 at 17:47 -0700, Jeff Law wrote: This is work originally started by Joern @ Embecosm. There's been a long standing sense that we're generating too many sign/zero extensions on the RISC-V port.  REE is useful, but it's really focused on a

[pushed] c++: add DECL_IMPLICIT_TEMPLATE_PARM_P macro

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Let's use a more informative name instead of DECL_VIRTUAL_P directly. gcc/cp/ChangeLog: * cp-tree.h (DECL_TEMPLATE_PARM_CHECK): New. (DECL_IMPLICIT_TEMPLATE_PARM_P): New. (decl_template_parm_check): New. * m

[pushed] c++: compare one level of template parms

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- There should never be a reason to compare more than one level of template parameters; additional levels are for the enclosing context, which is either irrelevant (for a template template parameter) or already compared (for a member template)

[PATCH RFC] c++: mangle function template constraints

Tested x86_64-pc-linux-gnu. Are the library bits OK? Any comments before I push this? -- 8< -- Per https://github.com/itanium-cxx-abi/cxx-abi/issues/24 and https://github.com/itanium-cxx-abi/cxx-abi/pull/166 We need to mangle constraints to be able to distinguish between function templates tha

[PATCH] [x86] Support reduc_{and, ior, xor}_scal_m for V4HI/V8QI/V4QImode

Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. Ready push to trunk. gcc/ChangeLog: PR target/112325 * config/i386/i386-expand.cc (emit_reduc_half): Hanlde V8QImode. * config/i386/mmx.md (reduc__scal_): New expander. (reduc__scal_v4qi): Ditto. gc

Re: [RFA] New pass for sign/zero extension elimination

On Sun, 2023-11-19 at 19:51 -0700, Jeff Law wrote: > > On 11/19/23 18:22, Oleg Endo wrote: > > > > On Sun, 2023-11-19 at 17:47 -0700, Jeff Law wrote: > > > This is work originally started by Joern @ Embecosm. > > > > > > There's been a long standing sense that we're generating too many > > > sig

[PATCH] LoongArch: Add support for xorsign.

This patch adds support for xorsign pattern to scalar fp and vector. With the new expands, uniformly using vector bitwise logical operations to handle xorsign. On LoongArch64, floating-point registers and vector registers share the same register, so this patch also allows conversion between LSX

[PATCH] LoongArch: Add support for xorsign.

This patch adds support for xorsign pattern to scalar fp and vector. With the new expands, uniformly using vector bitwise logical operations to handle xorsign. On LoongArch64, floating-point registers and vector registers share the same register, so this patch also allows conversion between LSX

[PATCH] LoongArch: Add support for xorsign.

This patch adds support for xorsign pattern to scalar fp and vector. With the new expands, uniformly using vector bitwise logical operations to handle xorsign. On LoongArch64, floating-point registers and vector registers share the same register, so this patch also allows conversion between LSX

Re: Re: RISC-V: Support XTheadVector extensions

As kito's suggestions. I just have a quick try. This patch should does following things: 1. Remove all new API that RVV1.0 doesn't have. E.g. vlb. They should be another separate patch to be reviewed. So the first series patch should be "Support part of theadvector API base on current RV

  1   2   >