Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
Currently we incorrectly retain "in_unbraced_linkage_specification_p"
and "in_unbraced_export_declaration_p" when parsing a (braced)
declaration-seq. This patch ensures that we clear these flags before
parsing the
> -Original Message-
> From: Li, Pan2
> Sent: Thursday, May 2, 2024 4:11 AM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; richard.guent...@gmail.com;
> Liu, Hongtao
> Subject: RE: [PATCH v3] Internal-fn: Introduce new internal function
Thanks Tamar
> Could you also split off the vectorizer change from scalar recog one?
> Typically I would structure a change like this as:
> 1. create types/structures + scalar recogn
> 2. Vector recog code
> 3. Backend changes
Sure thing, will rearrange the patch like this.
> Is ECF_NOTHROW
On Wed, May 1, 2024 at 7:40 PM Ian Lance Taylor wrote:
>
> On Wed, May 1, 2024 at 12:43 AM Aldy Hernandez wrote:
> >
> > gcc/ChangeLog:
> >
> > * ipa-fnsummary.cc (evaluate_properties_for_edge): Initialize
> > Value_Range's.
> > * value-range.h (class Value_Range): Add a buffer
On 5/1/24 12:44 PM, Patrick O'Neill wrote:
It also introduced:
FAIL: gcc.target/riscv/rvv/autovec/unop/math-nearbyint-run-2.c execution
test
on rv32gcv newlib/linux.
I think I see what's going on here as well. Need to ponder this one a
bit longer, but I'm confident I'll be able to sort
On Wed, May 1, 2024 at 12:43 AM Aldy Hernandez wrote:
>
> gcc/ChangeLog:
>
> * ipa-fnsummary.cc (evaluate_properties_for_edge): Initialize
> Value_Range's.
> * value-range.h (class Value_Range): Add a buffer and remove
> m_irange and m_frange.
>
On Thu, May 02, 2024 at 12:15:44AM +1000, Nathaniel Shead wrote:
> On Wed, May 01, 2024 at 09:57:38AM -0400, Patrick Palka wrote:
> >
> > On Wed, 1 May 2024, Nathaniel Shead wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk (and
> > > later 14.2)? I don't think
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/14.2?
Another alternative would be to stream such !DECL_NAME temporaries with
a merge key of MK_unique rather than attempting to find the matching
(nonexistant) field of the class context.
-- >8 --
In r14-9266-g2823b4d96d9ec4 I
This should address the majority of issues left from Rainer's report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112959 . I pushed this
for now.
Rainer, thank you very much for your report and all the details. I am
sorry our documentation was not up-to-date.
It would be great could you have
When deducing auto for `adc_return_type`, `adc_variable_type`, and
`adc_decomp_type` contexts (at the usage time), we try to resolve the outermost
template arguments to be used for satisfaction. This is done by one of the
following, depending on the scope:
1. Checking the `DECL_TEMPLATE_INFO`
On Wed, 1 May 2024, Patrick Palka wrote:
> On Wed, 1 May 2024, Jason Merrill wrote:
>
> > On 4/12/24 13:22, Patrick Palka wrote:
> > > On Fri, 12 Apr 2024, Jason Merrill wrote:
> > >
> > > > On 3/26/24 09:44, Patrick Palka wrote:
> > > > > On Thu, 7 Mar 2024, Jason Merrill wrote:
> > > > >
> >
On 5/1/24 12:44 PM, Patrick O'Neill wrote:
Hi Jeff,
It looks like this patch's gcc.target/riscv/round_64.c testcase doesn't
pass when run with newlib.
So I expected this would ultimately end up being a case where certain
builtins aren't enabled when we're using a newlib based C library
On 5/1/24 13:40, Patrick Palka wrote:
On Wed, 1 May 2024, Jason Merrill wrote:
On 5/1/24 12:41, Patrick Palka wrote:
On Fri, 2 Feb 2024, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux, does this look like
an improvement? This is not a bugfix and barely related to the
On Wed, 1 May 2024, Jason Merrill wrote:
> On 4/12/24 13:22, Patrick Palka wrote:
> > On Fri, 12 Apr 2024, Jason Merrill wrote:
> >
> > > On 3/26/24 09:44, Patrick Palka wrote:
> > > > On Thu, 7 Mar 2024, Jason Merrill wrote:
> > > >
> > > > > On 1/29/24 17:42, Patrick Palka wrote:
> > > > > >
On Wed, 1 May 2024, Jason Merrill wrote:
> On 5/1/24 12:41, Patrick Palka wrote:
> > On Fri, 2 Feb 2024, Patrick Palka wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux, does this look like
> > > an improvement? This is not a bugfix and barely related to the previous
> > > patch,
On 4/12/24 13:22, Patrick Palka wrote:
On Fri, 12 Apr 2024, Jason Merrill wrote:
On 3/26/24 09:44, Patrick Palka wrote:
On Thu, 7 Mar 2024, Jason Merrill wrote:
On 1/29/24 17:42, Patrick Palka wrote:
On Mon, 29 Jan 2024, Patrick Palka wrote:
On Fri, 26 Jan 2024, Jason Merrill wrote:
On
On 5/1/24 12:11, Patrick Palka wrote:
On Wed, 1 May 2024, Jason Merrill wrote:
On 5/1/24 08:54, Patrick Palka wrote:
On Thu, 2 May 2024, Nathaniel Shead wrote:
On Wed, May 01, 2024 at 10:11:20AM -0400, Patrick Palka wrote:
On Wed, 1 May 2024, Nathaniel Shead wrote:
Bootstrapped and
On 5/1/24 12:41, Patrick Palka wrote:
On Fri, 2 Feb 2024, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux, does this look like
an improvement? This is not a bugfix and barely related to the previous
patch, but the previous patch's new use of entering_scope=true motivated
me
On Wed, May 01, 2024 at 12:55:25PM -0700, H.J. Lu wrote:
> Since bfloat16 has the same range as float32, _Float16 to bfloat16
> conversion is an extension, not a truncation. Rename trunchfbf2.c
> to extendhfbf2.c to provide __extendhfbf2, instead of __trunchfbf2.
>
> Since _Float16 to bfloat16
On 5/1/24 12:44 PM, Patrick O'Neill wrote:
Hi Jeff,
It looks like this patch's gcc.target/riscv/round_64.c testcase doesn't
pass when run with newlib.
Looks like a testsuite error as much as anything. The test relies on
the gimple optimizers to propagate the input paramters to their use
Since bfloat16 has the same range as float32, _Float16 to bfloat16
conversion is an extension, not a truncation. Rename trunchfbf2.c
to extendhfbf2.c to provide __extendhfbf2, instead of __trunchfbf2.
Since _Float16 to bfloat16 conversion never worked from the day one,
the same libgcc version of
Tested x86_64-linux.
I'm considering making the increment of __to_incr conditional:
if constexpr (!random_access_iterator<_Iter>)
++__to_incr;
and then when we call _M_update using _M_curr() - __g._M_orig for the
number of characters consumed. I should benchmark that to see if it
On Fri, 2 Feb 2024, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux, does this look like
> an improvement? This is not a bugfix and barely related to the previous
> patch, but the previous patch's new use of entering_scope=true motivated
> me to submit this patch since it
This patch heavily refactors btfout.cc to take advantage of the
structural changes in the prior commits.
Now that inter-type references are internally stored as simply pointers,
all the painful, brittle, confusing infrastructure that was used in the
process of converting CTF type IDs to BTF type
This patch replaces all inter-type references in the ctfc internal data
structures with pointers, rather than the references-by-ID which were
used previously.
A couple of small updates in the BPF backend are included to make it
compatible with the change.
This change is only to the in-memory
This patch adds a new option, -fprune-btf, to control BTF debug info
generation.
As the name implies, this option enables a kind of "pruning" of the BTF
information before it is emitted. When enabled, rather than emitting
all type information translated from DWARF, only information for types
This patch enables -fprune-btf by default in the BPF backend when
generating BTF information, and fixes BPF CO-RE generation when using
-fprune-btf.
When generating BPF CO-RE information, we must ensure that types used
in CO-RE relocations always have sufficient BTF information emited so
that the
This commit makes some structural changes to the CTF/BTF debug info
emission. In particular:
a) CTF is new always fully generated and emitted before any
BTF-related procedures are run. This means that BTF-related
functions can change, even irreversibly, the shared in-memory
This patch series signficantly refactors the BTF generation in gcc,
making it simpler and easier to understand, extend and maintain.
It also introduces an optional algorithm to "prune" BTF information
before emission. This pruning is meant to be used for BPF programs,
to alleviate the massive
Previously it was not supported to generate both CTF and BTF debug info
in the same compiler run, as both formats made incompatible changes to
the same internal data structures.
With the structural change in the prior patch, in particular the
guarantee that CTF will always be fully emitted before
On Wed, 1 May 2024, Jason Merrill wrote:
> On 5/1/24 08:54, Patrick Palka wrote:
> > On Thu, 2 May 2024, Nathaniel Shead wrote:
> >
> > > On Wed, May 01, 2024 at 10:11:20AM -0400, Patrick Palka wrote:
> > > > On Wed, 1 May 2024, Nathaniel Shead wrote:
> > > >
> > > > > Bootstrapped and
On 5/1/24 12:44 PM, Patrick O'Neill wrote:
Hi Jeff,
It looks like this patch's gcc.target/riscv/round_64.c testcase doesn't
pass when run with newlib.
It also introduced:
FAIL: gcc.target/riscv/rvv/autovec/unop/math-nearbyint-run-2.c execution
test
on rv32gcv newlib/linux.
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Constructors and destructors use the in-charge parameter to decide whether
they're responsible for recursing into virtual bases. Historically all
destructors had this parameter in order to also distinguish the deleting
destructor. But
On 5/1/24 23:33, Jakub Jelinek wrote:
The following patch implements the C++26 P2573R2
= delete("should have a reason"); paper.
I've tried to avoid increasing compile time memory for it when it isn't
used (e.g. by adding a new lang_decl tree member), so the reason is
represented as STRING_CST
As I was reviewing and cleaning up some internal work, I noticed a
particular idiom being used elsewhere in the RISC-V backend.
Specifically the use of explicit subregs when an adjustment to the
match_operand would be sufficient.
Let's take this example from the and-not splitter:
On 5/1/24 08:54, Patrick Palka wrote:
On Thu, 2 May 2024, Nathaniel Shead wrote:
On Wed, May 01, 2024 at 10:11:20AM -0400, Patrick Palka wrote:
On Wed, 1 May 2024, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
When calling
Hi Jeff,
It looks like this patch's gcc.target/riscv/round_64.c testcase doesn't
pass when run with newlib.
It also introduced:
FAIL: gcc.target/riscv/rvv/autovec/unop/math-nearbyint-run-2.c execution
test
on rv32gcv newlib/linux.
Precommit with a few targets:
We've got the ability to count the number of store pair fusions
happening in the front-end of the pipeline. When comparing some code
from last year vs the current trunk we saw a fairly dramatic drop.
The problem is the store pair fusion detection code was actively harmful
due to a minor
Hi,
> From: Pan Li
>
> Update in v3:
> * Rebase upstream for conflict.
>
> Update in v2:
> * Fix one failure for x86 bootstrap.
>
> Original log:
>
> This patch would like to add the middle-end presentation for the
> saturation add. Aka set the result of add to the max when overflow.
> It
"add_flexible_array_elts_to_size" C++ FE routine "layout_var_decl" to handle
the cases when the DECL is union.
Add testing cases to test the _bos for flexible array members in unions
or alone in structures.
gcc/c/ChangeLog:
* c-decl.cc (add_flexible_array_elts_to_size): Handle the
gcc/testsuite/ChangeLog:
* c-c++-common/fam-in-union-alone-in-struct-1.c: New testcase.
* c-c++-common/fam-in-union-alone-in-struct-2.c: New testcase.
* c-c++-common/fam-in-union-alone-in-struct-3.c: New testcase.
---
.../fam-in-union-alone-in-struct-1.c | 52
to support flexible array members
in unions and alone in structures. Adjust testcases for flexible array member
in union and alone in structure extension.
gcc/c/ChangeLog:
* c-decl.cc (finish_struct): Change errors to pedwarns for the cases
flexible array members in union or
The request for GCC to accept that the C99 flexible array member can be
in a union or alone in a structure has been made a long time ago around 2012
for supporting several practical cases including glibc.
A GCC PR has been opened for such request at that time:
Hi,
This is the 5th version for
Allow flexible array members in unions and alone in structures [PR53548]
(for your reference, the 1st version is at:
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649737.html
The 2nd version is at:
Tested x86_64-linux. Pushed to trunk.
I'll backport this to gcc-14 as well, but it can wait until after the
14.1 release.
-- >8 --
This type trait isn't supported by Clang 18. It's only used in static
assertions, so they can just be omitted if the trait isn't available.
libstdc++-v3/ChangeLog:
On 2/3/24 05:50, Lehua Ding wrote:
This patch apply the DF_LIVE_SUBREG to LRA pass. More changes were made
to the LRA than the IRA since the LRA will modify the DF data directly.
The main big changes are centered on the lra-lives.cc file.
gcc/ChangeLog:
* lra-coalesce.cc
On 2/3/24 05:50, Lehua Ding wrote:
This patch simple replace df_get_live_in to df_get_subreg_live_in
and replace df_get_live_out to df_get_subreg_live_out.
gcc/ChangeLog:
* ira-build.cc (create_bb_allocnos): Switch to DF_LIVE_SUBREG df data.
(create_loop_allocnos): Ditto.
On May 1, 2024, at 09:35, Jason Merrill wrote:
On 5/1/24 08:19, Qing Zhao wrote:
"add_flexible_array_elts_to_size" and "layout_var_decl" to handle
the cases when the DECL is union.
Add testing cases to test the _bos for flexible array members in unions
or alone in structures.
On Thu, 2 May 2024, Nathaniel Shead wrote:
> On Wed, May 01, 2024 at 10:11:20AM -0400, Patrick Palka wrote:
> > On Wed, 1 May 2024, Nathaniel Shead wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> > >
> > > -- >8 --
> > >
> > > When calling
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The C++ standard specifies that the functions have const and
non-const overloads, unlike C's single function with const argument and
non-const return. Many systems don't actually implement this, but only add
an overload with non-const
On 5/1/24 08:19, Qing Zhao wrote:
"add_flexible_array_elts_to_size" and "layout_var_decl" to handle
the cases when the DECL is union.
Add testing cases to test the _bos for flexible array members in unions
or alone in structures.
gcc/c/ChangeLog:
* c-decl.cc
On 5/1/24 03:01, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
Another thought would be to replace xtreme-header.h with so
that we don't need to keep it up-to-date in the future. But this patch just
does the obviously correct thing.
-- >8 --
On 5/1/24 02:59, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
The change in r14-8408 to also emit partial specializations in the
global module fragment caused the regression in the linked PR; this
patch fixes this by restricting
On 5/1/24 07:11, Patrick Palka wrote:
On Wed, 1 May 2024, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
When calling instantiate_pending_templates at end of parsing, any new
functions that are instantiated from this point have their module
to support flexible array members
in unions and alone in structures. Adjust testcases for flexible array member
in union and alone in structure extension.
gcc/c/ChangeLog:
* c-decl.cc (finish_struct): Change errors to pedwarns for the cases
flexible array members in union or
"add_flexible_array_elts_to_size" and "layout_var_decl" to handle
the cases when the DECL is union.
Add testing cases to test the _bos for flexible array members in unions
or alone in structures.
gcc/c/ChangeLog:
* c-decl.cc (add_flexible_array_elts_to_size): Handle the cases
gcc/testsuite/ChangeLog:
* c-c++-common/fam-in-union-alone-in-struct-1.c: New testcase.
* c-c++-common/fam-in-union-alone-in-struct-2.c: New testcase.
* c-c++-common/fam-in-union-alone-in-struct-3.c: New testcase.
---
.../fam-in-union-alone-in-struct-1.c | 52
The request for GCC to accept that the C99 flexible array member can be
in a union or alone in a structure has been made a long time ago around 2012
for supporting several practical cases including glibc.
A GCC PR has been opened for such request at that time:
Hi,
This is the 4th version for
Allow flexible array members in unions and alone in structures [PR53548]
(for your reference, the 1st version is at:
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649737.html
The 2nd version is at:
On 5/1/24 04:37, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This patch implements the changes described in
https://github.com/itanium-cxx-abi/cxx-abi/pull/171.
One restriction that is lifted in the ABI that hasn't been updated here
is that
The recent thread on building on FreeBSD made me release there's quite
some cruft to remove (and a note to add) regarding that.
Pushed (and more to come).
Gerald
gcc:
PR target/69374
PR target/112959
* doc/install.texi (Specific) <*-*-freebsd*>: No longer refer
On Wed, May 01, 2024 at 10:11:20AM -0400, Patrick Palka wrote:
> On Wed, 1 May 2024, Nathaniel Shead wrote:
>
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> >
> > -- >8 --
> >
> > When calling instantiate_pending_templates at end of parsing, any new
> > functions that
On Wed, May 01, 2024 at 09:57:38AM -0400, Patrick Palka wrote:
>
> On Wed, 1 May 2024, Nathaniel Shead wrote:
>
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk (and
> > later 14.2)? I don't think making it a GTY root is necessary but I felt
> > perhaps better to be safe than
On Wed, 1 May 2024, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
LGTM
>
> -- >8 --
>
> Similarly to in the previous commit, templated virtual functions are
> sometimes not instantiated until after parsing has completed. This
> means that any new
On Wed, 1 May 2024, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> -- >8 --
>
> When calling instantiate_pending_templates at end of parsing, any new
> functions that are instantiated from this point have their module
> purview set based on the
On Tue, 30 Apr 2024, Martin Jambor wrote:
> +Pragma GCC Target now affects preprocessor
> symbols
Note the id: should be "gcc-target-pragma", though I even suggest to
simplify and say "target-pragma".
> +The behavior of pragma GCC Target and specifically how it affects ISA
Seconding Jakub's
On Apr 30, 2024, at 17:55, Kees Cook wrote:
On Tue, Apr 30, 2024 at 05:51:20PM -0400, Jason Merrill wrote:
On 4/30/24 14:45, Qing Zhao wrote:
On Apr 30, 2024, at 15:27, Jason Merrill wrote:
On 4/30/24 07:58, Qing Zhao wrote:
The request for GCC to accept that the C99 flexible array member
On Wed, 1 May 2024, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk (and
> later 14.2)? I don't think making it a GTY root is necessary but I felt
> perhaps better to be safe than sorry.
>
> Potentially another approach would be to use DECL_UID instead
On Mon, 22 Apr 2024 at 12:35, Georg-Johann Lay wrote:
>
> Am 22.04.24 um 12:04 schrieb Jonathan Wakely:
> > OK for wwwdocs?
>
> For me it's ok (I am not a native speaker though,
> which is the reason the typos are there to begin with).
I've pushed this now.
>
> Johann
>
> >
I am resending this message as the previous one had one wrong response
email address "gcc-pat...@gcc.gnu.org"
Forwarded Message
Subject: Re: [PATCH V2 0/4] Add DF_LIVE_SUBREG data and apply to IRA
and LRA
Date: Wed, 1 May 2024 08:35:27 -0400
From: Vladimir Makarov
On 4/25/24 14:32, Richard Biener wrote:
>
>
>> Am 25.04.2024 um 17:44 schrieb Carlos O'Donell :
>>
>> Discussion is here:
>> https://inbox.sourceware.org/gcc/CAPS5khZeWkAD=v8ka9g5eecdnk3bdhfnzjumpvc+hedmkvj...@mail.gmail.com/
>>
>> Rough consensus from Jakub Jelinek, Richard Biener and others
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This patch implements the changes described in
https://github.com/itanium-cxx-abi/cxx-abi/pull/171.
One restriction that is lifted in the ABI that hasn't been updated here
is that the ABI no longer requires unique vtables
On Fri, 26 Apr 2024, Marek Polacek wrote:
> Thanks, I think you can go ahead with this.
Agreed, thanks.
Alex, if you agree, how about simplifying
+This is primarily intended to aid the portability of code written
+against Clang.
to
+This is aids the portability of code
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Another thought would be to replace xtreme-header.h with so
that we don't need to keep it up-to-date in the future. But this patch just
does the obviously correct thing.
-- >8 --
This new testcase helps verify that the issues
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
Similarly to in the previous commit, templated virtual functions are
sometimes not instantiated until after parsing has completed. This
means that any new declarations they instantiate are incorrectly marked
as being in
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
When calling instantiate_pending_templates at end of parsing, any new
functions that are instantiated from this point have their module
purview set based on the current value of module_kind.
This is unideal, however, as
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
The change in r14-8408 to also emit partial specializations in the
global module fragment caused the regression in the linked PR; this
patch fixes this by restricting emitted GM partial specializations to
those that are
This patch series fixes a number of issues with declarations in the GMF not
correctly getting discarded, and ending up in the module CMI. The most
noticeable outcome of this is users running very quickly into issues with
including a header after those names have already been provided by an
Pushed.
Gerald
gcc:
PR target/69374
* doc/install.texi (Specific) : Remove details
on libunwind for GCC 3.4 and earlier.
---
gcc/doc/install.texi | 6 --
1 file changed, 6 deletions(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index
Value_Range is our polymorphic temporary that can hold any range. It
is used for type agnostic code where it isn't known ahead of time,
what the type of the range will be (irange, france, etc). Currently,
there is a temporary of each type in the object, which means we need
to construct each
Here are some cleanups to unsupported_range so the assignment operator
takes an unsupported_range and behaves like the other ranges. This
makes subsequent cleanups easier.
gcc/ChangeLog:
* value-range.cc (unsupported_range::union_): Cast vrange to
unsupported_range.
Hi!
The following patch implements the C++26 P2573R2
= delete("should have a reason"); paper.
I've tried to avoid increasing compile time memory for it when it isn't
used (e.g. by adding a new lang_decl tree member), so the reason is
represented as STRING_CST in DECL_INITIAL (which normally is
82 matches
Mail list logo
