On Tue, Mar 19, 2024 at 01:06:50PM +0100, Richard Biener wrote:
> 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
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.
#undef vec_step
int
main ()
{
int vec_step = 0;
return vec_step;
}
clang --target=powerpc64le-linux -o
r vec_set and appart from altivec.h it is just used in
tree-vect-loop.cc, some Ada files which aren't preprocessed, ChangeLogs,
rs6000-vecdefines.h (but that header is only included from altivec.h and
vec_step is then redefined to the function-like macro) and in
rs6000-overload.def
but tha
Hi!
Like for x86-64, alpha or rs6000, arc seems to be affected too.
Just visually checked differences in c23-stdarg-9.c assembly in a cross
without/with the patch, committed to trunk.
2024-03-19 Jakub Jelinek
PR target/114175
* config/arc/arc.cc (arc_setup_incoming_varargs
wasn't translated
at all (would need to use _("...") to get translated), so this patch rewrites it
such that the whole messages are in the format strings.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2024-03-19 Jakub Jelinek
PR c/114364
.
Ok for trunk?
2024-03-18 Jakub Jelinek
PR target/114175
* config/alpha/alpha.cc (alpha_setup_incoming_varargs): Only skip
function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.
--- gcc/config/alpha/alpha.cc.jj2024-01-05 15:22
or trunk?
2024-03-18 Jakub Jelinek
PR target/114175
* config/rs6000/rs6000-call.cc (setup_incoming_varargs): Only skip
rs6000_function_arg_advance_1 for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.
* gcc.dg/c23-stdarg-9.c: New test.
--- gc
Then arm, epiphany, fr30, frv, ft32, m32r, mcore, nds32, rs6000, sh
have different changes but most likely need something similar too.
I don't have access to most of those, could test aarch64 and rs6000 I guess.
2024-03-16 Jakub Jelinek
PR target/114175
*
adds a helper method for the 4 creatikons of
BIT_FIELD_REF which when needed adds a VIEW_CONVERT_EXPR.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-16 Jakub Jelinek
PR tree-optimization/114329
* gimple-lower-bitint.cc (struct bitint_large_huge
On Fri, Mar 15, 2024 at 06:57:18PM +0100, Martin Jambor wrote:
> --- a/gcc/ipa-param-manipulation.cc
> +++ b/gcc/ipa-param-manipulation.cc
> @@ -1525,6 +1525,22 @@ ipa_param_body_adjustments::common_initialization
> (tree old_fndecl,
>replacement with a constant (for split
On Fri, Mar 15, 2024 at 10:20:06AM -0700, Andi Kleen wrote:
> > One issue is the character set question. The strings in inline asm right
> > now are untranslated, i.e. remain in SOURCE_CHARSET, usually UTF-8 (in
> > theory there is also UTF-EBCDIC support, but nobody knows if it actually
> >
-03-15 Jakub Jelinek
PR tree-optimization/113431
* gcc.dg/vect/pr113431.c: Restrict scan-tree-dump-times to
vect_hw_misalign targets.
--- gcc/testsuite/gcc.dg/vect/pr113431.c.jj 2024-01-18 08:44:33.673916652
+0100
+++ gcc/testsuite/gcc.dg/vect/pr113431.c2024
Hi!
When backporting r14-9315 to 13 branch, I've noticed I've missed
one letter in a comment. And grepping for similar issues I found
one word with too many.
Committed to trunk as obvious.
2024-03-15 Jakub Jelinek
* lower-subreg.cc (resolve_simple_move): Fix comment typo
On Thu, Jan 25, 2024 at 04:18:19AM -0800, Andi Kleen wrote:
> Some programing styles use a lot of inline assembler, and it is common
> to use very complex preprocessor macros to generate the assembler
> strings for the asm statements. In C++ there would be a typesafe alternative
> using templates
ust the testcase to use the find_if result, but instead
have added -Wno-unused-result flag to quiet the warning.
The testcase tests side-effects of the lambda used by find_if rather than
its actual result.
Tested on x86_64-linux -m32/-m64, committed to trunk as obvious.
2024-03-15 Jakub Jeli
ok for trunk?
2024-03-15 Jakub Jelinek
PR target/114339
* config/i386/i386-expand.cc (ix86_expand_int_sse_cmp) : Fix
a pasto, compare code against LE rather than GE.
* gcc.target/i386/pr114339.c: New test.
--- gcc/config/i386/i386-expand.cc.jj 2024-03-07 08:34:
on x86_64-linux and i686-linux, ok for trunk?
2024-03-15 Jakub Jelinek
PR middle-end/114332
* expr.cc (expand_expr_real_1): EXTEND_BITINT also CALL_EXPR results.
--- gcc/expr.cc.jj 2024-03-04 19:20:27.120200885 +0100
+++ gcc/expr.cc 2024-03-14 19:22:50.623550538 +0100
should
then extend with memset to 0, not memset to -1.
The following patch achieves that by letting bitint_negate also check if
the negated operand is zero and changes the memset argument based on that.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-15 Jakub Jelinek
On Thu, Mar 14, 2024 at 04:27:22PM -0400, Jason Merrill wrote:
> OK for trunk?
>
> -- 8< --
>
> It came up on the mailing list that OBJECT_BEGIN/END are described as
> marking object lifetime, but mark the beginning of the constructor and end
> of the destructor, whereas the C++ notion of
Hi!
I've noticed a typo in the comment above ABI_VERSION_SPEC.
Fixed thusly, committed to trunk as obvious.
2024-03-14 Jakub Jelinek
* config/gcn/gcn-hsa.h (ABI_VERSION_SPEC): Fix comment typo.
--- gcc/config/gcn/gcn-hsa.h.jj 2024-01-27 13:03:55.589073484 +0100
+++ gcc/config/gcn
On Thu, Mar 14, 2024 at 05:16:59PM +0100, Jan Hubicka wrote:
> Sorry, this was bit of a misunderstanding: I tought you still considered
> the original patch to be full fix, while I tought I should look into it
> more and dig out more issues. This is bit of can of worms. Overall I
> think the
On Thu, Mar 14, 2024 at 11:49:14AM +, Richard Earnshaw (lists) wrote:
> On 14/03/2024 08:37, Jakub Jelinek wrote:
> > Hi!
> >
> > The following testcase ICEs with LSE atomics.
> > The problem is that the @atomic_compare_and_swap expander uses
> > aarch64_reg_
On Thu, Mar 14, 2024 at 09:59:12AM +0100, Richard Biener wrote:
> On Thu, 14 Mar 2024, Jakub Jelinek wrote:
>
> > On Thu, Mar 14, 2024 at 09:48:45AM +0100, Richard Biener wrote:
> > > Ugh. OK, but I wonder whether we might want to simply delay
> > > fixing the
On Thu, Mar 14, 2024 at 09:48:45AM +0100, Richard Biener wrote:
> Ugh. OK, but I wonder whether we might want to simply delay
> fixing the CFG for inserts before returns-twice? Would that make
> things less ugly?
You mean in lower_call just remember if we added anything before
ECF_RETURNS_TWICE
into the link register to emulate pair of zeros.
So, the following patch fixes that by forcing the newval operand into
a register for the TImode LSE case.
Bootstrapped/regtested on aarch64-linux, ok for trunk?
2024-03-14 Jakub Jelinek
PR target/114310
* config/aarch64/aarch64.cc
to be growed (otherwise it is
just a partition_union).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-14 Jakub Jelinek
PR tree-optimization/113466
* gimple-lower-bitint.cc (bitint_large_huge::lower_call): Handle
ECF_RETURNS_TWICE call arguments
, but gsi_bb
and gsi_seq are no longer correct; the patch updates it
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-14 Jakub Jelinek
* gimple-iterator.cc (edge_before_returns_twice_call): Copy all
flags and probability from ad_edge to e edge
On Wed, Mar 13, 2024 at 12:18:45PM +0100, Jan Hubicka wrote:
> > On Wed, Mar 13, 2024 at 10:55:07AM +0100, Jan Hubicka wrote:
> > > > > So the ipa_jump_func are I think the only thing that actually can
> > > > > differ
> > > > > on the ICF merging candidates from value range POV.
> > > >
> > > >
On Wed, Mar 13, 2024 at 06:05:29PM +0800, Xi Ruoyao wrote:
> On Tue, 2024-03-12 at 17:19 +0100, Jakub Jelinek wrote:
> > On Thu, Feb 15, 2024 at 10:53:08PM +, Sam James wrote:
> > > With _FORTIFY_SOURCE >= 2 (enabled by -fhardened), vfprintf-chk-1.c's
> > >
and i686-linux, ok for trunk?
2024-03-13 Jakub Jelinek
PR middle-end/114319
* gimple-ssa-store-merging.cc
(imm_store_chain_info::try_coalesce_bswap): For 32-bit targets
allow matching __builtin_bswap64 if there is bswapsi2 optab.
* gcc.target/i386
On Wed, Mar 13, 2024 at 10:55:07AM +0100, Jan Hubicka wrote:
> > > So the ipa_jump_func are I think the only thing that actually can differ
> > > on the ICF merging candidates from value range POV.
> >
> > I agree. Btw, I would have approved the original patch in this
> > thread that wipes
On Wed, Mar 13, 2024 at 07:37:26AM +0100, Дилян Палаузов wrote:
> Non-parallel build can fail, depending on the ./configure parameters -
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 .
>
> The change below does fix the problem.
CCing build system maintainers and the Go maintainer.
While
the
right size to use anyway because the code uses VIEW_CONVERT_EXPR on it.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-13 Jakub Jelinek
PR middle-end/114313
* gimple-lower-bitint.cc (bitint_large_huge::limb_access): Use
TYPE_SIZE of TREE
On Tue, Mar 12, 2024 at 02:46:07PM +0100, Richard Biener wrote:
> OK.
Thanks. Here is the actually committed version which uses
gsi_safe_insert_before instead.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to
trunk.
2024-03-13 Jakub Jelinek
PR sanitizer/112
On Tue, Mar 12, 2024 at 05:21:58PM +0100, Jakub Jelinek wrote:
> On Tue, Mar 12, 2024 at 10:46:42AM +0100, Jan Hubicka wrote:
> > I am sorry for delaying this. I made the variant that simply compares
> > value range of functions and prevents merging if they diverge and wanted
&
On Tue, Mar 12, 2024 at 10:46:42AM +0100, Jan Hubicka wrote:
> I am sorry for delaying this. I made the variant that simply compares
> value range of functions and prevents merging if they diverge and wanted
> to make some bigger statistics. This made me notice some performance
> problems on
On Thu, Feb 15, 2024 at 10:53:08PM +, Sam James wrote:
> With _FORTIFY_SOURCE >= 2 (enabled by -fhardened), vfprintf-chk-1.c's
> __vfprintf_chk ends up calling __vprintf_chk rather than vprintf.
s/__vprintf_chk/__vfprintf_chk/ above
>
> ```
> --- a/fortify.s
> +++ b/no-fortify.s
> @@ -8,27
line function.
The patch is even shorter then (the asan patch as well).
Tested again with make check-gcc check-g++ RUNTESTFLAGS='ubsan.exp asan.exp'
2024-03-12 Jakub Jelinek
PR sanitizer/112709
* gimple-iterator.h (gsi_safe_insert_before,
gsi_safe_insert_seq_before): D
On Tue, Mar 12, 2024 at 01:47:53PM +0100, Richard Biener wrote:
> > Admittedly the above is the ugliest part of the patch IMHO.
> > It isn't needed in all cases, but e.g. for the pr112709-2.c (qux) case
> > we have before ubsan pass
> > # _7(ab) = PHI <_20(9), _8(ab)(11)>
> > _22 = bar
t;correctly" for abnormals (or add
> split_block_before_returns_twice_call ()). But that's just bike-shedding.
I don't see how is that possible. The usual case is that no split_block
is needed, usually the returns_twice block has just a single normal
predecessor an
case as well as instrumentation of loads from aggregate memory in the
function arguments of returns_twice calls.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-12 Jakub Jelinek
PR sanitizer/112709
* asan.cc (asan_insert_before): New function
o code executed during that point.
The ubsan/pr112709-1.c testcase includes non-virtual PHIs to cover
the handling of those as well.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-12 Jakub Jelinek
PR sanitizer/112709
-linux and i686-linux, ok for trunk?
2024-03-12 Jakub Jelinek
PR sanitizer/112709
* asan.cc (has_stmt_been_instrumented_p): Don't instrument call
stores on the caller side unless it is a call to a builtin or
internal function or function doesn't return by hidden
to that, and we have
choice to only keep the min and use +inf for max, or only keep max
and use 0 for min, or not set the range at all, or use [min, min] or
[max, max] etc. The following patch uses [min, +inf].
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-12 Jakub
Hi!
On Thu, Feb 15, 2024 at 08:29:24AM +0100, Jakub Jelinek wrote:
> 2024-02-15 Jakub Jelinek
>
> PR middle-end/113907
> * ipa-icf.cc (sem_item_optimizer::merge_classes): Reset
> SSA_NAME_RANGE_INFO and SSA_NAME_PTR_INFO on successfully ICF merged
&g
On Mon, Mar 11, 2024 at 11:31:51AM +0100, Richard Biener wrote:
> On Mon, 11 Mar 2024, Jakub Jelinek wrote:
>
> > On Sat, Mar 09, 2024 at 12:25:42PM +0100, Richard Biener wrote:
> > > Ideally we?d clear TREE_ADDRESSABLE but set DECL_NOT_GIMPLE_REG,
> > > I thi
On Mon, Mar 11, 2024 at 11:07:46AM +0100, Tobias Burnus wrote:
> Using dummy procedures in a target region with 'defaultmap(none)' leads to:
>
> Error: 'g' not specified in enclosing 'target'
>
> and this cannot be fixed by using 'firstprivate' as non-pointer dummy routines
> are rejected as
and i686-linux.
2024-03-11 Jakub Jelinek
PR tree-optimization/114278
* tree-ssa.cc (maybe_optimize_var): If large/huge _BitInt vars are no
longer addressable, set DECL_NOT_GIMPLE_REG_P on them.
* gcc.dg/bitint-99.c: New test.
--- gcc/tree-ssa.cc.jj 2024-01
-mnoreturn-no-callee-saved-registers
works, committed to trunk as obvious.
2024-03-09 Jakub Jelinek
* config/i386/i386.opt.urls: Regenerate.
--- gcc/config/i386/i386.opt.urls.jj2024-03-04 19:20:27.060201697 +0100
+++ gcc/config/i386/i386.opt.urls 2024-03-08 18:32:20.527162487
table_p () is taken as the old profitable_p ()
as a requirement rather than just a hint. For propagation of something
which doesn't load from memory this keeps the r14-8319 behavior.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-09 Jakub Jelinek
PR target/114284
trunk?
2024-03-09 Jakub Jelinek
PR tree-optimization/114278
* tree-ssa.cc (maybe_optimize_var): Punt on large/huge _BitInt
vars after bitint lowering.
* gcc.dg/bitint-99.c: New test.
--- gcc/tree-ssa.cc.jj 2024-01-03 11:51:39.902615009 +0100
+++ gcc/tree-
ype and dereferences it.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-08 Jakub Jelinek
PR c++/111284
* constexpr.cc (cxx_bind_parameters_in_call): For PARM_DECLs with
TREE_ADDRESSABLE types use vc_glvalue rather than vc_prva
Jakub Jelinek
PR rtl-optimization/113617
* g++.dg/other/pr113617.C: Define -DSHARED when linking with -shared.
* g++.dg/other/pr113617-aux.cc: Add definitions for used methods and
templates not defined elsewhere.
--- gcc/testsuite/g++.dg/other/pr113617.C.jj2024
asm.
The following patch fixes the assertion to actually check that it is
asm goto.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-08 Jakub Jelinek
* bb-reorder.cc (fix_up_fall_thru_edges): Fix up checking assert,
asm_noperands < 0 means it is not asm go
On Thu, Mar 07, 2024 at 02:25:09PM +, Sam James wrote:
> Jakub Jelinek writes:
>
> > On Thu, Mar 07, 2024 at 02:16:37PM +, Sam James wrote:
> >> 'python' on some systems (e.g. SLES 15) might be Python 2. Prefer
> >> ${EPYTHON}
> >> if defined
On Thu, Mar 07, 2024 at 02:16:37PM +, Sam James wrote:
> 'python' on some systems (e.g. SLES 15) might be Python 2. Prefer ${EPYTHON}
> if defined (used by Gentoo's python-exec wrapping), then python3, then python.
I'd say EPYTHON is too distro specific, just use for python in python3 python
On Thu, Mar 07, 2024 at 12:53:31PM +0100, Thomas Schwinge wrote:
> >From 6a6520e01f7e7118b556683c2934f2c64c6dbc81 Mon Sep 17 00:00:00 2001
> From: Thomas Schwinge
> Date: Thu, 7 Mar 2024 12:31:52 +0100
> Subject: [PATCH] GCN, nvptx: Fatal error for missing symbols in
> 'libhsa-runtime64.so.1',
On Thu, Mar 07, 2024 at 11:11:35AM +0100, Uros Bizjak wrote:
> > Since you CCed me - looking at the code I wonder why we fatally fail.
> > The following might also fix the issue and preserve more of the
> > rest of the flow of the function.
> >
> > If that works I'd prefer it. But I'll defer
here:
grep pp_format_decoder.*=.default_tree_printer analyzer/* | wc -l
57
The following patch fixes that by making sure diagnostic-core.h is included
before pretty-print.h.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-07 Jakub Jelinek
* access-diagram.c
ition on aarch64 before/after this patch
just b .L? jumps which I believe are +-32MB, so if .text is larger than
32MB, it could fail to link, but this patch doesn't address that.
Bootstrapped/regtested on x86_64-linux, i686-linux and aarch64-linux, ok for
trunk?
2024-03-07 Jakub Jelinek
sts that something that could be
expressed as x << 63 would be better expressed as (x * 0x7fff) + 1
In the long term, I think we should just rewrite
choose_mult_variant/synth_mult etc. to work on wide_int.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-
does and triggers UB only if there would be signed multiply
overflow. In the end, the compiler will treat them the same at least at the
RTL level (at least, if not and they aren't the same cost, it should).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-07 Jakub
On Wed, Mar 06, 2024 at 05:28:21PM -0300, Alexandre Oliva wrote:
> On Mar 1, 2024, "Richard Earnshaw (lists)" wrote:
>
> > On 01/03/2024 04:38, Alexandre Oliva wrote:
> >> Thanks for the review.
>
> > For closure, Jakub has just pushed a patch to the generic code, so I
> > don't think we need
Hi!
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/thread.html#645781
[PATCH] c++: Fix up parameter pack diagnostics on xobj vs. varargs functions
[PR113802]
The thread contains two possible further versions of the patch.
So, is the following still ok if it passes bootstrap/regtest?
2024-03-06 Jakub Jelinek
PR tree-optimization/114009
* genmatch.cc (decision_tree::gen): Emit ARG_UNUSED for captures
argument even for GENERIC, not just for GIMPLE.
* match.pd (a * !a -> 0): New si
686-linux, ok for trunk?
2024-03-06 Jakub Jelinek
PR tree-optimization/114009
* match.pd (a * !a -> 0): New simplification.
* gcc.dg/tree-ssa/pr114009.c: New test.
--- gcc/match.pd.jj 2024-03-01 14:56:42.442810053 +0100
+++ gcc/match.pd2024-03-05 22:53:25
Jakub Jelinek
PR rtl-optimization/114190
* config/i386/i386-features.cc (rest_of_handle_insert_vzeroupper):
Call df_remove_problem for df_note before calling df_analyze.
* gcc.target/i386/avx-pr114190.c: New test.
--- gcc/config/i386/i386-features.cc.jj 2024-02
On Tue, Mar 05, 2024 at 07:49:21PM +, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > On Tue, Mar 05, 2024 at 06:30:40PM +, Richard Sandiford wrote:
> >> (1) Keep the test where it is, taking advantage of the current SVE
> >> handling
On Tue, Mar 05, 2024 at 06:30:40PM +, Richard Sandiford wrote:
> (1) Keep the test where it is, taking advantage of the current SVE
> handling in aarch64-sve.exp, and add:
>
> /* { dg-skip-if "" { no_fsanitize_address } } */
I'd go with this. asan/ directory for test would be
On Tue, Mar 05, 2024 at 06:03:41PM +, Richard Sandiford wrote:
> This patch makes the expansion of IFN_ASAN_MARK let through
> poly-int-sized objects. The expansion itself was already generic
> enough, but the tests for the fast path were too strict.
>
> Bootstrapped & regression tested on
On Tue, Mar 05, 2024 at 04:16:00PM +, Jonathan Wakely wrote:
> OK for trunk?
>
> Or am I missing something and the docs are right? (sometimes? always?)
>
>
> -- >8 --
>
> The manual has always claimed that -dD differs from -dM by not
> outputting predefined macros, but that's untrue. It
On Tue, Mar 05, 2024 at 09:29:38AM +0100, Richard Biener wrote:
> I wonder if we need to care about extra temporaries on RTL before
> RA, thus whether always using a temporary would be OK?
I'd still need to do the resolve_reg_p check, otherwise if it is e.g. a
memory, the copying to temporary
On Tue, Mar 05, 2024 at 09:27:22AM +0100, Richard Biener wrote:
> On Tue, 5 Mar 2024, Jakub Jelinek wrote:
> > The following patch adds support for BIT_FIELD_REF lowering with
> > large/huge _BitInt lhs. BIT_FIELD_REF requires mode argument first
> > operand, so the operand
temporary pseudo
to hold the original (reg:DI 128 [ h+8 ]) value across the first store.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-05 Jakub Jelinek
PR rtl-optimization/114211
* lower-subreg.cc (resolve_simple_move): For double-word
first argument of BIT_FIELD_REF and uses MEM_REF with an offset
with VIEW_CONVERT_EXPR around it.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-05 Jakub Jelinek
PR middle-end/114157
* gimple-lower-bitint.cc: Include stor-layout.h
paradoxical subregs of non-scalar_int_mode
REGs/MEMs and for the scalar_int_mode ones should initialize inner_mode
before we use it.
Another option would be to use
maybe_lt (GET_MODE_PRECISION (GET_MODE (SUBREG_REG (op0))), BITS_PER_WORD)
and
load_extend_op (GET_MODE (SUBREG_REG (op0))) == ZERO_
On Mon, Mar 04, 2024 at 03:30:01PM +, Andrew Stubbs wrote:
> vect: Fix integer overflow calculating mask
>
> The masks and bitvectors were broken when nunits==32 on hosts where int is
> 32-bit.
>
> gcc/ChangeLog:
>
> * dojump.cc (do_compare_and_jump): Use full-width integers for
... and as a named argument.
Tested on x86_64-linux, committed to trunk.
2024-03-04 Jakub Jelinek
PR libgomp/114216
* target.c (gomp_target_rev): Change host_fn type and corresponding
cast from void (*)() to void (*) (void *).
--- libgomp/target.c.jj 2024-01-03 12:07
Hi!
We ICE on the following testcase due to invalid tree sharing.
The second hunk fixes that, the first one is from me looking around at
other spots which might need end up with invalid tree sharing too.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-04 Jakub
On Mon, Mar 04, 2024 at 09:34:30AM +0100, Uros Bizjak wrote:
> > --- gcc/config/i386/i386-expand.cc.jj 2024-03-01 14:56:34.120925989 +0100
> > +++ gcc/config/i386/i386-expand.cc 2024-03-03 18:41:08.278793046 +0100
> > @@ -451,6 +451,20 @@ ix86_expand_move (machine_mode mode, rtx
> >
that needs it from the scalar ones,
others should just be folded.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-04 Jakub Jelinek
PR target/114184
* config/i386/i386-expand.cc (ix86_expand_move): If XFmode op1
is SUBREG of CONSTANT_P, force
On Fri, Mar 01, 2024 at 05:19:29PM +0100, Tobias Burnus wrote:
> Jakub Jelinek wrote:
> > As discussed on IRC, I believe not disregarding the capture proxies in
> > target regions if they shouldn't be shared is always wrong, but also the
> > gimplify.cc suggestion was incorrec
On Fri, Mar 01, 2024 at 01:53:08PM +, Richard Earnshaw (lists) wrote:
> On 29/02/2024 17:56, Jakub Jelinek wrote:
> > On Thu, Feb 29, 2024 at 05:51:03PM +, Richard Earnshaw (lists) wrote:
> >> Oh, but wait! Perhaps that now falls into the initial 'if' clause and we
On Fri, Mar 01, 2024 at 09:29:01AM +0100, Tobias Burnus wrote:
> John David Anglin wrote:
> > On 2024-02-29 6:02 p.m., Thomas Schwinge wrote:
> > > I wonder: shouldn't that cap at 50 threads happen inside libgomp,
> > > generally, instead of per test case and user code (!)?
>
> > > Per my
> > >
ence, i.e. this time not all, but the floating point args
were conditionally all saved twice.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-01 Jakub Jelinek
* function.cc (assign_parms): Only call assign_parms_setup_varargs
early for TYPE_NO_NAMED_ARGS_STDARG_P
of preventing the merging
gimple_lower_bitint; we'd then copy from memory to memory and and do the
vce only on the second one, it is just better to vce the first one.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-01 Jakub Jelinek
PR middle-end/114156
On Thu, Feb 29, 2024 at 12:50:47PM +0100, Jakub Jelinek wrote:
> finish_decltype_type uses DECL_HAS_VALUE_EXPR_P (expr) check for
> DECL_DECOMPOSITION_P (expr) to determine if it is
> array/struct/vector/complex etc. subobject proxy case vs. structured
> binding using std::tuple_{
On Fri, Mar 01, 2024 at 01:53:54AM -0300, Alexandre Oliva wrote:
> On Feb 27, 2024, Richard Earnshaw wrote:
>
> > This one has been festering for a while; both Alexandre and Torbjorn
> > have attempted to fix it recently, but I'm not sure either is really
> > right...
>
> *nod* xref
On Thu, Feb 29, 2024 at 05:51:03PM +, Richard Earnshaw (lists) wrote:
> Oh, but wait! Perhaps that now falls into the initial 'if' clause and we
> never reach the point where you pick zero. So perhaps I'm worrying about
> nothing.
If you are worried about the
+ else if
On Thu, Feb 29, 2024 at 05:23:25PM +, Richard Earnshaw (lists) wrote:
> On 29/02/2024 15:55, Jakub Jelinek wrote:
> > On Thu, Feb 29, 2024 at 02:14:05PM +, Richard Earnshaw wrote:
> >>> I tried the above on arm, aarch64 and x86_64 and that seems fine,
> >>&g
On Sat, Feb 17, 2024 at 12:35:48AM +0100, Tobias Burnus wrote:
> Hence, I now use this code, but also pass a flag to distinguish target
> regions (→ map) from shared usage, assuming that it is needed for the
> latter (otherwise, there wouldn't be that code).
>
> The issue only showed up for a
med_args to be number of named arguments except the last, then that
should be 0 rather than 1.
Thus, is the following patch ok for trunk then?
2024-02-29 Jakub Jelinek
PR target/107453
* calls.cc (expand_call): For TYPE_NO_NAMED_ARGS_STDARG_P set
n_named_args initial
On Thu, Feb 29, 2024 at 03:15:30PM +0100, Jan Hubicka wrote:
> I am not wed to the idea (just it appeared to me as an option to
> disabling this optimization by default). I still think it may make sense.
Maybe I misunderstood your idea.
So, you are basically suggesting to go in a completely
On Thu, Feb 29, 2024 at 02:31:05PM +0100, Jan Hubicka wrote:
> I agree that debugability of user core dumps is important here.
>
> I guess an ideal solution would be to change codegen of noreturn functions
> to callee save all registers. Performance of prologue of noreturn
> function is not too
On Thu, Feb 29, 2024 at 02:08:19PM +0100, Richard Biener wrote:
> > So, wouldn't it be better to outline what you have above + POLY_INT_CST
> > handling into a helper function, which similarly to get_range_pos_neg
> > returns a bitmask, but rather than 1 bit for may be [0, max] and another
> >
On Thu, Feb 29, 2024 at 04:26:00AM -0800, H.J. Lu wrote:
> > > Adding Hongtao and Honza into the loop as the ones who acked the original
> > > patch.
> > >
> > > The no_callee_saved_registers by default for noreturn functions change can
> > > break in-process backtrace(3) or backtraces from
, ...).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-29 Jakub Jelinek
PR debug/114015
* dwarf2out.cc (should_move_die_to_comdat): Return false for
aggregates without DW_AT_byte_size attribute or with non-constant
DW_AT_byte_size.
* gcc.dg
else
/* Expr is a reference variable for the tuple case. */
return lookup_decomp_type (expr);
2024-02-29 Jakub Jelinek
PR c++/92687
* decl.cc (cp_finish_decomp): If processing_template_decl, remember
whether std::tuple_{size,element} wil
On Thu, Feb 29, 2024 at 11:16:54AM +0100, Richard Biener wrote:
> That said, the quick experiment shows this isn't anything for stage4.
The earlier the vector lowering is moved in the pass list, the higher
are the possibilities that match.pd or some other optimization reintroduces
unsupportable
On Thu, Feb 29, 2024 at 09:21:02AM +0100, Richard Biener wrote:
> The following switches the logic in chrec_fold_multiply to
> get_range_pos_neg since handling POLY_INT_CST possibly mixed with
> non-poly ranges will make the open-coding awkward and while not
> a perfect fit it should work.
>
> In
301 - 400 of 19067 matches
Mail list logo
