Hi.
When I implemented a hash table with reference to the C++ STL, I found that
when the hash table in the C++ STL deletes elements, if the first element
deleted is the begin element, the before begin node is repeatedly assigned.
This creates unnecessary performance overhead.
First, let’s see th
Thanks. Done.
2024年1月17日(水) 12:39 Sam James :
>
> Huanghui Nie writes:
>
> > Hi.
>
> Please CC the libstdc++ LM for libstdc++ patches, per
>
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html#list.patches
> .
>
> > [...]
>
>
On 2024-01-16 15:44, Jakub Jelinek wrote:
On Tue, Jan 16, 2024 at 03:11:39PM +0100, Daniel Cederman wrote:
When GCC is configured with --enable-target-optspace the compiler generates
a memcpy call in the Symbolizer constructor in sanitizer_symbolizer.cpp
when compiling for SPARC V8. Add HAVE_AS_
On Wed, 17 Jan 2024, 08:14 Huanghui Nie via Gcc, wrote:
> Thanks. Done.
>
And don't CC the main gcc@ list, that's not for patch discussion. And if
you CC the right list, you don't need to CC the individual maintainers.
Anyway, it's on the right list now so we'll review it there, thanks.
> 20
Tested on x86_64, aarch64 Darwin21 (which default to heap-based trampolines)
and on x86_64 Darwin19 and Linux (which default to executable stack
trampolines).
OK for trunk?
Iain
--- 8< ---
The symbols for the functions supporting heap-based trampolines were
exported at an incorrect symbol version
Hi Andrew,
On 16/01/2024 19:29, Andrew Pinski wrote:
> So the problem here is that aarch64_ldp_reg_operand will all subreg even
> subreg of lo_sum.
> When LRA tries to fix that up, all things break. So the fix is to change the
> check to only
> allow reg and subreg of regs.
Thanks a lot for tra
From: Pan Li
The recent middle-end change result in some asm check failures.
This patch would like to fix the asm check by adjust the times.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vls/shift-1.c: Fix asm check
count.
* gcc.target/riscv/rvv/autovec/vls/shi
LGTM。
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-01-17 17:00
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Fix asm checks regression due to recent middle-end
change
From: Pan Li
The recent middle-end change result in some asm check failu
Committed, thanks Juzhe.
Pan
From: juzhe.zh...@rivai.ai
Sent: Wednesday, January 17, 2024 5:02 PM
To: Li, Pan2 ; gcc-patches
Cc: Li, Pan2 ; Wang, Yanzhang ;
kito.cheng
Subject: Re: [PATCH v1] RISC-V: Fix asm checks regression due to recent
middle-end change
LGTM。
__
> On 17 Jan 2024, at 08:55, Iain Sandoe wrote:
>
> Tested on x86_64, aarch64 Darwin21 (which default to heap-based trampolines)
> and on x86_64 Darwin19 and Linux (which default to executable stack
> trampolines).
> OK for trunk?
Hmm.. maybe this is not right and the builtins should still be
On Tue, Jan 16, 2024 at 07:29:04PM -0800, Andrew Pinski wrote:
> So the problem here is that aarch64_ldp_reg_operand will all subreg even
> subreg of lo_sum.
> When LRA tries to fix that up, all things break. So the fix is to change the
> check to only
> allow reg and subreg of regs.
>
> Note th
On Wed, Jan 17, 2024 at 09:17:09AM +0100, Daniel Cederman wrote:
> On 2024-01-16 15:44, Jakub Jelinek wrote:
> > On Tue, Jan 16, 2024 at 03:11:39PM +0100, Daniel Cederman wrote:
> > > When GCC is configured with --enable-target-optspace the compiler
> > > generates
> > > a memcpy call in the Symbo
On Wed, Jan 17, 2024 at 09:04:08AM +, Iain Sandoe wrote:
> > On 17 Jan 2024, at 08:55, Iain Sandoe wrote:
> >
> > Tested on x86_64, aarch64 Darwin21 (which default to heap-based trampolines)
> > and on x86_64 Darwin19 and Linux (which default to executable stack
> > trampolines).
> > OK for t
This patch fixes SPEC2017 cam4 mismatch issue due to we miss has compatible
check
for conflict vsetvl fusion.
Buggy assembler before this patch:
.L69:
vsetvli a5,s1,e8,mf4,ta,ma -> buggy vsetvl
vsetivlizero,8,e8,mf2,ta,ma
vmv.v.i v1,0
vse8
Hello Kewen:
On 17/01/24 12:32 pm, Kewen.Lin wrote:
> on 2024/1/16 06:22, Ajit Agarwal wrote:
>> Hello Richard:
>>
>> On 15/01/24 6:25 pm, Ajit Agarwal wrote:
>>>
>>>
>>> On 15/01/24 6:14 pm, Ajit Agarwal wrote:
Hello Richard:
On 15/01/24 3:03 pm, Richard Biener wrote:
> On Sun,
From: YunQiang Su
Currently, almost all of the shared libraries of MIPS, rely on $t9
to get the address of current function, instead of PCREL instructions,
even on MIPSr6. So we have to set $t9 properly.
To get the address of preemptible function, we need the help of GOT.
MIPS/O32 has .cpload, w
Hi!
Seems pass_ipa_strub::execute contains a copy of the expand_thunk
code I've changed for _BitInt in r14-6805 PR112941 - larger _BitInts
are aggregate_value_p even when they are is_gimple_reg_type.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
2024-01-17 J
Hi!
Unlike NOP_EXPR/CONVERT_EXPR which are GIMPLE_UNARY_RHS, VIEW_CONVERT_EXPR
is GIMPLE_SINGLE_RHS and so gimple_assign_rhs1 contains the operand wrapped
in VIEW_CONVERT_EXPR tree.
So, to handle it like other casts we need to look through it.
Bootstrapped/regtested on x86_64-linux and i686-linu
On Wed, 2024-01-17 at 17:38 +0800, chenglulu wrote:
>
> 在 2024/1/13 下午9:05, Xi Ruoyao 写道:
> > 在 2024-01-13星期六的 15:01 +0800，chenglulu写道：
> > > 在 2024/1/12 下午7:42, Xi Ruoyao 写道:
> > > > 在 2024-01-12星期五的 09:46 +0800，chenglulu写道：
> > > >
> > > > > > I found an issue bootstrapping GCC with -mcmodel=ex
This allows the backend to generate movcc instructions, if target
machine has movcc pattern.
branchless-cond.c needs to be updated since some target machines have
conditional move instructions, and the experssion will not change to
branchless expression.
gcc/ChangeLog:
PR target/113095
Hi!
The following patch adds support for _BitInt iterators of OpenMP canonical
loops (with the preexisting limitation that when not using compile time
static scheduling the iterators in the library are at most unsigned long long
or signed long, so one can't in the runtime/dynamic/guided etc. cases
在 2024/1/17 下午5:50, Xi Ruoyao 写道:
On Wed, 2024-01-17 at 17:38 +0800, chenglulu wrote:
在 2024/1/13 下午9:05, Xi Ruoyao 写道:
在 2024-01-13星期六的 15:01 +0800，chenglulu写道：
在 2024/1/12 下午7:42, Xi Ruoyao 写道:
在 2024-01-12星期五的 09:46 +0800，chenglulu写道：
I found an issue bootstrapping GCC with -mcmodel=ex
Hi!
The following testcase is miscompiled because the bitint lowering emits a
.MULBITINT (&a, 1024, &a, 1024, &x, 1024);
call. The bug is in the overlap between the destination and source, that is
something the libgcc routines don't handle, they use the source arrays
during the entire algorithm
* config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.
---
.../abi/post/riscv64-linux-gnu/baseline_symbols.txt | 9 +
1 file changed, 9 insertions(+)
diff --git
a/libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt
b/libstdc++-v3/config/abi/post/r
> -Original Message-
> From: Andrew Pinski
> Sent: Wednesday, January 17, 2024 3:29 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Alex Coplan ; Andrew Pinski
>
> Subject: [PATCH] aarch64: Fix aarch64_ldp_reg_operand predicate not to allow
> all subreg [PR113221]
>
> So the problem here is th
Hi!
When looking at PR113410, I found a comment typo and just searched for
the same typo elsewhere and found some typos in the comments which had
that typo as well.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to
trunk as obvious.
2024-01-17 Jakub Jelinek
* tree-i
Hi!
WHen a VLA is created with some very high precision size expression
(say __int128, or _BitInt(65535) etc.), we cast it to sizetype, because
we can't have arrays longer than what can be expressed in sizetype.
But the maybe_check_access_sizes code when trying to determine ranges
wasn't doing th
I'm sorry for CC the gcc@ list. Waiting for your review results there.
Thanks.
2024年1月17日(水) 16:18 Jonathan Wakely :
>
>
> On Wed, 17 Jan 2024, 08:14 Huanghui Nie via Gcc, wrote:
>
>> Thanks. Done.
>>
>
> And don't CC the main gcc@ list, that's not for patch discussion. And if
> you CC the right
Hi!
This testcase started to hang at -O3 with r13-4208 and got fixed
with r14-2097.
Regtested on x86_64-linux and i686-linux, committed to trunk as obvious.
2024-01-17 Jakub Jelinek
PR tree-optimization/110251
* gcc.c-torture/compile/pr110251.c: New test.
--- gcc/testsuite/g
On Wed, 17 Jan 2024, Jonathan Wakely wrote:
> So we can remove the dependency on __STRICT_ISO__ for 128-bit integer
> types, and implementing std::is_integral with a built-in seems like
> the perfect time to do that. But that seems like stage 1 material, as
> we need to go through the library and
SEH _Unwind_Resume_or_Rethrow invokes abort directly if
_Unwind_RaiseException doesn't manage to find a handler for the rethrown
exception; this is incorrect, as in this case std::terminate should be
invoked, allowing an application-provided terminate handler to handle
the situation instead of stra
On Tue, 16 Jan 2024 at 21:28, Jonathan Wakely wrote:
>
> Tested aarch64-linux. I plan to push this to fix an error when using
> trunk with Clang.
Pushed.
>
> -- >8 --
>
> We were relying on P1814R0 (CTAD for alias templates) which isn't
> supported by Clang. We can just not use CTAD and provide a
On Wed, 17 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> Seems pass_ipa_strub::execute contains a copy of the expand_thunk
> code I've changed for _BitInt in r14-6805 PR112941 - larger _BitInts
> are aggregate_value_p even when they are is_gimple_reg_type.
>
> Fixed thusly, bootstrapped/regtested on
On Wed, 17 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> Unlike NOP_EXPR/CONVERT_EXPR which are GIMPLE_UNARY_RHS, VIEW_CONVERT_EXPR
> is GIMPLE_SINGLE_RHS and so gimple_assign_rhs1 contains the operand wrapped
> in VIEW_CONVERT_EXPR tree.
>
> So, to handle it like other casts we need to look through
Here's the final version that I pushed.
Tested aarch64-linux, x86_64-linux.
commit df0a668b784556fe4317317d58961652d93d53de
Author: Jonathan Wakely
Date: Mon Jan 15 15:42:50 2024
libstdc++: Implement C++26 std::text_encoding (P1885R12) [PR113318]
This is another C++26 change, appr
On Wed, 17 Jan 2024, Monk Chiang wrote:
> This allows the backend to generate movcc instructions, if target
> machine has movcc pattern.
>
> branchless-cond.c needs to be updated since some target machines have
> conditional move instructions, and the experssion will not change to
> branchless ex
On Wed, 17 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> WHen a VLA is created with some very high precision size expression
> (say __int128, or _BitInt(65535) etc.), we cast it to sizetype, because
> we can't have arrays longer than what can be expressed in sizetype.
>
> But the maybe_check_access_s
Hi,
expr_expected_value is doing some guesswork when it is merging two or more
independent value predictions either in PHI node or in binary operation.
Since we do not know how the predictions interact with each other, we can
not really merge the values precisely.
The previous logic merged the pre
On Wed, Jan 17, 2024 at 01:45:18PM +0100, Jan Hubicka wrote:
> Hi,
> expr_expected_value is doing some guesswork when it is merging two or more
> independent value predictions either in PHI node or in binary operation.
> Since we do not know how the predictions interact with each other, we can
> no
> > +falign-all-functions
> > +Common Var(flag_align_all_functions) Optimization
> > +Align the start of functions.
>
> all functions
>
> or maybe "of every function."?
Fixed, thanks!
> > +@opindex falign-all-functions=@var{n}
> > +@item -falign-all-functions
> > +Specify minimal alignment for f
>
> Please fill in what has changed, both for predict-18.c and predict.{cc,def}
> changes.
Sorry, I re-generated the patch after fixing some typos and forgot to
copy over the changelog.
>
> > @@ -2613,24 +2658,40 @@ expr_expected_value_1 (tree type, tree op0, enum
> > tree_code code,
> >
On 1/3/2024 5:14 PM, Lipeng Zhu wrote:
On 2023/12/21 19:42, Thomas Schwinge wrote:
Hi!
On 2023-12-13T21:52:29+0100, I wrote:
On 2023-12-12T02:05:26+, "Zhu, Lipeng" wrote:
On 2023/12/12 1:45, H.J. Lu wrote:
On Sat, Dec 9, 2023 at 7:25 PM Zhu, Lipeng
wrote:
On 2023/12/9 23:23, Jaku
On Wed, 17 Jan 2024, Jan Hubicka wrote:
> > > +falign-all-functions
> > > +Common Var(flag_align_all_functions) Optimization
> > > +Align the start of functions.
> >
> > all functions
> >
> > or maybe "of every function."?
>
> Fixed, thanks!
> > > +@opindex falign-all-functions=@var{n}
> > > +@
On Wed, 17 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled because the bitint lowering emits a
> .MULBITINT (&a, 1024, &a, 1024, &x, 1024);
> call. The bug is in the overlap between the destination and source, that is
> something the libgcc routines don't handle,
>
> I meant the new option might be named -fmin-function-alignment=
> rather than -falign-all-functions because of how it should
> override all other options.
I was also pondering about both names. -falign-all-functions has the
advantage that it is similar to all the other alignment flags that a
Hi Juzhe,
the change itself is OK but I don't think we should add binary
files like this. Even if not ideal, if you want to go forward
IMHO let's skip the test for now and add it at a (not much) later
time.
> diff --git
> a/gcc/testsuite/gcc.target/riscv/rvv/fortran/spec2017_cam4/ppgrid.mod
>
Hello,
On Wed, 17 Jan 2024, Ajit Agarwal wrote:
> > first is even, since OOmode is only ok for even vsx register and its
> > size makes it take two consecutive vsx registers.
> >
> > Hi Peter, is my understanding correct?
> >
>
> I tried all the combination in the past RA is not allocating seq
On Wed, 17 Jan 2024, Jan Hubicka wrote:
> >
> > I meant the new option might be named -fmin-function-alignment=
> > rather than -falign-all-functions because of how it should
> > override all other options.
>
> I was also pondering about both names. -falign-all-functions has the
> advantage tha
This patch fixes SPEC2017 cam4 mismatch issue due to we miss has compatible
check
for conflict vsetvl fusion.
Buggy assembler before this patch:
.L69:
vsetvli a5,s1,e8,mf4,ta,ma -> buggy vsetvl
vsetivlizero,8,e8,mf2,ta,ma
vmv.v.i v1,0
vse8
OK.
Regards
Robin
Recent commit introduced a conditional branch in eh_return epilogues
that is not compatible with speculation tracking:
commit 426fddcbdad6746fe70e031f707fb07f55dfb405
Author: Szabolcs Nagy
CommitDate: 2023-11-27 15:52:48 +
aarch64: Use br instead of ret for eh_return
gcc/ChangeL
On 1/17/24 05:14, Richard Biener wrote:
On Wed, 17 Jan 2024, Monk Chiang wrote:
This allows the backend to generate movcc instructions, if target
machine has movcc pattern.
branchless-cond.c needs to be updated since some target machines have
conditional move instructions, and the experssio
On 1/13/24 08:43, Alex Coplan wrote:
The next patch in this series exposes an interface for creating new uses
in RTL-SSA. The intent is that new user-created uses can consume new
user-created defs in the same change group. This is so that we can
correctly update uses of memory when inserting
Hi,
On Wed, Jan 10 2024, Jakub Jelinek wrote:
> Hi!
>
> As changed in other parts of the compiler, using
> build_nonstandard_integer_type is not appropriate for arbitrary precisions,
> especially if the precision comes from a BITINT_TYPE or something based on
> that, build_nonstandard_integer_type
On 17/01/2024 07:42, Jeff Law wrote:
>
>
> On 1/13/24 08:43, Alex Coplan wrote:
> > The next patch in this series exposes an interface for creating new uses
> > in RTL-SSA. The intent is that new user-created uses can consume new
> > user-created defs in the same change group. This is so that w
On Wed, Jan 17, 2024 at 03:46:44PM +0100, Martin Jambor wrote:
> > Note, it would be good if we were able to punt on the optimization
> > (but this code doesn't seem to be able to punt, so it needs to be done
> > somewhere earlier) at least in cases where building it would be invalid.
> > E.g. righ
The current ldp/stp policy framework implementation was missing cases, where
the memory operands were reversed. Therefore the call to the framework function
is moved after the lower mem check with the suitable parameters. Also removes
the mode of aarch64_operands_ok_for_ldpstp, which becomes unused
On Wed, Jan 17, 2024 at 8:39 AM Maxim Kuvyrkov
wrote:
>
> > On Jan 17, 2024, at 10:51, Richard Biener
> > wrote:
> >
> > On Tue, Jan 16, 2024 at 3:52 PM Jeff Law wrote:
> >>
> >>
> >>
> >> On 1/15/24 05:56, Maxim Kuvyrkov wrote:
> >>> Hi Vladimir,
> >>> Hi Jeff,
> >>>
> >>> Richard and Alexande
> On Jan 17, 2024, at 19:02, Richard Biener wrote:
>
> On Wed, Jan 17, 2024 at 8:39 AM Maxim Kuvyrkov
> wrote:
>>
>>> On Jan 17, 2024, at 10:51, Richard Biener
>>> wrote:
>>>
>>> On Tue, Jan 16, 2024 at 3:52 PM Jeff Law wrote:
On 1/15/24 05:56, Maxim Kuvyrkov wrote:
>
... caused by scheduler fix for PR96388 and PR111554.
This patch adjusts decision sched-deps.cc:find_inc() to use
length of dependency lists sans any DEBUG_INSN instructions.
gcc/ChangeLog:
* haifa-sched.cc (dep_list_size): Make global.
* sched-deps.cc (find_inc): Use instead of
On Mon, 15 Jan 2024, Jason Merrill wrote:
> On 1/5/24 11:50, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > for trunk and perhaps 13?
> >
> > -- >8 --
> >
> > invalid_tparm_referent_p was rejecting using the address of a class NTTP
> > object as
> On Jan 17, 2024, at 19:05, Maxim Kuvyrkov wrote:
>
>> On Jan 17, 2024, at 19:02, Richard Biener wrote:
>>
>> On Wed, Jan 17, 2024 at 8:39 AM Maxim Kuvyrkov
>> wrote:
>>>
On Jan 17, 2024, at 10:51, Richard Biener
wrote:
On Tue, Jan 16, 2024 at 3:52 PM Jeff Law wrote:
On 1/17/24 01:33, Nathaniel Shead wrote:
On Mon, Jan 15, 2024 at 06:10:55PM -0500, Jason Merrill wrote:
Under what circumstances does it make sense for CLASSTYPE_INTERFACE_ONLY to
be set in the context of modules, anyway? We probably want to propagate it
for things in the global module so that
> On Wed, 17 Jan 2024, Jan Hubicka wrote:
>
> > >
> > > I meant the new option might be named -fmin-function-alignment=
> > > rather than -falign-all-functions because of how it should
> > > override all other options.
> >
> > I was also pondering about both names. -falign-all-functions has the
On 1/8/24 12:04, Patrick Palka wrote:
On Mon, 8 Jan 2024, Nathaniel Shead wrote:
On Sat, Jan 06, 2024 at 05:32:37PM -0500, Nathan Sidwell wrote:
I;m not sure about this, there was clearly a reason I did it the way it is,
but perhaps that reasoning became obsolete -- something about an existing
On 1/17/24 10:43, Patrick Palka wrote:
On Mon, 15 Jan 2024, Jason Merrill wrote:
On 1/5/24 11:50, Patrick Palka wrote:
invalid_tparm_referent_p was rejecting using the address of a class NTTP
object as a template argument, but this should be fine.
Hmm, I suppose so; https://eel.is/c++draft/t
On Wed, Jan 17, 2024 at 03:40:20PM +, Maxim Kuvyrkov wrote:
> ... caused by scheduler fix for PR96388 and PR111554.
>
> This patch adjusts decision sched-deps.cc:find_inc() to use
> length of dependency lists sans any DEBUG_INSN instructions.
>
> gcc/ChangeLog:
>
Please mention
PR b
Hi Andre,
> -Original Message-
> From: Andre Vieira
> Sent: Friday, January 5, 2024 5:52 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Stam Markianos-Wright
>
> Subject: [PATCH v2 2/2] arm: Add support for MVE Tail-Predicated Low Overhead
> Loops
>
> Respin after comments on
PR110934 is a problem on m68k where -fzero-call-used-regs -fpic ICEs
when clearing an FP register.
The generic code generates an XFmode move of zero to that register,
which becomes an XFmode load from initialized data, which due to -fpic
uses a non-constant address, which the backend rejects. The
> Can we backport the patch(at least the generic part) to
> GCC11/GCC12/GCC13 release branch?
Yes, the periodic testers has took the change and as far as I can tell,
there are no surprises.
Thanks,
Honza
> > > >
> > > > /* X86_TUNE_AVOID_512FMA_CHAINS: Avoid creating loops with tight
> > > > 51
Hi,
I have noticed quite bad pasto in handling of X86_TUNE_AVOID_512FMA_CHAINS. At
the
moment it is ignored, but X86_TUNE_AVOID_256FMA_CHAINS controls 512FMA too.
This patch fixes it, we may want to re-check how that works on AVX512 machines.
Bootstrapped/regtested x86_64-linux, will commit it s
Hi,
I managed to commit a hack setting offset to 0 in
ipa_polymorphic_call_context::set_by_invariant. This makes it to give up on
multiple
inheritance, but most likely won't give bad code since the ohter base will be of
different type.
Bootstrapped/regtested x86_64-linux, comitted.
gcc/Change
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 replacements. Because we can't
have that after ASM go
On Wed, Jan 17, 2024 at 7:02 AM Richard Biener
wrote:
>
> On Wed, Jan 17, 2024 at 8:39 AM Maxim Kuvyrkov
> wrote:
> >
> > > On Jan 17, 2024, at 10:51, Richard Biener
> > > wrote:
> > >
> > > On Tue, Jan 16, 2024 at 3:52 PM Jeff Law wrote:
> > >>
> > >>
> > >>
> > >> On 1/15/24 05:56, Maxim Kuv
> -Original Message-
> From: Alex Coplan
> Sent: Wednesday, January 17, 2024 12:59 AM
> To: Andrew Pinski (QUIC)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] aarch64: Fix aarch64_ldp_reg_operand predicate not to
> allow all subreg [PR113221]
>
> Hi Andrew,
>
> On 16/01/2024 19:2
When staring at VSETVL pass for PR/113429, spotted some minor
improvements.
1. For readablity, remove some redundant condition check in Phase 2
function earliest_fuse_vsetvl_info ().
2. Add iteration count in debug prints in same function.
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc
RVV requires VSET?VL? instructions to dynamically configure VLEN at
runtime. There's a custom pass to do that which has a simple mode
which generates a VSETVL for each V insn and a lazy/optimal mode which
uses LCM dataflow to move VSETVL around, identify/delete the redundant
ones.
Currently simple
Hi
Looks like a great finding to me, this is indeed a useless check, thanks!
Have you any figures on the performance enhancement ? It might help to
get proper approval as gcc is currently in dev stage 4 that is to say
only bug fixes normally.
François
On 17/01/2024 09:11, Huanghui Nie wrote
So the problem here is that aarch64_ldp_reg_operand will all subreg even subreg
of lo_sum.
When LRA tries to fix that up, all things break. So the fix is to change the
check to only
allow reg and subreg of regs.
Note the tendancy here is to use register_operand but that checks the mode of
the r
gcc/ChangeLog
PR middle-end/111659
* doc/extend.texi (Common Variable Attributes): Fix long lines
in documentation of strict_flex_array + other minor copy-editing.
Add a cross-reference to -Wstrict-flex-arrays.
* doc/invoke.texi (Option Summary): Fix whitespa
These sections used to be alphabetized, but when I was working on the
fix for PR111659 I noticed documentation for some newer attributes had
been inserted at random places in the tables instead of maintaining
alphabetical order. There's no change to content here, just moving
blocks of text around.
ok for master ?
Bootstrapped on power8 (cfarm135), power9 (cfarm120) and
x86_64-linux-gnu.
---
This patch corrects commit
r14-4149-g81d5ca0b9b8431f1bd7a5ec8a2c94f04bb0cf032 which assummed
all powerpc platforms would have IEEE754 long double. The patch
ensures that cc1gm2 obtains the default I
David,
On Jan 7, 2024, "Kewen.Lin" wrote:
> As PR113100 shows, the unbiasing introduced by r14-6737 can
> cause the scrubbing to overrun and screw some critical data
> on stack like saved toc base consequently cause segfault on
> Power.
I suppose this problem that Kewen fixed (thanks) was what
V3: Rebase to trunk and commit it.
This patch fixes SPEC2017 cam4 mismatch issue due to we miss has compatible
check
for conflict vsetvl fusion.
Buggy assembler before this patch:
.L69:
vsetvli a5,s1,e8,mf4,ta,ma -> buggy vsetvl
vsetivlizero,8,e8,mf2,ta,
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
In grokdeclarator/cdk_function the comment says that the find_xobj_parm
lambda clears TREE_PURPOSE so that we can correctly detect an xobj that
is not the first parameter. That's all good, but we should also clear
the TREE_PURP
If the fixes remove the failures on AIX, then the patch to disable the
tests also can be reverted.
Thanks, David
On Wed, Jan 17, 2024 at 8:06 PM Alexandre Oliva wrote:
> David,
>
> On Jan 7, 2024, "Kewen.Lin" wrote:
>
> > As PR113100 shows, the unbiasing introduced by r14-6737 can
> > cause
These warnings are enabled by default, thus the manual should document the
-no form instead of the positive form.
gcc/ChangeLog
PR middle-end/110847
* doc/invoke.texi (Option Summary): Document negative forms of
-Wtsan and -Wxor-used-as-pow.
(Warning Options): Likew
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
Some _Safe_iterator member functions define a variable of non-literal
type __gnu_cxx::__scoped_lock, which automatically disqualifies them from
being constexpr in C++20 mode even if that code path is never constant
evaluated. T
Thanks for your advice!! I agree it should be fixed in the RISC-V backend
when expansion.
On Wed, Jan 17, 2024 at 10:37 PM Jeff Law wrote:
>
>
> On 1/17/24 05:14, Richard Biener wrote:
> > On Wed, 17 Jan 2024, Monk Chiang wrote:
> >
> >> This allows the backend to generate movcc instructions, i
On Wed, 17 Jan 2024 19:19:58 PST (-0800), monk.chi...@sifive.com wrote:
Thanks for your advice!! I agree it should be fixed in the RISC-V backend
when expansion.
On Wed, Jan 17, 2024 at 10:37 PM Jeff Law wrote:
On 1/17/24 05:14, Richard Biener wrote:
> On Wed, 17 Jan 2024, Monk Chiang wrot
On Tue, Jan 16, 2024 at 11:44 PM Richard Biener
wrote:
> > On Tue, Jan 16, 2024 at 11:20 PM Greg McGary wrote:
> > >
> > > The sign bit of a sign-extending load cannot be known until runtime,
> > > so don't attempt to simplify it in the combiner.
> >
> It feels like this papers over an issue
On Wed, Jan 10, 2024 at 12:47 AM H.J. Lu wrote:
>
> When -fsanitize=hwaddress is used, libhwasan will try to enable LAM_U57
> in the startup code. Update the target check to enable hwaddress tests
> if LAM_U57 is enabled. Also compile hwaddress tests with -mlam=u57 on
> x86-64 since hwasan requi
On 1/17/24 20:17, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
In grokdeclarator/cdk_function the comment says that the find_xobj_parm
lambda clears TREE_PURPOSE so that we can correctly detect an xobj that
is not the first parameter. That's
Hi,
As PR101169 comment #c4 shows, previously the addi count
update on fold-vec-extract-char.p7.c covered a sub-optimal
code gen issue. On trunk, pass fold-mem-offsets helps to
recover the best code sequence, so this patch is to
revert the count back to the original which matches the
optimal addi
Hi David,
on 2024/1/18 09:27, David Edelsohn wrote:
> If the fixes remove the failures on AIX, then the patch to disable the tests
> also can be reverted.
>
Since I didn't find strub-unsupported*.c failed on ppc64 linux, to ensure it's
related, I reverted your commit r14-6838 and my fix r14-708
When -fcf-protection=branch is used, with the current -mno-cet-switch
default, a NOTRACK indirect jump is generated for jump tables, which can
target a non-ENDBR instruction. However, the overwhelming opinion is to
avoid NOTRACK (PR104816) to improve safety. Projects such as Linux
kernel and Xen
gcc.dg/tree-ssa/scev-16.c is OK to move
gcc.dg/pr104992.c should simply add -fno-tree-vectorize to the used
options and remove the vect_* stuff
Hi Richard:
I have a question. I don't understand the purpose of adding
'-fno-tree-vectorize' here.
Thanks!
On Wed, 17 Jan 2024, 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
gcc/testsuite/ChangeLog:
* gcc.dg/vect/bb-slp-subgroups-3.c: Add !vect128.
---
gcc/testsuite/gcc.dg/vect/bb-slp-subgroups-3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-subgroups-3.c
b/gcc/testsuite/gcc.dg/vect/bb-slp-subgroups-3
On Thu, Jan 18, 2024 at 1:58 AM Gaius Mulley wrote:
>
>
> ok for master ?
>
> Bootstrapped on power8 (cfarm135), power9 (cfarm120) and
> x86_64-linux-gnu.
OK.
I wonder what this does to the libm2 ABI?
> ---
>
> This patch corrects commit
> r14-4149-g81d5ca0b9b8431f1bd7a5ec8a2c94f04bb0cf032 whic
1 - 100 of 119 matches
Mail list logo
