On Thu, Sep 22, 2022 at 11:04 PM Jakub Jelinek wrote:
>
> On Thu, Sep 22, 2022 at 06:49:10PM +0200, Aldy Hernandez wrote:
> > It has been suggested that if we start bumping numbers by an ULP when
> > calculating open ranges (for example the numbers less than 3.0) that
> > dumping these will become
On Thu, Sep 22, 2022 at 6:48 PM Aldy Hernandez via Gcc-patches
wrote:
>
> We currently have no way of dumping REAL_VALUE_TYPEs when debugging.
>
> Tested on a gdb session examining the real value 10.0:
>
> (gdb) p min
> $9 = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0, uexp = 4,
On Fri, Sep 23, 2022 at 02:42:54PM +0800, liuhongt via Gcc-patches wrote:
> 2022-09-23 Hongtao Liu
> Liwei Xu
>
> gcc/ChangeLog:
>
> PR target/53346
> * config/i386/i386-expand.cc (expand_vec_perm_shufps_shufps):
> New function.
> (ix86_expand_vec_perm_const
On Thu, Sep 22, 2022 at 3:59 PM Martin Liška wrote:
>
> Fixes -flto-compression option:
>
> - -flto-compression-level= Use z Use zlib/zstd compression level
> for IL.
> + -flto-compression-level=<0,19> Use zlib/zstd compression level
> for IL.
>
> Ready for master?
OK
> Thanks,
> Marti
On Fri, 23 Sep 2022, Jakub Jelinek wrote:
> Hi!
>
> When looking at the attribs code, I've noticed weird diagnostics
> like
> int a __attribute__((section ("foo", "bar")));
> a.c:1:1: error: wrong number of arguments specified for ?section? attribute
> 1 | int a __attribute__((section ("foo",
x86 have shufps which shuffles the first operand to the lower 64-bit,
and the second operand to the upper 64-bit. For
__builtin_shufflevector (op0, op1, 1, 4, 3, 6), it will be veclowered since
can_vec_perm_const_p return false for sse2 target.
This patch add a new function to support 2-operand v4s
Hi!
When looking at the attribs code, I've noticed weird diagnostics
like
int a __attribute__((section ("foo", "bar")));
a.c:1:1: error: wrong number of arguments specified for ‘section’ attribute
1 | int a __attribute__((section ("foo", "bar")));
| ^~~
a.c:1:1: note: expected between 1
On Fri, Sep 23, 2022 at 11:07 AM Hu, Lin1 wrote:
>
> Hi, Hongtao
>
> I have modefied this patch and regtested on x86_64-pc-linux-gnu.
>
Ok.
> BRs.
> Lin
>
> -Original Message-
> From: Hongtao Liu
> Sent: Friday, September 23, 2022 9:48 AM
> To: Hu, Lin1
> Cc: gcc-patches@gcc.gnu.org; Liu
Hi, Hongtao
I have modefied this patch and regtested on x86_64-pc-linux-gnu.
BRs.
Lin
-Original Message-
From: Hongtao Liu
Sent: Friday, September 23, 2022 9:48 AM
To: Hu, Lin1
Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao
Subject: Re: [PATCH] i386: Optimize code generation of
__mm256_z
Hi,
Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601190.html
BR,
Jeff (Jiufu)
Jiufu Guo writes:
> Hi,
>
> As the issue in PR106460, a rtx 'high:DI (symbol_ref:DI ("var_48")' is tried
> to store into constant pool and ICE occur. But actually, this rtx represents
> part
On Thu, Sep 22, 2022 at 3:20 PM Hu, Lin1 via Gcc-patches
wrote:
>
> Hi all,
>
> This patch aims to optimize code generation of
> __mm256_zextsi128_si256(__mm_set1_epi8(-1)). Reduce the number of
> instructions required to achieve the final result.
>
> Regtested on x86_64-pc-linux-gnu. Ok for tru
On Thu, Sep 22, 2022 at 11:56 PM Jakub Jelinek wrote:
>
> On Tue, Sep 20, 2022 at 10:51:18AM +0200, Jakub Jelinek via Gcc-patches wrote:
> > On Tue, Sep 20, 2022 at 11:35:07AM +0800, Hongtao Liu wrote:
> > > > The question is (mainly for aarch64, arm and x86 backend maintainers)
> > > > if we
> >
On Thu, 22 Sept 2022 at 15:26, Jonathan Wakely via Libstdc++
wrote:
>
> Tested x86_64-linux. Pushed to trunk.
>
> -- >8 --
>
> Also add _GLIBCXX_HOSTED checks to simplify making
> freestanding in the near future.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/bitset (bitset): Add constexpr
On Thu, 22 Sep 2022, Torbjörn SVENSSON via Gcc-patches wrote:
> This patch stops reporting fails for Arm targets with single
> precision floating point unit for types wider than 32 bits (the width
> of float on arm-none-eabi).
>
> As reported in PR102017, fenv is reported as supported in recent
>
On 9/19/22 12:20, Thomas Neumann wrote:
In some scenarios (e.g., when mixing gcc and clang code), it can
happen that frames are deregistered after the lookup structure
has already been destroyed. That in itself would be fine, but
it triggers an assert in __deregister_frame_info_bases that
expects
On 9/20/22 17:05, Marek Polacek wrote:
We ICE in the code added in r12-7117: type_build_dtor_call gets
the error_mark_node because the type of 'prev' wasn't declared.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
PR c++/106983
gcc/cp/ChangeLog:
* typeck2.
On 9/22/22 09:39, Marek Polacek wrote:
To improve compile times, the C++ library could use compiler built-ins
rather than implementing std::is_convertible (and _nothrow) as class
templates. This patch adds the built-ins. We already have
__is_constructible and __is_assignable, and the nothrow fo
Hi!
On Thu, Sep 22, 2022 at 09:41:42AM +0800, Kewen.Lin wrote:
> * config/rs6000/rs6000-logue.cc (rs6000_emit_epilogue): Update the
> condition for adding REG_CFA_DEF_CFA reg note with
> frame_pointer_needed_indeed.
> --- a/gcc/config/rs6000/rs6000-logue.cc
> +++ b/gcc/config/rs
Hi!
Heh, I first thought I had mistyped thgew PR #, but it is this one after
all :-)
On Thu, Sep 22, 2022 at 09:41:34AM +0800, Kewen.Lin wrote:
> PR100645 exposes one latent bug in define_expand vec_shr_
> that the current condition TARGET_ALTIVEC is too loose. The
> mode iterator VEC_L contains
On Fri, 16 Sept 2022 at 19:49, Sergei Trofimovich wrote:
>
> From: Sergei Trofimovich
>
> i386-builtin-types.inc is included indirectly via i386-builtins.h
> into 4 files: i386.cc i386-builtins.cc i386-expand.cc i386-features.cc
>
> Only i386.cc dependency was present in gcc/config/t-i386 makefil
On Thu, Sep 22, 2022 at 06:49:10PM +0200, Aldy Hernandez wrote:
> It has been suggested that if we start bumping numbers by an ULP when
> calculating open ranges (for example the numbers less than 3.0) that
> dumping these will become increasingly harder to read, and instead we
> should opt for the
On 9/22/22 10:49, Aldy Hernandez via Gcc-patches wrote:
It has been suggested that if we start bumping numbers by an ULP when
calculating open ranges (for example the numbers less than 3.0) that
dumping these will become increasingly harder to read, and instead we
should opt for the hex represe
If it's not too cumbersome, I suggest dumping both.
In my neck-of-the-woods (meteorology) I have seen this done just to
ensure that algorithms that are supposed to be bit-reproducable actually
are - and that it can be checked visually.
Kind regards,
Toon.
On 9/22/22 18:49, Aldy Hernandez via
On 9/22/22 14:25, Patrick Palka wrote:
index 80467c19254..722b64793ed 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -18235,9 +18235,11 @@ maybe_register_incomplete_var (tree var)
{
/* When the outermost open class is complete we can resolve any
pointers-to-me
Also, as the last builtin remaining, also remove the builtin
infrastructure routines from fold_using_range.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 5608e410914ebb7c8cc9fa50afc8ada3b22cbf2c Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
AndrewFrom e7f035f66aa25e0537a0e3a76d43c71fe9531724 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 19:19:30 -0400
Subject: [PATCH 16/17] Convert CFN_BUILT_IN_GOACC_DIM_* to range-ops.
* gimple-range-fold.cc
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From c750e675cb77f283ff991682db7740bc5f6d4cf4 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 19:05:03 -0400
Subject: [PATCH 15/17] Convert CFN_BUILT_IN_STRLEN to range-ops.
* gimple-range-fold.cc (ra
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
AndrewFrom f7e62b09300b6935bceaffb4c42f6edab80f52dc Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 18:21:04 -0400
Subject: [PATCH 13/17] Convert CFN_BUILT_IN_CLRSB to range-ops.
* gimple-range-fold.cc (ran
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From b6f670ff706e35dc51a62db4206cb241dcac4963 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 18:48:05 -0400
Subject: [PATCH 14/17] Convert CFN_BUILT_IN_UBSAN_CHECK_* to range-ops.
* gimple-range-fol
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 55738d8d96bb4f39a72cf5e3739d35b39fc2146a Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 18:19:30 -0400
Subject: [PATCH 12/17] Convert CFN_CTZ builtins to range-ops.
* gimple-range-fold.cc (range
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From ae1669a98656cca594fcd2fef6bd2cd7308a361f Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 18:12:25 -0400
Subject: [PATCH 11/17] Convert CFN_CLZ builtins to range-ops.
* gimple-range-fold.cc (rang
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
AndrewFrom 5f730c650184d4c8bfad513a9e0e593f87a5bf0c Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 18:07:14 -0400
Subject: [PATCH 10/17] Convert CFN_BUILT_FFS and CFN_POPCOUNT to range-ops.
* gimple-range-
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 2f5da730f159de238500c82b0c6ef6c9ab91b1c2 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 17:14:30 -0400
Subject: [PATCH 09/17] Convert CFN_BUILT_IN_TOUPPER and TOLOWER to range-ops.
* gimple-rang
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From eb82b9f68eb8d0cc65a1a022154c8e729860ea59 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Wed, 21 Sep 2022 09:29:40 -0400
Subject: [PATCH 08/17] Convert CFN_BUILT_IN_SIGNBIT to range-ops.
* gimple-range-fold.cc
Check for builtins that can be a range-op entry and Convert
CFN_BUILT_IN_CONSTANT_P as first POC.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From b40b3035879cf695b72010858b9705a344292bdb Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 16:53:3
The fold_range routine in range-ops returns FALSE if the operation
fails. There are a few places which assume the operation was
successful. Fix those.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 2f92f685da2ef9e82ee6262519919180df8f2dd9 Mon Sep 17 00:00:00
Unary operations require op2 to be the range of the type of the LHS.
This is so the type for the LHS can be properly set. There are is a
missing prototype for this combination.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From be2a25adbdc76a770f7470cc9f47892f7a413
Unary operations pass the type of operand 1 into op1_range. If that
range is undefined, the routine blindly picks the type of operand
2,which in the case of a unary op, does not exist and traps.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
AndrewFrom a7a6649f4e7c459a95dee
Range-ops is meant to be IL independent. Some gimple processing has
be placed in range-ops, and some is located in gori. Split it all into
a file and isolate it in a new class gimple_range_op_handler.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 51ce06385bf2
Range_op_handler currently stores a tree code and a type. It defers
checking to see if there is a valid handler until asked.
This change checks at constructor time and store a pointer to the
handler if there is one.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
Fr
When the original patch was applied, I missed a spot which could
also be rewritten to use gimple_range_ssa_names.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 3cba5cd6e019182dbff756f621af048d55cdda98 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Wed, 31 Au
Builtin functions have been handled until now as special cases in
gimple-range-fold.cc. This set of patches makes the changes required to
create a range_operator for those functions. This allows them to behave
like a normal unary/binary operation through out the ranger ecosystem.
In particula
When streaming in the artificial VAR_DECL synthesized for a class NTTP
argument, we end up crashing from complete_vars because the call to
maybe_register_incomplete_var from add_module_namespace_decl for this
VAR_DECL pushes an unexpected NULL_TREE type onto the incomplete_vars
vector.
This patch
Hi
This patch fix failures when _GLIBCXX_INLINE_VERSION mode and running:
make check-debug RUNTESTFLAGS=prettyprinters.exp
libstdc++: [_GLIBCXX_INLINE_VERSION] Add gdb pretty print for
_GLIBCXX_DEBUG
In _GLIBCXX_DEBUG mode containers are in std::__debug namespace but
not templat
On Mon, Sep 5, 2022, 23:51 Charles-Francois Natali
wrote:
> `basic_filebuf::xsputn` would bypass the buffer when passed a chunk of
> size 1024 and above, seemingly as an optimisation.
>
> This can have a significant performance impact if the overhead of a
> `write` syscall is non-negligible, e.g.
It has been suggested that if we start bumping numbers by an ULP when
calculating open ranges (for example the numbers less than 3.0) that
dumping these will become increasingly harder to read, and instead we
should opt for the hex representation. I still find the floating
point representation eas
Similarly to how we drop NANs to UNDEFINED when -ffinite-math-only, I
think we can drop the numbers outside of the min/max representable
numbers to the representable number.
This means the endpoings to VR_VARYING for -ffinite-math-only can now
be the min/max representable, instead of -INF and +INF
We currently have no way of dumping REAL_VALUE_TYPEs when debugging.
Tested on a gdb session examining the real value 10.0:
(gdb) p min
$9 = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0, uexp = 4,
sig = {0, 0, 11529215046068469760}}
(gdb) p debug (min)
0x0.ap+4
OK for trunk?
g
This patch stops reporting fails for Arm targets with single
precision floating point unit for types wider than 32 bits (the width
of float on arm-none-eabi).
As reported in PR102017, fenv is reported as supported in recent
versions of newlib. At the same time, for some Arm targets, the
implementa
On Tue, Sep 20, 2022 at 10:51:18AM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Sep 20, 2022 at 11:35:07AM +0800, Hongtao Liu wrote:
> > > The question is (mainly for aarch64, arm and x86 backend maintainers) if
> > > we
> > > shouldn't support it, in the PR there is a partial patch to do
On Thu, Sep 22, 2022 at 5:22 PM Jakub Jelinek wrote:
>
> On Thu, Sep 22, 2022 at 05:02:19PM +0200, Aldy Hernandez wrote:
> > It has always irritated me that we don't have TYPE_MIN_VALUE and
> > TYPE_MAX_VALUE for floats (and for pointers for that matter). This
> > means, we have to recalculate it
I've merged trunk revision f35be1268c996d993ab0b4ff329734d467474445 to
the gccgo branch.
Ian
On 2022-09-22 09:02, Jakub Jelinek wrote:
On Mon, Aug 15, 2022 at 03:23:11PM -0400, Siddhesh Poyarekar wrote:
--- a/gcc/tree-object-size.cc
+++ b/gcc/tree-object-size.cc
@@ -495,6 +495,18 @@ decl_init_size (tree decl, bool min)
return size;
}
+/* Get the outermost object that PTR may po
On Thu, Sep 22, 2022 at 05:02:19PM +0200, Aldy Hernandez wrote:
> It has always irritated me that we don't have TYPE_MIN_VALUE and
> TYPE_MAX_VALUE for floats (and for pointers for that matter). This
> means, we have to recalculate it ad-nauseum in vrp_val_min and
> vrp_val_max.
>
> I know we hav
It has always irritated me that we don't have TYPE_MIN_VALUE and
TYPE_MAX_VALUE for floats (and for pointers for that matter). This
means, we have to recalculate it ad-nauseum in vrp_val_min and
vrp_val_max.
I know we have dconstinf and dconstninf for floats, which we can just
wrap around a TREE_
Approved by Richi on IRC. Pushed to trunk.
-- >8 --
We want bugs reported to Bugzilla, not emailed to gcc-bugs.
libiberty/ChangeLog:
* README: Replace gcc-bugs email address with Bugzilla URL.
---
libiberty/README | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libi
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Also add _GLIBCXX_HOSTED checks to simplify making
freestanding in the near future.
libstdc++-v3/ChangeLog:
* include/std/bitset (bitset): Add constexpr for C++23. Guard
members using std::string with _GLIBCXX_HOSTED.
* inc
Tested x86_64-linux. Pushed to trunk.
-- >8 --
In C++03 std::bitset was in the Container clause, but since C++11 it has
been in the Utilties clause. This moves the tests to the 20_util
directory, where most people probably expect to find them.
Also create 'access', 'observers', and 'io' subdirec
Hi!
On Thu, Sep 22, 2022 at 10:28:23AM +0800, Kewen.Lin wrote:
> on 2022/9/22 05:56, Segher Boessenkool wrote:
> > On Fri, Jun 24, 2022 at 10:02:19AM +0800, HAO CHEN GUI wrote:
> > In the other direction I am worried that the unspecs will degrade
> > performance (relative to smin/smax) when -ffast
Fixes -flto-compression option:
- -flto-compression-level= Use z Use zlib/zstd compression level
for IL.
+ -flto-compression-level=<0,19> Use zlib/zstd compression level for
IL.
Ready for master?
Thanks,
Martin
---
gcc/common.opt | 2 +-
gcc/opts.cc| 2 +-
2 files changed, 2 inse
Hi!
On Thu, Sep 22, 2022 at 05:59:07PM +0800, HAO CHEN GUI wrote:
> >> I still think we should get RTL codes for this, to have access to proper
> >> floating point min/max semantics always and everywhere. "fmin" and
> >> "fmax" seem to be good names :-)
> >
> > It would be good, especially if we
To improve compile times, the C++ library could use compiler built-ins
rather than implementing std::is_convertible (and _nothrow) as class
templates. This patch adds the built-ins. We already have
__is_constructible and __is_assignable, and the nothrow forms of those.
Microsoft (and clang, for
This libgo patch changes the cgo command to use runtime/cgo.Incomplete
instead of //go:notinheap, and to define the new type in the
runtime/cgo package. This ports https://go.dev/cl/421879 to libgo.
This is a quick port to update libgo to work with the version of cgo
in gc mainline. A more comple
On Mon, Sep 19, 2022 at 08:40:34PM +0100, Julian Brown wrote:
> On Wed, 14 Sep 2022 15:24:12 +0200
> Jakub Jelinek wrote:
>
> > On Tue, Sep 13, 2022 at 02:03:18PM -0700, Julian Brown wrote:
> > > This patch is an extension and rewrite/rethink of the following two
> > > patches:
> > >
> > > "Op
The following testcase is fixed in GCC 12+
Tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/102801
gcc/testsuite/
* g++.dg/warn/Wuninitialized-33.C: New testcase.
---
gcc/testsuite/g++.dg/warn/Wuninitialized-33.C | 55 +++
1 file changed, 55 insert
On Sun, Sep 18, 2022 at 08:19:29PM +0100, Julian Brown wrote:
> @@ -2609,6 +2672,9 @@ gfc_trans_omp_clauses (stmtblock_t *block,
> gfc_omp_clauses *clauses,
>if (clauses == NULL)
> return NULL_TREE;
>
> + hash_map sym_rooted_nl;
Isn't hash_map ctor pretty costly (allocates memory etc.
---
htdocs/gcc-13/changes.html | 4
1 file changed, 4 insertions(+)
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index a7d88038..0e895110 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -35,6 +35,10 @@ a work-in-progress.
-gstabs and
On Mon, Aug 15, 2022 at 03:23:11PM -0400, Siddhesh Poyarekar wrote:
> --- a/gcc/tree-object-size.cc
> +++ b/gcc/tree-object-size.cc
> @@ -495,6 +495,18 @@ decl_init_size (tree decl, bool min)
>return size;
> }
>
> +/* Get the outermost object that PTR may point into. */
> +
> +static tree
>
Hi.
Tested with Fangrui's patch set sent to binutils ML and mold linker.
$ gcc -g -gz=zstd a.c --save-temps --verbose 2>&1 | grep debug-sections
/home/marxin/Programming/binutils/objdir/gas/as-new -v --gdwarf-5
--compress-debug-sections=zstd --64 -o a.o a.s
/home/marxin/bin/gcc/libexec/gcc/x86
On Thu, Sep 22, 2022 at 2:34 PM Richard Biener
wrote:
>
> On Wed, Sep 7, 2022 at 9:30 AM Di Zhao OS
> wrote:
> >
> > Gentle ping again.
>
> So I got the chance to review the change again on the travel to GNU
> Cauldron 2022.
>
> There's quite some factoring / moving of stuff in the patch. I've
On Thu, Sep 22, 2022 at 2:26 PM Martin Liška wrote:
>
> Hi.
>
> I have a better version of the patch where section compression detection is
> based
> on ld --help, rather than a particular binutils version.
> That's much easier and all ld, ld.bfd and mold use the very same option.
>
> Ready to be
On Wed, Sep 7, 2022 at 9:30 AM Di Zhao OS wrote:
>
> Gentle ping again.
So I got the chance to review the change again on the travel to GNU
Cauldron 2022.
There's quite some factoring / moving of stuff in the patch. I've
already pushed to trunk
a change that factores out can_track_predicate_on_
Hi.
I have a better version of the patch where section compression detection is
based
on ld --help, rather than a particular binutils version.
That's much easier and all ld, ld.bfd and mold use the very same option.
Ready to be installed?
Thanks,
MartinFrom d2314c942c5c19a5fd5d6b2d45750d86363687
On Tue, Jun 21, 2022 at 11:12:15AM -0700, Noah Goldstein wrote:
> This patch allows for strchr(x, c) to the replace with memchr(x, c,
> strlen(x) + 1) if strlen(x) has already been computed earlier in the
> tree.
>
> Handles PR95821: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95821
>
> Since me
On 9/21/22 12:16, Patrick Palka wrote:
With partial variable template specializations, it looks like we
stream the VAR_DECL (i.e. the DECL_TEMPLATE_RESULT of the corresponding
TEMPLATE_DECL) since process_partial_specialization adds it to the
specializations table, but end up never streaming the
On Tue, Sep 06, 2022 at 09:20:47PM -0400, David Malcolm via Gcc-patches wrote:
> I added c_expr::m_decimal in r13-2386-gbedfca647a9e9c1a as part of the
> implementation of -Wxor-used-as-pow, but I missed various places where
> the field needed to be initialized.
>
> Fixed thusly (based on searchin
On 9/21/22 11:35, Richard Biener wrote:
> On Wed, Sep 21, 2022 at 9:49 AM Martin Liška wrote:
>>
>> On 9/21/22 09:36, Richard Biener wrote:
>>> If it's all configure time what's the point in
>>> "deprecating" it?
>>
>> Note it's one of our options -gz where 'zlib-gnu' is one of the possible
>> op
The following enhances the store-with-same-value trick in
vn_reference_lookup_3 by not only looking for
a = val;
*ptr = val;
.. = a;
but also
*ptr = val;
other = x;
.. = a;
where the earlier store is more than one hop away. It does this
by queueing the actual value to compare until
On Tue, Sep 13, 2022 at 2:58 PM Max Filippov wrote:
>
> Suwa-san, could you please take a look?
>
> This change fixes the fowllowing testsuite failures when building for
> call0 ABI:
>
> g++.dg/ipa/pr60640-4.C
> g++.dg/ipa/pr83549.C
> g++.dg/ipa/pr83667.C
> g++.dg/torture/pr81812.C
>
> gcc/
>
gcc/
* config/xtensa/xtensa.cc (TARGET_MAX_ANCHOR_OFFSET): New
definition.
---
gcc/config/xtensa/xtensa.cc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
index e5abd356a745..828c7642b7cb 100644
--- a/gcc/config/xtens
The following resolves the issue that DSE cannot handle references
with variable offsets well when identifying possible uses of a store.
Instead of just relying on ref_maybe_used_by_stmt_p we use data-ref
analysis, making sure to perform that at most once per stmt. The
new mode is only exercised b
Hi Kewen & Segher,
Thanks so much for your review comments.
On 22/9/2022 上午 10:28, Kewen.Lin wrote:
> on 2022/9/22 05:56, Segher Boessenkool wrote:
>> Hi!
>>
>> On Fri, Jun 24, 2022 at 10:02:19AM +0800, HAO CHEN GUI wrote:
>>> This patch also binds __builtin_vsx_xs[min/max]dp to fmin/max instea
Hi!
The following patch implements C++23 P1774R8 - Portable assumptions
paper, by introducing support for [[assume (cond)]]; attribute for C++.
In addition to that the patch adds [[gnu::assume (cond)]]; and
__attribute__((assume (cond))); support to both C and C++.
As described in C++23, the attri
On Thu, 22 Sep 2022, juzhe.zh...@rivai.ai wrote:
> Hi, Richard. I tried your suggestion which is applying your code and PR106019.
> It works for me now. Thank you so much.
>
> I will apply your suggestion on RVV GCC12.2 downstream (Because it has not
> been supported on upstream).
>
> I have an
Hi, Richard. I tried your suggestion which is applying your code and PR106019.
It works for me now. Thank you so much.
I will apply your suggestion on RVV GCC12.2 downstream (Because it has not been
supported on upstream).
I have another question:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=994
Hello Paul-Antoine, hi all,
On 21.09.22 23:18, Paul-Antoine Arras wrote:
Here is a patch that fixes an ICE in gfortran triggered by an invalid end
statement at the end of an OMP metadirective:
Remark for other reads of this email: This only applies to OG12 as mainline
does not have the follo
OK. Thank you so much fixing this for me. Would you mind pushing your
optimization upstream?
I will abandon my codes. Thank you so much.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2022-09-22 16:48
To: juzhe.zh...@rivai.ai
CC: gcc-patches
Subject: Re: Re: [PATCH] DSE: Enhance dse with de
On Thu, 22 Sep 2022, juzhe.zh...@rivai.ai wrote:
> Does your local code exclude my codes?
> I am using GCC12.2. When I delete all my codes and apply your codes only.
> It fails to delete redundant stores and no auto-vecotorization of my RVV GCC
> in this test.
> I am not sure whether I am on the
Does your local code exclude my codes?
I am using GCC12.2. When I delete all my codes and apply your codes only.
It fails to delete redundant stores and no auto-vecotorization of my RVV GCC in
this test.
I am not sure whether I am on the same page with you.
juzhe.zh...@rivai.ai
From: Richar
On Thu, 22 Sep 2022, Richard Biener wrote:
> On Thu, 22 Sep 2022, juzhe.zh...@rivai.ai wrote:
>
> > From: Ju-Zhe Zhong
> >
> > This patch fix issue: PR 99407
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99407
> >
> > The enhancement implementation is simple:
> > 1.Search gimple statement i
OK. You mean we should check why if fails in ref_maybe_used_by_stmt_p
instead of doing the data-ref analysis outside dse_classify_store ?
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2022-09-22 15:32
To: Ju-Zhe Zhong
CC: gcc-patches; richard.sandiford
Subject: Re: [PATCH] DSE: Enhance dse wi
On Thu, 22 Sep 2022, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> This patch fix issue: PR 99407
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99407
>
> The enhancement implementation is simple:
> 1.Search gimple statement in program reverse order.
> 2.Queue the store statement which m
Hi all,
This patch aims to optimize code generation of
__mm256_zextsi128_si256(__mm_set1_epi8(-1)). Reduce the number of instructions
required to achieve the final result.
Regtested on x86_64-pc-linux-gnu. Ok for trunk?
BRs,
Lin
gcc/ChangeLog:
PR target/94962
* config/i386/co
The following was prompted by review of the patch introducing
equivalences to VN.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-ssa-sccvn.cc (can_track_predicate_on_edge): New
function split out from ...
(vn_nary_op_insert_pieces_predicated): ... here
From: Ju-Zhe Zhong
This patch fix issue: PR 99407
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99407
The enhancement implementation is simple:
1.Search gimple statement in program reverse order.
2.Queue the store statement which may be possible kill the def
of previous store statement.
3.Perfo
95 matches
Mail list logo
