On Thu, Jan 18, 2024 at 08:40:04AM +0100, Richard Biener wrote:
> > This test FAILs on i686-linux or e.g. sparc*-solaris*, because
> > it uses vect_int effective target outside of */vect/ testsuite.
> > That is wrong, vect_int assumes the extra added flags by vect.exp
> > by default, which aren't
On Thu, 18 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> This test FAILs on i686-linux or e.g. sparc*-solaris*, because
> it uses vect_int effective target outside of */vect/ testsuite.
> That is wrong, vect_int assumes the extra added flags by vect.exp
> by default, which aren't added in other
On Thu, 2024-01-18 at 15:15 +0800, chenglulu wrote:
> > 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
>
On Thu, 18 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> From what I can see, this test has been written for a backend fix and
> assumes the loop isn't vectorized (at least, it wasn't when the test was
> added, it contains an early exit), but that is no longer true and because
> of the vectorization
Hi!
This test FAILs on i686-linux or e.g. sparc*-solaris*, because
it uses vect_int effective target outside of */vect/ testsuite.
That is wrong, vect_int assumes the extra added flags by vect.exp
by default, which aren't added in other testsuites.
The following patch fixes that by moving the
On Wed, Jan 17, 2024 at 11:28 PM Matthias Kretz wrote:
>
> On Thursday, 4 January 2024 10:10:12 CET Andrew Pinski wrote:
> > I really doubt this would work in the end. Because HW which is 128bits
> > only, can't support -msve-vector-bits=2048 . I am thinking
> > std::experimental::simd is not the
Hi!
>From what I can see, this test has been written for a backend fix and
assumes the loop isn't vectorized (at least, it wasn't when the test was
added, it contains an early exit), but that is no longer true and because
of the vectorization it now contains an instruction which the test scans
On Thu, 18 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> While the option was originally meant to be a Target option for a single
> target, it is an option for all targets, so should be Common rather than
> Target, and because it is an optimization option which could be different
> in between
The following fixes wrong virtual operands being used for peeled
early breaks where we can have different live ones and for multiple
exits it makes sure to update the correct PHI arguments.
I've introduced SET_PHI_ARG_DEF_ON_EDGE so we can avoid using
a wrong edge to compute the PHI arg index
Hi!
While the option was originally meant to be a Target option for a single
target, it is an option for all targets, so should be Common rather than
Target, and because it is an optimization option which could be different
in between different LTO TUs, I've added Optimization keyword too.
>From
The vectorizer dependence analysis is confused with invariant loads
when figuring whether the circumstances are so that we preserve
scalar stmt execution order. The following rectifies this.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/113431
On Thu, 18 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> On aarch64 the backend decides to use non-BLKmode for some arrays
> like unsigned long[4] - OImode in that case, but the corresponding
> BITINT_TYPEs have BLKmode (like structures containing that many limb
> elements). This both isn't a good
Hi!
x86_function_profiler emits assembly directly into file and only emits
AT syntax. The following patch adjusts it to emit MASM syntax
if -masm=intel.
As it doesn't use asm_fprintf, I can't use {|} syntax for the dialects.
I've tested using
for i in -mcmodel=large "-mcmodel=large -fpic" ""
Pushed to r14-8204.
在 2024/1/13 下午3:28, chenxiaolong 写道:
1.Added dg-do compile on LoongArch.
When binutils does not support vector instruction sets, an error occurs
because the assembler does not recognize vector instructions.
2.Added "-mlsx" option for vectorization on LoongArch.
On Sunday, 10 December 2023 14:29:45 CET Richard Sandiford wrote:
> Thanks for the patch and sorry for the slow review.
Sorry for my slow reaction. I needed a long vacation. For now I'll focus on
the design question wrt. multi-arch compilation.
> I can only comment on the usage of SVE, rather
On Thursday, 4 January 2024 10:10:12 CET Andrew Pinski wrote:
> I really doubt this would work in the end. Because HW which is 128bits
> only, can't support -msve-vector-bits=2048 . I am thinking
> std::experimental::simd is not the right way of supporting this.
> Really the route the standard
On Thu, 18 Jan 2024, Juzhe-Zhong wrote:
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/vect/bb-slp-subgroups-3.c: Add !vect128.
OK
> ---
> gcc/testsuite/gcc.dg/vect/bb-slp-subgroups-3.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
Hi!
On aarch64 the backend decides to use non-BLKmode for some arrays
like unsigned long[4] - OImode in that case, but the corresponding
BITINT_TYPEs have BLKmode (like structures containing that many limb
elements). This both isn't a good idea (we really want such underlying vars
to live in
Pushed to r14-8203.
在 2024/1/13 下午2:37, Lulu Cheng 写道:
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_split_symbol):
Assign the '/u' attribute to the mem.
gcc/testsuite/ChangeLog:
* g++.target/loongarch/got-load.C: New test.
---
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
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
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
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!
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
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
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
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
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
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
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
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,
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.
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):
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
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
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
vsetivli
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
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
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
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
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
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
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
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:
*
> -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
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
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
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.
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
> 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
> > > >
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.
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 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
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;
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
> 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
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 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 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
... 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 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:
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
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
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.
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
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 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
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
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
OK.
Regards
Robin
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
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
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
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
>
>
> 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
On Wed, 17 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled because the bitint lowering emits a
> .MULBITINT (, 1024, , 1024, , 1024);
> call. The bug is in the overlap between the destination and source, that is
> something the libgcc routines don't handle, they
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 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,
>
> 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,
> >
> > +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
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
>
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
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
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
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,
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
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 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
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
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
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.
---
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
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
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
*
> -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
* 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
Hi!
The following testcase is miscompiled because the bitint lowering emits a
.MULBITINT (, 1024, , 1024, , 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 algorithms
在 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
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.
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
1 - 100 of 119 matches
Mail list logo
