On Thu, Jun 6, 2024 at 2:39 PM Hongyu Wang wrote:
>
> Current target apxf check does not specify sub-features that assembler
> supports, so the check with older binutils will fail at assemble stage
> for new apx features like NF,CCMP or CFCMOV. Adjust the assembler check
> for latest apx subfeatur
On Thu, 6 Jun 2024 at 07:49, Jonathan Wakely wrote:
>
> On Thu, 6 Jun 2024 at 03:37, Deev Patel wrote:
> >
> > Things like std::atomic are currently unable to be created in a
> > constexpr context with clang 18 and c++20. Example compilation error
> > ```
> > external/com_google_tcmalloc/tcmallo
On Thu, 6 Jun 2024 at 03:37, Deev Patel wrote:
>
> Things like std::atomic are currently unable to be created in a
> constexpr context with clang 18 and c++20. Example compilation error
> ```
> external/com_google_tcmalloc/tcmalloc/parameters.cc:223:17: error: variable
> does not have a constant
Current target apxf check does not specify sub-features that assembler
supports, so the check with older binutils will fail at assemble stage
for new apx features like NF,CCMP or CFCMOV. Adjust the assembler check
for latest apx subfeatures.
Bootstrapped & regtested on x86-64-pc-linux-gnu with bin
Hi!
The implementation has been committed in r15-1037.
2024-06-06 Jakub Jelinek
* libgomp.texi (OpenMP 5.1 status): Mark Loop transformation constructs
as implemented.
--- libgomp/libgomp.texi
+++ libgomp/libgomp.texi
@@ -302,7 +302,7 @@ The OpenMP 4.5 specification is fully
From: Pan Li
This patch would like to support the .SAT_SUB for the unsigned
vector int. Given we have below example code:
void
vec_sat_sub_u64 (uint64_t *out, uint64_t *x, uint64_t *y, unsigned n)
{
for (unsigned i = 0; i < n; i++)
out[i] = (x[i] - y[i]) & (-(uint64_t)(x[i] >= y[i]));
}
On Thu, 6 Jun 2024, YunQiang Su wrote:
> Richard Biener 于2024年5月28日周二 17:47写道：
> >
> > The following avoids accounting single-lane SLP to the discovery
> > limit. As the two testcases show this makes discovery fail,
> > unfortunately even not the same across targets. The following
> > should fi
Hello All:
All comments are addressed.
Common infrastructure using generic code for pair mem fusion of different
targets.
rs6000 target specific code implement virtual functions defined by generic code.
Target specific code are added in rs6000-mem-fusion.cc.
Tested for powerpc64-linux-gnu.
Th
Hi Gaius,
on 2024/6/5 22:22, Gaius Mulley wrote:
> "Kewen.Lin" writes:
>
>> Hi Joseph and Gaius,
>>
>> on 2024/6/4 02:02, Joseph Myers wrote:
>>> On Sun, 2 Jun 2024, Kewen Lin wrote:
>>>
diff --git a/gcc/m2/gm2-gcc/m2type.cc b/gcc/m2/gm2-gcc/m2type.cc
index 571923c08ef..d52cbdf0b99 100
From: YunQiang Su
In mips_insn_cost, COSTS_N_INSNS is missing when we return the cost
if count * ratio > 0.
gcc
* config/mips/mips.cc(mips_insn_cost): Add missing COSTS_N_INSNS
to count.
---
gcc/config/mips/mips.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
For power10, there're extra 3 REG_EQUIV notes with (fix:SI. to avoid
the failure. Check (fix:SI is from the pattern not NOTE.
gcc/testsuite/ChangeLog:
PR target/115365
* gcc.dg/pr100927.c: Don't scan fix:SI from the note.
---
gcc/testsuite/gcc.dg/pr100927.c | 2 +-
1 file changed
Richard Biener 于2024年5月28日周二 17:47写道：
>
> The following avoids accounting single-lane SLP to the discovery
> limit. As the two testcases show this makes discovery fail,
> unfortunately even not the same across targets. The following
> should fix two FAILs for GCN as a side-effect.
>
> Bootstrapp
On 2024-06-05 21:58 Jeff Law wrote:
>
>
>
>On 6/5/24 1:47 AM, Fei Gao wrote:
>>
>> On 2024-06-05 14:36 Kito Cheng wrote:
>>>
>>> Thanks for fixing this issue, and I am wondering doest it possible to
>>> fix that without introduce target hook? I ask that because...GCC 14
>>> also has this bug, b
YunQiang Su 于2024年5月29日周三 10:02写道：
>
> Richard Sandiford 于2024年5月29日周三 05:28写道：
> >
> > YunQiang Su writes:
> > > If `find_a_program` cannot find `as/ld/objcopy` and we are a cross
> > > toolchain,
> > > the final fallback is `as/ld` of system. In fact, we can have a try with
> > > -as/ld/objc
Hi Carl,
on 2024/6/6 06:25, Carl Love wrote:
> Kewen:
>
> On 6/3/24 23:00, Kewen.Lin wrote:
>> Hi Carl,
>>
>> on 2024/5/29 23:52, Carl Love wrote:
>>> This patch was approved in the previous series. There are no changes to
>>> this patch. Reposting for completeness.
>> I guess you can just pu
Things like std::atomic are currently unable to be created in a
constexpr context with clang 18 and c++20. Example compilation error
```
external/com_google_tcmalloc/tcmalloc/parameters.cc:223:17: error: variable
does not have a constant initializer
223 | Parameters::peak_sampling_heap_growth
Hi Hans-Peter,
on 2024/6/6 09:41, Hans-Peter Nilsson wrote:
> On Sun, 2 Jun 2024, Kewen Lin wrote:
>
>> This is to remove macros {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE
>> defines in mmix port.
>
> This is fine once prerequisites are in place.
>
> If I may add a nit: In these target change commit mess
Hi,
on 2024/6/6 09:43, HAO CHEN GUI wrote:
> Hi Kewen,
>
> 在 2024/6/5 17:00, Kewen.Lin 写道:
>> This predicate can be moved to its only use (define_insn part condition).
>> The const_vector match_code check is redundant as const_vec_duplicate_p
>> already checks that, I wonder if we really need eas
On Jun 1, 2024, Jonathan Wakely wrote:
> OK
Thanks, I've dropped adjustments for bits that got removed since last
week; here's what I'm pushing.
A proprietary embedded operating system that uses clang as its primary
compiler ships headers that require __clang__ to be defined. Defining
that m
Hi,
Gentle ping ...
Jiufu Guo writes:
> Hi,
>
> Gentle ping ...
>
> BR,
> Jeff(Jiufu) Guo
>
> Jiufu Guo writes:
>
>> Hi,
>>
>> 'rlwinm' pattern is already well used for SImode. As this instruction
>> can touch the whole 64bit register, so some constants in 64bit(DImode)
>> can be built via
Hi Kewen,
在 2024/6/5 17:00, Kewen.Lin 写道:
> This predicate can be moved to its only use (define_insn part condition).
> The const_vector match_code check is redundant as const_vec_duplicate_p
> already checks that, I wonder if we really need easy_altivec_constant?
> Even if one vector constant doe
On Sun, 2 Jun 2024, Kewen Lin wrote:
> This is to remove macros {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE
> defines in mmix port.
This is fine once prerequisites are in place.
If I may add a nit: In these target change commit messages, add
a hint as to which defaulted hook or macro the removed macro now
Hi Richard,
After revisited all the comments of the mail thread, I would like to confirm if
my understanding is correct according to the generated match code.
For now the generated code looks like below:
else if (gphi *_a1 = dyn_cast (_d1))
{
basic_block _b1 = gimple_bb (_a1);
if (gim
On Wed, Jun 5, 2024 at 10:44 PM Jeff Law wrote:
>
>
>
> On 6/4/24 10:22 PM, liuhongt wrote:
> >> Can you add a testcase for this? I don't mind if it's x86 specific and
> >> does a bit of asm scanning.
> >>
> >> Also note that the context for this patch has changed, so it won't
> >> automatically
On 6/5/24 06:01, Uros Bizjak wrote:
On Tue, Jun 4, 2024 at 10:10 PM Evgeny Karpov
wrote:
Richard and Uros, could you please review the changes for v2?
LGTM for the generic x86 part, OS-specific part (cygming) should also
be reviewed by OS port maintainer (CC'd).
Thanks,
Uros.
Where is HA
On Tue, 28 May 2024, Tobias Burnus wrote:
> Let's make https://gcc.gnu.org/gcc-15/changes.html a bit more useful …
Always a good idea. :-)
> Thus, document selected_logical_kind and the ISO_FORTRAN_ENV additions.
>
> Comments or suggestions before I commit it?
Looks good to me, thanks.
Gerald
Hi Tobias,
On Mon, 3 Jun 2024, Tobias Burnus wrote:
> Comments or fine as is?
+NVPTX
+
+
+ GCC's nvptx target now supports constructors and destructors;
I'd make this a full stop/distinct sentence and ...
+ for this, a recent version of nvptx-tools is https://gcc.gnu.org/install/specific.
Kewen:
On 6/3/24 23:00, Kewen.Lin wrote:
> Hi Carl,
>
> on 2024/5/29 23:52, Carl Love wrote:
>> This patch was approved in the previous series. There are no changes to
>> this patch. Reposting for completeness.
> I guess you can just push the approved ones, as there is no dependency
> between
On 5/30/24 14:32, David Faust wrote:
Previously it was not supported to generate both CTF and BTF debug info
in the same compiler run, as both formats made incompatible changes to
the same internal data structures.
With the structural change in the prior patches, in particular the
guarantee that
On Mon, May 6, 2024 at 4:09 PM Fangrui Song wrote:
>
> On Wed, Mar 6, 2024 at 1:54 AM Richard Earnshaw (lists)
> wrote:
> >
> > On 06/03/2024 05:07, Fangrui Song wrote:
> > > On Fri, Feb 23, 2024 at 7:33 PM Fangrui Song wrote:
> > >>
> > >> From: Fangrui Song
> > >>
> > >> Targets that are not
On 5/30/24 14:32, David Faust wrote:
This patch enables -fprune-btf by default in the BPF backend when
generating BTF information, and fixes BPF CO-RE generation when using
-fprune-btf.
When generating BPF CO-RE information, we must ensure that types used
in CO-RE relocations always have suffici
OK for trunk?
-- >8 --
This change fixes the following two errors:
Traceback (most recent call last):
File "../contrib/header-tools/gcc-order-headers", line 267, in
process_known_dups ()
File "../contrib/header-tools/gcc-order-headers", line 101, in
process_known_dups
if dups[i] an
OK for trunk?
-- >8 --
Use raw strings so that backslashes don't need to be escaped. Otherwise
the Python interpreter warns.
contrib/header-tools/ChangeLog:
* headerutils.py (is_pound_if, is_pound_endif): Use raw strings
for strings containing backslashes.
* included-by:
Pushed as obvious.
-- >8 --
contrib/header-tools/ChangeLog:
* README: Fix spelling and capitalization typos.
* gcc-order-headers: Fix spelling typo.
---
contrib/header-tools/README| 24
contrib/header-tools/gcc-order-headers | 2 +-
2 files
From: Sundeep KOKKONDA
Thanks for the patch. I've pushed it to trunk now (after discussion on
IRC). I made some small whitespace changes. There was a spurious space
in one place, saying print(fn ), and I added a space between 'print' and
the openin parenthesis, to conform for the usual GCC style
> On Jun 5, 2024, at 09:49, David Malcolm wrote:
>
> On Tue, 2024-06-04 at 22:09 +, Qing Zhao wrote:
>>
>>
>>> On Jun 4, 2024, at 17:55, David Malcolm
>>> wrote:
>>>
>>> On Fri, 2024-05-31 at 13:11 +, Qing Zhao wrote:
>
> [...]
>
Thanks a lot for the r
>>> Here's what I've retested on x86_64-linux-gnu and, slightly adjusted for
>>> gcc-13, on arm-vx7r2. Ok to install?
>>
>> OK
Thanks Jonathan!
>> If there's any chance of getting the vxworks system headers fixed to
>> work with GCC properly, that would be nice.
That would be nice for sure.
Regarding
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653417.html , are
there any …
Tobias Burnus wrote:
Comments or fine as is?
Tobias
> On Jun 5, 2024, at 13:07, Richard Biener wrote:
>
>
>
>> Am 05.06.2024 um 18:39 schrieb Qing Zhao :
>>
>>
>>
>>> On Jun 5, 2024, at 03:26, Richard Biener wrote:
>>>
On Tue, Jun 4, 2024 at 10:31 PM Qing Zhao wrote:
> On Jun 4, 2024, at 03:43, Richard Biener
This v2 patch uses std::is_constant_evaluated() so the algos don't try
to use memchr in constant expressions, and removes the
_GLIBCXX_NODISCARD I added to std::find (it should still be added, but
as a separate patch).
Tamar has asked that I don't push this until he compares the performance
to a v
This patch needs a tweak to not try to use memchr during constant
evaluation, i.e. check std::is_constant_evaluated().
On Wed, 5 Jun 2024 at 16:34, Jonathan Wakely wrote:
>
> I plan to push this after testing finishes.
>
> -- >8 --
>
> This optimizes std::find to use memchr when searching for an
> Am 05.06.2024 um 18:39 schrieb Qing Zhao :
>
>
>
>> On Jun 5, 2024, at 03:26, Richard Biener wrote:
>>
>>> On Tue, Jun 4, 2024 at 10:31 PM Qing Zhao wrote:
>>>
>>>
>>>
On Jun 4, 2024, at 03:43, Richard Biener
wrote:
On Mon, Jun 3, 2024 at 4:48 PM David Malcolm
> On Jun 5, 2024, at 03:26, Richard Biener wrote:
>
> On Tue, Jun 4, 2024 at 10:31 PM Qing Zhao wrote:
>>
>>
>>
>>> On Jun 4, 2024, at 03:43, Richard Biener wrote:
>>>
>>> On Mon, Jun 3, 2024 at 4:48 PM David Malcolm wrote:
On Mon, 2024-06-03 at 08:29 +0200, Richard Biener wro
YunQiang Su writes:
> Richard Sandiford 于2024年6月5日周三 23:20写道：
>>
>> YunQiang Su writes:
>> > Richard Sandiford 于2024年6月5日周三 22:14写道：
>> >>
>> >> YunQiang Su writes:
>> >> > PR target/113179.
>> >> >
>> >> > In `store_bit_field_using_insv`, we just use SUBREG if value_mode
>> >> >>= op_mode, wh
Hi,
This patch adds missing assembly directives to the CMSE library wrapper
to call functions with attribute cmse_nonsecure_call. Without the .type
directive the linker will fail to produce the correct veneer if a call
to this wrapper function is to far from the wrapper itself. The .size
wa
Richard Sandiford 于2024年6月5日周三 23:20写道：
>
> YunQiang Su writes:
> > Richard Sandiford 于2024年6月5日周三 22:14写道：
> >>
> >> YunQiang Su writes:
> >> > PR target/113179.
> >> >
> >> > In `store_bit_field_using_insv`, we just use SUBREG if value_mode
> >> >>= op_mode, while in some ports, a sign_extend
I plan to push this after testing finishes.
-- >8 --
This optimizes std::find to use memchr when searching for an integer in
a range of bytes.
libstdc++-v3/ChangeLog:
PR libstdc++/88545
PR libstdc++/115040
* include/bits/cpp_type_traits.h (__can_use_memchr_for_find):
On 6/5/24 8:57 AM, YunQiang Su wrote:
Richard Sandiford 于2024年6月5日周三 22:14写道：
YunQiang Su writes:
PR target/113179.
In `store_bit_field_using_insv`, we just use SUBREG if value_mode
= op_mode, while in some ports, a sign_extend will be needed,
such as MIPS64:
If either GPR rs or GPR
YunQiang Su writes:
> Richard Sandiford 于2024年6月5日周三 22:14写道：
>>
>> YunQiang Su writes:
>> > PR target/113179.
>> >
>> > In `store_bit_field_using_insv`, we just use SUBREG if value_mode
>> >>= op_mode, while in some ports, a sign_extend will be needed,
>> > such as MIPS64:
>> > If either GPR
Richard Sandiford 于2024年6月5日周三 22:14写道：
>
> YunQiang Su writes:
> > PR target/113179.
> >
> > In `store_bit_field_using_insv`, we just use SUBREG if value_mode
> >>= op_mode, while in some ports, a sign_extend will be needed,
> > such as MIPS64:
> > If either GPR rs or GPR rt does not contain s
On Fri, May 31, 2024 at 9:09 AM Richard Sandiford
wrote:
>
> Wilco Dijkstra writes:
> > Improve check-function-bodies by allowing single-character function names.
> > Also skip '#' comments which may be emitted from inline assembler.
> >
> > Passes regress, OK for commit?
> >
> > gcc/testsuite:
>
On 6/4/24 10:22 PM, liuhongt wrote:
Can you add a testcase for this? I don't mind if it's x86 specific and
does a bit of asm scanning.
Also note that the context for this patch has changed, so it won't
automatically apply. So be extra careful when updating so that it goes
into the right pla
On 6/4/24 6:26 AM, Jørgen Kvalsvik wrote:
Make gcov aware which edges are the true/false to more accurately
reconstruct the CFG. There are plenty of bits left in arc_info and it
opens up for richer reporting.
gcc/ChangeLog:
* gcov-io.h (GCOV_ARC_TRUE): New.
(GCOV_ARC_FALSE):
On 6/5/24 8:14 AM, Richard Sandiford wrote:
YunQiang Su writes:
PR target/113179.
In `store_bit_field_using_insv`, we just use SUBREG if value_mode
= op_mode, while in some ports, a sign_extend will be needed,
such as MIPS64:
If either GPR rs or GPR rt does not contain sign-extended 32
"Kewen.Lin" writes:
> Hi Joseph and Gaius,
>
> on 2024/6/4 02:02, Joseph Myers wrote:
>> On Sun, 2 Jun 2024, Kewen Lin wrote:
>>
>>> diff --git a/gcc/m2/gm2-gcc/m2type.cc b/gcc/m2/gm2-gcc/m2type.cc
>>> index 571923c08ef..d52cbdf0b99 100644
>>> --- a/gcc/m2/gm2-gcc/m2type.cc
>>> +++ b/gcc/m2/gm2-
YunQiang Su writes:
> PR target/113179.
>
> In `store_bit_field_using_insv`, we just use SUBREG if value_mode
>>= op_mode, while in some ports, a sign_extend will be needed,
> such as MIPS64:
> If either GPR rs or GPR rt does not contain sign-extended 32-bit
> values (bits 63..31 equal), then
On 6/5/24 1:47 AM, Fei Gao wrote:
On 2024-06-05 14:36 Kito Cheng wrote:
Thanks for fixing this issue, and I am wondering doest it possible to
fix that without introduce target hook? I ask that because...GCC 14
also has this bug, but I am not sure it's OK to introduce new target
hook for r
On 6/5/24 12:36 AM, Kito Cheng wrote:
Thanks for fixing this issue, and I am wondering doest it possible to
fix that without introduce target hook? I ask that because...GCC 14
also has this bug, but I am not sure it's OK to introduce new target
hook for release branch? or would you suggest we
On Tue, 2024-06-04 at 22:09 +, Qing Zhao wrote:
>
>
> > On Jun 4, 2024, at 17:55, David Malcolm
> > wrote:
> >
> > On Fri, 2024-05-31 at 13:11 +, Qing Zhao wrote:
> > >
> > >
[...]
> > >
> > >
> > > Thanks a lot for the review.
> > > Will commit the patch set soon.
> >
> > [...sn
Thanks Richard for comments, will address the comments in v7, and looks like I
also need to resolve conflict up to a point.
Pan
-Original Message-
From: Richard Biener
Sent: Wednesday, June 5, 2024 4:50 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@gmai
On 6/5/24 3:08 AM, Richard Sandiford wrote:
HAO CHEN GUI writes:
Hi,
This patch replaces rtx_cost with insn_cost in forward propagation.
In the PR, one constant vector should be propagated and replace a
pseudo in a store insn if we know it's a duplicated constant vector.
It reduces the in
Wilco Dijkstra writes:
> Hi Richard,
>
>>> Essentially anything covered by HWCAP doesn't need an explicit check. So I
>>> kept
>>> the LS64 and PREDRES checks since they don't have a HWCAP allocated (I'm not
>>> entirely convinced we need these, let alone having 3 individual bits for
>>> LS64, b
Richard Biener writes:
> On Tue, 4 Jun 2024, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> > The following emulates classical interleaving for SLP load permutes
>> > that we are unlikely handling natively. This is to handle cases
>> > where interleaving (or load/store-lanes) is the opt
On Wed, Jun 5, 2024 at 2:00 PM Richard Sandiford
wrote:
>
> Sorry for the slow review.
>
> Manolis Tsamis writes:
> > This is an extension of what was done in PR106590.
> >
> > Currently if a sequence generated in noce_convert_multiple_sets clobbers the
> > condition rtx (cc_cmp or rev_cc_cmp) th
On Wed, 5 Jun 2024, Richard Biener wrote:
> On Tue, 4 Jun 2024, Richard Sandiford wrote:
>
> > Richard Biener writes:
> > > The following emulates classical interleaving for SLP load permutes
> > > that we are unlikely handling natively. This is to handle cases
> > > where interleaving (or load
On Wed, 5 Jun 2024, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Tuesday, June 4, 2024 3:33 PM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Richard Sandiford ; Tamar Christina
> >
> > Subject: [PATCH] [RFC] lower SLP load permutation to interleaving
> >
>
On Tue, 4 Jun 2024, Richard Sandiford wrote:
> Richard Biener writes:
> > The following emulates classical interleaving for SLP load permutes
> > that we are unlikely handling natively. This is to handle cases
> > where interleaving (or load/store-lanes) is the optimal choice for
> > vectorizing
Hi Richard,
>> Essentially anything covered by HWCAP doesn't need an explicit check. So I
>> kept
>> the LS64 and PREDRES checks since they don't have a HWCAP allocated (I'm not
>> entirely convinced we need these, let alone having 3 individual bits for
>> LS64, but
>> that's something for the A
From: Pan Li
As the middle support of .SAT_SUB committed, implement the unsigned
scalar int of .SAT_SUB for the riscv backend. Consider below example
code:
T __attribute__((noinline))\
sat_u_sub_##T##_fmt_1 (T x, T y) \
{ \
return (x - y) & (-(T)(x
Sorry for the slow review.
Manolis Tsamis writes:
> This is an extension of what was done in PR106590.
>
> Currently if a sequence generated in noce_convert_multiple_sets clobbers the
> condition rtx (cc_cmp or rev_cc_cmp) then only seq1 is used afterwards
> (sequences that emit the comparison it
Jan Beulich writes:
> Much like AT_HWCAP is already provided in case the platform headers
> don't have the value (yet).
>
> libgcc/
>
> * config/aarch64/cpuinfo.c: Provide AT_HWCAP2.
OK for trunk and GCC 14.
Thanks,
Richard
> ---
> Observed as build failure with 14.1.0, so may want backpo
Hi Fortraneers,
another patch to fix a memory leak. This time temporaries created during an
array construction did not have their finalizers called. I.e. allocated memory
was not freed. The attached patch addresses this issue.
Regtested ok on x86_64/Fedora 39. Ok for trunk?
Regards,
Andr
Hi Andrew, hello world,
Now with AMD Instinct MI200 data - see below.
And a better look at the numbers. In terms of USM,
there does not seem to be any clear winner of both
approaches. If we want to draw conclusions, definitely
more runs are needed (statistics):
The runs below show that the diff
Hi Eric,
on 2024/6/3 16:51, Eric Botcazou wrote:
>> Joseph pointed out "floating types should have their mode,
>> not a poorly defined precision value" in the discussion[1],
>> as he and Richi suggested, the existing macros
>> {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE will be replaced with a
>> hook mode_f
Hi Iain,
on 2024/6/4 19:35, Iain Buclaw wrote:
> Excerpts from Kewen.Lin's message of Juni 4, 2024 5:17 am:
>> Hi Iain,
>>
>> on 2024/6/3 22:39, Iain Buclaw wrote:
>>> Excerpts from Kewen.Lin's message of Juni 3, 2024 10:57 am:
Hi Iain,
on 2024/6/3 16:40, Iain Buclaw wrote:
> Ex
Hi Harald,
on 2024/6/4 04:01, Harald Anlauf wrote:
> Hi,
>
> Am 03.06.24 um 05:00 schrieb Kewen Lin:
>> Joseph pointed out "floating types should have their mode,
>> not a poorly defined precision value" in the discussion[1],
>> as he and Richi suggested, the existing macros
>> {FLOAT,{,LONG_}DOU
Hi Iain,
on 2024/6/4 14:21, Iain Sandoe wrote:
> Hi Kewen,
>
>> On 3 Jun 2024, at 04:00, Kewen Lin wrote:
>>
>> Joseph pointed out "floating types should have their mode,
>> not a poorly defined precision value" in the discussion[1],
>> as he and Richi suggested, the existing macros
>> {FLOAT,{,
Hongyu Wang writes:
> CC'd Richard for ccmp part as previously it is added only for aarch64.
> The original logic will not interrupted since if
> aarch64_gen_ccmp_first succeeded, aarch64_gen_ccmp_next will also
> success, the cmp/fcmp and ccmp/fccmp supports all GPI/GPF, and the
> prepare_operand
On 5 Jun 2024, at 10:34, Jakub Jelinek wrote:
> On Wed, Jun 05, 2024 at 08:13:14AM +, Simon Martin wrote:
>> --- a/gcc/cp/decl.cc
>> +++ b/gcc/cp/decl.cc
>> @@ -2792,10 +2792,13 @@ duplicate_decls (tree newdecl, tree olddecl,
>> bool hiding, bool was_hidden)
>>retrofit_lang_decl (newd
On Wed, 5 Jun 2024, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Wednesday, June 5, 2024 9:07 AM
> > To: Manolis Tsamis
> > Cc: gcc-patches@gcc.gnu.org; Christoph Müllner
> > ;
> > Kewen . Lin ; Philipp Tomsich
> > ;
> > Tamar Christina ; Jiangning L
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, June 5, 2024 9:07 AM
> To: Manolis Tsamis
> Cc: gcc-patches@gcc.gnu.org; Christoph Müllner ;
> Kewen . Lin ; Philipp Tomsich ;
> Tamar Christina ; Jiangning Liu
>
> Subject: Re: [PATCH] Rearrange SLP nodes with duplicate stat
On Wed, Jun 5, 2024 at 10:52 AM Li, Pan2 wrote:
>
> Thanks for explaining. I see, cmove is well designed for such cases.
If the question is if it is worth it to convert using
__builtin_sub_overflow here if the target doesn't provide scalar
saturating optab, I think the answer is yes. For x86, the
HAO CHEN GUI writes:
> Hi,
> This patch replaces rtx_cost with insn_cost in forward propagation.
> In the PR, one constant vector should be propagated and replace a
> pseudo in a store insn if we know it's a duplicated constant vector.
> It reduces the insn cost but not rtx cost. In this case, t
Hi Haochen,
on 2024/1/26 09:17, HAO CHEN GUI wrote:
> Hi,
> This patch creates an insn_and_split pattern which helps the duplicated
> constant vector replace the source pseudo of store insn in fwprop pass.
> Thus the store can be implemented by a single stxvd2x and it eliminates the
> unnecessar
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, June 4, 2024 3:33 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Sandiford ; Tamar Christina
>
> Subject: [PATCH] [RFC] lower SLP load permutation to interleaving
>
> The following emulates classical interleaving for SLP load p
Thanks for explaining. I see, cmove is well designed for such cases.
Pan
-Original Message-
From: Uros Bizjak
Sent: Wednesday, June 5, 2024 4:46 PM
To: Li, Pan2
Cc: Richard Biener ; gcc-patches@gcc.gnu.org;
juzhe.zh...@rivai.ai; kito.ch...@gmail.com; tamar.christ...@arm.com
Subject: R
On Thu, May 30, 2024 at 3:37 PM wrote:
>
> From: Pan Li
>
> After we support one gassign form of the unsigned .SAT_ADD, we
> would like to support more forms including both the branch and
> branchless. There are 5 other forms of .SAT_ADD, list as below:
>
> Form 1:
> #define SAT_ADD_U_1(T) \
On Wed, Jun 5, 2024 at 10:38 AM Li, Pan2 wrote:
>
> > I see. x86 doesn't have scalar saturating instructions, so the scalar
> > version indeed can't be converted.
>
> > I will amend x86 testcases after the vector part of your patch is committed.
>
> Thanks for the confirmation. Just curious, the .
Committed with the example in commit log updated, thanks all.
Pan
-Original Message-
From: Li, Pan2
Sent: Wednesday, June 5, 2024 4:38 PM
To: Uros Bizjak
Cc: Richard Biener ; gcc-patches@gcc.gnu.org;
juzhe.zh...@rivai.ai; kito.ch...@gmail.com; tamar.christ...@arm.com
Subject: RE: [PAT
> I see. x86 doesn't have scalar saturating instructions, so the scalar
> version indeed can't be converted.
> I will amend x86 testcases after the vector part of your patch is committed.
Thanks for the confirmation. Just curious, the .SAT_SUB for scalar has sorts of
forms, like a branch version
On Wed, Jun 05, 2024 at 08:13:14AM +, Simon Martin wrote:
> --- a/gcc/cp/decl.cc
> +++ b/gcc/cp/decl.cc
> @@ -2792,10 +2792,13 @@ duplicate_decls (tree newdecl, tree olddecl, bool
> hiding, bool was_hidden)
> retrofit_lang_decl (newdecl);
> tree alias = DECL_LOCAL_DECL_ALIAS (n
Hi,
For PR96866, when printing asm code for modifier "%a", an addressable
operand is required. While the constraint "X" allow any kind of
operand even which is hard to get the address directly. e.g. extern
symbol whose address is in TOC.
An error message would be reported to indicate the invalid
On Wed, Jun 5, 2024 at 10:22 AM Li, Pan2 wrote:
>
> > Is the above testcase correct? You need "(x + y)" as the first term.
>
> Thanks for comments, should be copy issue here, you can take SAT_SUB (x, y)
> => (x - y) & (-(TYPE)(x >= y)) or below template for reference.
>
> +#define DEF_SAT_U_SUB_F
Hi,
There was a formatting error, corrected in the updated attached patch
:-/
On 5 Jun 2024, at 10:13, Simon Martin wrote:
> We currently ICE upon the following because we don't properly handle
> local
> functions with an error_mark_node as DECL_LOCAL_DECL_ALIAS in
> duplicate_decls.
>
> ===
> Is the above testcase correct? You need "(x + y)" as the first term.
Thanks for comments, should be copy issue here, you can take SAT_SUB (x, y) =>
(x - y) & (-(TYPE)(x >= y)) or below template for reference.
+#define DEF_SAT_U_SUB_FMT_1(T) \
+T __attribute__((noinline))\
+sat_u_su
Evgeny Karpov writes:
> Richard and Uros, could you please review the changes for v2?
> Additionally, we have detected an issue with GCC GC in winnt-dll.cc. The fix
> will be included in v2.
Would it be possible to have a more "purposeful" name than
CMODEL_IS_NOT_LARGE_OR_MEDIUM_PIC? What's the
We currently ICE upon the following because we don't properly handle local
functions with an error_mark_node as DECL_LOCAL_DECL_ALIAS in duplicate_decls.
=== cut here ===
void f (void) {
virtual int f (void) const;
virtual int f (void);
}
=== cut here ===
This patch fixes this by checking for
On Wed, Jun 5, 2024 at 9:38 AM Li, Pan2 wrote:
>
> Thanks Richard, will commit after the rebased pass the regression test.
>
> Pan
>
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, June 5, 2024 3:19 PM
> To: Li, Pan2
> Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kit
On Tue, 4 Jun 2024, Manolis Tsamis wrote:
> This change adds a function that checks for SLP nodes with multiple
> occurrences
> of the same statement (e.g. {A, B, A, B, ...}) and tries to rearrange the node
> so that there are no duplicates. A vec_perm is then introduced to recreate the
> origina
On Tue, 20 Feb 2024, Danny van Kooten wrote:
> --- a/htdocs/gcc-14/porting_to.html
> +++ b/htdocs/gcc-14/porting_to.html
> @@ -133,7 +133,7 @@ On GNU systems, headers described in standards (such as
> the C
> standard, or POSIX) may require the definition of certain
> macros at the start of the
1 - 100 of 110 matches
Mail list logo
