PR target/118601
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_use_by_pieces_infrastructure_p):
Exclude XTheadVector.
Reported-by: Edwin Lu
---
gcc/config/riscv/riscv.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/riscv/riscv.cc b/gcc/
The code change looks good to me. I defer to y'all's judgment as to
how it slots into the release.
On Sat, Feb 8, 2025 at 9:33 AM Jeff Law wrote:
>
>
>
> On 2/7/25 9:34 PM, Vineet Gupta wrote:
> > A couple of Vector pseudoinstructions use x0 scalar which being regfile
> > crosser could be ineffi
There's some special case code in the risc-v move expander to try and
optimize cases where the source is a subreg of a vector and the
destination is a scalar mode.
The code works fine except when we have no support for the given mode.
ie HF or BF when those extensions aren't enabled. We'll en
On 2/8/25 1:52 PM, Georg-Johann Lay wrote:
Am 08.02.25 um 18:23 schrieb Jeff Law:
On 2/8/25 3:04 AM, Georg-Johann Lay wrote:
That test case from https://gcc.gnu.org/bugzilla/show_bug.cgi?
id=116389#c7
still ICEs with that change in http://gcc.gnu.org/r15-7428
pr116389-red.c: In func
Hi Thomas,
Am 08.02.25 um 15:31 schrieb Thomas Koenig:
Hello world,
this fixes a rather old PR from 2005, where a subroutine
could be passed and called as a function. This patch checks
for that, also for the reverse, and for wrong types of functions.
looks good, just two minor comments:
+
Fixed typos in extend.texi.
Applied as as obvious.
Johann
--
ad target/118764: Fix a typo in doc/extend.texi.
gcc/
PR target/118764
* doc/invoke.texi (AVR Options): Fix typos.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index c33eb4425de..0aef2abf05b
Am 08.02.25 um 18:23 schrieb Jeff Law:
On 2/8/25 3:04 AM, Georg-Johann Lay wrote:
That test case from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116389#c7
still ICEs with that change in http://gcc.gnu.org/r15-7428
pr116389-red.c: In function 'func':
pr116389-red.c:20:1: error: insn do
On 2/4/25 01:49, Tobias Burnus wrote:
[snip]
To conclude: The patch LGTM but consider giving the user some hint
how to solve it, e.g. using one of the ideas above.
Thanks for the review. I've pushed the attached version of the patch,
which suggests using BLOCK or BEGIN/END METADIRECTIVE (but
On 2/7/25 9:34 PM, Vineet Gupta wrote:
A couple of Vector pseudoinstructions use x0 scalar which being regfile
crosser could be inefficient on certain wider uarches.
Use the imm 0 form, which should be functionally equivalent.
pseudoinsnorig insn with x0 this patch
--
On 2/8/25 3:04 AM, Georg-Johann Lay wrote:
That test case from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116389#c7
still ICEs with that change in http://gcc.gnu.org/r15-7428
pr116389-red.c: In function 'func':
pr116389-red.c:20:1: error: insn does not satisfy its constraints:
20 | }
On Tue, 28 Jan 2025, Dimitry Andric wrote:
> Ref: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118685
>
> This ensures that gcc uses its own crt objects for static linking.
> Otherwise, it could mix the base system's crtbeginT.o with libgcc's
> crtend.o, leading to possible segfaults.
>
> Signed-
On 2/7/25 6:34 PM, Andrew Waterman wrote:
Replacing x0 with 0 when possible is fine; it should never hurt and
might help on some uarches. (Of course, future versions of those
uarches will eventually be forced to improve handling of x0, anyway,
since as Vineet notes, some of the interesting ca
On 2/8/25 1:11 AM, Liao Shihua wrote:
The following warning was encountered while building GCC, fix it:
../.././gcc/gcc/config/riscv/bitmanip.md:809:1: warning: source missing a mode?
../.././gcc/gcc/config/riscv/bitmanip.md:809:1: warning: source missing a mode?
gcc/ChangeLog:
* con
Hello world,
this fixes a rather old PR from 2005, where a subroutine
could be passed and called as a function. This patch checks
for that, also for the reverse, and for wrong types of functions.
I expect that this will find a few bugs in dusty deck code...
Regression-tested. OK for trunk?
Be
On Sat, 8 Feb 2025 at 10:55, Matthew Malcomson wrote:
>
> Hi Jonathan!
>
> Many thanks! Will learn the libstdc++ style eventually.
>
> I've run bootstrap & regression test on this, and did the manual checks
> I mentioned before of compiling atomic_float/1.cc with clang and then
> adding `+ 1` on
Tested on x86_64-pc-linux-gnu, OK for trunk if full bootstrap + regtest
passes?
-- >8 --
There are two issues with no-linkage decls (e.g. explicit type aliases)
in unnamed namespaces that this patch fixes.
Firstly, we don't currently handle exporting no-linkage decls in unnamed
namespaces. This
On Fri, Feb 07, 2025 at 11:11:21AM -0500, Jason Merrill wrote:
> On 2/7/25 9:28 AM, Nathaniel Shead wrote:
> > On Fri, Feb 07, 2025 at 08:14:23AM -0500, Jason Merrill wrote:
> > > On 1/31/25 8:46 AM, Nathaniel Shead wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> >
Hi!
On 2018-09-05T12:52:10+0100, wrote:
> There are a number of tests that fail because they assume that exceptions are
> available, but [BPF, GCN, nvptx] does not support them, yet.
To make this explicit for GCN, nvptx (José: can BPF do the same?), I've
pushed to trunk branch commit 63121656500
For example, for nvptx, these test cases currently indeed fail with
'sorry, unimplemented: target cannot support nonlocal goto'. However,
that's just an artefact of non-existing support for exception handling,
and these test cases already require effective-target 'exceptions'.
gcc/testsui
Hi!
On 2018-09-05T12:52:10+0100, wrote:
> There are a number of tests that fail because they assume that exceptions are
> available, but GCN does not support them, yet.
Pushed to trunk branch commit 2466b0b4d9bcfe51c1a049c3d7f6a8043d68630e
"nvptx doesn't actually support effective-target 'except
Hi!
On 2018-09-05T12:52:10+0100, wrote:
> There are a number of tests that fail because they assume that exceptions are
> available, but GCN does not support them, yet.
Pushed to trunk branch commit e90276a4831553268f3dd4917d7b6ae9c08dbf0f
"BPF doesn't actually support effective-target 'exceptio
Hi!
On 2019-11-27T19:53:32+, Jozef Lawrynowicz wrote:
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
| # Return 1 if -fexceptions is supported.
|
| proc check_effective_target_exceptions {} {
| if { [istarget amdgcn*-*-*] } {
| retur
Hi!
On 2019-06-20T12:39:48+0200, Tom de Vries wrote:
> Add missing dg-require-effective-target nonlocal_goto.
>
> Tested on nvptx.
> --- a/gcc/testsuite/gcc.dg/pr88870.c
> +++ b/gcc/testsuite/gcc.dg/pr88870.c
> @@ -1,5 +1,6 @@
> /* PR rtl-optimization/88870 */
> /* { dg-do compile } */
> +/* {
Hi Jonathan!
Many thanks! Will learn the libstdc++ style eventually.
I've run bootstrap & regression test on this, and did the manual checks
I mentioned before of compiling atomic_float/1.cc with clang and then
adding `+ 1` on the builtin codepath to check that the clang binary
aborts while
Am 07.02.25 um 22:28 schrieb Jeff Law:
On 2/7/25 11:01 AM, Georg-Johann Lay wrote:
Am 07.02.25 um 17:12 schrieb Jeff Law:
On 2/3/25 2:09 AM, Richard Sandiford wrote:
Jeff Law writes:
So pulling on this thread leads me into the code that sets up
ALLOCNO_WMODE in create_insn_allocnos:
When configuring GCC with --program-suffix=-$(BASE_VERSION) to allow
installation multiple GCC versions in parallel, the executable of the
driver (gcc-$(BASE_VERSION)) gets recorded in the libgccjit.so.0
library. Assuming, that you only install the libgccjit.so.0 library
from the newest GCC, y
Hi!
The following testcase is miscompiled because of RTL represententation
of bt{l,q} insn followed by e.g. j{c,nc} being misleading to what it
actually does.
Let's look e.g. at
(define_insn_and_split "*jcc_bt"
[(set (pc)
(if_then_else (match_operator 0 "bt_comparison_operator"
The following warning was encountered while building GCC, fix it:
../.././gcc/gcc/config/riscv/bitmanip.md:809:1: warning: source missing a mode?
../.././gcc/gcc/config/riscv/bitmanip.md:809:1: warning: source missing a mode?
gcc/ChangeLog:
* config/riscv/bitmanip.md (*bsetclr_zero_extrac
28 matches
Mail list logo
