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
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 loop
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;
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 loop unrolling.
As I speculated a couple years ago, we could eliminate the comparisons
against bogus
Here's a potential approach to fixing PR92539, a P2 -Warray-bounds false
positive triggered by loop unrolling.
As I speculated a couple years ago, we could eliminate the comparisons
against bogus pointers. Consider:
[local count: 30530247]:
if (last_12 != [(void *)"aa" + 3B])
So as I mentioned in the BZ, the case of
t = MIN_EXPR (A, B)
where we know something about the relationship between A and B can be
trivially handled by some existing code in DOM. That existing code
would simplify when A == B. But by testing GE and LE instead of EQ we
can cover more cases
https://gcc.gnu.org/g:8fe27ed193d60f6cd8b34761858a720c95eabbdb
commit r14-9419-g8fe27ed193d60f6cd8b34761858a720c95eabbdb
Author: jlaw
Date: Sun Mar 10 11:58:00 2024 -0600
[committed] [PR tree-optimization/110199] Simplify MIN/MAX more often
So as I mentioned in the BZ, the case
With Jakub's twiddle to the forward propagation pass, the assembly code
for pr59533-1.c has returned to its previous state. Thus I've reverted
my patch which adjusted the expected output.
Jeffcommit 6f7d000fcacef31a6947f95021e445c846170f92
Author: jlaw
Date: Sat Mar 9 21:33:47 2024 -0700
https://gcc.gnu.org/g:6f7d000fcacef31a6947f95021e445c846170f92
commit r14-9417-g6f7d000fcacef31a6947f95021e445c846170f92
Author: jlaw
Date: Sat Mar 9 21:33:47 2024 -0700
Revert "[committed] Adjust expectations for pr59533-1.c"
This reverts commit
Not sure why nobody's taken care of this yet. Under certain
circumstances python may be needed if you're building a RISC-V compiler.
Here's what I've checked in. Happy to adjust if folks want to wordsmith
it further.
Jeffcommit 7c8f0a79a7e1e42f846ddbca14b98b47ddcfd178
Author: jlaw
Date:
https://gcc.gnu.org/g:7c8f0a79a7e1e42f846ddbca14b98b47ddcfd178
commit r14-9416-g7c8f0a79a7e1e42f846ddbca14b98b47ddcfd178
Author: jlaw
Date: Sat Mar 9 20:11:39 2024 -0700
[committed] [target/102250] Document python requirement for risc-v
PR target/102250
gcc/
The issue here is the code we emit for mode-switching can change when -g
is added to the command line. This is caused by processing debug notes
occurring after a call which is the last real statement in a basic block.
Without -g the CALL_INSN is literally the last insn in the block and the
https://gcc.gnu.org/g:50531b6d400945793a1d549e6ee941d989319d42
commit r14-9415-g50531b6d400945793a1d549e6ee941d989319d42
Author: jlaw
Date: Sat Mar 9 19:27:32 2024 -0700
[committed] [PR target/111362] Fix compare-debug issue with mode switching
The issue here is the code we emit
On 3/7/24 07:27, Sam James wrote:
'python' on some systems (e.g. SLES 15) might be Python 2. Prefer python3,
then python, then python2 (as the script still tries to work there).
contrib/ChangeLog:
* dg-extract-results.sh: Check for python3 before python. Check for
python2 last.
OK.
actually has distinct patterns for those two cases. So swapping the
operands is neither needed nor advisable.
Regression tested on rv64gc and verified the new tests pass.
Pushing to the trunk.
jeff
commit 10cbfcd60f9e5bdbe486e1c0192e0f168d899b77
Author: Jeff Law
Date: Wed Mar 6 09:50:44
https://gcc.gnu.org/g:10cbfcd60f9e5bdbe486e1c0192e0f168d899b77
commit r14-9341-g10cbfcd60f9e5bdbe486e1c0192e0f168d899b77
Author: Jeff Law
Date: Wed Mar 6 09:50:44 2024 -0700
[PR target/113001] Fix incorrect operand swapping in conditional move
This bug totally fell off my radar
On 2/6/24 04:37, Richard Biener wrote:
The following avoids accessing out-of-bound vector elements when
native encoding a boolean vector with sub-BITS_PER_UNIT precision
elements. The error was basing the number of elements to extract
on the rounded up total byte size involved and the patch
On 3/4/24 09:49, Jakub Jelinek wrote:
On Mon, Mar 04, 2024 at 05:18:39PM +0100, Rainer Orth wrote:
On 2/26/24 17:17, Greg McGary wrote:
The sign-bit-copies of a sign-extending load cannot be known until runtime on
WORD_REGISTER_OPERATIONS targets, except in the case of a zero-extending MEM
On 3/4/24 02:12, HAO CHEN GUI wrote:
Hi Jeff,
在 2024/3/4 11:37, Jeff Law 写道:
Can the same thing happen with a volatile memory load? I don't think that will
be caught by the volatile_insn_p check.
Yes, I think so. If the define rtx contains volatile memory references, it
may hit the same
Excerpt from gcc.sum:
[...]
PASS: gcc.c-torture/execute/20101011-1.c -O0 (test for excess errors)
FAIL: gcc.c-torture/execute/20101011-1.c -O0 execution test
PASS: gcc.c-torture/execute/20101011-1.c -O1 (test for excess errors)
FAIL: gcc.c-torture/execute/20101011-1.c -O1 execution
On 3/3/24 19:56, HAO CHEN GUI wrote:
Hi Jeff,
Thanks for your comments.
在 2024/3/4 6:02, Jeff Law 写道:
Why specifically are you worried here? Propagation of a volatile shouldn't in
and of itself cause a problem. We're not changing the number of volatile
accesses or anything like
On 2/9/24 03:26, Richard Biener wrote:
The following allows a base term to be derived from an existing
MEM_EXPR, notably the points-to set of a MEM_REF base. For the
testcase in the PR this helps RTL DSE elide stores to a stack
temporary. This covers pointers to NONLOCAL which can be mapped
On 2/29/24 06:28, Robin Dapp wrote:
On 2/29/24 02:38, Li, Pan2 wrote:
So it's going to check if V2SF can be tied to DI and V4QI with SI. I
suspect those are going to fail for RISC-V as those aren't tieable.
Yes, you are right. Different REG_CLASS are not allowed to be tieable in RISC-V.
On 2/25/24 20:30, HAO CHEN GUI wrote:
Hi,
This patch tries to fix a potential problem which is raised by the patch
for PR111267. The volatile asm operand tries to be propagated to a single
set insn with the patch for PR111267. It has potential risk as the behavior
is wrong. Currently
On 2/29/24 00:06, Xi Ruoyao wrote:
The vect_int_mod target selector is evaluated with the options in
DEFAULT_VECTCFLAGS in effect, but these options are not automatically
passed to tests out of the vect directories. So this test fails on
targets where integer vector modulo operation is
On 3/3/24 12:43, Uros Bizjak wrote:
umuldi3_highpart expander does:
if (REG_P (operands[2]))
operands[2] = gen_rtx_ZERO_EXTEND (TImode, operands[2]);
on register_operand predicate, which also allows SUBREG RTX. So,
subregs were emitted without ZERO_EXTEND RTX.
But nowadays we
On 2/29/24 01:35, Richard Biener wrote:
The following amends the PR114070 fix to optimistically allow
the folding when we cannot expand the current vec_cond using
vcond_mask and we're still before vector lowering. This leaves
a small window between vectorization and lowering where we could
So one of the broad goals we've had over the last few months has been to
ensure that every insn has a scheduling type and that every insn is
associated with an insn reservation in the scheduler.
This avoids some amazingly bad behavior in the scheduler. I won't go
through the gory details.
On 2/26/24 17:17, Greg McGary wrote:
The sign-bit-copies of a sign-extending load cannot be known until runtime on
WORD_REGISTER_OPERATIONS targets, except in the case of a zero-extending MEM
load. See the fix for PR112758.
2024-02-22 Greg McGary
PR rtl-optimization/113010
On 2/28/24 15:57, Tom Tromey wrote:
"Jeff" == Jeff Law writes:
I could not push this because:
remote: *** ChangeLog format failed:
remote: *** ERR: invalid PR component in subject: "Fix PR libcc1/113977"
I guess this script isn't in sync with the components in bug
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
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
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
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
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/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,
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 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
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
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/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
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
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
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
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/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 correctness
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
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
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
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:
*
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:
*
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
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 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
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
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.
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
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/5/24 20:57, hameeza ahmed via Gcc wrote:
Hello,
I want to add an intrinsic in gcc toolchain that will generate the assembly
instruction. As it is said I need
to add a pattern to the gcc/config/riscv/riscv.md file to describe the
instruction. Can you please help me. Are there any tutorial
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
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/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++
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
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 aware you *can
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
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.
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
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/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
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
vsetivli
t 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: Sun Feb 4 13:01:50 2024 -070
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
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
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
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
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 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 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.
On 1/27/24 20:41, Sophie 'Tyalie' Friedrich via Gcc wrote:
Hello dear people,
I want to try building a GCC compiler backend for the STM8
micro-controller target in order to make this wonderful architecture
more accessible.
But as I'm fairly new in this area of building compiler backends
On 12/31/23 09:23, Roger Sayle wrote:
Very many thanks (and a Happy New Year) to the pre-commit
patch testing folks at linaro.org. Their testing has revealed that
although my patch is clean on x86_64, it triggers some problems
on aarch64 and arm. The issue (with the previous version of my
On 1/24/24 17:07, Patrick O'Neill wrote:
On 12/16/23 10:58, Jeff Law wrote:
On 12/15/23 17:14, Andrew Waterman wrote:
On Fri, Dec 15, 2023 at 1:38 PM Jeff Law wrote:
On 12/12/23 20:54, Palmer Dabbelt wrote:
I can't actually find anything in the ISA manual that makes Ztso imply
On 1/24/24 07:40, Robin Dapp wrote:
Hi,
on Solaris/SPARC several vector tests appeared to be regressing. They
were never vectorized but the checks before r14-3612-ge40edf64995769
would match regardless if a loop was actually vectorized or not.
The refined checks only match a successful
On 1/23/24 00:13, Alexandre Oliva wrote:
newlib-src/libc/include/sys/fenv.h doesn't define the FE_* macros that
libgcc expects to enable decimal float support. Only after newlib is
configured and built does an overriding header that defines those
macros become available in
On 1/23/24 00:15, Alexandre Oliva wrote:
Targets whose binutils support -shared, but that don't have a shared
libc, and that can't add PDC (non-PIC) to shared libraries, may
succeed at the effective target test for -shared, because it brings
nothing from libc, but tests that rely on -shared
On 1/24/24 04:26, Maciej W. Rozycki wrote:
On Tue, 16 Jan 2024, Maciej W. Rozycki wrote:
I don't have a strong opinion on this. I certainly see Andrew's point, but
it's also the case that if some work earlier in the RTL or gimple pipeline
comes along and compromises the test, then we'd see
On 1/24/24 05:54, Monk Chiang wrote:
Since the match.pd transforms (zero_one == 0) ? y : z y,
into ((typeof(y))zero_one * z) y. Add splitters to recongize
this expression to generate SFB instructions.
gcc/ChangeLog:
PR target/113095
* config/riscv/sfb.md: New splitters to
On 1/24/24 04:16, Maciej W. Rozycki wrote:
Add RTL tests, for RV64 and RV32 where appropriate, corresponding to the
existing cset-sext.c tests. They have been produced from RTL code as at
the entry of the "ce1" pass for the respective cset-sext.c tests built
at -O3.
gcc/testsuite/
On 1/24/24 04:16, Maciej W. Rozycki wrote:
Add a pair of RTL tests, for RV64 and RV32 respectively, corresponding
to the existing pr105314.c test. They have been produced from RTL code
as at the entry of the "ce1" pass for pr105314.c compiled at -O3.
gcc/testsuite/
*
On 1/21/24 23:12, Monk Chiang wrote:
Since the match.pd transforms (zero_one == 0) ? y : z y,
into ((typeof(y))zero_one * z) y. Add splitters to recongize
this expression to generate SFB instructions.
gcc/ChangeLog:
PR target/113095
* config/riscv/sfb.md: New splitters to
On 1/15/24 06:34, Richard Biener wrote:
The following adjusts find_base_value similar as to what
find_base_term was adjusted for PR113255.
* alias.cc (known_base_value_p): Remove.
(find_base_value): Remove PLUS/MINUS handling
when both operands are not CONST_INT_P.
On 1/22/24 00:45, Richard Biener wrote:
On Fri, Jan 19, 2024 at 5:06 PM Georg-Johann Lay wrote:
Am 18.01.24 um 20:54 schrieb Roger Sayle:
This patch tweaks RTL expansion of multi-word shifts and rotates to use
PLUS rather than IOR for disjunctive operations. During expansion of
these
On 1/15/24 06:34, Richard Biener wrote:
When the x86 backend generates code for cpymem with the rep_8byte
strathegy for the 8 byte aligned main rep movq it needs to compute
an adjusted pointer to the source after doing a prologue aligning
the destination. It computes that via
src_ptr +
On 1/15/24 06:34, Richard Biener wrote:
When the x86 backend generates code for cpymem with the rep_8byte
strathegy for the 8 byte aligned main rep movq it needs to compute
an adjusted pointer to the source after doing a prologue aligning
the destination. It computes that via
src_ptr +
as all those are either a wash or a
The fwprop change does cause some code regressions on the same test.
I'll file a distinct but for that issue.
Pushed to the trunk,
Jeffcommit 7e16f819ff413c48702f9087b62eaac39a060a14
Author: Jeff Law
Date: Sun Jan 21 19:12:21 2024 -0700
[committed] Adjust
On 1/16/24 10:13, Mary Bennett wrote:
gcc/testsuite/ChangeLog:
* gcc.target/riscv/cv-alu-fail-compile.c: Change warning to error.
AFAICT this is independent of the other patches and fixes a clear
testsuite issue. I've pushed it to the trunk.
Thanks,
Jeff
On 1/16/24 09:25, 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 Keaney
Jessica Mills
Craig Blackmore
Simon Cook
Jeremy Bennett
On 1/16/24 09:55, Mikael Pettersson wrote:
On Thu, 4 Jan 2024 14:39:23 -0700, Jeff Law wrote:
On 1/4/24 02:23, Mikael Pettersson wrote:
emit_library_call_value_1 calls emit_push_insn with NULL_TREE
for TYPE. Sometimes emit_push_insn needs to assign a temp with
that TYPE, which causes
On 1/17/24 11:21, Martin Jambor wrote:
Hi,
PR 110422 shows that SRA can ICE assuming there is a single edge
outgoing from a block terminated with an asm goto. We need that for
BB-terminating statements so that any adjustments they make to the
aggregates can be copied over to their
On 1/19/24 18:18, 钟居哲 wrote:
OK. I saw the other arguments there:
tree fntype ATTRIBUTE_UNUSED,
rtx libname ATTRIBUTE_UNUSED,
So I leverage these and add ATTRIBUTE_UNUSED to 'fndecl'
Maybe it's better remove all arguments for
The signature was still using ATTRIBUTE_UNUSED and actually marked one
of the used arguments with ATTRIBUTE_UNUSED.
This patch drops the decorations and instead remove the name of
arguments which are actually unused which is the preferred way to handle
this now when we can.
Bootstrapped.
601 - 700 of 16262 matches
Mail list logo
