On Wed, Feb 12, 2025 at 4:04 AM Richard Biener wrote:
>
> The PR indicates a very specific issue with regard to SSA coalescing
> failures because there's a pre IV increment loop exit test. While
> IVOPTs created the desired IL we later simplify the exit test into
> the undesirable form again. Th
On Thu, 2025-02-13 at 09:24 +0800, Lulu Cheng wrote:
>
> 在 2025/2/12 下午6:19, Xi Ruoyao 写道:
> > On Wed, 2025-02-12 at 18:03 +0800, Lulu Cheng wrote:
> >
> > /* snip */
> >
> > > diff --git a/gcc/testsuite/gcc.target/loongarch/pr118828-3.c
> > > b/gcc/testsuite/gcc.target/loongarch/pr118828-3.c
>
On 2/12/25 9:23 PM, Palmer Dabbelt wrote:
PR/117974
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_sched_can_speculate_insn):
(TARGET_SCHED_CAN_SPECULATE_INSN): Implement.
Correct me if I'm wrong, there's not anything inherently wrong with the
speculation from a correctness sta
Hi,
Excerpts from liushuyu's message of Februar 6, 2025 2:02 am:
From: Zixing Liu
This set of patches will add proper IEEE 128 quad precision marking to GDC
compiler, so that it works with the new changes in D standard library
where POWER system can use any math functions inside the standard
On Wed, 12 Feb 2025 16:47:07 PST (-0800), jeffreya...@gmail.com wrote:
On 2/12/25 4:27 PM, Edwin Lu wrote:
The instruction scheduler appears to be speculatively hoisting vsetvl
insns outside of their basic block without checking for data
dependencies. This resulted in a situation where the fol
>> vsetvl pass inserts based on needs of vector instructions.
Yes. vector instructions should make use of scheduler which could minimize
"vsetvli" insertion in VSETVL PASS.
What I said is we should not involve "vsetvli" instruction (not vector
instructions like vadd.vv) in scheduler.
juzhe.zh.
On Wed, Feb 12, 2025 at 1:00 AM Richard Biener
wrote:
>
> On Wed, Feb 12, 2025 at 9:41 AM Andrew Pinski
> wrote:
> >
> > So inline-asm is known not to trap BUT it can have undefined behavior
> > if made executed speculatively. This fixes the loop invariant pass to
> > treat it similarly as trapp
On 2/12/25 6:44 PM, 钟居哲 wrote:
VSETVL PASS is supposed to insert "vsetvli" into optimal place so
"vsetvli" inserted by VSETVL PASS shouldn't involved into instruction
scheduling.
vsetvl pass inserts based on needs of vector instructions. The
scheduler will move code to try and minimize the
在 2025/1/24 下午7:44, Richard Sandiford 写道:
Lulu Cheng writes:
在 2025/1/24 下午3:58, Richard Sandiford 写道:
Lulu Cheng writes:
在 2025/1/22 上午8:49, Xi Ruoyao 写道:
I have no problem with this patch.
But, I have always been confused about the use of reload_completed.
I can understand that it needs
VSETVL PASS is supposed to insert "vsetvli" into optimal place so "vsetvli"
inserted by VSETVL PASS shouldn't involved into instruction scheduling.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2025-02-13 08:47
To: Edwin Lu; gcc-patches
CC: gnu-toolchain; vineetg; juzhe.zhong
Subject: Re: [PATCH]
Hello-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118838
This patch addresses the issue mentioned in the PR (another instance of
_Pragma string location issues). bootstrap + regtest all languages on
aarch64 looks good. Is it OK please for now or for stage 1? Note, it is not
a regression, since
在 2025/2/12 下午6:19, Xi Ruoyao 写道:
On Wed, 2025-02-12 at 18:03 +0800, Lulu Cheng wrote:
/* snip */
diff --git a/gcc/testsuite/gcc.target/loongarch/pr118828-3.c
b/gcc/testsuite/gcc.target/loongarch/pr118828-3.c
new file mode 100644
index 000..a682ae4a356
--- /dev/null
+++ b/gcc/testsu
Ping patch to fix PR target/117251, Add PowerPC XXEVAL support for fusion
optimization in power10
Note, I will be away on vacation from Tuesday February 25th through Friday
March 7th. At this point of time, I do not anticipate bringing a laptop that I
can respond to emails on this account.
Messa
On Wed, Feb 12, 2025 at 6:58 AM Richard Biener wrote:
>
> For the testcase in question which uses a fold-left vectorized
> reduction of a reverse iterating loop we'd need two forwprop
> invocations to first bypass the permute emitted for the reverse
> iterating loop and then to decompose the vecto
Ping patches for adding intial dense math support to a potential future PowerPC
processor:
Note, I will be away on vacation from Tuesday February 25th through Friday
March 7th. At this point of time, I do not anticipate bringing a laptop that I
can respond to emails on this account.
Explation of
Ping the following patch:
Note, I will be away on vacation from Tuesday February 25th through Friday
March 7th. At this point of time, I do not anticipate bringing a laptop that I
can respond to emails on this account.
Message-ID:
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/670787.
Ping patch to fix PR target/99293, Optimize splat of a V2DF/V2DI extract with
constant element:
Note, I will be away on vacation from Tuesday February 25th through Friday
March 7th. At this point of time, I do not anticipate bringing a laptop that I
can respond to emails on this account.
Message
Ping patches 1-2 to separate PowerPC ISA bits from architecture bits set by
-mcpu=.
Note, I will be away on vacation from Tuesday February 25th through Friday
March 7th. At this point of time, I do not anticipate bringing a laptop that I
can respond to emails on this account.
Message-ID
Explan
Ping patch for PR target/108958, Use mtvsrdd to zero extend GPR DImode to VSX
TImode
Note, I will be away on vacation from Tuesday February 25th through Friday
March 7th. At this point of time, I do not anticipate bringing a laptop that I
can respond to emails on this account.
Message-ID
https
Ping patches 1-5 to Add more user friendly TARGET_ names for PowerPC:
Note, I will be away on vacation from Tuesday February 25th through Friday
March 7th. At this point of time, I do not anticipate bringing a laptop that I
can respond to emails on this account.
Message-ID
Information for patc
Ping patch to fix PR target/117487, Add power9/power10 float to logical
operations
Note, I will be away on vacation from Tuesday February 25th through Friday
March 7th. At this point of time, I do not anticipate bringing a laptop that I
can respond to emails on this account.
Message-ID
https:/
x86 conditional branch (jcc) target can be either a label or a symbol.
Add a pass to fold tail call with jcc by turning:
jcc .L6
...
.L6:
jmp tailcall
into:
jcc tailcall
After basic block reordering pass, conditional branches look like
(jump_insn 7 6 14 2 (s
x86 conditional branch (jcc) target can be either a label or a symbol.
Add a pass to fold tail call with jcc by turning:
jcc .L6
...
.L6:
jmp tailcall
into:
jcc tailcall
After basic block reordering pass, conditional branches look like
(jump_insn 7 6 14 2 (s
Enhance fold sibcall pass to fold sibcall targets into jump table by
turning:
foo:
.cfi_startproc
cmpl$4, %edi
ja .L1
movl%edi, %edi
jmp *.L4(,%rdi,8)
.section.rodata
.L4:
.quad .L8
.quad .L7
.quad
On 2/12/25 4:27 PM, Edwin Lu wrote:
The instruction scheduler appears to be speculatively hoisting vsetvl
insns outside of their basic block without checking for data
dependencies. This resulted in a situation where the following occurs
vsetvli a5,a1,e32,m1,tu,ma
vle32.v v2,
The instruction scheduler appears to be speculatively hoisting vsetvl
insns outside of their basic block without checking for data
dependencies. This resulted in a situation where the following occurs
vsetvli a5,a1,e32,m1,tu,ma
vle32.v v2,0(a0)
sub a1,a1,a5 <-- a1 poten
Hi!
On Thu, Feb 13, 2025 at 12:08:30AM +0100, Jason Merrill wrote:
Thanks for the review.
> > + if (tsi_end_p (iter))
> > +*body_p = NULL_TREE;
> > + else
> > +*body_p = tsi_stmt (iter);
>
> This could use a comment that we're setting _BODY temporarily for the next
> function.
Done.
Oops I made a mental note to add one and then completely forgot. I'll
run the testsuite again with the testcase before sending it up as v2.
Edwin
On 2/12/2025 3:38 PM, 钟居哲 wrote:
Could you add PR117974 testcase ?
juzhe.z
LGTM
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2025-02-12 22:03
To: gcc-patches
CC: pal...@dabbelt.com; kito.ch...@gmail.com; juzhe.zh...@rivai.ai;
jeffreya...@gmail.com; pan2...@intel.com; rdapp@gmail.com
Subject: [PATCH] RISC-V: Avoid more unsplit insns in const expander [PR118832].
H
It appears that bin/preprocess-html.py introduces HTML errors when an
... element contains a nested hyperlink. My recent gcc-15 release
note changes passed validation when checked via file upload, but not after
commit via file link. It seems the easiest fix is just to remove the
offending elemen
Could you add PR117974 testcase ?
juzhe.zh...@rivai.ai
From: Edwin Lu
Date: 2025-02-13 07:27
To: gcc-patches
CC: gnu-toolchain; vineetg; juzhe.zhong; Edwin Lu
Subject: [PATCH] RISC-V: Prevent speculative vsetvl insn scheduling
The instruction scheduler appears to be speculatively hoisting vset
On 2/12/25 1:22 PM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/14?
OK.
-- >8 --
While looking into PR118846 I noticed that we don't currently constrain
the linkage of functions involving CNTTPs of internal-linkage types. It
seems to me that this w
The instruction scheduler appears to be speculatively hoisting vsetvl
insns outside of their basic block without checking for data
dependencies. This resulted in a situation where the following occurs
vsetvli a5,a1,e32,m1,tu,ma
vle32.v v2,0(a0)
sub a1,a1,a5 <-- a1 poten
On 2/12/25 5:23 PM, mmalcom...@nvidia.com wrote:
From: Matthew Malcomson
I've posted the patch on the relevant Bugzilla, but also sending to
mailing list. If should have only done one please do mention.
Having it in both places is fine, or send to the mailing list and put a
link to the list
On 2/12/25 7:54 PM, Marek Polacek wrote:
Tested on x86_64-pc-linux-gnu, ok for trunk? I'll also update cxx-status.html.
OK.
-- >8 --
This proposal was implemented a long time ago by my r9-5271,
but it took me this long to verify that it still works as per P2308.
This patch adds assorted tes
On 2/11/25 6:59 PM, Jakub Jelinek wrote:
Hi!
The recent PR86769 r15-7426 changes regressed the following two testcases,
the first one is more important as it is derived from real-world code.
The first problem is that the chosen
prep = do_pushlevel (sk_block);
// emit something
body = push_stmt_
---
htdocs/gcc-15/changes.html | 80 --
1 file changed, 50 insertions(+), 30 deletions(-)
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index e273693a..d7919379 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -
> -Original Message-
> From: Tamar Christina
> Sent: Wednesday, February 12, 2025 3:20 PM
> To: Richard Biener
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: RE: [PATCH v2]middle-end: delay checking for alignment to load
> [PR118464]
>
> > -Original Message-
> > From: Richard Bien
On Wed, Feb 12, 2025 at 01:42:12PM -0700, Jeff Law wrote:
> > I'm fine if your patch is for GCC 15 limited to the easy cases with all 3
> > types compatible (that is the common case). Still, I think it would be nice
> > not to restrict to TYPE_UNSIGNED, just say check either that for a >= b or
>
This is version 3 of the patch.
In version 3, I made the following changes:
1: The new argument to rs6000_reverse_condition that says whether we should
allow ordered floating point compares to be reversed is now an
enumeration instead of a boolean.
2: I tried to make th
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
Fixed by r12-3643.
PR c++/101740
gcc/testsuite/ChangeLog:
* g++.dg/template/dtor12.C: New test.
---
gcc/testsuite/g++.dg/template/dtor12.C | 19 +++
1 file changed, 19 insertions(+)
create mode 100644 gcc/
The attached patch is fairly obvious. The use of notify_std is changed
to a gfc_error. Several test cases had to be adjusted.
Regression tested on x86_64.
OK for trunk?
Regards,
Jerry
Author: Jerry DeLisle
Date: Tue Feb 11 20:57:50 2025 -0800
Fortran: gfortran allows type(C_ptr) in
On 2/12/25 8:44 AM, Jakub Jelinek wrote:
On Wed, Feb 12, 2025 at 08:29:37AM -0700, Jeff Law wrote:
On 2/12/25 8:18 AM, Jakub Jelinek wrote:
On Tue, Feb 11, 2025 at 05:20:49PM -0700, Jeff Law wrote:
So this is a fairly old regression, but with all the ranger work that's been
done, it's becom
On 2/12/25 10:18, Jakub Jelinek wrote:
On Tue, Feb 11, 2025 at 05:20:49PM -0700, Jeff Law wrote:
So this is a fairly old regression, but with all the ranger work that's been
done, it's become easy to resolve.
The basic idea here is to use known relationships between two operands of a
SUB_OVER
Tested on x86_64-pc-linux-gnu, ok for trunk? I'll also update cxx-status.html.
-- >8 --
This proposal was implemented a long time ago by my r9-5271,
but it took me this long to verify that it still works as per P2308.
This patch adds assorted tests, both from clang and from [temp.arg.nontype].
F
On 2/10/25 2:25 AM, Andre Vehreschild wrote:
[PATCH 1/7] Fortran: Move caf_get-rewrite to rewrite.cc [PR107635]
Add a rewriter to keep all expression tree manipulation that is not
optimization together. At the moment this is just a move from resolve.cc,
but will be extended to handle more cases
Ping.
On 1/31/25 10:35, Jørgen Kvalsvik wrote:
Record basic blocks that make up a conditional expression with
-fcondition-coverage and report when using the gcov -w/--verbose flag.
This makes the report more accurate when basic blocks are included as
there may be blocks in-between the actual Boo
...plus, I updated the documentation: -mno-call-main
asserts that main() does not return.
Johann
index 0aef2abf05b..af41d7b9ad3 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -24457,6 +24457,24 @@ Do not save registers in @code{main}. The
effect is the same like
attaching attr
From: Matthew Malcomson
I've posted the patch on the relevant Bugzilla, but also sending to
mailing list. If should have only done one please do mention.
- 8< --- >8
When making warnings trigger a failure in template substitution I
could not find any way
Uros Bizjak writes:
> On Wed, Feb 12, 2025 at 4:16 PM Richard Sandiford
> wrote:
>>
>> Uros Bizjak writes:
>> > The combine pass is trying to combine:
>> >
>> > Trying 16, 22, 21 -> 23:
>> >16: r104:QI=flags:CCNO>0
>> >22: {r120:QI=r104:QI^0x1;clobber flags:CC;}
>> > REG_UNUSED fla
On 05/02/2025 08:05, Tamar Christina wrote:
>
>
> > -Original Message-
> > From: Jan Hubicka
> > Sent: Tuesday, February 4, 2025 4:25 PM
> > To: Alex Coplan
> > Cc: gcc-patches@gcc.gnu.org; Richard Biener ; Tamar
> > Christina
> > Subject: Re: [PATCH 1/4] vect: Set counts of early brea
Hello,
On Fri, Jan 10 2025, Martin Jambor wrote:
> Hello,
>
> On Wed, Dec 11 2024, Martin Jambor wrote:
>> Hello,
>>
>> even though it is not my work, I would like to ping this patch. Having
>> it upstream would really help us a lot.
>>
>
> Please, pretty please, consider reviewing this in time f
On Wed, Feb 12, 2025 at 08:29:37AM -0700, Jeff Law wrote:
> On 2/12/25 8:18 AM, Jakub Jelinek wrote:
> > On Tue, Feb 11, 2025 at 05:20:49PM -0700, Jeff Law wrote:
> > > So this is a fairly old regression, but with all the ranger work that's
> > > been
> > > done, it's become easy to resolve.
> > >
I have applied fixes for everything in the last review, plus some GNU
style fixes that I had missed previously. We have tested and used a
build with this applied for 3-4 months now and haven't run into any
issues.
Jørgen Kvalsvik (2):
gcov: branch, conds, calls in function summaries
Add prime
The gcov function summaries only output the covered lines, not the
branches and calls. Since the function summaries is an opt-in it
probably makes sense to also include branch coverage, calls, and
condition coverage.
$ gcc --coverage -fpath-coverage hello.c -o hello
$ ./hello
Before:
$ gcov -
On Wed, Feb 12, 2025 at 4:16 PM Richard Sandiford
wrote:
>
> Uros Bizjak writes:
> > The combine pass is trying to combine:
> >
> > Trying 16, 22, 21 -> 23:
> >16: r104:QI=flags:CCNO>0
> >22: {r120:QI=r104:QI^0x1;clobber flags:CC;}
> > REG_UNUSED flags:CC
> >21: r119:QI=flags:CC
On 2/12/25 8:18 AM, Jakub Jelinek wrote:
On Tue, Feb 11, 2025 at 05:20:49PM -0700, Jeff Law wrote:
So this is a fairly old regression, but with all the ranger work that's been
done, it's become easy to resolve.
The basic idea here is to use known relationships between two operands of a
SUB_O
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, February 12, 2025 2:58 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: Re: [PATCH v2]middle-end: delay checking for alignment to load
> [PR118464]
>
> On Tue, 11 Feb 2025, Tamar Christina wrote:
>
> >
On Tue, Feb 11, 2025 at 05:20:49PM -0700, Jeff Law wrote:
> So this is a fairly old regression, but with all the ranger work that's been
> done, it's become easy to resolve.
>
> The basic idea here is to use known relationships between two operands of a
> SUB_OVERFLOW IFN to statically compute the
Uros Bizjak writes:
> The combine pass is trying to combine:
>
> Trying 16, 22, 21 -> 23:
>16: r104:QI=flags:CCNO>0
>22: {r120:QI=r104:QI^0x1;clobber flags:CC;}
> REG_UNUSED flags:CC
>21: r119:QI=flags:CCNO<=0
> REG_DEAD flags:CCNO
It looks like something has already gone
For the testcase in question which uses a fold-left vectorized
reduction of a reverse iterating loop we'd need two forwprop
invocations to first bypass the permute emitted for the reverse
iterating loop and then to decompose the vector load that only
feeds element extracts. The following moves the
On Tue, 11 Feb 2025, Tamar Christina wrote:
> Hi All,
>
> This fixes two PRs on Early break vectorization by delaying the safety checks
> to
> vectorizable_load when the VF, VMAT and vectype are all known.
>
> This patch does add two new restrictions:
>
> 1. On LOAD_LANES targets, where the bu
On 2/12/25 7:17 AM, Andrew MacLeod wrote:
The patch is mostly fine, although you probably want to change the
condition to check for a non-null stmt as well... ie
Thanks for the reminder. I saw that defaulting and made a mental note
to test that we actually had a statement, then promptly forg
The patch is mostly fine, although you probably want to change the
condition to check for a non-null stmt as well... ie
- if (subcode == MINUS_EXPR)
+ if (s && subcode == MINUS_EXPR)
because it looks like the stmt defaults to NULL and I suspect the
relation query will trap if S is null.
I
The representation of CONSTRUCTOR nodes in VN NARY and gimple_match_op
do not agree so do not attempt to marshal between them.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
PR tree-optimization/118817
* tree-ssa-sccvn.cc (vn_nary_simplify): Do not process
CONS
Hi,
in PR118832 we have another instance of the problem already noticed in
PR117878. We sometimes use e.g. expand_simple_binop for vector
operations like shift or and. While this is usually OK, it causes
problems when doing it late, e.g. during LRA.
In particular, we might rematerialize a const
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/14?
-- >8 --
While looking into PR118846 I noticed that we don't currently constrain
the linkage of functions involving CNTTPs of internal-linkage types. It
seems to me that this would be sensible to do.
PR c++/118849
gcc/
On Wed, Feb 12, 2025 at 1:14 PM Uros Bizjak wrote:
>
> The combine pass is trying to combine:
>
> Trying 16, 22, 21 -> 23:
>16: r104:QI=flags:CCNO>0
>22: {r120:QI=r104:QI^0x1;clobber flags:CC;}
> REG_UNUSED flags:CC
>21: r119:QI=flags:CCNO<=0
> REG_DEAD flags:CCNO
>23:
The combine pass is trying to combine:
Trying 16, 22, 21 -> 23:
16: r104:QI=flags:CCNO>0
22: {r120:QI=r104:QI^0x1;clobber flags:CC;}
REG_UNUSED flags:CC
21: r119:QI=flags:CCNO<=0
REG_DEAD flags:CCNO
23: {r110:QI=r119:QI|r120:QI;clobber flags:CC;}
REG_DEAD r120:QI
The PR indicates a very specific issue with regard to SSA coalescing
failures because there's a pre IV increment loop exit test. While
IVOPTs created the desired IL we later simplify the exit test into
the undesirable form again. The following fixes this up during RTL
expansion where we try to im
On Wed, 12 Feb 2025 at 12:05, Matthew Malcomson wrote:
>
> Hi there -- since you've not pushed quite yet can I ask that you use the
> following commit message instead of the existing one?
> (Updated a few comments to match what has changed since I wrote that
> message).
>
> Apologies for not notic
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
There are two separate issues making various template parameters behave
as if they were TU-local.
Firstly, the TU-local detection code uses WILDCARD_TYPE_P to check for
types that are not yet concrete; for some reason UNBO
Hi there -- since you've not pushed quite yet can I ask that you use the
following commit message instead of the existing one?
(Updated a few comments to match what has changed since I wrote that
message).
Apologies for not noticing it earlier.
libstdc++: Conditionally use floating-point
Ping
On 03/02/2025 14:46, Tamar Christina wrote:
> Ping
>
> > -Original Message-
> > From: Tamar Christina
> > Sent: Friday, January 24, 2025 9:18 AM
> > To: Alex Coplan ; gcc-patches@gcc.gnu.org
> > Cc: Richard Biener ; Jan Hubicka
> > Subject: RE: [PATCH 2/4] cfgloopmanip: Add infrastr
Almost a copy/paste from the recent aarch64 version of this patch,
this one is a bit more intrusive because it also introduces
arm_general_gimple_fold_builtin.
With this patch,
gcc.target/arm/aes_xor_combine.c scan-assembler-not veor
passes again.
gcc/ChangeLog:
PR target/114522
On Wed, Feb 12, 2025 at 11:06 AM H.J. Lu wrote:
>
> On Wed, Feb 12, 2025 at 5:28 PM Uros Bizjak wrote:
> >
> > On Wed, Feb 12, 2025 at 6:25 AM H.J. Lu wrote:
> > >
> > > Don't assume that stack slots can only be accessed by stack or frame
> > > registers. We first find all registers defined by
On Wed, 2025-02-12 at 18:03 +0800, Lulu Cheng wrote:
/* snip */
> diff --git a/gcc/testsuite/gcc.target/loongarch/pr118828-3.c
> b/gcc/testsuite/gcc.target/loongarch/pr118828-3.c
> new file mode 100644
> index 000..a682ae4a356
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/loongarch/pr
LGTM, thanks
On Wed, 12 Feb 2025 at 09:25, Sam James wrote:
>
> Suggested by Andrew Pinski.
> ---
> htdocs/gcc-15/porting_to.html | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/htdocs/gcc-15/porting_to.html b/htdocs/gcc-15/porting_to.html
> index b9b2efc7..829ae92f 100644
> --- a
This looks more accurate than the current wording, yes.
Specifically, only objects/libraries "built with experimental standard
support" need to be recompiled.
LGTM, but I'll let Jason give approval.
On Wed, 12 Feb 2025 at 09:30, Sam James wrote:
>
> C++ ABI for C++ standards with full suppor
On Wed, Feb 12, 2025 at 4:03 PM Sam James wrote:
>
> "H.J. Lu" writes:
>
> > Don't assume that stack slots can only be accessed by stack or frame
> > registers. We first find all registers defined by stack or frame
> > registers. Then check memory accesses by such registers, including
> > stack
On Wed, Feb 12, 2025 at 5:28 PM Uros Bizjak wrote:
>
> On Wed, Feb 12, 2025 at 6:25 AM H.J. Lu wrote:
> >
> > Don't assume that stack slots can only be accessed by stack or frame
> > registers. We first find all registers defined by stack or frame
> > registers. Then check memory accesses by su
Split the implementation of the function loongarch_cpu_cpp_builtins into two
parts:
1. Macro definitions that do not change (only considering 64-bit architecture)
2. Macro definitions that change with different compilation options.
gcc/ChangeLog:
* config/loongarch/loongarch-c.cc (bu
gcc/ChangeLog:
* config/loongarch/loongarch-target-attr.cc
(loongarch_pragma_target_parse): Move to ...
(loongarch_register_pragmas): Move to ...
* config/loongarch/loongarch-c.cc
(loongarch_pragma_target_parse): ... here.
(loongarch_register_pragmas
v1 -> v2:
1. Move __loongarch_{arch,tune} _LOONGARCH_{ARCH,TUNE}
__loongarch_{div32,am_bh,amcas,ld_seq_sa} and
__loongarch_version_major/__loongarch_version_minor to update function.
2. Fixed PR118843.
3. Add testsuites.
Lulu Cheng (4):
LoongArch: Move the function loongarch_register_pragmas
PR target/118843
gcc/ChangeLog:
* config/loongarch/loongarch-c.cc
(loongarch_update_cpp_builtins): Fix macro definition issues.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/pr118843.c: New test.
Change-Id: I777e46ccbc80bfa8948e7d416ac86853c8f4c16d
---
gcc/co
PR target/118828
gcc/ChangeLog:
* config/loongarch/loongarch-c.cc (loongarch_pragma_target_parse):
Update the predefined macros.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/pr118828.c: New test.
* gcc.target/loongarch/pr118828-2.c: New test.
*
Suggested by Andrew Pinski. I think it makes sense to have it in here even
if perhaps a bit verbose, because we really try to tell bug reporters to
read the page properly.
This could also be a table.
---
htdocs/bugs/index.html | 24
1 file changed, 24 insertions(+)
diff
On Wed, Feb 12, 2025 at 6:25 AM H.J. Lu wrote:
>
> Don't assume that stack slots can only be accessed by stack or frame
> registers. We first find all registers defined by stack or frame
> registers. Then check memory accesses by such registers, including
> stack and frame registers.
>
> gcc/
>
C++ ABI for C++ standards with full support by GCC (rather than those
marked as experimental per https://gcc.gnu.org/projects/cxx-status.html)
should be stable. It's certainly not the case in 2025 that one needs a
full world rebuild for C++ libraries using e.g. the default standard
or any other sup
Suggested by Andrew Pinski.
---
htdocs/gcc-15/porting_to.html | 6 ++
1 file changed, 6 insertions(+)
diff --git a/htdocs/gcc-15/porting_to.html b/htdocs/gcc-15/porting_to.html
index b9b2efc7..829ae92f 100644
--- a/htdocs/gcc-15/porting_to.html
+++ b/htdocs/gcc-15/porting_to.html
@@ -137,6 +1
Hi!
On 2025-02-05T16:12:38+, Andrew Carlotti wrote:
> Various aarch64 tests attempt to reduce the batch size for parallel test
> execution to a single test per batch, but it looks like the necessary
> changes to gcc_parallel_test_run_p were accidentally omitted when the
> aarch64-*-acle-asm.e
On Wed, Feb 12, 2025 at 9:41 AM Andrew Pinski wrote:
>
> So inline-asm is known not to trap BUT it can have undefined behavior
> if made executed speculatively. This fixes the loop invariant pass to
> treat it similarly as trapping cases. If the inline-asm could be executed
> always, then it will
Jeff Law writes:
> On 2/11/25 3:17 PM, Richard Sandiford wrote:
>> Jeff Law writes:
>>> On 2/11/25 9:08 AM, Richard Sandiford wrote:
Jeff Law writes:
> On 2/7/25 5:59 AM, Andrew Waterman wrote:
>> This patch runs counter to the ABI spec, which states that vxrm is not
>> preserve
On Wed, Feb 12, 2025 at 5:39 AM Andrew Pinski wrote:
>
> So unlike loop invariant motion, moving an inline-asm out of an
> if is not always profitable and the cost estimate for the instruction
> inside inline-asm is unknown.
>
> This is a regression from GCC 4.6 which didn't speculatively move inl
So inline-asm is known not to trap BUT it can have undefined behavior
if made executed speculatively. This fixes the loop invariant pass to
treat it similarly as trapping cases. If the inline-asm could be executed
always, then it will be pulled out of the loop; otherwise it will be kept
inside the
Giving it a second thought: instead of checking for something we don't
expect, namely a const_wide_int, and bailing out in such a case, rather
check for something we expect, namely a const_int, and bail out if that
is not the case. This should be more robust.
Bootstrap and regtest are still runni
"H.J. Lu" writes:
> Don't assume that stack slots can only be accessed by stack or frame
> registers. We first find all registers defined by stack or frame
> registers. Then check memory accesses by such registers, including
> stack and frame registers.
>
> gcc/
>
> PR target/109780
> PR target
Due to the presence of R_LARCH_B26 in
/usr/lib/gcc/loongarch64-linux-gnu/14/crtbeginS.o, its addressing
range is [PC-128MiB, PC+128MiB-4]. This means that when the code
segment size exceeds 128MB, linking with lld will definitely fail
(ld will not fail because the order of the two is different).
T
98 matches
Mail list logo
