[PATCH v4 6/6] libstdc++: make std::is_object dispatch to new built-in traits

This patch gets std::is_object to dispatch to new built-in traits, __is_function, __is_reference, and __is_void. libstdc++-v3/ChangeLog: * include/std/type_traits (is_object): Use new built-in traits, __is_function, __is_reference, and __is_void. Signed-off-by: Ken Matsui ---

[PATCH v4 4/6] libstdc++: use new built-in trait __is_function for std::is_function

This patch gets std::is_function to dispatch to new built-in trait __is_function. libstdc++-v3/ChangeLog: * include/std/type_traits (is_function): Use __is_function built-in trait. (is_function_v): Likewise. Signed-off-by: Ken Matsui ---

[PATCH v4 5/6] c++, libstdc++: implement __is_void built-in trait

This patch implements built-in trait for std::is_void. Since the new built-in name is __is_void, to avoid unintentional macro replacement, this patch also involves the removal of the existing __is_void in helper_functions.h and cpp_type_traits.h and renaming __is_void to is_void in the test

[PATCH v4 3/6] c++: implement __is_function built-in trait

This patch implements built-in trait for std::is_function. gcc/cp/ChangeLog: * cp-trait.def: Define __is_function. * constraint.cc (diagnose_trait_expr): Handle CPTK_IS_FUNCTION. * semantics.cc (trait_expr_value): Likewise. (finish_trait_expr): Likewise.

[PATCH v4 2/6] libstdc++: use new built-in trait __is_reference for std::is_reference

This patch gets std::is_reference to dispatch to new built-in trait __is_reference. libstdc++-v3/ChangeLog: * include/std/type_traits (is_reference): Use __is_reference built-in trait. (is_reference_v): Likewise. Signed-off-by: Ken Matsui ---

[PATCH v4 1/6] c++: implement __is_reference built-in trait

This patch implements built-in trait for std::is_reference. gcc/cp/ChangeLog: * cp-trait.def: Define __is_reference. * constraint.cc (diagnose_trait_expr): Handle CPTK_IS_REFERENCE. * semantics.cc (trait_expr_value): Likewise. (finish_trait_expr): Likewise.

[PATCH v4 0/6] c++, libstdc++: get std::is_object to dispatch to new built-in traits

Hi, This patch series gets std::is_object to dispatch to built-in traits and implements the following built-in traits, on which std::object depends. * __is_reference * __is_function * __is_void std::is_object was depending on them with disjunction and negation.

Re: [PATCH] rs6000: Don't use TFmode for 128 bits fp constant in toc [PR110011]

On Tue, Jun 6, 2023 at 5:20 AM Kewen.Lin wrote: > Hi, > > As PR110011 shows, when encoding 128 bits fp constant into > toc, we adopts REAL_VALUE_TO_TARGET_LONG_DOUBLE which is > to find the first float mode with LONG_DOUBLE_TYPE_SIZE > bits of precision, it would be TFmode here. But the 128 >

Re: [PATCH 4/4] rs6000: build constant via li/lis;rldic

On Wed, Jun 7, 2023 at 9:56 PM Jiufu Guo wrote: > Hi, > > This patch checks if a constant is possible to be built by "li;rldic". > We only need to take care of "negative li", other forms do not need to > check. > For example, "negative lis" is just a "negative li" with an additional > shift. > >

Re: [PATCH 3/4] rs6000: build constant via li/lis;rldicl/rldicr

On Wed, Jun 7, 2023 at 9:56 PM Jiufu Guo wrote: > Hi, > > This patch checks if a constant is possible left/right cleaned on a rotated > value from a negative value of "li/lis". If so, we can build the constant > through "li/lis ; rldicl/rldicr". > > Bootstrap and regtest pass on ppc64{,le}. >

Re: [PATCH 2/4] rs6000: build constant via lis;rotldi

On Wed, Jun 7, 2023 at 9:55 PM Jiufu Guo wrote: > Hi, > > This patch checks if a constant is possible to be rotated to/from a > negative > value from "lis". If so, we could use "lis;rotldi" to build it. > The positive value of "lis" does not need to be analyzed. Because if a > constant can be

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

On Wed, Jun 7, 2023 at 9:55 PM Jiufu Guo wrote: > Hi, > > This patch checks if a constant is possible to be rotated to/from a > positive > or negative value from "li". If so, we could use "li;rotldi" to build it. > > Bootstrap and regtest pass on ppc64{,le}. > Is this ok for trunk? > > BR, >

[PATCH v1] RISC-V: Support RVV FP16 MISC vlmul ext intrinsic API

From: Pan Li This patch support the intrinsic API of FP16 ZVFHMIN vlmul ext. Aka: vfloat16*_t <==> vfloat16*_t. >From the user's perspective, it is reasonable to do some type convert between vfloat16*_t and vfloat16*_t when only ZVFHMIN is enabled. Signed-off-by: Pan Li gcc/ChangeLog:

RE: [PATCH V3] RISC-V: Rework Phase 5 && Phase 6 of VSETVL PASS

Committed, thanks Jeff. Pan -Original Message- From: Gcc-patches On Behalf Of Jeff Law via Gcc-patches Sent: Sunday, June 11, 2023 12:49 AM To: juzhe.zh...@rivai.ai; gcc-patches@gcc.gnu.org Cc: kito.ch...@sifive.com; pal...@rivosinc.com; rdapp@gmail.com Subject: Re: [PATCH V3]

[GCC 13 PATCH] PR target/109973: CCZmode and CCCmode variants of [v]ptest.

This is a backport of the fixes for PR target/109973 and PR target/110083. This backport to the releases/gcc-13 branch has been tested on x86_64-pc-linux-gnu with make bootstrap and make -k check, both with and without --target_board=unix{-m32} with no new failures. Ok for gcc-13, or should we

[PATCH] libstdc++: Clarify manual demangle doc

libstdc++-v3/ChangeLog: * doc/xml/manual/extensions.xml: Remove demangle exception description and include. --- libstdc++-v3/doc/xml/manual/extensions.xml | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/libstdc++-v3/doc/xml/manual/extensions.xml

[c++] Implement DR 976

DR 976 affects conversion operator deduction, swapping reference stripping and cv-qual removal. This allows 'Y::operator P const & ()' to deduce T against a call wanting plain A (previously that would fail as 'P const' cannot be deduced from 'A'). It also affects deductions for array- or

Re: [PATCH] Implement ipa_vr hashing.

On 5/29/23 16:51, Martin Jambor wrote: Hi, On Mon, May 22 2023, Aldy Hernandez via Gcc-patches wrote: Implement hashing for ipa_vr. When all is said and done, all these patches incurr a 7.64% slowdown for ipa-cp, with is entirely covered by the similar 7% increase in this area last week.

libgfortran: remove support for --enable-intermodule

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109373 I don’t believe it is widely used, and it was removed from everywhere else in gcc. Bootstrapped and regtested on x86_64-pc-linux-gnu. OK to commit? FX 0001-libgfortran-remove-support-for-enable-intermodule.patch Description: Binary data

Re: [PATCH] Convert ipcp_vr_lattice to type agnostic framework.

On 6/10/23 10:49, Martin Jambor wrote: Hi, thanks for dealing with my requests. On Wed, Jun 07 2023, Aldy Hernandez wrote: On 5/26/23 18:17, Martin Jambor wrote: Hello, On Mon, May 22 2023, Aldy Hernandez wrote: I've adjusted the patch with some minor cleanups that came up when I

gcc/config.in was not regenerated

Hi, Building GCC in maintainer mode leads to changes in gcc/config.in : > diff --git a/gcc/config.in b/gcc/config.in > index 4cad077bfbe..25442c59aec 100644 > --- a/gcc/config.in > +++ b/gcc/config.in > @@ -67,6 +67,12 @@ > #endif > +/* Define to larger than one set the

Re: Splitting up 27_io/basic_istream/ignore/wchar_t/94749.cc (takes too long)

On Jun 9, 2023, at 2:47 PM, Bernhard Reutner-Fischer wrote: > > On 9 June 2023 19:18:45 CEST, Mike Stump via Gcc-patches > wrote: >> simulation ports. Maybe a 20-100x speedup? If you want to go this way I'd >> say do it in python at the bottom as it would be nice to switch over to >>

Re: [PATCH 11/11] riscv: thead: Add support for the XTheadFMemIdx ISA extension

On 4/28/23 00:23, Christoph Muellner wrote: From: Christoph Müllner The XTheadFMemIdx ISA extension provides additional load and store instructions for floating-point registers with new addressing modes. The following memory accesses types are supported: * ftype = [w,d] (single-precision,

Re: [PATCH 10/11] riscv: thead: Add support for the XTheadMemIdx ISA extension

On 4/28/23 00:23, Christoph Muellner wrote: From: Christoph Müllner The XTheadMemIdx ISA extension provides a additional load and store instructions with new addressing modes. The following memory accesses types are supported: * ltype = [b,bu,h,hu,w,wu,d] * stype = [b,h,w,d] The following

Re: Ping^^: [PATCH V2] extract DF/SF/SI/HI/QI subreg from parameter word on stack

On 5/10/23 19:20, Jiufu Guo wrote: Hi, I would like to ping: https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609396.html We know there are a few issues related to aggregate parameter and returns. I'm thinking if it is ok for trunk to use this patch to resolve part of those issues.

Re: [patch,avr]: Improve bit-extractions as of PR109907.

On 6/7/23 02:41, Georg-Johann Lay wrote: Subject: [patch,avr]: Improve bit-extractions as of PR109907. From: Georg-Johann Lay Date: 6/7/23, 02:41 To: gcc-patches@gcc.gnu.org CC: Jeff Law , Denis Chertykov This patch improves bit-extractions on AVR. Andrew added some patches so that more

Re: [patch,avr] Fix PR109650 wrong code

On 5/19/23 02:49, Georg-Johann Lay wrote: Subject: Re: [patch,avr] Fix PR109650 wrong code From: Georg-Johann Lay Date: 5/19/23, 02:49 To: gcc-patches@gcc.gnu.org CC: Jeff Law , Denis Chertykov , Senthil Kumar Selvaraj ...Ok, and now with the patch attached... Here is a revised

Re: [PATCH V3] RISC-V: Rework Phase 5 && Phase 6 of VSETVL PASS

On 6/9/23 17:11, juzhe.zh...@rivai.ai wrote: From: Juzhe-Zhong Address comments from Jeff. This patch is to rework Phase 5 && Phase 6 of VSETVL PASS since Phase 5 && Phase 6 are quite messy and cause some bugs discovered by my downstream auto-vectorization test-generator. Before this

Re: [patch] Fix PR101188 wrong code from postreload

On 6/3/23 12:38, Georg-Johann Lay wrote:     }   note_stores (insn, move2add_note_store, insn); The point is that in the continue block, the effect of the insn is recorded even if !success, it's just the computed effect of the code. Moreover, "next" is REG = REG + CONST_INT, so

Re: [PATCH 1/2] Implementation of new RISCV optimizations pass: fold-mem-offsets.

On 5/25/23 06:35, Manolis Tsamis wrote: Implementation of the new RISC-V optimization pass for memory offset calculations, documentation and testcases. gcc/ChangeLog: * config.gcc: Add riscv-fold-mem-offsets.o to extra_objs. * config/riscv/riscv-passes.def

Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions

Given the agreement that the patch is not making things for powerpc worse, and the review by Steve, I have committed as https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=17bccd1d2c0fa1f08e0483c8ed841994a95febb0 Best, FX

Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions

Hi Thomas, > The KIND=17 is a bit of a kludge. It is not visible for > user programs, they use KIND=16, but this is then translated > to library calls as if it was KIND=17 if the IEEE 128-bit floats > are selected Can you check what the IEEE test results are when -mabi=ieeelongdouble is

Re: [PATCH] Fortran: add IEEE_QUIET_* and IEEE_SIGNALING_* comparisons

Hi Harald, > I just looked at that thread. I guess if you answer Mikael's > questions at > https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601744.html > the patch will be fine. Amended patch, adding the required testing of signalling vs. quiet behaviour. I still need to get an OK on

Re: [RFC] Add stdckdint.h header for C23

On Sat, Jun 10, 2023 at 12:37:40PM +0200, Jakub Jelinek via Gcc-patches wrote: > I think changing __builtin_classify_type behavior after 35 years > would be dangerous, shall we introduce a new similar builtin which > would just never promote the argument/perform array/function/enum > conversions

[RFC] Add stdckdint.h header for C23

Hi! The following patch is an attempt to implement the C23 stdckdint.h header on top of our GNU extension - __builtin_{add,sub,mul}_overflow builtins. I have looked at gnulib stdckdint.h and they are full of workarounds for various compilers, EDG doesn't do this, clang <= 14 can't multiply

Re: [PATCH] Convert ipcp_vr_lattice to type agnostic framework.

Hi, thanks for dealing with my requests. On Wed, Jun 07 2023, Aldy Hernandez wrote: > On 5/26/23 18:17, Martin Jambor wrote: >> Hello, >> >> On Mon, May 22 2023, Aldy Hernandez wrote: >>> I've adjusted the patch with some minor cleanups that came up when I >>> implemented the rest of the IPA

Re: [PATCH] (Re: Splitting up 27_io/basic_istream/ignore/wchar_t/94749.cc (takes too long))

On Sat, 10 Jun 2023, 06:18 Hans-Peter Nilsson via Libstdc++, < libstd...@gcc.gnu.org> wrote: > Thank you for your consideration. (Or is that phrase only used > negatively?) > > > From: Jonathan Wakely > > Date: Fri, 9 Jun 2023 21:40:15 +0100 > > > test01, test02, test03 and test04 should run