> On Mon, May 29, 2023 at 6:20 PM Martin Jambor wrote:
> >
> > Hi,
> >
> > there have been concerns that linear searches through DECL_ARGUMENTS
> > that are often necessary to compute the index of a particular
> > PARM_DECL which is the key to results of IPA-CP can happen often
> > enough to be a
gcc/ChangeLog:
* rtl.h (comparison_dominates_p): Change return type from int to bool.
(condjump_p): Ditto.
(any_condjump_p): Ditto.
(any_uncondjump_p): Ditto.
(simplejump_p): Ditto.
(returnjump_p): Ditto.
(eh_returnjump_p): Ditto.
(onlyjump_p): Ditto.
(invert_ju
Also, I have investigated power's testcase in RVV:
#include
#define TEST_ALL(T)\
T (int8_t) \
T (uint8_t)
On Mon, 29 May 2023, Jin Ma wrote:
> > Can you give me a specific example (compilation options and multilibs
> > available) of a failure you refer to?
>
> A simple example:
> 1. Use "--disable-multilib --with-abi =lp64d --with-arch
> =rv64imafdc_zba_zbb_zbc_zbs"
> to build the toolchain".
> 2.
On Thu, 25 May 2023, Richard Biener wrote:
> On Wed, May 24, 2023 at 8:36 PM Alexander Monakov wrote:
> >
> >
> > On Wed, 24 May 2023, Richard Biener via Gcc-patches wrote:
> >
> > > I’d have to check the ISAs what they actually do here - it of course
> > > depends
> > > on RTL semantics as we
More information of power's testcase:
Before this patch:
test_npeel_int16_t:
lui a4,%hi(.LANCHOR0+130)
lui a3,%hi(.LANCHOR1)
addi a3,a3,%lo(.LANCHOR1)
addi a4,a4,%lo(.LANCHOR0+130)
li a5,58
li a2,16
vsetivli zero,16,e16,m1,ta,ma
vl1re16.v v3,0(a3)
vid.v v1
.L5:
minu a3,a5,a2
vsetvli zero,a3,e16,m1
> On May 26, 2023, at 4:12 PM, Joseph Myers wrote:
>
> On Fri, 26 May 2023, Qing Zhao via Gcc-patches wrote:
>
>> Another question: is it better for me to rearrange the Patch 1/2 and Patch
>> 2/2 a little bit,
>> to put the FE , doc change and corresponding testing case together into one
> On May 26, 2023, at 4:40 PM, Kees Cook wrote:
>
> On Thu, May 25, 2023 at 04:14:47PM +, Qing Zhao wrote:
>> GCC will pass the number of elements info from the attached attribute to
>> both
>> __builtin_dynamic_object_size and bounds sanitizer to check the out-of-bounds
>> or dynamic ob
Ping?
On Tue, 23 May 2023 at 16:59, Stamatis Markianos-Wright <
stam.markianos-wri...@arm.com> wrote:
>
> On 23/05/2023 15:41, Christophe Lyon wrote:
> > Glibc defines int32_t as 'int' while newlib defines it as 'long int'.
> >
> > Although these correspond to the same size, g++ complains when u
Ok.
Thanks,
Kyrill
From: Christophe Lyon
Sent: Tuesday, May 30, 2023 4:44 PM
To: Kyrylo Tkachov
Cc: gcc-patches@gcc.gnu.org; Stam Markianos-Wright
Subject: Re: [PATCH] [arm] testsuite: make mve_intrinsic_type_overloads-int.c
libc-agnostic
Ping?
On Tue, 23 May 2023 at 16:59, Stamatis Markia
It's long mail but I think this should explain most high level concept
why I did this:
I guess I skipped too much story about the VLS-mode support; VLS-mode
support can be split into the middle-end and back-end.
# Middle-end
As Richard mentioned, those VLS types can be held by VLA-modes; for
exam
> On May 27, 2023, at 6:20 AM, Martin Uecker wrote:
>
>
> Thank you for working on this!
>
>
> Here are a couple of comments:
>
> How is the size for an object with FAM defined?
Right now, with the attribute approach, the sizeof for the object with FAM is
not impacted, and kept the same
On 5/30/23 00:30, Indu Bhagat wrote:
> On 5/25/23 9:37 AM, David Faust via Gcc-patches wrote:
>> Many BTF type kinds refer to other types via index to the final types
>> list. However, the order of the final types list is not guaranteed to
>> remain the same for the same source program between d
On 5/30/23 09:08, David Faust wrote:
@@ -793,7 +917,8 @@ btf_asm_enum_const (unsigned int size, ctf_dmdef_t * dmd)
/* Asm'out a function parameter description following a BTF_KIND_FUNC_PROTO.
*/
static void
-btf_asm_func_arg (ctf_func_arg_t * farg, size_t stroffset)
+btf_asm_func_arg
On Tue, 2023-05-30 09:05:43 +0100, Maciej W. Rozycki wrote:
[Ada as a cross-compiler fails to build with a slightly-older compiler.]
> Alternatively you can just bootstrap GCC under test natively first and
> then use the newly-built compiler for all the cross builds you want to
> verify. As y
[Changes from v1: split this change into own commit.]
All BTF type records have a 4-byte field used to encode a size or link
to another type, depending on the type kind. But BTF_KIND_ARRAY and
BTF_KIND_FWD do not use this field at all, and should write zero.
GCC already correctly writes zero in t
[Changes from v1:
- Fix typos.
- Split unrelated change into separate commit.
- Improve asm comment for enum constants, update btf-enum-1 test.
- Improve asm comment for DATASEC records, update btf-datasec-2 test.]
Many BTF type kinds refer to other types via index to the final types
list. How
Hi,
This is the 8th version of the patch, which rebased on the latest trunk.
This is an important patch needed by Linux Kernel security project.
compared to the 8th version, the Only change is in PATCH 2/2 (per
Joseph's comment):
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 17e
Richard or Jakub,
could you please review this patch and see whether it's Okay to commit?
thanks a lot.
Qing
===
GCC extension accepts the case when a struct with a C99 flexible array member
is embedded into another struct or union (possibly recursively) as the
Joseph,
could you please review this patch and see whether it's Okay for commit
now?
thanks a lot for all your comments and suggestions for this patch.
Qing.
==
on a structure with a C99 flexible array member being nested in
another structure.
"The GCC exte
On 5/26/23 16:38, Vineet Gupta wrote:
On 5/25/23 13:26, Thomas Schwinge wrote:
I'm pasting a snippet of gcc.log. Issue is indeed triggered by rvv.exp
which needs some love.
I'd intentionally asked to "see a complete 'gcc.log' file where the
ERRORs are visible".
The full log files are humon
Prathamesh Kulkarni writes:
> Hi Richard,
> The s32 case for single constant patch doesn't regress now after the
> above commit.
> Bootstrapped+tested on aarch64-linux-gnu, and verified that the new
> tests pass for aarch64_be-linux-gnu.
> Is it OK to commit ?
>
> Thanks,
> Prathamesh
>
> [aarch64
On 5/30/23 08:36, Uros Bizjak via Gcc-patches wrote:
gcc/ChangeLog:
* rtl.h (comparison_dominates_p): Change return type from int to bool.
(condjump_p): Ditto.
(any_condjump_p): Ditto.
(any_uncondjump_p): Ditto.
(simplejump_p): Ditto.
(returnjump_p): Ditto.
"Roger Sayle" writes:
> This patch implements Richard Sandiford's suggestion from
> https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618215.html
> that wi::bswap (and a new wi::bitreverse) should be functions,
> and ideally only accessors are member functions. This patch
> implements the first
Hi,
I figured I'd send this patch that I quickly hacked together some
days back. It's likely going to be controversial because we don't
have vector costs in place at all yet and even with costs it's
probably debatable as the emitted sequence is longer :)
I'm willing to defer or ditch it altogethe
The following patch fixes an LRA bug triggered by switching H8300 target
from reload to LRA. The description of the problem is in the commit
message.
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64le.
commit 30038a207c10a2783fa2695b62c7c8458ef05e73
Author: V
Committed to undo implicit assumptions.
Johann
testsuite/52641: Fix more of implicit int=32 assumption fallout.
gcc/testsuite/
PR testsuite/52641
* gcc.dg/torture/pr107451.c: Require int32plus.
* gcc.dg/torture/pr108574-3.c: Use __INT32_TYPE__ instead of int.
* g
This turns out to be a de-optimization for implementations with any
amount of temporal execution (which is most machines with LMUL > 1 and
even some machines with LMUL <= 1). Scalar instructions are generally
cheaper than multi-cycle-occupancy vector operations, so reducing
scalar work by increasi
On 5/30/23 14:05, Vladimir Makarov wrote:
The following patch fixes an LRA bug triggered by switching H8300 target
from reload to LRA. The description of the problem is in the commit
message.
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64le.
THanks. We s
On 5/30/23 04:23, Jakub Jelinek wrote:
On Tue, May 30, 2023 at 10:03:05AM +0200, Eric Botcazou wrote:
We want to be able to treat such things as invariant somehow even if we
can't do that for references to user data that might be changed by
intervening code.
That is, indicate that we know that
GCC maintainers:
The following patch fixes the first argument in the builtin definition
and the corresponding test cases. Initially, the builtin specification
was wrong due to a cut and past error. The documentation was fixed in:
commit 8cb748a31cd8c7ac9c88b6abc38ce077dd462a7a
Author: Bi
GCC maintainers:
The following patch takes the tests in vsx-vector-6-p7.h, vsx-vector-
6-p8.h, vsx-vector-6-p9.h and reorganizes them into a series of smaller
test files by functionality rather than processor version.
The patch has been tested on Power 10 with no regressions.
Please let me know
On Tue, May 30, 2023 at 04:36:34PM -0400, Jason Merrill wrote:
> Note that it is fine to treat p->fld as invariant in C++ if fld is
> TREE_READONLY and p is itself invariant. The implementation is allowed to
> assume that other code didn't destroy *p and create a new object with a
> different valu
On 5/30/23 16:51, Jakub Jelinek wrote:
On Tue, May 30, 2023 at 04:36:34PM -0400, Jason Merrill wrote:
Note that it is fine to treat p->fld as invariant in C++ if fld is
TREE_READONLY and p is itself invariant. The implementation is allowed to
assume that other code didn't destroy *p and create
PR109836 is a request to have -Wpointer-sign enabled by default. There
were points of disagreement raised in the bug report, so I figured
that maybe as a compromise, the warning could just be enabled by
-Wextra, as well (I have in fact seen some projects that enable
-Wextra but not -Wall). This pat
> On May 26, 2023, at 12:12 PM, Kees Cook wrote:
>
> On Thu, May 25, 2023 at 04:14:47PM +, Qing Zhao wrote:
>> This patch set introduces a new attribute "element_count" to annotate bounds
>> for C99 flexible array member.
>
> Thank you for this work! I'm really excited to start using it
I agree with Andrew.
And I don't think this patch is appropriate for following reasons:
1. This patch increases vector workload in machine since
it convert scalar load + vmv.v.x into vmv.v.i + vsll.vi.
2. For multi-issue OoO machine, scalar instructions are very cheap
when they are locat
On 5/30/23 16:01, 钟居哲 wrote:
I agree with Andrew.
And I don't think this patch is appropriate for following reasons:
1. This patch increases vector workload in machine since
it convert scalar load + vmv.v.x into vmv.v.i + vsll.vi.
This is probably uarch dependent. I can probably constr
Ok. I prefer just keep scalar load + vmv.v.x by default since I believe most
machines
prefer this way.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-05-31 06:09
To: 钟居哲; andrew; rdapp.gcc
CC: gcc-patches; kito.cheng; palmer
Subject: Re: [PATCH] RISC-V: Synthesize power-of-two constants.
On 5/30/23 16:13, 钟居哲 wrote:
Ok. I prefer just keep scalar load + vmv.v.x by default since I believe
most machines prefer this way.
Seems quite reasonable to me.
jeff
Assuming a fully pipelined vector unit (and from experience on
AArch64), an u-arch's scalar-to-vector move cost is likely to play a
significant role in whether this will be profitable or not.
--Philipp.
On Wed, 31 May 2023 at 00:10, Jeff Law via Gcc-patches
wrote:
>
>
>
> On 5/30/23 16:01, 钟居哲 w
Hi, Richi.
>> As I said in the PR with the proposed scheme you get a loop around copy of
>> the IV since both the pre and the post decrement values are live at the same
>> time.
>> If the CPU has a underflow bit set from the subtraction and a branch on that
>> test using that could avoid the
On Mon, 29 May 2023, Martin Uecker via Gcc-patches wrote:
> Support instrumentation of function arguments for functions
> called via a declaration. We can support only simple size
What do you mean by "via a declaration"?
If the *definition* is visible (and known to be the definition use
Pushed to trunk as r14-1420-ge4c8f7024f02d8.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/malloc-sarif-1.c: Add missing verify-sarif-file
directive.
* gcc.dg/analyzer/sarif-pr107366.c: Likewise.
---
gcc/testsuite/gcc.dg/analyzer/malloc-sarif-1.c | 2 ++
gcc/testsuite/gcc.dg/
Hi, Kito.
After consideration, I think extending VLS modes into VLA pattern is not a
wise choice now.
And I prefer everything to be pefect (Otherwise, I will rework the whole thing
in the future and it's wasting time).
So I have suggestions as follows:
First, add a new avl_type here:
enum avl
On Tue, 30 May 2023, Qing Zhao via Gcc-patches wrote:
> Joseph,
>
> could you please review this patch and see whether it's Okay for commit
> now?
This version is OK.
--
Joseph S. Myers
jos...@codesourcery.com
On 5/30/23 08:48, Maciej W. Rozycki wrote:
On Mon, 29 May 2023, Jin Ma wrote:
Can you give me a specific example (compilation options and multilibs
available) of a failure you refer to?
A simple example:
1. Use "--disable-multilib --with-abi =lp64d --with-arch
=rv64imafdc_zba_zbb_zbc_zb
From: Pan Li
This patch fix one unreachable test code, which is for debugging purpose
without cleanup before commit.
Signed-off-by: Pan Li
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vls-vlmax/init-repeat-sequence-run-1.c:
Remove debug code.
Signed-off-by: Pan Li
On 5/24/23 17:14, Jivan Hakobyan via Gcc-patches wrote:
gcc/ChangeLog:
* config/riscv/bitmanip.md (rotrdi3): New pattern.
(rotrsi3): Likewise.
(rotlsi3): Likewise.
* config/riscv/riscv-protos.h (riscv_emit_binary): New function
declaration
OK
On Wed, May 31, 2023 at 8:29 AM wrote:
>
> From: Pan Li
>
> This patch fix one unreachable test code, which is for debugging purpose
> without cleanup before commit.
>
> Signed-off-by: Pan Li
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/autovec/vls-vlmax/init-repeat-sequen
Committed, thanks Kito.
Pan
-Original Message-
From: Kito Cheng
Sent: Wednesday, May 31, 2023 8:50 AM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; Wang, Yanzhang
; daisukeokahas...@gmail.com
Subject: Re: [PATCH] RISC-V: Fix unreachable test code for init repeat sequ
Hi,
This patch is to fix ICE in rewrite_expr_tree_parallel.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110038
Bootstrapped and regtested. Ok for trunk?
Regards
Lili.
1. Limit the value of tree-reassoc-width to IntegerRange(0, 256).
2. Add width limit in rewrite_expr_tree_parallel.
gcc/Change
Hi，all. I have posted my several investigations:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620101.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620105.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620108.html
Turns out when "niters is a constant value and vf is a co
Gentle ping...
Jiufu Guo via Gcc-patches writes:
> Gentle ping...
>
> Jiufu Guo via Gcc-patches writes:
>
>> Hi
>>
>> I would like to ping this patch for stage1:
>> https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612168.html
>>
>> BR,
>> Jeff (Jiufu)
>>
>> Jiufu Guo writes:
>>
>>> Hi
Gentle ping...
Jiufu Guo via Gcc-patches writes:
> Hi,
>
> I would like to ping these patches.
> [0/4]
> https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611286.html
> [1/4]
> https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611287.html
> [2/4]
> https://gcc.gnu.org/pipermail/gcc
Gentle ping...
Jiufu Guo via Gcc-patches writes:
> Gentle ping...
>
> Jiufu Guo via Gcc-patches writes:
>
>> Hi,
>>
>> I'm thinking that we may enable this patch for stage1, so ping it.
>> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603530.html
>>
>> BR,
>> Jeff (Jiufu)
>>
>> Jiufu
After r14-1014-gc5df248509b489364c573e8, GCC started to emit
directly a zero_extract for `(t1&0x8)!=0`. This introduced
a small regression where ifcvt would not do the ifconversion
as there is now a paradoxical subreg in the dest which
was being rejected. Since paradoxical subreg set the whole
regi
Hi Suwa-san,
On Tue, May 30, 2023 at 2:51 AM Takayuki 'January June' Suwa
wrote:
>
> Resubmitting the correct one due to a mistake in merging order of fixes.
> ---
> This patch introduces more optimized implementations for the 6 cstoresi4
> insn comparison methods (eq/ne/lt/le/gt/ge, however, req
On 30.05.23 13:17, Richard Biener wrote:
The alternative would be to provide the required subset of atomic
library functions from libgcov.a and emit calls to that directly?
The locked data isn't part of any ABI so no compatibility guarantee
needs to be maintained?
So, if atomic operations are n
Hello Jeff:
Please review Jeff.
Thanks & Regards
Ajit
On 12/05/23 4:48 pm, Ajit Agarwal via Gcc-patches wrote:
> Hello Jeff:
>
>
> On 29/04/23 3:40 am, Jeff Law wrote:
>>
>>
>> On 4/20/23 15:03, Ajit Agarwal wrote:
>>
>>>
>>> Currently I support AND with const1_rtx. This is what is equivalent
On Tue, May 30, 2023 at 2:50 AM Takayuki 'January June' Suwa
wrote:
>
> Resubmitting the correct one due to a mistake in merging order of fixes.
> ---
> More optimized than the default RTL generation.
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.md (adddi3, subdi3):
> New RTL gene
On 5/30/23 11:27, David Faust wrote:
[Changes from v1: split this change into own commit.]
All BTF type records have a 4-byte field used to encode a size or link
to another type, depending on the type kind. But BTF_KIND_ARRAY and
BTF_KIND_FWD do not use this field at all, and should write zero.
On 5/30/23 11:27, David Faust wrote:
[Changes from v1:
- Fix typos.
- Split unrelated change into separate commit.
- Improve asm comment for enum constants, update btf-enum-1 test.
- Improve asm comment for DATASEC records, update btf-datasec-2 test.]
Many BTF type kinds refer to other t
From: yulong
I find fail of the xtheadcondmov-indirect-rv64.c test case and provide the way
to solve it.
In this patch, I modify the check information of the
function(ConEmv_imm_imm_reg and ConNmv_imm_imm_reg) body.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/xtheadcondmov-indirect-rv
On Wed, 31 May 2023, juzhe.zh...@rivai.ai wrote:
> Hi?all. I have posted my several investigations:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620101.html
> https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620105.html
> https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620108.html
Hi, Richi.
>> Note with SELECT_VL all bets will be off since as I understand the
>> value it gives can vary from iteration to iteration (but we know
>> a lower and maybe an upper bound?)
Yes, in RVV side, the SELECT_VL output can be in range of [ceil(avl/2), vlmax],
can be any value between the
Hello All:
This patch improves code sinking pass to sink statements before call to reduce
register pressure.
Review comments are incorporated.
For example :
void bar();
int j;
void foo(int a, int b, int c, int d, int e, int f)
{
int l;
l = a + b + c + d +e + f;
if (a != 5)
{
bar(
From: Pan Li
This patch would like to add new sub extension (aka ZVFH) to the -march= option.
To make it simple, only the sub extension itself is involved in this patch, and
the underlying FP16 related RVV intrinsic API depends on the TARGET_ZVFH.
The Zvfh extension depends on the Zve32f and Zfh
101 - 168 of 168 matches
Mail list logo
