From: Pan Li
The phiopt2 pass will also try the gimple_simplify for the form 5
of unsigned integer SAT_ADD. Thus add the testcase to make sure
it will be performed in phiopt2 pass.
gcc/testsuite/ChangeLog:
* gcc.dg/sat_arith_simplify.h: Add test helper macros.
* gcc.dg/sat_u_ad
From: Pan Li
The phiopt2 pass will also try the gimple_simplify for the form 8
of unsigned integer SAT_ADD. Thus add the testcase to make sure
it will be performed in phiopt2 pass.
gcc/testsuite/ChangeLog:
* gcc.dg/sat_arith_simplify.h: Add test helper macros.
* gcc.dg/sat_u_ad
From: Pan Li
The phiopt2 pass will also try the gimple_simplify for the form 6
of unsigned integer SAT_ADD. Thus add the testcase to make sure
it will be performed in phiopt2 pass.
gcc/testsuite/ChangeLog:
* gcc.dg/sat_arith_simplify.h: Add test helper macros.
* gcc.dg/sat_u_ad
Hello,
This patch adds initial support for FUJITSU-MONAKA CPU, which we are developing.
This is the slides for the CPU:
https://www.fujitsu.com/downloads/SUPER/topics/isc24/next-arm-based-processor-fujitsu-monaka-and-its-software-ecosystem.pdf
Bootstrapped/regtested on aarch64-unknown-linux-gnu.
From: Pan Li
As suggested by Richard, move the SAT_ADD simplify testcases from
the tree-ssa to gcc.dg.
gcc/testsuite/ChangeLog:
* gcc.dg/sat_arith_simplify.h: Add test macros.
* gcc.dg/tree-ssa/sat_u_add-simplify-1-u16.c: Move to...
* gcc.dg/sat_u_add-simplify-1-u16.c: .
From: Pan Li
The phiopt2 pass will also try the gimple_simplify for the form 7
of unsigned integer SAT_ADD. Thus add the testcase to make sure
it will be performed in phiopt2 pass.
gcc/testsuite/ChangeLog:
* gcc.dg/sat_arith_simplify.h: Add test helper macros.
* gcc.dg/sat_u_ad
From: Pan Li
There are sorts of forms for the unsigned SAT_ADD. Some of them are
complicated while others are cheap. This patch would like to simplify
the complicated form into the cheap ones. For example as below:
>From the form 8 (branch):
SAT_U_ADD = x > (T)(x + y) ? -1 : (x + y).
To (b
From: Pan Li
Sorts of comments of unsigned integer SAT_ADD matching is not updated
to date. This patch would like to refine it.
The below test suites are passed for this patch:
1. The rv64gcv fully regression tests.
2. The x86 bootstrap tests.
3. The x86 fully regression tests.
gcc/ChangeLog:
From: Pan Li
There are sorts of forms for the unsigned SAT_ADD. Some of them are
complicated while others are cheap. This patch would like to simplify
the complicated form into the cheap ones. For example as below:
>From the form 7 (branch):
SAT_U_ADD = x <= (T)(x + y) ? (x + y) : -1.
To (
From: Pan Li
In previous, we extract matching usadd_left_part_1 to avoid duplication.
After we simplify some usadd patterns into cheap form, there will be
only one reference to this matching. Thus, remove this matching pattern
and unfold it to the reference place.
The below test suites are pass
From: Pan Li
There are sorts of forms for the unsigned SAT_ADD. Some of them are
complicated while others are cheap. This patch would like to simplify
the complicated form into the cheap ones. For example as below:
>From the form 4 (branch):
SAT_U_ADD = (X + Y) < x ? -1 : (X + Y).
To (bran
Currently, the RISC-V target uses the target specific mplt option to
control PLT generation. This patch deprecates the target specific mplt
option and uses the common fplt option instead. This allows users to
use the same option for most targets. Since both fplt and mplt are
initialized to 1, it's
This was fixed by r12-8835-ge8d5f3a1b5a583 which surely made it latent
but richi points out it was likely an instance of PR90348. -fstack-reuse
continues to be a menace, so let's add the testcase.
gcc/testsuite/ChangeLog:
PR middle-end/90348
PR tree-optimization/106073
* g
On 10/20/24 1:40 PM, Vineet Gupta wrote:
Background
--
sched1 runs a preliminary "model schedular" ahead of the main list schedular.
Its sole purpose is to keep register pressure to mimimum [1] and it uses DFA
register depenendency tracking to arrange insns.
[1] https://gcc.gnu.or
On Linux/x86_64,
acba8b3d8dec0124c8b3a7e112b3a784a5091214 is the first bad commit
commit acba8b3d8dec0124c8b3a7e112b3a784a5091214
Author: Kugan Vivekanandarajah
Date: Thu Oct 31 07:23:10 2024 +1100
[PATCH] Fix SLP when ifcvt versioned loop is not vectorized
caused
FAIL: gcc.dg/vect/bb-sl
Fix quoting issues, escaping, and dg directive types.
There were two issues here:
1) The incorrect quoting in an earlier dg-message was covering up that the
syntax in the next part was wrong;
2) Fix dg-warning -> dg-message to correctly pick up the notes. Once 1) was
fixed, this was exposed.
With
So this patch is a very conservative approach to eliminate more vsetvl
instructions.
As we know, scheduling can scramble the instruction stream based on a
variety of factors and can easily result in an instruction sequence
where we ping-pong between different vector configurations, thus
resul
On Thu, Jul 4, 2024 at 11:00 AM Hongtao Liu wrote:
>
> On Tue, Jul 2, 2024 at 11:24 AM Hongyu Wang wrote:
> >
> > Hi,
> >
> > According to APX spec, the pushp/popp pairs should be matched,
> > otherwise the PPX hint cannot take effect and cause performance loss.
> >
> > In the ix86_expand_epilogu
On 10/30/24 14:13, Jeff Law wrote:
> On 10/29/24 6:11 PM, Vineet Gupta wrote:
>> When bisecting for ICE in PR/117353, commit 771256bcb9dd ("RISC-V: Emit
>> costs for
>> bool and stepped const vectors") uncovered yet another latent issue (first
>> noted [1])
>>
>>[1] https://github.com/patrick
On Wed, Oct 30, 2024 at 09:58:56PM +, Jonathan Wakely wrote:
> I suppose the "not implicitly convertible to an integer" rule for
> scoped enums is just a language constraint, the compiler sees scoped
> enumerations like any other integral value.
Sure. This is used in the middle-end and for it
You see, Jerry, it's the tmp4 that might have been or, perhaps, was and is
no more :-) The comment will be changed.
Thanks for the review.
Paul
On Wed, 30 Oct 2024 at 17:01, Jerry D wrote:
> On 10/30/24 9:58 AM, Steve Kargl wrote:
> > On Wed, Oct 30, 2024 at 04:41:40PM +, Paul Richard Tho
These comments were copied from the std::vector tests, but the
value_type is not bool in these ones.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/vector/cons/from_range.cc: Fix copy &
paste error in comment.
* testsuite/23_containers/vector/modifiers/append_range.cc:
Hi Jason,
On 22 Oct 2024, at 17:07, Jason Merrill wrote:
> On 10/17/24 10:30 AM, Simon Martin wrote:
>> Hi,
>>
>> The issue reported in PR117129 is pretty similar to the one in
>> PR117099,
>>
>> so here’s an updated version of the patch that fixes both issues,
>> by
>> ensuring that finish_ret
Hi Mikael,
Am 30.10.24 um 11:23 schrieb Mikael Morin:
*PING*
The first series of patches was pushed, the second (and last) one [1][2]
is awaiting review.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665360.html
[2] https://gcc.gnu.org/pipermail/fortran/2024-October/061180.html
On Wed, 30 Oct 2024 at 21:54, Jakub Jelinek wrote:
>
> On Wed, Oct 30, 2024 at 09:24:05PM +, Jonathan Wakely wrote:
> > The aligned versions of operator new should use the align_alloc
> > attribute to help the compiler.
> >
> > PR c++/86878 requests that the compiler would use the attribute to
On Wed, Oct 30, 2024 at 09:24:05PM +, Jonathan Wakely wrote:
> The aligned versions of operator new should use the align_alloc
> attribute to help the compiler.
>
> PR c++/86878 requests that the compiler would use the attribute to warn
> about invalid attributes, so an XFAILed test is added f
On Wed, 30 Oct 2024 at 21:26, Jonathan Wakely wrote:
>
> The aligned versions of operator new should use the align_alloc
> attribute to help the compiler.
>
> PR c++/86878 requests that the compiler would use the attribute to warn
> about invalid attributes, so an XFAILed test is added for that.
>
The aligned versions of operator new should use the align_alloc
attribute to help the compiler.
PR c++/86878 requests that the compiler would use the attribute to warn
about invalid attributes, so an XFAILed test is added for that.
libstdc++-v3/ChangeLog:
* libsupc++/new (operator new):
This is another piece of P1206R7, adding new members to std::list and
std::forward_list.
libstdc++-v3/ChangeLog:
PR libstdc++/111055
* include/bits/forward_list.h
(forward_list(from_range, R&&, const Alloc&), assign_range)
(prepend_range, insert_range_after): Defin
Also remove some redundant 'void' parameters from code examples.
libstdc++-v3/ChangeLog:
* doc/xml/manual/using_exceptions.xml: Fix typos and grammatical
errors.
* doc/html/manual/using_exceptions.html: Regenerate.
---
Pushed to trunk.
libstdc++-v3/doc/html/manual/using_
On 10/29/24 6:11 PM, Vineet Gupta wrote:
When bisecting for ICE in PR/117353, commit 771256bcb9dd ("RISC-V: Emit costs
for
bool and stepped const vectors") uncovered yet another latent issue (first
noted [1])
[1] https://github.com/patrick-rivos/gcc-postcommit-ci/issues/1625
This patch
On 10/30/24 11:21 AM, Craig Blackmore wrote:
Consider that a short term problem, at least for glibc. I've got the
magic ifunc bits which introduce vector versions and also check for
fast unaligned support. Does that change the calculus in your mind?
Yes, with those bits in place it wo
On Wed, Oct 30, 2024 at 09:01:36AM -0400, Patrick Palka wrote:
> On Tue, 29 Oct 2024, Marek Polacek wrote:
> > +/* Substitute ARGS into T, which is a pack index (i.e., PACK_INDEX_TYPE or
> > + PACK_INDEX_EXPR). Returns a single type or expression, a PACK_INDEX_*
> > + node if only a partial su
Hi, David,
> On Oct 30, 2024, at 14:54, David Malcolm wrote:
>
> On Wed, 2024-10-30 at 15:53 +, Qing Zhao wrote:
>>
>>
>>> On Oct 30, 2024, at 10:48, David Malcolm
>>> wrote:
>>>
>>> On Wed, 2024-10-30 at 14:34 +, Sam James wrote:
Qing Zhao writes:
> Control this with
On 10/20/24 1:40 PM, Vineet Gupta wrote:
This is just a testing hack in case someone runs into infinite loops
with model schedule change. I did run into quite a few during the course
of development and instead of sched trace files eating up the disk,
better to ICE and abort.
gcc/ChangeLog:
On 10/20/24 1:40 PM, Vineet Gupta wrote:
This inhibits sched1 aggressive spilling on RISC-V (see prev commit for
details of what the hook does).
On RISC-V (BPI-F3) we see good results.
(Build: -Ofast -march=rv64gcv_zba_zbb_zbs)
Before:
--
Performance counter stats for './cactusB
I've backported the following patches from trunk to releases/gcc-14
testsuite, jit: fix test-error-pr63969-missing-driver.c
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665552.html
Trunk: r15-4360-gf8dcb559e615db.
GCC 14: r14-10854-g771873f0a95162
jit: reset state in varasm.cc [PR11
David Malcolm writes:
> On Wed, 2024-10-30 at 17:33 +, Sam James wrote:
>> Qing Zhao writes:
>>
>> > > On Oct 30, 2024, at 10:48, David Malcolm
>> > > wrote:
>> > >
>> > > On Wed, 2024-10-30 at 14:34 +, Sam James wrote:
>> > > > Qing Zhao writes:
>> > > >
>> > > > > Control this wit
Hi, Andi
> On Oct 30, 2024, at 12:15, Andi Kleen wrote:
>
> Qing Zhao writes:
>
>> Control this with a new option -fdiagnostics-details.
>
> It would be useful to be also able to print the inline call stack,
> maybe with a separate option.
Thank you for the suggestion.
Yes, inline call stac
> On Oct 30, 2024, at 13:48, Sam James wrote:
>
> Qing Zhao writes:
>
>> Control this with a new option -fdiagnostics-details.
>>
>> $ cat t.c
>> extern void warn(void);
>> static inline void assign(int val, int *regs, int *index)
>> {
>> if (*index >= 4)
>>warn();
>> *regs = val;
>> }
> On Oct 30, 2024, at 13:38, Sam James wrote:
>
>
> Absolutely. Both in terms of improving safety as the whole point of
> these warnings is, but also stopping users from being panicked. They
> sometimes believe the warnings imply miscompilation because they can't
> understand how they would ha
Thanks, Sam.
Yes, the changes you made are exactly what I made in my local area for the
rebase.
All the new testing cases passed.
I am doing the complete regression test on X86 and also bootstrap on aarch64
right now.
Qing
> On Oct 30, 2024, at 13:33, Sam James wrote:
>
> Qing Zhao writes:
This wrinkle to PR115700 came about because the associate-name string
length was not being initialized, when an array selector had a substring
reference with non-constant start or end. This, of course, caused
subsequent references to fail.
The ChangeLog provides an adequate explanation of the atta
On Wed, Oct 23, 2024 at 02:56:51PM +0200, Richard Biener wrote:
> On Wed, Oct 9, 2024 at 6:18 PM Andi Kleen wrote:
> >
> > From: Andi Kleen
> >
> > Retrieving sys/user time in timevars is quite expensive because it
> > always needs a system call. Only getting the wall time is much
> > cheaper bec
On Wed, 2024-10-30 at 17:33 +, Sam James wrote:
> Qing Zhao writes:
>
> > > On Oct 30, 2024, at 10:48, David Malcolm
> > > wrote:
> > >
> > > On Wed, 2024-10-30 at 14:34 +, Sam James wrote:
> > > > Qing Zhao writes:
> > > >
> > > > > Control this with a new option -fdiagnostics-detail
On Wed, 2024-10-30 at 15:53 +, Qing Zhao wrote:
>
>
> > On Oct 30, 2024, at 10:48, David Malcolm
> > wrote:
> >
> > On Wed, 2024-10-30 at 14:34 +, Sam James wrote:
> > > Qing Zhao writes:
> > >
> > > > Control this with a new option -fdiagnostics-details.
> > > >
[...]
>
> I have
Since C23 support is substantially feature-complete, update
documentation to no longer refer to it as experimental and incomplete.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
gcc/
* doc/cpp.texi (__STDC_VERSION__): Do not refer to C23 support as
experimental.
After the previous patch, we can now accurately model the ISA
requirements for the SVE FAMINMAX intrinsics. They can be used
in non-streaming mode if TARGET_SVE2 and in streaming mode if
TARGET_SME2 (with both cases also requiring TARGET_FAMINMAX).
They can be used in streaming-compatible mode if
The btf_decl_tag and btf_type_tag attributes provide a means to annotate
declarations and types respectively with arbitrary user provided
strings. These strings are recorded in debug information for
post-compilation uses, and despite the name they are meant to be
recorded in DWARF as well as BTF.
For some upcoming extensions, we need to add intrinsics whose
ISA requirements differ between streaming mode and non-streaming mode.
This patch tries to generalise the infrastructure to support that:
- Rather than have a single set of feature flags, the patch uses a
separate set for sm_off (non-
It's more convenient for later patches if we only define ENTRY_VHSDF
once, in the .def file. Then the only macro that needs to be defined
before including the file is ENTRY itself.
The patch also moves the architecture requirements out of the
individual ENTRY invocations into a block-level defini
Currently we represent architecture requirements using a single bitmask
of features. However, some of the new extensions have different
requirements in non-streaming mode compared to stremaing mode.
This series adds support for that and applies it to FAMINMAX.
Tested on aarch64-linux-gnu. Since
This patch series adds support for the btf_decl_tag and btf_type_tag attributes
to GCC. This entails:
- Two new C-family attributes that allow to associate (to "tag") particular
declarations and types with arbitrary strings. As explained below, this is
intended to be used to, for example, char
Hi Richard,
Apologies as I replied w/o looking for another update on the thread first.
On 10/30/24 11:35, Richard Sandiford wrote:
I'm not saying that the algorithm gets the decision right for cactu
when tuning for in-order CPU X and running on that same CPU X.
But it seems like th
Vineet Gupta writes:
> On 10/30/24 10:25, Jeff Law wrote:
>> On 10/30/24 9:31 AM, Richard Sandiford wrote:
>>> That might need some finessing of the name. But I think the concept
>>> is right. I'd rather base the hook (or param) on a general concept
>>> like that rather than a specific "wide vs
On Tue, Oct 29, 2024 at 2:04 PM Samuel Thibault
wrote:
>
> * libgo/go/syscall/syscall_funcs.go: Do not build on GNU/Hurd.
> * libgo/go/syscall/syscall_funcs_stubs.go: Build on GNU/Hurd.
> * libgo/runtime/go-nosys.c: Do not produce syscall() stub on
> GNU/Hurd.
>
T
Support the btf_decl_tag and btf_type_tag attributes in BTF by creating
and emitting BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG records,
respectively, for them.
Some care is required when -gprune-btf is in effect to avoid emitting
decl or type tags for declarations or types which have been pruned and
Translate DW_TAG_GNU_annotation DIEs created for C attributes
btf_decl_tag and btf_type_tag into an in-memory representation in the
CTF/BTF container. They will be output in BTF as BTF_KIND_DECL_TAG and
BTF_KIND_TYPE_TAG records.
The new CTF kinds used to represent these annotations, CTF_K_DECL_T
gcc/
* doc/extend.texi (Common Variable Attributes): Document new
btf_decl_tag attribute.
(Common Type Attributes): Document new btf_type_tag attribute.
---
gcc/doc/extend.texi | 68 +
1 file changed, 68 insertions(+)
diff --git
Add two new c-family attributes, "btf_decl_tag" and "btf_type_tag" along
with a simple shared handler for them.
gcc/c-family/
* c-attribs.cc (c_common_attribute_table): Add btf_decl_tag and
btf_type_tag attributes.
(handle_btf_tag_attribute): New handler for both new attri
On 10/30/24 10:25, Jeff Law wrote:
> On 10/30/24 9:31 AM, Richard Sandiford wrote:
>> That might need some finessing of the name. But I think the concept
>> is right. I'd rather base the hook (or param) on a general concept
>> like that rather than a specific "wide vs narrow" thing.
> Agreed. Na
Qing Zhao writes:
> gcc/ChangeLog:
>
> * diagnostic-move-history.cc (dump_move_history): New routine.
> (dump_move_history_for): Likewise.
> (debug_mv_h): Likewise.
> * diagnostic-move-history.h (dump_move_history): New prototype.
> (dump_move_history_for): Likewise.
Jeff Law writes:
> On 10/30/24 9:31 AM, Richard Sandiford wrote:
>
>>
>> OK (and yeah, I can sympathise). But I think there's an argument that,
>> if you're scheduling for one in-order core using the pipeline of an
>> unrelated core, that's effectively scheduling for the core as though
>> it wer
> Could you just try the below change?
They work, including them in v3.
--
Regards
Robin
Qing Zhao writes:
> Control this with a new option -fdiagnostics-details.
>
> $ cat t.c
> extern void warn(void);
> static inline void assign(int val, int *regs, int *index)
> {
> if (*index >= 4)
> warn();
> *regs = val;
> }
> struct nums {int vals[4];};
>
> void sparx5_set (int *ptr, st
Before the patch, the included testcase fails with:
declare-variant-9.C:4:29: error: could not find variant declaration
4 | #pragma omp declare variant(variant_fn) match(user={condition(1)})
| ^~
Comments, remarks, suggestions before I commit it?
To
The function body checks for f3 only ran with -mcmodel explicitly set
which meant I missed a regression in my local testing of:
commit b039d06c9a810a3fab4c5eb9d50b0c7aff94b2d8
Author: Craig Blackmore
Date: Fri Oct 18 09:17:21 2024 -0600
[PATCH 3/7] RISC-V: Fix vector memcpy smaller
Qing Zhao writes:
> Hi,
>
> This is the 3rd version of the patch for fixing PR109071.
>
> Thanks a lot for San James's help to test the previous 2nd version of
> the patch on a lot of packages in the wild and provide detailed analysis
> and filed new bugs. (PR117179, PR117180, etc).
Thank you Q
On 30/10/2024 15:08, Tobias Burnus wrote:
I still need to look at 4/7 (C++) and 5/7 (tests for C and C++) [either
before after you posted the new version].
I sent a revised C++ patch a few moments ago.
* * *
However, this 3/7 patch LGTM 🙂
One comment: For the < C23 testcase, can you add, e.
Qing Zhao writes:
>> On Oct 30, 2024, at 10:48, David Malcolm wrote:
>>
>> On Wed, 2024-10-30 at 14:34 +, Sam James wrote:
>>> Qing Zhao writes:
>>>
Control this with a new option -fdiagnostics-details.
[...]
>>>
>>> The patch doesn't apply for me on very latest trunk --
On 10/30/24 9:31 AM, Richard Sandiford wrote:
OK (and yeah, I can sympathise). But I think there's an argument that,
if you're scheduling for one in-order core using the pipeline of an
unrelated core, that's effectively scheduling for the core as though
it were out-of-order. In other words
On 29/10/2024 15:09, Jeff Law wrote:
On 10/29/24 7:59 AM, Craig Blackmore wrote:
On 19/10/2024 14:05, Jeff Law wrote:
On 10/18/24 7:12 AM, Craig Blackmore wrote:
`expand_vec_setmem` only generated vectorized memset if it fitted
into a
single vector store. Extend it to generate a loop
On 10/30/24 9:58 AM, Steve Kargl wrote:
On Wed, Oct 30, 2024 at 04:41:40PM +, Paul Richard Thomas wrote:
This wrinkle to PR115700 came about because the associate-name string
length was not being initialized, when an array selector had a substring
reference with non-constant start or end. Th
On Wed, Oct 30, 2024 at 04:41:40PM +, Paul Richard Thomas wrote:
> This wrinkle to PR115700 came about because the associate-name string
> length was not being initialized, when an array selector had a substring
> reference with non-constant start or end. This, of course, caused
> subsequent re
The ACLE defines a new set of fp8 vector types and intrinsics that operate on
these, some of them operating on the vectors as if they were bags of bits and
some requiring an additional argument of type fpm_t.
The following two patches introduce:
- the types
- intrinsics that operate without the f
Some intrinsics require setting the fpm register before calling the
specific asm opcode required.
In order to simplify review, this patch:
- adds the fpm_mode_index attribute to function_group_info and
function_instance objects
- updates existing initialisations and call sites.
- updates equalit
On Wed, Oct 30, 2024 at 1:56 AM Andrew Pinski wrote:
>
> After r13-707-g68e0063397ba82, COND_EXPR for gimple assign no longer could
> contain a comparison.
> The vectorizer was builting gimple assigns with comparison until
> r15-4695-gd17e672ce82e69
> (which added an assert to make sure it no lo
Qing Zhao writes:
> Control this with a new option -fdiagnostics-details.
It would be useful to be also able to print the inline call stack,
maybe with a separate option.
In some array bounds cases I looked at the problem was hidden in some inlines
and it wasn't trivial to figure it out.
I wro
[ Resending since this was somehow sent in HMTL mode and was scrubbed ]
On 30 Oct 2024, at 17:16, Simon Martin wrote:
> Hi,
>
> Just closing the loop on this...
>
> On 19 Oct 2024, at 11:57, Iain Sandoe wrote:
>
> On 19 Oct 2024, at 10:16, Simon Martin wrote:
>
> On 18 Oct 2024, at 10:55, Sam Ja
The current code was based on an early version of the SME spec,
which allowed the .Q forms of TRN1, TRN2, UZP1, UZP2, ZIP1, and ZIP2
to be used in streaming mode. We should now forbid them instead;
see
https://developer.arm.com/documentation/ddi0602/2024-09/SVE-Instructions/TRN1--TRN2--vectors---
Hi,
Just closing the loop on this...
On 19 Oct 2024, at 11:57, Iain Sandoe wrote:
On 19 Oct 2024, at 10:16, Simon Martin wrote:
On 18 Oct 2024, at 10:55, Sam James wrote:
Simon Martin writes:
Hi Sam,
Hi Simon,
On 16 Oct 2024, at 22:06, Sam James wrote:
Simon Martin writes:
We ICE upon
On 24/10/2024 16:10, Tobias Burnus wrote:
Hi PA;
only playing around quickly and glancing at the patch; I need to have a
real look at this later.
Paul-Antoine Arras:
This patch adds C++ support for the `dispatch` construct and the
`adjust_args`
clause. It relies on the c-family bits comprised
On 29/10/2024 12:48, Richard Biener wrote:
On Mon, Oct 28, 2024 at 4:45 PM Akram Ahmad wrote:
Case 7 of unsigned scalar saturating addition defines
SAT_ADD = X <= (X + Y) ? (X + Y) : -1. This is the same as
SAT_ADD = Y <= (X + Y) ? (X + Y) : -1 due to usadd_left_part_1
being commutative.
The p
> On Oct 30, 2024, at 10:48, David Malcolm wrote:
>
> On Wed, 2024-10-30 at 14:34 +, Sam James wrote:
>> Qing Zhao writes:
>>
>>> Control this with a new option -fdiagnostics-details.
>>>
>>> [...]
>>
>> The patch doesn't apply for me on very latest trunk -- I think
>> David's
>> recent
Hi,
This is a backport of the PR116783 fix to GCC 14. It was pre-approved here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665097.html
The only intended non-contextual difference w.r.t. the patch on trunk is
that the test no longer needs -fno-late-combine-instructions on the 14
branc
Jeff Law writes:
> On 10/30/24 8:44 AM, Richard Sandiford wrote:
>
>>> But the data from the BPI (spacemit k1 chip) is an in-order core.
>>> Granted we don't have a good model of its pipeline, but it's definitely
>>> in-order.
>>
>> Damn :) (I did try to clarify what was being tested earlier, bu
> On Oct 30, 2024, at 10:34, Sam James wrote:
>
> Qing Zhao writes:
>
>> Control this with a new option -fdiagnostics-details.
>>
>> [...]
>
> The patch doesn't apply for me on very latest trunk -- I think David's
> recent diag refactoring means it needs a slight rebase. Could you send
> th
> On Oct 30, 2024, at 19:59, Richard Sandiford
> wrote:
>
> Yangyu Chen writes:
>> We forgot to apply DECL_EXTERNAL to __init_cpu_features_resolver decl. When
>> building with LTO, the linker cannot find the
>> __init_cpu_features_resolver.lto_priv* symbol, causing the link error.
>>
>> Thi
On Fri, Oct 25, 2024 at 4:39 PM Alexandre Oliva wrote:
>
>
> In preparation to changes that may modify both inner and outer
> conditions in ifcombine, drop the redundant parameter result_inv, that
> is always identical to inner_inv.
OK.
>
> for gcc/ChangeLog
>
> * tree-ssa-ifcombine.cc
On 10/30/24 8:44 AM, Richard Sandiford wrote:
But the data from the BPI (spacemit k1 chip) is an in-order core.
Granted we don't have a good model of its pipeline, but it's definitely
in-order.
Damn :) (I did try to clarify what was being tested earlier, but the
response wasn't clear.)
So
The inline function wraps the vector_cost class API and no longer is
a good representation of the query style of that class which makes it
also difficult to extend.
Boostrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vectorizer.h (finish_cost): Inline everywhere and remove.
Evgeny Karpov writes:
> Tuesday, October 29, 2024
> Richard Sandiford wrote:
>
>> Hmm, I see. I think this is surprising enough that it would be worth
>> a comment. How about:
>>
>> /* Since the assembly directive only specifies a size, and not an
>> alignment, we need to follow the defaul
Jeff Law writes:
> On 10/30/24 4:05 AM, Richard Sandiford wrote:
>> Vineet Gupta writes:
>>> On 10/29/24 11:51, Wilco Dijkstra wrote:
Hi Vineet,
> I agree the NARROW/WIDE stuff is obfuscating things in technicalities.
Is there evidence this change would make things significantly wor
On Wed, 2024-10-30 at 14:34 +, Sam James wrote:
> Qing Zhao writes:
>
> > Control this with a new option -fdiagnostics-details.
> >
> > [...]
>
> The patch doesn't apply for me on very latest trunk -- I think
> David's
> recent diag refactoring means it needs a slight rebase. Could you
> se
On Fri, Oct 25, 2024 at 4:39 PM Alexandre Oliva wrote:
>
>
> Rework ifcombine to support merging conditions from noncontiguous
> blocks. This depends on earlier preparation changes.
>
> The function that attempted to ifcombine a block with its immediate
> predecessor, tree_ssa_ifcombine_bb, now l
Hi all,
This patch adds the TARGET_CREATE_FMV_DISPATCHER_AT_DEFAULT_IMPL hook
which changes FMV behavior for target_version functions to match the Arm
C Language Extension.
The functional differences consist of:
1. Generating the resolver for the dispatched symbol at the site of the
default ve
> Symbols in the object file also look good.
>
> 015 SECT2 notype External | large_aligned_array
> 016 0010 SECT2 notype External | large_aligned_array2
> 017 0020 SECT2 notype External | large_aligned_array3
> 018 0040 SECT2 notype Exte
Yangyu Chen writes:
> We forgot to apply DECL_EXTERNAL to __init_cpu_features_resolver decl. When
> building with LTO, the linker cannot find the
> __init_cpu_features_resolver.lto_priv* symbol, causing the link error.
>
> This patch gets this fixed by adding DECL_EXTERNAL to the decl. To avoid us
Qing Zhao writes:
> Control this with a new option -fdiagnostics-details.
>
> [...]
The patch doesn't apply for me on very latest trunk -- I think David's
recent diag refactoring means it needs a slight rebase. Could you send
that?
gcc/ChangeLog:
* diagnostic-move-history.cc (dump_move_history): New routine.
(dump_move_history_for): Likewise.
(debug_mv_h): Likewise.
* diagnostic-move-history.h (dump_move_history): New prototype.
(dump_move_history_for): Likewise.
* gimple-ssa-i
1 - 100 of 145 matches
Mail list logo
