When loop distribution releases a PHI node of the original IL it
can end up clobbering memory that's re-used when it upon releasing
its RDG resets all stmt UIDs back to -1, even those that got released.
The fix is to avoid resetting UIDs based on stmts in the RDG but
instead reset only those
On Fri, May 10, 2024 at 3:18 PM Robin Dapp wrote:
>
> Hi,
>
> this only forces the first comparison operator into a register if it is
> not already suitable.
>
> Bootstrap and regtest is running on x86 and aarch64, successful on p10.
> Regtested on riscv.
How does this make a difference in the
On Fri, Mar 1, 2024 at 10:21 AM Richard Biener wrote:
>
> The following removes the over-broad rejection of patterns for SLP
> reductions which is done by removing them from LOOP_VINFO_REDUCTIONS
> during pattern detection. That's also insufficient in case the
> patte
On Fri, May 10, 2024 at 12:55 PM Di Zhao OS
wrote:
>
> This patch tries to fix pr114760 by checking for the
> variants explicitly. When recognizing bit counting idiom,
> include pattern "x * 2" for "x << 1", and "x / 2" for
> "x >> 1" (given x is unsigned).
>
> Bootstrapped and tested on
On Fri, May 10, 2024 at 12:54 PM Segher Boessenkool
wrote:
>
> On Fri, May 10, 2024 at 12:19:35PM +0200, Richard Biener wrote:
> > On Fri, May 10, 2024 at 11:06 AM Segher Boessenkool
> > wrote:
> > > *All* code using a cost will have to be inspected and possibly a
On Fri, May 10, 2024 at 11:24 AM Aldy Hernandez wrote:
>
> There are various calls into fold_range() that have the wrong type
> associated with the range temporary used to hold the result. This
> used to work, because we could store either integers or pointers in a
> Value_Range, but is no
On Fri, May 10, 2024 at 11:06 AM Segher Boessenkool
wrote:
>
> On Fri, May 10, 2024 at 04:50:10PM +0800, HAO CHEN GUI wrote:
> > Hi Richard,
> > Thanks for your comments.
> >
> > 在 2024/5/10 15:16, Richard Biener 写道:
> > > But if targets return sth
On Fri, May 10, 2024 at 10:54 AM John Paul Adrian Glaubitz
wrote:
>
> Hello Rainer,
>
> On Fri, 2024-05-10 at 10:20 +0200, Rainer Orth wrote:
> > > > Support for Solaris 11.3 had already been obsoleted in GCC 13. However,
> > > > since the only Solaris system in the cfarm was running 11.3, I've
On Fri, May 10, 2024 at 4:25 AM HAO CHEN GUI wrote:
>
> Hi,
>The cost return from set_src_cost might be zero. Zero for
> pattern_cost means unknown cost. So the regularization converts the zero
> to COSTS_N_INSNS (1).
>
>// pattern_cost
>cost = set_src_cost (SET_SRC (set), GET_MODE
On Thu, 9 May 2024, Jakub Jelinek wrote:
> On Thu, May 09, 2024 at 12:14:43PM +0200, Jakub Jelinek wrote:
> > On Thu, May 09, 2024 at 12:04:38PM +0200, Rainer Orth wrote:
> > > I just noticed that gcc/DATESTAMP wasn't updated yesterday and today,
> > > staying at 20240507.
> >
> > I think it is
computations out of loops.
> > -The pass is located in @file{tree-ssa-loop.cc} and described by
> > +The pass is located in @file{tree-ssa-loop-im.cc} and described by
> > @code{pass_lim}.
> >
> > -@item Loop nest optimizations
> > -
> > -This is a family of loop transformations that works on loop nests. It
> > -includes loop interchange, scaling, skewing and reversal and they are
> > -all geared to the optimization of data locality in array traversals
> > -and the removal of dependencies that hamper optimizations such as loop
> > -parallelization and vectorization. The pass is located in
> > -@file{tree-loop-linear.c} and described by
> > -@code{pass_linear_transform}.
> > -
> > -@item Removal of empty loops
> > -
> > -This pass removes loops with no code in them. The pass is located in
> > -@file{tree-ssa-loop-ivcanon.cc} and described by
> > -@code{pass_empty_loop}.
> > -
> > @item Unrolling of small loops
> >
> > This pass completely unrolls loops with few iterations. The pass
>
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
On Thu, May 9, 2024 at 9:12 PM Joseph Myers wrote:
>
> On Wed, 8 May 2024, Kewen.Lin wrote:
>
> > to widen IFmode to TFmode. To make build_common_tree_nodes
> > be able to find the correct mode for long double type node,
> > it introduces one hook mode_for_longdouble to offer target
> > a way to
On Fri, Mar 29, 2024 at 8:02 PM Jørgen Kvalsvik wrote:
>
> This is a prototype for --include/--exclude flags, and I would like a
> review of both the approach and architecture, and the implementation,
> plus feedback on the feature itself. I did not update the manuals or
> carefully extend
On Wed, Mar 13, 2024 at 2:56 PM Ajit Agarwal wrote:
>
> Hello Richard:
>
> Currently, code sinking will sink code at the use points with loop having same
> nesting depth. The following patch improves code sinking by placing the sunk
> code in begining of the block after the labels.
>
> For
For pointer reductions we need to convert the initial value to
the vector component integer type.
Re-bootstrap and regtest running on x86_64-unknown-linux-gnu.
I've ran into this latent bug on the force-slp branch.
Richard.
* tree-vect-loop.cc (get_initial_defs_for_reduction): Convert
When we have a non-grouped access we bogously multiply by zero.
This shows most with single-lane SLP but also happens with
the multi-lane splat case.
Re-bootstrap & regtest running on x86_64-unknown-linux-gnu.
I've ran into this latent bug on the force-slp branch.
Richard.
*
On Wed, May 8, 2024 at 9:56 AM Stefan Schulze Frielinghaus
wrote:
>
> On s390 the following tests fail
>
> FAIL: gcc.dg/vect/pr109011-1.c -flto -ffat-lto-objects scan-tree-dump-times
> optimized " = .CLZ (vect" 1
> FAIL: gcc.dg/vect/pr109011-1.c -flto -ffat-lto-objects scan-tree-dump-times
When insert_updated_phi_nodes_for tries to skip pruning the IDF to
blocks dominated by the nearest common dominator of the set of
definition blocks it compares against ENTRY_BLOCK but that's never
going to be the common dominator. In fact if it ever were the code
fails to copy IDF to PRUNED_IDF,
case '_':
> + case '+':
> + a = *x;
> + x++;
> + continue;
> + default:
> + break;
> + }
> + break;
> +}
> + if (a == '0' || a == '+')
> +__builtin_abort ();
> +}
> +
> +int
> +main ()
> +{
> + foo ("_");
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
On Wed, May 8, 2024 at 7:50 AM Kewen.Lin wrote:
>
> Hi,
>
> As the discussion in PR112980, although the current
> implementation for -fpatchable-function-entry* conforms
> with the documentation (making N NOPs be consecutive),
> it's inefficient for both kernel and userspace livepatching
> (see
On Wed, May 8, 2024 at 5:25 AM Andrew Pinski wrote:
>
> We can optimize `a == nonnegative ? a : ABS`, `a > nonnegative ? a :
> ABS`
> and `a >= nonnegative ? a : ABS` into `ABS`. This allows removal of
> some extra comparison and extra conditional moves in some cases.
> I don't remember where I
On Tue, May 7, 2024 at 10:56 PM Andrew Pinski wrote:
>
> On Tue, May 7, 2024 at 1:45 PM Jeff Law wrote:
> >
> >
> >
> > On 4/30/24 9:21 PM, Andrew Pinski wrote:
> > > This adds a few more of what is currently done in phiopt's
> > > value_replacement
> > > to match. I noticed this when I was
hdr
> members from struct flex now (f->hdr.foo instead of f->foo). Sometimes
> this can be avoided by using a union, as I did in a recent refactoring
> in Linux: [4]
>
> For more complex cases in Linux we've handled this by using our
> "struct_group"[5] macro, which allows for a union and tagged struct to
> be constructed:
>
> struct flex {
> __struct_group(flex_hdr, hdr,,
> int foo;
> int bar;
> );
> char data[];
> };
> struct mid_flex { struct flex_hdr hdr; int n; int o; };
>
> Then struct flex member names don't have to change, but if anything is
> trying to get at struct flex::data through struct mid_flex::hdr, that'll
> need casting. But it _shouldn't_ since it has "n" and "o".
>
> -Kees
>
> [1] https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620122.html
> [2] https://github.com/RTEMS/rtems
> [3]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/container_of.h#n10
> [4] https://git.kernel.org/linus/896880ff30866f386ebed14ab81ce1ad3710cfc4
> [5]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/stddef.h?h=v6.8#n11
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
On Tue, May 7, 2024 at 10:44 PM Joseph Myers wrote:
>
> On Fri, 3 May 2024, Richard Biener wrote:
>
> > So what I do not necessarily agree with is that we need to preserve
> > the multiplication with -fsignaling-nans. Do we consider a program doing
> >
> >
> Am 07.05.2024 um 18:02 schrieb Jakub Jelinek :
>
> Hi!
>
> The HF and BF modes have the same size/precision and neither is
> a subset nor superset of the other.
> So, using either __extendhfbf2 or __trunchfbf2 is weird.
> The expansion apparently emits __extendhfbf2, but on the libgcc side
> Am 07.05.2024 um 17:54 schrieb Jakub Jelinek :
>
> Hi!
>
> In r9-5742 we've started allowing to inline always_inline functions into
> functions which have disabled e.g. address sanitization even when the
> always_inline function is implicitly from command line options sanitized.
>
> This
When insert_updated_phi_nodes_for tries to skip pruning the IDF to
blocks dominated by the nearest common dominator of the set of
definition blocks it compares against ENTRY_BLOCK but that's never
going to be the common dominator, instead it will be at most its single
successor.
Re-bootstrap and
The following avoids re-allocating the var map BB vector by
pre-allocating it to the exact size needed when operating on the
whole function.
Re-bootstrap and regtest running on x86_64-unknown-linux-gnu.
* tree-ssa-live.cc (init_var_map): Pre-allocate vec_bbs vector
to the correct
This replaces a >= 0 block index check with the appropriate NUM_FIXED_BLOCKs,
the check is from times ENTRY_BLOCK was negative.
Re-bootstrap and regtest running on x86_64-unknown-linux-gnu.
* tree-into-ssa.cc (insert_updated_phi_nodes_for): Fix block
index check.
---
This avoids a tempoary when gimplifying reg = a ? b : c, re-using
the LHS of an assignment if that's a register.
Re-bootstrap and regtest running on x86_64-unknown-linux-gnu.
PR middle-end/27800
* gimplify.cc (gimplify_modify_expr_rhs): For a COND_EXPR
avoid a temporary
operand_equal_p already has checking code to verify the hash
is equal, avoid doing that again in gimplify_hasher::equal.
Re-bootstrap & regtest running on x86_64-unknown-linux-gnu.
* gimplify.cc (gimplify_hasher::equal): Remove redundant
checking.
---
gcc/gimplify.cc | 4
1
On Mon, 6 May 2024, Martin Uecker wrote:
> Am Montag, dem 06.05.2024 um 11:07 +0200 schrieb Richard Biener:
> > On Mon, 6 May 2024, Martin Uecker wrote:
> >
> > > Am Montag, dem 06.05.2024 um 09:00 +0200 schrieb Richard Biener:
> > > > On
On Fri, Jan 26, 2024 at 7:26 PM Roger Sayle wrote:
>
>
> This patch addresses a missed optimization opportunity in the RTL
> optimization passes. The function simplify_const_binary_operation
> will constant fold binary operators with two CONST_INT operands,
> and those with two CONST_VECTOR
On Tue, May 7, 2024 at 10:58 AM Stefan Schulze Frielinghaus
wrote:
>
> Ping. Ok for mainline?
OK.
Thanks,
Richard.
> On Thu, Apr 25, 2024 at 09:26:45AM +0200, Stefan Schulze Frielinghaus wrote:
> > Bitcount operations popcount, clz, and ctz are emulated for narrow modes
> > in case an
We're currently using size_t but at the same time storing them into
bitmaps which only support unsigned int index. The following makes
it unsigned int throughout, saving memory as well.
Re-bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
* cfgexpand.cc
Status
==
The GCC 14.1 release tarballs have been created, the releases/gcc-14
branch is open again for regression and documentation bugfixing.
GCC 14.2 can be expected in about two months unless something serious
changes the plans.
Quality Data
Priority # Change
On Mon, May 6, 2024 at 11:28 PM Andrew Pinski wrote:
>
> Like was done for -ffast-math in r0-105946-ga570fc16fa8056, we should
> document that -Ofast enables -fmath-errno, -funsafe-math-optimizations,
> -finite-math-only, -fno-trapping-math in their documentation.
>
> Note this changes the
The following implements the gist of the PR100923 fix in a leaner
(and more complete) way by realizing that all ao_ref_init_from_vn_reference
uses need to have an SSA name in the base valueized with availability
in mind. Instead of re-valueizing the whole chain of operands we can
simply only and
This makes sure we can create ao_refs from all VN operands we create.
Bootstrapped and tested on x86_64-unknown-linux-gnu. Will push later.
Richard.
* tree-ssa-sccvn.cc (ao_ref_init_from_vn_reference): Add
TARGET_MEM_REF support. Handle more bases.
---
gcc/tree-ssa-sccvn.cc |
The following further strengthens the check which convert expressions
we allow to vectorize as simple copy by resorting to
tree_nop_conversion_p on the vector components.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
PR tree-optimization/114921
*
On Mon, May 6, 2024 at 10:29 AM Peter0x44 wrote:
>
> On Mon May 6, 2024 at 8:14 AM BST, Richard Biener wrote:
> > On Sat, May 4, 2024 at 9:36 PM Peter Damianov wrote:
> > >
> > > Currently, commands like:
> > > gcc -o file.c -lm
> > > will delete
ptimization opportunities. */
> if (access_has_children_p (lacc))
> - generate_subtree_copies (lacc->first_child, rhs, lacc->offset,
> - 0, 0, gsi, true, true, loc);
> + {
> + generate_subtree_copies (lacc->first_c
On Mon, 6 May 2024, Martin Uecker wrote:
> Am Montag, dem 06.05.2024 um 09:00 +0200 schrieb Richard Biener:
> > On Sat, 4 May 2024, Martin Uecker wrote:
> >
> > > Am Freitag, dem 03.05.2024 um 21:16 +0200 schrieb Jakub Jelinek:
> > > > > On Fri, May 03,
On Sun, 5 May 2024, Rainer Orth wrote:
> Rainer Orth writes:
>
> >> On Fri, May 03, 2024 at 09:31:08AM -0400, David Malcolm wrote:
> >>> Jakub, Richi, Rainer: this is a non-trivial change that cleans up
> >>> analyzer C++ testsuite results on Solaris, but has a slight risk of
> >>> affecting
On Sat, May 4, 2024 at 9:36 PM Peter Damianov wrote:
>
> Currently, commands like:
> gcc -o file.c -lm
> will delete the user's code.
Since there's an error from the linker in the end (missing 'main'), I wonder if
the linker can avoid truncating/opening the output file instead? A trivial
On Sat, 4 May 2024, Sebastian Huber wrote:
> On 07.08.23 16:22, Qing Zhao via Gcc-patches wrote:
> > Hi,
> >
> > This is the 2nd version of the patch.
> > Comparing to the 1st version, the only change is to address Richard's
> > comment on refering a warning option for diagnosing deprecated
t; causes all sorts of problems with the Fortran frontend. */
> > > if (TREE_CODE (type1) == ARRAY_TYPE
> > > && TREE_CODE (type2) == ARRAY_TYPE)
> > > return -1;
> > > ...
> > > and later compares alias sets and the like.
> > > So
> Am 03.05.2024 um 20:37 schrieb Martin Uecker :
>
> Am Freitag, dem 03.05.2024 um 20:18 +0200 schrieb Jakub Jelinek:
>>> On Fri, May 03, 2024 at 08:04:18PM +0200, Martin Uecker wrote:
>>> A change that is not optimal but would avoid a lot of trouble is to
>>> only use the tag of the struct
> Am 03.05.2024 um 17:33 schrieb Martin Uecker :
>
> Am Freitag, dem 03.05.2024 um 14:13 +0200 schrieb Richard Biener:
>> TYPE_STRUCTURAL_EQUALITY_P is part of our type system so we have
>> to make sure to include that into the type unification done via
>> type
TYPE_STRUCTURAL_EQUALITY_P is part of our type system so we have
to make sure to include that into the type unification done via
type_hash_canon. This requires the flag to be set before querying
the hash which is the biggest part of the patch.
Bootstrapped and tested on x86_64-unknown-linux-gnu
On Thu, May 2, 2024 at 11:40 PM Andrew Pinski wrote:
>
> When we have :
> `void f (int y, int z) { int x = ( z++,y); }`
>
> This would have printed the decl's initializer without
> parentheses which can confusion if you think that is defining
> another variable rather than the compound
On Thu, May 2, 2024 at 11:40 PM Andrew Pinski wrote:
>
> Right now we don't print that a DECL_EXPR and we get
> basically double output of the decls and it looks confusing.
> This fixes that.
> for the simple example:
> `void foo () { int result = 0;}`
> This gives:
> ```
> {
> int result = 0;
On Thu, May 2, 2024 at 11:40 PM Andrew Pinski wrote:
>
> Starting with the merge of the openmp branch into the trunk
> (r0-73077-g953ff28998b59b), COMPOUND_EXPR started to be printed
> as `expr; , expr` which is wrong. This was due to the wrong
> conversion of dumping_stmts into `!(flags &
The following adds a check that the global bitmap obstack is initialized
when allocating a bitmap from it.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* bitmap.cc (bitmap_alloc): When using the global bitmap obstack
assert that is initialized.
---
gcc/bitmap.cc
On Fri, May 3, 2024 at 10:03 AM Peter Damianov wrote:
>
> libgcc/
> * libgcov-util.c (tag_counters): Swap order of arguments to xcalloc.
> (topen_to_memory_representation): Likewise.
Thanks, I pushed this for you.
Richard.
> Signed-off-by: Peter Damianov
> ---
>
On Fri, May 3, 2024 at 12:55 PM Jonathan Wakely wrote:
>
> On Fri, 3 May 2024 at 11:51, Jonathan Wakely wrote:
> >
> > On Fri, 3 May 2024 at 10:30, Andreas Schwab wrote:
> > >
> > > * config/abi/post/powerpc-linux-gnu/baseline_symbols.txt: Update.
> > > *
When building a type and type_hash_canon returns an existing type
avoid changing it, in particular its TYPE_CANONICAL.
Bootstrapped and tested on x86_64-unknown-linux-gnu for all languages.
OK for trunk?
Thanks,
Richard.
PR middle-end/114931
* tree.cc (build_array_type_1):
On Thu, May 2, 2024 at 3:48 PM Roger Sayle wrote:
>
>
> > From: Richard Biener
> > On Thu, May 2, 2024 at 11:34 AM Roger Sayle
> > wrote:
> > >
> > >
> > > > From: Richard Biener On Fri, Apr 26,
> > > > 2024 at 10:19 AM Roger
times "__builtin_stack_restore \\\(" 3
> "einline" } } */
> +
> +void baz (char *p, int n);
> +volatile int v;
> +
> +static inline __attribute__((always_inline)) void
> +foo (int n)
> +{
> + ++v;
> + {
> +char *p = __builtin_alloca (n);
> +baz (p, n);
> + }
> + ++v;
> +}
> +
> +static inline __attribute__((always_inline)) void
> +bar (int n)
> +{
> + ++v;
> + {
> +char p[n];
> +baz (p, n);
> + }
> + ++v;
> +}
> +
> +void
> +qux (int n)
> +{
> + foo (n);
> + bar (n);
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
On Fri, 3 May 2024, Richard Ball wrote:
> Hi,
>
> Requesting permission to backport:
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=24cf1f600b8ad34c68a51f48884e72d01f729893
> to gcc-13 in order to fix:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111882
>
> Applies cleanly and with no
tion/114924
> * cfgrtl.cc (duplicate_insn_chain): When updating MEM_EXPRs,
> don't strip (e.g.) ARRAY_REFs from the final MEM_EXPR.
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
On Thu, 2 May 2024, Manolis Tsamis wrote:
> On Thu, May 2, 2024 at 4:00 PM Richard Biener wrote:
> >
> > On Tue, 23 Apr 2024, Manolis Tsamis wrote:
> >
> > > The original motivation for this pattern was that the following function
> > > does
> > >
The vectorizer handles a _Float16 to __bf16 conversion through
vectorizable_assignment, thinking it's a noop. The following
fixes this by requiring the same vector component mode when
checking for CONVERT_EXPR_CODE_P, being stricter than for
VIEW_CONVERT_EXPR.
This variant splits the check for
The following notes which lanes are considered live and adds an overload
to produce a graphviz graph for multiple entries into an SLP graph.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
* tree-vect-slp.cc (vect_print_slp_tree): Mark live lanes.
(dot_slp_tree):
,16 @@
> +/* PR tree-optimization/109393 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-optimized" } */
> +/* { dg-final { scan-tree-dump-times "return 1;" 2 "optimized" } } */
> +
> +int foo(int *a, int j)
> +{
> + int k = j - 1;
> + return a[j - 1] == a[k];
> +}
> +
> +int bar(int *a, int j)
> +{
> + int k = j - 1;
> + return ([j + 1] - 2) == [k];
> +}
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
and gcc-13.
I'm fine with backporting if you have bootstrapped/tested them.
Richard.
> Thanks,
> Richard
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
The vectorizer handles a _Float16 to __bf16 conversion through
vectorizable_assignment, thinking it's a noop. The following
fixes this by making the same-size check stricter, requiring
the same vector component mode.
Posted again for the arm CI
PR tree-optimization/114921
*
On Thu, 2 May 2024, Richard Biener wrote:
> The vectorizer handles a _Float16 to __bf16 conversion through
> vectorizable_assignment, thinking it's a noop. The following
> fixes this by making the same-size check stricter, requiring
> the same vector component mode.
>
> B
The vectorizer handles a _Float16 to __bf16 conversion through
vectorizable_assignment, thinking it's a noop. The following
fixes this by making the same-size check stricter, requiring
the same vector component mode.
Bootstrap & regtest running on x86_64-unknown-linux-gnu. I couldn't
manage to
On Mon, Apr 29, 2024 at 1:48 AM Peter Damianov wrote:
>
> Signed-off-by: Peter Damianov
> ---
>
> Fixes these warnings:
>
> ../../gcc/gcc/../libgcc/libgcov-util.c: In function 'void
> tag_counters(unsigned int, int)':
> ../../gcc/gcc/../libgcc/libgcov-util.c:214:59: warning: 'void*
On Thu, May 2, 2024 at 11:34 AM Roger Sayle wrote:
>
>
> > From: Richard Biener
> > On Fri, Apr 26, 2024 at 10:19 AM Roger Sayle
> > wrote:
> > >
> > > This patch addresses PR middle-end/111701 where optimization of
> > > signbit(x
in c_parser_sizeof_expression (parser= > out>)
> > > at ../../gcc/gcc/c/c-parser.cc:9932
> > >
> > >
> > > I hope this explains what's happening. The size_binop_loc call is a
> > > bit of a red herring that returns the same tree it is give
On Mon, Apr 29, 2024 at 1:27 AM Peter0x44 wrote:
>
> 29 Apr 2024 12:16:26 am Peter Damianov :
>
> > This commit adds a new option to the driver that truncates one file
> > after
> > linking.
> >
> > Tested likeso:
> >
> > $ gcc hello.c -c
> > $ du -h hello.o
> > 4.0K hello.o
> > $ gcc hello.o
On Sun, Apr 28, 2024 at 11:11 AM Roger Sayle wrote:
>
>
> This patch fixes PR tree-optimization/113673, a P2 ice-on-valid regression
> caused by load merging of (ptr[0]<<8)+ptr[1] when -ftrapv has been
> specified. When the operator is | or ^ this is safe, but for addition
> of signed integer
On Sun, Apr 28, 2024 at 7:53 AM liuhongt wrote:
>
> The Intel Decimal Floating-Point Math Library is available as open-source on
> Netlib[1].
>
> [1] https://www.netlib.org/misc/intel/.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk?
OK for trunk.
Thanks,
Richard.
On Fri, Apr 26, 2024 at 10:19 AM Roger Sayle wrote:
>
>
> This patch addresses PR middle-end/111701 where optimization of signbit(x*x)
> using tree_nonnegative_p incorrectly eliminates a floating point
> multiplication when the operands may potentially be signaling NaNs.
>
> The above bug fix
SLP build eventually uses graphds graphs, the following makes its
dump use graphviz format so you can easily visualize it.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* graphds.cc (dump_graph): Dump in graphviz format.
---
gcc/graphds.cc | 17 ++---
1 file
On Tue, Apr 30, 2024 at 9:13 PM Jason Merrill wrote:
>
> On 4/30/24 12:04, Andrew Pinski wrote:
> > On Tue, Apr 30, 2024 at 11:54 AM Jason Merrill wrote:
> >>
> >> On 2/20/24 19:06, Andrew Pinski wrote:
> >>> After r7-987-gf17a223de829cb, the access for the elements of a vector
> >>> type would
On Mon, Apr 29, 2024 at 5:12 PM Joe Ramsay wrote:
>
> This optimisation does not honour signed zeros, so should not be
> enabled except with -fno-signed-zeros.
>
> Cherry-pick of 7dd3b2b09cbeb6712ec680a0445cb0ad41070423.
>
> Applies cleanly on releases/gcc-13, regression-tested with no new
>
ith a TREE_TYPE of error_mark_node.
>
> As Andrew Pinski writes in comment #3, this one is trickier than average.
>
> A more comprehensive fix might be to write deep_error_operand_p which does
> more of a tree traversal checking error_operand_p within the unary and binary
> operators of an ex
r = bar()
> + u = 1
> + do i = 1,a
> +do k = 1,1011
> + km1 = max0(k-1,1)
> + h(k) = c(k) * e(k-1) * d(km1)
> + f = g(k) + h(k)
> + if(f.gt.1.e-6)then
> +p = max(p,r)
> + endif
> +end do
> +q = 0.9_8 * p
> +t = integer(b/
/* { dg-warning "nul past the
> end" } */
>
>/* The following could result in as few as no bytes and in as many as
> MB_CUR_MAX, but since the MB_CUR_MAX value is a runtime property
> @@ -1550,7 +1550,7 @@ void test_snprintf_c_const (char *d)
>
>/* Wide
On Sun, Apr 28, 2024 at 8:31 AM Andrew Pinski wrote:
>
> I noticed that single_non_singleton_phi_for_edges could
> return a phi whos entry are all the same for the edge.
> This happens only if there was a single phis in the first place.
> Also gimple_seq_singleton_p walks the sequence to see if
On Sun, Apr 28, 2024 at 8:31 AM Andrew Pinski wrote:
>
> This adds a few early outs to value_replacement that I noticed
> while rewriting this to use match-and-simplify but could be committed
> seperately.
> * virtual operands won't change so return early for them
> * special case `A ? B : B` as
On Sat, Apr 27, 2024 at 1:04 AM Andrew Pinski wrote:
>
> When cfgexpand was changed to support expanding from tuple gimple
> (r0-95521-g28ed065ef9f345), the code was added to support
> doing nontemporal stores with LHS of a SSA_NAME but that will
> never be a nontemporal store.
> This patch
On Sat, Apr 27, 2024 at 1:04 AM Andrew Pinski wrote:
>
> Currently the middle-end only knows how to support temporal stores
> (the undocumented storent optab) so let's verify that the only time
> we set nontemporal_move on an assign is if the the lhs is not a
> gimple reg.
>
> Bootstrapped and
On Fri, Apr 19, 2024 at 11:49 AM Arthur Cohen wrote:
>
> Hi everyone,
>
> This patch checks for the presence of dlopen and pthread_create in libc. If
> that is not the
> case, we check for the existence of -ldl and -lpthread, as these libraries
> are required to
> link the Rust runtime to our
On Sun, Apr 28, 2024 at 9:07 PM Aldy Hernandez wrote:
>
> Fix some Value_Range's that we know ahead of time will be only
> integers. This avoids using the polymorphic Value_Range unnecessarily
But isn't Value_Range a variable-size irange but int_range<2> doesn't
support more than two
On Sun, Apr 28, 2024 at 10:24 AM Alexandre Oliva wrote:
>
>
> The fact that both options accept negative forms suggests that maybe
> they aren't negative forms of each other. They are, but that isn't
> clear even by examining common.opt. Use NegativeAlias to make it
> abundantly clear.
>
> The
On Tue, Apr 30, 2024 at 1:06 AM Roger Sayle wrote:
>
>
> This patch solves another ICE-after-error problem in the C family
> front-ends. Upon a conflicting type redeclaration, the ambiguous
> type is poisoned with an error_mark_node to indicate to the middle-end
> that the type is suspect, but
On Mon, Apr 29, 2024 at 5:30 PM H.J. Lu wrote:
>
> On Mon, Apr 29, 2024 at 6:47 AM liuhongt wrote:
> >
> > The Fortran standard does not specify what the result of the MAX
> > and MIN intrinsics are if one of the arguments is a NaN. So it
> > should be ok to tranform reduction for IFN_COND_MIN
On Mon, Apr 29, 2024 at 8:52 AM Andrew Pinski wrote:
>
> While moving value replacement part of PHIOPT over
> to use match-and-simplify, I ran into the case where
> we would have an undef use that was conditional become
> unconditional. This prevents that. I can't remember at this
> point what
When expand_call_mem_ref looks at the definition of the address
argument to eventually expand a _MEM_REF argument together
with a masked load it fails to honor constraints imposed by SSA
coalescing decisions. The following fixes this.
Boostrap and regtest running on x86_64-unknown-linux-gnu.
> Am 25.04.2024 um 20:24 schrieb Jakub Jelinek :
>
> Hi!
>
> glibc 2.34 and later doesn't have separate libpthread (libpthread.so.0 is a
> dummy shared library with just some symbol versions for compatibility, but
> all the pthread_* APIs are in libc.so.6).
> So, we don't need to do the
> 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 is
> that maintainers ar
When we use unloop_loops we have to make sure to have loops ordered
inner to outer as otherwise we can wreck inner loop structure where
unlooping relies on that being intact. The following re-sorts the
vector of to unloop loops after copy-header as that adds to the
vector in two places and the
When CFG cleanup removes a backedge we have to be more careful with
loop update. In particular we need to clear niter info and estimates
and if we remove the last backedge of a loop we have to also mark
it for removal to prevent a following basic block merging to associate
loop info with an
When we update the dominator of the redirected exit after peeling
we check whether the immediate dominator was the loop header rather
than the exit source when we later want to just update it to the
new source. The following fixes this oversight.
Bootstrap and regtest running on
The following plugs a hole with computing whether a SLP node has any
pattern stmts which is important to know when we want to replace it
by a CTOR from external defs.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/114799
* tree-vect-slp.cc
On Mon, Apr 22, 2024 at 12:05 PM Alexandre Oliva wrote:
>
> Ping?-ish for the full version of the RFC posted at
> https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566588.html
>
> On Mar 11, 2021, Richard Biener wrote:
>
> > On Thu, Mar 11, 2021 at 9:03 AM Alexandre
1 - 100 of 25170 matches
Mail list logo
