Hi Damian, hi Steve,
enabling coarray-support by default has implications we need to consider. The
memory footprint of a coarray enabled program is larger than the one of a
non-coarray one. This is simply because the coarray token needs to be stored
somewhere.
Furthermore, I just yesterday figure
> Am 25.06.2025 um 07:32 schrieb H.J. Lu :
>
> On Wed, Jun 25, 2025 at 1:11 PM Hongtao Liu wrote:
>>
>>> On Wed, Jun 25, 2025 at 1:06 PM H.J. Lu wrote:
>>>
>>> -mtune=intel is used to generate a single binary to run well on both big
>>> core and small core, similar to hybrid CPUs. Update
The `far_branch` attribute only ever takes the values 0 or 1, so make it
a `no/yes` valued string attribute instead.
gcc/ChangeLog:
* config/aarch64/aarch64.md (far_branch): Replace 0/1 with
no/yes.
(aarch64_bcond): Handle rename.
(aarch64_cbz1): Likewise.
On Tue, 24 Jun 2025, Jan Hubicka wrote:
> > On Sun, 22 Jun 2025, Jan Hubicka wrote:
> >
> > > Hi,
> > > auto-fdo is currently confused by a fact that all inlined functions get
> > > locators with 0 discriminator, so it is not bale to distinguish multiple
> > > inlined calls from single line.
> >
On Tue, 24 Jun 2025, Jan Hubicka wrote:
> > > That is why I checked for loc != UNKNOWN_LOCATION. I did not expect
> > > UNKNOWN_LOCATION to have discriminators. What they are good for?
> >
> > I have no idea, this was simply a defensive review where it's no
> > longer obvious that inlined_functi
On Mon, Jun 23, 2025 at 4:53 PM Hongtao Liu wrote:
>
> On Mon, Jun 23, 2025 at 4:45 PM H.J. Lu wrote:
> >
> > On Mon, Jun 23, 2025 at 4:10 PM H.J. Lu wrote:
> > >
> > > On Mon, Jun 23, 2025 at 3:11 PM Hongtao Liu wrote:
> > > >
> > > > On Thu, Jun 19, 2025 at 10:25 AM H.J. Lu wrote:
> > > > >
On 6/24/25 10:16 AM, Nathaniel Shead wrote:
On Tue, Jun 24, 2025 at 01:03:53PM +0200, Jakub Jelinek wrote:
Hi!
The following patch implements the P3618R0 paper by tweaking pedwarn
condition, adjusting pedwarn wording, adjusting one testcase and adding 4
new ones. The paper was voted in as DR,
On Fri, May 23, 2025 at 1:56 PM H.J. Lu wrote:
>
> Add preserve_none attribute which is similar to no_callee_saved_registers
> attribute, except on x86-64, r12, r13, r14, r15, rdi and rsi registers are
> used for integer parameter passing. This can be used in an interpreter
> to avoid saving/rest
On Wed, Jun 25, 2025 at 1:11 PM Hongtao Liu wrote:
>
> On Wed, Jun 25, 2025 at 1:06 PM H.J. Lu wrote:
> >
> > -mtune=intel is used to generate a single binary to run well on both big
> > core and small core, similar to hybrid CPUs. Update -mtune=intel to tune
> > for Diamond Rapids and Clearwate
On Wed, Jun 25, 2025 at 1:06 PM H.J. Lu wrote:
>
> -mtune=intel is used to generate a single binary to run well on both big
> core and small core, similar to hybrid CPUs. Update -mtune=intel to tune
> for Diamond Rapids and Clearwater Forest, instead of Silvermont.
>
> PR target/120815
> * common
PING³
June 2, 2025 Tobias Burnus wrote:
Tobias Burnus wrote:
PING²
On May 12, 2025, Tobias Burnus wrote:
PING.
There is actually a minor update as meanwhile CUDA 12.8 was
released that added the 'f' suffix and sm_103 and sm_121.
Still, the pattern remains the same; hence, a normal PING.
On
-mtune=intel is used to generate a single binary to run well on both big
core and small core, similar to hybrid CPUs. Update -mtune=intel to tune
for Diamond Rapids and Clearwater Forest, instead of Silvermont.
PR target/120815
* common/config/i386/i386-common.cc (processor_alias_table):
Replace
Hi Mike,
On 24/06/25 10:03 am, Michael Meissner wrote:
> On Fri, Jun 20, 2025 at 01:19:45PM -0500, Segher Boessenkool wrote:
>> Hi!
>>
>> On Fri, Jun 20, 2025 at 10:38:30PM +0530, Surya Kumari Jangala wrote:
>>> On 14/06/25 2:13 pm, Michael Meissner wrote:
This is patch #4 of 4 to add -mcpu=f
> -Original Message-
> From: Uros Bizjak
> Sent: Wednesday, June 25, 2025 12:53 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Cui, Lili
> Subject: [committed] i386: Convert LEA stack adjust insn to SUB when
> FLAGS_REG is dead
>
> ADD/SUB is faster than LEA for most processors. Also, there are
On 6/23/25 9:12 PM, Ciyan Pan wrote:
From: panciyan
This patch adds testcase for form2, as shown below:
T __attribute__((noinline)) \
sat_s_add_imm_##T##_fmt_2##_##INDEX (T x)\
{
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/arch-rvb23s.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rva23s64 -mabi=lp64d" } */
rva23s64 -> rvb23s64
Thank you for pointing this out.
On 6/24/25 3:38 AM, Jiawei wrote:
This patch adds support for the RISC-V Pr
On Mon, Jan 20, 2025 at 02:59:44PM +0100, Stefan Schulze Frielinghaus wrote:
> On Mon, Jan 20, 2025 at 02:46:40PM +0100, Richard Biener wrote:
> > On Mon, Jan 20, 2025 at 11:04 AM Stefan Schulze Frielinghaus
> > wrote:
> > >
> > > gcc/ChangeLog:
> >
> > Interesting - I can't find anything about t
Richard Biener writes:
> On Tue, 24 Jun 2025, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> > On Tue, 24 Jun 2025, Richard Sandiford wrote:
>> >
>> >> Tamar Christina writes:
>> >> > store_bit_field_1 has an optimization where if a target is not a memory
>> >> > operand
>> >> > and th
On Tue, 24 Jun 2025, Jonathan Wakely wrote:
> On Tue, 24 Jun 2025 at 03:20, Patrick Palka wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> >
> > -- >8 --
> >
> > When checking __is_complete_or_unbounded on a reference to incomplete
> > type, we overeagerly try to insta
Erroneously changed when converting dwarf2out to the new inchash
interface (f768061c4c0). The other hash_loc_operands calls
were left in place.
gcc/Changelog:
* dwarf2out.cc (hash_loc_operands): do not hash pointer
---
gcc/dwarf2out.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Tue, 24 Jun 2025 at 08:39, Tomasz Kamiński wrote:
>
> For month_day we incorrectly reported day information to be available, which
> lead
> to format_error being thrown from the call to formatter::format at runtime,
> instead
> of making call to format ill-formed.
>
> The included test cover
On 6/24/25 3:38 AM, Jiawei wrote:
This patch adds support for the RISC-V Profiles RVA23S64 and RVB23S64.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: New Profiles.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/arch-rva23s.c: New test.
* gcc.target/riscv/arch-
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, June 24, 2025 9:58 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Sandiford
>
> Subject: Re: [PATCH]middle-end: Fix store_bit_field expansions of vector
> constructors [PR120718]
>
> On Tue, 24 Jun 2025,
On Tue, 24 Jun 2025, Tamar Christina wrote:
> store_bit_field_1 has an optimization where if a target is not a memory
> operand
> and the entire value is being set from something larger we can just wrap a
> subreg around the source and emit a move.
>
> For vector constructors this is however pro
On Tue, Jun 24, 2025 at 9:38 AM Tomasz Kamiński wrote:
> For month_day we incorrectly reported day information to be available,
> which lead
> to format_error being thrown from the call to formatter::format at
> runtime, instead
> of making call to format ill-formed.
>
> The included test cover m
> > On Fri, May 23, 2025 at 2:31 PM Alexander Monakov
> > wrote:
> > >
> > > In PR 105965 we accepted a request to form FMA instructions when the
> > > source code is using a narrow generic vector that contains just one
> > > element, corresponding to V1SF or V1DF mode, while the backend does not
On Tue, Jun 24, 2025 at 09:49:01AM +0200, Juergen Christ wrote:
> Some patterns that are detected by the autovectorizer can be supported by
> s390. Add expanders such that autovectorization of these patterns works.
>
> Bootstrapped and regtested on s390. Ok for trunk?
>
> gcc/ChangeLog:
>
>
> On Jun 24, 2025, at 03:26, Richard Biener wrote:
>
> On Mon, Jun 23, 2025 at 4:44 PM Qing Zhao wrote:
>>
>> gcc/ChangeLog:
>>
>>* tree-object-size.cc (access_with_size_object_size): Update comments
>>for pointers with .ACCESS_WITH_SIZE.
>>(collect_object_sizes_for):
Commit the test file `mask_load_2.c` before the vectorisation analysis
is changed, so that the changes in codegen are more obvious in the next
commit.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/sve/mask_load_2.c: New test.
---
.../gcc.target/aarch64/sve/mask_load_2.c | 23
This cleans the rest of vectorizable_load from non-SLP
* tree-vect-stmts.cc (vectorizable_load): Step 2.
---
gcc/tree-vect-stmts.cc | 185 +++--
1 file changed, 50 insertions(+), 135 deletions(-)
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-
On Tue, Jun 24, 2025 at 10:33:01PM +0200, Jakub Jelinek wrote:
> On Tue, Jun 24, 2025 at 08:25:33PM +0200, Jakub Jelinek wrote:
> > > > know enough about dynamic_cast and cxx_eval_dynamic_cast_fn
> > > > to figure out what needs to change there. It is hint -2 that
> > > > fails, not hint -1.
> > >
Hi Richard,
> OK.
>
> Thanks,
> Richard.
Thanks for the quick review! Could you please help me merge this patch? I'll
post the rest of the original patch soon.
Thanks,
Yuao
On Tue, 24 Jun 2025, Jason Merrill wrote:
> On 6/23/25 5:41 PM, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
> >
> > -- >8 --
> >
> > We were erroring because the TEMPLATE_DECL of the existing partial
> > specialisation has an undeduced return ty
Ok for master? Bootstrapped on x86_64 gnu/linux
regards,
Gaius
---
[PR modula2/120761] GM2_FOR_BUILD is not substituted in the toplevel Makefile
This patch removes the unused GM2_FOR_BUILD in the toplevel Makefile.tpl
and removes any reference to GM2_FOR_BUILD in libgm2. The only reference
Andrew Stubbs:
You still seem to have the unrelated preload bits in this patch, but
other than that, this looks fine.
Now committed with that one removed: r16-1661-g750bc2899844d6
In principle, we could use %Gn everywhere and use the address space
from the MEM to determine which cache to use,
Pushed.
* gcc-16/criteria.html: Mention Modula-2, Cobol and Rust.
Order alphabetically.
---
htdocs/gcc-16/criteria.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/gcc-16/criteria.html b/htdocs/gcc-16/criteria.html
index 6bca431a..85fa39cd 100644
-
Dear all,
here's an obvious fix for a recent regression: substring offset
calculations used a wrong type that crashed in gimplification.
Andre basically OK'ed it in the PR, but here it is nevertheless.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 5bc92717b804483a17dd
Hi all,
this series of patches (six in total) adds a new coarray backend library to
libgfortran. The library uses shared memory and processes to implement
running multiple images on the same node. The work is based on work started by
Thomas and Nicolas Koenig. No changes to the gfortran compile
On 6/24/25 6:09 AM, Andre Vehreschild wrote:
Hi all,
this series of patches (six in total) adds a new coarray backend library to
libgfortran. The library uses shared memory and processes to implement
running multiple images on the same node. The work is based on work started by
Thomas and Nico
Richard Biener writes:
> On Tue, 24 Jun 2025, Richard Sandiford wrote:
>> Richard Biener writes:
>> > On Tue, 24 Jun 2025, Richard Sandiford wrote:
>> >> (from h8300). This is also why simplify_gen_subreg has:
>> >>
>> >> if (GET_CODE (op) == SUBREG
>> >> || GET_CODE (op) == CONCAT
>> >
On 6/18/25 7:55 AM, Paul-Antoine Arras wrote:
On 17/06/2025 18:19, Jeff Law wrote:
On 6/17/25 7:15 AM, Paul-Antoine Arras wrote:
This is part of my vector-scalar FMA series. See:
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/679513.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-J
On 6/24/25 2:25 PM, Jakub Jelinek wrote:
On Tue, Jun 24, 2025 at 11:57:01AM -0400, Jason Merrill wrote:
The two other errors on the testcase are expectedly gone with C++26,
but the last one remains. The problem is that when parsing nm3.a
inside of mutable_subobjects()::A::f()
build_class_member
On 6/23/25 5:41 PM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
-- >8 --
We were erroring because the TEMPLATE_DECL of the existing partial
specialisation has an undeduced return type, but the imported
declaration did not.
The root cause is simila
Hi Andre,
All six patches require git apply --whitespace=fix --ignore-space-change <
~/prs/Shared_Memory/pr88076_v1_x.patch to apply.
The build fails with:
Makefile:3848: caf/.deps/caf_error.Plo: No such file or directory
make[2]: *** No rule to make target 'caf/.deps/caf_error.Plo'. Stop.
make
On Fri, Jun 20, 2025 at 08:23:01PM +0200, Juergen Christ wrote:
> Also provide the vec_extract patterns for floats on pre-z13 machines
> to prevent ICEing in those cases.
>
> Bootstrapped and regtested on s390.
Ok.
Thanks,
Stefan
>
> gcc/ChangeLog:
>
> * config/s390/vector.md (VF): Don'
On Mon, Jun 23, 2025, 6:09 PM Jeff Law wrote:
>
>
> On 6/7/25 1:04 AM, Andrew Pinski wrote:
> > Currently expand_constructor when it comes to BLKmode types, we store out
> > the constructor to memory. But for the zero case, we could just use
> `const_int 0`
> > instead for types who are less than
On Tue, Jun 24, 2025 at 08:25:33PM +0200, Jakub Jelinek wrote:
> > > know enough about dynamic_cast and cxx_eval_dynamic_cast_fn
> > > to figure out what needs to change there. It is hint -2 that
> > > fails, not hint -1.
> >
> > Yes, this is a -2 case because C does not derive from B.
> >
> > H
And convert a pointer reference with counted_by attribute to
.ACCESS_WITH_SIZE.
For example:
struct PP {
size_t count2;
char other1;
char *array2 __attribute__ ((counted_by (count2)));
int other2;
} *pp;
specifies that the "array2" is an array that is pointed by the
pointer field, and
Current array bound checker only instruments ARRAY_REF, and the INDEX
information is the 2nd operand of the ARRAY_REF.
When extending the array bound checker to pointer references with
counted_by attributes, the hardest part is to get the INDEX of the
corresponding array ref from the offset comput
yeah, sure. Its wasted memory. If we ever need it fro anything, it
could be added back in.
I'll add it to my next commit.
Thanks
Andrew
On 6/23/25 18:21, Martin Jambor wrote:
Hello,
On Thu, May 23 2024, Andrew MacLeod wrote:
This patch provides a basic oracle which doesn't do anything, bu
On Mon, Jun 23, 2025 at 07:30:51PM +0530, Surya Kumari Jangala wrote:
> Hi Mike,
>
> On 14/06/25 2:07 pm, Michael Meissner wrote:
> > This is patch #1 of 4 that adds the support that can be used in developing
> > GCC
> > support for future PowerPC processors.
>
> Please reword the commit message
On Tue, 24 Jun 2025, Richard Biener wrote:
> On Tue, Jun 24, 2025 at 1:18 PM Alexander Monakov wrote:
> >
> > > > On Fri, May 23, 2025 at 2:31 PM Alexander Monakov
> > > > wrote:
> > > > >
> > > > > In PR 105965 we accepted a request to form FMA instructions when the
> > > > > source code is
libstdc++-v3/ChangeLog:
* testsuite/std/time/format/precision.cc: New tests.
---
Merging additional tests I have added, when working on erasing chrono
types. Testing on x86_64-linux.
OK for trunk when test passes?
.../testsuite/std/time/format/precision.cc| 64 +--
1
Am 24.06.25 um 21:11 schrieb Steve Kargl:
On Tue, Jun 24, 2025 at 09:00:46PM +0200, Harald Anlauf wrote:
here's an obvious fix for a recent regression: substring offset
calculations used a wrong type that crashed in gimplification.
Andre basically OK'ed it in the PR, but here it is nevertheless
On Tue, Jun 24, 2025 at 09:00:46PM +0200, Harald Anlauf wrote:
>
> here's an obvious fix for a recent regression: substring offset
> calculations used a wrong type that crashed in gimplification.
> Andre basically OK'ed it in the PR, but here it is nevertheless.
>
> Regtested on x86_64-pc-linux-g
On Tue, Jun 24, 2025 at 11:57:01AM -0400, Jason Merrill wrote:
> > The two other errors on the testcase are expectedly gone with C++26,
> > but the last one remains. The problem is that when parsing nm3.a
> > inside of mutable_subobjects()::A::f()
> > build_class_member_access_expr calls build_bas
Damian,
I submitted a patch a long time ago to make -fcoarray=single the
default behavior. The patch made -fcoarray=none a NOP. With
inclusion of a shmem implementation of the runtime parts, this
might be the way to go. I'll leave that decision to Andre, Thomas,
and Nicolas.
I believe that the
This patch series adds support for the CMPBR extension. It includes the
new `+cmpbr` option and rules to generate the new instructions when
lowering conditional branches.
Changelog:
* v6:
- Correct the constraint string for immediate operands.
- Drop the commit for adding `%j` format specifier
insn_info::has_been_deleted () is documented to return true if an
instruction is deleted. Such instructions have their `volatile` bit set,
which can be tested via rtx_insn::deleted ().
The current condition for insn_info::has_been_deleted () is:
* m_rtl is not NULL: this can't happen as no member
ADD/SUB is faster than LEA for most processors. Also, there are
several peephole2 patterns available that convert prologue esp
subtractions to pushes (at the end of i386.md). These process only
patterns with flags reg clobber, so they are ineffective
with clobber-less stack ptr adjustments, introdu
Move the rules for CBZ/TBZ to be above the rules for
CBB/CBH/CB. We want them to have higher priority
because they can express larger displacements.
gcc/ChangeLog:
* config/aarch64/aarch64.md (aarch64_cbz1): Move
above rules for CBB/CBH/CB.
(*aarch64_tbz1): Likewise.
gcc/
Give the `define_insn` rules used in lowering `cbranch4` to RTL
more descriptive and consistent names: from now on, each rule is named
after the AArch64 instruction that it generates. Also add comments to
document each rule.
gcc/ChangeLog:
* config/aarch64/aarch64.md (condjump): Rename to
Add rules for lowering `cbranch4` to CBB/CBH/CB when
CMPBR extension is enabled.
gcc/ChangeLog:
* config/aarch64/aarch64-protos.h (aarch64_cb_rhs): New function.
* config/aarch64/aarch64.cc (aarch64_cb_rhs): Likewise.
* config/aarch64/aarch64.md (cbranch4): Rename to ...
The rules for conditional branches were spread throughout `aarch64.md`.
Group them together so it is easier to understand how `cbranch4`
is lowered to RTL.
gcc/ChangeLog:
* config/aarch64/aarch64.md (condjump): Move.
(*compare_condjump): Likewise.
(aarch64_cb1): Likewise.
Make the formatting of the RTL templates in the rules for branch
instructions more consistent with each other.
gcc/ChangeLog:
* config/aarch64/aarch64.md (cbranch4): Reformat.
(cbranchcc4): Likewise.
(condjump): Likewise.
(*compare_condjump): Likewise.
(aar
On Tue, Jun 24, 2025 at 4:28 PM Alexander Monakov wrote:
>
> > > Thanks! Any thoughts on the other patch in the thread, about flipping
> > > -ffp-contract from =fast to =on?
> >
> > I can't find this mail, not in spam either, but I'm OK with such change if
> > it
> > comes with test coverage.
>
>
On 6/24/25 7:22 AM, Jakub Jelinek wrote:
Hi!
The following patch attempts to implement the C++26
P3533R2 - constexpr virtual inheritance
paper.
The changes include not rejecting it for C++26, tweaking the
error wording to show that it is valid in C++26, adjusting
synthesized_method_walk not to m
On Tue, 24 Jun 2025, Richard Sandiford wrote:
> Tamar Christina writes:
> > store_bit_field_1 has an optimization where if a target is not a memory
> > operand
> > and the entire value is being set from something larger we can just wrap a
> > subreg around the source and emit a move.
> >
> > For
process_uses_of_deleted_def seems to have been written on the assumption
that non-degenerate phis would be explicitly deleted by an insn_change,
and that the function therefore only needed to delete degenerate phis.
But that was inconsistent with the rest of the code, and wouldn't be
very convenien
> I'd say we want to fix these kind of things before switching the default. Can
> you file bugreports for the distinct issues you noticed when adjusting the
> testcases?
Sure, filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120808 for the most
frequently hit issue on x86 for now.
> I suppose
This patch adds the OpenACC routines acc_attach and acc_detach.
However, in order to avoid the generation of a temporary, which
breaks this feature, a special case had to be added to
gfc_trans_call.
Otherwise, I think it completes the Fortran additions of existing
C/C++ functions, by adding this
On 23/06/2025 22:39, Tobias Burnus wrote:
This is more based on documentation reading that on testing
as still only limited MI300 testing has been done and seemingly
this code does not usually get touched.
MI300's "9.1.10 Memory Scope and Temporal Control" distinguishes
between scalar memory (9.
This cleans the rest of vectorizable_load from non-SLP, propagates
out ncopies == 1, and elides loops from 0 to ncopies.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vect-stmts.cc (vectorizable_load): Remove non-SLP
paths and propagate out ncopies == 1.
---
On Tue, 24 Jun 2025 at 13:53, Patrick Palka wrote:
>
> On Tue, 24 Jun 2025, Jonathan Wakely wrote:
>
> > On Tue, 24 Jun 2025 at 03:20, Patrick Palka wrote:
> > >
> > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> > >
> > > -- >8 --
> > >
> > > When checking __is_complete_or_unbou
> > Thanks! Any thoughts on the other patch in the thread, about flipping
> > -ffp-contract from =fast to =on?
>
> I can't find this mail, not in spam either, but I'm OK with such change if it
> comes with test coverage.
Ouch, let me reproduce it below. About test coverage, I'm not exactly sure w
Re-indent elided loop bodies
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Will squash, repost and push if all OK.
Richard.
* tree-vect-stmts.cc (vectorizable_load):
---
gcc/tree-vect-stmts.cc | 1686
1 file changed, 831 inserti
Propagate out ncopies == 1.
* tree-vect-stmts.cc (vectorizable_load): Step 3.
---
gcc/tree-vect-stmts.cc | 46 +++---
1 file changed, 12 insertions(+), 34 deletions(-)
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index eca7e70ad
Elide loops over ncopies.
* tree-vect-stmts.cc (vectorizable_load):
---
gcc/tree-vect-stmts.cc | 54 --
1 file changed, 20 insertions(+), 34 deletions(-)
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index 2efa34c..717d4694b88 10
This cleans the rest of vectorizable_load from non-SLP
* tree-vect-stmts.cc (vectorizable_load): Step 1.
---
gcc/tree-vect-stmts.cc | 62 +-
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts
* tree-vect-stmts.cc (vectorizable_load): One more tricky
!SLP path removal.
---
gcc/tree-vect-stmts.cc | 40 +---
1 file changed, 1 insertion(+), 39 deletions(-)
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index c5fe7879d5a..ec
The current implementation of this function is somewhat difficult to
understand, as it uses a direct break statement within the for loop,
rendering the loop meaningless. Additionally, during the Coverity check
on the for loop, a warning appeared: "unreachable: Since the loop
increment ix++; is unre
The function `vect_check_gather_scatter` requires the `base` of the load
to be loop-invariant and the `off`set to be not loop-invariant. When faced
with a scenario where `base` is not loop-invariant, instead of giving up
immediately we can try swapping the `base` and `off`, if `off` is
actually loo
On Tue, Jun 24, 2025 at 01:03:53PM +0200, Jakub Jelinek wrote:
> Hi!
>
> The following patch implements the P3618R0 paper by tweaking pedwarn
> condition, adjusting pedwarn wording, adjusting one testcase and adding 4
> new ones. The paper was voted in as DR, so it isn't guarded on C++ version.
>
Hi!
The following patch attempts to implement the C++26
P3533R2 - constexpr virtual inheritance
paper.
The changes include not rejecting it for C++26, tweaking the
error wording to show that it is valid in C++26, adjusting
synthesized_method_walk not to make synthetized cdtors non-constexpr
just b
On Tue, 2025-06-24 at 15:16 +0200, Marc Poulhiès wrote:
> Having both an enum and a variable with the same name triggers an
> error with
> gcc 5.
>
> ChangeLog:
>
> * c/gcc/diagnostic-state-to-dot.cc
> (get_color_for_dynalloc_state):
> Rename argument dynalloc_state to dynalloc_st.
>
On Tue, Jun 24, 2025 at 1:53 PM Alexander Monakov wrote:
>
>
>
> On Tue, 24 Jun 2025, Richard Biener wrote:
>
> > On Tue, Jun 24, 2025 at 1:18 PM Alexander Monakov
> > wrote:
> > >
> > > > > On Fri, May 23, 2025 at 2:31 PM Alexander Monakov
> > > > > wrote:
> > > > > >
> > > > > > In PR 105965
Hi all,
this small patch unifies handling of the optional team argument to
failed_/stopped_images(). I did not find a ticket for this, but stumbled over
it while implementing caf_shmem.
Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Regards,
Andre
--
Andre Vehreschild * Kreu
On Tue, Jun 24, 2025 at 11:31 AM Yuao Ma wrote:
>
> Hi Richard,
>
> > OK.
> >
> > Thanks,
> > Richard.
>
> Thanks for the quick review! Could you please help me merge this patch? I'll
> post the rest of the original patch soon.
I pushed it.
Richard.
> Thanks,
> Yuao
>
Having both an enum and a variable with the same name triggers an error with
gcc 5.
ChangeLog:
* c/gcc/diagnostic-state-to-dot.cc (get_color_for_dynalloc_state):
Rename argument dynalloc_state to dynalloc_st.
(add_title_tr): Rename argument style to styl.
(on_xml_n
Hi all,
this is the last patch of the mini-series. It just updates the testcases common
to coarrays in the gfortran testsuite. All tests in the
gcc/testsuite/gfortran.dg/caf directory are now also run with caf_shmem. The
test driver ensures, that no more than 8 images are used per testcase (if not
On Tue, Jun 24, 2025 at 1:26 PM H.J. Lu wrote:
>
> On Mon, Jun 23, 2025 at 4:53 PM Hongtao Liu wrote:
> >
> > On Mon, Jun 23, 2025 at 4:45 PM H.J. Lu wrote:
> > >
> > > On Mon, Jun 23, 2025 at 4:10 PM H.J. Lu wrote:
> > > >
> > > > On Mon, Jun 23, 2025 at 3:11 PM Hongtao Liu wrote:
> > > > >
>
On 2025-06-24 03:26, Richard Biener wrote:
+ /* Handle the following stmt #2 to propagate the size from the
+ stmt #1 to #3:
+ 1 _1 = .ACCESS_WITH_SIZE (_3, _4, 1, 0, -1, 0B);
+ 2 _5 = *_1;
+ 3 _6 = __builtin_dynamic_object_size
On Tue, Jun 24, 2025 at 5:39 PM Jiawei wrote:
>
> This patch adds support for the RISC-V Profiles RVA23S64 and RVB23S64.
>
> gcc/ChangeLog:
>
> * common/config/riscv/riscv-common.cc: New Profiles.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/arch-rva23s.c: New test.
>
Hi Ma Jin,
thanks for looking into this, it has been on my todo list with very low
priority since the vsetvl rewrite.
+ /* Handle case with no predecessors (including ENTRY block). */
+ if (EDGE_COUNT (b->preds) == 0)
{
- e = EDGE_PRED (b, ix);
- bitmap_copy (dst, src[e->src
On Tue, Jun 24, 2025 at 1:18 PM Alexander Monakov wrote:
>
> > > On Fri, May 23, 2025 at 2:31 PM Alexander Monakov
> > > wrote:
> > > >
> > > > In PR 105965 we accepted a request to form FMA instructions when the
> > > > source code is using a narrow generic vector that contains just one
> > > >
On Tue, 24 Jun 2025 at 12:19, Tomasz Kaminski wrote:
>
>
>
> On Tue, Jun 24, 2025 at 9:38 AM Tomasz Kamiński wrote:
>>
>> For month_day we incorrectly reported day information to be available, which
>> lead
>> to format_error being thrown from the call to formatter::format at runtime,
>> instea
On Tue, 24 Jun 2025, Richard Sandiford wrote:
> Richard Biener writes:
> > On Tue, 24 Jun 2025, Richard Sandiford wrote:
> >
> >> Richard Biener writes:
> >> > On Tue, 24 Jun 2025, Richard Sandiford wrote:
> >> >
> >> >> Tamar Christina writes:
> >> >> > store_bit_field_1 has an optimization wh
On Mon, Jun 23, 2025 at 09:51:13AM +0200, Juergen Christ wrote:
> On VXE targets, we can directly use the fp min/max instruction instead of
> calling into libm for fmin/fmax etc.
>
> Provide fmin/fmax versions also for vectors even though it cannot be
> called directly. This will be exploited wit
On Tue, 24 Jun 2025, Richard Sandiford wrote:
> Richard Biener writes:
> > On Tue, 24 Jun 2025, Richard Sandiford wrote:
> >
> >> Tamar Christina writes:
> >> > store_bit_field_1 has an optimization where if a target is not a memory
> >> > operand
> >> > and the entire value is being set from s
On Tue, 24 Jun 2025, Richard Biener wrote:
> On Tue, 24 Jun 2025, Richard Sandiford wrote:
>
> > Tamar Christina writes:
> > > store_bit_field_1 has an optimization where if a target is not a memory
> > > operand
> > > and the entire value is being set from something larger we can just wrap a
>
1 - 100 of 122 matches
Mail list logo
