Look through all backends which defined signbitm2.
1. When m is a scalar mode, the dest is SImode.
2. When m is a vector mode, the dest mode is the vector integer
mode has the same size and elements number as m.
Ok for trunk?
gcc/ChangeLog:
* doc/md.texi: Document signbitm2.
---
gcc/doc
On Fri, Mar 31, 2023 at 1:57 PM Uros Bizjak wrote:
>
> 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_R
On Thu, Mar 30, 2023 at 1:40 PM Andrew MacLeod via Gcc-patches
wrote:
>
> 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:
libstdc++v3's 23_containers/vector/bool/allocator/copy.cc fails m
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 wa
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: 23_containers/vector/bool/alloca
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 whi
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 t
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>
Than
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 elements
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>
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 thin
On Thu, 30 Mar 2023, Alexandre Oliva wrote:
> How about this, does this seem useful?
I like it - helpful and easy to understand. :-)
Gerald
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
> https://inbox.sourceware.org/overseers/20230327222524.ga20...@gnu
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?
> --- a/htd
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 master?
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
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 av
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 di
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 red
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
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 varia
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
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 endian-independe
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 deserves
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
> > > calling
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
---
li
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 fil
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 --g
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, 7
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.
gcc/te
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.
gcc/tests
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.
__not_<__
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 change
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.
__not_<__
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
T
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 th
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: 23_containers/v
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,
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 (due
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
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 wou
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
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 enhance
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 an
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,
>>>
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 backen
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
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
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. ufix
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 bas
>
> 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:
> > 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 t
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 libstdc+
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 ra
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 computed
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
https://inbox.so
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 intent
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))) attribute
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 a
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
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 -std
61 matches
Mail list logo
