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 https://gcc.
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_{
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/1
+.L12:
difference, 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 T
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
> > > un
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
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 inc
hat is the only mode 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
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
> >
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
rough ... 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
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 shifts
ized.
I think we shouldn't worry about 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
l
the whole
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 sto
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
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
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 woul
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 has
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 aa
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 neede
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
ok for trunk?
2024-03-06 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/i3
n x86_64-linux and i686-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.pd
g that is really
too hard to optimize.
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.
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.
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/thread.ht
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 t
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 J
ge costs 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?
blocks-and-partition 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 Jaku
ter everywhere:
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
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 appro
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', 'l
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 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}
> >>
t inline 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 i
03-08 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.jj
to the desired type 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 rat
i686-linux, ok for 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
likely_profitable_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
html#index-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
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
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 "E
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 think t
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
t can lead 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
/regtested on x86_64-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
t as there is no 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 s
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
ppened.
> Or alternatively not expose
> gsi_insert_before_returns_twice_call but instead make
> split_block () behave "correctly" for abnormals (or add
> split_block_before_returns_twice_call ()). But that's just bike-shedding.
I don't see how is th
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 (*_7(ab)
helper inline 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_i
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 +
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 clan
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 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
like 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
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
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 SSA_NA
sted on x86_64-linux 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.
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
> >
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.
> > > >
> > > >
, 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
eeds 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
o 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/aarch
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
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 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 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 plan
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/confi
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 lifetim
zero (that is ok), but we 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?
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
86-linux, 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
just 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
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 a
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 co
-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
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
> > works
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 aggr
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
rly looking snippet in their hooks
changed by the r13-3549 commit.
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 J
ok for 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.
-
return
pointer.
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.jj2
part 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/11436
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
git grepped for 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-
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
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 SCEV
On Tue, Mar 19, 2024 at 01:14:51PM +, Qing Zhao wrote:
> Currently, the OST_DYNAMIC information is not passed to
> early_object_sizes phase. Pass this information to it, and adjust the code
> and testing case accordingly.
Can you explain why do you think this is desirable?
Having both passe
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. Instead of possibly slowing things down by using
> widest_int the following makes
lt;< _19;
where instead of _33 the _36 def stmt should be using _34.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2024-03-20 Jakub Jelinek
PR tree-optimization/114365
* gimple-lower-bitint.cc (bitint_large_huge::handle_load): When addin
trunk (or defer for stage1, though guess I'd need to redo it
from scratch at that point)?
2024-03-20 Jakub Jelinek
gcc/analyzer/
* constraint-manager.cc (test_range, test_constraint_conditions,
test_constant_comparisons, test_constraint_impl, test_purging,
test_
Hi!
When looking at PR109596, I've noticed some comment typos.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as
obvious.
2024-03-20 Jakub Jelinek
* tree-ssa-loop-ch.cc (update_profile_after_ch): Fix comment typo:
probabbility -> pro
Hi!
Like for x86-64, alpha or rs6000, csky 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-20 Jakub Jelinek
PR target/114175
* config/csky/csky.cc
Hi!
Like for x86-64, alpha or rs6000, epiphany 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-20 Jakub Jelinek
PR target/114175
* config/epiphany/epiphany.cc
Hi!
Like for x86-64, alpha or rs6000, ft32 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-20 Jakub Jelinek
PR target/114175
* config/ft32/ft32.cc
Hi!
Like for x86-64, alpha or rs6000, m32r 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-20 Jakub Jelinek
PR target/114175
* config/m32r/m32r.cc
Hi!
Like for x86-64, alpha or rs6000, nds32 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-20 Jakub Jelinek
PR target/114175
* config/nds32/nds32.cc
Hi!
Like for x86-64, alpha or rs6000, nios2 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-20 Jakub Jelinek
PR target/114175
* config/nios2/nios2.cc
Hi!
Like for x86-64, alpha or rs6000, visium 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-20 Jakub Jelinek
PR target/114175
* config/visium/visium.cc
601 - 700 of 18704 matches
Mail list logo