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
On Mon, Apr 22, 2024 at 10:47 AM Andreas Krebbel wrote:
>
> Hi Stefan,
>
> due to that missed optimization we currently generate silly code for these
> two tests and should
> really fix this (after gcc entering stage1). So just skipping it on s390x
> would definitely be the
> wrong choice I
On Sun, Apr 21, 2024 at 11:06 PM James K. Lowden
wrote:
>
> I have two simple questions, I hope!
>
> 1. Is there a set of flags that, when compiling gcc, is meant to
> produce no warnings? I get a surfeit of warnings with my particular
> favorite options.
-w is supposed to do that
> 2. Are
On Fri, Apr 19, 2024 at 3:29 PM Tamar Christina wrote:
>
> Hi All,
>
> As the reporter in PR114769 points out the control flow for the abd detection
> is hard to follow. This is because vect_recog_absolute_difference has two
> different ways it can return true.
>
> 1. It can return true when the
024-04-18 15:43:30.389730365 +0200
> @@ -0,0 +1,10 @@
> +/* PR rtl-optimization/114768 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-rtl-final" } */
> +/* { dg-final { scan-rtl-dump "\\\(mem/v:" "final" { target { ! { nvptx*-*-*
> } } } } } */
> +
> +void
> +foo (int *p)
> +{
> + *p = *(volatile int *) p;
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
ive_tests } { "-flto" } { "" } } */
> +
> +#if __BITINT_MAXWIDTH__ >= 255
> +__attribute__((__noipa__)) signed _BitInt(255)
> +foo (signed _BitInt(255) a, signed _BitInt(65) b)
> +{
> + return a / b;
> +}
> +#endif
> +
> +int
> +main ()
> +{
> +#if __BITINT_MAXWIDTH__ >= 255
> + if (foo (1, -0xwb - 1wb))
> +__builtin_abort ();
> +#endif
> +}
>
> 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 Thu, Apr 18, 2024 at 6:34 PM Jonathan Wakely wrote:
>
> This would fix the but, how do people feel about it this close to the
> gcc-14 release?
Guess we'll have to fix it anyway, so why not now ... (what could go wrong..)
Richard.
> Tested x86_64-linux.
>
> -- >8 --
>
> Since 2022 the TZif
21448 +0200
> +++ gcc/testsuite/gcc.dg/torture/bitint-69.c 2024-04-17 19:10:25.343814139
> +0200
> @@ -0,0 +1,26 @@
> +/* PR libgcc/114755 */
> +/* { dg-do run { target bitint } } */
> +/* { dg-options "-std=c23" } */
> +/* { dg-skip-if "" { ! run_expensiv
alse, NULL);
> + flag_trapv = save_flag_trapv;
> return;
> }
>
> --- gcc/testsuite/gcc.dg/pr114753.c.jj2024-04-17 13:55:16.246482369
> +0200
> +++ gcc/testsuite/gcc.dg/pr114753.c 2024-04-17 13:54:14.035352376 +0200
> @@ -0,0 +1,14 @@
> +/
On Thu, Apr 18, 2024 at 6:12 AM Peter Damianov wrote:
>
> This commit changes the Makefiles generated by lto-wrapper to no longer use
> the "mv" and "touch" shell commands. These don't exist on Windows, so when the
> Makefile attempts to call them, it results in errors like:
> The system cannot
On Thu, Apr 18, 2024 at 6:12 AM Peter Damianov wrote:
>
> 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 -truncate hello
> $ ./a.out
> Hello world
> $ du -h hello.o
> $
On Wed, Apr 17, 2024 at 1:17 PM Jakub Jelinek wrote:
>
> Hi!
>
> Starting with GCC 14 we have the nice URLification of the options printed
> in diagnostics, say for in
> test.c:4:23: warning: format ‘%d’ expects argument of type ‘int’, but
> argument 2 has type ‘long int’ [-Wformat=]
> the
The following adds support for the various division and modulo operators
to the GIMPLE frontend via __{CEIL,FLOOR,ROUND}_{DIV,MOD} and
__EXACT_DIV operators.
Bootstrapped and tested on x86_64-unknown-linux-gnu, queued for stage1.
Richard.
gcc/c/
* gimple-parser.cc
https://gcc.gnu.org/g:bf2b5231312e1cea45732cb8df6ffa2b2c9115b6
commit r14-10005-gbf2b5231312e1cea45732cb8df6ffa2b2c9115b6
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
The following makes sure to reset LOOP_VINFO_USING_PARTIAL_VECTORS_P
to its default of false when re-trying without SLP as otherwise
analysis may run into bogus asserts.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
PR tree-optimization/114749
*
> +
> +void
> +freddy (int x, int *y, struct S *p)
> +{
> + bar (*p);
> + ++p;
> + if (x == 25)
> +x = foo (2);
> + else if (x == 42)
> +x = foo (foo (3));
> + *y = bar (*p);
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
Currently we expand POINTER_DIFF_EXPR using subv_optab when -ftrapv
(but -fsanitize=undefined does nothing). That's not consistent
with the behavior of POINTER_PLUS_EXPR which never uses addv_optab
with -ftrapv. Both are because of the way we select whether to use
the trapping or the
https://gcc.gnu.org/g:f949481a1f7ab973608a4ffcc0e342ab5a74e8e4
commit r14-9993-gf949481a1f7ab973608a4ffcc0e342ab5a74e8e4
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:45a41ace55d0ffb1097e374868242329788ec82a
commit r14-9992-g45a41ace55d0ffb1097e374868242329788ec82a
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
The following fixes a DFS walk issue when identifying to be ignored
latch edges. We have (bogus) SLP_TREE_REPRESENTATIVEs for VEC_PERM
nodes so those have to be explicitly ignored as possibly being PHIs.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
Richard.
PR
The neg induction vectorization code isn't prepared to deal with
single element vectors.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
Richard.
PR tree-optimization/114733
* tree-vect-loop.cc (vectorizable_nonlinear_induction): Reject
neg induction
t;
> -/* For T being aggregate type try to turn it into a incomplete variant.
> +/* For T being aggregate type try to turn it into an incomplete variant.
> Return T if no simplification is possible. */
>
> static tree
>
> 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 Tue, Apr 16, 2024 at 5:43 AM Alexandre Oliva wrote:
>
>
> Fix another test that uses -fPIC without requiring fpic support.
>
> Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
> aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
OK.
> PS: This is neither the first nor
On Tue, Apr 16, 2024 at 5:31 AM Alexandre Oliva wrote:
>
>
> pr103798-2.c fails in C++ on targets that provide a ISO C++-compliant
> declaration of memchr, because it mismatches the C-compatible builtin,
> as per PR113706. Expect the C++ test to fail on vxworks as well.
>
> Regstrapped on
On Tue, Apr 16, 2024 at 5:29 AM Alexandre Oliva wrote:
>
>
> Test that calls select fails on vxworks because select is only
> declared in sys/select.h. Include that header if it's present.
>
> Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
> aarch64-, x86- and
On Tue, Apr 16, 2024 at 5:27 AM Alexandre Oliva wrote:
>
>
> Mark tests that fail due to the lack of fork, as in vxworks kernel
> mode, as requiring fork.
>
> Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
> aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
>
OK
> for
On Tue, Apr 16, 2024 at 5:25 AM Alexandre Oliva wrote:
>
>
> Define macro that prevents mode_t from being defined by vxworks'
> headers as well.
>
> Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
> aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
OK
>
> for
On Tue, Apr 16, 2024 at 5:26 AM Alexandre Oliva wrote:
>
>
> O_ACCMODE is not defined on vxworks, and the test is meaningless and
> failing without it, so skip it.
>
> Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
> aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
OK
>
On Tue, Apr 16, 2024 at 5:23 AM Alexandre Oliva wrote:
>
>
> A number of tests that call strndup fail on vxworks, where there's no
> strndup. Some of them already had workarounds to skip the strndup
> parts of the tests on platforms that don't offer it. I've changed
> them to rely on a strndup
On Tue, Apr 16, 2024 at 2:26 AM Andrew Pinski wrote:
>
> This just adds a clause to make it more obvious that the vector_size
> attribute extension works with typedefs.
> Note this whole section needs a rewrite to be a similar format as other
> extensions. But that is for another day.
>
> OK?
OK
get { ! ilp32 }
> } } } */
>
> #include "tree-vect.h"
>
> -typedef unsigned long PV;
> +typedef unsigned long long PV;
> typedef struct _buff_t {
> int foo;
> PV Val;
>
>
>
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
d
> + GCC supports a new pragma pragma GCC novector to
> + indicate to the vectorizer not to vectorize the loop annotated with the
> + pragma.
>
>
> Runtime Library (libstdc++)
>
>
>
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
On Mon, Apr 15, 2024 at 2:35 PM Jørgen Kvalsvik wrote:
>
> Guard the longjmp to not infinitely loop. The longjmp (jump) function is
> called unconditionally to make test flow simpler, but the jump
> destination would return to a point in main that would call longjmp
> again. The longjmp is really
On Mon, Apr 15, 2024 at 12:04 PM Tobias Burnus wrote:
>
> I experimented with some variants to make clearer that each of RDNA2 and
> RNDA3 applies to two card types, but at the end I settled on the
> fewest-word version.
>
> Comments, remarks, suggestions? (To this change or in general?)
>
>
https://gcc.gnu.org/g:9d573f71e80e9f6f4aac912fc8fc128aa2697e3a
commit r14-9971-g9d573f71e80e9f6f4aac912fc8fc128aa2697e3a
Author: Richard Biener
Date: Mon Apr 15 11:09:17 2024 +0200
gcov-profile/114715 - missing coverage for switch
The following avoids missing coverage
On Mon, 15 Apr 2024, Jakub Jelinek wrote:
> On Mon, Apr 15, 2024 at 10:05:58AM +0200, Jakub Jelinek wrote:
> > On Mon, Apr 15, 2024 at 10:02:25AM +0200, Richard Biener wrote:
> > > > Though, haven't managed to reproduce it with -O2 -flto -std=c23
> > > > struct S
The following avoids missing coverage for the line of a switch statement
which happens when gimplification emits a BIND_EXPR wrapping the switch
as that prevents us from setting locations on the containing statements
via annotate_all_with_location. Instead set the location of the GIMPLE
switch
00
> @@ -0,0 +1,8 @@
> +// PR c++/114634
> +// { dg-do compile }
> +
> +template
> +struct A
> +{
> + enum { e __attribute__ ((aligned (16))) }; // { dg-error "alignment may
> not be specified for 'e'" }
> +};
>
> Jakub
>
>
--
Ric
On Mon, 15 Apr 2024, Jakub Jelinek wrote:
> On Mon, Apr 15, 2024 at 09:38:29AM +0200, Jakub Jelinek wrote:
> > I had this spot instrumented to log the different cases (before adding the
> > code to fix up also pointer types in c_update_type_canonical) and the only
> > thing
> > that triggered
On Mon, 15 Apr 2024, Richard Biener wrote:
> On Sun, 14 Apr 2024, H.J. Lu wrote:
>
> > We can't profile indirect calls to IFUNC resolvers nor their callees as
> > it requires TLS which hasn't been set up yet when the dynamic linker is
> > resolving IFUNC symbols.
> &
t; + f3();
> + return bar;
> +}
> +
> +/* { dg-final { scan-tree-dump-not "__gcov_indirect_call_profiler_v"
> "optimized" } } */
> diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
> index da300d5f9e8..b5de0fb914f 100644
> --- a/gcc/tree-profile.cc
> +++ b/gcc/tree-profile.cc
> @@ -418,7 +418,13 @@ gimple_gen_ic_func_profiler (void)
>gcall *stmt1;
>tree tree_uid, cur_func, void0;
>
> - if (c_node->only_called_directly_p ())
> + /* Disable indirect call profiling for an IFUNC resolver and its
> + callees since it requires TLS which hasn't been set up yet when
> + the dynamic linker is resolving IFUNC symbols. See
> + https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114115
> + */
> + if (c_node->only_called_directly_p ()
> + || c_node->called_by_ifunc_resolver)
> return;
>
>gimple_init_gcov_profiler ();
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
@@
> +/* PR c/114361 */
> +/* { dg-do compile } */
> +/* { dg-options "-std=gnu23 -g" } */
> +
> +void f()
> +{
> +typedef struct foo bar;
> +typedef __typeof( ({ (struct foo { bar *x; }){ }; }) ) wuz;
> +struct foo { wuz *x; };
> +}
> +
> d
iltin_memcmp (buffer+i, (char*)[i].Val, store_size))
> + __builtin_abort ();
> +
> + return 0;
> +}
> +
> diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
> index
> 4375ebdcb493a90fd0501cbb4b07466077b525c3..024a24a305c4727f97eb022247f4dca791c52dfe
> 100644
> --- a/gcc/tree-vect-loop.cc
> +++ b/gcc/tree-vect-loop.cc
> @@ -12144,6 +12144,12 @@ vect_transform_loop (loop_vec_info loop_vinfo,
> gimple *loop_vectorized_call)
> -min_epilogue_iters to remove iterations that cannot be performed
> by the vector code. */
>int bias_for_lowest = 1 - min_epilogue_iters;
> + /* For an early break we must always assume that the vector loop can be
> + executed partially. In this definition a partial iteration means that
> we
> + take an exit before the IV exit. */
> + if (LOOP_VINFO_EARLY_BREAKS (loop_vinfo))
> +bias_for_lowest = 1;
> +
>int bias_for_assumed = bias_for_lowest;
>int alignment_npeels = LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo);
>if (alignment_npeels && LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo))
>
>
>
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
> Am 12.04.2024 um 09:58 schrieb Jakub Jelinek :
>
> Hi!
>
> While translation of the verifier messages is questionable, that case is
> something that ideally should never happen except to gcc developers
> and so pressumably English should be fine, we use error etc. APIs and
> those imply
> Am 12.04.2024 um 09:50 schrieb Jakub Jelinek :
>
> Hi!
>
> The tree-cfg.cc verifier only diagnoses returns_twice calls preceded
> by non-label/debug stmts if it is in a bb with abnormal predecessor.
> The following testcase shows that if a user lies in the attributes
> (a function which
On Fri, Apr 12, 2024 at 1:25 AM Andrew Pinski (QUIC)
wrote:
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Thursday, April 11, 2024 2:31 AM
> > To: Andrew Pinski (QUIC)
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH] ma
On Fri, Apr 12, 2024 at 6:53 AM Andrew Pinski wrote:
>
> The problem is `!a?b:c` pattern will create a COND_EXPR with an 1bit signed
> integer
> which breaks patterns like `a?~t:t`. This rejects when we have a signed
> operand for
> both patterns.
>
> Note for GCC 15, I am going to look at the
stage1 material and will be only able to slowly look
at it after we released.
> On 2024-04-03T19:50:55+0800, Chung-Lin Tang
> wrote:
> > On 2023/10/30 8:46 PM, Richard Biener wrote:
> >>>
> >>> What Chung-Lin's first patch does is mark the OMP clause for 'x' (not t
On Fri, 12 Apr 2024, haochen.jiang wrote:
> On Linux/x86_64,
>
> c7e8a8d814229fd6fc4c16c2452f15dddc613479 is the first bad commit
> commit c7e8a8d814229fd6fc4c16c2452f15dddc613479
> Author: Richard Biener
> Date: Thu Apr 11 11:08:07 2024 +0200
>
> tree-optimizat
On Fri, 12 Apr 2024, haochen.jiang wrote:
> On Linux/x86_64,
>
> c7e8a8d814229fd6fc4c16c2452f15dddc613479 is the first bad commit
> commit c7e8a8d814229fd6fc4c16c2452f15dddc613479
> Author: Richard Biener
> Date: Thu Apr 11 11:08:07 2024 +0200
>
> tree-optimizat
> Am 11.04.2024 um 16:03 schrieb Segher Boessenkool
> :
>
> On Wed, Apr 10, 2024 at 08:32:39PM +0200, Uros Bizjak wrote:
>>> On Wed, Apr 10, 2024 at 7:56 PM Segher Boessenkool
>>> wrote:
>>> This is never okay. You cannot commit a patch without approval, *ever*.
>
> This is the biggest
On Thu, Apr 11, 2024 at 10:43 AM Andrew Pinski wrote:
>
> The issue here is that the `a?~t:t` pattern assumed (maybe correctly) that a
> here was always going to be a unsigned boolean type. This fixes the problem
> in both patterns to cast the operand to boolean type first.
>
> I should note that
https://gcc.gnu.org/g:c7e8a8d814229fd6fc4c16c2452f15dddc613479
commit r14-9912-gc7e8a8d814229fd6fc4c16c2452f15dddc613479
Author: Richard Biener
Date: Thu Apr 11 11:08:07 2024 +0200
tree-optimization/109596 - wrong debug stmt move by copyheader
The following fixes an omission
The following fixes an omission in r14-162-gcda246f8b421ba causing
wrong-debug and a bunch of guality regressions.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/109596
* tree-ssa-loop-ch.cc (ch_base::copy_headers): Propagate
debug stmts
https://gcc.gnu.org/g:52b63100b1eda433120e726d4e8f8dfca6fc94fa
commit r14-9911-g52b63100b1eda433120e726d4e8f8dfca6fc94fa
Author: Richard Biener
Date: Thu Apr 11 08:47:19 2024 +0200
middle-end/114681 - condition coverage and inlining
When inlining a gcond it can map to multiple
When inlining a gcond it can map to multiple stmts, esp. with
non-call EH. The following makes sure to pick up the remapped
condition when dealing with condition coverage.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR middle-end/114681
* tree-inline.cc
; +struct __attribute__((aligned (64))) T { char s[192]; };
> +struct __attribute__((aligned (32))) U { char s[256]; };
> +struct __attribute__((aligned (64))) V { char s[320]; };
> +struct __attribute__((aligned (128))) W { char s[512]; };
> +
> +__attribute__((noipa)) void
> +foo
On Thu, Apr 11, 2024 at 9:02 AM Stefan Schulze Frielinghaus
wrote:
>
> Revert parameter max-completely-peel-times to 16, otherwise, the
> innermost loop is removed and we are left with no loop interchange which
> this test is all about.
>
> gcc/testsuite/ChangeLog:
>
> *
On Wed, 10 Apr 2024, Uros Bizjak wrote:
> On Wed, Apr 10, 2024 at 7:56 PM Segher Boessenkool
> wrote:
> >
> > On Sun, Apr 07, 2024 at 08:31:38AM +0200, Uros Bizjak wrote:
> > > If there are no further comments, I plan to commit the referred patch
> > > to the mainline on Wednesday. The latest
On Wed, 10 Apr 2024, Jakub Jelinek wrote:
> On Wed, Apr 10, 2024 at 06:43:02PM +0200, Richard Biener wrote:
> > The following fixes a mismatch in COMPOUND_EXPR handling in
> > tsubst_expr vs tsubst_stmt where the latter allows a stmt in
> > operand zero but the former
https://gcc.gnu.org/g:912753cc5f18d786e334dd425469fa7f93155661
commit r14-9892-g912753cc5f18d786e334dd425469fa7f93155661
Author: Richard Biener
Date: Wed Apr 10 10:33:40 2024 +0200
tree-optimization/114672 - WIDEN_MULT_PLUS_EXPR type mismatch
The following makes sure to restrict
The following fixes a mismatch in COMPOUND_EXPR handling in
tsubst_expr vs tsubst_stmt where the latter allows a stmt in
operand zero but the former doesn't. This makes a difference
for the case at hand because when the COMPOUND_EXPR is wrapped
inside an ANNOTATE_EXPR it gets handled by
The following makes sure to restrict WIDEN_MULT*_EXPR to a mode
precision final compute type as the mode is used to find the optab
and type checking chokes when seeing bit-precisions later which
would likely also not properly expanded to RTL.
Bootstrapped and tested on x86_64-unknown-linux-gnu,
On Wed, Apr 10, 2024 at 8:24 AM Kewen.Lin wrote:
>
> Hi,
>
> pr113359-2_*.c define a struct having unsigned long type
> members ay and az which have 4 bytes size at -m32, while
> the related constants CL1 and CL2 used for equality check
> are always 8 bytes, it makes compiler consider the below
>
https://gcc.gnu.org/g:109f1b28fc94c93096506e3df0c25e331cef19d0
commit r14-9885-g109f1b28fc94c93096506e3df0c25e331cef19d0
Author: Richard Biener
Date: Wed Apr 10 07:57:03 2024 +0200
Revert "combine: Don't combine if I2 does not change"
This reve
This reverts commit 839bc42772ba7af66af3bd16efed4a69511312ae.
I have now pushed the temporary reversion of this to resolve the
P1 regressions this caused. I'll re-install it on trunk once 14.1
was released (which might be a week or two after stage1 opens).
Richard.
---
gcc/combine.cc | 11
On Tue, Apr 9, 2024 at 11:02 PM Andrew Pinski (QUIC)
wrote:
>
> While looking into PR 114666, I noticed that we don't verify COND_EXPR's
> first operand. In most of my recent patches to match.pd, I was assuming that
> it would be a boolean (or a type which would contain
> [0,1]) but this PR
https://gcc.gnu.org/g:32fb04adae90a0ea68e64e8fc3cb04b613b2e9f3
commit r14-9872-g32fb04adae90a0ea68e64e8fc3cb04b613b2e9f3
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
On Tue, 9 Apr 2024, Jan Hubicka wrote:
> > The following adjusts -flto option processing in lto-wrapper to have
> > link-time -flto override any compile time setting.
> >
> > LTO-boostrapped on x86_64-unknown-linux-gnu, testing in progress.
> >
> > OK for trunk and branches? GCC 11 seems to be
The following adjusts -flto option processing in lto-wrapper to have
link-time -flto override any compile time setting.
LTO-boostrapped on x86_64-unknown-linux-gnu, testing in progress.
OK for trunk and branches? GCC 11 seems to be unaffected by this.
Thanks,
Richard.
PR lto/114655
The following removes the unused tree_live_info_d->global bitmap.
Bootstrapped and tested on x86_64-unknown-linux-gnu, queued for stage1.
Richard.
* tree-ssa-live.h (tree_live_info_d::global): Remove.
(partition_is_global): Likewise.
(make_live_on_entry): Do not set bit
in PR gcov-profile/114601, when
> + -finstrument-functions-once is used and the function has no conditions.
> */
> unsigned
> condition_uid (struct function *fn, basic_block b)
> {
> gimple *stmt = gsi_stmt (gsi_last_bb (b));
> -if (!safe_is_a (stmt))
>
On Tue, Apr 9, 2024 at 9:47 AM Jora Gevorgyan via Gcc wrote:
>
> Hi!
>
> We're trying to improve the optimization process in GCC by adding manual
> optimization attributes to some needed functions. I couldn't yet find the
> code routine where the attributes can be added to a special function
>
On Tue, Apr 9, 2024 at 9:11 AM Jakub Jelinek wrote:
>
> On Tue, Apr 09, 2024 at 09:03:59AM +0200, Richard Biener wrote:
> > > With the possibility of sounding like a broken record, I think
> > > __builtin_unreachable is fundamentally flawed. It generates no code
> &g
On Mon, Apr 8, 2024 at 6:39 PM wrote:
>
> From: Pierre-Emmanuel Patry
>
> Hello,
>
> The rust frontend requires cargo to build some of it's components,
> it's presence was not checked during configuration.
OK.
Please work on documenting build requirements for rust in doc/install.texi,
look for
On Mon, Apr 8, 2024 at 6:39 PM wrote:
>
> From: Pierre-Emmanuel Patry
>
> Hello,
>
> The rust frontend requires cargo to build some of it's components,
> it's presence was not checked during configuration.
OK.
Please work on documenting build requirements for rust in doc/install.texi,
look for
the return value, the number of conditions, make
> sure
> + to include the increment of the last basic block. */
> +if (increment)
> + xi += 1;
> +
> gcc_assert (xi == bitmap_count_bits (core));
>
> const tree relaxed = build_int_cst (integer_type_node, MEMMODEL_RELAXED);
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
dd_local_decl (caller, new_var);
>}
> -
> - /* If -fcondition-coverage is used and the caller has conditions, copy the
> - mapping into the caller but and the end so the caller and callee
> - expressions aren't mixed. */
> - if (callee->cond_uids)
> -{
> -
to @code{TARGET_@var{name}} but take an
> -argument as @samp{target_flags}, and and @code{TARGET_@var{name}_OPTS_P} also
> -similar to @code{TARGET_@var{name}} but take an argument as
> @code{gcc_options}.
> +@code{TARGET_@var{name}_P} is similar to @code{TARGET_@var{name}} but takes
On Tue, Apr 9, 2024 at 6:03 AM Jeff Law wrote:
>
>
>
> On 4/8/24 5:04 PM, Iain Sandoe wrote:
> > Hi
> >
> > PR 109627 is about functions that have had their bodies completely elided,
> > but still have the wrappers for EH frames (either .cfi_xxx or LFSxx/LFExx).
> >
> > These are causing issues
On Tue, Apr 9, 2024 at 4:42 AM Hanke Zhang via Gcc wrote:
>
> Hi Marc,
>
> Thanks for your reply.
>
> I want to create a new type similar to this one `(const __m256i_u *
> {ref-all})` indeed. And I try to create it via these calls:
>
> tree type = build_vector_type_for_mode (intDI_type_node,
On Tue, Apr 9, 2024 at 4:07 AM Kewen.Lin wrote:
>
> on 2024/4/8 18:47, Richard Biener wrote:
> > On Mon, Apr 8, 2024 at 11:22 AM Kewen.Lin wrote:
> >>
> >> Hi,
> >>
> >> As the comments in PR88309 show, there are two oversights
> >&g
+l2:
> + x = foo (foo (3));
> + bar (y);
> + goto *q[x & 1];
> +l1:;
> +}
> +
> +void
> +qux (int x, _BitInt(129) y)
> +{
> + void *q[] = { &, & };
> +l2:
> + x = foo (foo (3));
> + bar (y);
> +l1:;
> +}
> +#endif
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
didn't try instrumenting there).
Feel free to improve next stage1.
Richard.
> Aldy
>
> On Mon, Apr 8, 2024 at 7:47 PM Richard Biener
> wrote:
> >
> >
> >
> > > Am 08.04.2024 um 18:40 schrieb Aldy Hernandez :
> > >
> > > On Mon, Apr 8, 2024 at 6:
https://gcc.gnu.org/g:d76df699b8ff792575e9df4d214c21fed0ed3b6b
commit r14-9855-gd76df699b8ff792575e9df4d214c21fed0ed3b6b
Author: Richard Biener
Date: Mon Apr 8 10:50:18 2024 +0200
middle-end/114604 - ranger allocates bitmap without initialized obstack
The following fixes ranger
> Am 08.04.2024 um 18:40 schrieb Aldy Hernandez :
>
> On Mon, Apr 8, 2024 at 6:29 PM Richard Biener wrote:
>>
>>
>>
>>>> Am 08.04.2024 um 18:09 schrieb Aldy Hernandez :
>>>
>>> On Mon, Apr 8, 2024 at 5:54 PM Jakub Jelinek wrote:
> Am 08.04.2024 um 18:09 schrieb Aldy Hernandez :
>
> On Mon, Apr 8, 2024 at 5:54 PM Jakub Jelinek wrote:
>>
>> On Mon, Apr 08, 2024 at 05:40:23PM +0200, Aldy Hernandez wrote:
PR middle-end/114604
* gimple-range.cc (enable_ranger): Initialize the global
On Mon, 8 Apr 2024, Richard Biener wrote:
> On Fri, 5 Apr 2024, Jan Hubicka wrote:
>
> > > + /* When there's a call that might not return the last iteration
> > > + is possibly partial. This matches what we check in invariant
> > > + motion.
> &
utions (loop);
> >
> > - basic_block *body = get_loop_body (loop);
> > + basic_block *body = get_loop_body_in_rpo (cfun, loop);
> >auto_vec exits = get_loop_exit_edges (loop, body);
> >likely_exit = single_likely_exit (loop, exits);
> >FOR_EACH_VEC_ELT (exits, i, ex)
> > --
> > 2.35.3
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
1 - 100 of 27631 matches
Mail list logo
