On Tue, May 6, 2025 at 9:34 PM David Faust wrote:
>
>
>
> On 5/6/25 01:24, Richard Biener wrote:
> > On Mon, May 5, 2025 at 10:40 PM David Faust wrote:
> >>
> >>
> >>
> >> On 5/2/25 01:26, Richard Biener wrote:
> >>> On Wed, Apr 30, 2025 at 7:26 PM David Faust
> >>> wrote:
>
> The btf
Hi Richard,
Thanks for the feedback! We have sent a new version that uses
lowpart_subreg (https://gcc.gnu.org/pipermail/gcc-patches/2025-May/682835.html).
We had tried that before, but we were mishandling the case where there
are multiple stores with the same offset as the load.
As for `it->offse
On Wed, May 7, 2025 at 9:25 AM H.J. Lu wrote:
>
> On Wed, May 7, 2025 at 9:17 AM Hongtao Liu wrote:
> >
> > On Wed, May 7, 2025 at 9:06 AM H.J. Lu wrote:
> > >
> > > On Tue, May 6, 2025 at 3:35 PM Hongtao Liu wrote:
> > > >
> > > > On Tue, May 6, 2025 at 3:06 PM H.J. Lu wrote:
> > > > >
> > >
During the base register initialization, when we are eliminating the load
instruction, we were calling `emit_move_insn` on registers of the same
size but of different mode in some cases, causing an ICE.
This patch uses `lowpart_subreg` for the base register initialization,
instead of zero-extendin
On Tue, May 06, 2025 at 01:17:40PM +0100, Richard Sandiford wrote:
> Dimitar Dimitrov writes:
> > After r16-160-ge6f89d78c1a752, late_combine2 started transforming the
> > following RTL for pru-unknown-elf:
> >
> > (insn 3949 3948 3951 255 (set (reg:QI 56 r14.b0 [orig:1856 _619 ] [1856])
> >
On Tue, May 06, 2025 at 05:11:51PM -0400, Jason Merrill wrote:
> Well, that's all very complicated but seems to make sense. Can you also add
> short rationale comments to the changes in linemap_add and plugin_init?
So like this?
2025-05-07 Jakub Jelinek
PR preprocessor/108900
On Tue, May 6, 2025 at 1:35 AM wrote:
>
> From: Soumya AR
>
> Hi,
>
> This RFC and subsequent patch series introduces support for printing and
> parsing
> of aarch64 tuning parameters in the form of JSON.
>
> It is important to note that this mechanism is specifically intended for power
> users
While looking into the ifcombine, I noticed that rewrite_to_defined_overflow
was rewriting already defined code. In the previous attempt at fixing this,
the review mentioned we should not be calling rewrite_to_defined_overflow
in those cases. The places which called rewrite_to_defined_overflow didn
As mentioned previously the rewrite in move_stmt should be
using gimple_needing_rewrite_undefined/rewrite_to_defined_unconditional
instead of just rewriting the VCE.
This moves move_stmt over to those APIs.
A few testcases needed to be updated due to ABS_EXPR rewrite that happens.
Bootstrapped an
Like the patch to phiopt (r15-4033-g1f619fe25925a5f7), this adds rewriting
of VCE to gimple_with_undefined_signed_overflow/rewrite_to_defined_overflow.
In the case of moving VCE of a bool from being conditional to unconditional,
it needs to be rewritten to not to use VCE but a normal cast. pr120122
While fixing up how rewrite_to_defined_overflow works, gcc.dg/Wrestrict-22.c
started
to fail. This is because `d p+ 2` would moved by LIM and then be rewritten not
using
pointer plus. The rewriting part is correct behavior. It only recently started
to be
moved out; due to r16-190-g6901d56fea2132
On 5/6/25 10:59 AM, Steve Kargl wrote:
On Tue, May 06, 2025 at 07:43:41PM +0200, Harald Anlauf wrote:
the new logic misses the following bad code:
print *, c_associated(c_loc(val), 42)
This now ICEs here.
I suggest to not 'return true' too early before all arguments
have been checked.
On Wed, May 7, 2025 at 9:17 AM Hongtao Liu wrote:
>
> On Wed, May 7, 2025 at 9:06 AM H.J. Lu wrote:
> >
> > On Tue, May 6, 2025 at 3:35 PM Hongtao Liu wrote:
> > >
> > > On Tue, May 6, 2025 at 3:06 PM H.J. Lu wrote:
> > > >
> > > > On Tue, May 6, 2025 at 2:30 PM Liu, Hongtao
> > > > wrote:
>
On Wed, May 7, 2025 at 9:06 AM H.J. Lu wrote:
>
> On Tue, May 6, 2025 at 3:35 PM Hongtao Liu wrote:
> >
> > On Tue, May 6, 2025 at 3:06 PM H.J. Lu wrote:
> > >
> > > On Tue, May 6, 2025 at 2:30 PM Liu, Hongtao wrote:
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: H
On Tue, May 6, 2025 at 3:35 PM Hongtao Liu wrote:
>
> On Tue, May 6, 2025 at 3:06 PM H.J. Lu wrote:
> >
> > On Tue, May 6, 2025 at 2:30 PM Liu, Hongtao wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: H.J. Lu
> > > > Sent: Tuesday, May 6, 2025 2:16 PM
> > > > To: Liu, H
On 4/18/25 2:47 AM, Dongyan Chen wrote:
This patch support sdtrig and ssstrict extensions[1].
To enable GCC to recognize and process sdtrig and ssstrict extensions correctly
at compile time.
[1]https://github.com/riscv/riscv-profiles/blob/main/src/rva23-profile.adoc
gcc/ChangeLog:
On 3/24/25 6:18 AM, Mingzhu Yan wrote:
This patch support svadu and svade extension.
To enable GCC to recognize and process svadu and svade extension correctly at
compile time.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc:
(riscv_ext_version_table) New extension.
I was preparing to do some testing of Shreya's next patch on spec and
stumbled across another "andi dst,src,-1" case. I fixed some stuff like
this in the gcc-15 cycle, but this one slipped through.
It's probably about 100M instructions on deepsjeng. So tiny, but
there's no good reason to lea
On Tue, May 6, 2025 at 2:04 PM H.J. Lu wrote:
>
> On Wed, May 7, 2025 at 12:29 AM Andi Kleen wrote:
> >
> > On 2025-05-06 09:48, H.J. Lu wrote:
> > > On Mon, May 5, 2025 at 9:56 PM Andi Kleen wrote:
> > >>
> > >> On Mon, May 05, 2025 at 06:20:40AM -0700, Andi Kleen wrote:
> > >> > > If the branc
Richard Biener writes:
> The following amends gcc-15/changes.html with a note that reload
> is going to be removed for GCC 16.
>
> OK for www?
>
> * htdocs/gcc-15/changes.html: Mark GCC 15 as last release
> supporting reload.
My reading of the threads was that no-one is objecting to t
On 5/6/25 6:49 AM, Jakub Jelinek wrote:
Hi!
The backport of the PR108900 fix to 14 branch broke building chromium
because static_assert (__LINE__ == expected_line_number, ""); now triggers
as the __LINE__ values are off by one.
This isn't the case on the trunk and 15 branch because we've switche
On Wed, May 7, 2025 at 12:29 AM Andi Kleen wrote:
>
> On 2025-05-06 09:48, H.J. Lu wrote:
> > On Mon, May 5, 2025 at 9:56 PM Andi Kleen wrote:
> >>
> >> On Mon, May 05, 2025 at 06:20:40AM -0700, Andi Kleen wrote:
> >> > > If the branch edge destination is a basic block with only a direct
> >> > >
Jennifer Schmitz writes:
> About the tests: Non-power-of-2 patterns are already being tested in
> gcc.target/aarch64/sve/acle/general/whilelt_5.c.
OK
> For the case of svptrue_b16 ()
> with 8-bit load, I added a test case for it. Currently, it has a single test
> case,
> but if necessary I can
On 5/6/25 3:05 PM, Simon Martin wrote:
The following test case highlights two issues - see
https://godbolt.org/z/7E1KGYreh:
1. We error out at both L4 and L5, while (at least) clang, EDG and MSVC
only reject L5
2. Our error message for L5 incorrectly mentions using a null pointer
=== cu
On Tue, May 06, 2025 at 02:09:45PM -0400, Paul Koning wrote:
> > It is pretty hard to work with double-indirect things, often have to
> > make sure the two memory accesses are not to the same address, etc.
>
> Types will prevent that, typically, but in any case double indirect like that
> is stil
On 5/6/25 01:24, Richard Biener wrote:
> On Mon, May 5, 2025 at 10:40 PM David Faust wrote:
>>
>>
>>
>> On 5/2/25 01:26, Richard Biener wrote:
>>> On Wed, Apr 30, 2025 at 7:26 PM David Faust wrote:
The btf_decl_tag and btf_type_tag attributes provide a means to annotate
declarat
Dear all,
here's another rather obvious case where a temporary is needed for
an inquiry reference of a complex array which is a component of a
derived type. In contrast to PR119986, the argument is handled
within the code for the intrinsic TRANSFER, so that the other
patch did not catch the pres
The following test case highlights two issues - see
https://godbolt.org/z/7E1KGYreh:
1. We error out at both L4 and L5, while (at least) clang, EDG and MSVC
only reject L5
2. Our error message for L5 incorrectly mentions using a null pointer
=== cut here ===
struct A { int i; };
struct C : v
> On May 6, 2025, at 1:17 PM, Segher Boessenkool
> wrote:
>
> ...
>>> As for MEM(MEM(xyz)) addressing modes I'm less sure - I suppose those
>>> are usually formed at RTL expansion time (rather than, say, by
>>> RTL combine)? If PDP-11 is the only target with those then it might
>>> be easier
On Tue, May 06, 2025 at 07:43:41PM +0200, Harald Anlauf wrote:
>
> the new logic misses the following bad code:
>
> print *, c_associated(c_loc(val), 42)
>
> This now ICEs here.
>
> I suggest to not 'return true' too early before all arguments
> have been checked.
>
Good catch, Harald. We
Hi Jerry, all,
the new logic misses the following bad code:
print *, c_associated(c_loc(val), 42)
This now ICEs here.
I suggest to not 'return true' too early before all arguments
have been checked.
Cheers,
Harald
On 5/6/25 19:15, Jerry D wrote:
On 5/6/25 12:44 AM, Paul Richard Thomas wr
On Tue, May 6, 2025 at 6:48 PM Jonathan Wakely wrote:
> When concatenating a path we reallocate the left operand's storage to
> make room for the new components being added. When the two operands are
> the same object, or the right operand is one of the components of the
> left operand, the reall
On Sat, May 03, 2025 at 07:42:22AM -0600, Jeff Law wrote:
> On 5/3/25 4:52 AM, Richard Biener wrote:
> >On Fri, 2 May 2025, Paul Koning wrote:
> >>>On May 2, 2025, at 12:27 PM, Maciej W. Rozycki
> >>>wrote:
> >>Indeed, I have noticed that LRA doesn't take advantage of PDP-11 (and I
> >>would gues
On 5/6/25 12:44 AM, Paul Richard Thomas wrote:
HI Jerry,
The patch looks good to me. OK for mainline and for backporting. I never
quite know what to suggest for delaying backporting and so I will leave
it to your judgement.
Thanks for the patch.
Paul
Thanks Paul, committed as:
commit r16
Hi!
On Fri, May 02, 2025 at 12:11:37PM +0200, Richard Biener wrote:
> This mini-series removes the TARGET_LRA_P hook, forcing all targets
> to use LRA. I have not touched the targets that define -mlra
> in terms of a 'Target Mask(XXX)' since IIRC there's no way to
> "default" that. I'd expect th
When concatenating a path we reallocate the left operand's storage to
make room for the new components being added. When the two operands are
the same object, or the right operand is one of the components of the
left operand, the reallocation invalidates the pointers that refer
into the right opera
On Mon, May 05, 2025 at 08:30:09PM -0700, Jerry D wrote:
> Attached patch fixes this by checking for BT_VOID and EXPR_FUNCTION.
>
> Thank you for guidance from Steve in the PR and Vincent for
> identifying the problem.
>
> Two test case files added to the testsuite.
>
> Regression tested on x86_
On Tue, 29 Apr 2025 at 09:45, Jonathan Wakely wrote:
>
> All of reduce, transform_reduce, exclusive_scan, and inclusive_scan,
> transform_exclusive_scan, and transform_inclusive_scan have a
> precondition that the type of init meets the Cpp17MoveConstructible
> requirements. It isn't required to b
This causes an ICE as shown in the PR, but it should be fixed in the
library code anyway.
libstdc++-v3/ChangeLog:
PR c++/120112
* include/bits/ptr_traits.h (_Safe_iterator_base): Use class
keyword in class-head of declaration.
* include/debug/debug.h (_Safe_iterato
Currently the GLIBCXX_ENABLE_ATOMIC_BUILTINS macro checks for a variety
of __atomic built-ins for bool, short and int. If all those checks pass,
then it defines _GLIBCXX_ATOMIC_BUILTINS and uses the definitions from
config/cpu/generic/atomicity_builtins/atomicity.h for the non-inline
versions of __
On 2025-05-06 09:48, H.J. Lu wrote:
On Mon, May 5, 2025 at 9:56 PM Andi Kleen wrote:
On Mon, May 05, 2025 at 06:20:40AM -0700, Andi Kleen wrote:
> > If the branch edge destination is a basic block with only a direct
> > sibcall, change the jcc target to the sibcall target, decrement the
> > de
On Tue, 6 May 2025 at 13:35, Tomasz Kamiński wrote:
>
> Use `__unicode::_field_width` to compute the field width of the output when
> writting
> the formatted output for std::chrono::types. This applies both to characters
> copied
> from format string, and one produced by localized formatting.
>
Dhruv Chawla writes:
> This patch modifies the intrinsic expanders to expand svlsl and svlsr to
> unpredicated forms when the predicate is a ptrue. It also folds the
> following pattern:
>
> lsl , ,
> lsr , ,
> orr , ,
>
> to:
>
> revb/h/w ,
>
> when the shift amount is equal to half t
Hi Harald,
It appears that something is not right and generates wrong code with
the check enabled. Can you have another look?
The problem was indeed that generating a formal from an actual
arglist is a bad idea when classes are involved. Fixed in the
attached patch. I think it still makes s
> On 6 May 2025, at 17:49, Alfie Richards wrote:
>
> On 06/05/2025 09:36, Yangyu Chen wrote:
>>> On 6 May 2025, at 16:01, Alfie Richards wrote:
>>>
>>> Hello,
>>>
>>> I like this idea. I have a couple thoughts to add.
>>>
>>> On 05/05/2025 09:46, Yangyu Chen wrote:
> On 5 May 2025, at
Hi,
Thanks for the update. The patch mostly looks good, but one minor and
one more substantial comment below.
BTW, the patch seems to have been corrupted en route, in that unchanged
lines have too much space. Attaching is fine if that's easier.
Dhruv Chawla writes:
> diff --git a/gcc/config/a
On 3/17/25 8:26 AM, Dongyan Chen wrote:
This patch support zilsd and zclsd[1] extensions.
To enable GCC to recognize and process zilsd and zclsd extension correctly at
compile time.
[1] https://github.com/riscv/riscv-zilsd
Changes for v2:
- Remove the addition of zilsd and zclsd extension i
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r16-417-gf4fa41cd5ccbcc.
gcc/ChangeLog:
* selftest-diagnostic.cc (test_diagnostic_context::report): Use
diagnostic_option_id rather than plain int.
* selftest-d
This should work for Solaris and BSD variants; further extensions might be
needed to produce a good QoI on other targets (but at least the library
should still build there).
Tested on x86_64, aarch64 and powerpc64le Linux and on x86_64-darwin21/23.
Checked manually that the configurations were as
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 r16-415-g9fb44cc4823106.
gcc/ChangeLog:
* diagnostic-format-sarif.cc (maybe_get_sarif_kind): Add cases for
new kinds of logical loc
For followup work I need to be able to get at data from a
diagnostic_logical_location after creating it, hence the
need to extend libgdiagnostics with accessor entrypoints.
This is the first extension to libgdiagnostics since the initial
release. The patch uses symbol versioning to add the new
en
This patch extends our json class to track JSON pointers (RFC 6901),
and then uses this within sarif-replay to provide logical locations
within the JSON when reporting on issues in the SARIF.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration test
Previously our SARIF output did not capture nesting of logical
locations: any time a result or event referred to a logical location it
would simply put a copy of the logical location into the pertinent
location object without a "parentIndex" property.
With this patch we instead populate such locat
Previously we used an abstract base class logical_location with
concrete subclasses to separate the diagnostics subsystem from
implementation details of "tree" and of libgdiagnostics.
This approach required allocating implementation objects on the heap
whenever working with logical locations, and
On Tue, 6 May 2025, Jakub Jelinek wrote:
> Hi!
>
> Here is the 14 branch version of the PR120061 fix I've just posted
> for 16/15.
> The differences from the earlier patch are all caused by the
> 32-bit location_t on the branch instead of 64-bit location_t that
> 16/15 has.
> So, it needs 1 << wh
Remove the gimple ** argument that is no longer needed from vectorizable_lc_phi
and vect_transform_lc_phi.
---
gcc/tree-vect-loop.cc | 4 ++--
gcc/tree-vect-stmts.cc | 4 ++--
gcc/tree-vectorizer.h | 6 ++
3 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/gcc/tree-vect-loop.cc
This removes the non-SLP paths from vectorizable_conversion and in the process
eliminates uses of 'ncopies' and removes 'get_initial_def_for_reduction'. Not
done anything about STMT_VINFO_VECTYPE as I'm not sure about its uses in
vectorizable_reduction in relation to the vectype_in/out.
---
Split up vectorizable_lc_phi and create a vect_transform_lc_phi.
---
gcc/tree-vect-loop.cc | 30 +-
gcc/tree-vect-stmts.cc | 4 ++--
gcc/tree-vectorizer.h | 2 ++
3 files changed, 21 insertions(+), 15 deletions(-)
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect
Folds loops that used ncopies and now no longer need to be loops
---
gcc/tree-vect-loop.cc | 51 +++
1 file changed, 18 insertions(+), 33 deletions(-)
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index c47ebc564c7..b2fa2703d34 100644
--- a/gc
Prunes code from the trivial true/false conditions.
---
gcc/tree-vect-loop.cc | 540 --
1 file changed, 155 insertions(+), 385 deletions(-)
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 69b692f1673..4ab7d227e42 100644
--- a/gcc/tree-vect
This replaces trivially to fold conditions.
---
gcc/tree-vect-loop.cc | 90 +--
1 file changed, 45 insertions(+), 45 deletions(-)
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 3de1ea646b4..69b692f1673 100644
--- a/gcc/tree-vect-loop.cc
+
From: Andre Vieira
Somewhat following richi's example of SLP cleanup, this patch series cleansup
SLP code for vectorizable_reduction and friends.
1) fold trivially true/false conditions based on the slp_node argument
without code block removal/reindent, etc.
2) do trivial dead code elimin
On 4/16/25 8:32 AM, Paul-Antoine Arras wrote:
Please find attached an updated patch with an additional cost model. By
default, an instruction is 4 and the penalty for moving data from
floating-point to vector register is 2; thus, vfmadd.vf costs 6, which
still makes it cheaper than vec_du
The following fixes the alignment analysis done by the VMAT_STRIDED_SLP
code which for the case of VF > 1 currently relies on dataref analysis
which assumes consecutive accesses. But the code generation advances
by DR_STEP between each iteration which requires us to assess that
individual DR_STEP
在 2025/5/6 下午6:14, WANG Xuerui 写道:
On 4/30/25 14:26, Lulu Cheng wrote:
Because MIPS function symbol is generated in the prologue function,
this nop generation should be done in prologue.
OK for trunk?
PR target/99217
gcc/ChangeLog:
* config/mips/mips.cc (mips_start_function_definiti
On Tue, May 6, 2025 at 1:39 PM Luc Grosheintz
wrote:
>
> On 5/6/25 11:28 AM, Tomasz Kaminski wrote:
> > For better reference, here is illustration of the design I was thinking
> > about:
> > https://godbolt.org/z/7aTcM8fz4
> > I would also consider having left_mapping_base to accept padding, wher
Use `__unicode::_field_width` to compute the field width of the output when
writting
the formatted output for std::chrono::types. This applies both to characters
copied
from format string, and one produced by localized formatting.
We also use _Str_sink::view() instead of get(), which avoids copy
This patch provides _M_discarding functiosn for _Sink_iter and _Sink function
that returns true, if any further writes to the _Sink_iter and underlying _Sink,
will be discared, and thus can be omitted.
Currently only the _Padding_sink reports discarding mode of if width of sequence
characters is g
> Please still remove the leading '*' of the comment. The series is OK with
> that
> fixed. Thanks for your patience.
Thanks Robin for help and explanation. I will commit with these changes, it
looks like auto inserted when enter.
> We can take care of a more comprehensive rtx_cost once all
+/*
+ * Return the cost of operation that move from gpr to vr.
+ *
+ * It will take the value of --param=gpr2vr_cost if it is provided.
+ * Or the default regmove->GR2VR will be returned.
+ */
Please still remove the leading '*' of the comment. The series is OK with that
fixed. Thanks for you
On 5/6/25 1:56 PM, Tomasz Kaminski wrote:
On Tue, May 6, 2025 at 1:39 PM Luc Grosheintz
wrote:
On 5/6/25 11:28 AM, Tomasz Kaminski wrote:
For better reference, here is illustration of the design I was thinking
about:
https://godbolt.org/z/7aTcM8fz4
I would also consider having left_mappin
On Tue, 6 May 2025 at 13:06, Tomasz Kaminski wrote:
>
>
>
> On Tue, May 6, 2025 at 1:59 PM Jonathan Wakely wrote:
>>
>> On 05/05/25 16:45 +0200, Tomasz Kamiński wrote:
>> >Use `__unicode::_field_width` to compute the field width of the output when
>> >writting
>> >the formatted output for std::c
From: Pan Li
Add asm dump check and for vec_duplicate + vadd.vv combine to vadd.vx.
The late-combine will not take action when GR2VR cost is 15.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec
From: Pan Li
Add asm dump check and run test for vec_duplicate + vadd.vv combine
to vadd.vx. Introduce new folder to hold all related testcases.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/rvv.ex
On Tue, May 6, 2025 at 2:07 PM Jonathan Wakely wrote:
> On Tue, 6 May 2025 at 12:42, Tomasz Kaminski wrote:
> >
> >
> >
> > On Tue, May 6, 2025 at 1:34 PM Jonathan Wakely
> wrote:
> >>
> >> On 05/05/25 14:44 +0200, Tomasz Kamiński wrote:
> >> >This patch provides an equality operator between _S
Dimitar Dimitrov writes:
> After r16-160-ge6f89d78c1a752, late_combine2 started transforming the
> following RTL for pru-unknown-elf:
>
> (insn 3949 3948 3951 255 (set (reg:QI 56 r14.b0 [orig:1856 _619 ] [1856])
> (and:QI (reg:QI 1 r0.b1 [orig:1855 _201 ] [1855])
> (const
From: Pan Li
This patch would like to introduce the combine of vec_dup + vadd.vv into
vadd.vx on the cost value of GR2VR. The late-combine will take place if
the cost of GR2VR is zero, or reject the combine if non-zero like 1, 15
in test. A helper function get_gr2vr_cost is introduced to make s
From: Pan Li
Add asm dump check and for vec_duplicate + vadd.vv combine to vadd.vx.
The late-combine will not take action when GR2VR cost is 1.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/
On Tue, 6 May 2025 at 12:42, Tomasz Kaminski wrote:
>
>
>
> On Tue, May 6, 2025 at 1:34 PM Jonathan Wakely wrote:
>>
>> On 05/05/25 14:44 +0200, Tomasz Kamiński wrote:
>> >This patch provides an equality operator between _Sink_iter and
>> >default_sentinel,
>> >that returns true, if any further
From: Pan Li
During investigate the combine from vec_dup and vop.vv into
vop.vx, we need to depend on the cost of the insn operate
from the gpr to vr, for example, vadd.vx. Thus, for better
control and test, we introduce a new option, aka below:
--param=gpr2vr-cost=
To specific the cost value
From: Pan Li
This patch would like to combine the vec_duplicate + vadd.vv to the
vadd.vx. From example as below code. The related pattern will depend
on the cost of vec_duplicate from GR2VR, it will:
* The pattern matching will be active by default.
* The cost of GR2VR will be added to the tot
From: Pan Li
After we introduced the --param=gpr2vr-cost option to set the cost
value of when operation act from gpr to vr, we would like to introduce
a new helper function to get the cost of gp2vr. And then make sure
all reference to gr2vr should go this helper function.
The helper function wi
On Mon, 5 May 2025 at 19:50, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/15?
OK for trunk and 15.
>
> -- >8 --
>
> This std::expected friend operator== is prone to constraint recursion
> after CWG 2369 for the same reason as basic_const_iterator's compari
On Tue, May 6, 2025 at 1:59 PM Jonathan Wakely wrote:
> On 05/05/25 16:45 +0200, Tomasz Kamiński wrote:
> >Use `__unicode::_field_width` to compute the field width of the output
> when writting
> >the formatted output for std::chrono::types. This applies both to
> characters copied
> >from format
On 5/6/25 7:18 AM, Jakub Jelinek wrote:
Hi!
While the r15-521 commit was meant for trunk only:
On Thu, Apr 25, 2024 at 11:30:48AM -0400, Jason Merrill wrote:
Hmm, maybe maybe_clone_body shouldn't clear DECL_SAVED_TREE for aliases, but
rather set it to some stub like void_node?
Though with all
On 05/05/25 16:45 +0200, Tomasz Kamiński wrote:
Use `__unicode::_field_width` to compute the field width of the output when
writting
the formatted output for std::chrono::types. This applies both to characters
copied
from format string, and one produced by localized formatting.
We also use _St
On Mon, May 05, 2025 at 06:51:31PM +0300, Dimitar Dimitrov wrote:
> After r16-160-ge6f89d78c1a752, late_combine2 started transforming the
> following RTL for pru-unknown-elf:
>
> (insn 3949 3948 3951 255 (set (reg:QI 56 r14.b0 [orig:1856 _619 ] [1856])
> (and:QI (reg:QI 1 r0.b1 [orig:1
On Tue, May 6, 2025 at 1:39 PM Luc Grosheintz
wrote:
>
> On 5/6/25 11:28 AM, Tomasz Kaminski wrote:
> > For better reference, here is illustration of the design I was thinking
> > about:
> > https://godbolt.org/z/7aTcM8fz4
> > I would also consider having left_mapping_base to accept padding, wher
On Tue, May 6, 2025 at 1:34 PM Jonathan Wakely wrote:
> On 05/05/25 14:44 +0200, Tomasz Kamiński wrote:
> >This patch provides an equality operator between _Sink_iter and
> default_sentinel,
> >that returns true, if any further writes to the _Sink_iter and underlying
> _Sink,
> >will be discared,
On 5/6/25 11:28 AM, Tomasz Kaminski wrote:
For better reference, here is illustration of the design I was thinking
about:
https://godbolt.org/z/7aTcM8fz4
I would also consider having left_mapping_base to accept padding, where
layout_left uses left_mapping_base.
Thank you for all the help! I
On Tue, May 06, 2025 at 01:28:16PM +0200, Jørgen Kvalsvik wrote:
> Mostly because it would make the print more noisy, and because by the time
> we have 4 billion prime paths, all systems would probably already have been
> crushed under the load of computing them.
>
> I'm happy to change to fmt_siz
On 05/05/25 14:44 +0200, Tomasz Kamiński wrote:
This patch provides an equality operator between _Sink_iter and
default_sentinel,
that returns true, if any further writes to the _Sink_iter and underlying _Sink,
will be discared, and thus can be omitted. This operator is implemented in terms
new
On Wed, 16 Apr 2025, Richard Biener wrote:
> The following tries to address us BB vectorizing a loop body that
> swaps consecutive elements of an array like for bubble-sort. This
> causes the vector store in the previous iteration to fail to forward
> to the vector load in the current iteration s
Mostly because it would make the print more noisy, and because by the
time we have 4 billion prime paths, all systems would probably already
have been crushed under the load of computing them.
I'm happy to change to fmt_size_t everywhere, of course, but the use of
size_t for pathno was my own
On Tue, May 06, 2025 at 01:17:54PM +0200, Richard Biener wrote:
> On Tue, 6 May 2025, Jørgen Kvalsvik wrote:
>
> > Some systems don't support the %zu format modifier for size_t, such as
> > hppa64-hp-hpux. We don't really need the full width of size_t for
> > printing the number of prime paths as
Hi!
While the r15-521 commit was meant for trunk only:
On Thu, Apr 25, 2024 at 11:30:48AM -0400, Jason Merrill wrote:
> Hmm, maybe maybe_clone_body shouldn't clear DECL_SAVED_TREE for aliases, but
> rather set it to some stub like void_node?
>
> Though with all these changes, it's probably better
On Tue, 6 May 2025, Jørgen Kvalsvik wrote:
> Some systems don't support the %zu format modifier for size_t, such as
> hppa64-hp-hpux. We don't really need the full width of size_t for
> printing the number of prime paths as path counts of those sizes
> would've already blown up the machine. For pr
Some systems don't support the %zu format modifier for size_t, such as
hppa64-hp-hpux. We don't really need the full width of size_t for
printing the number of prime paths as path counts of those sizes
would've already blown up the machine. For printing the vector size we
can use the formatting dir
Never mind, it seems someone already beat me to it. Sorry for all the mess!
best regards,
Julian
On Tue, May 6, 2025 at 5:11 PM Sam James wrote:
>
> Julian Waters writes:
>
> > gcc bootstrap works on my end pretty well, but you know what they say,
> > no one likes an "It works on my device" dev
Hi!
Here is the 14 branch version of the PR120061 fix I've just posted
for 16/15.
The differences from the earlier patch are all caused by the
32-bit location_t on the branch instead of 64-bit location_t that
16/15 has.
So, it needs 1 << whatever instead of loc_one << whatever in the
sources, and
1 - 100 of 147 matches
Mail list logo
