Thanks for your feedback. You're right that MicroMIPS doesn't support
MSA, so disabling micromips for MSA tests is a reasonable change.
I'll make sure to include a ChangeLog entry with a clear description of
future patches. Thanks for the suggestions, and I'll strive to improve
my work based on
On 3/13/23 19:25, Hans-Peter Nilsson via Gcc-patches wrote:
Jan, did I get this right? This was from your
r0-36413-g6b24c25948265c / svn r44249, now on its 22nd year!
I spot-checked the pdf for readability. Also calling on a
doc maintainer to check grammos etc. Ok to commit?
-- >8 --
I
IIRC the canonical form of (plus (op) (mult (op) (op))) is (plus
(mult (op) (op) (op)), so using the first form might not friendly for
the combine pass.
On Tue, Mar 14, 2023 at 10:24 AM wrote:
>
> From: Ju-Zhe Zhong
>
> Co-authored-by: kito-cheng
> Co-authored-by: kito-cheng
>
> This patch
From: Ju-Zhe Zhong
Co-authored-by: kito-cheng
Co-authored-by: kito-cheng
This patch is fixing the bugs reported by @kito.
// vnmsub.vx vd, rs1, vs2, vm# vd[i] = -(x[rs1] * vd[i]) + vs2[i]
// vd = -(vb * a) + vc
//= -(3 * 1) + 10
//= 7
// GCC wrongly optmize this pattern
On 2023/3/9 20:02, Richard Biener wrote:
On Wed, 8 Mar 2023, Xionghu Luo wrote:
On 2023/3/7 19:25, Richard Biener wrote:
It would be nice to avoid creating blocks / preserving labels we'll
immediately remove again. For that we do need some analysis
before creating basic-blocks that
Jan, did I get this right? This was from your
r0-36413-g6b24c25948265c / svn r44249, now on its 22nd year!
I spot-checked the pdf for readability. Also calling on a
doc maintainer to check grammos etc. Ok to commit?
-- >8 --
I needed to check what was allowed in a define_split, but
had
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/vector.md: Fine tune vmadc/vmsbc RA constraint.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/narrow_constraint-13.c: New test.
* gcc.target/riscv/rvv/base/narrow_constraint-14.c: New test.
*
Thank you for fixing this. I am not familiar with this.
This generator code (genrvv-type-indexer.cc) is written by @kito.
Kito ? Can you take a look at this?
juzhe.zh...@rivai.ai
From: Sam James
Date: 2023-03-14 08:23
To: gcc-patches
CC: Kito Cheng; Palmer Dabbelt; Andrew Waterman; Jim
This is no longer used since 0a62889c7a155f8ed971860d68870dc9c46bb004, so
let's clean it up.
gcc/ChangeLog:
* system.h: Drop unused INCLUDE_PTHREAD_H.
Signed-off-by: Sam James
---
gcc/system.h | 4
1 file changed, 4 deletions(-)
diff --git a/gcc/system.h b/gcc/system.h
index
This fixes errors like:
```
In file included from /usr/include/pthread.h:30,
from
/usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/riscv64-gentoo-linux-musl/bits/gthr-default.h:35,
from
Hi Suwa-san,
On Tue, Mar 7, 2023 at 10:04 PM Takayuki 'January June' Suwa
wrote:
>
> This patch makes LRA well with some exceptions
> (e.g. MI thunk generation due to pretending reload_completed).
>
> gcc/ChangeLog:
>
> * config/xtensa/constraints.md (R, T, U):
> Change
Hi, Richard,
Do you have more comments on my responds to your previous questions?
thanks.
Qing
> On Mar 10, 2023, at 8:48 AM, Qing Zhao via Gcc-patches
> wrote:
>
>
>
>> On Mar 10, 2023, at 2:54 AM, Richard Biener wrote:
>>
>> On Thu, 9 Mar 2023, Qing Zhao wrote:
>>
>>>
>>>
On
On Mon, Mar 13, 2023 at 10:02:41PM +0100, Jakub Jelinek wrote:
> On Mon, Mar 13, 2023 at 04:15:12PM -0400, Jason Merrill wrote:
> > The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke
> > gdbhooks, which expects tree_code_type to always be available. I considered
> >
Hi,
This is the second part to fixing PR109108, don't blindly generate the
associated function definition of all referenced thunks in the
compilation. Just delay finishing a thunk until the function gets
codegen itself. If the function never gets a definition, then the thunk
is left as "extern".
Hi,
When looking into PR109108, the reason why things go awry is because
of the logic around functions with thunks - they have their definitions
generated even when they are external. This subsequently then relied on
the detection of whether a function receiving codegen really is extern
or not,
Hi!
On Thu, Mar 09, 2023 at 07:24:58PM -0600, Peter Bergner wrote:
> On 3/9/23 8:55 AM, Segher Boessenkool wrote:
> >> Nit: Maybe we can build them out of the loop once and then just use the
> >> built one in the loop.
> >
> > Or as globals even. Currently we have X and pointer to X, but no
> >
On Mon, Mar 13, 2023 at 04:15:12PM -0400, Jason Merrill wrote:
> The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke
> gdbhooks, which expects tree_code_type to always be available. I considered
> trying to make gdbhooks more robust, but it seemed simpler to define
>
On 3/13/23 16:15, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke
gdbhooks, which expects tree_code_type to always be available. I considered
trying to make gdbhooks more robust, but it seemed
gcc/
* config/xtensa/linux.h (TARGET_ASM_FILE_END): New macro.
libgcc/
* config/xtensa/crti.S: Add .note.GNU-stack section on linux.
* config/xtensa/crtn.S: Likewise.
* config/xtensa/lib1funcs.S: Likewise.
* config/xtensa/lib2funcs.S: Likewise.
---
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
It's been inconvenient to compile testcases preprocessed with GCC 12 or
earlier because they break on
typedef __float128 _Float128;
We already had code for handling this with bool and wchar_t, it just needs
to be extended to _FloatNN as
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke
gdbhooks, which expects tree_code_type to always be available. I considered
trying to make gdbhooks more robust, but it seemed simpler to define
tree_code_type as a
Adding regression test coverage; I believe I fixed this leak
false positive with r13-5113-g688fc162b76dc6.
Successfully regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-6641-g23532dac3f602d.
gcc/testsuite/ChangeLog:
PR analyzer/105906
* gcc.dg/analyzer/leak-pr105906.c:
Successfully regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-6639-gfa9d3aa67894c8.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/exec-1.c: New test.
* gcc.dg/analyzer/snprintf-concat.c: New test.
* gcc.dg/analyzer/vsnprintf-1.c: New test.
Signed-off-by: David
PR analyzer/108045 reports a leak false positive from -fanalyzer.
The false +ve as reported seems to have been fixed by
r13-6589-g14f5e56a8a766c, but with -fanalyzer-call-summaries there are
two additional false +ves which aren't fixed by that commit.
This patch adds test coverage for these
Jan suggested we add this link, restoring in a way, though now pointing to
our general testing page.
Pushed.
(Note: gcc.gnu.org will take a couple of hours to pick up this change.)
Gerald
---
htdocs/style.mhtml | 1 +
1 file changed, 1 insertion(+)
diff --git a/htdocs/style.mhtml
Cupertino Miranda via Gcc-patches writes:
>> On 1/24/23 05:24, Cupertino Miranda wrote:
>>> Thank you for the comments and suggestions.
>>> I have changed the patch.
>>> Unfortunately in case of rx target I could not make
>>> scan-assembler-symbol-section to match. I believe it is because the
> On 1/24/23 05:24, Cupertino Miranda wrote:
>> Thank you for the comments and suggestions.
>> I have changed the patch.
>> Unfortunately in case of rx target I could not make
>> scan-assembler-symbol-section to match. I believe it is because the
>> .section and .global entries order is reversed
> Am 13.03.2023 um 16:54 schrieb Andre Vieira (lists) via Gcc-patches
> :
>
> This patch fixes the condition check for eligilibity of lowering bitfields,
> where before we would check for non-BLKmode types, in the hope of excluding
> unsuitable aggregate types, we now check directly the
On Sun, Mar 12, 2023 at 5:37 PM Takayuki 'January June' Suwa
wrote:
>
> Because GO_IF_LEGITIMATE_ADDRESS was deprecated a long time ago
> (see commit c6c3dba931548987c78719180e30ebc863404b89).
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.h (REG_OK_STRICT, REG_OK_FOR_INDEX_P,
>
This patch fixes the condition check for eligilibity of lowering bitfields,
where before we would check for non-BLKmode types, in the hope of excluding
unsuitable aggregate types, we now check directly the representative is
not an
aggregate type, i.e. suitable for a scalar register.
I tried
On 3/10/23 14:07, Marek Polacek wrote:
std::span is a view and therefore should be treated as a reference
wrapper class for the purposes of -Wdangling-reference. I'm not sure
there's a pattern that we could check for.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
On 3/13/23 02:57, Arsen Arsenović wrote:
In the edge case of a coroutine not containing any locals, the ifcd/switch
temporaries would get added to the coroutine frame, corrupting its
layout. To prevent this, we can make sure there is always a BIND_EXPR at
the top of the function body, and thus,
Hi!
This is stage 1 stuff (or does it fix some regression or such?)
On Fri, Mar 03, 2023 at 03:00:02PM -0300, Alexandre Oliva wrote:
> Some of the rs6000 call patterns, on some ABIs, issue multiple opcodes
> out of a single call insn, but the call (bl) or jump (b) is not always
> the last opcode
From: Ju-Zhe Zhong
This patch fix bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109092.
gcc/ChangeLog:
* config/riscv/riscv.md: Fix subreg bug.
---
gcc/config/riscv/riscv.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/config/riscv/riscv.md
On 3/12/2023 3:32 PM, Sandra Loosemore wrote:
> On 3/12/23 01:12, Bernhard Reutner-Fischer via Gcc-patches wrote:
>> On 12 March 2023 03:47:08 CET, Sean Bright via Gcc-patches
>> wrote:
>>> On 3/11/2023 6:39 PM, Bernhard Reutner-Fischer wrote:
On 11 March 2023 18:33:46 CET, Sean Bright via
On 13/03/2023 12:25, Tobias Burnus wrote:
Found when comparing '-v -Wl,-v' output as despite -save-temps multiple
runs
yielded differed results.
Fixed as attached.
OK for mainline?
OK.
Andrew
> On Mar 12, 2023, at 7:14 PM, Sandra Loosemore wrote:
>
> On 3/2/23 17:03, Qing Zhao via Gcc-patches wrote:
>> Ping.
>
> It looks to me like there is an associated code patch (for PR101832) that is
> still under technical discussion?
Yes, the 1st patch in this serie is the patch for
Found when comparing '-v -Wl,-v' output as despite -save-temps multiple runs
yielded differed results.
Fixed as attached.
OK for mainline?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung;
Richard Biener writes:
> On Fri, Mar 10, 2023 at 8:00 PM Gerald Pfeifer wrote:
>>
>> On Fri, 10 Mar 2023, Sandra Loosemore wrote:
>> > AFAIK we have not knowingly changed any specific requirements beyond the
>> > stated 4.7 and 4.9 for PDF output, but it concerns me that nobody is
>> > likely
I've pushed this to trunk, so that it's easier to find the docs on
maintaining the docs.
-- >8 --
pick fdcba7a9088 libstdc++: Update copyright year in FAQ
pick 6d8325681ef libstdc++: Regenerate HTML docs
libstdc++-v3/ChangeLog:
* doc/Makefile.am: Add comment referring to documentation.
On Fri, 10 Mar 2023 at 23:09, Jonny Grant wrote:
>
> docs: update copyright year in libstdc++ manual
Thanks for the patch.
> gcc/ChangeLog
> * libstdc++-v3/doc/xml/faq.xml: update copyright year in
> libstdc++ manual
This should be in the libstdc++-v3/ChangeLog file, not
Pushed to trunk.
-- >8 --
Reported by Jonny Grant.
libstdc++-v3/ChangeLog:
* include/bits/allocator.h: Fix typo in comment.
---
libstdc++-v3/include/bits/allocator.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/include/bits/allocator.h
On Mon, 13 Mar 2023 at 09:10, Jakub Jelinek wrote:
>
> Hi!
>
> On Tue, Mar 07, 2023 at 05:50:39PM +, Jonathan Wakely via Gcc-patches
> wrote:
> > I guess you want to regenerate the powerpc64 ones now. The others are
> > all OK for trunk.
>
> So the following patch updates powerpc64 which has
Hi!
On Tue, Mar 07, 2023 at 05:50:39PM +, Jonathan Wakely via Gcc-patches wrote:
> I guess you want to regenerate the powerpc64 ones now. The others are
> all OK for trunk.
So the following patch updates powerpc64 which has been excluded from
the last patch (the difference between the older
On Fri, Mar 10, 2023 at 9:16 PM Michael Collison wrote:
>
> While working on autovectorizing for the RISCV port I encountered an issue
> where can_duplicate_and_interleave_p assumes that GET_MODE_NUNITS is a
> power of two. The RISC-V target has vector modes (e.g. VNx1DImode) that
> are not a
From: Ju-Zhe Zhong
According to RVV ISA:
14. Vector Reduction Operations
"The destination vector register can overlap the source operands, including the
mask register."
gcc/ChangeLog:
* config/riscv/vector.md: Refine RA constraint.
---
gcc/config/riscv/vector.md | 96
On Fri, Mar 10, 2023 at 8:00 PM Gerald Pfeifer wrote:
>
> On Fri, 10 Mar 2023, Sandra Loosemore wrote:
> > AFAIK we have not knowingly changed any specific requirements beyond the
> > stated 4.7 and 4.9 for PDF output, but it concerns me that nobody is
> > likely to be using versions that old on
On 3/13/23 09:06, Jakub Jelinek wrote:
On Mon, Mar 13, 2023 at 08:59:15AM +0100, Aldy Hernandez wrote:
Yes, sure - I just noticed that we're forced to use high-level API for
something that's quite low-level and should be internal (a range
"breaking" internal consistency checks).
Yeah,
From: Ju-Zhe Zhong
For DEST EEW < SOURCE EEW, we can partial overlap register
according to RVV ISA.
gcc/ChangeLog:
* config/riscv/vector.md: Fix RA constraint.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/narrow_constraint-12.c: New test.
---
From: Ju-Zhe Zhong
Co-authored-by: kito-cheng
Co-authored-by: kito-cheng
Consider this case:
void f19 (void *base,void *base2,void *out,size_t vl, int n)
{
vuint64m8_t bindex = __riscv_vle64_v_u64m8 (base + 100, vl);
for (int i = 0; i < n; i++){
vbool8_t m = __riscv_vlm_v_b8
On Mon, Mar 13, 2023 at 08:59:15AM +0100, Aldy Hernandez wrote:
> > Yes, sure - I just noticed that we're forced to use high-level API for
> > something that's quite low-level and should be internal (a range
> > "breaking" internal consistency checks).
>
> Yeah, let's fix the API. No sense
在 2023/3/13 下午3:30, WANG Xuerui 写道:
On 2023/3/13 13:14, Xi Ruoyao wrote:
On Mon, 2023-03-13 at 12:58 +0800, Lulu Cheng wrote:
在 2023/3/13 下午12:54, Xi Ruoyao 写道:
On Mon, 2023-03-13 at 12:40 +0800, WANG Xuerui wrote:
This is ugly. The fact all current LA32 models don't support CRC
ops is
On 3/13/23 08:50, Richard Biener wrote:
On Mon, 13 Mar 2023, Aldy Hernandez wrote:
On 3/10/23 11:29, Jakub Jelinek wrote:
On Fri, Mar 10, 2023 at 08:53:37AM +, Richard Biener wrote:
Meh - I wonder if we can avoid all this by making float_widen_lhs_range
friend of frange and simply
From: Ju-Zhe Zhong
Co-authored-by: kito-cheng
Co-authored-by: kito-cheng
This patch fixed a bunch of bugs reported by kito.ch...@sifive.com.
gcc/ChangeLog:
* config/riscv/riscv-v.cc (legitimize_move): Handle undef value.
* config/riscv/riscv-vector-builtins.cc
On Mon, 13 Mar 2023, Aldy Hernandez wrote:
>
>
> On 3/10/23 11:29, Jakub Jelinek wrote:
> > On Fri, Mar 10, 2023 at 08:53:37AM +, Richard Biener wrote:
> >> Meh - I wonder if we can avoid all this by making float_widen_lhs_range
> >> friend of frange and simply access m_min/m_max directly
On Sat, 11 Mar 2023, Jeff Law wrote:
>
>
> On 3/7/23 04:08, Richard Biener via Gcc-patches wrote:
> > The following addresses PR109046 by adding an optimization to forwprop
> > to combine a piecewise complex load to a complex load when there are
> > no uses of the components. That's something
On 2023/3/13 13:14, Xi Ruoyao wrote:
On Mon, 2023-03-13 at 12:58 +0800, Lulu Cheng wrote:
在 2023/3/13 下午12:54, Xi Ruoyao 写道:
On Mon, 2023-03-13 at 12:40 +0800, WANG Xuerui wrote:
This is ugly. The fact all current LA32 models don't support CRC
ops is
just a coincidence; it's entirely possible
On Fri, 10 Mar 2023, Richard Sandiford wrote:
> Sorry for the slow reply.
>
> Prathamesh Kulkarni writes:
> > Unfortunately it regresses code-gen for the following case:
> >
> > svint32_t f(int32x4_t x)
> > {
> > return svdupq_s32 (x[0], x[1], x[2], x[3]);
> > }
> >
> > -O2 code-gen with
On 3/10/23 11:29, Jakub Jelinek wrote:
On Fri, Mar 10, 2023 at 08:53:37AM +, Richard Biener wrote:
Meh - I wonder if we can avoid all this by making float_widen_lhs_range
friend of frange and simply access m_min/m_max directly and use the
copy-CTOR to copy bounds and nan state ... after
In the edge case of a coroutine not containing any locals, the ifcd/switch
temporaries would get added to the coroutine frame, corrupting its
layout. To prevent this, we can make sure there is always a BIND_EXPR at
the top of the function body, and thus, always a place for our new
temporaries to
Hi Segher,
on 2023/3/9 22:55, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Mar 09, 2023 at 05:30:53PM +0800, Kewen.Lin wrote:
>> on 2023/3/9 07:01, Peter Bergner via Gcc-patches wrote:
>>> PR109073 shows a problem where GCC 11 and GCC 10 do not accept a const
>>> __vector_pair pointer operand to
61 matches
Mail list logo
