Re: [PATCH v7] RISC-V: Implement __init_riscv_feature_bits, __riscv_feature_bits, and __riscv_vendor_feature_bits

> On Oct 14, 2024, at 14:12, Kito Cheng wrote: > > On Mon, Oct 14, 2024 at 1:40 PM Yangyu Chen > wrote: >> >>> On Oct 14, 2024, at 12:32, Kito Cheng wrote: >>> >>> I prefer not to handle the extension implication rules, as it's easy >>> for them to get out of sync, and this should be the

Re: [PATCH] middle-end/116891 - fix (negate (IFN_FNMS@3 @0 @1 @2)) -> (IFN_FMA @0 @1 @2)

On Mon, Oct 14, 2024 at 08:14:01AM +0200, Richard Biener wrote: > Transforming -fma (-a, b, -c) to fma (a, b, c) is only valid when > not rounding towards -inf or +inf as the sign of the multiplication > changes. > > Bootstrap and regtest running on x86_64-unknown-linux-gnu, OK? > > Richard. > >

ping: [PATCH] Fix crash with constant initializer

The original submission patch is at: https://gcc.gnu.org/pipermail/gcc-patches/2024-September/664127.html Thanks in advance. -- Eric Botcazou

[PATCH] middle-end/116891 - fix (negate (IFN_FNMS@3 @0 @1 @2)) -> (IFN_FMA @0 @1 @2)

Transforming -fma (-a, b, -c) to fma (a, b, c) is only valid when not rounding towards -inf or +inf as the sign of the multiplication changes. Bootstrap and regtest running on x86_64-unknown-linux-gnu, OK? Richard. PR middle-end/116891 * match.pd ((negate (IFN_FNMS@3 @0 @1 @2)) -

Re: [PATCH v7] RISC-V: Implement __init_riscv_feature_bits, __riscv_feature_bits, and __riscv_vendor_feature_bits

On Mon, Oct 14, 2024 at 1:40 PM Yangyu Chen wrote: > > > > > On Oct 14, 2024, at 12:32, Kito Cheng wrote: > > > > I prefer not to handle the extension implication rules, as it's easy > > for them to get out of sync, and this should be the linux kernel's > > responsibility rather than libgcc's. >

Re: [PATCH v7] RISC-V: Implement __init_riscv_feature_bits, __riscv_feature_bits, and __riscv_vendor_feature_bits

> + if (hwprobe_ima_ext.value & RISCV_HWPROBE_IMA_C) > +{ > + SET_EXT (C); > + SET_EXT (ZCA); > + if (hwprobe_ima_ext.value & RISCV_HWPROBE_IMA_FD) > + { > + SET_EXT (ZCF); Zcf if F is specified (RV32 only) https://github.com/riscv/riscv-isa-manual/blob/main/src/

Re: [PATCH] [RFC] target/117072 - more RTL FMA canonicalization

On Mon, 14 Oct 2024, Hongtao Liu wrote: > On Sun, Oct 13, 2024 at 8:02 PM Richard Biener wrote: > > > > On Sun, 13 Oct 2024, Hongtao Liu wrote: > > > > > On Fri, Oct 11, 2024 at 8:33 PM Hongtao Liu wrote: > > > > > > > > On Fri, Oct 11, 2024 at 8:22 PM Richard Biener > > > > wrote: > > > > > >

Re: [PATCH v7] RISC-V: Implement __init_riscv_feature_bits, __riscv_feature_bits, and __riscv_vendor_feature_bits

> On Oct 14, 2024, at 12:32, Kito Cheng wrote: > > I prefer not to handle the extension implication rules, as it's easy > for them to get out of sync, and this should be the linux kernel's > responsibility rather than libgcc's. > I still prefer to handle the extension here since users may us

Re: [PATCH 3/5][_Hashtable] Avoid redundant usage of rehash policy

Here is a fresh rebased version. François On 04/01/2024 06:50, François Dumont wrote: Here is an updated version.     libstdc++: [_Hashtable] Avoid redundant usage of rehash policy     Bypass call to __detail::__distance_fwd and the check if rehash is needed when     instantiating from an it

Re: [PATCH v7] RISC-V: Implement __init_riscv_feature_bits, __riscv_feature_bits, and __riscv_vendor_feature_bits

I prefer not to handle the extension implication rules, as it's easy for them to get out of sync, and this should be the linux kernel's responsibility rather than libgcc's. > +struct { > + unsigned vendorID; This field is gone since it moved to __riscv_cpu_model > + unsigned length; > + unsig

Re: [PR middle-end/114635] Set OMP safelen handling to INT_MAX when the pragma didn’t provide one.

Hi Richard, Thanks for the review. > On 8 Oct 2024, at 7:15 pm, Richard Biener wrote: > > External email: Use caution opening links or attachments > > > On Mon, Aug 5, 2024 at 7:05 AM Kugan Vivekanandarajah > wrote: >> >> >> >>> On 15 Jul 2024, at 5:18 pm, Jakub Jelinek wrote: >>> >>> E

Re: [PATCH] SVE intrinsics: Fold constant operands for svlsl.

Pinging with updated subject, had missed the [PATCH] header before. Regards, Soumya > On 24 Sep 2024, at 2:00 PM, Soumya AR wrote: > > This patch implements constant folding for svlsl. Test cases have been added > to > check for the following cases: > > Zero, merge, and don't care predication

Re: [PATCH] [RFC] target/117072 - more RTL FMA canonicalization

On Sun, Oct 13, 2024 at 8:02 PM Richard Biener wrote: > > On Sun, 13 Oct 2024, Hongtao Liu wrote: > > > On Fri, Oct 11, 2024 at 8:33 PM Hongtao Liu wrote: > > > > > > On Fri, Oct 11, 2024 at 8:22 PM Richard Biener wrote: > > > > > > > > The following helps the x86 backend by canonicalizing FMAs

Re: [wwwdocs] projects/gomp: Update for TR13; gcc-15/changes.html link to routine doc

On Tue, 8 Oct 2024, Tobias Burnus wrote: > Update and sync with > https://gcc.gnu.org/onlinedocs/libgomp/OpenMP-Implementation-Status.html > > Current page: https://gcc.gnu.org/projects/gomp/ (and > https://gcc.gnu.org/gcc-15/changes.html ) > > Comments before I apply it? Quite some work! I like

[SH][committed] PR 113533

For memory loads/stores (that contain a MEM rtx) sh_rtx_costs would wrongly report a cost lower than 1 insn which is not accurate as it makes loads/stores appear cheaper than simple arithmetic insns. The cost of a load/store insn is at least 1 insn plus the cost of the address expression (some add

[SH][committed] Add -fno-math-errno to fsca,fsrra tests.

Without -fno-math-errno some of the test might fail because the expected insns will not be generated. Tested with make -k check RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/- mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}" Committed to master. gcc/testsuite/ChangeLog: * gcc.target/sh

[PATCH 5/5] passes: Remove limit on the number of params

Having a limit of 2 params for NEXT_PASS was just done because I didn't think there was a way to handle arbitrary number of params. But I found that we can handle this via a static const variable array (constexpr so we know it is true or false at compile time) and just loop over the array. Note

[PATCH 4/5] dce: Use a base common base class for pass_cd_dce and pass_dce

The classes pass_dce and pass_cd_dce share the same mechansim for their params and almost the same execute functionality so let's create a new base class which will be used for these two classes and move the common code into the same one. Note update_address_taken_p was updated to be a NSDMI inste

[PATCH 3/5] dce: add remove_unused_locals conditionally to the todos [PR117096]

This is the updated patch with the suggestion from: https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665217.html Where we use a second arg/param to set which passes we want to have the remove_unused_locals on the dce. Bootstrapped and tested on x86_64-linux-gnu. gcc/ChangeLog: PR t

[PATCH 1/5] passes: Move #undef to pass-instances.def

Like what was done r6-4608-g0aad01985747ab for builtins.def/DEF_BUILTIN, the same should be done for the defines that are used for pass-instances.def. Bootstrapped and tested on x86_64-linux-gnu. gcc/ChangeLog: * gen-pass-instances.awk: Print out the #undefs. * pass_manager.h Don

[PATCH 2/5] passes: Allow for second param for NEXT_PASS

Right now we currently only support 1 parameter for each pass in NEXT_PASS. We also don't error out if someone tries to use more than 1. This adds support for more than one but only to a max of max_number_args (which is currently 2). In the next patch, this will be used for DCE, adding a new parame

[PATCH] libquadmath: Typo in powq summary

Hello, since step 9 in "Basics: Contributing to GCC in 10 easy steps" says I should not commit the first few patches, I kindly ask someone to commit the following for me: libquadmath\ChangeLog: * math/powq.c: --- a/libquadmath/math/powq.c +++ b/libquadmath/math/powq.c @@ -37,7 +37,7 @@

Re: [PATCH] libstdc++: testsuite: adjust name_fortify test for pre-defined _FORTIFY_SOURCE

Jonathan Wakely writes: > On Sun, 13 Oct 2024 at 23:23, Sam James wrote: >> >> Otherwise we get failures with toolchains that have _FORTIFY_SOURCE >> defined already to a different value like 3. > > I was going to say we could do: > > #ifndef _FORTIFY_SOURCE > #define _FORTIFY_SOURCE 2 > #endif

[PATCH] libstdc++: Implement LWG 3798 for range adaptors [PR106676]

Tested x86_64-linux. -- >8 -- LWG 3798 modified the iterator_category of the iterator types for transform_view, join_with_view, zip_transform_view and adjacent_transform_view, to allow the iterator's reference type to be an rvalue reference. libstdc++-v3/ChangeLog: PR libstdc++/106676

[PATCH] libstdc++: Implement LWG 3564 for ranges::transform_view

Tested x86_64-linux. -- >8 -- The _Iterator type returned by begin() const uses const F& to transform the elements, so it should use const F& to determine the iterator's value_type and iterator_category as well. This was accepted into the WP in July 2022. libstdc++-v3/ChangeLog: * incl

[PATCH] libstdc++: Refactor std::uninitialized_{copy, fill, fill_n} algos [PR68350]

Tested x86_64-linux. -- >8 -- This refactors the std::uninitialized_copy, std::uninitialized_fill and std::uninitialized_fill_n algorithms to directly perform memcpy/memset optimizations instead of dispatching to std::copy/std::fill/std::fill_n. The reasons for this are: - Use 'if constexpr' to

[PATCH] libstdc++: Use std::move for iterator in ranges::fill [PR117094]

Tested x86_64-linux. -- >8 -- Input iterators aren't required to be copyable. libstdc++-v3/ChangeLog: PR libstdc++/117094 * include/bits/ranges_algobase.h (__fill_fn): Use std::move for iterator that might not be copyable. * testsuite/25_algorithms/fill/constrain

Re: [PATCH] libstdc++: testsuite: adjust name_fortify test for pre-defined _FORTIFY_SOURCE

On Sun, 13 Oct 2024 at 23:23, Sam James wrote: > > Otherwise we get failures with toolchains that have _FORTIFY_SOURCE > defined already to a different value like 3. I was going to say we could do: #ifndef _FORTIFY_SOURCE #define _FORTIFY_SOURCE 2 #endif But I realised that the original names.c

[PATCH] libstdc++: testsuite: adjust name_fortify test for pre-defined _FORTIFY_SOURCE

Otherwise we get failures with toolchains that have _FORTIFY_SOURCE defined already to a different value like 3. libstdc++-v3/ChangeLog: * testsuite/17_intro/names_fortify.cc: Undefine _FORTIFY_SOURCE. --- I'll commit later if no objections. libstdc++-v3/testsuite/17_intro/names_fortify

Re: [PATCH RFC] build: enable C++11 narrowing warnings

On Tue, Sep 24, 2024 at 2:41 AM Richard Biener wrote: > > On Mon, Sep 23, 2024 at 3:41 PM Jason Merrill wrote: > > > > On 9/23/24 9:05 AM, Richard Biener wrote: > > > On Sat, Sep 21, 2024 at 2:49 AM Jason Merrill wrote: > > >> > > >> Tested x86_64-pc-linux-gnu. OK for trunk? > > >> > > >> -- 8<

Re: [PATCH 0/5] Provide better definitions of NULL

Hi Joseph, On Fri, Oct 11, 2024 at 01:44:36PM GMT, Alejandro Colomar wrote: > Hi, > > This is just an untested draft. If there's rough agreement that this is > wanted, I'll test it, write changelog, etc. > > The intention of this change is to help improve the common C/C++ > language subset, pro

[releases/gcc-14 PATCH COMMITTED] testsuite: fix PR111613 test

PR ipa/111613 * gcc.c-torture/pr111613.c: Rename to.. * gcc.c-torture/execute/pr111613.c: ...this. (cherry picked from commit 5e5d7a88932b132437069f716160f8b20862890b) --- I actually thought I'd backported this already. Pushed as obvious, as the test issue was only introduc

[committed] libstdc++: Fix ranges::copy_backward for a single memcpyable element [PR117121]

Tested x86_64-linux. Pushed to trunk. -- >8 -- The result iterator needs to be decremented before writing to it. Improve the PR 108846 tests for all of std::copy, std::copy_n, std::copy_backward, and the std::ranges versions. libstdc++-v3/ChangeLog: PR libstdc++/117121 * includ

Re: [PATCH] libstdc++: improve std::atomic compatibility with Clang

On Sun, 13 Oct 2024 at 18:59, Giuseppe D'Angelo wrote: > > Hello, > > On 11/10/2024 21:43, Jonathan Wakely wrote: > > > Or alternatively, and arguably simpler, we could get rid of the ugly > > _GLIBCXX20_INIT macro and just do this: > > +#if __cpp_lib_atomic_value_initialization > > + atomic(

Re: [PATCH v4] libstdc++: implement concatenation of strings and string_views

Hello, On 09/10/2024 22:39, Patrick Palka wrote: +#if __glibcxx_string_view >= 202403L + // const string & + string_view + template +[[nodiscard]] +constexpr inline basic_string<_CharT, _Traits, _Alloc> Redundant 'inline's +operator+(const basic_string<_CharT, _Traits, _Alloc>&

Re: [PATCH] libstdc++: improve std::atomic compatibility with Clang

Hello, On 11/10/2024 21:43, Jonathan Wakely wrote: Or alternatively, and arguably simpler, we could get rid of the ugly _GLIBCXX20_INIT macro and just do this: +#if __cpp_lib_atomic_value_initialization + atomic() noexcept (is_nothrow_default_constructible_v<_Tp>) + requires (is_defau

[PATCH v2] testsuite: Sanitize pacbti test cases for Cortex-M

Ok for trunk and releases/gcc-14? Changes since v1: - Dropped changes to dg- instructions. These will be addressed in a separate set of patches later. -- Some of the test cases were scanning for "bti", but it would, incorrectly, match the ".arch_extenssion pacbti". gcc/testsuite/ChangeLog:

[PATCH] testsuite: arm: Update expected asm in no-literal-pool-m0.c

Ok for trunk? -- With the changes in r15-1579-g792f97b44ff, the constants have been updated. This patch aligns the constants in the test cases with the updated implementation. gcc/testsuite/ChangeLog: * gcc.target/arm/pure-code/no-literal-pool-m0.c: Update expected asm. Signed-

[COMMITED] MAINTAINERS: Add myself to write after approval

ChangeLog: * MAINTAINERS: Add myself to write after approval Signed-off-by: Josef Melcr --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4a53521d8eb..f94aa9aeb79 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -657,6 +657,7 @@ Bryce McKin

[PATCH v7] RISC-V: Implement __init_riscv_feature_bits, __riscv_feature_bits, and __riscv_vendor_feature_bits

From: Kito Cheng This provides a common abstraction layer to probe the available extensions at run-time. These functions can be used to implement function multi-versioning or to detect available extensions. The advantages of providing this abstraction layer are: - Easy to port to other new platf

Re: [PATCH] c++: Restore rust front-end build [PR117114]

The patch failed so I’ve reverted the offending commit for the moment; commit r15-4301-ga4eec6c712ec16 refers. I’ll work on a resubmit via the initial PR (109918). Apologies for the breakage. Simon On 13 Oct 2024, at 13:55, Simon Martin wrote: > The patch that I merged via r15-4282-g60163c8573

m68k: replace reload_in_progress by reload_in_progress || lra_in_progress

For now assume that LRA needs the same treatment as reload. * config/m68k/m68k.md ("movsi", "movxf"): Replace reload_in_progress by reload_in_progress || lra_in_progress. * config/m68k/m68k.cc (m68k_legitimate_mem_p) (emit_move_sequence): Likewise. * config/

Re: [RFC PATCH] RISC-V: Implement riscv_minimal_hwprobe_feature_bits

> On Oct 7, 2024, at 20:37, Kito Cheng wrote: > > I suggest not handling the extension implication rules. This way, it > can simplify > the logic and reduce the cost of run-time checks. > > Also, you need to consider situations where that extension can't be detected. For this, I would also l

[PATCH] tree-optimization/116290 - fix compare-debug issue in ldist

Loop distribution does different analysis with -g0/-g due to counting a debug stmt starting a BB against a limit which will everntually lead to different IVOPTs choices. I've fixed a possible IVOPTs issue on the way even though it doesn't make a difference here. Bootstrap and regtest running on x

Re: [PATCH] tree-optimization/116481 - avoid building function_type[]

On Sun, Oct 13, 2024 at 12:50:31PM +0200, Richard Biener wrote: > The following avoids building an array type with function or method > element type during diagnosing an array bound violation as this > will result in an error, rejecting a program with a not too useful > error message. Instead buil

[releases/gcc-13 PATCH 1/2] Use delete[] in int_range destructor [PR109920]

From: Aldy Hernandez gcc/ChangeLog: PR tree-optimization/109920 * value-range.h (RESIZABLE>::~int_range): Use delete[]. (cherry picked from commit 493a63af6cbab094c36a76435c12b1886328dab8) --- gcc/value-range.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a

[releases/gcc-13 PATCH 2/2] Remove buggy special case in irange::invert [PR109934].

From: Aldy Hernandez This patch removes a buggy special case in irange::invert which seems to have been broken for a while, and probably never triggered because the legacy code was handled elsewhere, and the non-legacy code was using an int_range_max of int_range<255> which made it extremely like

[releases/gcc-13 PATCH 0/2] Two backports (Valgrind noise, wrong-code)

Two backports for Valgrind noise (PR109920, PR116808) and wrong-code (PR109934, PR117100). OK? Bootstrapped and regtested with no regressions. Aldy Hernandez (2): Use delete[] in int_range destructor [PR109920] Remove buggy special case in irange::invert [PR109934]. gcc/testsuite/gcc.dg/tre

Re: [PATCH] [RFC] target/117072 - more RTL FMA canonicalization

On Sun, 13 Oct 2024, Hongtao Liu wrote: > On Fri, Oct 11, 2024 at 8:33 PM Hongtao Liu wrote: > > > > On Fri, Oct 11, 2024 at 8:22 PM Richard Biener wrote: > > > > > > The following helps the x86 backend by canonicalizing FMAs to have > > > any negation done to one of the commutative multiplicati

[PATCH] c++: Restore rust front-end build [PR117114]

The patch that I merged via r15-4282-g60163c85730e6b breaks the build for the rust front-end because it does not work well when virtual inheritance is in play. The problem is that in such a case, an overrider and its overridden base method might have a different DECL_VINDEX, and the derived method

[PATCH] tree-optimization/116907 - stale BLOCK reference from DECL_VALUE_EXPR

When we remove unused BLOCKs we fail to clean references to them from DECL_VALUE_EXPRs of variables in other BLOCKs which in the PR causes LTO streaming to walk into pointers to GGC freed blocks. There's the question of whether such DECL_VALUE_EXPRs should keep variables and blocks referenced live

[PATCH] tree-optimization/116481 - avoid building function_type[]

The following avoids building an array type with function or method element type during diagnosing an array bound violation as this will result in an error, rejecting a program with a not too useful error message. Instead build such array type manually. Bootstrapped and tested on x86_64-unknown-l

Re: [PATCH] [RFC] target/117072 - more RTL FMA canonicalization

On Fri, Oct 11, 2024 at 8:33 PM Hongtao Liu wrote: > > On Fri, Oct 11, 2024 at 8:22 PM Richard Biener wrote: > > > > The following helps the x86 backend by canonicalizing FMAs to have > > any negation done to one of the commutative multiplication operands > > be done to a register (and not a memo

Re: [PATCH] warning option for traps (-Wtrap)

Am Sonntag, dem 13.10.2024 um 10:56 +0200 schrieb Richard Biener: > On Sat, 12 Oct 2024, Martin Uecker wrote: > > > Am Samstag, dem 12.10.2024 um 18:44 +0200 schrieb Richard Biener: > > > > > > > Am 12.10.2024 um 16:43 schrieb Martin Uecker : > > > > > > > >  > > > > There is code which should

Re: [PATCH] DSE: add remove_unused_locals to the todos [PR117096]

On Sun, Oct 13, 2024 at 12:07 AM Andrew Pinski wrote: > > This is a better patch to fix PR 117096 (phiopt vs clobbers). > The only time we remove clobbers of local variables is during > remove_unused_locals. Since DSE might remove all of the stores > to a local variable, it makes sense to also try

Re: [PATCH] warning option for traps (-Wtrap)

On Sat, 12 Oct 2024, Martin Uecker wrote: > Am Samstag, dem 12.10.2024 um 18:44 +0200 schrieb Richard Biener: > > > > > Am 12.10.2024 um 16:43 schrieb Martin Uecker : > > > > > >  > > > There is code which should not fail at run-time. For this, > > > it is helpful to get a warning when a compi

Re: [PATCH v6] RISC-V: Implement __init_riscv_feature_bits, __riscv_feature_bits, and __riscv_vendor_feature_bits

> On Oct 7, 2024, at 18:15, Kito Cheng wrote: > > Could you implement the latest API defined in the doc? > > struct { > unsigned length; > unsigned long long features[]; > } __riscv_feature_bits; > > struct { > unsigned length; > unsigned long long features[]; > } __riscv_vendor_feature_bits;

Re: [Patch] Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP' __builtin_is_initial_device

Now pushed as r15-4298-g3269a722b7a036. Thanks to Bernhard for some proof reading! Tobias Tobias Burnus wrote: Anyone feeling like reviewing this patch? (Mainly the Fortran side?!?) — Or should I declare it as OpenMP/(OpenACC) patch and just commit it? → https://gcc.gnu.org/pipermail/gcc-pat