In the __fwd_prod, __rev_prod I would also add the case for all-dynamic
extents, so we do not instantiate an array with all 1, i.e. we would have:
constexpr size_t __rank = _Extents::rank();
+ size_t __sta_prod = _RevProd<_Extents>::_S_value[__r];
+ return __extents_prod(__exts, __sta_
On Sun, Jul 27, 2025 at 2:57 PM Luc Grosheintz
wrote:
> In mdspan related code involving static extents, often the IndexType is
> part of the template parameters, even though it's not needed.
>
> This commit extracts the parts of _ExtentsStorage not related to
> IndexType into a separate class _S
On Sun, Jul 27, 2025 at 2:47 PM Luc Grosheintz
wrote:
> The methods layout_{left,right}::mapping::stride are defined
> as
>
> \prod_{i = 0}^r E[i]
> \prod_{i = r+1}^n E[i]
>
> This is computed as the product of a pre-comupted static product and the
> product of the required dynamic extents.
>
On Sun, Jul 27, 2025 at 2:53 PM Luc Grosheintz
wrote:
> Let E denote an multi-dimensional extent; n the rank of E; r = 0, ...,
> n; E[i] the i-th extent; and D[k] be the (possibly empty) array of
> dynamic extents.
>
> The two partial products for r = 0, ..., n:
>
> \prod_{i = 0}^r E[i] (fw
Ping (https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689930.html), thanks.
On 18/07/25 14:05, Dhruv Chawla wrote:
External email: Use caution opening links or attachments
On 18/07/25 13:22, Filip Kastl wrote:
External email: Use caution opening links or attachments
Hi,
I've tried runn
Pushed to r16-2571.
在 2025/7/24 下午7:35, Lulu Cheng 写道:
On LoongArch, the switch jump-table always stores absolute
addresses, so there is no need to define the macro
CASE_VECTOR_SHORTEN_MODE.
gcc/ChangeLog:
* config/loongarch/loongarch.h
(CASE_VECTOR_SHORTEN_MODE): Delete.
---
On Mon, Jul 14, 2025, at 10:43 PM, Hans-Peter Nilsson wrote:
> Tested to fix build for MMIX (and to fix a few type-generic-builtin
> test-cases; c-c++-common/pr111309-1.c, gcc.dg/torture/pr116480-1.c).
> Also regtested cris-elf and native x86_64-pc-linux-gnu.
FYI, this patch also fixes PR120144, s
On Thu, Jul 24, 2025 at 6:40 PM Takayuki 'January June' Suwa
wrote:
>
> The previous fix also had some flaws:
>
> - The TARGET_CONST16 check was a bit premature
> - It didn't take into account the possibility of the RTL expression
>"(set (reg:SF gpr) (const_int))", especially when TARGET_AUTOL
I am throwing in the towel.
I am chalking up the hours I have spent on this as a positive on the
educational side of the ledger. I have learned things about
git-cherry-pick, git-rev-list, and git-log that I didn't know, and that's
good.
I have reached the point where I am convinced that what
From: Aleksandar Rakic
There are no platforms nor simulators for MSA and microMIPS R5 so
turning off this support for now.
gcc/ChangeLog:
* config/mips/mips.cc (mips_option_override): Error out for
-mmicromips -mmsa for MIPSr5 and less.
Cherry-picked 1009d6ff7a8d3b56e0224a6b193
I tried to use just "TARGET_MICROMIPS" instead of "is_micromips", but
the compiler optimized "TARGET_MICROMIPS" away for some reason and
encoded it as "false".
From: Aleksandar Rakic
Aleksandar Rakic (1):
Make MSA and microMIPS R5 unsupported
gcc/config/mips/mips.cc | 7 +++
1 file changed, 7 insertions(+)
--
2.34.1
From: Caolán McNamara
libstdc++-v3/ChangeLog:
* include/bits/regex.tcc (__collatenames): Make array const.
Signed-off-by: Caolán McNamara
---
libstdc++-v3/include/bits/regex.tcc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/include/bits/regex.tcc
b/libst
Hi Alex,
and this is how this could potentially be used
in _Countof.
Martin
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index ed6e56e7279..b46eb43bb5a 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -3771,6 +3771,26 @@ is_top_array_vla (tree type)
return var;
}
+
+tree
There are couple of unsolved problems and missing features
related to -Wvla-parameter. I found it difficult to address these
with the current implementation. Here is a patch to improve the
implementation of the `arg spec' attribute. This patch would also
give us access to the type of the un
When I added the factor operations to ifcvt, I messed how handling of removing
the phi nodes. The fix is we need to remove the phi node that was factored out
as we factored out the operator because otherwise scev can go when it comes
to detecting if the new args are from a reduction.
Also the need
Public
Hi,
> I was going to apply this patch as it seems reasonable and independent
> of everything else. But unfortunately it appears that you have munged
> tabs into spaces.
>
> While we could potentially use "-l" to ignore that problem and allow the
> patch to apply, but then the resulting ch
On 7/27/25 3:35 AM, Artemiy Volkov wrote:
Hi all,
This small patch series is intended to address a shortcoming of the
scheduler, which currently only identifies and preserves fusible
instruction pairs (according to the value of the
TARGET_SCHED_MACRO_FUSION_PAIR_P hook) that are already conse
Thanks to everybody. I actually did do the more specific searches over a
range starting at the gcc-15 starting point; in my frustration I didn't copy
the final actual command I used. I thought I needed to start at the
original releases/gcc-15 point because that's where we branched away, and as
Versions 1, 2 and 3 of the patch for adding aligned_accessor had a
bug in the constraints that allowed conversion of
aligned_accessor a = aligned_accessor{};
and prevented the reverse.
The file mdspan/accessors/generic.cc already contains code that checks
all variation of the constraint. This
On 7/27/2025 8:51 PM, Mikael Morin wrote:
Le 27/07/2025 à 13:46, Yuao Ma a écrit :
On 7/27/2025 7:14 PM, Mikael Morin wrote:
Le 27/07/2025 à 11:37, Yuao Ma a écrit :
On 7/27/2025 5:19 PM, Mikael Morin wrote:
+gfc_charlen_type
+string_split (gfc_charlen_type stringlen, const CHARTYPE *str
Le 27/07/2025 à 13:46, Yuao Ma a écrit :
On 7/27/2025 7:14 PM, Mikael Morin wrote:
Le 27/07/2025 à 11:37, Yuao Ma a écrit :
On 7/27/2025 5:19 PM, Mikael Morin wrote:
+gfc_charlen_type
+string_split (gfc_charlen_type stringlen, const CHARTYPE *string,
+ gfc_charlen_type setlen, const
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
The function gfc_array_init_size evaluates the number of array elements
to a variable from a caller, but the single caller providing the
variable actually doesn't use it.
This change removes the variable and t
In mdspan related code involving static extents, often the IndexType is
part of the template parameters, even though it's not needed.
This commit extracts the parts of _ExtentsStorage not related to
IndexType into a separate class _StaticExtents.
It also prefers passing the array of static extent
An interesting case to consider is:
bool same11(const std::extents& e1,
const std::extents& e2)
{ return e1 == e2; }
Which has the following properties:
- There's no mismatching static extents, preventing any
short-circuiting.
- There's a comparison between dynamic and
The methods layout_{left,right}::mapping::stride are defined
as
\prod_{i = 0}^r E[i]
\prod_{i = r+1}^n E[i]
This is computed as the product of a pre-comupted static product and the
product of the required dynamic extents.
Disassembly shows that even for low-rank extents, i.e. rank == 1 and
r
On 7/24/25 21:49, Toon Moene wrote:
On 7/24/25 21:35, Thomas Koenig wrote:
Am 23.07.25 um 21:47 schrieb Toon Moene:
Today I used Thomas's "locks" example code from the same e-mail
message (showing the full output):
Actually, I think that example is flawed, it lacks synchronization.
Sorry
Let E denote an multi-dimensional extent; n the rank of E; r = 0, ...,
n; E[i] the i-th extent; and D[k] be the (possibly empty) array of
dynamic extents.
The two partial products for r = 0, ..., n:
\prod_{i = 0}^r E[i] (fwd)
\prod_{i = r+1}^n E[i] (rev)
can be computed as the product
Using __int_traits avoids the need to include from .
This in turn should reduce the size of the pre-compiled .
Similar refactoring was carried out for PR92546. Unfortunately,
./gcc/xgcc -std=c++23 -P -E -x c++ - -include mdspan | wc -l
shows a decrease by 1(!) line. This is due to bits/max_siz
This is a sequence of related improvements to we
discussed during review and then postponed. The ideas are:
* Pre-compute the product of static extents; and a follow up
for fine-tuning for low-rank extents.
* Returning to extents::operator== to improve the case of mixed
dynamic/stati
libstdc++-v3/ChangeLog:
* include/std/mdspan: Small stylistic adjustments.
Signed-off-by: Luc Grosheintz
---
libstdc++-v3/include/std/mdspan | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/libstdc++-v3/include/std/mdspan b/libstdc++-v3/include/std/
We failed to build the correct initialization vector.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Note this restricts n-lanes to 1 for VLA vectors since I don't
know how to build a proper initializer there. I think that
RVV at least could do this by shifting in the individual lane
Hi Mikael,
This looks fine to me. OK for mainline.
Thanks for the fix.
Paul
On Sat, 26 Jul 2025 at 20:31, Mikael Morin wrote:
> From: Mikael Morin
>
> Regression-tested on x86_64-pc-linux-gnu.
> OK for master?
>
> -- >8 --
>
> Don't look for a class container too far after an array descript
On 7/27/2025 7:14 PM, Mikael Morin wrote:
Le 27/07/2025 à 11:37, Yuao Ma a écrit :
On 7/27/2025 5:19 PM, Mikael Morin wrote:
+gfc_charlen_type
+string_split (gfc_charlen_type stringlen, const CHARTYPE *string,
+ gfc_charlen_type setlen, const CHARTYPE *set,
+ gfc_charlen_typ
Le 27/07/2025 à 11:37, Yuao Ma a écrit :
On 7/27/2025 5:19 PM, Mikael Morin wrote:
+gfc_charlen_type
+string_split (gfc_charlen_type stringlen, const CHARTYPE *string,
+ gfc_charlen_type setlen, const CHARTYPE *set,
+ gfc_charlen_type pos, GFC_LOGICAL_4 back)
+{
+ gfc_charlen_
I am at a point where I want to store additional information from
analysis (from loads and stores) to re-use them at transform stage
without repeating the analysis. I do not want to add to
stmt_vec_info at this point, so this starts adding kind specific
sub-structures by moving the STMT_VINFO_TYPE
On Sat, 26 Jul 2025, Robert Dubner wrote:
>
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Saturday, July 26, 2025 12:06
> > To: Robert Dubner
> > Cc: g...@gcc.gnu.org; gcc-patches@gcc.gnu.org; James K. Lowden
> >
> > Subject: Re: GCC 15.1.1 Status Report (2025-07-11)
> >
On 7/27/2025 5:43 PM, Mikael Morin wrote:
I forgot to add:
+ else
+ {
+ if (pos < 1 || pos > (stringlen + 1))
+ runtime_error ("If BACK is present with the value true, the
value of "
+ "POS shall be in the range [1, LEN (STRING) + 1]");
+
can you provide the valu
I forgot to add:
+ else
+ {
+ if (pos < 1 || pos > (stringlen + 1))
+ runtime_error ("If BACK is present with the value true, the value
of "
+ "POS shall be in the range [1, LEN (STRING) + 1]");
+
can you provide the value of pos and stringlen in the error messages?
From: Artemiy Volkov
Presently, the scheduler code only considers consecutive instructions
for macro-op fusion (see sched-deps.cc::sched_macro_fuse_insns () for
details). This patch introduces the new dep_fusion pass, which is
intended to uncover more fusion opportunities by reordering eligible
On 7/27/2025 5:19 PM, Mikael Morin wrote:
+gfc_charlen_type
+string_split (gfc_charlen_type stringlen, const CHARTYPE *string,
+ gfc_charlen_type setlen, const CHARTYPE *set,
+ gfc_charlen_type pos, GFC_LOGICAL_4 back)
+{
+ gfc_charlen_type i, j;
+
+ if (!back)
+ {
+ i
From: Artemiy Volkov
Some of the instruction pairs recognized as fusible by a preceding
invocation of the dep_fusion pass require that both components of a pair
have the same hard register output for the fusion to work in hardware.
(An example of this would be a multiply-add operation, or a zero-
From: Artemiy Volkov
Consider the following (RISC-V) instruction pair:
mul s6,a1,a2
add s6,a4,s6
Without this patch, while handling the second instruction, (a) the
existing chain for s6 will first be closed (upon the terminate_write
action for the input operand), then (b) a new one will be open
Hi all,
This small patch series is intended to address a shortcoming of the
scheduler, which currently only identifies and preserves fusible
instruction pairs (according to the value of the
TARGET_SCHED_MACRO_FUSION_PAIR_P hook) that are already consecutive in
the instruction stream, but does not
Le 27/07/2025 à 05:40, Yuao Ma a écrit :
Hi Mikael,
On 7/27/2025 3:57 AM, Mikael Morin wrote:
Hello,
here are a few more comments on the patch below.
It's not ready yet, but the remarks should be easily addressed.
Thanks for the thorough review! I've addressed the comments and attached
a n
Committed as the failures of CI is unrelated.
Pan
-Original Message-
From: Li, Pan2
Sent: Friday, July 25, 2025 9:30 PM
To: gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; jeffreya...@gmail.com;
rdapp@gmail.com; Chen, Ken ; Liu, Hongtao
; Li, Pan2
Subject:
On Jul 27 2025, Thomas Schwinge wrote:
> Hi Bob!
>
> On 2025-07-27T08:55:04+0200, Andreas Schwab wrote:
>> On Jul 26 2025, Robert Dubner wrote:
>>> Follow-up: After poking around on the internet for inspiration, I used
>>>
>>> git log
>>> basepoints/gcc-15~1..HEAD --reverse --grep="^gcc/cobol"
Hi Bob!
On 2025-07-27T08:55:04+0200, Andreas Schwab wrote:
> On Jul 26 2025, Robert Dubner wrote:
>> Follow-up: After poking around on the internet for inspiration, I used
>>
>> git log
>> basepoints/gcc-15~1..HEAD --reverse --grep="^gcc/cobol" --grep="^libgcobol"
>> --grep="cobol.dg"
You ne
48 matches
Mail list logo
