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)
On Mon, Apr 8, 2024 at 11:23 AM Kewen.Lin wrote:
>
> Hi,
>
> As PR114614 shows, the newly added test case gcov-20.c by
> commit r14-9789-g08a52331803f66 failed on targets which do
> not support atomic profile update, there would be a message
> like:
>
> warning: target does not support atomic
On Mon, Apr 8, 2024 at 11:22 AM Kewen.Lin wrote:
>
> Hi,
>
> As the comments in PR88309 show, there are two oversights
> in rs6000_gimple_fold_builtin that pass align in bytes to
> build_aligned_type but which actually requires align in
> bits, it causes unexpected ICE or hanging in function
>
The following fixes ranger bitmap allocation when invoked from IPA
context where the global bitmap obstack possibly isn't initialized.
Instead of trying to use one of the ranger obstacks the following
simply initializes the global bitmap obstack around an active ranger.
Bootstrapped and tested on
https://gcc.gnu.org/g:97d5cd8740384dbce5a83080916388f80d8976dd
commit r14-9829-g97d5cd8740384dbce5a83080916388f80d8976dd
Author: Richard Biener
Date: Mon Apr 8 10:38:49 2024 +0200
tree-optimization/114624 - fix use-after-free in SCCP
We're inspecting the replaced PHI node after
We're inspecting the replaced PHI node after releasing it.
Bootstrapped and tested on x86-64-unknown-linux-gnu, pushed.
PR tree-optimization/114624
* tree-scalar-evolution.cc (final_value_replacement_loop):
Get at the PHI arg location before releasing the PHI node.
On Mon, Apr 8, 2024 at 10:47 AM Pierrick Philippe
wrote:
>
> On 06/04/2024 14:53, Richard Biener wrote:
>
> On Fri, Apr 5, 2024 at 3:44 PM Pierrick Philippe
> wrote:
>
> On 05/04/2024 14:46, Richard Biener wrote:
>
> On Fri, Apr 5, 2024 at 1:59 PM Pierrick Philippe
>
> Am 01.04.2024 um 21:28 schrieb Uros Bizjak :
>
> Hello!
>
> I'd like to ping the
> https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647634.html
> PR112560 P1 patch.
Ok.
Thanks,
Richard
> Thanks,
> Uros.
> Am 06.04.2024 um 22:41 schrieb Jørgen Kvalsvik :
>
> On 06/04/2024 13:15, Jørgen Kvalsvik wrote:
>>> On 06/04/2024 07:50, Richard Biener wrote:
>>>
>>>
>>>> Am 05.04.2024 um 21:59 schrieb Jørgen Kvalsvik :
>>>>
>&
On Fri, Apr 5, 2024 at 11:18 PM Andrew Sutton via Gcc wrote:
>
> >
> >
> >
> > > I think the key difference here is that Autotools allows arbitrarily
> > generated code to be executed at any time. More modern build systems
> > require the use of specific commands/files to run arbitrary code, e.g.
On Fri, Apr 5, 2024 at 3:52 PM Richard Sandiford
wrote:
>
> aarch64-sve.md had a pattern that combined:
>
> cmpeq pb.T, pa/z, zc.T, #0
> mov zd.T, pb/z, #1
>
> into:
>
> cnotzd.T, pa/m, zc.T
>
> But this is only valid if pa.T is a ptrue. In other cases, the
>
On Fri, Apr 5, 2024 at 3:44 PM Pierrick Philippe
wrote:
>
> On 05/04/2024 14:46, Richard Biener wrote:
>
> On Fri, Apr 5, 2024 at 1:59 PM Pierrick Philippe
> wrote:
>
> Hi all,
>
> I do have a question regarding ssa_name and result_decl.
>
> For example on the f
On Fri, Apr 5, 2024 at 11:29 PM Segher Boessenkool
wrote:
>
> Hi!
>
> On Wed, Apr 03, 2024 at 01:07:41PM +0200, Richard Biener wrote:
> > The following avoids re-walking and re-combining the instructions
> > between i2 and i3 when the pattern of i2 doesn't change.
>
> Am 05.04.2024 um 21:59 schrieb Jørgen Kvalsvik :
>
> Hi,
>
> I propose these fixes for the current issues with the condition
> coverage.
>
> Rainer, I propose to simply delete the test with __sigsetjmp. I don't
> think it actually detects anything reasonable any more, I kept it around
>
> Am 05.04.2024 um 15:46 schrieb H.J. Lu :
>
> On Fri, Apr 5, 2024 at 1:21 AM Richard Biener wrote:
>>
>> There's no default bitmap obstack during global CTORs, so allocate the
>> bitmap locally.
>>
>> Bootstrap and regtest running on x
On Fri, 5 Apr 2024, Richard Biener wrote:
> The following makes sure to only compute upper bounds for the number
> of iterations of loops from undefined behavior invoked by stmts when
> those are executed in each loop iteration, in particular also in the
> last one. The l
The following makes sure to only compute upper bounds for the number
of iterations of loops from undefined behavior invoked by stmts when
those are executed in each loop iteration, in particular also in the
last one. The latter cannot be guaranteed if there's possible
infinite loops or calls with
The following adds another get_loop_body variant, one to get blocks
in RPO.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
* cfgloop.h (get_loop_body_in_rpo): Declare.
* cfgloop.cc (get_loop_body_in_rpo): Compute loop body in RPO.
---
gcc/cfgloop.cc | 68
The following passes down whether a stmt is always executed from
infer_loop_bounds_from_undefined to infer_loop_bounds_from_array.
The parameters were already documented. The patch doesn't remove
possibly redundant checks from idx_infer_loop_bounds yet.
Boostrapped on x86_64-unknown-linux-gnu,
On Tue, Apr 2, 2024 at 1:16 PM Richard Biener
wrote:
>
> On Tue, Apr 2, 2024 at 11:14 AM Thor Preimesberger via Gcc
> wrote:
> >
> > Forgot to CC the mailing list - mea culpa.
> >
> > -- Forwarded message -
> > From: Thor Preimesberger
On Fri, Apr 5, 2024 at 1:59 PM Pierrick Philippe
wrote:
>
> Hi all,
>
> I do have a question regarding ssa_name and result_decl.
>
> For example on the following gimple function:
>
> int f ()
> {
> int x;
> int D.2747;
> int _2;
>
>:
> x_1 = 42;
> _2 = x_1;
>
>:
> :
> return
On Fri, Apr 5, 2024 at 2:28 PM Manolis Tsamis wrote:
>
> If we consider code like:
>
> if (bar1 == x)
> return foo();
> if (bar2 != y)
> return foo();
> return 0;
>
> We would like the ifcombine pass to convert this to:
>
> if (bar1 == x || bar2 != y)
> return
ttribute__((noipa)) int
> +foo (float x, float y)
> +{
> + float a[8][56];
> + __builtin_memset (a, 0, sizeof (a));
> +
> + for (int j = 0; j < 8; j++)
> +for (int k = 0; k < 56; k++)
> + {
> + float b = k * y;
> + if (b < 0.)
> + b = 0.;
https://gcc.gnu.org/g:9ab8fdfeef5b1a47b358e08a98177b2fad65fed9
commit r14-9803-g9ab8fdfeef5b1a47b358e08a98177b2fad65fed9
Author: Richard Biener
Date: Fri Apr 5 10:16:41 2024 +0200
middle-end/114599 - fix bitmap allocation for
check_ifunc_callee_symtab_nodes
There's no default
dg/gcov.exp.jj 2024-04-04 21:45:56.025155257 +0200
> +++ gcc/testsuite/gdc.dg/gcov.exp 2024-04-05 10:20:23.678682559 +0200
> @@ -1,4 +1,4 @@
> -# Copyright (C) 1997-2023 Free Software Foundation, Inc.
> +# Copyright (C) 1997-2024 Free Software Foundation, Inc.
>
> # This program is free software; you can redistribute it and/or modify
> # it under the terms of the GNU General Public License as published by
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
There's no default bitmap obstack during global CTORs, so allocate the
bitmap locally.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
PR middle-end/114599
* symtab.cc (ifunc_ref_map): Do not use auto_bitmap.
(is_caller_ifunc_resolver): Optimize
On Thu, 4 Apr 2024, Tamar Christina wrote:
> Hi All,
>
> The report shows that we end up in a situation where the code has been peeled
> for gaps and we have an early break.
>
> The code for peeling for gaps assume that a scalar loop needs to perform at
> least one iteration. However this
The following speeds up stack variable conflict detection by recognizing
that the all-to-all conflict recording is only necessary for CFG merges
as it's the unioning of the live variable sets that doesn't come with
explicit mentions we record conflicts for.
If we employ this optimization we have
https://gcc.gnu.org/g:85621f98d245004a6c9787dde21e0acc17ab2c50
commit r14-9786-g85621f98d245004a6c9787dde21e0acc17ab2c50
Author: Richard Biener
Date: Thu Apr 4 10:00:51 2024 +0200
tree-optimization/114485 - neg induction with partial vectors
We can't use
t (T, f);
> +}
> +}
> +
> +struct A { signed char b : 1 = 0; signed char c : 7 = 0; };
> +struct D { unsigned char e; };
> +constexpr unsigned char f = std::bit_cast (A{}).e;
> +static_assert (f == 0);
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
t; +/* { dg-options "-std=c23 -O -fno-tree-forwprop" } */
> +
> +#if __BITINT_MAXWIDTH__ >= 4139
> +struct S { _BitInt(31) : 6; _BitInt(513) b : 241; } s;
> +_BitInt(4139) a;
> +#endif
> +
> +void
> +foo (void)
> +{
> +#if __BITINT_MAXWIDTH__ >= 4139
> + int i = 0;
> + a -= s.b << i;
> +#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)
We can't use vect_update_ivs_after_vectorizer for partial vectors,
the following fixes vect_can_peel_nonlinear_iv_p accordingly.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
We could handle this case by vectorizing the live lane but that's
a different thing and might be tackled
https://gcc.gnu.org/g:e152177b362143465e2b9d721ea632cae3f13445
commit r14-9781-ge152177b362143465e2b9d721ea632cae3f13445
Author: Richard Biener
Date: Wed Apr 3 14:53:30 2024 +0200
tree-optimization/114551 - loop splitting and undefined overflow
When loop splitting hoists a guard
When loop splitting hoists a guard computation it needs to make sure
that can be safely evaluated at this place when it was previously
only conditionally evaluated. The following fixes this for the
case of undefined overflow.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
On Wed, 3 Apr 2024, Tobias Burnus wrote:
> Found when working with -save-temps and looking at 'mkoffload'
> with a GCC configured for both nvptx and gcn offloading.
>
> Before (for 'a.out') for mkoffload:a.offload_args now:
> a.amdgcn-amdhsa.offload_args and a.nvptx-none.offload_args
> OK for
On Thu, Mar 28, 2024 at 4:03 AM Eugene Rozenfeld
wrote:
>
> auto-profile currently doesn't guarantee that it will set probabilities
> on all edges because of zero basic block counts. Normally those edges
> just have probabilities set by the preceding profile_estimate pass but
> under -O0
The following avoids re-walking and re-combining the instructions
between i2 and i3 when the pattern of i2 doesn't change.
Bootstrap and regtest running ontop of a reversal of
r14-9692-g839bc42772ba7a.
It brings down memory use frmo 9GB to 400MB and compile-time from
80s to 3.5s.
>
> Given that the two patches here (for
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632) were considered obvious
> - and are needed on release branches.
>
> OK for backporting?
OK.
> (Gerald has volunteered to do the earlier ones, I have already made/tested
> t
On Wed, 3 Apr 2024, Jan Beulich wrote:
> On 03.04.2024 10:45, Jakub Jelinek wrote:
> > On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon wrote:
> >> Any concerns/objections?
> >
> > I'm all for it, in fact I've been sending it like that myself for years
> > even when the policy said not
6793 +0200
> +++ gcc/testsuite/gcc.c-torture/execute/pr114552.c2024-04-02
> 16:03:49.829963659 +0200
> @@ -0,0 +1,24 @@
> +/* PR middle-end/114552 */
> +
> +struct __attribute__((packed)) S { short b; int c; };
> +struct T { struct S b; int e; };
> +static const struct T
On Wed, Apr 3, 2024 at 9:25 AM Jakub Jelinek wrote:
>
> Hi!
>
> The following patch attempts to implement P2809R3, which has been voted
> in as a DR.
>
> The middle-end has its behavior documented:
> '-ffinite-loops'
> Assume that a loop with an exit will eventually take the exit and
>
https://gcc.gnu.org/g:e7b7188b1cf8c174f0e890d4ac279ff480b51043
commit r14-9767-ge7b7188b1cf8c174f0e890d4ac279ff480b51043
Author: Richard Biener
Date: Tue Apr 2 12:31:04 2024 +0200
tree-optimization/114557 - reduce ehcleanup peak memory use
The following reduces peak memory use
On Tue, 2 Apr 2024, Richard Biener wrote:
> The following reduces peak memory use for the PR114480 testcase at -O1
> which is almost exclusively spent by the ehcleanup pass in allocating
> PHI nodes. The free_phinodes cache we maintain isn't very effective
> since it has effective
The following reduces peak memory use for the PR114480 testcase at -O1
which is almost exclusively spent by the ehcleanup pass in allocating
PHI nodes. The free_phinodes cache we maintain isn't very effective
since it has effectively two slots, one for 4 and one for 9 argument
PHIs and it is only
the host and the
> +# It sets various shell variables based on the host and the
> # configuration options. You can modify this shell script without needing
> # to rerun autoconf/aclocal/etc. This file is "sourced" not executed.
> #
> --- libvtv/vtv_rts.cc.jj
@endunless target-libstdc++-v3-bootstrap
> +@unless target-libatomic-bootstrap
> +all-target-libgm2: maybe-all-target-libatomic
> +@endunless target-libatomic-bootstrap
> +@unless target-libstdc++-v3-bootstrap
> +configure-target-libgrust: maybe-all-target-libstdc++-v3
> +@endunless target-libstdc++-v3-bootstrap
> +@unless target-libbacktrace-bootstrap
> +configure-target-libgfortran: maybe-all-target-libbacktrace
> +@endunless target-libbacktrace-bootstrap
> +@unless target-libbacktrace-bootstrap
> +configure-target-libgo: maybe-all-target-libbacktrace
> +@endunless target-libbacktrace-bootstrap
> +@endif gcc-bootstrap
> +
> @unless gcc-bootstrap
> all-gnattools: maybe-all-target-libstdc++-v3
> configure-libcc1: maybe-configure-gcc
>
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
901 - 1000 of 28486 matches
Mail list logo
