On Tue, May 20, 2025 at 9:08 PM Luc Grosheintz
wrote:
>
>
> On 5/20/25 17:44, Tomasz Kaminski wrote:
> > On Tue, May 20, 2025 at 4:30 PM Luc Grosheintz >
> > wrote:
> >
> >>
> >>
> >> On 5/20/25 4:07 PM, Tomasz Kaminski wrote:
> >>> On Tue, May 20, 2025 at 3:16 PM Luc Grosheintz <
> luc.groshei.
On Tue, May 20, 2025 at 3:16 PM Luc Grosheintz
wrote:
> Implements the parts of layout_left that don't depend on any of the
> other layouts.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/mdspan (layout_left): New class.
>
> Signed-off-by: Luc Grosheintz
> ---
> libstdc++-v3/include/std/
On Tue, 2025-05-20 at 13:06 +0100, Jonathan Wakely wrote:
> On 13/07/20 16:45 +0800, Xi Ruoyao via Libstdc++ wrote:
> >
> > > The second and third patch together resolve PR 81806.
> >
> > The attached patch modifies split_finish to use the subtree size we
> > maintained
> > in the previous patch,
On Wed, May 21, 2025 at 3:44 AM Andrew Pinski wrote:
>
> This was introduced by r15-1797-gd8fe4f05ef448e . I had missed that
> the LHS of the cabs call could be NULL. This seems to only happen at -O0,
> I tried to produce one that happens at -O1 but needed many different
> options to prevent the r
On Wed, May 21, 2025 at 12:30 AM Segher Boessenkool
wrote:
>
> On Mon, May 12, 2025 at 06:35:15PM -0400, Michael Meissner wrote:
> > On Mon, May 12, 2025 at 01:24:04PM +0530, Surya Kumari Jangala wrote:
> > > Hi Mike,
> > > Irrespective of whether -Ofast is used or not, should’nt we generate
> >
>>Thanks. I added the new cpu/tune options to the documentation in
doc/invoke.texi.
Thank you for the same
>>Going forward make sure to create a git commit message as well as a
ChangeLog entry.
Sure and we make sure that ChangeLog details in the commit log .
Thank you again
~U
On Tue, May 20, 2
>> I've pushed this to the trunk as well.
Thank you Jeff ,
~U
On Tue, May 20, 2025 at 11:29 PM Jeff Law wrote:
>
>
> On 5/19/25 1:03 AM, Umesh Kalappa wrote:
> > ---
> > gcc/config/riscv/mips-p8700.md | 28
> > 1 file changed, 28 insertions(+)
> I've pushed this
The middle-end uses rtx_cost on constants with the outer of being COMPARE
to find out the cost of a constant formation for a comparison instruction.
So for aarch64 backend, we would just return the cost of constant formation
in general. We can improve this by seeing if the outer is COMPARE and if
t
This is the first part in fixing PR target/120372.
The current code for canonicalize_comparison, uses gen_move_insn and rtx_cost
to find
out the cost of generating a constant. This is ok in most cases except sometimes
the comparison instruction can handle different constants than a simple set
intr
> Looks reasonably sensible. But I'll defer to Pan here since he's done
> *far* more work than I in this space.
Thanks Jeff.
LGTM but please wait the ack from Richard for the middle-end change.
Pan
-Original Message-
From: Jeff Law
Sent: Wednesday, May 21, 2025 2:06 AM
To: Li Xu ; g
Thanks Jeff.
> So for the tests, why are we forcing matching of the assembly code for
> the entire function? That must makes for a fragile test as we may
> change various aspects of code generation over time.
> If the point of the patch is to detect SAT_ADD in more cases, then the
> better an
From: Pan Li
Add asm dump check test for vec_duplicate + vand.vv combine to vand.vx,
with the GR2VR cost is 0, 2 and 15.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vx_vf/vx-1-i16.c: Add t
From: Pan Li
This patch would like to combine the vec_duplicate + vand.vv to the
vand.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 the
From: Pan Li
Add asm dump check test for vec_duplicate + vand.vv combine to vand.vx,
with the GR2VR cost is 0, 1 and 2.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vx_vf/vx-4-i16.c: Add as
From: Pan Li
This patch would like to introduce the combine of vec_dup + vand.vv into
vand.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. There will be two cases for the combine:
Case 0:
| .
On Tue, May 20, 2025 at 03:44:09PM GMT, Jakub Jelinek wrote:
> I'd suggest working on it incrementally rather than with a full patch set.
> In one or multiple patches handle the promote_mode stuff, the atomic
> extension and expr.cc changes with the feedback incorporated.
Ok.
> For gimple-lower-b
On Tue, May 20, 2025 at 09:55:04PM GMT, Xi Ruoyao wrote:
> On Tue, 2025-05-20 at 15:44 +0200, Jakub Jelinek wrote:
> > > Specifically, the tests told me to extend (thought "truncate"
> > > was kind of an equivalent word) the output of left shift, plus/minus,
> >
> > Truncation is the exact opposit
This was introduced by r15-1797-gd8fe4f05ef448e . I had missed that
the LHS of the cabs call could be NULL. This seems to only happen at -O0,
I tried to produce one that happens at -O1 but needed many different
options to prevent the removal of the call.
Anyways the fix is just keep around the call
> Pengxuan Zheng writes:
> > Some fields (e.g., zero_op0_p and zero_op1_p) of the struct "newd" may
> > be left uninitialized in aarch64_evpc_reencode. This can cause reading
> > of uninitialized data. I found this oversight when testing my patches
> > on and/fmov optimizations. This patch fixes t
There was a bug in aarch64_evpc_reencode which could leave zero_op0_p and
zero_op1_p of the struct "newd" uninitialized. r16-701-gd77c3bc1c35e303 fixed
the issue by zero initializing "newd." This patch provides an alternative fix
as suggested by Richard Sandiford based on the fact that the zerone
From: Lingling Kong
gcc/ChangeLog:
* config/i386/i386-expand.cc (ix86_expand_int_cfmovcc): Expand
to cfcmov pattern.
* config/i386/i386-opts.h (enum apx_features): New.
* config/i386/i386-protos.h (ix86_expand_int_cfmovcc): Define.
* config/i386/i386.cc (
From: Lingling Kong
Hi,
APX CFCMOV feature implements conditionally faulting which means
that all memory faults are suppressed when the condition code
evaluates to false and load or store a memory operand. Now we
could load or store a memory operand may trap or fault for
conditional move.
In mi
This operator is similar to sizeof but can only be applied to an array,
and returns its number of elements.
FUTURE DIRECTIONS:
- We should make it work with array parameters to functions,
and somehow magically return the number of elements of the array,
regardless of it being really a poin
gcc/ChangeLog:
* Makefile.in (USER_H): Add .
* ginclude/stdcountof.h: Add countof macro.
gcc/testsuite/ChangeLog:
* gcc.dg/countof-stdcountof.c: Add tests for .
Signed-off-by: Alejandro Colomar
---
gcc/Makefile.in | 1 +
gcc/ginclude/stdcount
It has been standardized in C2y.
gcc/c/ChangeLog:
* c-parser.cc (c_parser_sizeof_or_countof_expression):
Add -Wpedantic diagnostic for _Countof in <= C23 mode.
gcc/testsuite/ChangeLog:
* gcc.dg/countof-compat.c:
Test _Countof diagnostics with -Wc23-c2y-compat on
Hi!
Here's another revision of this patch set.
v23 changes:
- More specific change logs.
- #define assert() instead of #include'ing .
`make check` says all's good. I haven't diffed against master this
time, because that's slow as hell, and the changes are minimal. I've
only ran `make check
On Mon, May 12, 2025 at 06:35:15PM -0400, Michael Meissner wrote:
> On Mon, May 12, 2025 at 01:24:04PM +0530, Surya Kumari Jangala wrote:
> > Hi Mike,
> > Irrespective of whether -Ofast is used or not, should’nt we generate
> > XSCMPUDP instruction for ‘isgreater()’ operation? This is because XSCM
The instruction scheduler appears to be speculatively hoisting vsetvl
insns outside of their basic block without checking for data
dependencies. This resulted in a situation where the following occurs
vsetvli a5,a1,e32,m1,tu,ma
vle32.v v2,0(a0)
sub a1,a1,a5 <-- a1 poten
So this is the next step on the path to mvconst_internal removal and is
work from Shreya and myself.
This puts in the infrastructure to allow us to synthesize logical AND
much like we're doing with logical IOR/XOR.
Unlike IOR/XOR, AND has many more special cases that can be profitable.
For e
On Tue, May 20, 2025 at 11:44:43PM +0200, Alejandro Colomar wrote:
> Hi Jakub,
>
> On Tue, May 20, 2025 at 11:20:27PM +0200, Jakub Jelinek wrote:
> > On Tue, May 20, 2025 at 11:12:38PM +0200, Alejandro Colomar wrote:
> > > Okay; how about this?
> > >
> > > gcc/c-family/ChangeLog:
> > >
>
Hi Jakub,
On Tue, May 20, 2025 at 11:20:27PM +0200, Jakub Jelinek wrote:
> On Tue, May 20, 2025 at 11:12:38PM +0200, Alejandro Colomar wrote:
> > Okay; how about this?
> >
> > gcc/c-family/ChangeLog:
> >
> > * c-common.h: Add _Countof operator.
> > * c-common.def:
On Tue, May 20, 2025 at 11:12:38PM +0200, Alejandro Colomar wrote:
> Okay; how about this?
>
> gcc/c-family/ChangeLog:
>
> * c-common.h: Add _Countof operator.
> * c-common.def: Likewise.
> * c-common.cc (c_countof_type): Likewise.
No, that doesn't des
Hi Jakub,
On Tue, May 20, 2025 at 05:25:29PM +0200, Jakub Jelinek wrote:
> On Tue, May 20, 2025 at 05:15:33PM +0200, Alejandro Colomar wrote:
> > I've based on gnulib commits, which I believe follow the same
> > guidelines. For example:
> >
> > commit 6608062398ef4c983a58b90a1520c39f12fb7ac1
Many tests became unsupported on aarch64 when -mcpu=unset was added to
several arm_* effective targets, because this flag is only supported
on arm.
Since these effective targets are used on arm and aarch64, the patch
adds -mcpu=unset on arm only, and restores "" on aarch64.
This re-enables lots o
The automatically-generated gen_* routines take their operands as
individual arguments, named "operand0" upwards. These arguments are
stored into an "operands" array before invoking the expander's C++
code, which can then modify the operands by writing to the array.
However, the SPARC sign-extend
Maybe I'm missing something there. Particularly whether or not you can know
anything about frm's value after a call has returned. Normally the answer to
this kind of question is a hard no.
AFAICT the main difference to standard mode switching is that we (ab)use it to
set the rounding mode to
On 5/20/25 9:51 AM, Iain Sandoe wrote:
Hi Jason,
Moving this initialization doesn't seem connected to the type of gro, or
mentioned above?
A fly-by tidy up.. removed.
I still see it in the new patch?
Apologies, I obviously fat-fingered something - done now.
...return object from an objec
On 5/20/25 17:44, Tomasz Kaminski wrote:
On Tue, May 20, 2025 at 4:30 PM Luc Grosheintz
wrote:
On 5/20/25 4:07 PM, Tomasz Kaminski wrote:
On Tue, May 20, 2025 at 3:16 PM Luc Grosheintz
Implements the parts of layout_left that don't depend on any of the
other layouts.
libstdc++-v3/Chang
Hi Jerry!
Am 20.05.25 um 05:23 schrieb Jerry D:
On 5/19/25 1:50 PM, Harald Anlauf wrote:
Hi Jerry,
so contrary to what the name of patch claims (pr120049-final.diff),
it fixes only the case of direct use of iso_c_binding, but not the
indirect one thru the other module, which is the reason for
On 5/18/25 10:38 AM, Andrew Pinski wrote:
After r15-4791-gb60031e8f9f8fe, the valueize_condition argument becomes
unused. I didn't notice that as there was -Wno-unused option being added
while compiling gimple-match-exports.cc. This removes that too as there are
no unused warnings.
gcc/Change
On 5/18/25 2:41 PM, Richard Sandiford wrote:
Target [A] [B] [C]
native aarch64 0.5627 0.9585 0.5677
native x86_64 0.5925 0.9467 0.6377
aarch64-x-riscv64 0. 0.9066 0.2762
Nice. So how large
On 5/19/25 12:48 AM, Kito Cheng wrote:
Hi Jin:
Thanks for heads up:)
Hi Jeff:
I've rebased that on the trunk and everything seems right, do you think
it's OK for the trunk?
Yea, let's get it on the trunk and get it some soak time. We can then
look at backporting it to gcc-15's release br
0001-cobol-Multiple-PRs-formatting-exception-processing.patch
Description: Binary data
On 5/19/25 2:42 AM, Li Xu wrote:
From: xuli
This patch adds testcase for form1, as shown below:
void __attribute__((noinline)) \
vec_sat_s_add_imm_##T##_fmt_1##_##INDEX (T *out, T *op_1, unsigned limit) \
{
On 5/19/25 2:41 AM, Li Xu wrote:
From: xuli
This patch adds testcase for form1, as shown below:
T __attribute__((noinline)) \
sat_s_add_imm_##T##_fmt_1##_##INDEX (T x) \
{\
T sum = (UT)x + (UT)IMM;
On 5/19/25 1:02 AM, Umesh Kalappa wrote:
---
gcc/config/riscv/mips-p8700.md | 139 +++
gcc/config/riscv/riscv-cores.def | 5 ++
gcc/config/riscv/riscv-opts.h| 3 +-
gcc/config/riscv/riscv.cc| 22 +
gcc/config/riscv/riscv.md| 3
On 5/19/25 1:03 AM, Umesh Kalappa wrote:
---
gcc/config/riscv/mips-p8700.md | 28
1 file changed, 28 insertions(+)
I've pushed this to the trunk as well.
Thanks,
jeff
On Tue, 20 May 2025, Christopher Bazley wrote:
> + if (!cleared)
> + {
> + if (complete_p.padded_non_union
> + && warn_zero_init_padding_bits >= ZERO_INIT_PADDING_BITS_ALL)
> + {
> + warning (OPT_Wzero_init_padding_bits_,
> +
On Tue, May 20, 2025 at 6:32 PM Patrick Palka wrote:
> On Tue, 20 May 2025, Tomasz Kaminski wrote:
>
> > I think I do not have any more suggestions for cases to check, so the
> impl LGTM.
>
> It's cool how many optimizations we came up with for this algorithm :)
>
> >
> > On Tue, May 20, 2025 at
Hi!
On Thu, May 08, 2025 at 08:07:04PM -0400, Michael Meissner wrote:
> Previously GCC would zero externd a DImode GPR value to TImode by first zero
> extending the DImode value into a GPR TImode value, and then do a MTVSRDD to
> move this value to a VSX register.
>
> This patch does the move dir
This patch implements C++26 function_ref as specified in P0792R14,
with correction for constraints for constructor accepting nontype_t
parameter from LWG 4256.
As function_ref may store a pointer to the const object, __Ptrs::_M_obj is
changed to const void*, so again we do not cast away const from
Changes in v6:
* dispatch to starts_with for the bidi haystack + random access
needle case too
Changes in v5:
* dispatch to starts_with for the both-bidi/common range case
Changes in v4:
* optimize the both-bidi/common ranges case, as suggested by
Tomasz
* add tests for that code
On Tue, 20 May 2025, Tomasz Kaminski wrote:
> I think I do not have any more suggestions for cases to check, so the impl
> LGTM.
It's cool how many optimizations we came up with for this algorithm :)
>
> On Tue, May 20, 2025 at 4:33 PM Patrick Palka wrote:
> Changes in v5:
> * d
Sorry, the previous patch had some issues with the test case. Please refer to
the updated version, which resolves the problem.
From: Yuao Ma
Sent: Tuesday, May 20, 2025 23:54
To: gcc-patches@gcc.gnu.org ; GCC Fortran
; tbur...@baylibre.com
Subject: [PATCH] fort
Thank you very much.
I have repaired these typographical errors in our COBOLworx development
repository; they'll find their way into the gcc/master repository in at
most a few days.
(I had to look at the first one, the lower-case version, for about thirty
seconds before I saw the difference.)
Mu
>From 3c9066c01ccd7270408423b1773699af05dd361e Mon Sep 17 00:00:00 2001
From: Robert Dubner mailto:rdub...@symas.com
Date: Tue, 20 May 2025 11:49:43 -0400
Subject: [PATCH] cobol: sqrt(0) is not an ec-argument error. [PR119885]
libgcobol
PR cobol/119885
* intrinsic.cc: (__gg__sqrt)
On 16/05/25 15:56 +0200, Tomasz Kamiński wrote:
This patch implements C++26 function_ref as specified in P0792R14,
with correction for constraints for constructor accepting nontype_t
parameter from LWG 4256.
As function_ref may store a pointer to the const object, __Ptrs::_M_obj is
changed to co
For final target classes of which the source type is a unique non-
virtual base, we know that the dynamic_cast succeeding is equivalent to
the vptr pointing to the target's vtable. So check this if possible
instead of calling the more expensive `__dynamic_cast` runtime method.
This might be extend
Hi all,
This patch introduces constant input support for trigonometric functions,
including those involving half-revolutions. Both valid and invalid inputs have
been thoroughly tested, as have mpfr versions greater than or equal to 4.2 and
less than 4.2.
Inspired by Steve's previous work, this pa
On Tue, May 20, 2025 at 4:30 PM Luc Grosheintz
wrote:
>
>
> On 5/20/25 4:07 PM, Tomasz Kaminski wrote:
> > On Tue, May 20, 2025 at 3:16 PM Luc Grosheintz >
> > wrote:
> >
> >> Implements the parts of layout_left that don't depend on any of the
> >> other layouts.
> >>
> >> libstdc++-v3/ChangeLog
On Tue, May 20, 2025 at 03:44:09PM +0200, Jakub Jelinek wrote:
> The tests weren't included :(.
I'd like to see something along the lines of following as the test(s)
for the padding bits (if LoongArch will really have the weirdo psABI
then with some special version of that for it).
Though, this do
Richard Sandiford writes:
> Konstantinos Eleftheriou writes:
>> This patch uses `lowpart_subreg` for the base register initialization,
>> instead of zero-extending it. We had tried this solution before, but
>> we were leaving undefined bytes in the upper part of the register.
>> This shouldn't be
On Mon, 19 May 2025, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk/15/14?
Whoops, CI reports I missed a testsuite adjustment expecting an
additional error in other/default13.C, which seems reasonable. Here's
an updated patch.
-- >8 --
H
On Thu, May 15, 2025 at 10:29 AM MCC CS wrote:
>
> Dear all,
>
> Here's my patch for PR120265. Bootstrapped and tested on aarch64 that it
> causes no regressions. I also added a testcase. I'd be grateful
> if you could commit it.
>
> Otherwise, feedback to improve it is welcome.
>
> Many thanks
>
On Tue, May 20, 2025 at 05:15:33PM +0200, Alejandro Colomar wrote:
> I've based on gnulib commits, which I believe follow the same
> guidelines. For example:
>
> commit 6608062398ef4c983a58b90a1520c39f12fb7ac1
> Author: Paul Eggert
> Date: Fri Jan 10 10:34:58 2025 -0800
>
>
Hi,
in GCC 15 we allowed jump-function generation code to skip over a
type-cast converting one integer to another as long as the latter can
hold all the values of the former or has at least the same precision.
This works well for IPA-CP where we do then evaluate each jump
function as we propagate
Hi Joseph,
On Tue, May 20, 2025 at 02:43:55PM +, Joseph Myers wrote:
> > Could you please clarify if I need to do anything or if this is already
> > scheduled for review when you have some time? Also please clarify if
> > you're okay with amending that or if you prefer that I send v23.
>
> I
On Thu, May 15, 2025 at 10:04 AM liuhongt wrote:
>
> 1) Optimize (a >> 1) + (b >> 1) + ((a | b) & 1) to .AVG_CEIL (a, b)
> 2) Optimize (a | b) - ((a ^ b) >> 1) to .AVG_CEIL (a, b)
>
> Prof is at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118994#c6
>
> Bootstrapped and regtested on x86_64-pc-linu
Hi,
lack of white space breakes the tree-visualisation structure and makes
the dump unnecessarily difficult to read.
I have bootstrapped and tested the patch on x86_64-linux. I plan to
commit it soon as obvious.
Thanks,
Martin
gcc/ChangeLog:
2025-05-19 Martin Jambor
* ipa-prop.c
On 5/20/25 9:42 AM, Iain Sandoe wrote:
Hi Jason
So I moved this to the position before the g_r_o is initialized
(since we only manage cleanups of the entities that come before that, although
that's a bit hard to see from the patch).
This will probably need reevaluation if you take my suggest
I think I do not have any more suggestions for cases to check, so the impl
LGTM.
On Tue, May 20, 2025 at 4:33 PM Patrick Palka wrote:
> Changes in v5:
> * dispatch to starts_with for the both-bidi/common range case
>
> Changes in v4:
> * optimize the both-bidi/common ranges case, as suggeste
Commit 0547dbb725b reduced the number of cases in which
union padding bits are zeroed when the relevant language
standard does not strictly require it, unless gcc was
invoked with -fzero-init-padding-bits=unions or
-fzero-init-padding-bits=all in order to explicitly
request zeroing of padding bits.
Tested on hppa64-hp-hpux11.11. Committed to trunk.
Dave
---
hpux: Fix detection of atomic support when profiling
The pa target lacks atomic sync compare and swap instructions.
These are implemented as libcalls and in libatomic. As on linux,
we lie about their availability.
This fixes the gcov
Commit 0547dbb725b reduced the number of cases in which
union padding bits are zeroed when the relevant language
standard does not strictly require it, unless gcc was
invoked with -fzero-init-padding-bits=unions or
-fzero-init-padding-bits=all in order to explicitly
request
On Tue, 20 May 2025, Alejandro Colomar wrote:
> Could you please clarify if I need to do anything or if this is already
> scheduled for review when you have some time? Also please clarify if
> you're okay with amending that or if you prefer that I send v23.
I have it on my list for review. I'd
Tamar Christina writes:
> Hi All,
>
> With the middle-end providing a way to make vectorization more profitable by
> scaling vect-scalar-cost-multiplier this makes a more user friendly option
> to make it easier to use.
>
> I propose making it an actual -m option that we document and retain vs usi
Thanks Richard for the review.
> On 20 May 2025, at 2:47 am, Richard Sandiford
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> Kugan Vivekanandarajah writes:
>> diff --git a/Makefile.in b/Makefile.in
>> index b1ed67d3d4f..b5e3e520791 100644
>> --- a/Makefile.in
>> ++
On Tue, 20 May 2025, Patrick Palka wrote:
> Changes in v5:
> * dispatch to starts_with for the both-bidi/common range case
Forgot to mention:
And for a bidi common haystack, prefer iterating forward instead of
backward if the needle is at least half the size of the haystack,
>
> Changes in v
Changes in v5:
* dispatch to starts_with for the both-bidi/common range case
Changes in v4:
* optimize the both-bidi/common ranges case, as suggested by
Tomasz
* add tests for that code path
Changes in v3:
* Use the forward_range code path for a (non-sized) bidirectional
haystack,
On 5/20/25 4:07 PM, Tomasz Kaminski wrote:
On Tue, May 20, 2025 at 3:16 PM Luc Grosheintz
wrote:
Implements the parts of layout_left that don't depend on any of the
other layouts.
libstdc++-v3/ChangeLog:
* include/std/mdspan (layout_left): New class.
Signed-off-by: Luc Grosheint
On Tue, May 20, 2025 at 3:16 PM Luc Grosheintz
wrote:
> Implements the parts of layout_left that don't depend on any of the
> other layouts.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/mdspan (layout_left): New class.
>
> Signed-off-by: Luc Grosheintz
> ---
Sending feedback on this PR
On Tue, 2025-05-20 at 15:44 +0200, Jakub Jelinek wrote:
> > Specifically, the tests told me to extend (thought "truncate"
> > was kind of an equivalent word) the output of left shift, plus/minus,
>
> Truncation is the exact opposite of extension.
> I can understand the need for handling of left sh
Hi Jason,
>>>Moving this initialization doesn't seem connected to the type of gro, or
>>>mentioned above?
>>A fly-by tidy up.. removed.
>>I still see it in the new patch?
Apologies, I obviously fat-fingered something - done now.
>>...return object from an object that has already been destroyed.
On Tue, May 20, 2025 at 08:58:18PM +0800, Yang Yujie wrote:
> Thanks for the quick review.
>
> Aside from code formatting issues, can I conclude that you suggest
> we should rebase this onto your new big-endian support patch? Or
> do you think it's necessary to add big-endian && extended support
Hi Jason
>>>So I moved this to the position before the g_r_o is initialized
>>>(since we only manage cleanups of the entities that come before that,
>>>although
>>> that's a bit hard to see from the patch).
>>This will probably need reevaluation if you take my suggestion from the
>>decltype pat
On Sun, May 18, 2025 at 10:12 PM Luc Grosheintz
wrote:
> Implements the tests for layout_stride and for the features of the other
> two layouts that depend on layout_stride.
>
> libstdc++-v3/ChangeLog:
>
> * testsuite/23_containers/mdspan/layouts/class_mandate_neg.cc: Add
> tests
On Tue, May 20, 2025 at 3:17 PM Tomasz Kaminski wrote:
>
>
> On Tue, May 20, 2025 at 3:07 PM Patrick Palka wrote:
>
>> On Tue, 20 May 2025, Tomasz Kaminski wrote:
>>
>> >
>> >
>> > On Mon, May 19, 2025 at 6:06 PM Patrick Palka
>> wrote:
>> > On Mon, 19 May 2025, Patrick Palka wrote:
>> >
Hi!
The following patch fixes
FAIL: gcc.dg/dfp/bitint-1.c (test for excess errors)
FAIL: gcc.dg/dfp/bitint-2.c (test for excess errors)
FAIL: gcc.dg/dfp/bitint-3.c (test for excess errors)
FAIL: gcc.dg/dfp/bitint-4.c (test for excess errors)
FAIL: gcc.dg/dfp/bitint-5.c (test for excess errors)
FAI
Changes in V4:
* optimize the both-directional/common ranges case, as suggested by
Tomasz
* add tests for that code path
Changes in v3:
* Use the forward_range code path for a (non-sized) bidirectional
haystack, since it's slightly fewer increments/decrements
overall.
* Fix wro
On Tue, May 20, 2025 at 3:07 PM Patrick Palka wrote:
> On Tue, 20 May 2025, Tomasz Kaminski wrote:
>
> >
> >
> > On Mon, May 19, 2025 at 6:06 PM Patrick Palka wrote:
> > On Mon, 19 May 2025, Patrick Palka wrote:
> >
> > > Changes in v3:
> > > * Use the forward_range code path
On Tue, 20 May 2025, Tomasz Kaminski wrote:
>
>
> On Mon, May 19, 2025 at 6:06 PM Patrick Palka wrote:
> On Mon, 19 May 2025, Patrick Palka wrote:
>
> > Changes in v3:
> > * Use the forward_range code path for a (non-sized) bidirectional
> > haystack, since it's s
Implements the remaining parts of layout_left and layout_right; and all
of layout_stride.
libstdc++-v3/ChangeLog:
* include/std/mdspan(layout_stride): New class.
Signed-off-by: Luc Grosheintz
---
libstdc++-v3/include/std/mdspan | 211 +++-
1 file changed, 20
This follows up on:
https://gcc.gnu.org/pipermail/libstdc++/2025-May/061459.html
The changes are:
* Fix layout_stride::strides; and add tests.
* Add accessors for ranges of static and dynamic extents.
* Use them to implement __fwd_prod and __rev_prod.
* Remove public members with protected
Implements the tests for layout_stride and for the features of the other
two layouts that depend on layout_stride.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/mdspan/layouts/class_mandate_neg.cc: Add
tests for layout_stride.
* testsuite/23_containers/mdspan/layouts/c
Implement the parts of layout_left that depend on layout_right; and the
parts of layout_right that don't depend on layout_stride.
libstdc++-v3/ChangeLog:
* include/std/mdspan (layout_right): New class.
Signed-off-by: Luc Grosheintz
---
libstdc++-v3/include/std/mdspan | 153
Implements the parts of layout_left that don't depend on any of the
other layouts.
libstdc++-v3/ChangeLog:
* include/std/mdspan (layout_left): New class.
Signed-off-by: Luc Grosheintz
---
libstdc++-v3/include/std/mdspan | 309 +++-
1 file changed, 308 insert
Implements a suite of tests for the currently implemented parts of
layout_left. The individual tests are templated over the layout type, to
allow reuse as more layouts are added.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/mdspan/layouts/class_mandate_neg.cc: New test.
* tes
Adds tests for layout_right and for the parts of layout_left that depend
on layout_right.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/mdspan/layouts/class_mandate_neg.cc: Add
tests for layout_stride.
* testsuite/23_containers/mdspan/layouts/ctors.cc: Add tests for
On 5/19/25 2:56 PM, Tomasz Kaminski wrote:
On Sun, May 18, 2025 at 10:14 PM Luc Grosheintz
wrote:
Implements a suite of tests for the currently implemented parts of
layout_left. The individual tests are templated over the layout type, to
allow reuse as more layouts are added.
libstdc++-v3/
Hi Jakub,
Thanks for the quick review.
Aside from code formatting issues, can I conclude that you suggest
we should rebase this onto your new big-endian support patch? Or
do you think it's necessary to add big-endian && extended support
together?
> Are you sure all those changes were really nec
1 - 100 of 160 matches
Mail list logo
