This restores the semantics of can_be_invalidated_p to the original
semantics of the function this was split out from tree-ssa-uninit.c.
The current semantics only ever look at the first predicate which
cannot be correct.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
Thanks,
Richard.
On Thu, Nov 25, 2021 at 11:38 AM Aldy Hernandez wrote:
>
> On Wed, Nov 24, 2021 at 9:00 AM Richard Biener
> wrote:
> >
> > On Tue, Nov 23, 2021 at 5:36 PM Martin Liška wrote:
> > >
> > > On 11/23/21 16:20, Martin Liška wrote:
> > > > Sure, so for e.g. case 1 ... 5 we would need to create a new
On Thu, Nov 25, 2021 at 7:17 PM Roger Sayle wrote:
>
>
> On Tue, Nov 23, 2021 at 12:46PM Richard Biener < richard.guent...@gmail.com>
> wrote:
> > On Thu, Nov 18, 2021 at 4:18 PM Roger Sayle
> > wrote:
> > > > The patch doesn't add any testcase.
> > >
> > > The three new attached tests check
Shadow Call Stack can be used to protect the return address of a
function at runtime, and clang already supports this feature[1].
To enable SCS in user mode, in addition to compiler, other support
is also required (as discussed in [2]). This patch only adds basic
support for SCS from the compiler
On Linux/x86_64,
90cb088ece8d8cc1019d25629d1585e5b0234179 is the first bad commit
commit 90cb088ece8d8cc1019d25629d1585e5b0234179
Author: konglin1
Date: Wed Nov 10 09:37:32 2021 +0800
i386: vcvtph2ps and vcvtps2ph should be used to convert _Float16 to SFmode
with -mf16c [PR 102811]
On 11/26/21 10:58, Siddhesh Poyarekar wrote:
sure it works) and saw no issues in any of those builds. I did some
rudimentary analysis of the generated binaries using fortify-metrics[1]
to confirm that there was a difference in coverage between the two
fortification levels.
Here is a summary of
Allow returning dynamic expressions from ADDR_EXPR for
__builtin_dynamic_object_size and also allow offsets to be dynamic.
gcc/ChangeLog:
* tree-object-size.c (size_valid_p): New function.
(size_for_offset): Remove OFFSET constness assertion.
(addr_object_size): Build
Handle non-constant expressions in GIMPLE_CALL arguments. Also handle
alloca.
gcc/ChangeLog:
* tree-object-size.c (alloc_object_size): Make and return
non-constant size expression.
(call_object_size): Return expression or unknown based on
whether dynamic object
Handle GIMPLE_PHI and conditionals specially for dynamic objects,
returning PHI/conditional expressions instead of just a MIN/MAX
estimate.
This makes the returned object size variable for loops and conditionals,
so tests need to be adjusted to look for precise size in some cases.
Handle hints provided by __attribute__ ((access (...))) to compute
dynamic sizes for objects.
gcc/ChangeLog:
* tree-object-size.c: Include tree-dfa.h.
(parm_object_size): New function.
(collect_object_sizes_for): Call it.
gcc/testsuite/ChangeLog:
*
Recognize the __builtin_dynamic_object_size builtin and add paths in the
object size path to deal with it, but treat it like
__builtin_object_size for now. Also add tests to provide the same
testing coverage for the new builtin name.
gcc/ChangeLog:
* builtins.def
Transform tree-object-size to operate on tree objects instead of host
wide integers. This makes it easier to extend to dynamic expressions
for object sizes.
The compute_builtin_object_size interface also now returns a tree
expression instead of HOST_WIDE_INT, so callers have been adjusted to
Put all accesses to object_sizes behind functions so that we can add
dynamic capability more easily.
gcc/ChangeLog:
* tree-object-size.c (object_sizes_grow, object_sizes_release,
object_sizes_unknown_p, object_sizes_get, object_size_set_force,
object_sizes_set): New
A simple cleanup to allow inserting dynamic size code more easily.
gcc/ChangeLog:
* tree-object-size.c: New enum.
(object_sizes, computed, addr_object_size,
compute_builtin_object_size, expr_object_size, call_object_size,
merge_object_sizes, plus_stmt_object_size,
This patchset implements the __builtin_dynamic_object_size builtin for
gcc. The primary motivation to have this builtin in gcc is to enable
_FORTIFY_SOURCE=3 support with gcc, thus allowing greater fortification
in use cases where the potential performance tradeoff is acceptable.
Semantics:
On Linux/x86_64,
1b0acc4b800b589a39d637d7312da5cf969a5765 is the first bad commit
commit 1b0acc4b800b589a39d637d7312da5cf969a5765
Author: Jan Hubicka
Date: Thu Nov 25 23:58:48 2021 +0100
Remove forgotten early return in ipa_value_range_from_jfunc
caused
FAIL: gcc.dg/ipa/inline-9.c
Tested x86_64-linux, pushed to trunk.
There was a c++11_only dg-error in this testcase, for a "body of
constexpr function is not a return statement" diagnostic that was bogus,
but happened because the return statement was ill-formed. A change to
G++ earlier this month means that diagnostic is
Tested x86_64-linux, pushed to trunk.
This implements the resolution I'm proposing for LWG 3545, to avoid hard
errors when using std::to_address for types that make pointer_traits
ill-formed.
Consistent with std::iterator_traits, instantiating std::pointer_traits
for a non-pointer type will be
Add -mmove-max=bits and -mstore-max=bits to enable 256-bit/512-bit move
and store, independent of -mprefer-vector-width=bits:
1. Add X86_TUNE_AVX512_MOVE_BY_PIECES and X86_TUNE_AVX512_STORE_BY_PIECES
which are enabled for Intel Sapphire Rapids processor.
2. Add -mmove-max=bits to set the maximum
Hi Mikael,
Am 25.11.21 um 22:02 schrieb Mikael Morin:
Le 25/11/2021 à 21:03, Harald Anlauf a écrit :
Hi Mikael,
Am 25.11.21 um 17:46 schrieb Mikael Morin:
Hello,
Le 24/11/2021 à 22:32, Harald Anlauf via Fortran a écrit :
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index
On Wed, 24 Nov 2021 at 01:27, Thomas Rodgers wrote:
>
> const qualification was also missing in the free functions for
> wait/wait_explicit/notify_one/notify_all. Revised patch attached.
Please tweak the whitespace in the new test:
> +test1(const std::atomic , char*p)
The '&' should be on the
Hi!
On Wed, Nov 24, 2021 at 08:48:47PM -0300, Raoni Fassina Firmino wrote:
> gcc/ChangeLog:
> * builtins.c (expand_builtin_fegetround): New function.
> (expand_builtin_feclear_feraise_except): New function.
> (expand_builtin): Add cases for BUILT_IN_FEGETROUND,
>
Le 25/11/2021 à 21:03, Harald Anlauf a écrit :
Hi Mikael,
Am 25.11.21 um 17:46 schrieb Mikael Morin:
Hello,
Le 24/11/2021 à 22:32, Harald Anlauf via Fortran a écrit :
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 5a5aca10ebe..837eb0912c0 100644
--- a/gcc/fortran/check.c
+++
* Jakub Jelinek:
>> +/* Fallback declaration for old glibc headers. DL_FIND_EH_FRAME_DBASE is
>> used
>> + as a proxy to determine if declares _dl_find_eh_frame. */
>> +#if defined __GLIBC__ && !defined DL_FIND_EH_FRAME_DBASE
>> +#if NEED_DBASE_MEMBER
>> +void *_dl_find_eh_frame (void
I have reword the previous patch to make the interface more generally
useful. Since there are now four words in the core arrays, I did away
with the separate base address array. (We can bring it back in the
future if necessary.) I fixed a bug in the handling of proxy map (by
not copying proxy
Tested x86_64-linux, pushed to trunk.
libstdc++-v3/ChangeLog:
PR libstdc++/101608
* include/bits/ranges_algobase.h (__fill_n_fn): Check for
constant evaluation before using memset.
* testsuite/25_algorithms/fill_n/constrained.cc: Check
byte-sized values
Hi Mikael,
Am 25.11.21 um 17:46 schrieb Mikael Morin:
Hello,
Le 24/11/2021 à 22:32, Harald Anlauf via Fortran a écrit :
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 5a5aca10ebe..837eb0912c0 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -4866,10 +4868,17 @@
On Tue, Nov 23, 2021 at 12:46PM Richard Biener < richard.guent...@gmail.com>
wrote:
> On Thu, Nov 18, 2021 at 4:18 PM Roger Sayle
> wrote:
> > > The patch doesn't add any testcase.
> >
> > The three new attached tests check that the critical invariants have a
> > simpler form, and hopefully
On Mon, Nov 1, 2021 at 7:02 AM H.J. Lu wrote:
>
> On Thu, Oct 21, 2021 at 12:56 PM H.J. Lu wrote:
> >
> > On Wed, Sep 22, 2021 at 7:02 PM H.J. Lu wrote:
> > >
> > > Changes in the v4 patch.
> > >
> > > 1. Add nodirect_extern_access attribute.
> > >
> > > Changes in the v3 patch.
> > >
> > > 1.
On Tue, Nov 23, 2021 at 06:56:14PM +0100, Florian Weimer wrote:
> 8<--8<
> This allows switching to a different implementation for
> PT_GNU_EH_FRAME lookup in a subsequent commit.
>
> This moves some of the PT_GNU_EH_FRAME parsing
> >
> > In ipa-modref I precompute this to map so we do not need to walk all
> > params, but the loop is probably not bad since functions do not have
> > tens of thousdands parameters :)
>
> The most I have seen is about 70 and those were big outliers.
>
> I was thinking of precomputing it
Hi,
On Thu, Nov 25 2021, Jan Hubicka wrote:
>>
>> gcc/ChangeLog:
>>
>> 2021-11-23 Martin Jambor
>>
>> PR ipa/103227
>> * ipa-prop.h (ipa_get_param): New overload. Move bits of the existing
>> one to the new one.
>> * ipa-param-manipulation.h (ipa_param_adjustments): New
If committed this patch to fix the amdgcn ICE reported in PR103396.
The problem was that it was mis-counting the number of registers to save
when the link register was only clobbered implicitly by calls. The issue
is easily fixed by adjusting the condition to match elsewhere in the
same
Hello,
Le 24/11/2021 à 22:32, Harald Anlauf via Fortran a écrit :
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 5a5aca10ebe..837eb0912c0 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -4866,10 +4868,17 @@ gfc_check_reshape (gfc_expr *source, gfc_expr *shape,
Pushed.
Sorry for the noise.
On Thu, Nov 25, 2021 at 1:51 PM Aldy Hernandez wrote:
>
> On Thu, Nov 25, 2021 at 1:38 PM Richard Biener
> wrote:
> >
> > On Thu, Nov 25, 2021 at 1:10 PM Aldy Hernandez wrote:
> > >
> > > On Thu, Nov 25, 2021 at 12:57 PM Richard Biener
> > > wrote:
> > > >
> > >
On 11/21/21 21:51, Will Wray via Gcc-patches wrote:
Also address "FIXME: this code is duplicated from reshape_init" in
cp_complete_array_type by always calling reshape_init on init-list.
PR c++/55227
gcc/cp/ChangeLog:
* decl.c (reshape_init_r): Only call has_designator_check
On 11/8/21 15:03, Will Wray via Gcc-patches wrote:
This patch allows __builtin_bit_cast to materialize a C array as its To type.
It was developed as part of an implementation of P1997, array copy-semantics,
but is independent, so makes sense to submit, review and merge ahead of it.
On 11/25/21 09:38, Jakub Jelinek wrote:
On Wed, Nov 24, 2021 at 09:07:48PM -0500, Jason Merrill wrote:
--- gcc/cp/tree.c.jj2021-11-24 15:05:23.371927735 +0100
+++ gcc/cp/tree.c 2021-11-24 17:09:05.348164621 +0100
@@ -5167,6 +5167,7 @@ make_ptrmem_cst (tree type, tree member)
tree
> -Original Message-
> From: Jakub Jelinek
> Sent: Thursday, November 25, 2021 9:53 AM
> To: Richard Biener
> Cc: Tamar Christina ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] match.pd: Fix up the recent bitmask_inv_cst_vector_p
> simplification [PR103417]
>
> On Thu, Nov 25, 2021
On Wed, Nov 24, 2021 at 09:07:48PM -0500, Jason Merrill wrote:
> > --- gcc/cp/tree.c.jj2021-11-24 15:05:23.371927735 +0100
> > +++ gcc/cp/tree.c 2021-11-24 17:09:05.348164621 +0100
> > @@ -5167,6 +5167,7 @@ make_ptrmem_cst (tree type, tree member)
> > tree ptrmem_cst = make_node
This removes unreachable return statements as diagnosed by
the -Wunreachable-code patch. Some cases are more obviously
an improvement than others - in fact some may get you the idea
to replace them with gcc_unreachable () instead, leading to
cases of the 'Remove unreachable gcc_unreachable () at
This patch changes parsing for OpenMP map clauses in C++ to use the
generic expression parser, hence adds support for parsing general
lvalues (as required by OpenMP 5.0+). So far only a few new types of
expression are actually supported throughout compilation (including
everything in the
This patch adds support for parsing general lvalues for OpenMP "map"
clauses to the C front-end, similar to the previous patch for C++.
This version of the patch fixes several omissions regarding non-DECL_P
root terms in map clauses (i.e. "*foo" in "(*foo)->ptr->arr[:N]") --
similar to the
Several places in the C and C++ front-ends dig through OpenMP addresses
from "map" clauses (etc.) in order to determine whether they are component
accesses that need "attach" operations, check duplicate mapping clauses,
and so on. When we're extending support for more kinds of lvalues in
map
The C and C++ front-ends use a TREE_LIST as a 3-tuple representing an
OpenMP array section, which tends to crash debug_generic_expr if one
wants to print such an expression in the debugger. This little helper
function works around that.
We might want to adjust the representation of array
This patch fixes the baseptrs-3.C test case introduced in the patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/580729.html
The problematic case concerns OpenMP mapping clauses containing struct
members of reference type, e.g. "mystruct.myref.myptr[:N]". To be able
to access the
I noticed that the test in question now compiles properly, and in fact
runs properly too. Thus it's more useful as a runtime test than a
passing compilation test that otherwise doesn't do much. This patch
moves it to libgomp.
OK?
Thanks,
Julian
2021-10-11 Julian Brown
gcc/testsuite/
This patch fixes attach/detach operations for OpenMP that have a non-zero
bias: these can occur if we have a mapping such as:
#pragma omp target map(mystruct->a.b[idx].c[:arrsz])
i.e. where there is an offset between the attachment point ("mystruct"
here) and the pointed-to data. (The "b" and
On 7/30/21 13:01, Iain Buclaw via Gcc-patches wrote:
|Covers cases where functions that handle the extracted strings ignore the
explicit length. This isn't something that's known to happen in the current
front-end, but the self-hosted front-end has been observed to do this in its
conversions
This patch fixes parsing for struct components that are array references
in OMP clauses in both the C and C++ front ends.
OK?
Thanks,
Julian
2021-09-29 Julian Brown
gcc/c/
* c-typeck.c (c_finish_omp_clauses): Allow ARRAY_REF components.
gcc/cp/
* semantics.c
This patch lifts struct sibling-list handling out of the main loop in
gimplify_scan_omp_clauses. The reasons for this are several: first,
it means that we can subject created sibling list groups to topological
sorting (see previous patch) so base-pointer data dependencies are
handled correctly.
This patch has been split out from the previous one to avoid a
confusingly-interleaved diff. The two patches should probably be
committed squashed together.
2021-10-01 Julian Brown
gcc/
* gimplify.c (omp_target_reorder_clauses): Delete.
---
gcc/gimplify.c | 183
This patch reimplements the omp_target_reorder_clauses function in
anticipation of supporting "deeper" struct mappings (that is, with
several structure dereference operators, or similar).
The idea is that in place of the (possibly quadratic) algorithm in
omp_target_reorder_clauses that greedily
In preparation for follow-up patches extending struct dereference
handling for OpenMP, this patch removes base_ind/base_ref handling from
gimplify.c:extract_base_bit_offset. This arguably simplifies some of the
code around the callers of the function also, though subsequent patches
modify those
On Thu, 25 Nov 2021, Michael Matz wrote:
> Hello,
>
> On Thu, 25 Nov 2021, Richard Biener via Gcc-patches wrote:
>
> > It seems to be a style to place gcc_unreachable () after a
> > switch that handles all cases with every case returning.
> > Those are unreachable (well, yes!), so they will be
(Previously posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570400.html)
This patch reworks indirect struct handling in gimplify.c (i.e. for
struct components mapped with "mystruct->a[0:n]", "mystruct->b", etc.),
for OpenACC. The key observation leading to these changes was that
(Previously submitted here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570398.html)
This patch is a second attempt at refactoring struct component mapping
handling for OpenACC/OpenMP during gimplification, after the patch I
posted here:
This patch slightly cleans up the semantics of extract_base_bit_offset,
in that the stripping of ARRAY_REFS/INDIRECT_REFS out of
extract_base_bit_offset is moved back into the (two) call sites of the
function. This is done in preparation for follow-on patches that extend
the function.
Previously
It never makes sense for a GOMP_MAP_ATTACH_DETACH mapping to survive
beyond gimplify.c, so this patch rewrites such mappings to GOMP_MAP_ATTACH
or GOMP_MAP_DETACH unconditionally (rather than checking for a list
of types of OpenACC or OpenMP constructs), in cases where it hasn't
otherwise been
Hi Jakub,
This is a rebased/slightly bug-fixed version of several previously posted
patch series, all in one place for ease of reference. The series should
be applied on top of Chung-Lin's two patches:
"Improve OpenMP target support for C++ [PR92120 v5]"
Various ranger enabled passes, such as threading, or VRP2 resolve this
now. I'm adding the test case before closing.
committed as obvious.
Andrew
commit 1598bd47b2a4a5f12b5a987d16d82634644db4b6
Author: Andrew MacLeod
Date: Thu Nov 25 08:58:19 2021 -0500
Add the testcase for this PR
Hello,
On Thu, 25 Nov 2021, Richard Biener via Gcc-patches wrote:
> It seems to be a style to place gcc_unreachable () after a
> switch that handles all cases with every case returning.
> Those are unreachable (well, yes!), so they will be elided
> at CFG construction time and the middle-end
Fixes:
==129444==ERROR: AddressSanitizer: global-buffer-overflow on address
0x0666ca5c at pc 0x00ef094b bp 0x7fff8180 sp 0x7fff8178
READ of size 4 at 0x0666ca5c thread T0
#0 0xef094a in parse_optimize_options ../../gcc/d/d-attribs.cc:855
#1 0xef0d36 in
On 22/11/2021 11:41, Richard Biener wrote:
On 18/11/2021 11:05, Richard Biener wrote:
This is a good shout and made me think about something I hadn't before... I
thought I could handle the vector forms later, but the problem is if I add
support for the scalar, it will stop the vectorizer. It
On Thu, 25 Nov 2021, Michael Matz wrote:
> Hello,
>
> On Thu, 25 Nov 2021, Richard Biener wrote:
>
> > > Yes, that's definitely the case - I was too lazy to re-use the old
> > > option name here. But I don't have a good name at hand, maybe clang
> > > has an option covering the cases I'm
On 11/25/21 07:40, Richard Biener wrote:
On Wed, Nov 24, 2021 at 9:49 PM Andrew MacLeod via Gcc-patches
wrote:
PHI nodes frequently feed each other, and this is particularly true of
the one/two incoming edge PHIs inserted by some of the loop analysis
code which is introduced at the start of
On Thu, 25 Nov 2021, Jan Hubicka wrote:
> Hi,
> this pach removes gimple_call_cahin checkin ref_maybe_used_by_call_p that
> disables check for CONST functions. I suppose it was meant to allow consts
> to read variables from the static chain but this is not what other places
> do. The testcase:
It seems to be a style to place gcc_unreachable () after a
switch that handles all cases with every case returning.
Those are unreachable (well, yes!), so they will be elided
at CFG construction time and the middle-end will place
another __builtin_unreachable "after" them to note the
path doesn't
> We have quite a number of "default" returns that cannot be reached.
> One is particularly interesting since it says (see patch below):
>
> default:
>gcc_unreachable ();
> }
>/* We can get here with --disable-checking. */
>return false;
>
> which suggests that _maybe_
We have quite a number of "default" returns that cannot be reached.
One is particularly interesting since it says (see patch below):
default:
gcc_unreachable ();
}
/* We can get here with --disable-checking. */
return false;
which suggests that _maybe_ the intention was
Hello,
On Thu, 25 Nov 2021, Richard Biener wrote:
> > Yes, that's definitely the case - I was too lazy to re-use the old
> > option name here. But I don't have a good name at hand, maybe clang
> > has an option covering the cases I'm thinking about.
As you asked: I already have difficulties to
Hi,
this pach removes gimple_call_cahin checkin ref_maybe_used_by_call_p that
disables check for CONST functions. I suppose it was meant to allow consts
to read variables from the static chain but this is not what other places
do. The testcase:
int
main()
{
int a =0;
> The only use of get_alias_symbol is gated by a gcc_unreachable (),
> so the following patch gets rid of it.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
OK,
thanks!
Honza
On Thu, Nov 25, 2021 at 1:38 PM Richard Biener
wrote:
>
> On Thu, Nov 25, 2021 at 1:10 PM Aldy Hernandez wrote:
> >
> > On Thu, Nov 25, 2021 at 12:57 PM Richard Biener
> > wrote:
> > >
> > > On Thu, Nov 25, 2021 at 11:55 AM Aldy Hernandez via Gcc-patches
> > > wrote:
> > > >
> > > > Andrew's
On Thu, 25 Nov 2021, Andre Vieira (lists) wrote:
>
> On 24/11/2021 11:00, Richard Biener wrote:
> > On Wed, 24 Nov 2021, Andre Vieira (lists) wrote:
> >
> >> On 22/11/2021 12:39, Richard Biener wrote:
> >>> + if (first_loop_vinfo->suggested_unroll_factor > 1)
> >>> +{
> >>> + if
On Wed, Nov 24, 2021 at 9:49 PM Andrew MacLeod via Gcc-patches
wrote:
>
> PHI nodes frequently feed each other, and this is particularly true of
> the one/two incoming edge PHIs inserted by some of the loop analysis
> code which is introduced at the start of the VRP passes.
>
> Ranger has a
On Thu, Nov 25, 2021 at 1:10 PM Aldy Hernandez wrote:
>
> On Thu, Nov 25, 2021 at 12:57 PM Richard Biener
> wrote:
> >
> > On Thu, Nov 25, 2021 at 11:55 AM Aldy Hernandez via Gcc-patches
> > wrote:
> > >
> > > Andrew's patch for this PR103254 papered over some underlying
> > > performance
This avoids a -Wunreachable-code diagnostic with EXECUTE_IF_*
in case the first iteration will exit the loop. For the case
in thread_jump using bitmap_empty_p looks preferable so this
adds REG_SET_EMPTY_P to make that available for register sets.
Bootstrapped and tested on
This refactors the IL "walk" in a way to avoid the loop which will
never iterate.
Bootstrapped and tested on x86_64-unknown-linux-gnu, will push later
unless there are comments explaining the function is wrong in other
ways.
Richard.
2021-11-25 Richard Biener
* cfgexpand.c
One case used fatal_insn which does not return which isn't
intended as can be seen by the following erro = 1. The following
change refactors this to inline the relevant parts of fatal_insn
instead and continue validating the RTL IL.
Bootstrapped and tested on x86_64-unknown-linux-gnu, will push.
The only use of get_alias_symbol is gated by a gcc_unreachable (),
so the following patch gets rid of it.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
Thanks,
Richard.
2021-11-24 Richard Biener
* cgraphunit.c (symbol_table::output_weakrefs): Remove
unreachable
On Thu, Nov 25, 2021 at 12:57 PM Richard Biener
wrote:
>
> On Thu, Nov 25, 2021 at 11:55 AM Aldy Hernandez via Gcc-patches
> wrote:
> >
> > Andrew's patch for this PR103254 papered over some underlying
> > performance issues in the path solver that I'd like to address.
> >
> > We are currently
On Thu, Nov 25, 2021 at 12:30 PM Roger Sayle wrote:
>
>
> This is a simple one line fix to the regression PR middle-end/103406,
> where x - x is being folded to 0.0 even when x is +Inf or -Inf.
> In GCC 11 and previously, we'd check whether the type honored NaNs
> (which implicitly covered the
On Thu, Nov 25, 2021 at 11:55 AM Aldy Hernandez via Gcc-patches
wrote:
>
> Andrew's patch for this PR103254 papered over some underlying
> performance issues in the path solver that I'd like to address.
>
> We are currently solving the SSA's defined in the current block in
> bitmap order, which
This is a simple one line fix to the regression PR middle-end/103406,
where x - x is being folded to 0.0 even when x is +Inf or -Inf.
In GCC 11 and previously, we'd check whether the type honored NaNs
(which implicitly covered the case where the type honors infinities),
but my patch to test
Pushed as obvious.
Martin
gcc/ChangeLog:
* doc/invoke.texi: Use @option for -Wuninitialized.
---
gcc/doc/invoke.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index d0ac59768b9..3bddfbaae6a 100644
---
>
> gcc/ChangeLog:
>
> 2021-11-23 Martin Jambor
>
> PR ipa/103227
> * ipa-prop.h (ipa_get_param): New overload. Move bits of the existing
> one to the new one.
> * ipa-param-manipulation.h (ipa_param_adjustments): New member
> function
On Thu, 25 Nov 2021, Jakub Jelinek wrote:
> On Thu, Nov 25, 2021 at 10:17:52AM +0100, Richard Biener wrote:
> > > Ah I see, sorry I didn't see that rule before, you're right that if this
> > > is ordered
> > > after it then they can be dropped.
> >
> > So the patch is OK, possibly with
On Thu, 25 Nov 2021, Richard Biener wrote:
> On Wed, 24 Nov 2021, Jason Merrill wrote:
>
> > On 11/24/21 11:15, Marek Polacek wrote:
> > > On Wed, Nov 24, 2021 at 04:21:31PM +0100, Richard Biener via Gcc-patches
> > > wrote:
> > >> This resurrects -Wunreachable-code and implements a warning for
In a follow-up patch I will be pruning the set of exported ranges
within blocks to avoid unnecessary work. In order to do this, all the
interesting SSA names must be in the internal import bitmap ahead of
time. I had already abstracted them out into compute_imports, but I
missed the boolean
Andrew's patch for this PR103254 papered over some underlying
performance issues in the path solver that I'd like to address.
We are currently solving the SSA's defined in the current block in
bitmap order, which amounts to random order for all purposes. This is
causing unnecessary recursion in
On 24/11/2021 11:00, Richard Biener wrote:
On Wed, 24 Nov 2021, Andre Vieira (lists) wrote:
On 22/11/2021 12:39, Richard Biener wrote:
+ if (first_loop_vinfo->suggested_unroll_factor > 1)
+{
+ if (LOOP_VINFO_EPIL_USING_PARTIAL_VECTORS_P (first_loop_vinfo))
+ {
+ if
On Wed, Nov 24, 2021 at 9:00 AM Richard Biener
wrote:
>
> On Tue, Nov 23, 2021 at 5:36 PM Martin Liška wrote:
> >
> > On 11/23/21 16:20, Martin Liška wrote:
> > > Sure, so for e.g. case 1 ... 5 we would need to create a new
> > > unswitch_predicate
> > > with 1 <= index && index <= 5 tree
On Thu, Nov 25, 2021 at 9:00 AM liuhongt via Gcc-patches
wrote:
>
> TYPE_PRECISION (type) < TYPE_PRECISION (TREE_TYPE (@2)) supposed to check
> integer type but not pointer type, so use second parameter instead.
>
> i.e. first parameter is VPTR, second parameter is I4.
>
> 582DEF_SYNC_BUILTIN
On Mon, Aug 30, 2021 at 10:06 PM Martin Sebor via Gcc-patches
wrote:
>
> The predicate analysis subset of the tree-ssa-uninit pass isn't
> necessarily specific to the detection of uninitialized reads.
> Suitably parameterized, the same core logic could be used in
> other warning passes to improve
Just a quick ping to check this hasn't been forgotten.
> -Original Message-
> From: Joel Hutton
> Sent: 12 November 2021 11:42
> To: Richard Biener
> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford
>
> Subject: RE: [vect-patterns] Refactor widen_plus/widen_minus as
> internal_fns
>
> >
On Thu, Nov 25, 2021 at 10:17:52AM +0100, Richard Biener wrote:
> > Ah I see, sorry I didn't see that rule before, you're right that if this is
> > ordered
> > after it then they can be dropped.
>
> So the patch is OK, possibly with re-ordering the matches.
I've committed the patch as is
On Thu, Nov 25, 2021 at 09:21:37AM +0100, Richard Biener wrote:
> OK if you can add a testcase that exercises this "feature".
Sure, that is easy.
Here is what I've committed. f2 tests the x | x = x handling in it,
f3 tests x | y = unknown instead of punting, f4 tests x ^ x = 0
and f5 tests x ^
Changes from original patch:
1. Merged test_redef_* test files into one
2. Encapsulated contents of arm-mve-builtins.h in namespace arm_mve (missed
in initial patch).
3. Added extern declarations for scalar_types and acle_vector types to
arm-mve-builtins.h (missed in initial patch).
4.
On Thu, 25 Nov 2021, Tamar Christina wrote:
>
>
> > -Original Message-
> > From: Jakub Jelinek
> > Sent: Thursday, November 25, 2021 8:39 AM
> > To: Tamar Christina
> > Cc: Richard Biener ; gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH] match.pd: Fix up the recent
1 - 100 of 109 matches
Mail list logo
