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
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"
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!
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 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 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
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
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
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
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
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
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
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/
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
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
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?
> >
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:
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 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
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 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
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 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/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 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/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
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:
+
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
28 matches
Mail list logo
