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
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
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 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!
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
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
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, 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
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+
> > 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
>
> 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:
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
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
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 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
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
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,
>>>
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
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 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
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 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
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
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, 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
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
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
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_<__
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
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 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 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 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_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
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
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
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
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
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
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 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 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
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
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
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?
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 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 Thu, 30 Mar 2023, Alexandre Oliva wrote:
> How about this, does this seem useful?
I like it - helpful and easy to understand. :-)
Gerald
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 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>
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 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
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
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
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
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 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 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
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
61 matches
Mail list logo
