On 3/11/24 4:38 PM, Eric Botcazou wrote:
Hi,
this is a regression present on all active branches: the attached Ada testcase
triggers an assertion failure when compiled with -O2 -gnatp -flto:
/* Initialize the static chain. */
p = DECL_STRUCT_FUNCTION (fn)->static_chain_decl;
gcc_as
On 3/11/24 1:46 AM, Richard Biener wrote:
On Sun, Mar 10, 2024 at 10:09 PM Jeff Law wrote:
On 3/10/24 3:05 PM, Andrew Pinski wrote:
On Sun, Mar 10, 2024 at 2:04 PM Jeff Law wrote:
Here's a potential approach to fixing PR92539, a P2 -Warray-bounds false
positive triggered by
On 3/13/24 4:22 AM, Richard Biener wrote:
... this hunk is OK (please test and split it out separatley). In the spirit of
moving the stmt the least amount (in this case not schedule it within the
basic-block). In the same spirit one would choose an earlier basic-block
but only if the old c
On 3/16/24 11:35 AM, Vineet Gupta wrote:
Noticed that new sum of two s12 splitter was generating following:
| 059930 :
| 59930: add sp,sp,-16
| 59934: lui t0,0xf
| 59938: sd s0,0(sp)
| 5993c: sd ra,8(sp)
| 59940: add sp,sp,t0
| 59
On 3/16/24 11:35 AM, Vineet Gupta wrote:
If the constant used for stack offset can be expressed as sum of two S12
values, the constant need not be materialized (in a reg) and instead the
two S12 bits can be added to instructions involved with frame pointer.
This avoids burning a register and m
On 3/16/24 11:35 AM, Vineet Gupta wrote:
... if the constant can be represented as sum of two S12 values.
The two S12 values could instead be fused with subsequent ADD insn.
The helps
- avoid an additional LUI insn
- side benefits of not clobbering a reg
e.g.
On 3/17/24 2:22 PM, Christoph Müllner wrote:
On Fri, Apr 28, 2023 at 8:12 AM Christoph Muellner
wrote:
From: Christoph Müllner
The current implementation triggers an assertion in
dwarf2out_frame_debug_cfa_offset() under certain circumstances.
The standard code uses REG_FRAME_RELATED_EXPR
On 2/27/24 1:52 AM, Jiawei wrote:
From: Chen Jiawei
Co-Authored by: Lin Jiawei
This patch add XiangShan Nanhu cpu microarchitecture,
Nanhu is a 6-issue, superscalar, out-of-order processor.
More details see: https://xiangshan-doc.readthedocs.io/zh-cn/latest/arch
gcc/ChangeLog:
*
On 3/18/24 12:40 PM, Jakub Jelinek wrote:
Hi!
Like in the r14-9503 change on x86-64, I think Alpha also needs to
function_arg_advance after the hidden return pointer argument if
any.
At least, the following patch changes the assembly of s1-s6 functions
on the https://gcc.gnu.org/pipermail/gcc
On 3/18/24 12:54 PM, Edwin Lu wrote:
We assume that TYPE_NO_NAMED_ARGS_STDARG_P don't have any named arguments and
there is nothing to advance, but that is not the case for (...) functions
returning by hidden reference which have one such artificial argument.
This causes gcc.dg/c23-stdarg-[68]
On 3/12/24 3:56 PM, Edwin Lu wrote:
Given the recent change with adding the scheduler pipeline descriptions,
many scan-dump failures emerged. Relax the expected assembler output
conditions on the affected tests to reduce noise.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/costmodel/riscv/r
On 1/22/24 6:30 AM, Mary Bennett wrote:
On 09/01/2024 18:43, Jeff Law wrote:
On 1/8/24 06:14, Mary Bennett wrote:
Spec: github.com/openhwgroup/core-v-sw/blob/master/specifications/
corev-builtin-spec.md
Contributors:
Mary Bennett
Nandni Jamnadas
Pietra Ferreira
Charlie
On 3/5/24 4:40 AM, Xi Ruoyao wrote:
Recently I've fixed two wrong FP vector negate implementation which
caused wrong sign bits in zeros in targets (r14-8786 and r14-8801). To
prevent a similar issue from happening again, add a test case.
Tested on x86_64 (with SSE2, AVX, AVX2, and AVX512F),
On 3/18/24 3:09 AM, Jivan Hakobyan wrote:
As RV has round instructions it is reasonable to use them instead of
calling the library functions.
With my patch for the following C code:
double foo(double a) {
return ceil(a);
}
GCC generates the following ASM code (before it was tail call)
On 2/6/24 6:14 AM, Robin Dapp wrote:
The root cause is this following RTL pattern, after fwprop1:
(insn 82 78 84 9 (set (reg:DI 230)
(sign_extend:DI (minus:SI (subreg/s/v:SI (reg:DI 150 [ niters.10 ]) 0)
(subreg:SI (reg:DI 221) 0 13 {subsi3_extended}
(expr_
On 3/10/24 11:41 PM, HAO CHEN GUI wrote:
Hi,
This patch tries to fix the problem when a canonical form doesn't benefit
on a specific target. The const operand of AND is and with the nonzero
bits of another operand in combine pass. It's a canonical form, but it's no
benefits for the target w
On 3/16/24 11:35 AM, Vineet Gupta wrote:
Hi,
This set of patches (for gcc-15) help improve stack/array accesses
by improving constant materialization. Details are in respective
patches.
The first patch is the main change which improves SPEC cactu by 10%.
Just to confirm. Yup, 10% reduction
On 3/19/24 12:48 AM, Andrew Waterman wrote:
On Mon, Mar 18, 2024 at 5:28 PM Vineet Gupta wrote:
On 3/16/24 13:21, Jeff Law wrote:
| 59944:add s0,sp,2047 <
| 59948:mv a2,a0
| 5994c:mv a3,a1
| 59950:mv a0,sp
| 59954:li a
On 3/20/24 10:06 AM, Jakub Jelinek wrote:
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.
That fixed c23-stdarg-{6,8,9} execution tests.
jeff
On 3/20/24 10:05 AM, Jakub Jelinek wrote:
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
On 3/20/24 10:05 AM, Jakub Jelinek wrote:
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
*
On 3/20/24 10:06 AM, Jakub Jelinek wrote:
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
*
On 3/20/24 10:08 AM, Jakub Jelinek wrote:
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
On 3/20/24 10:04 AM, Jakub Jelinek wrote:
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
*
On 3/20/24 11:29 AM, Jakub Jelinek wrote:
On Wed, Mar 20, 2024 at 10:58:05AM -0600, Jeff Law wrote:
On 3/20/24 10:06 AM, Jakub Jelinek wrote:
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
On 3/19/24 10:23 AM, Palmer Dabbelt wrote:
On Mon, 18 Mar 2024 20:50:14 PDT (-0700), jeffreya...@gmail.com wrote:
On 3/18/24 3:09 AM, Jivan Hakobyan wrote:
As RV has round instructions it is reasonable to use them instead of
calling the library functions.
With my patch for the following C
On 3/19/24 2:05 PM, Vineet Gupta wrote:
Just to be clear, the changes don't misalign the stack pointer at all.
They merely have the potential to create *another* pointer into the
stack which may or may not be aligned. Which is totally normal, it's no
different than taking the address of a ch
On 3/21/24 8:36 AM, Vineet Gupta wrote:
On 3/18/24 21:41, Jeff Law wrote:
On 3/16/24 11:35 AM, Vineet Gupta wrote:
Hi,
This set of patches (for gcc-15) help improve stack/array accesses
by improving constant materialization. Details are in respective
patches.
The first patch is the
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 how the instruction
counts compare.
Oh yeah ! Robin hinted to this in Tu
hasing
one of these issues down again in the wild. Been there, done that.
Regression tested on rv64gc. Verified the scheduler no longer mucked up
realpath by hand. Pushing to the trunk.
Jeff
commit c65046ff2ef0a9a46e59bc0b3369b2d226f6a239
Author: Jeff Law
Date: Thu Mar 21 20:41:59 2024 -0600
On 3/22/24 2:47 AM, Richard Biener wrote:
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
On 3/15/24 4:29 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?
The unwinding mechanism registers both the code range and the unwind
table itself within a b-tree lookup st
On 3/15/24 4:29 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?
The unwinding mechanism registers both the code range and the unwind
table itself within a b-tree lookup st
On 3/9/24 2:11 AM, Alexandre Oliva wrote:
ipa_tree_profile asserts that the symtab is in IPA_SSA state, but we
don't reach that state and ICE if e.g. ipa-strub passes report errors.
Skip this pass if errors were seen.
Regstrapped on x86_64-linux-gnu. Ok to install?
for gcc/ChangeLog
On 3/21/24 5:20 AM, Thomas Schwinge wrote:
Hi!
On 2024-02-16T10:48:53-0800, Mike Stump wrote:
On Feb 16, 2024, at 2:16 AM, Jakub Jelinek wrote:
There is one special case, NVPTX, which is a TARGET_NO_REGISTER_ALLOCATION
target. I think claiming for it that it is a lra target is strange (
On 3/4/24 11:22 PM, Li, Pan2 wrote:
Thanks Jeff for comments.
But in the case of a vector modes, we can usually reinterpret the
underlying bits in whatever mode we want and do any of the usual
operations on those bits.
Yes, I think that is why we can allow vector mode in get_stored_val if
On 3/22/24 12:24 PM, Jakub Jelinek wrote:
On Fri, Mar 22, 2024 at 12:17:03PM -0600, Jeff Law wrote:
I'd just make target_lra return false for nvptx rather than creating a new
The lra effective target currently though doesn't check if asm goto can have
outputs, but rather if the
On 3/1/24 8:07 AM, Robin Dapp wrote:
+ /* Segment load/store permute cost. */
+ const int segment_permute_2;
+ const int segment_permute_4;
+ const int segment_permute_8;
Why do we only have 2/4/8, I think we should have 2/3/4/5/6/7/8
No idea why I posted that (wrong) version, I used i
On 3/18/24 6:07 PM, Vineet Gupta wrote:
Naive question: why is define_split more natural vs. define_insn_and_split.
Is it because of the syntax/implementation or that one is more Combine
"centric" and other is more of a Split* Pass thing (roughly speaking of
course) or something else altoget
On 3/19/24 2:05 PM, Vineet Gupta wrote:
On 3/19/24 06:10, Jeff Law wrote:
On 3/19/24 12:48 AM, Andrew Waterman wrote:
On Mon, Mar 18, 2024 at 5:28 PM Vineet Gupta wrote:
On 3/16/24 13:21, Jeff Law wrote:
| 59944:add s0,sp,2047 <
| 59948:mv a2,a0
| 59
On 3/21/24 11:19 AM, Vineet Gupta wrote:
Oh yeah ! Robin hinted to this in Tues patchworks meeting too
default : 2,565,319,368,591
128 : 2,509,741,035,068
256 : 2,527,817,813,612
no-sched{,2}: 1,295,520,567,376
So one more nugget here. I happened to be doing some his
On 3/25/24 1:48 PM, Xi Ruoyao wrote:
On Mon, 2024-03-18 at 20:54 -0600, Jeff Law wrote:
+/* Costs to use when optimizing for xiangshan nanhu. */
+static const struct riscv_tune_param xiangshan_nanhu_tune_info = {
+ {COSTS_N_INSNS (3), COSTS_N_INSNS (3)}, /* fp_add */
+ {COSTS_N_INSNS
On 3/25/24 2:13 PM, Palmer Dabbelt wrote:
On Mon, 25 Mar 2024 12:59:14 PDT (-0700), Jeff Law wrote:
On 3/25/24 1:48 PM, Xi Ruoyao wrote:
On Mon, 2024-03-18 at 20:54 -0600, Jeff Law wrote:
+/* Costs to use when optimizing for xiangshan nanhu. */
+static const struct riscv_tune_param
On 3/25/24 2:31 PM, Palmer Dabbelt wrote:
On Mon, 25 Mar 2024 13:27:34 PDT (-0700), Jeff Law wrote:
I'd doubt it's worth the complexity. Picking some reasonable value gets
you the vast majority of the benefit. Something like
COSTS_N_INSNS(6) is enough to get CSE to trigger.
On 3/25/24 2:57 PM, Palmer Dabbelt wrote:
On Mon, 25 Mar 2024 13:49:18 PDT (-0700), jeffreya...@gmail.com wrote:
On 3/25/24 2:31 PM, Palmer Dabbelt wrote:
On Mon, 25 Mar 2024 13:27:34 PDT (-0700), Jeff Law wrote:
I'd doubt it's worth the complexity. Picking some reasonable v
On 3/27/24 4:14 PM, Vineet Gupta wrote:
Per classic Vector calling convention ABI, vtype is call clobbered,
so ensure gcc generates fresh a VSETVLI after a function call or an
inline asm which clobbers vtype.
ATM gcc seems to be doing the right thing, but a test can never be
harmful.
gcc/tes
On 3/28/24 4:31 AM, demin.han wrote:
The adjacent_dr_p is sufficient and unnecessary condition for contiguous access.
So unnecessary live-ranges are added and result in spill.
This patch uses MEMORY_ACCESS_TYPE as condition and constrains segment
load/store.
Tested on RV64 and no regression.
oviding a suitable output template for the
reg->reg case.
Regression tested on h8300-elf. Pushing to the trunk.
gcc/
* config/h8300/extensions.md (zero_extendqihi*): Add output
template for reg->reg case where the regs don't match.
Jeffcommit c1e66532cbb424bd7ea8c3b2
do an audit to ensure that all
insn types map to an insn reservation.
Pushing this to the trunk.
Jeff
commit 08eaafadd5beaa56beb2d1fceca9f97eeb0219ba
Author: Jeff Law
Date: Sun Mar 31 10:51:17 2024 -0600
[committed] RISC-V: Add missing insn types to XiangShan Nanhu scheduler
model
On 4/4/24 6:41 AM, Richard Biener wrote:
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
On 4/5/24 3:27 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.
Bootstrap and regtest running ontop of a reversal of
r1
On 3/27/24 4:55 AM, Philipp Tomsich wrote:
Jeff,
just a heads-up that that trunk (i.e., the soon-to-be GCC14) still
generates the suboptimal sequence:
https://godbolt.org/z/K9YYEPsvY
Realistically it's too late to get this into gcc-14.
Jeff
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 for some linkers because such functions result in FDEs
with a 0 code exte
On 1/30/24 18:54, pan2...@intel.com wrote:
From: Pan Li
This patch would like to cleanup some comments which are out of date or
incorrect.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_get_arg_info): Cleanup comments.
(riscv_pass_by_reference): Ditto.
(riscv_fntype
On 2/1/24 18:24, Greg McGary wrote:
On 1/18/24 9:24 AM, Jeff Law wrote:
On 1/17/24 20:53, Greg McGary wrote:
While the code comment is true, perhaps it obscures the primary intent,
which is recognition that the pattern (SIGN_EXTEND (mem ...) ) is
destined
to expand into a single memory
On 1/30/24 03:30, Iain Sandoe wrote:
tested on i686, x86_64 (and aarch64) Darwin, x86_64, aarch64 Linux,
OK for trunk?
thanks
Iain
--- 8< ---
We use the shared asan/hwasan from both C,C++,D and Fortran.
The sanitizer libraries link to libstdc++.
When we are using the C/gdc/gfortran driver,
On 1/30/24 03:31, Iain Sandoe wrote:
tested on i686, x86_64 (and aarch64) Darwin, x86_64, aarch64 Linux,
OK for trunk?
thanks
Iain
--- 8< ---
We use the ubsan tests from both C, C++, D and Fortran.
the sanitizer libraries link to libstdc++.
When we are using the C/gdc/gfortran driver, and t
On 1/29/24 22:19, Andrew Pinski wrote:
The vect-avg-*.c testcases are trying to make sure
the AVG internal function are used and not
doing promotion to `vector unsigned short`
but when V4QI is implemented, `vector(2) unsigned short`
shows up in the detail dump file and causes the failure.
To f
On 2/1/24 07:20, Richard Biener wrote:
The following avoids re-associating
(minus:DI (reg/f:DI 119)
(minus:DI (reg/f:DI 120)
(reg/f:DI 114)))
into
(minus:DI (plus:DI (reg/f:DI 114)
(reg/f:DI 119))
(reg/f:DI 120))
as that possibly confuses the REG_POINTER heu
On 1/30/24 10:04, Khem Raj wrote:
libgcc/
* config/i386/enable-execute-stack-mingw32.c: Include
stdlib.h for abort() definition.
Thanks. Pushed to the trunk.
jeff
shing to the trunk.
Shout out to Jivan who took the original somewhat vague report about
bt_skip_func and boiled it down to a very simple testcase along with
info on a couple attempted fixes that didn't work out.
Jeffcommit 777df37a12e55ecbc135efbed2749a8a8a756d4d
Author: Jeff Law
Date:
On 2/1/24 18:56, Juzhe-Zhong wrote:
This patch fixes the following:
vsetvli a5,a1,e32,m1,tu,ma
sllia4,a5,2
sub a1,a1,a5
vle32.v v2,0(a0)
add a0,a0,a4
vadd.vv v1,v2,v1
bne a1,zero,.L3
vsetivlizero,1
On 2/4/24 20:20, Monk Chiang wrote:
gcc/ChangeLog:
PR target/113742
* config/riscv/riscv.cc (riscv_macro_fusion_pair_p): Fix
recognizes UNSPEC_AUIPC for RISCV_FUSE_LUI_ADDI.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr113742.c: New test.
OK. Presumably thi
On 2/4/24 20:26, Jeff Law wrote:
On 2/1/24 18:56, Juzhe-Zhong wrote:
This patch fixes the following:
vsetvli a5,a1,e32,m1,tu,ma
slli a4,a5,2
sub a1,a1,a5
vle32.v v2,0(a0)
add a0,a0,a4
vadd.vv v1,v2,v1
bne a1
On 2/2/24 15:48, Greg McGary wrote:
On 2/1/24 10:24 PM, Jeff Law wrote:
On 2/1/24 18:24, Greg McGary wrote:
However, for a machine where (WORD_REGISTER_OPERATIONS &&
load_extend_op (inner_mode) == SIGN_EXTEND), the high part of a PSoM
is only known at runtime as 0s or 1s. Th
On 2/5/24 05:00, Christoph Müllner wrote:
On Sat, Feb 3, 2024 at 2:11 PM Andreas Schwab
wrote:
On Jan 30 2024, Christoph Müllner wrote:
retested
Nope.
Sorry for this. I tested for no regressions in the test suite with a
cross-build and QEMU and did not do a Werror bootstrap build. I'l
On 2/4/24 23:37, juzhe.zh...@rivai.ai wrote:
I think it just trigger a latent bug that we didn't encounter.
Hi, Robin. Would you mind give me preprocessed file to reproduce the issue ?
I suspect it triggers latent bug in VSETVL PASS.
I've got a few minutes this morning before meetings start.
On 2/5/24 08:08, Andreas Schwab wrote:
On Feb 05 2024, Jeff Law wrote:
Until such systems are common, these niggling issues are bound to show up.
It won't if you do it properly: build with a cross compiler that was
built from the same source and enable -Werror.
We're all awar
On 2/5/24 01:15, Richard Biener wrote:
PR rtl-optimization/113255
* simplify-rtx.cc (simplify_context::simplify_binary_operation_1):
Do not re-associate a MINUS with a REG_POINTER op0.
Nasty little set of problems. I don't think we ever pondered that we could
have multiple REGNO_POIN
On 2/5/24 06:50, Jakub Jelinek wrote:
Hi!
gcc/Makefile.in since my r0-60234 change fills in HOSTCC and HOSTCFLAGS
in site.exp and since r8-671 also HOSTCXX and HOSTCXXFLAGS.
If those variables aren't set, we get errors like:
/usr/src/gcc/contrib/test_installed --without-g++ --without-gfortran
On 2/5/24 00:01, Lehua Ding wrote:
For SPEC INT 2017, when using upstream GCC (whitout these patches), I
get a
coredump when training the peak case, so no data yet. The cause of the
core
dump still needs to be investigated.
Typo, SPEC INT 2017 -> SPEC FP 2017
Also There is a bad news, the
On 2/4/24 23:37, juzhe.zh...@rivai.ai wrote:
I think it just trigger a latent bug that we didn't encounter.
Hi, Robin. Would you mind give me preprocessed file to reproduce the issue ?
I suspect it triggers latent bug in VSETVL PASS.
So it looks like vsetvl has made a transformation that mak
On 2/7/24 14:23, Gerald Pfeifer wrote:
On Tue, 19 Dec 2023, Jeff Law wrote:
Pushed to the trunk.
Is this minor follow-up okay, adding a full stop and shortening a bit?
Yes, of course.
Thanks.
jeff
On 2/9/24 02:44, Jakub Jelinek wrote:
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644701.html
Introduce HOST_SIZE_T_PRINT_UNSIGNED etc. macros to fix LLP64 host build issue
Both have been successfully bootstrapped/regtested on x86_64-linux and
i686-linux, the latter has been tes
On 2/9/24 09:53, Palmer Dabbelt wrote:
This builds for me, and I frequently have python-is-python3 type
packages installed so I think I've been implicitly testing it for a
while. Looks like Kito's tested similar configurations, and the
bugzilla indicates we should be moving over.
gcc/ChangeL
On 2/4/24 20:20, Monk Chiang wrote:
gcc/ChangeLog:
PR target/113742
* config/riscv/riscv.cc (riscv_macro_fusion_pair_p): Fix
recognizes UNSPEC_AUIPC for RISCV_FUSE_LUI_ADDI.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr113742.c: New test.
I was going through
On 2/13/24 06:42, Robin Dapp wrote:
Hi,
scalar loads provide offset addressing while unit-stride vector
instructions cannot. The offset must be loaded into a general-purpose
register before it can be used. In order to account for this, this
patch adds an address arithmetic heuristic that ke
On 2/13/24 01:26, Jakub Jelinek wrote:
On Mon, Feb 12, 2024 at 04:10:33PM +, Joseph Myers wrote:
On Sat, 10 Feb 2024, Jakub Jelinek wrote:
* c-format.cc (gcc_diag_length_specs): Add t and z modifiers.
(PP_FORMAT_CHAR_TABLE, gcc_gfc_char_table): Add entries for t and
On 2/13/24 01:21, Jakub Jelinek wrote:
Hi!
This is IMHO more of a theoretical case, I believe my current code
doesn't handle %tu or %to or %tx correctly if ptrdiff_t is not one of
int, long int or long long int. For size_t and %zd or %zi I'm
using va_arg (whatever, ssize_t) and hope that ssi
On 2/7/24 17:30, Patrick O'Neill wrote:
There is a proposal to split the A extension into two parts: Zaamo and Zalrsc.
This patch adds basic support by making the A extension imply Zaamo and
Zalrsc.
Proposal: https://github.com/riscv/riscv-zaamo-zalrsc/tags
gcc/ChangeLog:
* common/c
On 2/6/24 10:38, Edwin Lu wrote:
This patch adds support for recognizing the B standard extension to be the
collection of Zba, Zbb, Zbs extensions for consistency and conciseness across
toolchains
* https://github.com/riscv/riscv-b/tags
gcc/ChangeLog:
* common/config/riscv/riscv-com
On 2/16/24 07:56, Iain Sandoe wrote:
tested on x86_64-darwin, so far. OK for trunk if regression test is
successful on Linux too?
thanks
Iain
--- 8< ---
r14-5310-g879cf9ff45d940 introduced some new handling for spawning sub
processes. The return value from the generic exec_child is examined
On 2/18/24 02:18, Mikael Pettersson wrote:
m68k fails to bootstrap since -ffold-mem-offsets was introduced,
in what looks like wrong-code during stage2.
To restore bootstrap this disables -ffold-mem-offsets on m68k.
It's not ideal, but better than keeping bootstraps broken until
the root caus
On 2/19/24 21:26, Alexandre Oliva wrote:
This backport for gcc-13 is required for pr90838.c to get the expected
count of andi instructions on riscv64-elf, rather than fail because of
two extra andi insns in functions where it is not necessary. (On
riscv32-elf, it passes). Regstrapped on x86_
On 2/20/24 07:21, Alexandre Oliva wrote:
On Feb 20, 2024, Jeff Law wrote:
On 2/19/24 21:26, Alexandre Oliva wrote:
This backport for gcc-13 is required for pr90838.c to get the expected
count of andi instructions on riscv64-elf
.
In general, shouldn't backports be focused on correc
On 2/19/24 21:15, Alexandre Oliva wrote:
This backport is the first of two required for the pr111935 testcase,
already backported to gcc-13, to pass on riscv64-elf and riscv32-elf.
The V_VLS mode iterator, used in the original patch, is not available in
gcc-13, and I thought that would be too
On 2/19/24 21:21, Alexandre Oliva wrote:
This backport is the second of two required for the pr111935 testcase,
already backported to gcc-13, to pass on riscv64-elf and riscv32-elf.
The V_VLS mode iterator, used in the original patch, is not available in
gcc-13, and I thought that would be too
On 2/23/24 01:05, Richard Biener wrote:
The following deprecates ia64*-*-* for GCC 14. Since we plan to
force LRA for GCC 15 and the target only has slim chances of getting
updated this notifies people in advance. Given both Linux and
glibc have axed the target further development is also ma
On 2/23/24 01:22, Kito Cheng wrote:
I would prefer to only keep zvl and scalable or zvl only, since I
don't see too much value in specifying a value which different from
zvl*b, that's a legacy option used before zvl*b option was introduced,
and the reason to add that is that could used for com
On 2/27/24 00:43, Richard Biener wrote:
On Tue, 27 Feb 2024, haochen.jiang wrote:
On Linux/x86_64,
af66ad89e8169f44db723813662917cf4cbb78fc is the first bad commit
commit af66ad89e8169f44db723813662917cf4cbb78fc
Author: Richard Biener
Date: Fri Feb 23 16:06:05 2024 +0100
middle-end
On 2/27/24 06:53, Richard Biener wrote:
On Tue, 27 Feb 2024, Jeff Law wrote:
On 2/27/24 00:43, Richard Biener wrote:
On Tue, 27 Feb 2024, haochen.jiang wrote:
On Linux/x86_64,
af66ad89e8169f44db723813662917cf4cbb78fc is the first bad commit
commit
On 2/26/24 07:22, pan2...@intel.com wrote:
From: Pan Li
We allowed vector type for get_stored_val when read is less than or
equal to store in previous. Unfortunately, we missed to adjust the
validate_subreg part accordingly. When the vector type's size is
less than vector register, it will
On 2/26/24 20:12, Tom Tromey wrote:
While working on another patch, I discovered that the libcc1 plugin
code never did version negotiation correctly. So, the patches to
introduce v1 never did anything -- the new code, as far as I know, has
never been run.
Making version negotiation work show
On 2/26/24 18:21, juzhe.zh...@rivai.ai wrote:
If the scheduling model increases the vsetvls, we shouldn't set it as
default scheduling model
I don't think it's that simple. On some uarchs vsetvls are nearly free
while on others they can be fairly expensive. It's not clear (to me)
yet if on
On 2/25/24 21:53, Greg McGary wrote:
Add option -m(no-)autovec-segment to enable/disable autovectorizer
from emitting vector segment load/store instructions. This is useful for
performance experiments.
gcc/ChangeLog:
* config/riscv/autovec.md (vec_mask_len_load_lanes,
vec_mask_len_st
On 2/27/24 15:56, 钟居哲 wrote:
>> I don't think it's that simple. On some uarchs vsetvls are nearly free
while on others they can be fairly expensive. It's not clear (to me)
yet if one approach or the other is going to be the more common.
That's uarch dependent which is not the stuff I am
On 2/28/24 05:23, Kito Cheng wrote:
atomic_compare_and_swapsi will use lr.w and sc.w to do the atomic operation on
RV64, however lr.w is doing sign extend to DI and compare instruction only have
DI mode on RV64, so the expected value should be sign extend before compare as
well, so that we can
On 2/28/24 03:05, Richard Biener wrote:
Untested fix for targets that cannot handle the original IL below.
I'm not convinced that's the way to go here, is it? Or scrap
the testcase? Or have a cheap way to say "this target doesn't
support _any_ vec_cond"?
Another way, but for stage1 I thin
On 2/27/24 21:51, Li, Pan2 wrote:
if (!targetm.modes_tieable_p (src_int_mode, src_mode))
return NULL_RTX;
if (!targetm.modes_tieable_p (int_mode, mode))
return NULL_RTX;
Yes, will return NULL_RTX for in the first if, given src_int_mode is E_DImode
while src_mode is
E_V2SFmod
On 2/27/24 13:30, Greg McGary wrote:
On 2/27/24 8:25 AM, Jeff Law wrote:
On 2/25/24 21:53, Greg McGary wrote:
Add option -m(no-)autovec-segment to enable/disable autovectorizer
from emitting vector segment load/store instructions. This is useful for
performance experiments.
gcc
701 - 800 of 15555 matches
Mail list logo
