On Mon, Feb 10, 2025 at 04:21:28PM -, Roger Sayle wrote:
> 2025-02-10 Roger Sayle
>
> include/ChangeLog
> * dwarf2.def(DW_CFA_AARCH64_negate_ra_state_with_pc): Define.
Space after def
Ok for trunk with that nit fixed.
> diff --git a/include/dwarf2.def b/include/dwarf2.def
> index
This is a follow-up to the patch below to avoid generating unrecognized
vsetivl instructions for XTheadVector.
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674185.html
PR target/118601
gcc/ChangeLog:
* config/riscv/riscv-string.cc (expand_block_move): Check with new
On Mon, Jan 27, 2025 at 10:20:05AM -0500, Patrick Palka wrote:
> [snip]
>
> > @@ -18486,6 +18562,12 @@ dependent_operand_p (tree t)
> > {
> >while (TREE_CODE (t) == IMPLICIT_CONV_EXPR)
> > t = TREE_OPERAND (t, 0);
> > +
> > + /* If we contain a TU_LOCAL_ENTITY assume we're non-dependent;
LGTM, that seems right way to fix :)
Jin Ma 於 2025年2月11日 週二 21:45 寫道：
> This is a follow-up to the patch below to avoid generating unrecognized
> vsetivl instructions for XTheadVector.
>
> https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674185.html
>
> PR target/118601
>
> gcc/Cha
On 10/02/2025 08:37, Jin Ma wrote:
On Sun, 09 Feb 2025 14:04:00 +0800, Jin Ma wrote:
PR target/118601
Ok for trunk?
Best regards,
Jin Ma
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_use_by_pieces_infrastructure_p):
Exclude XTheadVector.
Reported-by: Edwin Lu
---
When PRE inserts code it is not fully folded with following SSA
edges which can cause missed optimizations since the next fully
folding pass is way ahead, after strlen which in the PRs case leads
to diagnostics emitted on dead code.
The following mitigates the missed expression canonicalization th
On Tue, 2025-02-11 at 20:49 +0800, Lulu Cheng wrote:
> 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.
On Tue, 11 Feb 2025 20:29:03 +0800, Craig Blackmore wrote:
> On 10/02/2025 08:37, Jin Ma wrote:
> > On Sun, 09 Feb 2025 14:04:00 +0800, Jin Ma wrote:
> >>PR target/118601
> >
> > Ok for trunk?
> >
> > Best regards,
> > Jin Ma
> >
> >> gcc/ChangeLog:
> >>
> >>* config/riscv/riscv.cc (risc
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
>> preserved across calls and is volatile upon function entry [1]. vxrm
>> does not play the same role as frm plays in the calling convention.
>> (I won't get int
Andrew Carlotti writes:
> We agreed with LLVM developer to not enforce the architectural
> dependencies between fp8 multiplication features, and they have already
> been removed from LLVM and Binutils. Remove them from GCC as well.
>
>
>
> I have bootstrapped and regression tested this. There ar
Jeff Law writes:
> On 2/7/25 5:51 AM, Oleg Endo wrote:
>>> Hi,
>>>
>>> Can the issue be resolved in a target independent manner as suggested below?
>>> Or is it better to deal with this in the target code?
> That seems like a pretty heavy hammer though. For that reason alone I
> think this is go
On Mon, Feb 10, 2025 at 11:01 PM Martin Jambor wrote:
>
> Hi,
>
> PR 118125 is a performance regression stemming from the fact that we
> lose the cold attribute of our __builtin_unreachable. The attribute
> is simply and silently dropped on the floor by decl_attributes (in
> attribs.cc) in the pr
On Mon, 10 Feb 2025, Richard Biener wrote:
> On Mon, 10 Feb 2025, Richard Biener wrote:
>
> > The following addresses the fact that we keep an excessive amount of
> > redundant DEBUG BEGIN_STMTs - in the testcase it sums up to 99.999%
> > of all stmts, sucking up compile-time in IL walks. The pa
On Tue, 2025-02-11 at 16:52 +0800, Lulu Cheng wrote:
>
> 在 2025/2/7 下午8:09, Xi Ruoyao 写道:
> /* snip */
> > -
> > -(define_insn "lasx_xvpickev_w"
> > - [(set (match_operand:V8SI 0 "register_operand" "=f")
> > - (vec_select:V8SI
> > - (vec_concat:V16SI
> > - (match_operand:V8SI 1 "regis
On Wed, 12 Feb 2025, Nathaniel Shead wrote:
> On Mon, Jan 27, 2025 at 10:20:05AM -0500, Patrick Palka wrote:
> > [snip]
> >
> > > @@ -18486,6 +18562,12 @@ dependent_operand_p (tree t)
> > > {
> > >while (TREE_CODE (t) == IMPLICIT_CONV_EXPR)
> > > t = TREE_OPERAND (t, 0);
> > > +
> > > +
Jeff Law writes:
> So the change to prefer ADD over IOR for combining two objects with no
> bits in common is (IMHO) generally good. It has some minor fallout.
>
> In particular the aarch64 port (and I suspect others) have patterns that
> recognize IOR, but not PLUS or XOR for these cases and t
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
preserved across calls and is volatile upon function entry [1]. vxrm
does not pl
> PR117081 is about regression in povray. The reducted testcase:
Just for clarification. PR117081 is not about regression in povray.
it's related to FAIL: gcc.target/i386/pr91384.c scan-assembler-not
testl
The pr91384.c is added by r12-7417 which is peephole optimization
expecting some specific ins
在 2025/2/7 下午8:09, Xi Ruoyao 写道:
/* snip */
-
-(define_insn "lasx_xvpickev_w"
- [(set (match_operand:V8SI 0 "register_operand" "=f")
- (vec_select:V8SI
- (vec_concat:V16SI
- (match_operand:V8SI 1 "register_operand" "f")
- (match_operand:V8SI 2 "register_operan
On 2/10/25 11:58 PM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu (and additionally
passed modules.exp with a checking=all build), OK for trunk?
-- >8 --
When instantiating a friend function, we call register_specialization
which adds it to the DECL_TEMPLATE_INSTANTI
On Tue, 2025-02-11 at 15:48 +0800, Lulu Cheng wrote:
> Hi,
>
> I think , the "{lsx_,lasx_x}hv{add,sub}w" in the title should be
> "{lsx_,lasx_x}vh{add,sub}w".
Indeed.
>
> 在 2025/2/7 下午8:09, Xi Ruoyao 写道:
> > Like what we've done for {lsx_,lasx_x}v{add,sub,mul}l{ev,od}, use
> > special predic
On Tue, 2025-02-11 at 15:49 +0800, Lulu Cheng wrote:
> It seems that the title here is "{lsx_,lasx_x}vmaddw".
Will fix in v2.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Tue, Feb 11, 2025 at 4:27 PM H.J. Lu wrote:
>
> On Tue, Feb 11, 2025 at 4:13 PM Hongtao Liu wrote:
> >
> > > PR117081 is about regression in povray. The reducted testcase:
> > Just for clarification. PR117081 is not about regression in povray.
> > it's related to FAIL: gcc.target/i386/pr91384.
On Tue, Feb 11, 2025 at 4:38 PM Hongtao Liu wrote:
>
> On Tue, Feb 11, 2025 at 4:27 PM H.J. Lu wrote:
> >
> > On Tue, Feb 11, 2025 at 4:13 PM Hongtao Liu wrote:
> > >
> > > > PR117081 is about regression in povray. The reducted testcase:
> > > Just for clarification. PR117081 is not about regres
After r7-1651-gac81cf0b2bf5efdd7, the location for the error for #include would
be the location on the token. Except in traditional cpp, the location
information
for directives is all messed up because first libcpp processes the directive
line in traditional
and copies it to a new buffer and then
On 2/10/25 12:09 PM, Simon Martin wrote:
Hi Jason,
On 7 Feb 2025, at 23:10, Jason Merrill wrote:
On 2/7/25 4:04 PM, Simon Martin wrote:
Hi Jason,
On 7 Feb 2025, at 14:21, Jason Merrill wrote:
On 2/6/25 3:05 PM, Simon Martin wrote:
Hi Jason,
On 6 Feb 2025, at 16:48, Jason Merrill wrote:
在 2025/2/11 下午4:37, Xi Ruoyao 写道:
On Tue, 2025-02-11 at 15:48 +0800, Lulu Cheng wrote:
Hi,
I think , the "{lsx_,lasx_x}hv{add,sub}w" in the title should be
"{lsx_,lasx_x}vh{add,sub}w".
Indeed.
在 2025/2/7 下午8:09, Xi Ruoyao 写道:
Like what we've done for {lsx_,lasx_x}v{add,sub,mul}l{ev,od}
On Tue, Feb 11, 2025 at 3:12 PM Uros Bizjak wrote:
>
> On Tue, Feb 11, 2025 at 7:13 AM H.J. Lu wrote:
> >
> > x is not a macro argument. It just happens to work as final.cc passes
> > x for 2nd argument:
> >
> > final.cc: ASM_OUTPUT_SYMBOL_REF (file, x);
> >
> > PR target/118825
> > * confi
Hi!
On 2025-02-08T13:17:55+0100, I wrote:
> pushed to trunk branch commit 6312165650091a4df34668d8e2aaa0bbc4008a66
> "GCN, nvptx: 'sorry, unimplemented: exception handling not supported'"
> For GCN, this avoids ICEs further down the compilation pipeline.
For the record, in case that's helpful la
On Tue, Feb 11, 2025 at 4:13 PM Hongtao Liu wrote:
>
> > PR117081 is about regression in povray. The reducted testcase:
> Just for clarification. PR117081 is not about regression in povray.
> it's related to FAIL: gcc.target/i386/pr91384.c scan-assembler-not
> testl
> The pr91384.c is added by r12
The problem here is with deferred pragmas, libcpp would inject a
PRAGMA_EOL before the end of the new line in the tokens stream
but traditional cpp path does not use that path except when
dealing with directives. In this case we call out to handle `#if`
directive and that token got added due to the
During combine we may end up with
(set (reg:DI 66 [ _6 ])
(ashift:DI (reg:DI 72 [ x ])
(subreg:QI (and:TI (reg:TI 67 [ _1 ])
(const_wide_int 0x0aabf))
15)))
where the shift count operand does not trivia
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
preserved across calls and is volatile upon function entry [1]. vxrm
does not play the same role as frm plays in th
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_list ();
// emit further stuff
body = pop_s
Hi!
The following testcase IMO in violation of the P2552R3 paper doesn't
pedwarn on alignas applying to dependent types or alignas with dependent
argument.
tsubst was just ignoring TYPE_ATTRIBUTES.
The following patch fixes it for the POINTER/REFERENCE_TYPE and
ARRAY_TYPE cases, but perhaps we n
target/PR118828
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.
Change-Id: I13f7b44b11bba2080db797157a0389cc1bd65ac6
---
gcc/co
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
Refer to the implementation of aarch64 to fix PR118828.
Lulu Cheng (3):
LoongArch: Move the function loongarch_register_pragmas to
loongarch-c.cc.
LoongArch: Split the function loongarch_cpu_cpp_builtins into two
functions.
LoongArch: After setting the compilation options, update the
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
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-7474-ge8c5013b6b7820.
gcc/ChangeLog:
PR sarif-replay/118792
* libsarifreplay.cc (sarif_replayer::handle_region_object): Fix
off-by-one in handling of endColumn property so that the code
On 2/7/25 12:18 PM, Richard Sandiford wrote:
FWIW, here's a very rough initial version of the kind of thing
I was thinking about. Hopefully the hook documentation describes
the approach. It's deliberately (overly?) flexible.
I've included an aarch64 version that (a) models the fact that the
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 overflow state and
ultimately allow turning the IFN into simple
在 2025/2/11 下午9:26, Xi Ruoyao 写道:
On Tue, 2025-02-11 at 20:49 +0800, Lulu Cheng wrote:
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
在 2025/2/7 下午8:09, Xi Ruoyao 写道:
These pattern definitions are tediously long, invoking 32 UNSPECs and
many hard-coded long const vectors. To simplify them, at first we use
the TImode vector operations instead of the UNSPECs, then we adopt an
approach in AArch64: using a special predicate to m
A couple of Vector pseudoinstructions use x0 scalar which could be
inefficient on wider uarches due to regfile crossing.
Instead use the imm 0 form, which should be functionally equivalent.
pseudoinsnorig insn with x0 this patch
--
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 inline-asm
as far as I can tell.
Bootstrapped and tested on x86_64-l
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/109093
* config/i386/i386.cc (ix86_
Tamar Christina writes:
> Hi All,
>
> It seems I ran regressions but forgot to check them last time `(*>?<*)?
>
> On the GCC-13 branch the backport caused a failure due to the branch not
> having
> generic-armv8-a and also it still treating the generic cpu special. This made
> it return NULL whe
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The implementation in r15-3840 used a novel technique of wrapping the entire
range-for loop in a CLEANUP_POINT_EXPR, which confused the coroutines
transformation. Instead let's use the existing extend_ref_init_temps
mechanism.
This does no
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
preserved across calls and is volatile upon functio
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Since -frange-for-ext-temps has been causing trouble, let's not enable it
by default in pre-C++23 GNU modes for GCC 15, and also allow disabling it in
C++23 and up.
PR c++/188574
gcc/c-family/ChangeLog:
* c-opts.cc (c_comm
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we ICE since r11-7740 because we no longer say that (long)&a
(where a is a global var) is non_constant_p. So VERIFY_CONSTANT
does not return and we crash on tree_to_uhwi. We should check
tree_fits_uhwi_p before calling tr
On 2/9/25 5:20 AM, Vineet Gupta wrote:
On 2/8/25 23:02, 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 inefficient on certain wider uarches.
Use the imm 0 form, which should be functionally equi
On 2/11/25 12:35 AM, Yangyu Chen wrote:
As discussed from RISC-V C-API PR #101 [1], As discussed in #96, current
interface is insufficient to support some cases, like a vendor buying a
CPU IP from the upstream vendor but using their own mvendorid and custom
features from the upstream vendor. I
For some time I've been seeing this Texinfo warning in my builds:
.../gcc/doc/install.texi:2295: warning: `.' or `,' must follow @xref, not f
Fixed thusly.
gcc/ChangeLog
* doc/install.texi: Add missing comma after @xref to fix warning.
---
gcc/doc/install.texi | 2 +-
1 file changed, 1
I spotted some typos in the GCC manual. Since often these are a sign
that the text was inserted without being proofread, I looked at the
context and fixed some grammar/punctuation/wording issues as well.
gcc/ChangeLog
* doc/extend.texi: Fix a bunch of typos and other writing bugs.
The "Interfacing to GCC Output" chapter used to be part of the
user-facing GCC documentation but ended up in the GCC internals manual
when the two documents were separated in 2001. It hasn't been updated
in any substantive way since then, and is now very bit-rotten. (PCC is
no longer the "standar
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
preserved across calls and is volatile upon functio
在 2025/2/12 上午3:30, Xi Ruoyao 写道:
On Tue, 2025-02-11 at 16:52 +0800, Lulu Cheng wrote:
在 2025/2/7 下午8:09, Xi Ruoyao 写道:
/* snip */
-
-(define_insn "lasx_xvpickev_w"
- [(set (match_operand:V8SI 0 "register_operand" "=f")
- (vec_select:V8SI
- (vec_concat:V16SI
- (match_
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.
I wonder i
On Wed, Feb 12, 2025 at 3:16 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
61 matches
Mail list logo
