From: Pan Li
Update in v2:
* Cleanup some unused code.
* Fix some typo of commit log.
Original log:
This patch would like to introduce one new gcc attribute for RVV.
This attribute is used to define fixed-length variants of one
existing sizeless RVV types.
This attribute is valid if and only i
Thanks for support it.
I leave this patch review to kito who is much more familiar with it than me.
CCing more folks who may be interested at this stuff.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-03-06 14:38
To: gcc-patches
CC: juzhe.zhong; kito.cheng; yanzhang.wang; Pan Li
Subject: [PATC
From: Pan Li
This patch would like to introduce one new gcc attribute for RVV.
This attribute is used to define fixed-length variants of one
existing sizeless RVV types.
This attribute is valid if and only if the mrvv-vector-bits=zvl, the only
one args should be the integer constant and its' val
On Tue, Mar 05, 2024 at 08:06:10PM -0800, Jerry D wrote:
> On 3/5/24 1:51 PM, Harald Anlauf wrote:
> > Hi Jerry,
> >
> > on further thought, do we sanitize 'child_iomsg'?
> > We pass it to snprintf as format.
> >
> > Wouldn't a strncpy be sufficient?
> >
> > Harald
> >
> >
>
> Just to be safe
On Fri, Feb 23, 2024 at 7:33 PM Fangrui Song wrote:
>
> From: Fangrui Song
>
> Targets that are not arm*-*-uclinuxfdpiceabi can use -S -mfdpic, but -c
> -mfdpic does not pass --fdpic to gas. This is an unnecessary
> restriction. Just define the ASM_SPEC in bpabi.h.
>
> Additionally, use armelf[
On 3/5/24 1:51 PM, Harald Anlauf wrote:
Hi Jerry,
on further thought, do we sanitize 'child_iomsg'?
We pass it to snprintf as format.
Wouldn't a strncpy be sufficient?
Harald
Just to be safe I will bump char message[IOMSG_LEN] to char
message[IOMSG_LEN + 1]
This is like a C string vs a
On 3/5/24 22:46, Nathaniel Shead wrote:
On Tue, Mar 05, 2024 at 06:19:07PM -0500, Jason Merrill wrote:
On 3/5/24 17:47, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
Unification for conversion operators (DEDUCE_CONV) doesn't perform
transform
On Tue, Mar 05, 2024 at 06:19:07PM -0500, Jason Merrill wrote:
> On 3/5/24 17:47, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> >
> > -- >8 --
> >
> > Unification for conversion operators (DEDUCE_CONV) doesn't perform
> > transformations like handli
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
Currently, reading a variable definition always marks that decl as
DECL_NOT_REALLY_EXTERN, with anything else imported still being
considered external. This is not sufficient for vtables, however; for an
extern template, a
Hi, han.
I think you can commit this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/646931.html
RISC-V: Refactor expand_vec_cmp
It's an NFC patch that I approved.
juzhe.zh...@rivai.ai
From: demin.han
Date: 2024-03-04 14:51
To: gcc-patches
CC: juzhe.zhong; kito.cheng
Subject: [PAT
gcc/ChangeLog:
* config.gcc: Add a case for loongarch*-*-linux-musl*.
* config/loongarch/linux.h: Disable the multilib-compatible
treatment for *musl* targets.
* config/loongarch/musl.h: New file.
---
gcc/config.gcc | 3 +++
gcc/config/loongarch/linu
On 2/26/24 15:52, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
OK.
-- >8 --
Here the TEMPLATE_DECL representing the template friend declaration for
B has class scope since B has class scope, but get_merge_kind assumes
all DECL_UNINSTANT
On 3/5/24 15:56, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
Here we ICE because we call register_local_specialization while
local_specializations is null, so
local_specializations->put ();
crashes on null this. It's null since maybe_in
On 3/5/24 17:47, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
Unification for conversion operators (DEDUCE_CONV) doesn't perform
transformations like handling forwarding references. This is correct in
general, but not for xobj parameters, whic
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
Unification for conversion operators (DEDUCE_CONV) doesn't perform
transformations like handling forwarding references. This is correct in
general, but not for xobj parameters, which should be handled "normally"
for the pur
On 3/5/24 13:33, Alejandro Colomar wrote:
Warn about the following:
char s[3] = "foo";
Initializing a char array with a string literal of the same length as
the size of the array is usually a mistake. Rarely is the case where
one wants to create a non-terminated character sequence from a
Hi Jerry,
on further thought, do we sanitize 'child_iomsg'?
We pass it to snprintf as format.
Wouldn't a strncpy be sufficient?
Harald
On 3/5/24 22:37, Harald Anlauf wrote:
Hi Jerry,
I think there is the risk of buffer overrun in the following places:
+ char message[IOMSG_LEN];
On Thu, Feb 29, 2024 at 7:11 AM H.J. Lu wrote:
>
> On Thu, Feb 29, 2024 at 7:06 AM Jan Hubicka wrote:
> >
> > > > I am worried about scenario where ifunc selector calls function foo
> > > > defined locally and foo is also used from other places possibly in hot
> > > > loops.
> > > > >
> > > > > >
We can't instrument an IFUNC resolver nor its callees as it may require
TLS which hasn't been set up yet when the dynamic linker is resolving
IFUNC symbols.
Add an IFUNC resolver caller marker to cgraph_node and set it if the
function is called by an IFUNC resolver. Update tree_profiling to skip
Hi Jerry,
I think there is the risk of buffer overrun in the following places:
+ char message[IOMSG_LEN];
+ child_iomsg_len = string_len_trim (IOMSG_LEN, child_iomsg)
+ 1;
free_line (dtp);
snprintf (message, child_iomsg_len, child_iomsg);
On 5 March 2024 04:15:12 CET, Jerry D wrote:
>
>Attached is the revised patch using the already available string_len_trim
>function.
>
>This hunk is only executed if a user has not passed an iostat or iomsg
>variable in the parent I/O statement and an error is triggered which
>terminates execu
Dear all,
error recovery on arithmetic errors during simplification has bugged
me for a long time, especially since the occurence of ICEs depended
on whether -frange-check is specified or not, whether array ctors
were involved, etc.
I've now come up with the attached patch that classifies the ari
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we ICE because we call register_local_specialization while
local_specializations is null, so
local_specializations->put ();
crashes on null this. It's null since maybe_instantiate_noexcept calls
push_to_top_level which
Warn about the following:
char s[3] = "foo";
Initializing a char array with a string literal of the same length as
the size of the array is usually a mistake. Rarely is the case where
one wants to create a non-terminated character sequence from a string
literal.
In some cases, for writing
On Tue, Mar 05, 2024 at 09:20:42PM +0100, Alejandro Colomar wrote:
> Hi!
>
> v6:
> - Small wording fix in c.opt
> - Document the option in invoke.texi
>
> I tried again, but didn't find much alphabetic order in there, so put
> it where Mike suggested, after -Warray-bounds=n.
>
> Have a lovely
On Tue, Mar 05, 2024 at 08:34:31AM -0500, David Malcolm wrote:
> > I committed that patch, but was not fast enough actually enabling the
> > buildbot and missed another fixlet needed first.
> >
> > OK, to push the attached regeneration patch?
>
> Yes
Thanks, pushed. And now also pushed the build
Warn about the following:
char s[3] = "foo";
Initializing a char array with a string literal of the same length as
the size of the array is usually a mistake. Rarely is the case where
one wants to create a non-terminated character sequence from a string
literal.
In some cases, for writing
On Tue, Mar 05, 2024 at 07:49:21PM +, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > On Tue, Mar 05, 2024 at 06:30:40PM +, Richard Sandiford wrote:
> >> (1) Keep the test where it is, taking advantage of the current SVE
> >> handling in aarch64-sve.exp, and add:
> >>
> >>
HAO CHEN GUI writes:
> Hi,
> This patch tries to fix a potential problem which is raised by the patch
> for PR111267. The volatile asm operand tries to be propagated to a single
> set insn with the patch for PR111267. The volatile asm operand might be
> executed for multiple times if the define
Jakub Jelinek writes:
> On Tue, Mar 05, 2024 at 06:30:40PM +, Richard Sandiford wrote:
>> (1) Keep the test where it is, taking advantage of the current SVE
>> handling in aarch64-sve.exp, and add:
>>
>> /* { dg-skip-if "" { no_fsanitize_address } } */
>
> I'd go with this. asan/ d
On Tue, 5 Mar 2024 at 18:31, Joseph Myers wrote:
>
> On Tue, 5 Mar 2024, Jakub Jelinek wrote:
>
> > I can't bisect that far, supposedly predefined macros weren't included back
> > in 1996 when this was written but maybe it changed in 1999 or even earlier.
>
> It looks like this changed in 3.0 (so p
On Tue, Mar 05, 2024 at 06:30:40PM +, Richard Sandiford wrote:
> (1) Keep the test where it is, taking advantage of the current SVE
> handling in aarch64-sve.exp, and add:
>
> /* { dg-skip-if "" { no_fsanitize_address } } */
I'd go with this. asan/ directory for test would be neede
On Tue, 5 Mar 2024, Jakub Jelinek wrote:
> I can't bisect that far, supposedly predefined macros weren't included back
> in 1996 when this was written but maybe it changed in 1999 or even earlier.
It looks like this changed in 3.0 (so probably with the move to cpplib to
provide the default prepr
Jakub Jelinek writes:
> On Tue, Mar 05, 2024 at 06:03:41PM +, Richard Sandiford wrote:
>> This patch makes the expansion of IFN_ASAN_MARK let through
>> poly-int-sized objects. The expansion itself was already generic
>> enough, but the tests for the fast path were too strict.
>>
>> Bootstra
On Tue, Mar 05, 2024 at 06:03:41PM +, Richard Sandiford wrote:
> This patch makes the expansion of IFN_ASAN_MARK let through
> poly-int-sized objects. The expansion itself was already generic
> enough, but the tests for the fast path were too strict.
>
> Bootstrapped & regression tested on aa
This patch makes the expansion of IFN_ASAN_MARK let through
poly-int-sized objects. The expansion itself was already generic
enough, but the tests for the fast path were too strict.
Bootstrapped & regression tested on aarch64-linux-gnu. Is this OK
for trunk now, or should it wait for GCC 15? I'
I was over-eager when adding support for strided SME2 instructions
and accidentally included forms of LUTI2 and LUTI4 that are only
available with SME2.1, not SME2. This patch removes them for now.
We're planning to add proper support for SME2.1 in the GCC 15
timeframe.
Sorry for the blunder :(
On 3/5/24 00:47, Indu Bhagat wrote:
> From: Cupertino Miranda
>
> [Changes from V2]
> - Fixed aarch64 new FAILs reported by Linaro CI.
> - Fixed typos and other nits pointed out in V2.
> [End of changes from V2]
OK, thanks.
>
> PR debug/114186
>
> DWARF DIEs of type DW_TAG_subrange_typ
For thumb1, when using a peephole to fuse
mov reg, #const
add reg, reg, SP
into
add reg, SP, #const
we must first check that reg is a low register, otherwise we will ICE
when trying to recognize the resulting insn.
gcc/ChangeLog:
PR target/113510
* con
On Sat, Jan 18, 2020 at 4:54 AM Iain Sandoe wrote:
>
> Hi,
>
> Thanks to:
>
>* the reviewers, the code was definitely improved by your reviews.
>
>* those folks who tested the branch and/or compiler explorer
> instance and reported problems with reproducers.
>
> * WG21 colleagues, e
On Tue, Mar 05, 2024 at 04:16:00PM +, Jonathan Wakely wrote:
> OK for trunk?
>
> Or am I missing something and the docs are right? (sometimes? always?)
>
>
> -- >8 --
>
> The manual has always claimed that -dD differs from -dM by not
> outputting predefined macros, but that's untrue. It has
OK for trunk?
Or am I missing something and the docs are right? (sometimes? always?)
-- >8 --
The manual has always claimed that -dD differs from -dM by not
outputting predefined macros, but that's untrue. It has been untrue
since at least GCC 3.2 and probably even older.
gcc/ChangeLog:
On Tue, Mar 5, 2024 at 1:51 PM Ken Matsui wrote:
>
> On Tue, Mar 5, 2024 at 12:38 AM Richard Biener
> wrote:
> >
> > On Mon, Mar 4, 2024 at 9:40 PM Ken Matsui wrote:
> > >
> > > (x - y) CMP 0 is equivalent to x CMP y where x and y are signed
> > > integers and CMP is <, <=, >, or >=. Similarly,
On 19/02/2024 10:11, Saurabh Jha wrote:
>
> On 2/9/2024 2:57 PM, Richard Earnshaw (lists) wrote:
>> On 30/01/2024 17:07, Saurabh Jha wrote:
>>> Hey,
>>>
>>> Previously, this test was added to fix this bug:
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337. However, it did not
>>> check the
On Mon, 26 Feb 2024, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk?
Ping.
>
> -- >8 --
>
> Here the TEMPLATE_DECL representing the template friend declaration for
> B has class scope since B has class scope, but get_merge_kind assumes
>
On Tue, 27 Feb 2024, Patrick Palka wrote:
> On Mon, 26 Feb 2024, Patrick Palka wrote:
>
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this approach
> > look reasonable?
> >
> > -- >8 --
> >
> > One known missing piece in the modules implementation is merging of a
> > streamed-in l
On Thu, 2023-11-09 at 19:33 -0500, Antoni Boucher wrote:
> Hi.
> See answers below.
>
> On Thu, 2023-11-09 at 18:04 -0500, David Malcolm wrote:
> > On Thu, 2023-11-09 at 17:27 -0500, Antoni Boucher wrote:
> > > Hi.
> > > This patch adds support for getting the CPU features in libgccjit
> > > (bug
On Tue, 5 Mar 2024, Nathaniel Shead wrote:
> On Mon, Mar 04, 2024 at 10:07:33PM -0500, Patrick Palka wrote:
> > On Tue, 5 Mar 2024, Nathaniel Shead wrote:
> >
> > > On Mon, Mar 04, 2024 at 09:26:00PM -0500, Patrick Palka wrote:
> > > > On Tue, 5 Mar 2024, Nathaniel Shead wrote:
> > > >
> > > > >
On 2/6/24 04:37, Richard Biener wrote:
The following avoids accessing out-of-bound vector elements when
native encoding a boolean vector with sub-BITS_PER_UNIT precision
elements. The error was basing the number of elements to extract
on the rounded up total byte size involved and the patch b
Register alloc may expand a 3-operand arithmetic X = Y o CST as
X = CST
X o= Y
where it may be better to instead:
X = Y
X o= CST
Johann
--
AVR: Add two RTL peepholes.
Register alloc may expand a 3-operand arithmetic X = Y o CST as
X = CST
X o= Y
where it may be better to inst
On Tue, 2024-03-05 at 13:06 +0100, Mark Wielaard wrote:
> Hi,
>
> On Mon, 2024-03-04 at 08:48 -0500, David Malcolm wrote:
> > > I have now regenerated the patch to also include the new avr
> > > mfuse-
> > > add change. It would be nice to get this committed so we can turn
> > > on the
> > > autom
Loops on named vector register are not vectorized (see comment 11 of
PR113622), so the these test cases have been failing for a while.
Rewrite them using check-function-bodies to remove hard coding register
names. A barrier is needed to always load the first operand before the
second operand.
gcc
On Tue, Mar 5, 2024 at 12:38 AM Richard Biener
wrote:
>
> On Mon, Mar 4, 2024 at 9:40 PM Ken Matsui wrote:
> >
> > (x - y) CMP 0 is equivalent to x CMP y where x and y are signed
> > integers and CMP is <, <=, >, or >=. Similarly, 0 CMP (x - y) is
> > equivalent to y CMP x. As reported in PR mi
在 2024/3/5 下午7:50, Xi Ruoyao 写道:
The psABI allows using s9 as an alias of r22.
gcc/ChangeLog:
* config/loongarch/loongarch.h (ADDITIONAL_REGISTER_NAMES): Add
s9 as an alias of r22.
---
v1 -> v2: Add a test case.
Ok for trunk?
Ok. Thanks!
gcc/config/loongarch/loongarch.h
Hi,
On Mon, 2024-03-04 at 08:48 -0500, David Malcolm wrote:
> > I have now regenerated the patch to also include the new avr mfuse-
> > add change. It would be nice to get this committed so we can turn on the
> > automatic checker.
>
> Please go ahead with that.
I committed that patch, but was n
The psABI allows using s9 as an alias of r22.
gcc/ChangeLog:
* config/loongarch/loongarch.h (ADDITIONAL_REGISTER_NAMES): Add
s9 as an alias of r22.
---
v1 -> v2: Add a test case.
Ok for trunk?
gcc/config/loongarch/loongarch.h | 1 +
gcc/testsuite/gcc.target/l
Recently I've fixed two wrong FP vector negate implementation which
caused wrong sign bits in zeros in targets (r14-8786 and r14-8801). To
prevent a similar issue from happening again, add a test case.
Tested on x86_64 (with SSE2, AVX, AVX2, and AVX512F), AArch64, MIPS
(with MSA), LoongArch (with
Applied Roger's proposed improvements with some changes:
Lengthy code is more convenient in avr.cc than in an insn
output function, and it makes it easy to work out the exact
instruction length. Moreover, the code can handle shifts
with offset zero (cases of *and3 insns).
Passed with no new reg
The following makes sure to use recognized patterns when vectorizing
roots during BB SLP discovery. We need to apply those late since
during root discovery we've not yet done pattern recognition.
All parts of the vectorizer assume patterns get used, for the testcase
we mix this up when doing live
OK, I will solve the comparison operation first and then do some check over
other operations.
Regards,
Demin
From: juzhe.zh...@rivai.ai
Sent: 2024年3月5日 17:02
To: Demin Han ; gcc-patches
Cc: kito.cheng ; pan2.li ; jeffreyalaw
; Robin Dapp ; richard.sandiford
Subject: Re: RE:[PATCH 3/5]
Ping
On 2/19/2024 10:11 AM, Saurabh Jha wrote:
On 2/9/2024 2:57 PM, Richard Earnshaw (lists) wrote:
On 30/01/2024 17:07, Saurabh Jha wrote:
Hey,
Previously, this test was added to fix this bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337. However, it did
not check the compilation o
On Tue, 2024-03-05 at 16:05 +0800, Guo Jie wrote:
> The constraint of op[1] is inconsistent with the output template.
>
> gcc/ChangeLog:
>
> * config/loongarch/loongarch.md
> (define_insn "*sge_"): Fix inconsistency
> error.
>
> ---
> Update in v2:
> Remove useless support
Committed, thanks Juzhe.
Pan
From: juzhe.zh...@rivai.ai
Sent: Tuesday, March 5, 2024 5:15 PM
To: Li, Pan2 ; gcc-patches
Cc: kito.cheng ; Wang, Yanzhang
; Li, Pan2
Subject: Re: [PATCH v1] RISC-V: Cleanup unused code in riscv_v_adjust_bytesize
[NFC]
LGTM. Thanks for clean up.
___
LGTM. Thanks for clean up.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-03-05 16:59
To: gcc-patches
CC: juzhe.zhong; kito.cheng; yanzhang.wang; Pan Li
Subject: [PATCH v1] RISC-V: Cleanup unused code in riscv_v_adjust_bytesize [NFC]
From: Pan Li
Cleanup mode_size related code which is not u
Yes. I think we are lacking some combine patterns to do all vector-scalar
combinations.
If you are interested at this topic, you can do some investigations on that (I
believe currently no body works on it for now).
I bet we should add some patterns for late-combine PASS for example:
(set (plus
From: Pan Li
Cleanup mode_size related code which is not used anymore. Below tests are
passed for this patch.
* The RVV fully regresssion test.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_v_adjust_bytesize): Cleanup unused
mode_size related code.
Signed-off-by: Pan Li
---
On Tue, 5 Mar 2024, Jakub Jelinek wrote:
> On Tue, Mar 05, 2024 at 09:27:22AM +0100, Richard Biener wrote:
> > On Tue, 5 Mar 2024, Jakub Jelinek wrote:
> > > The following patch adds support for BIT_FIELD_REF lowering with
> > > large/huge _BitInt lhs. BIT_FIELD_REF requires mode argument first
>
From: Cupertino Miranda
[Changes from V2]
- Fixed aarch64 new FAILs reported by Linaro CI.
- Fixed typos and other nits pointed out in V2.
[End of changes from V2]
PR debug/114186
DWARF DIEs of type DW_TAG_subrange_type are linked together to represent
the information about the subsequent d
On Tue, Mar 05, 2024 at 09:29:38AM +0100, Richard Biener wrote:
> I wonder if we need to care about extra temporaries on RTL before
> RA, thus whether always using a temporary would be OK?
I'd still need to do the resolve_reg_p check, otherwise if it is e.g. a
memory, the copying to temporary woul
On Tue, Mar 05, 2024 at 09:27:22AM +0100, Richard Biener wrote:
> On Tue, 5 Mar 2024, Jakub Jelinek wrote:
> > The following patch adds support for BIT_FIELD_REF lowering with
> > large/huge _BitInt lhs. BIT_FIELD_REF requires mode argument first
> > operand, so the operand shouldn't be any huge _
On Tue, Mar 5, 2024 at 8:09 AM Li, Pan2 wrote:
>
> Thanks Richard for comments.
>
> > I do wonder what the existing usadd patterns with integer vector modes
> > in various targets do?
> > Those define_insn will at least not end up in the optab set I guess,
> > so they must end up
> > being either
Hi,
I applied the mentioned last_combine
patch(https://patchwork.ozlabs.org/project/gcc/patch/mptbka7em9w@arm.com/).
And did some initial tests.
Found that:
1. Float vector-scalar and vector-imm are OK
2. Integer vector-scalar is OK
3. Integer vector-imm(e.g. a[i] > 16) is
On Mon, Mar 4, 2024 at 9:40 PM Ken Matsui wrote:
>
> (x - y) CMP 0 is equivalent to x CMP y where x and y are signed
> integers and CMP is <, <=, >, or >=. Similarly, 0 CMP (x - y) is
> equivalent to y CMP x. As reported in PR middle-end/113680, this
> equivalence does not hold for types other t
On Tue, 5 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase, we have
> (insn 10 7 11 2 (set (reg/v:TI 106 [ h ])
> (rotate:TI (reg/v:TI 106 [ h ])
> (const_int 64 [0x40]))) "pr114211.c":8:5 1042
> {rotl64ti2_doubleword}
> (nil))
> before subreg1 and the
On Tue, 5 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> The following patch adds support for BIT_FIELD_REF lowering with
> large/huge _BitInt lhs. BIT_FIELD_REF requires mode argument first
> operand, so the operand shouldn't be any huge _BitInt.
> If we only access limbs from inside of BIT_FIELD_REF
The constraint of op[1] is inconsistent with the output template.
gcc/ChangeLog:
* config/loongarch/loongarch.md
(define_insn "*sge_"): Fix inconsistency
error.
---
Update in v2:
Remove useless support for op[1] is const_imm12_operand.
---
gcc/config/loongarch/loong
76 matches
Mail list logo
