On Fri, Jul 5, 2024 at 7:48 AM Hu, Lin1 wrote:
>
> Hi, all
>
> ssedoublemode's double should mean double type, like SI -> DI.
> And we need to refactor some patterns with instead of
> .
>
> Bootstrapped and regtested on x86-64-linux-gnu, OK for trunk?
>
> BRs,
> Lin
>
> gcc/ChangeLog:
>
>
Hi, all
ssedoublemode's double should mean double type, like SI -> DI.
And we need to refactor some patterns with instead of
.
Bootstrapped and regtested on x86-64-linux-gnu, OK for trunk?
BRs,
Lin
gcc/ChangeLog:
* config/i386/sse.md (ssedoublemode): Fix the mode_attr.
---
gcc/config
Hi,
PR115688 exposes an inconsistent state in which we have VSX
enabled but ALTIVEC disabled. There is one hunk:
if (main_target_opt && !main_target_opt->x_rs6000_altivec_abi)
rs6000_isa_flags &= ~((OPTION_MASK_VSX | OPTION_MASK_ALTIVEC)
& ~rs6000_isa_flags_explic
Hi Jeff,
I have a try to only allow SI/DI mode in the iterator of the ustrunc2
pattern in the backend.
But it will get false when the middle-end try to tell
direct_internal_fn_supported_p for HImode, and
finally of course failed to detect the .SAT_TRUNC.
Indeed most patterns of riscv.md only ta
Hi Richard,
Thanks for the review comments!
on 2024/7/4 23:58, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi,
>>
>> With some historical reasons, rs6000 defines KFmode, TFmode
>> and IFmode to have different mode precision, but it causes
>> some issues and needs some workarounds such as r
Hello, Rainer,
Thanks for the report!
On Jul 3, 2024, Rainer Orth wrote:
> unfortunately this patch caused two regressions on Solaris/x86:
> FAIL: gcc.dg/ipa/iinline-attr.c scan-ipa-dump inline "hooray[^n]*inline
> copy in test"
> both 32 and 64-bit. Solaris/x86 does default to -fno-om
From: Pan Li
This patch would like to implement the .SAT_TRUNC for the RISC-V
backend. With the help of the RVV Vector Narrowing Fixed-Point
Clip Instructions. The below SEW(S) are supported:
* e64 => e32
* e64 => e16
* e64 => e8
* e32 => e16
* e32 => e8
* e16 => e8
Take below example to see
On Fri, Jul 5, 2024 at 8:06 AM Hongtao Liu wrote:
>
> On Fri, Jul 5, 2024 at 2:54 AM Roger Sayle wrote:
> >
> >
> > This patch fixes a problem with splitting of complex AVX512 ternlog
> > instructions on x86_64. A recent change allows the ternlog pattern
> > to have multiple mem-like operands pr
On Fri, Jul 5, 2024 at 5:23 AM FX Coudert wrote:
> Hi,
> The core of the powerpc-FPU manipulation is okay for me. Some comments
> below.
>
Thank you for reviewing!
> > --- a/gcc/testsuite/gfortran.dg/ieee/signaling_2_c.c
> > +++ b/gcc/testsuite/gfortran.dg/ieee/signaling_2_c.c
> > @@ -1,3 +1,1
On Fri, Jul 5, 2024 at 2:54 AM Roger Sayle wrote:
>
>
> This patch fixes a problem with splitting of complex AVX512 ternlog
> instructions on x86_64. A recent change allows the ternlog pattern
> to have multiple mem-like operands prior to reload, by emitting any
> "reloads" as necessary during sp
No need for a trailing slash, and switch to https.
---
htdocs/gcc-3.0/index.html | 2 +-
htdocs/gcc-3.1/index.html | 4 ++--
htdocs/gccmission.html| 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/htdocs/gcc-3.0/index.html b/htdocs/gcc-3.0/index.html
index a1f454e0..7d396
Hi,
The core of the powerpc-FPU manipulation is okay for me. Some comments below.
> --- a/gcc/testsuite/gfortran.dg/ieee/signaling_2_c.c
> +++ b/gcc/testsuite/gfortran.dg/ieee/signaling_2_c.c
> @@ -1,3 +1,11 @@
> +#ifdef __POWERPC__ // No support for issignaling in math.h on Darwin PPC
Two thin
On the way fix the spelling of SUSE in one case.
Pushed.
Gerald
---
htdocs/news.html | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/htdocs/news.html b/htdocs/news.html
index e78abfc3..4a104520 100644
--- a/htdocs/news.html
+++ b/htdocs/news.html
@@ -10,8 +10,7
Below is the diff of tests for gfortran on powerpc-apple-darwin10.8.0
without (unmodified gcc upstream) vs with the gfortran patch being added.
=== gfortran Summary ===
-# of expected passes69273
-# of unexpected failures36
+# of expected passes69646
+# of unexpected
>From 50fc05566ba7479844949d727233c04a5e8151e8 Mon Sep 17 00:00:00 2001
From: Sergey Fedorov
Date: Sat, 29 Apr 2023 14:55:44 +0800
Subject: [PATCH] libgfortran: implement fpu-macppc for Darwin, support IEEE
arithmetic
Signed-off-by: Sergey Fedorov
---
.../gfortran.dg/ieee/signaling_2_c.c
This patch fixes a problem with splitting of complex AVX512 ternlog
instructions on x86_64. A recent change allows the ternlog pattern
to have multiple mem-like operands prior to reload, by emitting any
"reloads" as necessary during split1, before register allocation.
The issue is that this code
At -O0, glibc's:
__extern_always_inline void
error (int __status, int __errnum, const char *__format, ...)
{
if (__builtin_constant_p (__status) && __status != 0)
__error_noreturn (__status, __errnum, __format, __builtin_va_arg_pack ());
else
__error_alias (__status, __errnum, __format
These are never nullptr and never change, so use a reference rather
than a pointer.
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r15-1846-gf8c130cdf53165.
gcc/
"Kewen.Lin" writes:
> Hi,
>
> The fix for PR112993 will make KFmode have 128 bit mode precision,
> we don't need this workaround to fix up the type precision any
> more, and just go with the mode precision. So this patch is to
> remove KFmode workaround.
>
> Bootstrapped and regtested on x86_64-r
"Kewen.Lin" writes:
> Hi,
>
> With some historical reasons, rs6000 defines KFmode, TFmode
> and IFmode to have different mode precision, but it causes
> some issues and needs some workarounds such as r14-6478 for
> PR112788. So we are going to make all rs6000 128 bit scalar
> FP modes have 128 bi
With the recent DCE related adjustment to late-combine the
rvv/base/vcreate.c test no longer has those undesirable vmvNr statements.
It's a bit unclear why this wasn't written as a scan-assembler-not and
xfailed given the comment says we don't want to see vmvNr insructions.
I must have misse
Hello Richard:
On 03/07/24 2:18 pm, Richard Biener wrote:
> On Sun, Jun 30, 2024 at 4:15 AM Ajit Agarwal wrote:
>>
>> Hello All:
>>
>> This patch determines Unroll factor based on loop register pressure.
>>
>> Unroll factor is quotient of max of available registers in loop
>> by number of livenes
Hello Richard:
Based on your feedback I have changed the logic of determining
unroll factor for loops.
Unroll factor is calculated based on available registers and regs
needed inside the loops.
Unroll factor is quotient of max of available registers in loop
over regs needed inside the loops.
Co
Am 04.07.24 um 13:25 schrieb Richard Biener:
On Thu, Jul 4, 2024 at 1:08 PM Georg-Johann Lay wrote:
Am 04.07.24 um 11:49 schrieb Richard Biener:
On Thu, Jul 4, 2024 at 11:24 AM Richard Biener
wrote:
On Wed, Jul 3, 2024 at 9:26 PM Georg-Johann Lay wrote:
Am 02.07.24 um 15:48 schrieb Richard
On 04/07/2024 13:50, Siarhei Volkau wrote:
> чт, 4 июл. 2024 г. в 12:45, Richard Earnshaw (lists)
> :
>>
>> On 20/06/2024 08:24, Siarhei Volkau wrote:
>>> If the address register is dead after load/store operation it looks
>>> beneficial to use LDMIA/STMIA instead of pair of LDR/STR instructions,
Fixes test fail on hppa*-*-linux*.
Committed to trunk.
Dave
---
Skip 30_threads/future/members/poll.cc on hppa*-*-linux*
hppa*-*-linux* lacks high resolution timer support. Timer resolution
ranges from 1 to 10ms. As a result, a large number of iterations are
needed for the wait_for_0 and ready
чт, 4 июл. 2024 г. в 12:45, Richard Earnshaw (lists) :
>
> On 20/06/2024 08:24, Siarhei Volkau wrote:
> > If the address register is dead after load/store operation it looks
> > beneficial to use LDMIA/STMIA instead of pair of LDR/STR instructions,
> > at least if optimizing for size.
> >
> > Chang
Richard Sandiford writes:
> Tamar Christina writes:
>>> -Original Message-
>>> From: Richard Sandiford
>>> Sent: Thursday, July 4, 2024 12:46 PM
>>> To: Tamar Christina
>>> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
>>> ; Marcus Shawcroft
>>> ; ktkac...@gcc.gnu.org
>>> Subject:
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Thursday, July 4, 2024 12:46 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
>> ; Marcus Shawcroft
>> ; ktkac...@gcc.gnu.org
>> Subject: Re: [PATCH 1/2]AArch64: make aarch64_
Tamar Christina writes:
> Hi All,
>
> When a two reg TBL is performed with one operand being a zero vector we can
> instead use a single reg TBL and map the indices for accessing the zero vector
> to an out of range constant.
>
> On AArch64 out of range indices into a TBL have a defined semantics
> -Original Message-
> From: Richard Sandiford
> Sent: Thursday, July 4, 2024 12:46 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; ktkac...@gcc.gnu.org
> Subject: Re: [PATCH 1/2]AArch64: make aarch64_simd_vec_unpack_lo_/_hi_
> consis
Tamar Christina writes:
> Hi All,
>
> The fix for PR18127 reworked the uxtl to zip optimization.
> In doing so it undid the changes in aarch64_simd_vec_unpack_lo_ and this
> now
> no longer matches aarch64_simd_vec_unpack_hi_. It still works because the
> RTL generated by aarch64_simd_vec_unpack
On Thu, Jul 4, 2024 at 1:08 PM Georg-Johann Lay wrote:
>
>
>
> Am 04.07.24 um 11:49 schrieb Richard Biener:
> > On Thu, Jul 4, 2024 at 11:24 AM Richard Biener
> > wrote:
> >>
> >> On Wed, Jul 3, 2024 at 9:26 PM Georg-Johann Lay wrote:
> >>>
> >>>
> >>>
> >>> Am 02.07.24 um 15:48 schrieb Richard
Hi All,
When a two reg TBL is performed with one operand being a zero vector we can
instead use a single reg TBL and map the indices for accessing the zero vector
to an out of range constant.
On AArch64 out of range indices into a TBL have a defined semantics of setting
the element to zero. Many
Hi All,
The fix for PR18127 reworked the uxtl to zip optimization.
In doing so it undid the changes in aarch64_simd_vec_unpack_lo_ and this now
no longer matches aarch64_simd_vec_unpack_hi_. It still works because the
RTL generated by aarch64_simd_vec_unpack_lo_ overlaps with the general zero
ext
> On 3 Jul 2024, at 11:59, Kyrylo Tkachov wrote:
>
> Hi all,
>
> The ACLE asks the user to test for __ARM_FEATURE_BF16 before using the
> header but GCC doesn't set this up.
> LLVM does, so this is an inconsistency between the compilers.
>
> This patch enables that macro for TARGET_BF16_FP.
Am 04.07.24 um 11:49 schrieb Richard Biener:
On Thu, Jul 4, 2024 at 11:24 AM Richard Biener
wrote:
On Wed, Jul 3, 2024 at 9:26 PM Georg-Johann Lay wrote:
Am 02.07.24 um 15:48 schrieb Richard Biener:
On Tue, Jul 2, 2024 at 3:43 PM Georg-Johann Lay wrote:
Hi Jeff,
This is a patch to
The following implements the group-size three scheme from
vect_permute_store_chain in SLP grouped store permute lowering
and extends it to power-of-two multiples of group size three.
The scheme goes from vectors A, B and C to
{ A[0], B[0], C[0], A[1], B[1], C[1], ... } by first producing
{ A[0], B
The following implements the group-size three scheme from
vect_permute_store_chain in SLP grouped store permute lowering
and extends it to power-of-two multiples of group size three.
The scheme goes from vectors A, B and C to
{ A[0], B[0], C[0], A[1], B[1], C[1], ... } by first producing
{ A[0], B
"bump" instead of "bumped" triggered by attention, and while I was there
already I tweaked the whole entry.
Pushed.
Gerald
---
htdocs/gcc-12/changes.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index bf332c8
Hi All,
The PR was about SVE codegen, the testcase accidentally used neoverse-n1
instead of neoverse-v1 as was the original report.
This updates the tool options.
Regtested on aarch64-none-linux-gnu and no issues.
committed under the obvious rule.
Thanks,
Tamar
gcc/testsuite/ChangeLog:
gcc/ChangeLog:
* config/loongarch/loongarch.cc
(loongarch_split_move): Delete.
(loongarch_hard_regno_mode_ok_uncached): Likewise.
* config/loongarch/loongarch.md
(move_doubleword_fpr): Likewise.
(load_low): Likewise.
(load_high): Likewise.
PR target/115752
gcc/ChangeLog:
* config/loongarch/loongarch.cc
(loongarch_hard_regno_mode_ok_uncached): Replace
UNITS_PER_FPVALUE with UNITS_PER_HWFPVALUE.
* config/loongarch/loongarch.h (UNITS_PER_FPVALUE): Delete.
gcc/testsuite/ChangeLog:
* gcc
On Thu, Jul 4, 2024 at 11:24 AM Richard Biener
wrote:
>
> On Wed, Jul 3, 2024 at 9:26 PM Georg-Johann Lay wrote:
> >
> >
> >
> > Am 02.07.24 um 15:48 schrieb Richard Biener:
> > > On Tue, Jul 2, 2024 at 3:43 PM Georg-Johann Lay wrote:
> > >>
> > >> Hi Jeff,
> > >>
> > >> This is a patch to get c
On 20/06/2024 08:24, Siarhei Volkau wrote:
> If the address register is dead after load/store operation it looks
> beneficial to use LDMIA/STMIA instead of pair of LDR/STR instructions,
> at least if optimizing for size.
>
> Changes v2 -> v3:
> - switching to mixed approach (insn+peep2)
> - keep
On Wed, Jul 3, 2024 at 9:26 PM Georg-Johann Lay wrote:
>
>
>
> Am 02.07.24 um 15:48 schrieb Richard Biener:
> > On Tue, Jul 2, 2024 at 3:43 PM Georg-Johann Lay wrote:
> >>
> >> Hi Jeff,
> >>
> >> This is a patch to get correct code out of 64-bit
> >> loads from address-space __memx.
> >>
> >> The
The change is OK, thanks.
> We suffer from an inconsistency in the names of uninstalled gnattools
> executables in cross-compiler configurations. The cause is a recipe we
> have:
>
> ada.all.cross:
> for tool in $(ADA_TOOLS) ; do \
> if [ -f $$tool$(exeext) ] ; \
> then \
Hi,
The fix for PR112993 will make KFmode have 128 bit mode precision,
we don't need this workaround to fix up the type precision any
more, and just go with the mode precision. So this patch is to
remove KFmode workaround.
Bootstrapped and regtested on x86_64-redhat-linux,
powerpc64{,le}-linux-g
Cache the source files as they are read, rather than discarding them at
the end of output_lines (), and move the reading of the source file to
the new function slurp.
This patch does not really change anything other than moving the file
reading out of output_file, but set gcov up for more interact
Hi,
On rs6000, there are three 128 bit scalar floating point
modes TFmode, IFmode and KFmode. With some historical
reasons, we defines them with different mode precisions,
that is KFmode 126, TFmode 127 and IFmode 128. But in
fact all of them should have the same mode precision 128,
this special
Hi,
With some historical reasons, rs6000 defines KFmode, TFmode
and IFmode to have different mode precision, but it causes
some issues and needs some workarounds such as r14-6478 for
PR112788. So we are going to make all rs6000 128 bit scalar
FP modes have 128 bit precision. Be prepared for that
> On 3 Jul 2024, at 12:50, Alfie Richards wrote:
>
> External email: Use caution opening links or attachments
> Hi Kyrill,
>
> Okay noted for future!
> Yes happy someone to commit this.
>
Ok, I’ve pushed the two patches to mainline for you.
Thanks!
Kyrill
> Kind regards,
> Alfie
>
> Sent
Hi Carl,
on 2024/7/4 07:51, Carl Love wrote:
> GCC maintainers:
>
> The patch has been updated to remove the customized vec_init built-in code.
> Specfivically the init identifier, the related generated code for the init
> built-in attribute bit, function altivec_expand_vec_init_builtin and c
Hi,
on 2024/7/4 07:40, Carl Love wrote:
>
> GCC maintainers:
>
> I moved the removal of built-ins __builtin_vsx_xvcvdpsxws and
> __builtin_vsx_xvcvdpuxws from patch 4 to patch patch 2.
>
> I fixed various issues with the ChangeLog wording, spaces and descriptions.
>
> Fixed the comments in f
Hi,
on 2024/7/4 07:33, Carl Love wrote:
> GCC maintainers:
>
> Per the comments on patch 2 from version 4, I have moved the removal of
> built-ins __builtin_vsx_xvcvdpsxws and __builtin_vsx_xvcvdpuxws from patch 4
> to this patch.
>
> Please let me know if this patch is acceptable. Thanks.
>
Hi Carl,
on 2024/7/4 01:23, Carl Love wrote:
>
> On 7/3/24 2:36 AM, Kewen.Lin wrote:
>> Hi Carl,
>>
>> on 2024/6/27 01:05, Carl Love wrote:
>>> GCC maintainers:
>>>
>>> The following patch updates the user documentation for the vec_ld, vec_lde,
>>> vec_st and vec_ste built-ins to make it clearer
on 2024/7/3 23:05, Peter Bergner wrote:
> On 7/3/24 4:01 AM, Kewen.Lin wrote:
>>> - if (TARGET_POWER10
>>> + if (TARGET_POWER8
>>>&& info->calls_p
>>>&& DEFAULT_ABI == ABI_ELFv2
>>>&& rs6000_rop_protect)
>>
>> Nit: I noticed that this is the only place to change
>> info->r
57 matches
Mail list logo
