gcc/
* haifa-sched.c (rank_for_schedule): Add bypass_p
cost check in flag_sched_last_insn_heuristic.
---
gcc/haifa-sched.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/gcc/haifa-sched.c b/gcc/haifa-sched.c
index 62d1816a55d..7d826483f55 1
Hi Segher,
Thanks for the review!
>>> Why does this test has_arch_pwr9 instead of adding -mdejagnu-cpu=power9?
>>
>> I thought using -mdejagnu-cpu=power9 would force the case run with
>> power9 cpu all the time, while using has_arch_pwr9 seems to be more
>> flexible, it can be compiled with power
On Mon, 2 Nov 2020 at 23:01, Vladimir Makarov wrote:
>
>
> On 2020-11-02 4:30 p.m., Vladimir Makarov via Gcc-patches wrote:
> >
> > On 2020-11-02 3:12 p.m., Christophe Lyon wrote:
> >>
> >> Hi,
> >>
> >> This patch causes ICEs on arm (eg arm-none-linux-gnueabi)
> >> gcc.c-torture/compile/sync
The change to clear the external_die_map slot after creating
the concrete instance DIE broke abstract origin processing which
tried to make sure to have those point to the early abstract instance
and not the concrete instance. The following restores this by
eventually following the abstract origin
The following fixes SLP vectorization of stores that were
pattern recognized. Since in SLP vectorization pattern analysis
happens after dataref group analysis we have to adjust the groups
with the pattern stmts. This has some effects down the pipeline
and exposes cases where we looked at the wron
H, Christophe,
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 15 October 2020 18:23
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH] arm: Implement vceqq_p64, vceqz_p64 and vceqzq_p64
> intrinsics
>
> This patch adds implementations for vc
Hi All,
My previous patch accidentally enabled some tests on x86 because my target
selector foo was weak.. This now properly only runs them on AArch64.
Bootstrapped Regtested on aarch64-none-linux-gnu and x86_64-pc-linux-gnu
and no issues.
Committed under the obvious rule.
Thanks,
Tamar
gcc/t
On Wed, 4 Nov 2020, Tamar Christina wrote:
> Hi Richi,
>
> > -Original Message-
> > From: rguent...@c653.arch.suse.de On
> > Behalf Of Richard Biener
> > Sent: Wednesday, November 4, 2020 8:07 AM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; o...@ucw.cz
> > Subject: RE:
> -Original Message-
> From: rguent...@c653.arch.suse.de On
> Behalf Of Richard Biener
> Sent: Thursday, November 5, 2020 10:17 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; o...@ucw.cz
> Subject: RE: [PATCH] SLP: Move load/store-lanes check till late
>
> On Wed, 4 Nov 202
On 10/31/20 4:59 PM, H.J. Lu wrote:
On Tue, Oct 13, 2020 at 1:17 AM Jakub Jelinek via Gcc-patches
wrote:
On Tue, Oct 13, 2020 at 10:11:26AM +0200, Martin Liška wrote:
--- a/gcc/testsuite/g++.dg/asan/asan_test.C
+++ b/gcc/testsuite/g++.dg/asan/asan_test.C
@@ -9,6 +9,7 @@
// { dg-additional-o
On Wed, Nov 04, 2020 at 03:58:56PM -0800, H.J. Lu wrote:
> On Wed, Nov 4, 2020 at 3:00 PM Hans-Peter Nilsson wrote:
> >
> > On Wed, 4 Nov 2020, H.J. Lu wrote:
> > > On Wed, Nov 4, 2020 at 1:56 PM Hans-Peter Nilsson
> > > wrote:
> > > > On Wed, 4 Nov 2020, H.J. Lu wrote:
> > > >
> > > > > On Wed,
Christophe Lyon writes:
[...]
>> I think you need to add -mfloat-abi=hard to the dg-additional-options
>> otherwise vld1_lane_bf16_1.c
>> fails on targets with a soft float-abi default (eg arm-linux-gnueabi).
>>
>> See bf16_vldn_1.c.
>
> Actually that's not sufficient because in turn we get:
> /
On Wed, 4 Nov 2020, H.J. Lu wrote:
> .retain is ill-defined. For example,
>
> [hjl@gnu-cfl-2 gcc]$ cat /tmp/x.c
> static int xyzzy __attribute__((__used__));
> [hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S /tmp/x.c -fcommon
> [hjl@gnu-cfl-2 gcc]$ cat x.s
> .file "x.c"
> .text
> .retain xyzzy < Wha
On Thu, Nov 05, 2020 at 06:21:21AM -0500, Hans-Peter Nilsson wrote:
> On Wed, 4 Nov 2020, H.J. Lu wrote:
> > .retain is ill-defined. For example,
> >
> > [hjl@gnu-cfl-2 gcc]$ cat /tmp/x.c
> > static int xyzzy __attribute__((__used__));
> > [hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S /tmp/x.c -fcommon
> >
On Thu, 5 Nov 2020 at 10:36, Kyrylo Tkachov wrote:
>
> H, Christophe,
>
> > -Original Message-
> > From: Gcc-patches On Behalf Of
> > Christophe Lyon via Gcc-patches
> > Sent: 15 October 2020 18:23
> > To: gcc-patches@gcc.gnu.org
> > Subject: [PATCH] arm: Implement vceqq_p64, vceqz_p64 an
On Thu, 5 Nov 2020 at 12:11, Andrea Corallo wrote:
>
> Christophe Lyon writes:
>
> [...]
>
> >> I think you need to add -mfloat-abi=hard to the dg-additional-options
> >> otherwise vld1_lane_bf16_1.c
> >> fails on targets with a soft float-abi default (eg arm-linux-gnueabi).
> >>
> >> See bf16_vl
OpenACC piggybacks on OpenACC for the atomic parsing; however, there
are two issues:
* Newer OpenMP versions added additional clauses such as 'seq_cst',
which do not exist in OpenACC.
* OpenACC 2.6 added 'acc atomic update capture' (besides 'acc atomic capture',
which was not accepted.
Actual
On Thu, Nov 05, 2020 at 01:03:38PM +0100, Tobias Burnus wrote:
> OpenACC piggybacks on OpenACC for the atomic parsing; however, there
> are two issues:
> * Newer OpenMP versions added additional clauses such as 'seq_cst',
> which do not exist in OpenACC.
> * OpenACC 2.6 added 'acc atomic update c
In PR87473, there are discussions about loop-closed PHIs which
are generated for loop optimization passes. It would be helpful
to clean them up after loop optimization is done, then this may
simplify some jobs of following passes.
This patch introduces a cheaper way to propagate them out in
pass_t
On Tue, Nov 3, 2020 at 10:16 PM Nathan Sidwell wrote:
>
> These are changes to gcc/tree.h adding some raw accessors to nodes,
> which seemed preferable to direct field access. I also needed access to
> the integral constant cache
can you please document the adjusted interface to cache_integer_cs
On 04/11/20 23:41 +, Jonathan Wakely wrote:
On 04/11/20 21:45 +, Jonathan Wakely wrote:
On 04/11/20 12:43 -0800, Thomas Rodgers wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97719
On Nov 4, 2020, at 11:54 AM, Stephan Bergmann wrote:
On 07/10/2020 18:55, Thomas Rodgers wrote:
On Tue, Nov 3, 2020 at 10:12 PM Nathan Sidwell wrote:
>
> Here is the implementation of C++20 modules that I have been developing
> on the devel/c++-modules branch over the last few years.
>
> It is not a complete implementation. The major missing pieces are:
>
> 1) Private Module Fragment
>T
On Thu, Nov 5, 2020 at 2:19 PM guojiufu via Gcc-patches
wrote:
>
> In PR87473, there are discussions about loop-closed PHIs which
> are generated for loop optimization passes. It would be helpful
> to clean them up after loop optimization is done, then this may
> simplify some jobs of following p
I'm going to prevent from creation of double 'cherry picked from'
lines. There are quite some revision that violate that. I'm going
to install it tomorrow in order to make DATESTAMP succeed
the upcoming night.
Then we can update server hook.
Martin
contrib/ChangeLog:
* gcc-changelog/g
Hi,
this patch fixes two uninitialized memory uses in ipa-modref. First is
harmless because the values are never used, but they will make valgrind
unhapy.
Second is an actual bug: while breaking the patch in half I forgot to
initialize errno at stream in time.
Bootstrapped/regtested x86_64-linux,
On Tue, 2020-11-03 at 16:12 -0500, Nathan Sidwell wrote:
[...]
[CCing Joseph]
> I have bootstrapped and tested on:
> x86_64-linux
> aarch64-linux
> powerpc8le-linux
> powerpc8-aix
>
> Iain Sandoe has been regularly bootstrapping on x86_64-
> darwin. Joseph
> Myers graciously built for i686-mi
Christophe Lyon writes:
> On Thu, 5 Nov 2020 at 12:11, Andrea Corallo wrote:
>>
>> Christophe Lyon writes:
>>
>> [...]
>>
>> >> I think you need to add -mfloat-abi=hard to the dg-additional-options
>> >> otherwise vld1_lane_bf16_1.c
>> >> fails on targets with a soft float-abi default (eg arm-l
On Thu, Nov 5, 2020 at 3:37 AM Jozef Lawrynowicz
wrote:
>
> On Thu, Nov 05, 2020 at 06:21:21AM -0500, Hans-Peter Nilsson wrote:
> > On Wed, 4 Nov 2020, H.J. Lu wrote:
> > > .retain is ill-defined. For example,
> > >
> > > [hjl@gnu-cfl-2 gcc]$ cat /tmp/x.c
> > > static int xyzzy __attribute__((__
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r11-4740-g54cbdb528df16686290ad26e2130a1896915639d.
gcc/analyzer/ChangeLog:
PR analyzer/97668
* svalue.cc (cmp_cst): Handle COMPLEX_CST.
gcc/testsuite/ChangeLog:
PR analyzer/97668
*
Doing this makes followup work to add HTML path-printing cleaner.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as f8cc59ef4941c19d068b9dfe4e13753c9fd402c6.
gcc/ChangeLog:
* tree-diagnostic-path.cc (struct path_summary::event_range): Move
out of p
On 11/5/20 12:31 AM, Richard Biener wrote:
On Thu, Nov 5, 2020 at 1:59 AM Martin Sebor via Gcc-patches
wrote:
To determine the target of a pointer expression and the offset into
it, the increasingly widely used compute_objsize function traverses
the IL following the DEF statements of pointer v
On 11/5/20 8:33 AM, Richard Biener wrote:
Moving the module mapper to a more easily (build-)testable location
and to a place where host dependences can be more easily fixed
& customized than in a bootstrapped directory would be nice. Thus,
I think the module mapper should be in the toplevel som
On Thu, Nov 05, 2020 at 08:20:20AM -0700, Martin Sebor via Gcc-patches wrote:
> compute_objsize() and the objsz pass are completely independent.
> The pass is also quite limited in that it doesn't make use of
> ranges. That limitation was also the main reason for introducing
> the compute_objsize(
On Fri, Oct 30, 2020 at 04:33:48PM -0400, Jason Merrill wrote:
> On 10/29/20 11:00 PM, Marek Polacek wrote:
> > Gotcha. Now we do most of the work in warn_about_ambiguous_parse.
>
> Thanks, just a few tweaks left.
> > --- a/gcc/cp/decl.c
> > +++ b/gcc/cp/decl.c
> > @@ -4378,6 +4378,9 @@ cxx_init_
Improve the inline memcpy expansion. Use integer load/store for copies <= 24
bytes
instead of SIMD. Set the maximum copy to expand to 256 by default, except that
-Os or
no Neon expands up to 128 bytes. When using LDP/STP of Q-registers, also use
Q-register
accesses for the unaligned tail, sav
This PR asks that we add a warning option for an existing (very old)
warning, so that it can be disabled selectively. clang++ uses
-Wexceptions for this, so I added this new option rather than using
e.g. -Wnoexcept.
gcc/c-family/ChangeLog:
PR c++/97675
* c.opt (Wexceptions): New
Hi Richard,
Thanks for the feedback.
Richard Sandiford writes:
> > diff --git a/gcc/config/aarch64/aarch64-builtins.c
> > b/gcc/config/aarch64/aarch64-builtins.c
> > index 4f33dd936c7..f93f4e29c89 100644
> > --- a/gcc/config/aarch64/aarch64-builtins.c
> > +++ b/gcc/config/aarch64/aarch64-builti
[ This patch depends on
c++: Use two levels of caching in satisfy_atom
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558096.html ]
A large source of cache misses in satisfy_atom is caused by the identity
of an (atom,args) pair within the satisfaction cache being determined by
the
Sometimes the overflow flag will leak into the IL. Drop it while
creating ranges.
There are various places we could plug this. This patch just plugs things
at get_tree_range which is the entry point for ranges from tree expressions.
It fixes the PR, and probably fixes the ranger entirely, but we
On 11/5/20 8:29 AM, Jakub Jelinek wrote:
On Thu, Nov 05, 2020 at 08:20:20AM -0700, Martin Sebor via Gcc-patches wrote:
compute_objsize() and the objsz pass are completely independent.
The pass is also quite limited in that it doesn't make use of
ranges. That limitation was also the main reason
On 11/5/20 3:27 PM, Jan Hubicka wrote:
poly_int64 offset;
struct modref_parm_map parm_map;
+ parm_map.parm_offset_known = false;
+ parm_map.parm_offset = 0;
+
I'm curious, can't we use a proper C++ class construction.
The IPA pass is new and so we can make it more C++-ish? Similar
Hi All,
They say third time is the charm.. It looks like the testcase
disables the cost model and so AArch64 we end up being able to
do the permute but on x86 we can't. However when analyzing the
testcase I didn't disable the cost model hence the difference.
So I now guard the testcase on vect_l
On 11/5/20 2:08 AM, Boris Kolpackov wrote:
To give an example of such a likely change, currently the mapper
has a notion of the central module repository directory that is
used to resolve all the relative CMI (compiled module interface[1])
paths (even paths like ./foo.gcm). However, this model
> On 11/5/20 3:27 PM, Jan Hubicka wrote:
> > poly_int64 offset;
> > struct modref_parm_map parm_map;
> > + parm_map.parm_offset_known = false;
> > + parm_map.parm_offset = 0;
> > +
>
> I'm curious, can't we use a proper C++ class construction.
> The IPA pass is new and so we can make it
Hi Richard,
> On 4 Nov 2020, at 20:04, Richard Sandiford wrote:
>
> It's a bit concerning that the second register now overlaps
> STACK_CLASH_SVE_CFA_REGNUM, but I agree that isn't a problem
> in practice, since the two uses are currently mutually-exclusive.
> I think it might be worth having a
> > On 11/5/20 3:27 PM, Jan Hubicka wrote:
> > > poly_int64 offset;
> > > struct modref_parm_map parm_map;
> > > + parm_map.parm_offset_known = false;
> > > + parm_map.parm_offset = 0;
> > > +
> >
> > I'm curious, can't we use a proper C++ class construction.
> > The IPA pass is new and
libstdc++-v3/ChangeLog:
PR libstdc++/97729
* config/abi/pre/gnu.ver (GLIBCXX_3.4.29): Add exports.
* src/c++20/sstream-inst.cc (basic_stringbuf): Instantiate
private constructor taking __xfer_bufptrs.
Tested powerpc64le-linux. Committed to trunk.
commit 50b840ac5e
As described in the PR, the recursive_directory_iterator constructor
calls advance(ec), but ec is a pointer so it calls _Dir::advance(bool).
The intention was to either call advance() or advance(*ec) depending
whether the pointer is null or not.
This fixes the bug and renames the parameter to ecpt
This fixes some multiple definition errors caused by the changes for
PR libstdc++/90295. The previous solution for inlining the members of
std::exception_ptr but still exporting them from the library was to
suppress the 'inline' keyword on those functions when compiling
libsupc++/eh_ptr.cc, so the
On 04/11/2020 2:33 pm, Jakub Jelinek wrote:
LGTM, except:
+ omp_lock_hint_contended __GOMP_DEPRECATED_5_0 = omp_sync_hint_contended,
omp_sync_hint_nonspeculative = 4,
- omp_lock_hint_nonspeculative = omp_sync_hint_nonspeculative,
+ omp_lock_hint_nonspeculative __GOMP_DEPRECATED_5_0 =
om
On Thu, Nov 05, 2020 at 06:18:11PM +, Kwok Cheung Yeung wrote:
> I have run the tests (with _OPENMP >= 201511) and added
> -Wno-deprecated-declarations option to the testcases that trigger the
> deprecation warning.
>
> I also found a bug in the previous version of the patch - C++ doesn't like
Instead of #define TARGET_OS_USES_R18 which is not
handled, pick R9 as an alternate static chain regnum
and document that the port needs to be configured to
issue -ffixed-r18 by default.
r9 is now available after the approval at
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558094.ht
On November 5, 2020 4:25:23 PM GMT+01:00, Nathan Sidwell wrote:
>On 11/5/20 8:33 AM, Richard Biener wrote:
>
>> Moving the module mapper to a more easily (build-)testable location
>> and to a place where host dependences can be more easily fixed
>> & customized than in a bootstrapped directory wou
The relational operators for std::optional were using the wrong types
in the declval expressions used to constrain them. Instead of using
const lvalues they were using non-const rvalues, which meant that a type
might satisfy the constraints but then give an error when the function
body was instanti
On Linux/x86_64,
1436ef2a57e79b6b8ce5b03e32a38dd64f46c97c is the first bad commit
commit 1436ef2a57e79b6b8ce5b03e32a38dd64f46c97c
Author: Richard Biener
Date: Thu Nov 5 09:27:28 2020 +0100
debug/97718 - fix abstract origin references after last change
caused
FAIL: gcc.dg/guality/pr54519-
On 10/1/20 11:25 AM, Martin Sebor wrote:
On 10/1/20 9:34 AM, Aldy Hernandez wrote:
On 10/1/20 3:22 PM, Andrew MacLeod wrote:
> On 10/1/20 5:05 AM, Aldy Hernandez via Gcc-patches wrote:
>>> Thanks for doing all this! There isn't anything I don't understand
>>> in the sprintf changes so no q
On 05/11/20 19:09 +, Jonathan Wakely wrote:
The relational operators for std::optional were using the wrong types
in the declval expressions used to constrain them. Instead of using
const lvalues they were using non-const rvalues, which meant that a type
might satisfy the constraints but then
On Tue, 3 Nov 2020 at 12:17, Dennis Zhang via Gcc-patches
wrote:
>
> Hi Richard,
>
> On 10/30/20 2:07 PM, Richard Sandiford wrote:
> > Dennis Zhang writes:
> >> diff --git a/gcc/config/aarch64/aarch64-simd-builtins.def
> >> b/gcc/config/aarch64/aarch64-simd-builtins.def
> >> index 332a0b6b1ea..3
On Thu, 5 Nov 2020 at 21:52, Jonathan Wakely via Libstdc++
wrote:
>
> On 05/11/20 19:09 +, Jonathan Wakely wrote:
> >The relational operators for std::optional were using the wrong types
> >in the declval expressions used to constrain them. Instead of using
> >const lvalues they were using non
On Thu, 5 Nov 2020 at 15:30, Andrea Corallo wrote:
>
> Christophe Lyon writes:
>
> > On Thu, 5 Nov 2020 at 12:11, Andrea Corallo wrote:
> >>
> >> Christophe Lyon writes:
> >>
> >> [...]
> >>
> >> >> I think you need to add -mfloat-abi=hard to the dg-additional-options
> >> >> otherwise vld1_lan
On 11/5/20 10:46 AM, Marek Polacek wrote:
On Fri, Oct 30, 2020 at 04:33:48PM -0400, Jason Merrill wrote:
On 10/29/20 11:00 PM, Marek Polacek wrote:
Gotcha. Now we do most of the work in warn_about_ambiguous_parse.
Thanks, just a few tweaks left.
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -4
As detailed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97725
This was a latent bug where we were passing a value_range into to
range_ops for aq calculation. This was being used by the
not_equal::fold() routine as an intermediary as one point, and it
couldnt represent the full range, and i
On 11/3/20 3:43 PM, Patrick Palka wrote:
Profiling revealed that sat_hasher::equal accounts for nearly 40% of
compile time in some cmcstl2 tests.
This patch eliminates this bottleneck by caching the ATOMIC_CONSTRs
returned by normalize_atom. This in turn allows us to replace the
expensive atomi
On 11/5/20 11:03 AM, Marek Polacek wrote:
This PR asks that we add a warning option for an existing (very old)
warning, so that it can be disabled selectively. clang++ uses
-Wexceptions for this, so I added this new option rather than using
e.g. -Wnoexcept.
OK.
gcc/c-family/ChangeLog:
On 10/27/20 3:01 AM, Richard Biener wrote:
> On Tue, 27 Oct 2020, Jan Hubicka wrote:
>
>>> On Mon, 26 Oct 2020, Jan Hubicka wrote:
>>>
Hi,
while looking for special cases of buitins I noticed that tree-ssa-ccp
can use EAF_RETURNS_ARG. I wonder if same should be done by value
Here's a small deficiency in decltype(auto). [dcl.type.auto.deduct]/5:
If the placeholder-type-specifier is of the form decltype(auto), [...]
the type deduced for T is determined [...] as though E had been the operand
of the decltype. So:
int &&i = 0;
decltype(auto) j = i; // should behave l
On 10/20/20 10:43 AM, Aldy Hernandez via Gcc-patches wrote:
> As promised.
>
> Now that we know the vr_values and ranger versions are in sync, it
> is safe to remove the vr_values version and just call the ranger one.
>
> I am holding off on pushing this for a week or two, or until Fedora gets
>
>
> On 10/27/20 3:01 AM, Richard Biener wrote:
> > On Tue, 27 Oct 2020, Jan Hubicka wrote:
> >
> >>> On Mon, 26 Oct 2020, Jan Hubicka wrote:
> >>>
> Hi,
> while looking for special cases of buitins I noticed that tree-ssa-ccp
> can use EAF_RETURNS_ARG. I wonder if same should be do
On 05/11/20 22:12 +0200, Ville Voutilainen via Libstdc++ wrote:
On Thu, 5 Nov 2020 at 21:52, Jonathan Wakely via Libstdc++
wrote:
On 05/11/20 19:09 +, Jonathan Wakely wrote:
>The relational operators for std::optional were using the wrong types
>in the declval expressions used to constrain
On 11/5/20 12:29 PM, Martin Sebor wrote:
On 10/1/20 11:25 AM, Martin Sebor wrote:
On 10/1/20 9:34 AM, Aldy Hernandez wrote:
On 10/1/20 3:22 PM, Andrew MacLeod wrote:
> On 10/1/20 5:05 AM, Aldy Hernandez via Gcc-patches wrote:
>>> Thanks for doing all this! There isn't anything I don't unde
On 11/5/20 3:52 PM, Marek Polacek wrote:
Here's a small deficiency in decltype(auto). [dcl.type.auto.deduct]/5:
If the placeholder-type-specifier is of the form decltype(auto), [...]
the type deduced for T is determined [...] as though E had been the operand
of the decltype. So:
int &&i = 0
I'll wait for the 11/01 snapshot to finish then.
Thanks.
Aldy
On Thu, Nov 5, 2020, 21:53 Jeff Law wrote:
>
> On 10/20/20 10:43 AM, Aldy Hernandez via Gcc-patches wrote:
> > As promised.
> >
> > Now that we know the vr_values and ranger versions are in sync, it
> > is safe to remove the vr_value
On 11/4/20 2:19 PM, Patrick Palka wrote:
[ This patch depends on
c++: Reuse identical ATOMIC_CONSTRs during normalization
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557929.html ]
This improves the effectiveness of caching in satisfy_atom by querying
the cache again after we
On 11/5/20 2:40 PM, Aldy Hernandez wrote:
> I'll wait for the 11/01 snapshot to finish then.
I'm worried that the 11/01 snapshot is going to generate so many
failures that it may not be useful. I'm not sure what's going on, but
I'm getting a ton of what appear to be codegen correctness issues.
On 11/5/20 11:18 AM, Patrick Palka wrote:
[ This patch depends on
c++: Use two levels of caching in satisfy_atom
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558096.html ]
A large source of cache misses in satisfy_atom is caused by the identity
of an (atom,args) pair within t
On Thu, 29 Oct 2020, hongtao Liu via Gcc-cvs-wwwdocs wrote:
> The branch, master has been updated
>via 88e29096c36837553fc841bd1fa5df6caa776b44 (commit)
> from 053c956f6e9c71efac5be01f8a8ba79f15d87f4b (commit)
>GCC now supports the Intel CPU named Alderlake through
> -marc
In gfc_get_symbol_decl, if an external procedure is invoked
and sym->backend_decl is NULL_TREE,
gfc_get_extern_function_decl
is called. This searches the translation unit (or gsym) to
find the declaration – and if found, it returns it.
Well, that worked and the module procedure's decl is return
On Wed, 2020-11-04 at 12:10 -0600, acsawdey--- via Gcc-patches wrote:
> From: Aaron Sawdey
>
> Ping, as it has been a while.
> This also includes a slight fix to make sure that all references can get
> optimized.
>
I've read over what I could. a few nits below, nothing significant
jumped out
On 10/14/20 11:55 AM, Jonathan Wakely via Gcc-patches wrote:
> On 14/10/20 17:29 +0100, Jonathan Wakely wrote:
>> The FIXME comment saying "Leave out until this is tested a bit more" is
>> from 1997. I think it's been sufficiently tested.
>>
>> ChangeLog:
>>
>> Â Â Â Â * config-ml.in (multi-do):
On 10/16/20 3:01 AM, Martin Liška wrote:
> On 10/16/20 9:41 AM, Kito Cheng wrote:
>> I think it is still useful for other targets which are not supporting
>> libsanitizer yet, so in this patch I also moved related testcases
>> from gcc.target to gcc.dg.
>
> All right, I can't approve the patch, b
Ug. Well, we need to wait for something later than the 25th's snapshot
since I committed the asset patch later.
Aldy
On Thu, Nov 5, 2020, 22:43 Jeff Law wrote:
>
> On 11/5/20 2:40 PM, Aldy Hernandez wrote:
> > I'll wait for the 11/01 snapshot to finish then.
>
> I'm worried that the 11/01 s
On Wed, 2020-11-04 at 14:42 -0600, Pat Haugen via Gcc-patches wrote:
> Update instruction attributes for Power10.
>
>
> This patch updates the type/prefixed/dot/size attributes for various new
> instructions (and a couple existing that were incorrect) in preparation for
> the Power10 scheduling
On Thu, 5 Nov 2020, Jason Merrill wrote:
> On 11/4/20 2:19 PM, Patrick Palka wrote:
> > [ This patch depends on
> >
> >c++: Reuse identical ATOMIC_CONSTRs during normalization
> >
> >https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557929.html ]
> >
> > This improves the effecti
On Wed, 2020-11-04 at 12:12 -0600, Aaron Sawdey via Gcc-patches wrote:
> Ping.
>
> Aaron Sawdey, Ph.D. saw...@linux.ibm.com
> IBM Linux on POWER Toolchain
>
>
> > On Oct 26, 2020, at 4:44 PM, acsaw...@linux.ibm.com wrote:
> >
> > From: Aaron Sawdey
> >
Hi,
> > This patch adds the first co
On Thu, 5 Nov 2020, Jason Merrill wrote:
> On 11/3/20 3:43 PM, Patrick Palka wrote:
> > Profiling revealed that sat_hasher::equal accounts for nearly 40% of
> > compile time in some cmcstl2 tests.
> >
> > This patch eliminates this bottleneck by caching the ATOMIC_CONSTRs
> > returned by normaliz
On Thu, 2020-11-05 at 11:03 -0500, Marek Polacek via Gcc-patches wrote:
> This PR asks that we add a warning option for an existing (very old)
> warning, so that it can be disabled selectively. clang++ uses
> -Wexceptions for this, so I added this new option rather than using
> e.g. -Wnoexcept.
>
C2x adds macros for decimal floating-point signaling NaNs to
. Add these macros to GCC's implementation.
Note that the current C2x draft has these under incorrect names
D32_SNAN, D64_SNAN, D128_SNAN. The intent was to change the naming
convention to be consistent with other macros when they we
Hi,
this patch moves size time tables out of ggc allocated memory. This makes
sources bit cleaner and saves about 60MB of GGC memory that turns to about 45MB
of heap memory for cc1plus LTO build.
Bootstrapped/regtested x86_64-linux, plan to commit it shortly.
Honza
2020-11-06 Jan Hubicka
On Thu, Nov 05, 2020 at 06:13:41PM -0500, David Malcolm via Gcc-patches wrote:
> On Thu, 2020-11-05 at 11:03 -0500, Marek Polacek via Gcc-patches wrote:
> > This PR asks that we add a warning option for an existing (very old)
> > warning, so that it can be disabled selectively. clang++ uses
> > -W
Hi,
this patch adds the IPA propagation support for fnspecs in ipa-modref.
Fnspec string are collected to a new edge summary (since they do depend
on the call statement and not only the called function) and stored to
summaries. Since ipa-modref is first pass that now cares about jump funitions
to
On 11/5/20 4:02 PM, Martin Sebor wrote:
On 11/5/20 12:29 PM, Martin Sebor wrote:
On 10/1/20 11:25 AM, Martin Sebor wrote:
On 10/1/20 9:34 AM, Aldy Hernandez wrote:
On 10/1/20 3:22 PM, Andrew MacLeod wrote:
> On 10/1/20 5:05 AM, Aldy Hernandez via Gcc-patches wrote:
>>> Thanks for doing all
On 11/5/20 2:29 PM, Martin Sebor wrote:
signed char g (signed char min, signed char max)
{
signed char i = x;
return i < min || max < i ? min : i;
}
void gg (void)
{
__builtin_sprintf (a, "%i", g (0, 9)); // bogus warning
}
Im looking at this. its actually completely different code tha
On 11/5/20 5:02 PM, Andrew MacLeod wrote:
On 11/5/20 4:02 PM, Martin Sebor wrote:
On 11/5/20 12:29 PM, Martin Sebor wrote:
On 10/1/20 11:25 AM, Martin Sebor wrote:
On 10/1/20 9:34 AM, Aldy Hernandez wrote:
On 10/1/20 3:22 PM, Andrew MacLeod wrote:
> On 10/1/20 5:05 AM, Aldy Hernandez via G
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556236.html
Thanks.
Gui Haochen
On 15/10/2020 下午 4:46, HAO CHEN GUI wrote:
Segher,
I re-wrote the patch based on parameterized name.
The attachments are the patch diff file and change log file.
Boots
Recent IPA work exposed this issue by causing wrong-code for
gfortran.dg/pdt_15.f03
with optimization turned on; this shows up rather prominently with an endless
loop,
until after 300s (per optimization level) the timeout kicks in.
OK? It probably should be backported to GCC 9 + 10, I think, ev
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556744.html
Thanks
Gui Haochen
On 22/10/2020 上午 10:53, HAO CHEN GUI wrote:
I had a wrong email setting and got your reply later. I modified the
patch according to your advice. Could you please review it again? Than
>-Original Message-
>From: Gerald Pfeifer
>Sent: Friday, November 6, 2020 5:57 AM
>To: Hongtao Liu ; hongtao Liu
>
>Cc: gcc-patches@gcc.gnu.org
>Subject: Re: gcc-wwwdocs branch master updated.
>88e29096c36837553fc841bd1fa5df6caa776b44
>
>On Thu, 29 Oct 2020, hongtao Liu via Gcc-cvs-wwwd
On Thu, 5 Nov 2020, Patrick Palka wrote:
> On Thu, 5 Nov 2020, Jason Merrill wrote:
>
> > On 11/3/20 3:43 PM, Patrick Palka wrote:
> > > Profiling revealed that sat_hasher::equal accounts for nearly 40% of
> > > compile time in some cmcstl2 tests.
> > >
> > > This patch eliminates this bottlenec
This patch (naively) extends the PR93907 fix to also apply to variadic
concepts invoked with a type argument pack. Without this, we ICE on
the below testcase (a variadic version of concepts-using2.C) in the same
manner as we used to on concepts-using2.C before r10-7133.
Patch series bootstrapped
Profiling revealed that sat_hasher::equal accounts for nearly 40% of
compile time in some cmcstl2 tests.
This patch eliminates this bottleneck by caching the ATOMIC_CONSTRs
returned by normalize_atom. This in turn allows us to replace the
expensive atomic_constraints_identical_p check in sat_hash
1 - 100 of 127 matches
Mail list logo
