On Mon, Jan 29, 2024 at 08:00:26AM -0800, H.J. Lu wrote:
> Attach REG_CFA_UNDEFINED notes for unsaved callee-saved registers which
> have been used in the function to an instruction in prologue.
>
> gcc/
>
> PR target/38534
> * dwarf2cfi.cc (add_cfi_undefined): New.
>
On Mon, Jan 29, 2024 at 06:36:47AM -0800, H.J. Lu wrote:
> TARGET_ASM_SELECT_RTX_SECTION is for constant in RTL.
> It should have a non-public label reference which can't be used
> by other TUs. The same section can contain other constants.
> If there is a COMAT issue, linker will catch it.
Let
On Mon, Jan 29, 2024 at 03:03:46PM +, Tamar Christina wrote:
> Hi All,
>
> This cherry-picks and squashes the differences between commits
>
> d3e5c20ab846303874a2a25e5877c72271fc798b..76e1e45922e6709392fb82aac44bebe3dbc2ea63
> from LLVM upstream from compiler-rt/lib/hwasan/ to GCC on the
On Mon, Jan 29, 2024 at 05:26:05AM -0800, H.J. Lu wrote:
> Changes in v3:
>
> 1. Add the TREE_THIS_VOLATILE check to minimize noreturn attribute lookup.
>
> Changes in v2:
>
> 1. Lookup noreturn attribute first.
> 2. Use __attribute__((noreturn, optimize("-Og"))) in pr38534-6.c.
>
>
>
On Mon, Jan 29, 2024 at 01:17:16PM +0100, Jakub Jelinek wrote:
> On Mon, Jan 29, 2024 at 01:05:51PM +0100, Richard Biener wrote:
> > The following implements storing to a non-MEM_P with a variable
> > offset. We usually avoid this by forcing expansion to memory but
> > this
On Mon, Jan 29, 2024 at 01:05:51PM +0100, Richard Biener wrote:
> The following implements storing to a non-MEM_P with a variable
> offset. We usually avoid this by forcing expansion to memory but
> this doesn't work for hard register variables. The solution is
> to spill and operate on the
On Sat, Jan 27, 2024 at 07:10:55AM -0800, H.J. Lu wrote:
> For function symbol reference in readonly data section, instead of putting
> it in .data.rel.ro or .rodata.cst section, call function_rodata_section to
> get the read-only or relocated read-only data section associated with the
> function
On Mon, Jan 29, 2024 at 11:24:58AM +0100, Richard Biener wrote:
> The following expands .VEC_SET and .VEC_EXTRACT instruction selection
> to global hard registers, not only automatic variables (possibly)
> promoted to registers. This can avoid some ICEs later and create
> better code.
>
>
On Sat, Jan 27, 2024 at 07:00:03AM -0800, H.J. Lu wrote:
> On Sat, Jan 27, 2024 at 6:09 AM Jakub Jelinek wrote:
> >
> > On Sat, Jan 27, 2024 at 05:52:34AM -0800, H.J. Lu wrote:
> > > @@ -3391,7 +3392,9 @@ ix86_set_func_type (tree fndecl)
> > > function is ma
On Sat, Jan 27, 2024 at 12:41:24PM -0800, H.J. Lu wrote:
> When assembler directives for DWARF frame unwind is enabled, generate
> the .cfi_undefined directive for unsaved callee-saved registers which
> have been used in the function.
>
> gcc/
>
> PR target/38534
> *
e reason this is harmless, just confusing, is that the code a few lines
later fortunately overwrites this incorrect pdata->maxlen value with
something different (either array length - 1 or all ones etc.).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-01-29 Jakub Je
On Sun, Jan 28, 2024 at 02:07:33PM +, Iain Sandoe wrote:
> In order to handle system security constraints during GCC build
> and test and that most platform versions cannot link to libgcc_eh
> since the unwinder there is incompatible with the system one.
>
> 1. We make the support functions
On Sun, Jan 28, 2024 at 02:07:32PM +, Iain Sandoe wrote:
> This removes the heap trampoline support functions from libgcc.a and
> adds them to libgcc_eh.a. They are also present in libgcc_s.
>
> PR libgcc/113403
>
> libgcc/ChangeLog:
>
> * config/aarch64/t-heap-trampoline: Move
On Sat, Jan 27, 2024 at 05:52:34AM -0800, H.J. Lu wrote:
> @@ -3391,7 +3392,9 @@ ix86_set_func_type (tree fndecl)
> function is marked as noreturn in the IR output, which leads the
> incompatible attribute error in LTO1. */
>bool has_no_callee_saved_registers
> -=
with division, modulo or
conversions to floating point.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-01-27 Jakub Jelinek
PR tree-optimization/113614
* gimple-lower-bitint.cc (gimple_lower_bitint): Don't merge
widening casts from signed
uld be handled didn't handle
the VCE case and so handle_plus_minus was called from the conditional
handle_cast.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2024-01-27 Jakub Jelinek
PR tree-optimization/113568
* gimple-lower-bitint
/RESULT_DECLs)
each SSA_NAME in large_huge.m_names bitmap maps to.
So, the following patch adds dumping of that, so that we know that say
_3 -> bitint.3
_8 -> bitint.7
_16 -> bitint.7
etc.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-01-27 Jakub Jelinek
is true, subtract vv1 from uv1:uv0
again and add 2 * vv1 to rhat, no __builtin_add_overflow is needed
as we know it always overflowed and so won't goto again.
If after the first subtraction uv1 < vv1, use __builtin_add_overflow
when adding vv1 to rhat, because it can but doesn't have to overflow.
On Fri, Jan 26, 2024 at 03:16:15PM +0100, Richard Biener wrote:
> The inliner puts variables for parameters of the inlined functions
> in the inline scope in reverse order. The following reverses them
> again so that we get consistent ordering between the
> DW_TAG_subprogram
On Fri, Jan 26, 2024 at 03:04:11PM +0100, Richard Biener wrote:
> > > Otherwise it looks reasoanble to me, but let's see what Andrew thinks.
> >
> > 'n' before 'a', please. ;-)
>
> ?!
I've misspelled a word.
> @@ -1443,6 +1445,16 @@ suitable_hsa_agent_p (hsa_agent_t agent)
>switch
On Fri, Jan 26, 2024 at 01:00:28PM +0100, Richard Biener wrote:
> The following avoids registering unsupported GCN offload devices
> when iterating over available ones. With a Zen4 desktop CPU
> you will have an IGPU (unspported) which will otherwise be made
> available. This causes testcases
+ (sizetype) e it computes
p+ (sizetype) e, which is ((A *) ) p+ 24.
The following patch fixes it by using convert instead of cp_convert which
eventually calls build_nop (ptype, datum).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-01-25 Jakub Jelinek
PR c++/113599
, and the shift count is 2 in that case.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-01-25 Jakub Jelinek
PR middle-end/113574
* convert.cc (convert_to_integer_1) : Compare shift
count against TYPE_PRECISION rather than TYPE_SIZE
Hi!
When looking into PR113572, I've noticed a typo in VECTOR_CST documentation
and grep found pasto of it elsewhere.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk
as obvious.
2024-01-25 Jakub Jelinek
* doc/generic.texi (VECTOR_CST): Fix typo - petterns
On Wed, Jan 24, 2024 at 10:37:47AM +0100, Rainer Orth wrote:
> A couple of gcc.dg/vect/vect-simd-clone-1*.c tests FAIL on 32-bit
> Solaris/x86 since 20230222:
>
> FAIL: gcc.dg/vect/vect-simd-clone-16c.c scan-tree-dump-times vect
> "[nr] [^n]* = foo.simdclone" 2
> FAIL:
On Tue, Jan 23, 2024 at 11:10:05AM +0100, Jakub Jelinek wrote:
> > --- a/gcc/config/ia64/ia64.cc
> > +++ b/gcc/config/ia64/ia64.cc
> > @@ -3886,7 +3886,7 @@ ia64_expand_prologue (void)
> > /* Output the textual info surrounding the prologue. */
> >
> >
On Tue, Jan 23, 2024 at 01:40:15PM +0100, Richard Biener wrote:
> It's never going to be 3 vs 2 but 3 * 2^n vs. 3 * 2^m so floor or
> ceil doesn't matter. In fact we could have just using
> some inverse of exact_log2 (n->simdclone->simdlen). That is,
> it's only simdlen that's varying in this
On Tue, Jan 23, 2024 at 01:03:46PM +0100, Richard Biener wrote:
> On Tue, 23 Jan 2024, Jakub Jelinek wrote:
>
> > On Tue, Jan 23, 2024 at 12:56:52PM +0100, Richard Biener wrote:
> > > The following avoids using exact_log2 on the number of SIMD clone calls
> > >
On Tue, Jan 23, 2024 at 12:56:52PM +0100, Richard Biener wrote:
> The following avoids using exact_log2 on the number of SIMD clone calls
> to be emitted when vectorizing calls since that can easily be not
> a power of two in which case it will return -1. For different simd
> clones the number of
On Tue, Jan 16, 2024 at 07:32:03PM -0700, Jeff Law wrote:
>
>
> On 1/15/24 02:22, Ilya Leoshkevich wrote:
> > Compile tested for the ia64-elf target; bootstrap and regtest running
> > on x86_64-redhat-linux. Ok for trunk when successful?
> >
> >
> >
> > ia64-elf build fails with the
?
2024-01-23 Jakub Jelinek
* config/gcn/gcn.cc (gcn_hsa_declare_function_name): Add
ATTRIBUTE_UNUSED to decl.
--- gcc/config/gcn/gcn.cc.jj2024-01-08 16:13:18.625940507 +0100
+++ gcc/config/gcn/gcn.cc 2024-01-23 10:47:33.945954494 +0100
@@ -6565,7 +6565,8
of those.
The following patch fixes it, while the function currently is only called
in the C FE because C++ doesn't support BITINT_TYPE, I think guarding the
calls on !c_dialect_cxx () is safer.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-01-22 Jakub Jelinek
C_TEST_RUN_EXPENSIVE=1
RUNTESTFLAGS="GCC_TEST_RUN_EXPENSIVE=1 dg.exp='*bitint* pr112673.c
builtin-stdc-bit-*.c pr112566-2.c pr112511.c' dg-torture.exp=*bitint*
dfp.exp=*bitint*"
(my usual quick test for bitint related changes). Ok for trunk if it passes
full bootstrap/regtest?
On Mon, Jan 22, 2024 at 11:27:52AM +0100, Richard Biener wrote:
> We run into
>
> static tree
> native_interpret_int (tree type, const unsigned char *ptr, int len)
> {
> ...
> if (total_bytes > len
> || total_bytes * BITS_PER_UNIT > HOST_BITS_PER_DOUBLE_INT)
> return NULL_TREE;
>
>
On Sat, Jan 20, 2024 at 12:11:10PM +0100, Richard Biener wrote:
> > The following patch ICEs because fre3 leaves around unfolded
> > _1 = VIEW_CONVERT_EXPR<_BitInt(129)>(0);
>
> Hmm, const_unop should handle this, I suppose either we fail to convert this
> to a NOP_EXPR or native
e same, as the handle_operand recursion
handles those.
Of course, maybe we should also try to fold_stmt such cases somewhere in
bitint lowering preparation.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-01-20 Jakub Jelinek
PR tree-optimization/113462
*
the index obviously needs to be done in unsigned __int128 or large/huge
BITINT_TYPE, but then we cast to sizetype if the precision is larger than
sizetype
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-01-20 Jakub Jelinek
PR tree-optimization/113491
Hi!
Like for GIMPLE_PHIs or calls, even for GIMPLE_ASMs we want
a corresponding VAR_DECL assigned for lhs SSA_NAMEs of loads
from memory, as even GIMPLE_ASM relies on those VAR_DECLs to exist.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-01-19 Jakub Jelinek
restrict this to non-narrowing conversions.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-01-19 Jakub Jelinek
PR tree-optimization/113463
* gimple-ssa-warn-restrict.cc (builtin_memref::extend_offset_range):
Only look through NOP_EXPRs if rhs1
/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-01-19 Jakub Jelinek
PR tree-optimization/113459
* tree-ssa-sccvn.cc (vn_walk_cb_data::push_partial_def): Use
TREE_INT_CST_LOW of TYPE_SIZE_UNIT rather than GET_MODE_SIZE
of SCALAR_INT_TYPE_MODE if type has
On Thu, Jan 18, 2024 at 02:59:23PM +, Iain Sandoe wrote:
> --- a/gcc/builtins.cc
> +++ b/gcc/builtins.cc
> @@ -8416,6 +8416,11 @@ expand_builtin (tree exp, rtx target, rtx subtarget,
> machine_mode mode,
> case BUILT_IN_ADJUST_DESCRIPTOR:
>return expand_builtin_adjust_descriptor
On Thu, Jan 18, 2024 at 02:13:55PM +0100, Jakub Jelinek wrote:
> The == BITINT_TYPE check is non-essential, was just trying to keep existing
> behavior otherwise. I can certainly drop that.
So following then?
2024-01-18 Jakub Jelinek
Richard Biener
* cfgexp
On Thu, Jan 18, 2024 at 01:57:49PM +0100, Richard Biener wrote:
> > - RTL expansion expectes TARGET_MEM_REF to always address actual
> > memory. */
> > + RTL expansion expectes TARGET_MEM_REF to always address actual memory.
> > + Also, force to stack non-BLKmode vars accessed
art helps for -O2, the expr.cc part is needed at all optimization levels.
2024-01-18 Jakub Jelinek
* cfgexpand.cc (discover_nonconstant_array_refs_r): Force non-BLKmode
VAR_DECLs referenced in BLKmode VIEW_CONVERT_EXPRs into memory.
* expr.cc (expand_expr_real_1) :
On Thu, Jan 18, 2024 at 01:16:45PM +0100, Richard Biener wrote:
> > This doesn't actually do anything, because the base is TREE_ADDRESSABLE.
> > The var gets both with -O0 and -O2 DECL_RTL like
> > (mem/c:OI (plus:DI (reg/f:DI 95 virtual-stack-vars)
> > (const_int -64
On Thu, Jan 18, 2024 at 01:11:56PM +0100, Rainer Orth wrote:
> Andreas Schwab writes:
>
> > * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.
>
> Speaking of baselines: is this a good time to update them for other
> targets, too, or should we better wait a little longer?
I
And
--- gcc/expr.cc.jj 2024-01-12 10:07:58.194851657 +0100
+++ gcc/expr.cc 2024-01-18 12:08:16.412147569 +0100
@@ -12382,6 +12382,21 @@ expand_expr_real_1 (tree exp, rtx target
}
}
+ /* Ensure non-BLKmode array VAR_DECLs VCEd to BLKmode BITINT_TYPE
+aren't
On Thu, Jan 18, 2024 at 08:27:51AM +0100, Richard Biener wrote:
> On Thu, 18 Jan 2024, Jakub Jelinek wrote:
>
> > Hi!
> >
> > On aarch64 the backend decides to use non-BLKmode for some arrays
> > like unsigned long[4] - OImode in that case, but the corresponding
?
2024-01-18 Jakub Jelinek
* config/riscv/riscv.opt (mshorten-memrefs, mrelax, mcsr-check,
minline-strcmp, minline-strncmp, minline-strlen,
-param=riscv-vector-abi): Remove Bool keywords.
--- gcc/config/riscv/riscv.opt.jj 2024-01-18 08:44:33.441919890 +0100
On Thu, Jan 18, 2024 at 08:40:04AM +0100, Richard Biener wrote:
> > This test FAILs on i686-linux or e.g. sparc*-solaris*, because
> > it uses vect_int effective target outside of */vect/ testsuite.
> > That is wrong, vect_int assumes the extra added flags by vect.exp
> > by default, which aren't
the test into gcc.dg/vect/
and doing small tweaks.
Regtested on x86_64-linux and i686-linux, ok for trunk?
2024-01-18 Jakub Jelinek
PR tree-optimization/112774
PR testsuite/113446
* gcc.dg/tree-ssa/scev-16.c: Move test ...
* gcc.dg/vect/pr112774.c: ... here. Add PR
ans
for not being present.
I think we should just disable vectorization here.
Regtested on x86_64-linux and i686-linux, ok for trunk?
2024-01-18 Jakub Jelinek
PR testsuite/113452
* gcc.target/i386/sse4_1-stv-1.c: Add -fno-tree-vectorize to
dg-options.
--- gcc/testsu
ile eventually, so that people don't copy this around.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-01-18 Jakub Jelinek
PR other/113399
* common.opt (ffold-mem-offsets): Remove Target and Bool keywords, add
Common and Optimization.
---
/tmp/1 /tmp/2; done
that the emitted sequences are identical after assembly.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-01-18 Jakub Jelinek
PR target/113122
* config/i386/i386.cc (x86_function_profiler): Add -masm=intel
support. Add mis
).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-01-18 Jakub Jelinek
* gimple-lower-bitint.cc (gimple_lower_bitint): When creating
array VAR_DECL for BITINT_TYPE SSA_NAMEs which have BLKmode, force
DECL_MODE of those vars to be BLKmode as well
On Wed, Jan 17, 2024 at 03:40:20PM +, Maxim Kuvyrkov wrote:
> ... caused by scheduler fix for PR96388 and PR111554.
>
> This patch adjusts decision sched-deps.cc:find_inc() to use
> length of dependency lists sans any DEBUG_INSN instructions.
>
> gcc/ChangeLog:
>
Please mention
PR
On Wed, Jan 17, 2024 at 03:46:44PM +0100, Martin Jambor wrote:
> > Note, it would be good if we were able to punt on the optimization
> > (but this code doesn't seem to be able to punt, so it needs to be done
> > somewhere earlier) at least in cases where building it would be invalid.
> > E.g.
ning does not work as expected.
>
> I also updated the code to be bit more careful about merging values and do not
> downgrade the precision when unnecesary (as tested by new testcases).
>
> Bootstrapped/regtested x86_64-linux, will commit it tomorrow if there are
> no complains.
>
Hi!
This testcase started to hang at -O3 with r13-4208 and got fixed
with r14-2097.
Regtested on x86_64-linux and i686-linux, committed to trunk as obvious.
2024-01-17 Jakub Jelinek
PR tree-optimization/110251
* gcc.c-torture/compile/pr110251.c: New test.
--- gcc/testsuite
?
2024-01-17 Jakub Jelinek
PR middle-end/113410
* gimple-ssa-warn-access.cc (pass_waccess::maybe_check_access_sizes):
If access_nelts is integral with larger precision than sizetype,
fold_convert it to sizetype.
* gcc.dg/bitint-72.c: New test.
--- gcc
Hi!
When looking at PR113410, I found a comment typo and just searched for
the same typo elsewhere and found some typos in the comments which had
that typo as well.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to
trunk as obvious.
2024-01-17 Jakub Jelinek
* tree
didn't.
The following patch implements that.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-01-17 Jakub Jelinek
PR tree-optimization/113421
* gimple-lower-bitint.cc (stmt_needs_operand_addr): Adjust function
comment.
(bitint_dom_walker
. cases iterate
more than what those types can represent, like is the case of e.g. __int128
iterators too) and the testcase also covers linear/reduction clauses for them.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2024-01-17 Jakub Jelinek
PR middle-end/113409
-linux, ok for trunk?
2024-01-17 Jakub Jelinek
PR tree-optimization/113408
* gimple-lower-bitint.cc (bitint_large_huge::handle_stmt): For
VIEW_CONVERT_EXPR, pass TREE_OPERAND (rhs1, 0) rather than rhs1
to handle_cast.
* gcc.dg/bitint-71.c: New test.
--- gcc
Jakub Jelinek
PR middle-end/113406
* ipa-strub.cc (pass_ipa_strub::execute): Check aggregate_value_p
regardless of whether is_gimple_reg_type (restype) or not.
* gcc.dg/bitint-70.c: New test.
--- gcc/ipa-strub.cc.jj 2024-01-03 11:51:28.374775006 +0100
+++ gcc/ipa
On Wed, Jan 17, 2024 at 09:04:08AM +, Iain Sandoe wrote:
> > On 17 Jan 2024, at 08:55, Iain Sandoe wrote:
> >
> > Tested on x86_64, aarch64 Darwin21 (which default to heap-based trampolines)
> > and on x86_64 Darwin19 and Linux (which default to executable stack
> > trampolines).
> > OK for
On Wed, Jan 17, 2024 at 09:17:09AM +0100, Daniel Cederman wrote:
> On 2024-01-16 15:44, Jakub Jelinek wrote:
> > On Tue, Jan 16, 2024 at 03:11:39PM +0100, Daniel Cederman wrote:
> > > When GCC is configured with --enable-target-optspace the compiler
> > > ge
On Tue, Jan 16, 2024 at 07:29:04PM -0800, Andrew Pinski wrote:
> So the problem here is that aarch64_ldp_reg_operand will all subreg even
> subreg of lo_sum.
> When LRA tries to fix that up, all things break. So the fix is to change the
> check to only
> allow reg and subreg of regs.
>
> Note
On Tue, Jan 16, 2024 at 03:11:39PM +0100, Daniel Cederman wrote:
> When GCC is configured with --enable-target-optspace the compiler generates
> a memcpy call in the Symbolizer constructor in sanitizer_symbolizer.cpp
> when compiling for SPARC V8. Add HAVE_AS_SYM_ASSIGN to replace it with a
> call
On Tue, Jan 16, 2024 at 10:00:09AM +0100, Richard Biener wrote:
> I'm not sure how fancy we need to get with this workaround, so
> changing to INTEGRAL_TYPE_P works for me.
I'll go for it.
BTW, I've also built linux kernel allyesconfig, and in there
per the statistics gathering patch there are
.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-01-16 Jakub Jelinek
PR libgcc/113402
* libgcc-std.ver.in (GCC_7.0.0): Move
__builtin_nested_func_ptr_created and
__builtin_nested_func_ptr_deleted from this symbol version
for the ADDR_EXPR vs. OMP_SCAN constant in the two spots.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Or should I just use INTEGRAL_TYPE_P instead of ptrofftype_p?
2024-01-15 Jakub Jelinek
PR tree-optimization/113372
PR middle-end/90348
PR middle-end/110115
Hi!
The ICE on this testcase was fixed by r14-7141.
Tested on x86_64-linux -m32/-m64 with current trunk as well as older
trunk which still ICEd, committed to trunk as obvious.
2024-01-15 Jakub Jelinek
PR rtl-optimization/113048
* gcc.target/i386/pr113048.c: New test
On Mon, Jan 15, 2024 at 02:54:26PM +, Qing Zhao wrote:
> So, before gimplification, when inserting tree node, we don’t need manually
> add unshare_expr since the gimplification will automatically unshare nodes.
There are cases where unshare_expr is needed even then, such as the uses in
the
for 2 limbs only if m_upwards_2limb and remainder for
1 limb otherwise.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-01-15 Jakub Jelinek
PR tree-optimization/113370
* gimple-lower-bitint.cc (bitint_large_huge::handle_operand): Only
set rem
sing long weren't changed to long long, so the testcase still warns
about UB in shifts.
Excess errors:
.../gcc/gcc/testsuite/gcc.dg/vect/vect-early-break_100-pr113287.c:28:48:
warning: right shift count >= width of type [-Wshift-count-overflow]
Fixed thusly, committed to trunk as obvious.
2024-
rec attempts to increase mp precision until it
isn't small anymore.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-01-13 Jakub Jelinek
PR tree-optimization/113361
* gimple-lower-bitint.cc (bitint_large_huge::handle_operand_addr):
Fix up determinat
tested
on the new testcases.
2024-01-12 Jakub Jelinek
gcc/cp/
* mangle.cc (write_nested_name): Mangle explicit object
member functions with H as per
https://github.com/itanium-cxx-abi/cxx-abi/issues/148 non-proposal.
gcc/testsuite/
* g++.dg/abi/mangle79.C: New test
should be already created.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
2024-01-12 John David Anglin
Jakub Jelinek
PR middle-end/113182
* varasm.cc (process_pending_assemble_externals,
assemble_external_libcall): Use
eck here whether the most significant bit is
set or clear.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2024-01-12 Jakub Jelinek
PR tree-optimization/113334
* gimple-lower-bitint.cc (bitint_large_huge::handle_operand): Use
wi::neg_p
true.
Regtested on x86_64-linux and i686-linux, committed to trunk as obvious.
2024-01-12 Jakub Jelinek
* gcc.dg/bitint-31.c: Fix up #if conditions checking whether
__*_MANT_DIG__ is equal to a particular precision.
--- gcc/testsuite/gcc.dg/bitint-31.c.jj 2023-11-09 09:04
on x86_64-linux and i686-linux, ok for trunk?
2024-01-12 Jakub Jelinek
PR tree-optimization/113330
* tree-sra.cc (create_access): Punt for BITINT_TYPE accesses with
too large size.
* gcc.dg/bitint-69.c: New test.
--- gcc/tree-sra.cc.jj 2024-01-10 12:45
something different there,
or on say INTEGER_TYPEs the precision will never be large enough to be
>= bitint_prec_large).
The following patch fixes that, bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk?
2024-01-12 Jakub Jelinek
PR tree-optimization/113323
* gim
24-01-12 Jakub Jelinek
PR tree-optimization/113316
* gimple-lower-bitint.cc (bitint_large_huge::lower_call): Handle
uninitialized large/huge _BitInt arguments to calls.
* gcc.dg/bitint-67.c: New test.
--- gcc/gimple-lower-bitint.cc.jj 2024-01-11 11:46:49.1
appear in ARRAY_REFs.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-01-12 Jakub Jelinek
PR c/113315
* c-typeck.cc (build_array_ref): If index has BITINT_TYPE type with
precision larger than sizetype precision, convert it to sizetype
On Thu, Jan 11, 2024 at 12:12:59PM +0100, Jakub Jelinek wrote:
> So, the problem was that in 2 spots I was comparing TYPE_SIZE of large/huge
> BITINT_TYPEs to determine if it can be handled cheaply.
> On x86_64 with limb_mode == abi_limb_mode (both DImode) that works fine,
> if TYPE_S
On Fri, Jan 12, 2024 at 07:40:19AM +, waffl3x wrote:
> Bootstrapped and tested on x86_64-linux with no regressions.
>
> I'm still getting used to things so let me know if the change log
> entries are excessive, thanks.
> From 9dc168e7bcbbd7d515fa28cb9cae28ec113fae0f Mon Sep 17 00:00:00 2001
On Thu, Jan 04, 2024 at 08:43:26PM -0500, Lipeng Zhu wrote:
> This patch try to fix the bug when HAVE_ATOMIC_FETCH_ADD is
> not defined in dec_waiting_unlocked function. As io.h does
> not include async.h, the WRLOCK and RWUNLOCK macros are
> undefined.
>
> libgfortran/ChangeLog:
>
> *
On Thu, Jan 11, 2024 at 09:53:33AM +0100, Jakub Jelinek wrote:
> On Wed, Jan 10, 2024 at 07:05:39PM +, Andre Vieira (lists) wrote:
> > This patch is still work in progress, but posting to show failure with
> > bitint-7 test where handle_stmt called from lower_mergeable_stmt IC
On Wed, Jan 10, 2024 at 07:05:39PM +, Andre Vieira (lists) wrote:
> This patch is still work in progress, but posting to show failure with
> bitint-7 test where handle_stmt called from lower_mergeable_stmt ICE's
> because the idx (3) is out of range for the __BitInt(135) with a limb_prec
> of
++ -j32 -k GCC_TEST_RUN_EXPENSIVE=1
RUNTESTFLAGS="GCC_TEST_RUN_EXPENSIVE=1 dg.exp='*bitint* pr112673.c
builtin-stdc-bit-*.c pr112566-2.c pr112511.c' dg-torture.exp=*bitint*
dfp.exp=*bitint*"
Ok for trunk if it passes full bootstrap/regtest?
2024-01-11 Jakub Jelinek
* libgcc2.h
On Wed, Jan 10, 2024 at 06:07:16PM +, Tamar Christina wrote:
> This changes the tests I committed for PR113287 to also
> run on targets that don't support bitint.
>
> Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu and no issues and
> tests run on both.
>
> Ok for master?
Yes,
On Wed, Jan 10, 2024 at 04:55:00PM +, Tamar Christina wrote:
> PR tree-optimization/113287
> * gcc.dg/vect/vect-early-break_100-pr113287.c: Support non-bitint.
This part is ok.
> --- a/gcc/testsuite/gcc.dg/vect/vect-early-break_99-pr113287.c
> +++
Hi!
This test was already fixed by r14-6051 aka PR112770 fix.
Tested on x86_64-linux, committed to trunk as obvious.
2024-01-10 Jakub Jelinek
PR tree-optimization/112734
* gcc.dg/bitint-64.c: New test.
--- gcc/testsuite/gcc.dg/bitint-64.c.jj 2024-01-10 17:17:08.438466886
On Wed, Jan 10, 2024 at 02:47:29PM +, Richard Sandiford wrote:
> Alex Coplan writes:
> > As discussed on IRC, this makes the aarch64 ldp/stp pass off by default.
> > This
> > should stabilize the trunk and give some time to address the P1 regressions.
> >
> > Sorry for the breakage.
> >
> >
On Wed, Jan 10, 2024 at 02:45:41PM +, Tamar Christina wrote:
> > -Original Message-
> > From: Jakub Jelinek
> > Sent: Wednesday, January 10, 2024 2:42 PM
> > To: Tamar Christina ; Richard Biener
> >
> > Cc: gcc-patches@gcc.gnu.org; nd ; j...@vent
Hi!
Thanks for fixing it, just testsuite nits.
On Wed, Jan 10, 2024 at 03:22:53PM +0100, Richard Biener wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/vect/vect-early-break_100-pr113287.c
> > @@ -0,0 +1,35 @@
> > +/* { dg-add-options vect_early_break } */
> > +/* {
uite/flock}
>
> So expect tries to literally execute '$(abs_top_srcdir)/testsuite/flock'
> which cannot work.
Does the following work then?
Using autoconf's internal _AC_SRCDIRS macro doesn't seem to be a good idea
to me, so I've copied what e.g. libobjc configure does instead.
On Wed, Jan 10, 2024 at 10:51:32AM +0100, Richard Biener wrote:
> > @@ -2742,8 +2743,11 @@ analyze_access_subtree (struct access *r
> > tree rt = root->type;
> > gcc_assert ((root->offset % BITS_PER_UNIT) == 0
> > && (root->size % BITS_PER_UNIT) == 0);
> > -
n't ICE,
so maybe it ran into some other SRA limit.
2024-01-10 Jakub Jelinek
PR tree-optimization/113120
* tree-sra.cc (analyze_access_subtree): For BITINT_TYPE
with root->size TYPE_PRECISION don't build anything new.
Otherwise, if root->type is a BITINT_
701 - 800 of 19171 matches
Mail list logo
