>> I went through how CRC pattern is recognized via symbolic execution. My
>> feeling
>> is that adopting the same approach in this mult pattern does not resolve the
>> problem
>> that pattern sequence might be shuffled with irrelevant statements due to
>> reassoc,
>>
>>pattern_part1 + (irre
That's right. I lack the privileges to land them myself. I was told
resubmitting them was the right thing to do for patches that never got merged.
Can you apply them?
John
On Mon, Dec 8, 2025, at 6:38 PM, Joseph Myers wrote:
> I believe I already approved this in July, unless there have been ch
On Mon, Dec 8, 2025 at 9:00 PM Haochen Jiang wrote:
>
> On Linux/x86_64,
>
> fae0c626250563c1619cc10c6af18a0c4cae5a97 is the first bad commit
> commit fae0c626250563c1619cc10c6af18a0c4cae5a97
> Author: Andrew Pinski
> Date: Sat Dec 6 01:11:29 2025 -0800
>
> final_cleanup: Call make_forwarde
Hi Joseph,
> On Sun, 7 Dec 2025, Rainer Orth wrote:
>
>> The following patch has remained unreviewed for a week and a half:
>>
>> Fix PID_TYPE on 32-bit Solaris
>> https://gcc.gnu.org/pipermail/gcc-patches/2025-November/701988.html
>
> The documentation changes are OK.
thanks. What
On Linux/x86_64,
fae0c626250563c1619cc10c6af18a0c4cae5a97 is the first bad commit
commit fae0c626250563c1619cc10c6af18a0c4cae5a97
Author: Andrew Pinski
Date: Sat Dec 6 01:11:29 2025 -0800
final_cleanup: Call make_forwarders_with_degenerate_phis [PR46555]
caused
FAIL: gcc.target/i386/pr90
On 05/12/25 10:33 am, Michael Meissner wrote:
> This patch adds support for a new PowerPC cpu (future). Until it is
> announced,
> the features of future processors may be changed. These patches allow people
> to
> use the new features of processors being developed. If/when the a processor
On Tue, Dec 09, 2025 at 12:05:43AM +0800, Jason Merrill wrote:
> On 12/8/25 3:50 AM, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> >
> > -- >8 --
> >
> > Modules allow temploid friends to no longer be implicitly inline, as
> > functions defined in a
On 12/8/25 17:33, Paul Koning wrote:
On Dec 7, 2025, at 4:36 PM, Sandra Loosemore wrote:
On 12/7/25 13:18, Paul Koning wrote:
The pdp-11 changes look mostly ok but I have two questions.
1. Why did you remove -munix-asm, mdec-asm and -mgnu-asm along with -mlro from
the gccoptlist at the top
> On Dec 8, 2025, at 7:49 PM, Maciej W. Rozycki wrote:
>
> On Mon, 8 Dec 2025, Paul Koning wrote:
>
1. Why did you remove -munix-asm, mdec-asm and -mgnu-asm along with
-mlro from the gccoptlist at the top?
>>>
>>> My patch doesn't do that. :-)
>>
>> Maybe I misread the diff, but
On Mon, 8 Dec 2025, Paul Koning wrote:
> >> 1. Why did you remove -munix-asm, mdec-asm and -mgnu-asm along with
> >> -mlro from the gccoptlist at the top?
> >
> > My patch doesn't do that. :-)
>
> Maybe I misread the diff, but it says:
>
> @emph{PDP-11 Options} (@ref{PDP-11 Options})
> -@gcco
> On Dec 7, 2025, at 4:36 PM, Sandra Loosemore wrote:
>
> On 12/7/25 13:18, Paul Koning wrote:
>> The pdp-11 changes look mostly ok but I have two questions.
>> 1. Why did you remove -munix-asm, mdec-asm and -mgnu-asm along with -mlro
>> from the gccoptlist at the top?
>
> My patch doesn't d
On Mon, Dec 8, 2025 at 5:42 PM Richard Biener wrote:
>
> When we get a <= b ? b : a into ix86_expand_sse_fp_minmax we can
> swap and invert this with -ffinite-math-only to get a < b ? a : b.
>
> Bootstrap and regtest running on x86_64-unknown-linux-gnu. I've
> added a runtime testcase showing we
On Sun, 7 Dec 2025, Rainer Orth wrote:
> The following patch has remained unreviewed for a week and a half:
>
> Fix PID_TYPE on 32-bit Solaris
> https://gcc.gnu.org/pipermail/gcc-patches/2025-November/701988.html
The documentation changes are OK.
--
Joseph S. Myers
josmy...@redha
On Sun, 7 Dec 2025, John Ericson wrote:
> My goal is to be able to build libgcc cleanly in isolation --- today one
> needs to figure `make ...` misc things in the gcc subdir.
>
> Following Andrew Pinski's suggestions in
> https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689683.html, this
> com
On Sun, 7 Dec 2025, John Ericson wrote:
> Following Andrew Pinski's suggestions in
> https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689683.html, just
> use the output of:
>
>$(CC) -print-sysroot
>
> It is just used in one spot, in an AIX code-path. I just made (within
> make) a shell va
I believe I already approved this in July, unless there have been changes
or build machinery maintainer objections since then.
--
Joseph S. Myers
[email protected]
On Sat, 6 Dec 2025, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs since checking has been added to TYPE_PRECISION
> macro. check_bitfield_type_and_width is called when attributes haven't
> been applied to the bit-field decl yet and so it still has INTEGER_TYPE
> type, while at finis
On Fri, 5 Dec 2025, Qing Zhao wrote:
> The first argument of the call to .ACCESS_WITH_SIZE includes
> "c_maybe_const_expr" which should not be passed to gimplifier.
>
> Before passing the expression as the first argument to the call to
> .ACCESS_WITH_SIZE, c_fully_fold should be called on this ex
On Fri, 5 Dec 2025, Qing Zhao wrote:
> > On Dec 4, 2025, at 18:43, Joseph Myers wrote:
> >
> > On Thu, 4 Dec 2025, Qing Zhao wrote:
> >
> >> However, where should we call the “verify_counted_by_attribute” for the
> >> above cases?
> >>
> >> Looks like that inside “finish_struct” is not the co
On Mon, Dec 8, 2025 at 2:30 PM Andrew Pinski
wrote:
>
> On Mon, Dec 8, 2025 at 4:18 AM Richard Biener
> wrote:
> >
> > On Mon, Dec 8, 2025 at 1:17 PM Richard Biener
> > wrote:
> > >
> > > On Sat, Dec 6, 2025 at 8:39 PM Andrew Pinski
> > > wrote:
> > > >
> > > > This fixes a regression introduce
On Mon, Dec 8, 2025 at 4:18 AM Richard Biener
wrote:
>
> On Mon, Dec 8, 2025 at 1:17 PM Richard Biener
> wrote:
> >
> > On Sat, Dec 6, 2025 at 8:39 PM Andrew Pinski
> > wrote:
> > >
> > > This fixes a regression introduced with r16-5258-g1d8e2d51e5c5cb.
> > > With GCC 12+, we would not merge for
The submdspan feature is complete and this commit sets the feature
testing macros accordingly. Also makes the feature testing macro
submdspan depend on constant_wrapper.
Also changes the value of the internal feature testing macro for padded
layouts to 202403.
libstdc++-v3/ChangeLog:
* i
Implements submdspan for layout_right_padded as described in P3663.
PR libstdc++/110352
libstdc++-v3/ChangeLog:
* include/std/mdspan (layout_right_padded::submdspan_mapping):
New friend method.
* testsuite/23_containers/mdspan/submdspan/selections/right_padded_1.c
Adds submdspan_mapping for layout_right as described in P3663.
PR libstdc++/110352
libstdc++-v3/ChangeLog:
* include/std/mdspan (layout_right::mapping::submdspan_mapping): New
friend function.
* testsuite/23_containers/mdspan/submdspan/selections/right.cc:
Add submdspan_mapping for layout_stride as in P3663.
PR libstdc++/110352
libstdc++-v3/ChangeLog:
* include/std/mdspan (layout_stride::mapping::submdspan_mapping): New
friend function.
* testsuite/23_containers/mdspan/submdspan/selections/stride.cc:
Instant
Implements `submdspan` and `submdspan_mapping` for layout_left as
described in P3663 (Future proofing mdspan).
When computing the offset of the submdspan, one must check that the
lower bound of the slice range isn't out-of-range. There's a few
cases when the lower bound is never out-of-range:
-
Implements submdspan for layout_left_padded as described in P3663.
PR libstdc++/110352
libstdc++-v3/ChangeLog:
* include/std/mdspan (layout_left_padded::submdspan_mapping):
New friend method.
* testsuite/23_containers/mdspan/layout_traits.h
(LayoutTraits::
Splitting the tests for submdspan triggered a compiler warning. This
commit changes the implementation of __dynamic_extents. In particular,
how the span is created. Functionally, the two are equivalent.
libstdc++-v3/ChangeLog:
* include/std/mdspan (_ExtentsStorage::_M_dynamic_extents):
Replaces v4. The important changes are:
- Split the testcase into one per layout.
- Fixed __slice_mapping and moved tests from `*_neg.cc` to
generic.cc using concepts.
- Make _BufferSize a regular parameter.
- Fixed bug in __substrides.
I didn't change the logic for _S_is_unpadded_submd
Hi,
Similar to 116149 we use the mode size of operand MODE_IDX but that
one could refer to a broadcast scalar. Use operand 3 for potential
scalar patterns instead. I hope to have caught every possible offender.
I'm not happy with the mode_idx/mode attribute/... situation. Mode and
mode_idx in
On Mon, 8 Dec 2025, Egas Ribeiro wrote:
> TARGET_EXPR represents semantic temporary objects and is deliberately
> not handled by tsubst routines, which expect syntactic templated trees.
> Add a comment and gcc_unreachable to make this explicit.
>
> gcc/cp/ChangeLog:
>
> * pt.cc (tsubst_exp
On Mon, 8 Dec 2025, Jonathan Wakely wrote:
> On Mon, 8 Dec 2025 at 15:23, Patrick Palka wrote:
> >
> >
> >
> > On Mon, 8 Dec 2025, Jonathan Wakely wrote:
> >
> > > We have __is_signed_integer and __is_unsigned_integer traits which
> > > should have been updated by r16-2190-g4faa42ac0dee2c when ma
>From 428b2c6459b7b650f1fffada6b53b6b9b40a0406 Mon Sep 17 00:00:00 2001
From: Pietro Monteiro
Date: Mon, 8 Dec 2025 13:07:08 -0500
Subject: [PATCH] Generate Algol68 frontend online docs
maintainer-scripts/ChangeLog:
* update_web_docs_git (MANUALS): Add ga68 and ga68-internals.
Signed-of
Andrew Stubbs wrote:
Maybe even adding 'requirement' on top as in:
# return 1 if the OpenMP requirement Unified Shared Memory
# is supported by at least one non-host device
This is a feature test, not a requirement at this stage, so I like it
better without.
Still, the result is based on th
TARGET_EXPR represents semantic temporary objects and is deliberately
not handled by tsubst routines, which expect syntactic templated trees.
Add a comment and gcc_unreachable to make this explicit.
gcc/cp/ChangeLog:
* pt.cc (tsubst_expr): Add TARGET_EXPR case with explanatory
comment
On 08/12/2025 12:43, Tobias Burnus wrote:
Andrew Stubbs wrote:
Unified Shared Memory does not appear to work well on gfx908, which is
why we
disabled xnack by default. For this reason it makes sense to inform
the user
as compile time, but this is causing trouble in the testsuite which
assumes
On Mon Dec 8, 2025 at 5:09 PM WET, Patrick Palka wrote:
> > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> > index 4dc8f980d0d..19729cfe13d 100644
> > --- a/gcc/cp/pt.cc
> > +++ b/gcc/cp/pt.cc
> > @@ -22300,6 +22300,10 @@ tsubst_expr (tree t, tree args, tsubst_flags_t
> > complain, tree in_decl)
> >
> -Original Message-
> From: Robin Dapp
> Sent: 08 December 2025 16:07
> To: gcc-patches
> Cc: Robin Dapp ; Tamar Christina
>
> Subject: [PATCH] optabs: Fix creation of length and bias operands.
>
> Hi,
>
> In the vec_cbranch_all/any optimization we prepare the length and bias
> operan
On Sun, 7 Dec 2025, Egas Ribeiro wrote:
> When checking a deleted explicit specialization in a SFINAE context,
> we were incorrectly selecting a partial specialization because
> resolve_nondeduced_context was calling mark_used. But resolving an
> overload to a single function (per DR 115) does no
On Sun, 30 Nov 2025, Egas Ribeiro wrote:
> TARGET_EXPR represents semantic temporary objects and is deliberately
> not handled by tsubst routines, which expect syntactic templated trees.
> Add a comment and gcc_unreachable to make this explicit.
>
> gcc/cp/ChangeLog:
>
> * pt.cc (tsubst_ex
Hi,
This implements the (cond_len_)cbranch_all/_any optabs for riscv and
adds a few tests. The patch requires a small vectorizer fix that I sent to the
mailing-list already. Without it we'll ICE when trying to legitimize operands.
Regtested on rv64gcv_zvl512b.
Regards
Robin
gcc/ChangeLog:
On 05/12/2025 13:50, Tobias Burnus wrote:
Andrew Stubbs wrote:
On 28/11/2025 12:16, Andrew Stubbs wrote:
This patch extends omp_target_is_accessible to check the actual
device status
for the memory region, on amdgcn and nvptx devices (rather than just
checking
if shared memory is enabled).
Hi,
Changes from v1:
- Always Initialize m_max_vect.
- Adjust docs.
v1 was already accepted so I plan to commit this if it passes CI.
v1's run had a spurious error that I hope will disappear with v2's run.
Will give Kito a chance to comment on the parsing flow adjustment as well,
still.
Regte
On Mon, Dec 8, 2025 at 3:59 PM Richard Biener wrote:
>
> On Mon, 8 Dec 2025, Uros Bizjak wrote:
>
> > On Mon, Dec 8, 2025 at 2:41 PM Richard Biener wrote:
> > >
> > > The following adjusts costing of vector construction from scalars for
> > > FP modes which with 387 math can reside in FP regs whi
Hi,
In the vec_cbranch_all/any optimization we prepare the length and bias
operands slightly differently than expected. This patch fixes it.
Bootstrapped and regtested on x86, regtested on riscv64.
Regards
Robin
gcc/ChangeLog:
* optabs.cc (emit_cmp_and_jump_insns): Fix len/bias opera
On 12/8/25 3:50 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
Modules allow temploid friends to no longer be implicitly inline, as
functions defined in a class body will not be implicitly inline if
attached to a named module.
This requires
Mikael Morin wrote:
Add accessor functions to get or set the value of the type field of array
descriptors, and remove from the public API the function giving direct acces
to the field.
This is one is interesting: The setter not only comes as set of
overloaded functions that modify a stmtblock_t
Hi,
As agreed in the patchwork sync call two weeks ago, this implements
#pragma GCC target () for riscv.
All the functionality was already there so we only need to wrap existing
functions.
Regtested on rv64gcv_zvl512b.
Regards
Robin
PR target/115325
gcc/ChangeLog:
* config/r
On Mon, 8 Dec 2025 at 15:23, Patrick Palka wrote:
>
>
>
> On Mon, 8 Dec 2025, Jonathan Wakely wrote:
>
> > We have __is_signed_integer and __is_unsigned_integer traits which
> > should have been updated by r16-2190-g4faa42ac0dee2c when making
> > __int128 an extended integer type (for PR libstdc++
Hi,
v2 failed the CI even though I regtested it successfully. From the logs it's
not obvious what's going on. I'm suspecting a target-selector issue.
Therefore this is v3 with the tests split into compile and run portions.
Going to commit if the CI succeeds.
Regtested on rv64gcv_zvl512b.
T
On Mon, 8 Dec 2025, Jonathan Wakely wrote:
> We have __is_signed_integer and __is_unsigned_integer traits which
> should have been updated by r16-2190-g4faa42ac0dee2c when making
> __int128 an extended integer type (for PR libstdc++/96710). Currently
> they check whether the type is a signed in
On Mon, 8 Dec 2025 at 14:20, Yuao Ma wrote:
>
> On Mon, Dec 8, 2025 at 6:52 PM Jonathan Wakely wrote:
> >
> > On Mon, 1 Dec 2025 at 19:52, Patrick Palka wrote:
> > >
> > > On Wed, 26 Nov 2025, Yuao Ma wrote:
> > > > diff --git
> > > > a/libstdc++-v3/testsuite/23_containers/flat_multiset/constex
On Mon, 8 Dec 2025, Uros Bizjak wrote:
> On Mon, Dec 8, 2025 at 2:41 PM Richard Biener wrote:
> >
> > The following adjusts costing of vector construction from scalars for
> > FP modes which with 387 math can reside in FP regs which need spilling
> > to be reloaded to XMM. I've played on the saf
On Mon, 8 Dec 2025, Yuao Ma wrote:
> On Mon, Dec 8, 2025 at 6:52 PM Jonathan Wakely wrote:
> >
> > On Mon, 1 Dec 2025 at 19:52, Patrick Palka wrote:
> > >
> > > On Wed, 26 Nov 2025, Yuao Ma wrote:
> > > > diff --git
> > > > a/libstdc++-v3/testsuite/23_containers/flat_multiset/constexpr.cc
> >
> -Original Message-
> From: [email protected]
> Sent: 04 December 2025 12:56
> To: [email protected]
> Cc: Alex Coplan ; Alice Carlotti
> ; [email protected];
> [email protected]; Richard Earnshaw ;
> Tamar Christina ; Wilco Dijkstra
> ; Ezra Sitorus
> Subject: [P
Mikael Morin wrote:
Add a static function producing a reference to the data field of array
descriptors, like those existing for the other fields.
OK, let's add this as cleanup/for completeness. → LGTM.
gcc/fortran/ChangeLog:
* trans-descriptor.cc (conv_descriptor_data): New function.
Hi all,
Mikael Morin wrote:
The attribute field is not used, this removes the single function giving
direct access to it.
I find this quite interesting, but I can confirm it. For type declaration,
it is added to the descriptor, but not initialized.
libgfortran.h offers GFC_DTYPE_CLEAR that se
Hi,
previously, callback edges of a carrying edge redirected to
__builtin_unreachable were deleted, as I thought they would
mess with the callgraph, given that they were no longer correct.
In some cases, the edges would be deleted when duplicating
a fn summary, producing a segfault. This patch cha
On Mon, 8 Dec 2025 at 14:18, LIU Hao wrote:
>
> 在 2025-12-8 22:03, Jonathan Wakely 写道:
> > In C++14 I would declare it like this:
> >
> > std::add_lvalue_reference_t
> > __get_once_call() noexcept;
> >
> > But for C++11 we don't have add_lvalue_reference, so we need the
> > slightly uglier form:
>
On Mon, Dec 8, 2025 at 6:52 PM Jonathan Wakely wrote:
>
> On Mon, 1 Dec 2025 at 19:52, Patrick Palka wrote:
> >
> > On Wed, 26 Nov 2025, Yuao Ma wrote:
> > > diff --git
> > > a/libstdc++-v3/testsuite/23_containers/flat_multiset/constexpr.cc
> > > b/libstdc++-v3/testsuite/23_containers/flat_mult
On Mon, Dec 8, 2025 at 2:41 PM Richard Biener wrote:
>
> The following adjusts costing of vector construction from scalars for
> FP modes which with 387 math can reside in FP regs which need spilling
> to be reloaded to XMM. I've played on the safe side with mixed
> SSE/387 math.
>
> Bootstrap an
在 2025-12-8 22:03, Jonathan Wakely 写道:
In C++14 I would declare it like this:
std::add_lvalue_reference_t
__get_once_call() noexcept;
But for C++11 we don't have add_lvalue_reference, so we need the
slightly uglier form:
std::add_lvalue_reference::type
__get_once_call() noexcept;
Well, in my
On Thu, 4 Dec 2025 at 09:31, LIU Hao wrote:
>
> The previous patch was incorrect, because it defined static references to
> thread-local variables and in
> that case they would no longer be thread-local.
>
> Instead of that, those getter functions are called directly in
> `_Prepare_execution`.
>
On Mon, Dec 8, 2025 at 12:06 AM Jeff Law wrote:
>
>
>
> On 12/7/25 1:44 PM, Florian Weimer wrote:
> > * Jeff Law:
> >
> >> This is Shreya's work except for the SH testcase which I added after
> >> realizing her work would also fix the testcases for that port. I
> >> bootstrapped and regression te
The following adjusts costing of vector construction from scalars for
FP modes which with 387 math can reside in FP regs which need spilling
to be reloaded to XMM. I've played on the safe side with mixed
SSE/387 math.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
OK?
Thanks,
Richar
From: Pan Li
This patch would like to introduce the combine of vec_dup + vmslt.wv
into vmslt.wx on the cost value of GR2VR. The late-combine will
take place if the cost of GR2VRlike 1, 2, 15 in test.
From:
| ...
| vmv.v.x
| L1:
| vmslt.vv
| J L1
| ...
To:
| ...
| L1:
| v
From: Pan Li
Add asm dump check and run test for vec_duplicate + vmslt.vv
combine to vmslt.vx, with the GR2VR cost is 0, 2 and 15.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vx_vf/vx-1-i16.c: Add asm check
for vmslt.vx.
* gcc.target/riscv/rvv/autovec/vx_vf/v
From: Pan Li
This patch would like to combine the vec_duplicate + vmslt.wv to the
vmslt.vx. From example as below code. The related pattern will depend
on the cost of vec_duplicate from GR2VR. Then the late-combine will
take action if the cost of GR2VR is zero, and reject the combination
if th
On Mon, Nov 24, 2025 at 10:21 PM Victor Do Nascimento
wrote:
>
> The iteration count profitability check is irrelevant for uncounted
> loops given that, even at runtime, the number of iterations is unknown
> at the start of loop execution.
>
> Likewise, the test for skipping the vectorized version
On 12/4/25 10:24, Tamar Christina wrote:
Hi Victor,
-Original Message-
From: Victor Do Nascimento
Sent: 03 December 2025 17:22
To: [email protected]
Cc: Tamar Christina ; [email protected]; Victor
Do Nascimento
Subject: [PATCH v3] vect: Add uncounted loop unit tests
New in t
Andrew Stubbs wrote:
Unified Shared Memory does not appear to work well on gfx908, which is why we
disabled xnack by default. For this reason it makes sense to inform the user
as compile time, but this is causing trouble in the testsuite which assumes
that USM only fails at runtime.
This patch
From: Pierre-Emmanuel Patry
Previously we aborted when querying the location on a MetaItemPathExpr,
the location should start on the path and continue over the expr but we
do not support that kind of location range yet.
gcc/rust/ChangeLog:
* ast/rust-expr.h: Use path locus.
gcc/testsui
On Mon, Nov 24, 2025 at 10:24 PM Victor Do Nascimento
wrote:
>
> Default types:
> --
>
> While the primary exit condition for loops is no longer tied to some
> upper limit in the number of executed iterations, similar limits are
> still required for vectorization. One example of this
On Mon, Nov 24, 2025 at 10:28 PM Victor Do Nascimento
wrote:
>
> In its current implementation, the loop vectorizer requires the main
> exit be the counting IV exit. With uncounted loops we no longer need
> to have any counting IV exits. Furthermore, it is possible to have
> reached this stage wi
The following handles (by rejecting) simplifications that end up
turning a VN NARY operation into a call which would be a VN REFERENCE
and is unexpected and not handled.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/123040
* tree-ssa-sccvn.cc (v
The changes the _Variadic_union implementation, in a way that the
_Unitialized partial specialization for non-trivial types is not
necessary.
This is simply done by separating the specialization for
__trivially_destructible
being true and false, and for the later defining an empty destructor (sim
On Mon, Dec 8, 2025 at 1:17 PM Richard Biener
wrote:
>
> On Sat, Dec 6, 2025 at 8:39 PM Andrew Pinski
> wrote:
> >
> > This fixes a regression introduced with r16-5258-g1d8e2d51e5c5cb.
> > With GCC 12+, we would not merge forwarders (with phis, vops included),
> > this meant that after the last c
On Sat, Dec 6, 2025 at 8:39 PM Andrew Pinski
wrote:
>
> This fixes a regression introduced with r16-5258-g1d8e2d51e5c5cb.
> With GCC 12+, we would not merge forwarders (with phis, vops included),
> this meant that after the last cddce, degenerate phis would stay not
> merged which allowed for bett
Hi All,
The attached is a straightforward fix for a problem with PDT class
components of a non parameterised derived type. The ICE is fixed by finding
the PDT instance and building the class type just before the ICE occurred
(gcc_assert (vtab);).
Note that, in common with a number of other PDT te
Unified Shared Memory does not appear to work well on gfx908, which is why we
disabled xnack by default. For this reason it makes sense to inform the user
as compile time, but this is causing trouble in the testsuite which assumes
that USM only fails at runtime.
This patch changes the gfx908 comp
On Mon, 8 Dec 2025 at 10:04, Jonathan Wakely wrote:
>
> We have __is_signed_integer and __is_unsigned_integer traits which
> should have been updated by r16-2190-g4faa42ac0dee2c when making
> __int128 an extended integer type (for PR libstdc++/96710). Currently
> they check whether the type is a s
Mikael Morin wrote:
Add accessor functions to get or set the value of the rank field of
array descriptors, and remove from the public API the function giving
direct acces to the field.
I note that gfc_conv_descriptor_rank_set takes either an int or a
tree, the latter is used by gfc_conv_gfc_des
Mikael Morin wrote:
Add accessor functions to get or set the value of the version field of array
descriptors, and remove from the public API the function giving direct acces
to the field.
gcc/fortran/ChangeLog:
* trans-descriptor.cc (gfc_conv_descriptor_version): Make static and
Mikael Morin wrote:
Add accessor functions to get or set the value of the elem_len field of
array descriptors, and remove from the public API the function giving direct
acces to the field.
gcc/fortran/ChangeLog:
* trans-descriptor.cc (gfc_conv_descriptor_elem_len): Make static
a
Mikael Morin wrote:
From: Mikael Morin
Regression tested on powerpc64le-unknown-linux-gnu. OK for master?
LGTM. The code already used 23 _set and 10 _get calls – and
outside the new trans-descriptor.cc function, only one
non _set/_get remained prior to this patch, which is now
replaced by a
Mikael Morin wrote:
The current API touching array descriptors is mostly limited to a set of
getters to pick the value of individual array descriptor fields, and setters
to update them. This requires every area of the compiler touching array
descriptors to have knowledge of their contents.
In
* Arnaud Charlet:
>> > From: Ronan Desplanques
>> >
>> > On some platforms, Long_Long_Float'Size (and Long_Long_Float'Stream_Size)
>> > is 128 but only 80 bits are effectively used. This pack makes it so
>> > 'Write in this case write zeros for the padding bits instead of
>> > unspecified values.
Hello Jeff,
thanks for having a look. It was posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689150.html
I attached it also to this e-mail.
Kind regards,
Sebastian
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu..
Copying narrow characters to a range of bool using std::copy cannot be
optimized to use std::memcpy. Assignment of an arbitrary integer to a
bool needs to convert all non-zero values to true, so is not a simple
memcpy-like or bit_cast-like operation. We currently get this wrong and
optimize it to m
On Mon, 1 Dec 2025 at 19:52, Patrick Palka wrote:
>
> On Wed, 26 Nov 2025, Yuao Ma wrote:
> > diff --git
> > a/libstdc++-v3/testsuite/23_containers/flat_multiset/constexpr.cc
> > b/libstdc++-v3/testsuite/23_containers/flat_multiset/constexpr.cc
> > new file mode 100644
> > index 000..860
Hi Jonathan,
On Tue, Dec 2, 2025 at 10:55 PM Jonathan Wakely wrote:
>
> But it seems we don't have agreement on doing it for C++23 anyway.
>
Have we reached a consensus on whether to backport this to C++23 or target
C++26 (as per the standard)? This decision affects both this patch and my
follow
On Thu, 4 Dec 2025 at 11:33, Christophe Lyon wrote:
>
> On Thu, 4 Dec 2025 at 11:55, Jonathan Wakely wrote:
> >
> > The libstdc++ style is different from the rest of GCC, so do not apply
> > the checks to libstdc++ files in a patch.
> >
> > contrib/ChangeLog:
> >
> > * check_GNU_style_lib
On Fri, 5 Dec 2025, Konstantinos Eleftheriou wrote:
> If we consider code like:
>
> if (bar1 == x)
> return foo();
> if (bar2 != y)
> return foo();
> return 0;
>
> We would like the ifcombine pass to convert this to:
>
> if (bar1 == x || bar2 != y)
> return foo
Hi Sandra!
It's NVIDIA "PTX", not "PDX". ;-)
The changes themselves are editorial, and look good to me.
Grüße
Thomas
On 2025-12-06T17:10:27-0700, Sandra Loosemore wrote:
> gcc/ChangeLog
> PR other/122243
> * doc/invoke.texi (Option Summary) : Add
> several missing options
On Mon, Dec 8, 2025 at 8:45 AM Feng Xue OS wrote:
>
> A possible approach to reference is detection of tabled-based CTZ in
> ssa-forward pass, which might be a suitable position for this pattern,
> in that ssa-forward pass is invoked more than one time, some happen
> before
On Mon, Dec 8, 2025 at 1:34 AM Andrew Pinski wrote:
>
>
>
> On Sun, Dec 7, 2025, 12:45 PM Florian Weimer wrote:
>>
>> * Jeff Law:
>>
>> > This is Shreya's work except for the SH testcase which I added after
>> > realizing her work would also fix the testcases for that port. I
>> > bootstrapped a
> > From: Ronan Desplanques
> >
> > On some platforms, Long_Long_Float'Size (and Long_Long_Float'Stream_Size)
> > is 128 but only 80 bits are effectively used. This pack makes it so
> > 'Write in this case write zeros for the padding bits instead of
> > unspecified values.
> >
> > gcc/ada/ChangeLo
> + /* Similarly for insertions, handle patterns like
> + (set (subreg:V4DI (reg:V8DI) idx)
^^^ It's offset rather than idx, although implementation is right, but
I think it's still worth to correct the comment
> + reg:V4DI)
> + and transform them into vector slideups. */
We have __is_signed_integer and __is_unsigned_integer traits which
should have been updated by r16-2190-g4faa42ac0dee2c when making
__int128 an extended integer type (for PR libstdc++/96710). Currently
they check whether the type is a signed integer type or an unsigned
integer type, or a cv-qualifi
On Tue, Dec 2, 2025 at 10:32 PM Robin Dapp wrote:
>
> Similar to vec_extract this implements vec_sets that are present as
> subreg inserts. Similar to a single element we can just slide up
> a vector with the TU policy.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-v.cc (expand_vector_subre
1 - 100 of 112 matches
Mail list logo
