https://gcc.gnu.org/g:7c469a9fc785505dc350aba60311812c2bb0c1b5
commit r15-204-g7c469a9fc785505dc350aba60311812c2bb0c1b5
Author: Richard Biener
Date: Wed Feb 28 10:08:31 2024 +0100
tree-optimization/100923 - re-do VN with contextual PTA info fix
The following implements the gist
https://gcc.gnu.org/g:8bdfb0c2d5a13a4fb846cde291decff06e4b753c
commit r15-203-g8bdfb0c2d5a13a4fb846cde291decff06e4b753c
Author: Richard Biener
Date: Tue Feb 27 13:55:15 2024 +0100
Complete ao_ref_init_from_vn_reference for all refs
This makes sure we can create ao_refs from all
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
https://gcc.gnu.org/g:db447ec808e997bd13a849d9b3076792afb888cb
commit r14-10164-gdb447ec808e997bd13a849d9b3076792afb888cb
Author: Richard Biener
Date: Fri May 3 16:03:14 2024 +0200
Revert "tree-optimization/114921 - _Float16 -> __bf16 isn't noop"
This r
https://gcc.gnu.org/g:0624852a3ea684f6b9dabea864bcb45e31304728
commit r13-8683-g0624852a3ea684f6b9dabea864bcb45e31304728
Author: Richard Biener
Date: Tue Apr 16 11:33:48 2024 +0200
tree-optimization/114736 - SLP DFS walk issue
The following fixes a DFS walk issue when identifying
https://gcc.gnu.org/g:704b15e277a8792ac4cd6008ee08bec4b047a3e6
commit r13-8684-g704b15e277a8792ac4cd6008ee08bec4b047a3e6
Author: Richard Biener
Date: Wed Apr 17 10:40:04 2024 +0200
tree-optimization/114749 - reset partial vector decision for no-SLP retry
The following makes sure
https://gcc.gnu.org/g:d040606257a579f120271dcd2af62a3458a7856e
commit r13-8681-gd040606257a579f120271dcd2af62a3458a7856e
Author: Richard Biener
Date: Tue Apr 9 14:25:57 2024 +0200
lto/114655 - -flto=4 at link time doesn't override -flto=auto at compile
time
The following adjusts
https://gcc.gnu.org/g:5a3cc62dbb45185dd1ca32caec80d57a320ec5a0
commit r13-8682-g5a3cc62dbb45185dd1ca32caec80d57a320ec5a0
Author: Richard Biener
Date: Mon Apr 15 11:09:17 2024 +0200
gcov-profile/114715 - missing coverage for switch
The following avoids missing coverage
https://gcc.gnu.org/g:b3f9f10e03c570074a517dcfe9df8d3eeddd6aca
commit r13-8680-gb3f9f10e03c570074a517dcfe9df8d3eeddd6aca
Author: Richard Biener
Date: Tue Apr 16 10:46:03 2024 +0200
tree-optimization/114733 - neg induction fails for 1 element vectors
The neg induction
https://gcc.gnu.org/g:a676581ddc49a6ead8edced7bb4b92aeceebde56
commit r13-8679-ga676581ddc49a6ead8edced7bb4b92aeceebde56
Author: Richard Biener
Date: Thu Apr 4 10:00:51 2024 +0200
tree-optimization/114485 - neg induction with partial vectors
We can't use
https://gcc.gnu.org/g:796319476e4fd6813e8319061bc3a8f19b355e35
commit r14-10162-g796319476e4fd6813e8319061bc3a8f19b355e35
Author: Patrick O'Neill
Date: Tue Apr 30 13:26:45 2024 -0700
RISC-V: Add testcase for pr114734
gcc/testsuite/ChangeLog:
PR middle-end/114734
https://gcc.gnu.org/g:5c42872b2a08a742f061809c7650e0c62dd7a9f3
commit r14-10161-g5c42872b2a08a742f061809c7650e0c62dd7a9f3
Author: Richard Biener
Date: Fri Apr 26 15:47:13 2024 +0200
middle-end/114734 - wrong code with expand_call_mem_ref
When expand_call_mem_ref looks
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 &
https://gcc.gnu.org/g:a2e9032deaf9dbcff329d650f61e36c6a5aa1fc4
commit r15-130-ga2e9032deaf9dbcff329d650f61e36c6a5aa1fc4
Author: Richard Biener
Date: Fri Apr 5 11:02:46 2024 +0200
Add default bitmap obstack allocation check
The following adds a check that the global bitmap obstack
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
> ---
>
https://gcc.gnu.org/g:c5245c869f0468ddb67c6d996219bd443610673c
commit r15-129-gc5245c869f0468ddb67c6d996219bd443610673c
Author: Peter Damianov
Date: Fri May 3 01:02:35 2024 -0700
Silence two instances of -Wcalloc-transposed-args
libgcc/
* libgcov-util.c
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.
> > > *
https://gcc.gnu.org/g:7a212ac678e13e0df5da2d090144b246a1262b64
commit r15-127-g7a212ac678e13e0df5da2d090144b246a1262b64
Author: Richard Biener
Date: Fri May 3 11:48:07 2024 +0200
Avoid changing type in the type_hash_canon hash
When building a type and type_hash_canon returns
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)
https://gcc.gnu.org/g:fa7e05d90bb672b58424ddbe37a05a0fd0949b35
commit r14-10159-gfa7e05d90bb672b58424ddbe37a05a0fd0949b35
Author: Richard Biener
Date: Thu May 2 13:55:15 2024 +0200
tree-optimization/114921 - _Float16 -> __bf16 isn't noop
The vectorizer handles a _Floa
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
https://gcc.gnu.org/g:87e35da16df74cd1c4729a55d94e7bc592487f48
commit r15-124-g87e35da16df74cd1c4729a55d94e7bc592487f48
Author: Richard Biener
Date: Thu May 2 13:55:15 2024 +0200
tree-optimization/114921 - _Float16 -> __bf16 isn't noop
The vectorizer handles a _Float16 to __b
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)
https://gcc.gnu.org/g:bf33fe90e75c2c463d77f83d9a44dc61abe087f5
commit r15-112-gbf33fe90e75c2c463d77f83d9a44dc61abe087f5
Author: Richard Biener
Date: Wed Mar 27 10:53:11 2024 +0100
Improve SLP dump and graph
The following notes which lanes are considered live and adds an overload
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*
https://gcc.gnu.org/g:a704554d2e798e2e1b74b9fea4baf3477180bd9d
commit r15-108-ga704554d2e798e2e1b74b9fea4baf3477180bd9d
Author: Peter Damianov
Date: Sun Apr 28 16:16:12 2024 -0700
lto-wrapper: Truncate files using -truncate driver option [PR110710]
This commit changes the
https://gcc.gnu.org/g:985b5a90f70c7376c771317c6c8c3bc5ef05e227
commit r15-107-g985b5a90f70c7376c771317c6c8c3bc5ef05e227
Author: Peter Damianov
Date: Sun Apr 28 16:16:11 2024 -0700
Driver: Add new -truncate option
This commit adds a new option to the driver that truncates one file
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
https://gcc.gnu.org/g:c59708fba3f98a4cc257741b88216b6caf6b4a87
commit r15-104-gc59708fba3f98a4cc257741b88216b6caf6b4a87
Author: Richard Biener
Date: Tue Apr 30 13:01:43 2024 +0200
Make graph dumps use graphviz format
SLP build eventually uses graphds graphs, the following makes
https://gcc.gnu.org/g:5176402d6fdbf131d176b5f43ac6449c1bda072b
commit r15-103-g5176402d6fdbf131d176b5f43ac6449c1bda072b
Author: Richard Biener
Date: Tue Apr 9 11:28:47 2024 +0200
Remove live-info global bitmap
The following removes the unused tree_live_info_d->global bit
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 Wed, May 1, 2024 at 11:41 PM Jeff Law via Gcc wrote:
>
>
>
> On 5/1/24 2:04 PM, Jason Merrill wrote:
> > On 5/1/24 12:15, Jeff Law wrote:
> >>
> >>
> >> On 4/22/24 9:24 PM, Tom Tromey wrote:
> >>> Jason> Someone mentioned earlier that gerrit was previously tried
> >>> Jason> unsuccessfully.
>
https://gcc.gnu.org/g:bbe83599320288025a417c54d9afcb3885cb2766
commit r15-99-gbbe83599320288025a417c54d9afcb3885cb2766
Author: Richard Biener
Date: Thu Apr 4 14:00:10 2024 +0200
middle-end/114579 - speed up add_scope_conflicts
The following speeds up stack variable conflict
> Am 30.04.2024 um 21:11 schrieb Jason Merrill via Gcc :
>
> On Fri, Apr 26, 2024 at 5:44 AM Aldy Hernandez via Gcc
> wrote:
>>
>> In implementing prange (pointer ranges), I have found a 1.74% slowdown
>> in VRP, even without any code path actually using the code. I have
>> tracked this
https://gcc.gnu.org/g:ab785f9a3901ca29710592a2d5480b5a44328bf2
commit r15-68-gab785f9a3901ca29710592a2d5480b5a44328bf2
Author: Richard Biener
Date: Wed Apr 17 11:22:00 2024 +0200
Support {CEIL,FLOOR,ROUND}_{DIV,MOD}_EXPR and EXACT_DIV_EXPR in GIMPLE FE
The following adds support
https://gcc.gnu.org/g:667c19de86b33648f5f4599f589a5e02adbb35cb
commit r15-67-g667c19de86b33648f5f4599f589a5e02adbb35cb
Author: Richard Biener
Date: Tue Apr 16 14:05:35 2024 +0200
middle-end/13421 - -ftrapv vs. POINTER_DIFF_EXPR
Currently we expand POINTER_DIFF_EXPR using
On Tue, Apr 30, 2024 at 11:45 AM Jørgen Kvalsvik wrote:
>
> Hi,
>
> I am working on adding path coverage support to gcc/gcov and need to
> develop a good testing strategy.
>
> So far I can reasonably well report on the uncovered path as such:
>
> paths covered 6 of 17
> path not covered: 2 8 3 4
https://gcc.gnu.org/g:e8482b86ef5641b1e0041f2712011b9389ac1e40
commit r12-10404-ge8482b86ef5641b1e0041f2712011b9389ac1e40
Author: Joe Ramsay
Date: Fri Mar 15 09:20:45 2024 +
match.pd: Only merge truncation with conversion for -fno-signed-zeros
This optimisation does not
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
>
https://gcc.gnu.org/g:13bf9232fc1ec2cb7be85b628a6f2d5ed15510d9
commit r13-8664-g13bf9232fc1ec2cb7be85b628a6f2d5ed15510d9
Author: Joe Ramsay
Date: Fri Mar 15 09:20:45 2024 +
match.pd: Only merge truncation with conversion for -fno-signed-zeros
This optimisation does not honour
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
https://gcc.gnu.org/g:440a612dbadfae5887ec7c9b3ab2fca88b065366
commit r13-8662-g440a612dbadfae5887ec7c9b3ab2fca88b065366
Author: Richard Biener
Date: Thu Sep 28 11:51:30 2023 +0200
target/111600 - avoid deep recursion in access diagnostics
pass_waccess::check_dangling_stores uses
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 26, 2024 at 11:45 AM Aldy Hernandez via Gcc wrote:
>
> Hi folks!
>
> In implementing prange (pointer ranges), I have found a 1.74% slowdown
> in VRP, even without any code path actually using the code. I have
> tracked this down to irange::get_bitmask() being compiled differently
>
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 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
https://gcc.gnu.org/g:4d3a5618de5a949c61605f545f90e81bc502
commit r15-60-g4d3a5618de5a949c61605f545f90e81bc502
Author: Richard Biener
Date: Fri Apr 26 15:47:13 2024 +0200
middle-end/114734 - wrong code with expand_call_mem_ref
When expand_call_mem_ref looks
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
https://gcc.gnu.org/g:59ff81835fee22a9d4c9a481a4d1814583aae945
commit r14-10120-g59ff81835fee22a9d4c9a481a4d1814583aae945
Author: Richard Biener
Date: Thu Apr 25 08:08:24 2024 +0200
tree-optimization/114792 - order loops to unloops in CH
When we use unloop_loops we have to make
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
https://gcc.gnu.org/g:cc48418cfc2e555d837ae9138cbfac23acb3cdf9
commit r14-10106-gcc48418cfc2e555d837ae9138cbfac23acb3cdf9
Author: Richard Biener
Date: Wed Apr 24 08:42:40 2024 +0200
tree-optimization/114787 - more careful loop update with CFG cleanup
When CFG cleanup removes
https://gcc.gnu.org/g:e28e8ab1a92e9b49f7c4045377577c8dc17751b7
commit r14-10105-ge28e8ab1a92e9b49f7c4045377577c8dc17751b7
Author: Richard Biener
Date: Wed Apr 24 06:24:22 2024 +0200
tree-optimization/114832 - wrong dominator info with vect peeling
When we update the dominator
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
https://gcc.gnu.org/g:18e8e55487238237f37f621668fdee316624981a
commit r14-10088-g18e8e55487238237f37f621668fdee316624981a
Author: Richard Biener
Date: Tue Apr 23 08:39:03 2024 +0200
tree-optimization/114799 - SLP and patterns
The following plugs a hole with computing whether
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
601 - 700 of 28319 matches
Mail list logo
