Re: [PATCH] Adjust memory_move_cost for MASK_REGS when MODE_SIZE > 8.

2023-03-30 Thread Uros Bizjak via Gcc-patches
On Fri, Mar 31, 2023 at 7:11 AM liuhongt wrote: > > RA sometimes will use lowest the cost of the mode with all different > regclasses > w/o check if it's hard_regno_mode_ok. > It's impossible to put modes whose size > 8 into MASK_REGS, ajdust the cost to > avoid potential performance issue. I

[r13-6945 Regression] FAIL: 23_containers/vector/bool/allocator/copy.cc (test for excess errors) on Linux/x86_64

2023-03-30 Thread haochen.jiang via Gcc-patches
On Linux/x86_64, 429a7a88438cc80e7c58d9f63d44838089899b12 is the first bad commit commit 429a7a88438cc80e7c58d9f63d44838089899b12 Author: Andrew MacLeod Date: Tue Mar 28 12:16:34 2023 -0400 Add recursive GORI recompuations with a depth limit. caused FAIL:

[GCC14 QUEUE PATCH] RISC-V: Support chunk = 128bit for 'V' Extension

2023-03-30 Thread juzhe . zhong
From: Juzhe-Zhong Currently, we only support chunk = 32 bit for zve32* and chunk = 64 for zve64*. According to RVV ISA chapter 18.3 V: Vector Extension for Application Processors We should also support chunk = 128 bit for Full 'V' extension. Also, currently, LMUL = 1 for INT64 is VNx1DImode

[PATCH] Adjust memory_move_cost for MASK_REGS when MODE_SIZE > 8.

2023-03-30 Thread liuhongt via Gcc-patches
RA sometimes will use lowest the cost of the mode with all different regclasses w/o check if it's hard_regno_mode_ok. It's impossible to put modes whose size > 8 into MASK_REGS, ajdust the cost to avoid potential performance issue. Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. Ok for

Re: [Patch] c-c++-common/Warray-bounds.c: fix excess warnings on LLP64

2023-03-30 Thread Jonathan Yong via Gcc-patches
On 3/31/23 00:09, Mike Stump wrote: On Feb 27, 2023, at 2:29 AM, Jonathan Yong via Gcc-patches wrote: Attached patch OK? Ok. * c-c++-common/Warray-bounds.c: Fix excess warnings on LLP64.<0001-c-c-common-Warray-bounds.c-fix-excess-warnings-on-LL.patch>

Re: [PATCH v4] rs6000: Fix incorrect RTL for Power LE when removing the UNSPECS [PR106069]

2023-03-30 Thread Xionghu Luo via Gcc-patches
Thanks, On 2023/3/31 03:30, Segher Boessenkool wrote: Hi! On Fri, Feb 10, 2023 at 10:59:52AM +0800, Xionghu Luo via Gcc-patches wrote: The native RTL expression for vec_mrghw should be same for BE and LE as they are register and endian-independent. This isn't so obvious at all. All

Re: [Patch] c-c++-common/Warray-bounds.c: fix excess warnings on LLP64

2023-03-30 Thread Mike Stump via Gcc-patches
On Feb 27, 2023, at 2:29 AM, Jonathan Yong via Gcc-patches wrote: > > Attached patch OK? Ok. >* c-c++-common/Warray-bounds.c: Fix excess warnings on > > LLP64.<0001-c-c-common-Warray-bounds.c-fix-excess-warnings-on-LL.patch>

Re: [PATCH] rtl-optimization: ppc backend generates unnecessary signed extension.

2023-03-30 Thread Hans-Peter Nilsson
On Fri, 24 Mar 2023, Peter Bergner via Gcc-patches wrote: > On 3/23/23 6:12 PM, Jeff Law via Gcc-patches wrote: > Is there a reason why REE cannot see that our (reg:QI 4) is a param > register > and thus due to our ABI, already correctly sign/zero extended? > >>> > >>> I don't

Re: [PATCH] Introduce -nolibstdc++ option

2023-03-30 Thread Gerald Pfeifer
On Thu, 30 Mar 2023, Alexandre Oliva wrote: > How about this, does this seem useful? I like it - helpful and easy to understand. :-) Gerald

Re: [pushed] wwwdocs: gcc-4.7: Adjust dwarfstd.org links

2023-03-30 Thread Gerald Pfeifer
On Thu, 30 Mar 2023, Mark Wielaard wrote: >>> Business as usual - 301 Moved Permanently. >> Just FYI, dwarfstd is now hosted by sourceware too. So I doubt these >> URLs will change after this. Famous last words. :-) > Indeed, see >

Re: [wwwdocs] Mention the GNU C enum changes in gcc-13/changes.html

2023-03-30 Thread Gerald Pfeifer
On Fri, 24 Mar 2023, Jakub Jelinek wrote: > Shall we mention it in porting_to.html as well? > The only known affected package is (was?) the Linux kernel. If in a rebuild of Fedora (or openSUSE) the only affected package is the kernel, we probably don't need to go for porting_to.html? > ---

Re: [PATCH]middle-end Guard value_replacement and store_elim from seeing diamonds.

2023-03-30 Thread Andrew Pinski via Gcc-patches
On Fri, Aug 5, 2022 at 6:16 AM Tamar Christina via Gcc-patches wrote: > > Hi All, > > This excludes value_replacement and store_elim from diamonds as they don't > handle the form properly. > > Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu > and no issues. > > Ok for

[pushed] c++: generic lambda and function ptr conv [PR105221]

2023-03-30 Thread Jason Merrill via Gcc-patches
Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- We weren't properly considering the function pointer conversions in deduction between FUNCTION_TYPE; we just hardcoded the UNIFY_ALLOW_MORE_CV_QUAL semantics, which are backwards when deducing for a template conversion function like the one

[pushed] c++: anonymous union member reference [PR105452]

2023-03-30 Thread Jason Merrill via Gcc-patches
Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- While parsing the anonymous union, we don't yet know that it's an anonymous union, so we build the reference to 'v' in the static_assert relative to the union type. But at instantiation time we know it's an anonymous union, so we need to

Re: [PATCH] c++tools: Fix Makefile to properly clean and rebuild [PR101834]

2023-03-30 Thread Jason Merrill via Gcc-patches
On 3/30/23 08:15, Jonathan Wakely wrote: Tested with various combinations of 'make clean all' etc. OK for trunk? And backport to gcc-12 and gcc-11 after some soak time on trunk? OK. -- >8 -- The c++tools makefile doesn't remove progressively more files in each of mostlyclean, clean, and

Re: [PATCH 1/2] c++: improve "NTTP argument considered unused" fix [PR53164, PR105848]

2023-03-30 Thread Jason Merrill via Gcc-patches
On 3/30/23 14:53, Patrick Palka wrote: On Wed, 29 Mar 2023, Jason Merrill wrote: On 3/27/23 09:30, Patrick Palka wrote: On Thu, 23 Mar 2023, Patrick Palka wrote: r13-995-g733a792a2b2e16 worked around the problem of FUNCTION_DECL template arguments not always getting marked as odr-used by

Re: [PATCH] c++: Fix up ICE in build_min_non_dep_op_overload [PR109319]

2023-03-30 Thread Jason Merrill via Gcc-patches
On 3/30/23 03:47, Jakub Jelinek wrote: Hi! The following testcase ICEs, because grok_array_decl during processing_template_decl handling of a non-dependent subscript emits a -Wcomma-subscript pedwarn, we decide to pass to the single index argument the index expressions as if it was wrapped with

Re: [PATCH] c++,coroutines: Stabilize names of promoted slot vars [PR101118].

2023-03-30 Thread Jason Merrill via Gcc-patches
On 3/30/23 03:53, Iain Sandoe wrote: Hi Jason, On 30 Mar 2023, at 00:53, Jason Merrill wrote: On 3/26/23 12:54, Iain Sandoe wrote: Tested on x86_64-darwin21, x86-64-linux-gnu +/* This is used to make a stable, but unique-per-function, sequence number for + each TARGET_EXPR slot

Re: recomputation and PR 109154

2023-03-30 Thread Andrew MacLeod via Gcc-patches
I committed it.   ran it again for fun.  sigh.  Looks like its also triggering another issue now in g++.dg/warn/Wstringop-overflow-4.C where its issuing: b.C: In function ‘void test_strcpy_new_int16_t(size_t, const size_t*)’: b.C:76:12: warning: ‘void* __builtin_memcpy(void*, const void*, long

Re: [PATCH v4] rs6000: Fix incorrect RTL for Power LE when removing the UNSPECS [PR106069]

2023-03-30 Thread Segher Boessenkool
Hi! On Fri, Feb 10, 2023 at 10:59:52AM +0800, Xionghu Luo via Gcc-patches wrote: > The native RTL expression for vec_mrghw should be same for BE and LE as > they are register and endian-independent. This isn't so obvious at all. All elements of these constructs are very much not

Re: [PATCH] Fix fc-prototypes usage with C_INT64_T and non LP64 Targets.

2023-03-30 Thread Steve Kargl via Gcc-patches
On Thu, Mar 30, 2023 at 07:39:55PM +0200, Thomas Koenig via Fortran wrote: > Hi Andrew, > > > "long long". This was just an oversight and a missing check. > > > > Committed as obvious after a bootstrap/test on x86_64-linux-gnu. > > Thanks! > > I think this one is obvious enough that it

Re: [PATCH 1/2] c++: improve "NTTP argument considered unused" fix [PR53164, PR105848]

2023-03-30 Thread Patrick Palka via Gcc-patches
On Wed, 29 Mar 2023, Jason Merrill wrote: > On 3/27/23 09:30, Patrick Palka wrote: > > On Thu, 23 Mar 2023, Patrick Palka wrote: > > > > > r13-995-g733a792a2b2e16 worked around the problem of FUNCTION_DECL > > > template arguments not always getting marked as odr-used by redundantly > > >

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

2023-03-30 Thread Ken Matsui via Gcc-patches
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 v2 5/7] c++, libstdc++: implement __is_void built-in trait

2023-03-30 Thread Ken Matsui via Gcc-patches
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 v2 6/7] libstdc++: use new built-in trait __is_void for std::is_void

2023-03-30 Thread Ken Matsui via Gcc-patches
This patch gets std::is_void to dispatch to new built-in trait __is_void. libstdc++-v3/ChangeLog: * include/std/type_traits (is_void): Use __is_void built-in trait. Signed-off-by: Ken Matsui --- libstdc++-v3/include/std/type_traits | 7 +++ 1 file changed, 7 insertions(+) diff

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

2023-03-30 Thread Ken Matsui via Gcc-patches
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. Signed-off-by: Ken Matsui --- libstdc++-v3/include/std/type_traits | 7 +++ 1 file changed,

[PATCH v2 1/7] c++: implement __is_reference built-in trait

2023-03-30 Thread Ken Matsui via Gcc-patches
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 v2 3/7] c++: implement __is_function built-in trait

2023-03-30 Thread Ken Matsui via Gcc-patches
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 v2 0/7] c++, libstdc++: get std::is_object to dispatch to new built-in traits

2023-03-30 Thread Ken Matsui via Gcc-patches
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.

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

2023-03-30 Thread Ken Matsui via Gcc-patches
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. Signed-off-by: Ken Matsui --- libstdc++-v3/include/std/type_traits | 7 +++ 1 file

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

2023-03-30 Thread Ken Matsui via Gcc-patches
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] Fix fc-prototypes usage with C_INT64_T and non LP64 Targets.

2023-03-30 Thread Thomas Koenig via Gcc-patches
Hi Andrew, "long long". This was just an oversight and a missing check. Committed as obvious after a bootstrap/test on x86_64-linux-gnu. Thanks! I think this one is obvious enough that it deserves a backport. I've cherry-picked this for gcc12, will do gcc11 tomorrow. Best regards

Re: [PATCH] c++tools: Fix Makefile to properly clean and rebuild [PR101834]

2023-03-30 Thread Segher Boessenkool
On Thu, Mar 30, 2023 at 01:15:46PM +0100, Jonathan Wakely wrote: > The c++tools makefile doesn't remove progressively more files in each of > mostlyclean, clean, and distclean. Instead, each removes a different set > of files (and some files are not removed by any target). Use > prerequisites so

Re: recomputation and PR 109154

2023-03-30 Thread Jakub Jelinek via Gcc-patches
On Thu, Mar 30, 2023 at 11:58:19AM -0400, Andrew MacLeod wrote: > > On 3/30/23 09:41, Jakub Jelinek wrote: > > On Wed, Mar 29, 2023 at 01:22:27PM -0400, Andrew MacLeod wrote: > > > however, as seems to be the case often, better ranges result in, I now > > > get: > > > > > > FAIL:

Re: [committed] libstdc++: Fix constexpr functions in

2023-03-30 Thread Daniel Krügler via Gcc-patches
Am Do., 30. März 2023 um 18:00 Uhr schrieb Jonathan Wakely via Libstdc++ : > [..] > > In fact, thinking about P2641 some more, I might revert this change. > Instead of adding an extra bool member to support constexpr, I think > I'll just remove the 'constexpr' keywords from basic_endpoint for now,

Re: [committed] libstdc++: Fix constexpr functions in

2023-03-30 Thread Jonathan Wakely via Gcc-patches
On Thu, 30 Mar 2023 at 15:44, Jonathan Wakely wrote: > > On Thu, 30 Mar 2023 at 00:40, Jonathan Wakely via Libstdc++ > wrote: > > > > Tested powerpc64le-linux. Pushed to trunk. > > > > -- >8 -- > > > > Change ip::basic_endpoint to work in constant expressions, but only for > > C++20 and later

Re: recomputation and PR 109154

2023-03-30 Thread Andrew MacLeod via Gcc-patches
On 3/30/23 09:41, Jakub Jelinek wrote: On Wed, Mar 29, 2023 at 01:22:27PM -0400, Andrew MacLeod wrote: however, as seems to be the case often, better ranges result in, I now get: FAIL: 23_containers/vector/bool/allocator/copy.cc (test for excess errors) Our middle-end warnings are just badly

Re: [PATCH v2] rtl-optimization: ppc backend generates unnecessary extension.

2023-03-30 Thread Segher Boessenkool
Hi! On Thu, Mar 30, 2023 at 04:28:51PM +0200, Bernhard Reutner-Fischer wrote: > On Thu, 30 Mar 2023 17:30:43 +0530 > Ajit Agarwal via Gcc-patches wrote: > > * ree.cc(is_feasible_elim_across_basic_blocks): > > We often use the lispy _p suffix for predicates. > Maybe eliminate_across_bbs_p

Re: [committed] libstdc++: Fix constexpr functions in

2023-03-30 Thread Jonathan Wakely via Gcc-patches
On Thu, 30 Mar 2023 at 00:40, Jonathan Wakely via Libstdc++ wrote: > > Tested powerpc64le-linux. Pushed to trunk. > > -- >8 -- > > Change ip::basic_endpoint to work in constant expressions, but only for > C++20 and later (due to the use of a union, which cannot change active > member in constexpr

Re: [PATCH v2] rtl-optimization: ppc backend generates unnecessary extension.

2023-03-30 Thread Bernhard Reutner-Fischer via Gcc-patches
On Thu, 30 Mar 2023 17:30:43 +0530 Ajit Agarwal via Gcc-patches wrote: > Hello All: Just some nits. And this seems to be an incremental diff ontop of your v2. You might want check for coding-style errors by running: contrib/check_GNU_style.py /tmp/ree-v2bis.patch > > This patch added

Re: 'g++.dg/modules/modules.exp': don't leak local 'unsupported' proc [PR108899]

2023-03-30 Thread Alexandre Oliva via Gcc-patches
On Mar 30, 2023, Alexandre Oliva wrote: > If we're dropping the renaming, I suppose we could also revert Jakub's > change. I suppose this patch will take care of it, pending testing... Regstrapped on x86_64-linux-gnu and also tested on arm-vx7r2 (with gcc-12), where I used to get fails after

Re: [PATCH] Introduce -nolibstdc++ option

2023-03-30 Thread Arsen Arsenović via Gcc-patches
Hi Alexandre, Alexandre Oliva via Gcc-patches writes: > Hello, Gerald, > > On Feb 11, 2023, Gerald Pfeifer wrote: > >> On Thu, 23 Jun 2022, Alexandre Oliva via Gcc-patches wrote: >>> Introduce -nostdlib++ option >>> >>> Using g++ to link without libstdc++, as in g++.dg/abi/pure-virtual1.C,

Re: [PATCH v2] rtl-optimization: ppc backend generates unnecessary extension.

2023-03-30 Thread Segher Boessenkool
Hi! On Tue, Mar 28, 2023 at 10:19:27PM +0530, Ajit Agarwal wrote: > This patch makes REE pass as a default pass in rs6000 target. And > add necessary subroutines to eliminate extensions across basic blocks. Please wait with this until stage 1? Some comments: > rtl-optimization: ppc

Re: recomputation and PR 109154

2023-03-30 Thread Jakub Jelinek via Gcc-patches
On Wed, Mar 29, 2023 at 01:22:27PM -0400, Andrew MacLeod wrote: > however, as seems to be the case often, better ranges result in, I now get: > > FAIL: 23_containers/vector/bool/allocator/copy.cc (test for excess errors) Our middle-end warnings are just badly designed :(, the better value ranges

[PATCH] c++tools: Fix Makefile to properly clean and rebuild [PR101834]

2023-03-30 Thread Jonathan Wakely via Gcc-patches
Tested with various combinations of 'make clean all' etc. OK for trunk? And backport to gcc-12 and gcc-11 after some soak time on trunk? -- >8 -- The c++tools makefile doesn't remove progressively more files in each of mostlyclean, clean, and distclean. Instead, each removes a different set of

Re: [PATCH V2] Rename ufix_trunc/ufloat* patterns to fixuns_trunc/floatuns* to align with standard pattern name.

2023-03-30 Thread Uros Bizjak via Gcc-patches
On Thu, Mar 30, 2023 at 1:43 PM liuhongt wrote: > > > > Just rename the instruction and fix all its call sites. The name of > > > the insn pattern is internal to the compiler and can be renamed at > > > will. > > > > Ideally, we should standardize all the names to a standard name, so > > e.g.

Re: [PATCH v2] rtl-optimization: ppc backend generates unnecessary extension.

2023-03-30 Thread Ajit Agarwal via Gcc-patches
Hello All: This patch added enhancement to extimination elimination for rs6000 target. Bootstrapped and regtested on powerpc64-linux-gnu. Thanks & Regards Ajit rtl-optimization: ppc backend generates unnecessary extension. Eliminate unnecessary redundant zero extension within

Re: [PATCH RFC] c++: lambda mangling alias issues [PR107897]

2023-03-30 Thread Jan Hubicka via Gcc-patches
> > How about moving it to symtab_node and using dyn_cast for the cgraph bits, > like this: > From 1d869ceb04573727e59be6518903133c8654069a Mon Sep 17 00:00:00 2001 > From: Jason Merrill > Date: Mon, 6 Mar 2023 15:33:45 -0500 > Subject: [PATCH] c++: lambda mangling alias issues [PR107897] > To:

[PATCH V2] Rename ufix_trunc/ufloat* patterns to fixuns_trunc/floatuns* to align with standard pattern name.

2023-03-30 Thread liuhongt via Gcc-patches
> > Just rename the instruction and fix all its call sites. The name of > > the insn pattern is internal to the compiler and can be renamed at > > will. > > Ideally, we should standardize all the names to a standard name, so > e.g. ufix_ -> fixuns_ and ufloat -> floatuns. Updated. There's some

Re: [PATCH] Introduce -nolibstdc++ option

2023-03-30 Thread Alexandre Oliva via Gcc-patches
Hello, Gerald, On Feb 11, 2023, Gerald Pfeifer wrote: > On Thu, 23 Jun 2022, Alexandre Oliva via Gcc-patches wrote: >> Introduce -nostdlib++ option >> >> Using g++ to link without libstdc++, as in g++.dg/abi/pure-virtual1.C, >> is error prone, because there's no way to tell g++ to drop

Re: [PATCH] tree-optimization/107561 - reduce -Wstringop-overflow false positives

2023-03-30 Thread Richard Biener via Gcc-patches
On Wed, 29 Mar 2023, Richard Biener wrote: > The following tells pointer-query to prefer a zero size when we > are querying for the size range for a write into an object we've > determined is of zero size. That avoids diagnostics about really > varying size arguments that just get a meaningful

[PATCH] tree-optimization/109342 - wrong code with edge equivalences in VN

2023-03-30 Thread Richard Biener via Gcc-patches
The following testcase shows a problem in how we query valitity for equivalences on edges when the edge is a backedge and thus refering to a block thats later in the iteration order we use for VN. That causes the dominated_by_p_w_unex helper to look at edge executable state that's not yet

Re: [pushed] wwwdocs: gcc-4.7: Adjust dwarfstd.org links

2023-03-30 Thread Mark Wielaard
On Wed, 2023-03-29 at 15:40 -0700, Andrew Pinski wrote: > On Wed, Mar 29, 2023 at 3:08 PM Gerald Pfeifer wrote: > > > > Business as usual - 301 Moved Permanently. > > Just FYI, dwarfstd is now hosted by sourceware too. So I doubt these > URLs will change after this. Indeed, see

Re: 'g++.dg/modules/modules.exp': don't leak local 'unsupported' proc [PR108899]

2023-03-30 Thread Thomas Schwinge
Hi! On 2023-03-30T04:00:03-0300, Alexandre Oliva wrote: > On Mar 29, 2023, Thomas Schwinge wrote: >> But surely the curly braces in: > >> -UNSUPPORTED: g++.dg/modules/explicit-bool-1_a.H -std=c++17 > >> +UNSUPPORTED: {g++.dg/modules/explicit-bool-1_a.H -std=c++17} > >> ... are not

[PATCH] testsuite, analyzer: Fix up pipe-glibc.c testcase [PR107396]

2023-03-30 Thread Jakub Jelinek via Gcc-patches
Hi! The gcc.dg/analyzer/pipe-glibc.c test FAILs when using recent glibc headers and succeeds with older headers. The important change is that https://sourceware.org/git/?p=glibc.git;a=commit;h=c1760eaf3b575ad174fd88b252fd16bd525fa818 in 2021 added __attribute__ ((__malloc__ (fclose, 1)))

Re: [PATCH] c++,coroutines: Stabilize names of promoted slot vars [PR101118].

2023-03-30 Thread Iain Sandoe
Hi Jason, > On 30 Mar 2023, at 00:53, Jason Merrill wrote: > > On 3/26/23 12:54, Iain Sandoe wrote: >> Tested on x86_64-darwin21, x86-64-linux-gnu >> +/* This is used to make a stable, but unique-per-function, sequence number >> for >> + each TARGET_EXPR slot variable that we 'promote' to

[PATCH] c++: Fix up ICE in build_min_non_dep_op_overload [PR109319]

2023-03-30 Thread Jakub Jelinek via Gcc-patches
Hi! The following testcase ICEs, because grok_array_decl during processing_template_decl handling of a non-dependent subscript emits a -Wcomma-subscript pedwarn, we decide to pass to the single index argument the index expressions as if it was wrapped with () around it, but then when preparing it

Re: 'g++.dg/modules/modules.exp': don't leak local 'unsupported' proc [PR108899]

2023-03-30 Thread Alexandre Oliva via Gcc-patches
On Mar 29, 2023, Thomas Schwinge wrote: > I assume that the second UNSUPPORTED: > -UNSUPPORTED: g++.dg/modules/explicit-bool-1_b.C -std=c++17 > ... disappears is the intention of this patch? Yup > But surely the curly braces in: > -UNSUPPORTED: g++.dg/modules/explicit-bool-1_a.H

Re: recomputation and PR 109154

2023-03-30 Thread Richard Biener via Gcc-patches
On Wed, Mar 29, 2023 at 7:22 PM Andrew MacLeod wrote: > > The patch, or a slight variation (attached), in the PR allows us to > generate better ranges be recomputing longer instruction sequences on > outgoing edges. > > This in fact also fixes > XPASS: gcc.dg/Walloca-13.c (test for bogus

Re: [PATCH] Support vector conversion for AVX512 vcvtudq2pd/vcvttps2udq/vcvttpd2udq.

2023-03-30 Thread Uros Bizjak via Gcc-patches
On Thu, Mar 30, 2023 at 8:17 AM Uros Bizjak wrote: > > On Thu, Mar 30, 2023 at 3:47 AM liuhongt wrote: > > > > There's some typo for the standard pattern name for unsigned_{float,fix}, > > it should be floatunsmn2/fixuns_truncmn2, not ufloatmn2/ufix_truncmn2 > > in current trunk, the patch fix

Re: [PATCH] Support vector conversion for AVX512 vcvtudq2pd/vcvttps2udq/vcvttpd2udq.

2023-03-30 Thread Uros Bizjak via Gcc-patches
On Thu, Mar 30, 2023 at 3:47 AM liuhongt wrote: > > There's some typo for the standard pattern name for unsigned_{float,fix}, > it should be floatunsmn2/fixuns_truncmn2, not ufloatmn2/ufix_truncmn2 > in current trunk, the patch fix the typo. > > Also vcvttps2udq is available under AVX512VL, so it

Re: [PATCH v3] RISC-V: Add Z*inx imcompatible check in gcc

2023-03-30 Thread Kito Cheng via Gcc-patches
Thanks Jiawei, committed to trunk! On Wed, Mar 29, 2023 at 12:55 AM Jiawei wrote: > > Z*inx is conflict with float extensions, add incompatible check when > z*inx and f extension both enabled. > > Since all float extension imply f extension and all z*inx extension > imply zfinx extension, so we