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: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
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: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:
> 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
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.
> 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 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 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 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.;
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
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
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
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
>
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)
On Mon, Apr 1, 2024 at 3:36 PM Qing Zhao wrote:
>
> This is a bug in tree-ssa-math-opts.c, when applying the widening mul
> optimization, the compiler needs to check whether the operand is in a
> ABNORMAL PHI, if YES, we should avoid the transformation.
>
> PR tree-optimization/111407
>
>
On Sat, Mar 30, 2024 at 9:11 PM Tom Tromey wrote:
>
> Investigating GDB PR d/31580 showed that the libiberty demangler
> doesn't automatically demangle D mangled names. However, I think it
> should -- like C++ and Rust (new-style), D mangled names are readily
> distinguished by the leading "_D",
On Thu, Mar 28, 2024 at 8:35 PM Tom Tromey wrote:
>
> When debugging gcc, I tried calling debug_dwarf_die and I saw this
> output:
>
> DW_AT_location: location descriptor:
> (0x7fffe9c2e870) DW_OP_dup 0, 0
> (0x7fffe9c2e8c0) DW_OP_bra location descriptor (0x7fffe9c2e640)
> ,
On Wed, 27 Mar 2024, Michael Matz wrote:
> Hey,
>
> On Wed, 27 Mar 2024, Jakub Jelinek wrote:
>
> > > @@ -1712,12 +1711,9 @@ compute_idf (bitmap def_blocks, bitmap_head *dfs)
> > >gcc_checking_assert (bb_index
> > > < (unsigned) last_basic_block_for_fn (cfun));
> >
> Am 27.03.2024 um 18:37 schrieb Peter0x44 :
>
>
>>
>>> >> > Another way would be to have a portable solution to truncate a file
>>> >> > (maybe even removing it would work). I don't think we should override
>>> >> > SHELL.
> I've been thinking harder about this, these files get unlinked
The testcase in this PR shows very slow IDF compute:
tree SSA rewrite : 76.99 ( 31%)
24.78%243663 cc1plus cc1plus [.] compute_idf
which can be mitigated to some extent by refactoring the bitmap
operations to simpler variants. With the patch below
On Wed, 27 Mar 2024, Jakub Jelinek wrote:
> On Wed, Mar 27, 2024 at 12:48:29PM +0100, Richard Biener wrote:
> > > The following patch attempts to fix the (view_convert (convert@0 @1))
> > > optimization. If TREE_TYPE (@0) is a _BitInt type with padding bits
> > >
On Wed, Mar 27, 2024 at 1:20 PM Xi Ruoyao wrote:
>
> On Wed, 2024-03-27 at 08:54 +0100, Richard Biener wrote:
> > On Tue, Mar 26, 2024 at 10:52 AM Xi Ruoyao wrote:
> > >
> > > The latency of LA464 and LA664 division instructions depends on the
> > > input
The following makes sure to record the scalars we add to the BB
reduction vectorization result as scalar uses for the purpose of
computing live lanes. This restores vectorization in the
bondfree.c TU of 435.gromacs.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR
+ ok = (TYPE_PRECISION (type0)
> + == tree_to_uhwi (TYPE_SIZE (type0)));
> + }
> + }
> + else if (TYPE_PRECISION (type0) > TYPE_PRECISION (type1)
> +&& TYPE_UNSIGNED (type1))
> +
On Wed, Mar 27, 2024 at 10:13 AM peter0x44 wrote:
>
> On 2024-03-27 01:58, Richard Biener wrote:
> > On Wed, Mar 27, 2024 at 9:13 AM Peter0x44
> > wrote:
> >>
> >> I accidentally replied off-list. Sorry.
> >>
> >> 27 Mar 2024 8:09:30 am Pet
On Wed, Mar 27, 2024 at 9:13 AM Peter0x44 wrote:
>
> I accidentally replied off-list. Sorry.
>
> 27 Mar 2024 8:09:30 am Peter0x44 :
>
>
> 27 Mar 2024 7:51:26 am Richard Biener :
>
> > On Tue, Mar 26, 2024 at 11:37 PM Peter Damianov
> > wrote:
> >>
On Tue, Mar 26, 2024 at 10:52 AM Xi Ruoyao wrote:
>
> The latency of LA464 and LA664 division instructions depends on the
> input. When I updated the costs in r14-6642, I unintentionally set the
> division costs to the best-case latency (when the first operand is 0).
> Per a recent discussion
On Tue, Mar 26, 2024 at 11:37 PM Peter Damianov wrote:
>
> lto-wrapper generates Makefiles that use the following:
> touch -r file file.tmp && mv file.tmp file
> to truncate files.
> If there is no suitable "touch" or "mv" available, then this errors with
> "The system cannot find the file
__) / 2U;
> + unsigned b = 1U;
> + unsigned c = (a * 2U > b * 2U ? a * 2U : b * 2U) * 2U;
> + if (c != 0U)
> +__builtin_abort ();
> + int d = (-__INT_MAX__ - 1) / 2;
> + int e = 10;
> + int f = (d * 2 > e * 5 ? d * 2 : e * 5) * 6;
> + if (f != 120)
The following fixes too lax verification of vector type compatibility
in vectorizable_operation. When we only have a single vector size then
comparing the number of elements is enough but with SLP we mix those
and thus for operations like BIT_AND_EXPR we need to verify compatible
element types as
The following adds missing verification of vector type compatibility
to recurrence vectorization.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/114464
* tree-vect-loop.cc (vectorizable_recurr): Verify the latch
vector type is compatible
* { dg-options "-fsanitize=thread -fdump-tree-optimized -ffat-lto-objects"
> } */
> +/* { dg-final { scan-tree-dump-not "__tsan_read" "optimized" } } */
> +/* { dg-final { scan-tree-dump-not "__tsan_write" "optimized" } } */
> +
> +#ifdef __x86_6
On Tue, Mar 26, 2024 at 9:43 AM Stefan Schulze Frielinghaus
wrote:
>
> This fixes the test on s390x. I'm also seeing test failures for
> riscv64-suse-linux-gnu, m68k-unknown-linux-gnu, pru-unknown-elf, and
> powerpc64le-unknown-linux-gnu. However, I didn't check them so this
> might or might
The following fixes out-of-bounds read in the testcase.
Pushed to trunk and branch.
PR tree-optimization/114027
* gcc.dg/vect/pr114027.c: Fix iteration count.
---
gcc/testsuite/gcc.dg/vect/pr114027.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Mon, 25 Mar 2024, Richard Biener wrote:
> Add support for the gfx1036 RDNA2 APU integrated graphics devices. The ROCm
> documentation warns that these may not be supported, but it seems to work
> at least partially.
>
> x86 host bootstrap/regtest running, target-
On Mon, 25 Mar 2024, Tobias Burnus wrote:
> Richard Biener wrote:
> > I'll follow up with the libgomp testing test summary for archival
> > purposes. I still see linker errors for testcases using -g
> > (the ld: ^[[0;31merror: ^[[0mincompatible mach:
> > /tmp/ccr0
On Mon, 25 Mar 2024, Andre Vieira (lists) wrote:
> Hi,
>
> After the backport off PR target/112787 a failure was reported against x86_64,
> this would be fixed by backporting:
> * tree-optimization/91838 - fix FAIL of g++.dg/opt/pr91838.C
> (d1c072a1c3411a6fe29900750b38210af8451eeb)
> *
Add support for the gfx1036 RDNA2 APU integrated graphics devices. The ROCm
documentation warns that these may not be supported, but it seems to work
at least partially.
x86 host bootstrap/regtest running, target-libgomp testing for the
offload produces results comparable to those of gfx1030.
rmations 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 vectorizatio
On Mon, 25 Mar 2024, Chenghui Pan wrote:
> Current document of Tree SSA passes contains many parts that is not
> updated for many years.
>
> This patch removes some info that is outdated and not existed in
> current GCC codebase, and fixes some wrong code location descriptions
> based on current
> Am 23.03.2024 um 08:59 schrieb Jakub Jelinek :
>
> Hi!
>
> We ICE on the following testcase, because handle_cast was incorrectly
> testing !m_first to see whether it should use m_data[m_bitfld_load + 1]
> or fresh SSA_NAME for a PHI result.
> Now, m_first is in the routine sometimes
> Am 23.03.2024 um 08:56 schrieb Jakub Jelinek :
>
> Hi!
>
> The task of the build_bitint_stmt_ssa_conflicts hook for
> tree-ssa-coalesce.cc next to special casing the
> multiplication/division/modulo is to ignore statements with
> large/huge _BitInt lhs which isn't in names bitmap and on
> Am 23.03.2024 um 08:49 schrieb Jakub Jelinek :
>
> Hi!
>
> On the following testcases, there is no overlap between data references
> within a single iteration, but the data references have size which is twice
> as large as the step, which means the data references overlap with the next
>
On Fri, Mar 22, 2024 at 5:20 AM Andrew Pinski wrote:
>
> This another one of these ICE after error issues with the
> gimplifier and a fallout from r12-3278-g823685221de986af.
> This case happens when we are trying to fold memcpy/memmove.
> There is already code to try to catch ERROR_MARKs as
On Thu, Mar 21, 2024 at 8:56 PM Jeff Law wrote:
>
>
>
> On 3/21/24 11:19 AM, Vineet Gupta wrote:
>
> >>
> >> So if we go back to Robin's observation that scheduling dramatically
> >> increases the instruction count, perhaps we try a run with
> >> -fno-schedule-insns -fno-schedule-insns2 and see
On Thu, Mar 21, 2024 at 5:07 PM Andrew Stubbs wrote:
>
> On 21/03/2024 15:18, Richard Biener wrote:
> > On Thu, Mar 21, 2024 at 3:23 PM Andrew Stubbs wrote:
> >>
> >> My previous patch to fix this problem with xor was rejected because we
> >> want to fi
/* { dg-final { scan-tree-dump-not "p_\[0-9]*.D. \[=!]= 0" "optimized" } } */
> +
> +#ifdef __x86_64__
> +#define SEG __seg_fs
> +#else
> +#define SEG __seg_gs
> +#endif
> +
> +int
> +foo (int SEG *p, int *q)
> +{
> + return *p;
> +}
> +
> +__attribute__((no_sanitize("alignment"))) int
> +bar (int SEG *p, int *q)
> +{
> + return *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)
n_abort ();
> + a = y >> (22658 - 22656);
> + s6.b = a;
> + f6 ();
> + if (s6.b != a - 6)
> +__builtin_abort ();
> + a = x >> (22658 - 22593);
> + s7.b = a;
> + f7 ();
> + if (s7.b != a - 7)
> +__builtin_abort ();
> + a = y >> (22658
On Thu, Mar 21, 2024 at 3:23 PM Andrew Stubbs wrote:
>
> My previous patch to fix this problem with xor was rejected because we
> want to fix these issues only at the point of use. That patch produced
> slightly better code, in this example, but this works too
>
> These patches fix up a
On Thu, 21 Mar 2024, Jakub Jelinek wrote:
> On Thu, Mar 21, 2024 at 10:50:04AM +0100, Richard Biener wrote:
> > Fixed and pushed. I suppose for address-spaces nested within the
> > generic address space we could instrument the address converted to
> > the generic address spa
On Thu, 21 Mar 2024, Rainer Orth wrote:
> gcc.dg/vect/bb-slp-32.c currently XPASSes on 32 and 64-bit Solaris/SPARC:
>
> XPASS: gcc.dg/vect/bb-slp-32.c -flto -ffat-lto-objects scan-tree-dump slp2
> "vectorization is not profitable"
> XPASS: gcc.dg/vect/bb-slp-32.c scan-tree-dump slp2
On Thu, 21 Mar 2024, Jakub Jelinek wrote:
> On Thu, Mar 21, 2024 at 10:25:24AM +0100, Richard Biener wrote:
> > The following more thoroughly avoids address sanitizing accesses
> > to non-generic address-spaces.
> >
> > Bootstrapped and tested on x86_64-unk
The following more thoroughly avoids address sanitizing accesses
to non-generic address-spaces.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
OK?
Thanks,
Richard.
PR tree-optimization/111736
* asan.cc (instrument_derefs): Do not instrument accesses
to non-generic
On Thu, Mar 21, 2024 at 9:35 AM liuhongt wrote:
>
> wi::from_mpz doesn't take a sign argument, we want it to be wrapped
> instead of saturation, so pass utype and true to it, and it fixes the
> bug.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk and backport to
8342628768636932743029911wb) != -1
> + || foo (336225022742818342628768636932743029912uwb,
> + -336225022742818342628768636932743029911wb) != -1
> + || foo (336225022742818342628768636932743029911uwb,
> + -336225022742818342628768636932743029912wb) != 0)
> +__builtin_abort ();
> +#endif
> +#if __BITINT_MAXWIDTH__ >= 192
> + if (bar (336225022742818342628768636932743029911uwb,
> +-336225022742818342628768636932743029911wb) != -1
> + || bar (336225022742818342628768636932743029912uwb,
> + -336225022742818342628768636932743029911wb) != -1
> + || bar (336225022742818342628768636932743029911uwb,
> + -336225022742818342628768636932743029912wb) != 0)
> +__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)
_int_cst (integer_type_node, 0);
> + errlen = integer_zero_node;
> }
>
> size = fold_convert (size_type_node, size);
> @@ -1903,7 +1903,7 @@ gfc_deallocate_with_status (tree pointer
> if (descr)
> cond = fold_build2_loc (input_location, EQ_EXPR, boolean_type_node,
> gfc_conv_descriptor_version (descr),
> - build_int_cst (integer_type_node, 1));
> + integer_one_node);
> else
> cond = gfc_omp_call_is_alloc (pointer);
> omp_tmp = builtin_decl_explicit (BUILT_IN_GOMP_FREE);
> @@ -1917,7 +1917,7 @@ gfc_deallocate_with_status (tree pointer
>0));
>if (flag_openmp_allocators && descr)
> gfc_add_modify (_null, gfc_conv_descriptor_version (descr),
> - build_zero_cst (integer_type_node));
> + integer_zero_node);
>
>if (status != NULL_TREE && !integer_zerop (status))
> {
> @@ -1946,7 +1946,7 @@ gfc_deallocate_with_status (tree pointer
> {
> gcc_assert (errlen == NULL_TREE);
> errmsg = null_pointer_node;
> - errlen = build_zero_cst (integer_type_node);
> + errlen = integer_zero_node;
> }
>else
> {
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
> +
> +struct S {
> + int : 31;
> +#if __BITINT_MAXWIDTH__ >= 129
> + _BitInt(129) b : 129;
> +#else
> + _BitInt(63) b : 63;
> +#endif
> +} s;
> +
> +void
> +foo (int a)
> +{
> + s.b <<= a;
> +}
>
> 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, Mar 15, 2024 at 11:31 AM Thomas Neumann
wrote:
>
> Original bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731
> Given that this is a regression, is this okay for gcc 13 and mainline?
It does look straightforward but I hope Jason or Florian can provide the ACK.
Thanks,
On Wed, 20 Mar 2024, Hao Liu OS wrote:
> Hi Richard,
>
> As mentioned in the comments of PR114322 (which has been fixed by PR114151
> r14-9540-ge0e9499a), this patch is to cover the case.
>
> Bootstrapped and regression tested on aarch64-linux-gnu, OK for trunk?
>
> gcc/testsuite/ChangeLog:
>
On Tue, 19 Mar 2024, Jakub Jelinek wrote:
> On Tue, Mar 19, 2024 at 03:47:37PM +0100, Richard Biener wrote:
> > The following fixes bogus truncation of a value-range for an int128
> > array index when computing the maximum extent for a variable array
> > reference. Instea
The following fixes bogus truncation of a value-range for an int128
array index when computing the maximum extent for a variable array
reference. Instead of possibly slowing things down by using
widest_int the following makes sure the range bounds fit within
the constraints offset_int were
When SRA analyzes BIT_FIELD_REFs it handles writes and not byte
aligned reads differently from byte aligned reads. Instead of
trying to create replacements for the loaded portion the former
cases try to replace the base object while keeping the wrapping
BIT_FIELD_REFs. This breaks when we have
The following reverts the chrec_fold_multiply fix and only keeps
handling of constant overflow which keeps the original testcase
fixed. A better solution might involve ranger improvements or
tracking of assumptions during SCEV analysis similar to what niter
analysis does.
Bootstrapped and tested
On Tue, 19 Mar 2024, Jakub Jelinek wrote:
> On Tue, Mar 19, 2024 at 12:54:47PM +0100, Richard Biener wrote:
> > Works for me, but would
> >
> > #undef vec_step
> >
> > work or is it really a keyword in the clang side?
>
> No, it is really keyword.
> #
4-03-08 09:07:29.484624793 +0100
> +++ gcc/system.h 2024-03-19 11:39:18.122700551 +0100
> @@ -1302,6 +1302,12 @@ void gcc_stablesort_r (void *, size_t, s
> #define NULL nullptr
> #endif
>
> +/* Workaround clang on PowerPC which has vec_step as reserved keyword
> + rather t
501 - 600 of 25513 matches
Mail list logo
