> ---
> htdocs/gcc-13/changes.html | 31 ++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
> index f6941534..5427f805 100644
> --- a/htdocs/gcc-13/changes.html
> +++
>> With --param=riscv-autovec-preference=fixed-vlmax, however, the output is
>> reasonable. BTW please use --param instead of -param in the description to
>> avoid confusion.
>>Now the patches don't explicitly note that they only work for certain marchs,
>>configurations or so but they certainly
OK. Thanks Richard.
So let me conclude:
1. Community agree that I should support variable IV in the middle-end.
2. We can keep WHILE_LEN pattern when "not only final iteration is partial".
And I should describe it more clearly in the doc.
I should do these 2 things in the later update patch.
Ahhh. Thanks kito.
Can you give more comments about Robin's opinion that he want to change into
"fixed" vs "varying" or "fixed vector size" vs "dynamic vector size" ?
I am Ok with any of them.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-04-20 17:31
To: juzhe.zh...@rivai.ai
CC: Robin
Ahhh. These compile options are not finalized.
I just ask kito provide me some compile option that I can specify LMUL &&
auto-vectorization mode && vector-length (scalable or fixed-length)
in order to have chances test auto-vectorizaiton fully for example: fully
testing LMUL = 1/2/4/8
钟居哲 writes:
> Hi, Richards.
> Since GCC 14 is open and this patch has been boostraped && tested on X86.
> Is this patch supporting variable IV OK for the trunk ?
Doesn't the patch need updating based on the previous discussion?
I thought the outcome was that WHILE_LEN isn't a simple MIN
"juzhe.zh...@rivai.ai" writes:
> Thanks Richard reminding me. I originally think community does not allow me
> support variable amount IV and let me do this in RISC-V backend.
No, I think that part should and needs to be done in the middle-end,
since if the initial IVs are incorrect, it's very
Thanks Richard reminding me. I originally think community does not allow me
support variable amount IV and let me do this in RISC-V backend.
It seems that I can do that in middle-end. Thank you so much. I will update the
patch. Really appreciate it!
juzhe.zh...@rivai.ai
From: Richard
> $ riscv64-unknown-linux-gnu-gcc
> --param=riscv-autovec-preference=fixed-vlmax
> gcc/testsuite/gcc.target/riscv/rvv/base/spill-10.c -O2 -march=rv64gcv
> -S
> ../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/testsuite/gcc.target/riscv/rvv/base/spill-10.c:
> In function 'stach_check_alloca_1':
>
Am Dienstag, dem 04.04.2023 um 19:31 -0600 schrieb Jeff Law:
>
> On 4/3/23 13:34, Martin Uecker via Gcc-patches wrote:
> >
> >
> > With the relatively new warnings (11..) affecting VLA bounds,
> > I now get a lot of false positives with -Wall. In general, I find
> > the new warnings very
Hi!
The following patch allows to vectorize __builtin_ffs*/.FFS even if
we just have vector .CTZ support, or __builtin_ffs*/.FFS/__builtin_ctz*/.CTZ
if we just have vector .CLZ or .POPCOUNT support.
It uses various expansions from Hacker's Delight book as well as GCC's
expansion, in particular:
> Can you give more comments about Robin's opinion that he want to change into
> "fixed" vs "varying" or "fixed vector size" vs "dynamic vector size" ?
It's not necessary to decide on this now as --params are not supposed
to be stable and can be changed quickly. I was just curious if this had
Richard Biener writes:
> On Thu, 20 Apr 2023, Richard Sandiford wrote:
>
>> "juzhe.zh...@rivai.ai" writes:
>> > OK. Thanks Richard.
>> > So let me conclude:
>> > 1. Community agree that I should support variable IV in the middle-end.
>> > 2. We can keep WHILE_LEN pattern when "not only final
OK, thanks :)
On Thu, Apr 20, 2023 at 12:35 PM Jeff Law wrote:
>
> This is primarily Raphael's work. All I did was adjust it to apply to
> the trunk and add the new types to generic.md's scheduling model.
>
>
> The basic idea here is to make sure we have the ability to schedule the
> bitmanip
Hi,
on 2023/4/20 14:04, HAO CHEN GUI wrote:
> Hi,
> This patch xfails a float128 comparison test case on powerpc64
> that fails due to a longstanding issue with floating-point
> compares.
>
> See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58684 for more
> information.
>
> The patch
> LGTM, do we missed the timeline to merge code size reduction extensions
> support in gcc13?
Yeah, GCC 13 is branching out, so we need to wait for GCC 14, I also
really want to have this in GCC 13 too, and I am a little concerned
that it is still not officially ratified yet for merge that.
>
>
Hi,
on 2023/4/20 14:04, HAO CHEN GUI wrote:
> Hi,
> This patch adds ppc_cpu_supports_hw into explicit name checking in
> proc is-effective-target-keyword. So ppc_cpu_supports_hw can be used
> as a target selector in test directives. It's required by patch2 of
> this issue.
OK for trunk,
On Thu, 20 Apr 2023, Jakub Jelinek wrote:
> Hi!
>
> The following patch allows to vectorize __builtin_ffs*/.FFS even if
> we just have vector .CTZ support, or __builtin_ffs*/.FFS/__builtin_ctz*/.CTZ
> if we just have vector .CLZ or .POPCOUNT support.
> It uses various expansions from Hacker's
Hi,
This patch adds ppc_cpu_supports_hw into explicit name checking in
proc is-effective-target-keyword. So ppc_cpu_supports_hw can be used
as a target selector in test directives. It's required by patch2 of
this issue.
Thanks
Gui Haochen
ChangeLog
testsuite: make ppc_cpu_supports_hw as
Hi,
This patch xfails a float128 comparison test case on powerpc64
that fails due to a longstanding issue with floating-point
compares.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58684 for more
information.
The patch passed regression test on Power Linux platforms.
Thanks
Gui
"juzhe.zh...@rivai.ai" writes:
> OK. Thanks Richard.
> So let me conclude:
> 1. Community agree that I should support variable IV in the middle-end.
> 2. We can keep WHILE_LEN pattern when "not only final iteration is partial".
> And I should describe it more clearly in the doc.
>
> I should
The following removes unused CFG order computes from
rest_of_handle_df_initialize. The CFG orders are computed from df_analyze ().
This also removes code duplication that would have to be kept in sync.
Bootstrapped and tested on x86_64-unknown-linux-gnu for all languages,
pushed.
*
Hi, kito. Can you give more comments for us in case of compile options?
I think I should fix this patch after we have done all discussions of compile
option
of choosing vector-length && LMUL && auto-vectorization mode (VLA/VLS).
I just received Richard Sandiford comments of "WHILE_LEN" pattern.
On Thu, Apr 20, 2023 at 5:07 PM juzhe.zh...@rivai.ai
wrote:
>
> >> With --param=riscv-autovec-preference=fixed-vlmax, however, the output is
> >> reasonable. BTW please use --param instead of -param in the description to
> >> avoid confusion.
> >>Now the patches don't explicitly note that they
On Thu, 20 Apr 2023, Richard Sandiford wrote:
> "juzhe.zh...@rivai.ai" writes:
> > OK. Thanks Richard.
> > So let me conclude:
> > 1. Community agree that I should support variable IV in the middle-end.
> > 2. We can keep WHILE_LEN pattern when "not only final iteration is partial".
> > And
> diff --git
> a/gcc/testsuite/gcc.target/riscv/rvv/autovec/partial/single_rgroup-1.h
> b/gcc/testsuite/gcc.target/riscv/rvv/autovec/partial/single_rgroup-1.h
> new file mode 100644
> index 000..be6b4c641cb
> --- /dev/null
> +++
On Wed, Apr 19, 2023 at 11:20:09AM -0400, Jason Merrill wrote:
> * g++.dg/ext/int128-8.C: New test.
The testcase needs to be restricted to int128 effective targets,
it expectedly fails on i386 and other 32-bit targets.
Tested using
GXX_TESTSUITE_STDS=98,11,14,17,20,2b make check-g++
writes:
> Yes, like kito said.
> We won't enable VNx1DImode in auto-vectorization so it's meaningless to fix
> it here.
> We dynamic adjust the minimum vector-length for different '-march' according
> to RVV ISA specification.
> So we strongly suggest that we should drop this fix.
I think the
The hardfp division patch exposed a flaw in the ldexp pattern at -O0;
the compiler was trying to use out-of-range immediates on VOP3
instruction encodings.
This patch changes the constraints appropriately, and also takes the
opportunity to combine the two patterns into one using the newly
This is the 3rd ping for the 6th version of the patches.
Now, GCC14 is open. Is it ready to commit these patches to GCC14?
Kees has tested this version of the patch with Linux kernel, and everything is
good, and relsolved many false
positives for bounds checking.
Note for the review history of
---
htdocs/gcc-13/changes.html | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index f6941534..4515a6af 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -636,7
Hi Robin:
Share with you more context that I've discussed with Ju-Zhe, and look
for comments from you :)
There is 3 different auto vectorization flavor:
- VLA
- VLS fixed-vlmax (Name TBD)
- (Traditional) VLS
I think I don't need to explain too much on VLA.
So let we focus on second and third:
On Wed, Apr 19, 2023 at 6:38 PM wrote:
>
> From: Ju-Zhe Zhong
>
> This patch is adding 2 compile option for RVV auto-vectorization.
> 1. -param=riscv-autovec-preference=
>This option is to specify the auto-vectorization approach for RVV.
>Currently, we only support scalable and
On Wed, Apr 19, 2023 at 03:15:51PM +0800, liuhongt wrote:
ChangeLog nits have been already reported earlier.
> --- a/gcc/config/i386/i386-c.cc
> +++ b/gcc/config/i386/i386-c.cc
> @@ -817,6 +817,43 @@ ix86_target_macros (void)
>if (!TARGET_80387)
> cpp_define (parse_in, "_SOFT_FLOAT");
>
GCC will complaint if target ABI isn't have corresponding multi-lib on
glibc toolchain, use stdint-gcc.h to suppress that.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/simplify_ior_optimization.c: Use stdint-gcc.h
rather than stdint.h
---
I've committed this to the devel/omp/gcc-12 branch.
The patch fixes a concurrency issue where the spin-locks didn't work
well if many GPU threads tried to free low-latency memory all at once.
Adding a short sleep instruction is enough for the hardware thread to
yield and allow another to
Committed to trunk, thanks :)
On Tue, Apr 18, 2023 at 9:50 PM Jeff Law wrote:
>
>
>
> On 3/13/23 02:19, juzhe.zh...@rivai.ai wrote:
> > From: Ju-Zhe Zhong
> >
> > Co-authored-by: kito-cheng
> > Co-authored-by: kito-cheng
> >
> > Consider this case:
> > void f19 (void *base,void *base2,void
Committed, thanks!
On Wed, Apr 19, 2023 at 6:42 PM wrote:
>
> From: Ju-Zhe Zhong
>
> Testcase coming from Kito.
>
> Co-authored-by: kito-cheng
> Co-authored-by: kito-cheng
>
> PR 109535
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-vsetvl.cc (count_regno_occurrences): New
>
If we have a TREE_VEC of types that we want to strip of typedefs, we
unintuitively need to call strip_typedefs_expr instead of strip_typedefs
since only strip_typedefs_expr handles TREE_VEC, and it also dispatches
to strip_typedefs when given a type. But this seems backwards: arguably
This patch makes us use a TREE_VEC instead of TREE_LIST to represent the
trailing arguments of a variadic built-in trait. These built-ins are
typically passed a simple pack expansion as the second argument, e.g.
__is_constructible(T, Ts...)
so the main benefit of this representation change
Hi,
Is this patch ready for GCC14?
Thanks.
Qing
Begin forwarded message:
From: Qing Zhao via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>>
Subject: Fwd: [V6][PATCH 2/2] Update documentation to clarify a GCC extension
Date: April 11, 2023 at 9:38:29 AM EDT
To: Joseph Myers
Thanks Richards (Sandiford && Biener).
I have a technique question:
In case of support variable IVs for memory address calculation, is it right I
should make output of WHILE_LEN
visible in tree-ssa-loop-ivopts.cc ? Since the address calculation is not in
the loop control handling function.
Hi Bernhard,
Thanks for your questions and suggestions.
The rwlock could allow multiple threads to have concurrent read-only
access to the cache/unit list, only a single writer is allowed.
Write lock will not be acquired until all read lock are released.
And I didn't change the mutex scope
Rebased all three patches and made some small changes to the second one:
- removed sub and abd optabs from commutative_optab_p, I suspect this
was a copy paste mistake,
- removed what I believe to be a superfluous switch case in vectorizable
conversion, the one that was here:
+ if
On Thu, Apr 20, 2023 at 09:17:10AM -0400, Siddhesh Poyarekar wrote:
> On 2023-04-20 08:59, Jakub Jelinek via Gcc-patches wrote:
> > > +r.set (type, dconstm1, dconst1);
> >
> > See above, are we sure we can use [-1., 1.] range safely, or should that be
> > [-1.-Nulps, 1.+Nulps] for some kind
On Thu, 20 Apr 2023, juzhe.zh...@rivai.ai wrote:
> Thanks Richards (Sandiford && Biener).
> I have a technique question:
> In case of support variable IVs for memory address calculation, is it right I
> should make output of WHILE_LEN
> visible in tree-ssa-loop-ivopts.cc ? Since the address
On 2023-04-20 08:59, Jakub Jelinek via Gcc-patches wrote:
+r.set (type, dconstm1, dconst1);
See above, are we sure we can use [-1., 1.] range safely, or should that be
[-1.-Nulps, 1.+Nulps] for some kind of expected worse error margin of the
implementation? And ditto for -frounding-math,
Recent patches have enabled new capabilities on AMD GCN, but not all the
testsuite features were enabled. The hardfp divide patch actually had an
test regression because the expected results were too conservative.
This patch corrects both issues.
Andrewamdgcn: update target-supports.exp
The
On Tue, Apr 18, 2023 at 03:12:50PM +0200, Aldy Hernandez wrote:
> [I don't know why I keep poking at floats. I must really like the pain.
> Jakub, are you OK with this patch for trunk?]
Thanks for working on this. Though expectedly here we are running
again into the discussions we had in
In newer ISA spec, F will implied zicsr, add that into -march option to
prevent different test result on different default -misa-spec version.
gcc/testsuite/
* gcc.target/riscv/arch-19.c: Add -misa-spec.
---
gcc/testsuite/gcc.target/riscv/arch-19.c | 4 ++--
1 file changed, 2
Hi Kito,
There is one patch reviewed already and I suppose it will be ok after GCC 14
open. Could you please help to double check about it?
Pann
-Original Message-
From: Gcc-patches On Behalf
Of Li, Pan2 via Gcc-patches
Sent: Wednesday, March 29, 2023 6:39 PM
To:
Hi,
Is this patch ready for GCC14?
Thanks.
Qing
Begin forwarded message:
From: Qing Zhao via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>>
Subject: Fwd: [V6][PATCH 1/2] Handle component_ref to a structre/union field
including flexible array member [PR101832]
Date: April 11, 2023 at 9:37:18
The following avoids registering two-way equivalences from PHIs when
UNDEFINED arguments are involved.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
As noted this causes missed optimizations for the cases where
we have unreachable edges rather than UNDEFINED ranges.
OK for trunk /
On Thu, Apr 20, 2023 at 04:02:02PM +0200, Jakub Jelinek via Gcc-patches wrote:
> So, I wrote following test.
Slightly adjusted to see more info:
x86_64-linux glibc 2.35:
for i in FLOAT DOUBLE LDOUBLE FLOAT128; do for j in TONEAREST UPWARD DOWNWARD
TOWARDZERO; do gcc -D$i -DROUND=FE_$j -g -O1 -o
"Andre Vieira (lists)" writes:
> Hi,
>
> This patch replaces the uses of simd_clone_subparts with
> TYPE_VECTOR_SUBPARTS and removes the definition of the first.
>
> gcc/ChangeLog:
>
> * omp-sind-clone.cc (simd_clone_subparts): Remove.
> (simd_clone_init_simd_arrays): Replace
1. Now that we no longer substitute the constraints of an auto, we can
get rid of the infinite recursion loop breaker during level lowering
of a constrained auto and we can also use the TEMPLATE_PARM_DESCENDANTS
cache in this case.
2. Don't bother recursing when level lowering a
On 12/2/22 00:26, Eric Gallager via Gcc-patches wrote:
I tried turning -Wnarrowing back on earlier this year, but
unfortunately it didn't work due to triggering a bunch of new errors.
This patch silences at least some of them, but there will still be
more left even after applying it. (When
On 4/20/23 09:56, Patrick Palka wrote:
This patch makes us use a TREE_VEC instead of TREE_LIST to represent the
trailing arguments of a variadic built-in trait. These built-ins are
typically passed a simple pack expansion as the second argument, e.g.
__is_constructible(T, Ts...)
so the
On Thu, Apr 20, 2023 at 12:48:57PM -0400, Marek Polacek wrote:
> > - else if (enum_and_int_p && TREE_CODE (newdecl) != TYPE_DECL)
> > + else if (enum_and_int_p
> > + && TREE_CODE (newdecl) != TYPE_DECL
> > + /* Don't warn about about acc_on_device builtin redeclaration,
>
> "built-in"
On Thu, 20 Apr 2023 09:55:23 PDT (-0700), Vineet Gupta wrote:
ChangeLog:
* MAINTAINERS (Write After Approval): Add myself.
(Ref: <680c7bbe-5d6e-07cd-8468-247afc65e...@gmail.com>)
Signed-off-by: Vineet Gupta
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git
Hi!
I've noticed I've made a typo, ifn in this function this late
is always only IFN_CTZ or IFN_FFS, never IFN_CLZ.
Due to this typo, we weren't using the originally intended
.CTZ (X) = .POPCOUNT ((X - 1) & ~X)
but
.CTZ (X) = PREC - .POPCOUNT (X | -X)
instead when we want to emit
Introduce extract_operator predicate to handle both, zero-extract and
sign-extract extract operations with expressions like:
(subreg:QI
(zero_extract:SWI248
(match_operand 1 "int248_register_operand" "0")
(const_int 8)
(const_int 8)) 0)
As shown in the testcase, this
Remove repeated word (typo).
Signed-off-by: Alejandro Colomar
---
gcc/doc/extend.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index fd3745c5608..cdfb25ff272 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@
> Am 20.04.2023 um 19:40 schrieb Jakub Jelinek via Gcc-patches
> :
>
> Hi!
>
> I've noticed I've made a typo, ifn in this function this late
> is always only IFN_CTZ or IFN_FFS, never IFN_CLZ.
>
> Due to this typo, we weren't using the originally intended
> .CTZ (X) = .POPCOUNT ((X - 1) &
On 20/04/2023 15:51, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
Hi all,
This is a series of patches/RFCs to implement support in GCC to be able
to target AArch64's libmvec functions that will be/are being added to glibc.
We have chosen to use the omp pragma '#pragma omp
On 2023-04-20 10:02, Jakub Jelinek wrote:
On x86_64-linux with glibc 2.35, I see
for i in FLOAT DOUBLE LDOUBLE FLOAT128; do for j in TONEAREST UPWARD DOWNWARD
TOWARDZERO; do gcc -D$i -DROUND=FE_$j -g -O1 -o /tmp/sincos{,.c} -lm;
/tmp/sincos || echo $i $j; done; done
Aborted (core dumped)
FLOAT
"Andre Vieira (lists)" writes:
> On 20/04/2023 15:51, Richard Sandiford wrote:
>> "Andre Vieira (lists)" writes:
>>> Hi all,
>>>
>>> This is a series of patches/RFCs to implement support in GCC to be able
>>> to target AArch64's libmvec functions that will be/are being added to glibc.
>>> We
On 4/20/23 11:44, Patrick Palka wrote:
On Thu, 20 Apr 2023, Patrick Palka wrote:
1. Now that we no longer substitute the constraints of an auto, we can
get rid of the infinite recursion loop breaker during level lowering
of a constrained auto and we can also use the
On Thu, Apr 20, 2023 at 07:24:29PM +0200, Jakub Jelinek wrote:
> On Thu, Apr 20, 2023 at 12:48:57PM -0400, Marek Polacek wrote:
> > > - else if (enum_and_int_p && TREE_CODE (newdecl) != TYPE_DECL)
> > > + else if (enum_and_int_p
> > > +&& TREE_CODE (newdecl) != TYPE_DECL
> > > +/* Don't
On Thu, 20 Apr 2023, Patrick Palka wrote:
> 1. Now that we no longer substitute the constraints of an auto, we can
>get rid of the infinite recursion loop breaker during level lowering
>of a constrained auto and we can also use the TEMPLATE_PARM_DESCENDANTS
>cache in this case.
> 2.
On Wed, Apr 19, 2023 at 11:02:53AM +0200, Jakub Jelinek wrote:
> Hi!
>
> The new -Wenum-int-mismatch warning triggers with -Wsystem-headers in
> , for obvious reasons the builtin acc_on_device uses int
> type argument rather than enum which isn't defined yet when the builtin
> is created, while
ChangeLog:
* MAINTAINERS (Write After Approval): Add myself.
(Ref: <680c7bbe-5d6e-07cd-8468-247afc65e...@gmail.com>)
Signed-off-by: Vineet Gupta
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index cebf45d49e56..5f25617212a5 100644
---
On 1/17/23 15:59, Vineet Gupta wrote:
This could be useful for library writers who want to write code variants
for fast vs. slow unaligned accesses.
We distinguish explicit -mstrict-align (1) vs. slow_unaligned_access
cpu tune param (2) for even more code divesity.
gcc/ChangeLog:
*
On 3/10/23 05:40, Jin Ma via Gcc-patches wrote:
This patch adds the 'Zfa' extension for riscv, which is based on:
https://github.com/riscv/riscv-isa-manual/commit/d74d99e22d5f68832f70982d867614e2149a3bd7
latest 'Zfa' change on the master branch of the RISC-V ISA Manual as
of this writing.
On 2/10/23 15:41, Philipp Tomsich wrote:
When if-conversion encounters sequences using immediates, the
sequences can't trivially map back onto czero.eqz/czero.nezt (even if
benefitial) due to czero.eqz/czero.nez not having immediate forms.
This adds a splitter to rewrite opportunities for
"Andre Vieira (lists)" writes:
> Hi all,
>
> This is a series of patches/RFCs to implement support in GCC to be able
> to target AArch64's libmvec functions that will be/are being added to glibc.
> We have chosen to use the omp pragma '#pragma omp declare variant ...'
> with a simd construct as
On Thu, Apr 20, 2023 at 11:22:24AM -0400, Siddhesh Poyarekar wrote:
> On 2023-04-20 10:02, Jakub Jelinek wrote:
> > On x86_64-linux with glibc 2.35, I see
> > for i in FLOAT DOUBLE LDOUBLE FLOAT128; do for j in TONEAREST UPWARD
> > DOWNWARD TOWARDZERO; do gcc -D$i -DROUND=FE_$j -g -O1 -o
On 4/20/23 09:56, Patrick Palka wrote:
If we have a TREE_VEC of types that we want to strip of typedefs, we
unintuitively need to call strip_typedefs_expr instead of strip_typedefs
since only strip_typedefs_expr handles TREE_VEC, and it also dispatches
to strip_typedefs when given a type. But
Hi David,
On 3/24/23 18:58, David Malcolm wrote:
> On Fri, 2023-03-24 at 18:45 +0100, Alejandro Colomar wrote:
>> Hi David,
>>
>> On 3/24/23 15:53, David Malcolm wrote:
>>> On Fri, 2023-03-24 at 14:39 +0100, Alejandro Colomar via Gcc-
>>> patches
>>> wrote:
Warn about the following:
> Am 20.04.2023 um 19:22 schrieb Andrew MacLeod :
>
> This removes specal casing UNDEFINED ranges when we are checking to see if
> all arguments are the same and registering an equivalence.
>
> previously if there were 2 different names, and one was undefined, we ignored
> it an created an
Alejandro Colomar via Gcc-patches writes:
> Remove repeated word (typo).
>
> Signed-off-by: Alejandro Colomar
> ---
> gcc/doc/extend.texi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index fd3745c5608..cdfb25ff272 100644
gcc/ChangeLog:
* config/arm/arm.cc (thumb1_legitimate_address_p):
Use VIRTUAL_REGISTER_P predicate.
(arm_eliminable_register): Ditto.
* config/avr/avr.md (push_1): Ditto.
* config/bfin/predicates.md (register_no_elim_operand): Ditto.
* config/h8300/predicates.md
On Thu, Apr 20, 2023 at 04:22:50PM +0100, Andre Vieira (lists) wrote:
> > I don't see a good reason for dropping the extension("scalable").
> > The problem is that since the base spec requires a simdlen clause,
> > GCC should in general raise an error if simdlen is omitted.
> Where can you find
On 2/10/23 15:41, Philipp Tomsich wrote:
This adds the RISC-V Zicond extension to the option parsing.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: Recognize "zicond"
as part of an architecture string.
* config/riscv/riscv-opts.h (MASK_ZICOND): Define.
On 2/10/23 15:41, Philipp Tomsich wrote:
Adds a pattern to map the output of noce_try_store_flag_mask
if-conversion in the combiner onto vt.maskc; the input patterns
supported are similar to the following:
(set (reg/v/f:DI 75 [ ])
(and:DI (neg:DI (ne:DI (reg:DI 82)
The following patch fixes test failure of 20030222-1.c on moxie port.
But the problem can occur on other targets. The patch actually
implements the old reload approach for the test case.
The patch was successfully tested and bootstrapped on x86-64, aarch64,
and ppc64le.
commit
This removes specal casing UNDEFINED ranges when we are checking to see
if all arguments are the same and registering an equivalence.
previously if there were 2 different names, and one was undefined, we
ignored it an created an equivaence with the other one. as observed,
this is not a 2 way
On 2023-04-20 11:52, Jakub Jelinek wrote:
Why? Unless an implementation guarantees <= 0.5ulps errors, it can be one
or more ulps off, why is an error at or near 1.0 or -1.0 error any worse
than similar errors for other values?
In a general sense, maybe not, but in the sense of breaching the
Hi all.
I have noticed that in the case when we try to clear two bits through a
small constant,
and ZBS is enabled then GCC split it into two "andi" instructions.
For example for the following C code:
int foo(int a) {
return a & ~ 0x101;
}
GCC generates the following:
foo:
andi
Hi Kito,
I will remove the unused UNSPECs, thank you for finding them.
I removed the include of "vector-iterators.md" because "riscv.md"
already includes it and I was receiving multiple definition errors.
On 4/18/23 21:19, Kito Cheng wrote:
diff --git a/gcc/config/riscv/vector-iterators.md
Hello Jeff:
On 20/04/23 3:23 am, Jeff Law wrote:
>
>
> On 4/19/23 12:00, Ajit Agarwal wrote:
>> Hello All:
>>
>> This is patch-3 to improve ree pass for rs6000 target.
>> Main functionality routines to imprve ree pass.
>>
>> Bootstrapped and regtested on powerpc64-gnu-linux.
>>
>> Thanks &
Dear all,
Fortran 2018 added a clarification that the *result* of a function
whose result *variable* has the ALLOCATABLE attribute is a *value*
that itself does not have the ALLOCATABLE attribute.
For those interested: there was a thread on the J3 mailing list
some time ago (for links see the
Gerald Pfeifer writes:
> Hi Arsen,
>
> On Fri, 14 Apr 2023, Arsen Arsenović wrote:
>>> Did you intentionally not implement the following part of my suggestion
>>>
>>>if [ x${MAKEINFO}x = xx ]; then
>>>:
>> > that is, allowing to override from the command-line (or crontab)?
>> (answering
Hello Jeff:
On 21/04/23 2:33 am, Ajit Agarwal wrote:
> Hello Jeff:
>
> On 20/04/23 3:23 am, Jeff Law wrote:
>>
>>
>> On 4/19/23 12:00, Ajit Agarwal wrote:
>>> Hello All:
>>>
>>> This is patch-3 to improve ree pass for rs6000 target.
>>> Main functionality routines to imprve ree pass.
>>>
>>>
Hi Arsen,
On Fri, 14 Apr 2023, Arsen Arsenović wrote:
>> Did you intentionally not implement the following part of my suggestion
>>
>>if [ x${MAKEINFO}x = xx ]; then
>>:
> > that is, allowing to override from the command-line (or crontab)?
> (answering both the questions)
>
> This :=
Hello Jeff:
On 21/04/23 2:33 am, Ajit Agarwal via Gcc-patches wrote:
> Hello Jeff:
>
> On 20/04/23 3:23 am, Jeff Law wrote:
>>
>>
>> On 4/19/23 12:00, Ajit Agarwal wrote:
>>> Hello All:
>>>
>>> This is patch-3 to improve ree pass for rs6000 target.
>>> Main functionality routines to imprve ree
The attached (gzipped) patch brings libstdc++'s PSTL implementation up to
the current upstream version.
Tested x86_64-pc-linux-gnu, specifically with TBB 2020.3 (fedora 37 +
tbb-devel).
0001-libstdc-Synchronize-PSTL-with-upstream.patch.gz
Description: application/gzip
On 2023-04-20 13:57, Siddhesh Poyarekar wrote:
For bounds that aren't representable, one could get error bounds from
libm-test-ulps data in glibc, although I reckon those won't be
exhaustive. From a quick peek at the sin/cos data, the arc target seems
to be among the worst performers at about
publicKey - imtheboot1@protonmail.com - 0xAE052B51.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
99 matches
Mail list logo
