Derived types with recursive allocatable components and FINAL procedures
trigger an ICE in gimplify_call_expr because the finalizer wrapper's result
symbol references itself (final->result = final), creating a cycle. This
patch creates a separate __result_ symbol to break the cycle.
Self-assignmen
As [1] says, we cannot mix up lock-free and locking atomics for one
object. For example assume atom = (0, 0) initially, if we have a
locking "atomic" xor running on T0 and a lock-free store running on T1
concurrently:
T0| T1
-+-
This patch is a prelimianry patch to add the full 1,024 bit dense math register
(DMRs) for -mcpu=future. The MMA 512-bit accumulators map onto the top of the
DMR register.
This patch only adds the new 1,024 bit register support. It does not add
support for any instructions that need 1,024 bit re
The MMA subsystem added the notion of accumulator registers as an optional
feature of ISA 3.1 (power10). In ISA 3.1, these accumulators overlapped with
the VSX registers 0..31, but logically the accumulator registers were separate
from the FPR registers. In ISA 3.1, it was anticipated that in fut
This patch adds a new constraint ('wD') that matches the accumulator registers
that overlap with VSX registers 0..31 on power10. Future patches will add the
support for a separate accumulator register class that will be used when the
support for dense math registes is added.
2025-11-07 Michael
I've had these patches floating around since 2023 that add support for
a potential extension to the PowerPC called the dense math facility.
The Dense Math Facility (dmf) is designed to be an extension to the ISA
3.1 (i.e. power10/power11) MMA facility. Now, since these are future
patches, the Den
I have a fix which I will be committing later tonight.
On Fri, Nov 7, 2025, 7:27 PM Haochen Jiang wrote:
> On Linux/x86_64,
>
> c66ebc3e22138dc505b18865f5337b05a61012ad is the first bad commit
> commit c66ebc3e22138dc505b18865f5337b05a61012ad
> Author: Andrew Pinski
> Date: Mon Oct 27 22:22:0
On Linux/x86_64,
c66ebc3e22138dc505b18865f5337b05a61012ad is the first bad commit
commit c66ebc3e22138dc505b18865f5337b05a61012ad
Author: Andrew Pinski
Date: Mon Oct 27 22:22:08 2025 -0700
Move build_call_nary away from va_list
caused
FAIL: gcc.target/i386/pr105951-1.c (internal compiler
Hi,
Thanks for the quick review of the v2 patch. I have pushed this patch to the
trunk with review comments mentioned in v2 being incorporated.
It should now improve vector code gen on power8/9 with altivec types.
Regards,
Avinash Jayakar
Use sequences of shifts and add/sub if the hardware does
On 11/7/25 1:37 PM, Harald Anlauf wrote:
Dear All,
the attached patch adjust the checks for interoperability of procedures,
the conditions of which were relaxed in F2018.
The testcase is based on the one provided by the reporter.
The added examples of interoperable subroutines for the further
This time we are gimplifying the expression and call
fold_stmt during the gimplification (which is fine) but
since we removed the phi and the expression references ssa
names in the phi indirectly, things just fall over inside the ranger.
This moves the removal of the phi until gimplification happe
On 11/7/25 12:28 PM, Christopher Albert wrote:
Derived types with recursive allocatable components and FINAL procedures
trigger an ICE in gimplify_call_expr because the finalizer wrapper's
result symbol references itself (final->result = final), creating a
cycle. This patch creates a separate __r
This is V2 of a patch that I have sent previously:
https://www.mail-archive.com/[email protected]/msg384874.html
The goal of this patch is to address a subtle way to break ABI when the
[[clang::trivial_abi]] attribute is applied as documented in this feature
request https://gcc.gnu.org/bugzi
Ranger parts are fine with me.
Andrew
On 11/7/25 18:12, Martin Jambor wrote:
Hi,
this patch adds the ability to infer ranges from loads from global
constant static aggregates which have static initializers. Even when
the load has one or more ARRAY_REFs with an unknown index and thus we
do not
Hi,
this patch adds the ability to infer ranges from loads from global
constant static aggregates which have static initializers. Even when
the load has one or more ARRAY_REFs with an unknown index and thus we
do not know the particular constant that is being loaded, we can
traverse the correpond
On 11/3/2025 3:18 PM, Evgeny Karpov wrote:
Tue Oct 28 2025
Saurabh Jha wrote:
For mingw targets, there is no way to identify the end of function using
assembly directives right now.
However, emitting an end of function marker now will let us modify
check-function-bodies in scanasm.exp, wh
This implements changes from P3913R1.
For opt of type optional is view (T is not const), the views::reverse(opt),
views::take(opt, n), views::drop(opt, n) now returns optional.
In case of views::as_const, the optional is converted into optional,
we do not return optional in non-reference case, as
On Fri, Nov 7, 2025 at 8:06 AM Philipp Tomsich wrote:
>
> This adds support for the Ampere1c core to the AArch64 backend. The
> initial patch only adds the core feature set (ARMv9.2 + extensions)
> and does not add any special tuning decisions, and those may come
> later.
>
> Bootstrapped and test
On Thu, Nov 6, 2025 at 8:51 AM Karl Meakin via Sourceware Forge
wrote:
>
>
> From: Karl Meakin
>
> The checks for `code == UNEQ || code == LTGT` are unecessary, because
> they are already excluded by `aarch64_comparison_operator`
Ok.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64.md (m
On Thu, Nov 6, 2025 at 8:43 AM Karl Meakin via Sourceware Forge
wrote:
>
>
> From: Karl Meakin
>
> Deduplicate the checks against `ccmode` by extracting to a new
> predicate.
Ok.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64.md(movcc): Use new predicate.
> (movcc): Likewise.
>
PR c/122591
gcc/c-family/ChangeLog:
* c-common.cc (c_countof_type): Convert return value to size_t.
gcc/testsuite/ChangeLog:
* gcc.dg/countof-compile.c (type): Test return type of _Countof.
Reported-by: Sam James
Suggested-by: Andrew Pinski
Signed-off-by: Alejandro Co
Dear All,
the attached patch adjust the checks for interoperability of procedures,
the conditions of which were relaxed in F2018.
The testcase is based on the one provided by the reporter.
The added examples of interoperable subroutines for the further cases
are not really needed, as they are a
Tested by hand; this leads to output like this:
(gdb) p m_enode_for_diag
$1 =
(gdb) p m_enode_for_diag->get_supernode ()
$2 =
Pushed to trunk as r16-5091-g90a7e657ba3f92.
gcc/ChangeLog:
* gdbhooks.py (class AnaSupernodePrinter): New.
(class AnaExplodedNodePrinter): New.
Fix event text like this (seen in gcc.dg/analyzer/allocation-size-5.c):
31 | char arr[sizeof (int16_t)];
|^~~
||
|(1) allocated 2 bytes hereallocated here
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r16-5090-gfce
I have updated this patch with the V7 version.
https://gcc.gnu.org/pipermail/gcc-patches/2025-November/699956.html
In V6, I forgot to update the .machine directive to use "future". The
V7 patch fixes that.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linu
I originally made a more complicated patch (V5) on September 22nd, 2025 that
tried to do infrastructure cleanup as well as adding -mcpu=future. This patch
is a more limited patch in that it just adds the -mcpu=future patch, and it does
not do the other infrastructure work.
I submitted the V6 patc
Derived types with recursive allocatable components and FINAL procedures
trigger an ICE in gimplify_call_expr because the finalizer wrapper's
result symbol references itself (final->result = final), creating a
cycle. This patch creates a separate __result_ symbol to
break the cycle.
Self-assignmen
On 11/3/2025 3:42 PM, Evgeny Karpov wrote:
Tue Oct 28 2025
Saurabh Jha wrote:
+case $host in
+ aarch64-*-mingw* | aarch64-*-cygwin*)
+LIBGOMP_CHECKED_REAL_KINDS="4 8" ;;
+ *)
It looks like the first introduction of aarch64-*-cygwin in the GNU toolchain.
The work on preparing the intr
On 11/3/2025 4:06 PM, Evgeny Karpov wrote:
Tue Oct 28 2025
Saurabh Jha wrote:
For master, it fails on step 4 because mingw-crt needs long double to be
8 bytes. So I couldn't run regression tests for aarch64-w64-mingw32 on
master. After these commits are applied, the test summary looks like
t
On Fri, Nov 7, 2025 at 8:28 AM Jeff Law wrote:
>
>
>
> On 10/27/25 11:29 PM, Andrew Pinski wrote:
> > Instead of a va_list here we can create a std::initializer_list that
> > contains the
> > arguments and pass that.
> > This is just one quick version of what was mentioned during the Reviewing
>
Currently, GCC does not fully support the cases when a FAM or pointer field and
its corresponding counted_by field are in different anonymous structure/unions
of a common named structure.
For example:
struct nested_mixed {
struct {
union {
int b;
float f;
};
int n;
};
From: Saurabh Jha
The aarch64-w64-mingw32 target is different from aarch64-**-linux-gnu
targets with respect to how arguments for variadic functions are
handled. Specifically:
1. Homogeneous Floating-Point Aggregate (HFA) and Homogeneous Vector
Aggregate (HVA) are not handled in a special wa
From: Saurabh Jha
On windows targets, the size of long double is 64 bits. Therefore,
unlike aarch64-**-linux-gnu, where the size of long double is 128
bits, the size of long double for aarch64-w64-mingw32 has to be 64
bits.
This commit makes changes to gcc and libgfortran so that long double is
From: Saurabh Jha
For mingw targets, there is no way to identify the end of function using
assembly directives right now.
This patch adds such directive as a comment. This is not a real
directive because some other things, like Structured Exception Handling
(SEH), needs to be supported before w
Hi gcc-patches mailing list,
Saurabh Jha has requested that the following
forgejo pull request
be published on the mailing list.
Created on: 2025-10-28 12:52:52+00:00
Latest update: 2025-11-07 20:08:24+00:00
Changes: 16 changed files, 728 additions, 32 deletions
Head revision: saurabh.jha/gcc-TE
The vect testsuite is special in that not everything named *.c will be run so
this testcase needs to be named vect-* to be able to run.
Pushed as obvious after making sure it at least now compiles for
aarch64-linux-gnu.
PR testsuite/122602
gcc/testsuite/ChangeLog:
* gcc.dg/vect/
It comes from a small discrepancy between class-wide subtypes and types: they
both have unknown discriminants, but only the latter may have discriminants,
which causes Subtypes_Statically_Match to incorrectly return False.
Tested on x86-64/Linux, applied on the mainline.
2025-11-07 Eric Botca
On 07/11/2025 13:35, Richard Biener wrote:
On Wed, 5 Nov 2025, Christopher Bazley wrote:
On 28/10/2025 13:51, Richard Biener wrote:
On Tue, 28 Oct 2025, Christopher Bazley wrote:
vect_create_constant_vectors is updated to pad with zeros
between the end of a group and the end of a vector of
On 11/7/25 13:28, Richard Biener wrote:
Am 07.11.2025 um 15:46 schrieb Andrew MacLeod :
On 11/7/25 08:29, Richard Biener wrote:
When feeding non-SSA names to range_on_edge we degrade to a
non-contextual query even though range_on_exits handling suggests
that we can do better. The followi
Add param flags to adjust the memcpy/memove/memset inlining threshold.
The threshold can be updated with --param=-size-threshold=
Default is currently set for disabled.
gcc/ChangeLog:
* config/riscv/riscv-string.cc (riscv_expand_block_move_scalar):
Add length check.
(expa
Hi Kyrill,
This looks like an old version of the patch - so hold off on
review...
Cheers,
Wilco
> On 7 Nov 2025, at 10:42, Kyrylo Tkachov wrote:
>
>
>
>> On 7 Nov 2025, at 10:23, Andre Vieira wrote:
>>
>> Expands the use of eor3 where we'd otherwise use two vector eor's.
>>
>> Bootstrapped and regression tested on aarch64-none-linux-gnu.
>>
>> OK for trunk?
>>
>> gcc/ChangeLog:
>>
> On 7 Nov 2025, at 10:23, Andre Vieira wrote:
>
> Expands the use of eor3 where we'd otherwise use two vector eor's.
>
> Bootstrapped and regression tested on aarch64-none-linux-gnu.
>
> OK for trunk?
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-simd.md (*eor3q4): New insn to be used by
On Mon, Nov 03, 2025 at 01:45:14PM +, Alfie Richards wrote:
> This does not add support for these version (and the corresponding
> __ARM_FEATURE_ macros aren't implemented for this reason) but
> accepts the command line strings and allows these to be passed on to
> the assembler.
This is missi
Hi,
vect_gather_scatter_fn_p currently ICEs if offset_vectype is NULL. This is an
oversight in the patches that relax the gather/scatter detection. Catch this.
Bootstrapped and regtested on x86 and power10. Regtested on aarch64 and
riscv64.
Regards
Robin
gcc/ChangeLog:
* tree-vec
> Am 07.11.2025 um 15:46 schrieb Andrew MacLeod :
>
>
>> On 11/7/25 08:29, Richard Biener wrote:
>> When feeding non-SSA names to range_on_edge we degrade to a
>> non-contextual query even though range_on_exits handling suggests
>> that we can do better. The following does what it does in
>>
On 11/7/25 11:15, Andrew MacLeod wrote:
On 11/7/25 00:46, Andrew Pinski wrote:
On Thu, Nov 6, 2025 at 6:22 PM Andrew MacLeod
wrote:
I can add a check in the inferred range manager for atomic loads to
resolve this PR.
The IL sequence tends to look like:
_1 = &this_2(D)->b;
__ato
Expands the use of eor3 where we'd otherwise use two vector eor's.
Bootstrapped and regression tested on aarch64-none-linux-gnu.
OK for trunk?
gcc/ChangeLog:
* config/aarch64/aarch64-simd.md (*eor3q4): New insn to be used by
combine after reload to optimize any grouping of eor'
This implements changes from P3913R1.
For opt of type optional is view (T is not const), the views::reverse(opt),
views::take(opt, n), views::drop(opt, n) now returns optional.
In case of views::as_const, the optional is converted into optional,
we do not return optional in non-reference case, as
This implements changes from P3913R1.
For opt of type optional is view (T is not const), the views::reverse(opt),
views::take(opt, n), views::drop(opt, n) now returns optional.
In case of views::as_const, the optional is converted into optional,
we do not return optional in non-reference case, as
On Fri, Nov 7, 2025 at 5:15 PM Tomasz Kamiński wrote:
> This implements proposed resolution for LWG4308 [1].
>
> For T denoting either function type or unbounded array, the optional no
> longer exposes iterator, and viable begin/end members. The conditionally
> provided iterator type, it is now d
Hi Faust.
OK. Thanks!
> The BPF backend inline memmove expansion was broken for certain
> constructs. This patch addresses the two underlying issues:
> 1. Off-by-one in the "backwards" unrolled move loop offset.
> 2. Poor use of temporary register for the generated move loop, which
>could
Hi,
In PR120922 we first disabled setting a range on niters_vector for
partial vectorization and later introduced a ceiling division instead.
In PR121985 we ran into this again where a bogus range caused wrong code
later. On top I saw several instances of this issue on a local branch
that enable
On Nov 07 2025, Jeff Law wrote:
> I'll assume that mame fits in the medlow model? I haven't built mame in
> ages, but my recollection was that it was extremely large. The static
> parts all have to fit in a 2G.
See https://build.opensuse.org/package/show/openSUSE:Factory:RISCV/mame
for the same
Hi,
In can_vec_perm_const_p if we cannot directly permute a vector mode we
try to pun it with a byte mode. qimode_for_vec_perm checks gets the
mode size and uses that as number of elements for the new QImode vector.
This doesn't work for RVV mask vectors, though: First, their
precision might be
On 10/27/25 11:29 PM, Andrew Pinski wrote:
Instead of a va_list here we can create a std::initializer_list that contains
the
arguments and pass that.
This is just one quick version of what was mentioned during the Reviewing
refactoring
goals and acceptable abstractions.
The generated code sh
On 11/7/25 00:46, Andrew Pinski wrote:
On Thu, Nov 6, 2025 at 6:22 PM Andrew MacLeod wrote:
I can add a check in the inferred range manager for atomic loads to
resolve this PR.
The IL sequence tends to look like:
_1 = &this_2(D)->b;
__atomic_load_8 (_1, 0);
Just want to make sur
This implements proposed resolution for LWG4308 [1].
For T denoting either function type or unbounded array, the optional no
longer exposes iterator, and viable begin/end members. The conditionally
provided iterator type, it is now defined in __optional_ref_base
base class.
Furthermore, range sup
Adds support for the AArch64 fmv priority syntax.
This allows users to override the default function ordering.
For example:
```c
int bar [[gnu::target_version("default")]] (int){
return 1;
}
int bar [[gnu::target_version("dotprod;priority=2")]] (int) {
return 2;
}
int bar [[gnu::target_ver
This changes the hook to support checking version mergeability for cases
where the version strings do imply the same version, but are conflicting in some
other way so cannot be merged.
This is a change required for adding priority version support in aarch64.
gcc/ChangeLog:
* target.def (
Hello,
Thank you for the feedback!
I discussed this patch offline with Richard E and in doing so realised I could
simplify this signifficanly checking the priority values mergeability in
diagnose_mismatched_decls instead of disjoint_version_decls. This makes more
sense for a lot of reasons.
Cha
This adds support for the Ampere1c core to the AArch64 backend. The
initial patch only adds the core feature set (ARMv9.2 + extensions)
and does not add any special tuning decisions, and those may come
later.
Bootstrapped and tested on aarch64-none-linux-gnu.
gcc/ChangeLog:
* config/aarc
On 07/11/2025 12:08, Andrew Stubbs wrote:
My v2 patch is attached, with the env.c, documentation, and changelog
changes requested. I also spotted I had "is_device_addr", instead of
"has_device_address".
Is it OK now?
After discussing some of the other issues offline, I think I now
understand
Hi Joseph,
On Fri, Nov 07, 2025 at 03:29:01PM +, Joseph Myers wrote:
> On Fri, 7 Nov 2025, Alejandro Colomar wrote:
>
> > The first patch adds a test, and the second one makes the test succeed.
> > My reproducer posted on the GCC bugzilla also succeeds after this patch,
> > as a sanity check.
On 10/26/25 2:57 PM, Andreas Schwab wrote:
On Okt 26 2025, Alexandre Oliva wrote:
OTOH, the uses of the INT_MAX constant in testcases from the duped PRs
114168 and 117460, that get added to data symbols because of loop IV
optimizations, don't seem artificial to me. It looks like reasonable
On 11/6/25 7:22 PM, Andrew MacLeod wrote:
I can add a check in the inferred range manager for atomic loads to
resolve this PR.
The IL sequence tends to look like:
_1 = &this_2(D)->b;
__atomic_load_8 (_1, 0);
Just want to make sure I get this right since memory operations are not
On 11/6/25 10:46 PM, Andrew Pinski wrote:
On Thu, Nov 6, 2025 at 6:22 PM Andrew MacLeod wrote:
Isn't the other route on fixing this is by adding the nonnull
attribute to these builtins? I tried looking to see if anyone had
mentioned why these builtins didn't have the nonnull attribute on
On Fri, 7 Nov 2025, Alejandro Colomar wrote:
> The first patch adds a test, and the second one makes the test succeed.
> My reproducer posted on the GCC bugzilla also succeeds after this patch,
> as a sanity check.
Please send patches in bisectable form, so not adding a failing test like
this be
PR c/122591
gcc/c-family/ChangeLog:
* c-common.cc (c_countof_type): Convert return value to size_t.
Reported-by: Sam James
Suggested-by: Andrew Pinski
Signed-off-by: Alejandro Colomar
---
gcc/c-family/c-common.cc | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
d
PR c/122591
gcc/testsuite/ChangeLog:
* gcc.dg/countof-compile.c (type): Test return type of _Countof.
Reported-by: Reported-by: Sam James
Signed-off-by: Alejandro Colomar
---
gcc/testsuite/gcc.dg/countof-compile.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/gcc/t
Hi Joseph,
This is a fix for _Countof(), to make it return a size_t. Previously,
it was returning a 'sizetype', some GCC internal stuff incompatible with
all standard integer types.
The first patch adds a test, and the second one makes the test succeed.
My reproducer posted on the GCC bugzilla a
Hi Joseph,
On Fri, Nov 07, 2025 at 02:56:52PM +, Joseph Myers wrote:
> On Thu, 6 Nov 2025, Alejandro Colomar wrote:
>
> > Hi Joseph,
> >
> > A gentle ping, now that Sandra has merged patch 1/1.
>
> This patch does not apply any more.
Hmmm, I'll have a look tonight. Thanks!
Have a lovely
On Thu, 6 Nov 2025, Alejandro Colomar wrote:
> Hi Joseph,
>
> A gentle ping, now that Sandra has merged patch 1/1.
This patch does not apply any more.
--
Joseph S. Myers
[email protected]
On 11/7/25 08:29, Richard Biener wrote:
When feeding non-SSA names to range_on_edge we degrade to a
non-contextual query even though range_on_exits handling suggests
that we can do better. The following does what it does in
range_on_edge directly, passing the edge source as 'bbend'
argument to
On Wed, 5 Nov 2025, Christopher Bazley wrote:
>
> On 28/10/2025 13:29, Richard Biener wrote:
> > On Tue, 28 Oct 2025, Christopher Bazley wrote:
> >
> > +/* Materialize length number INDEX for a group of scalar stmts in SLP_NODE
> > that
> > + operate on NVECTORS vectors of type VECTYPE, where 0
On Thu, 6 Nov 2025, Christopher Bazley wrote:
>
> On 05/11/2025 12:25, Richard Biener wrote:
> > On Tue, 4 Nov 2025, Christopher Bazley wrote:
> >
> >> On 28/10/2025 13:29, Richard Biener wrote:
> +/* Materialize mask number INDEX for a group of scalar stmts in SLP_NODE
> that
> +
ping?
On Thu, 18 Sept 2025 at 22:37, Christophe Lyon
wrote:
>
> On Mon, 18 Aug 2025 at 19:30, Christophe Lyon
> wrote:
> >
> > We get lots of error messages when compiling arm_neon.h under
> > e.g. -mcpu=cortex-m55, because Neon builtins are enabled only when
> > !TARGET_HAVE_MVE. This has been
On Wed, 5 Nov 2025, Christopher Bazley wrote:
>
> On 28/10/2025 13:29, Richard Biener wrote:
> > On Tue, 28 Oct 2025, Christopher Bazley wrote:
> >
> >> +tree
> >> +vect_slp_get_bb_mask (slp_tree slp_node, gimple_stmt_iterator *gsi,
> >> +unsigned int nvectors, tree vectype, unsig
On Wed, 5 Nov 2025, Christopher Bazley wrote:
>
> On 28/10/2025 13:51, Richard Biener wrote:
> > On Tue, 28 Oct 2025, Christopher Bazley wrote:
> >
> >> vect_create_constant_vectors is updated to pad with zeros
> >> between the end of a group and the end of a vector of the type
> >> chosen for th
The following uses ranger to try to simplify boolean expressions
in simplify_using_initial_conditions as used by niter analysis.
We also try to simplify niter expressions themselves, but we cannot
use ranger directly for this.
* tree-ssa-loop-niter.cc (simplify_using_initial_conditions):
The following enables ranger for the vectorizer, this lets niter
analysis use the active ranger to simplify conditions.
PR tree-optimization/122587
* tree-vectorizer.cc (pass_vectorize::execute): Enable
ranger around analysis and code generation.
---
gcc/tree-vectorizer.cc
When feeding non-SSA names to range_on_edge we degrade to a
non-contextual query even though range_on_exits handling suggests
that we can do better. The following does what it does in
range_on_edge directly, passing the edge source as 'bbend'
argument to get_tree_range if the edge source has a sin
Hi,
Is this combination of commits
027205879733933ec991c230795da6c01ac50029 and
697ccadd7217316ea91ddd978ddc944e6df09522 OK for gcc-15?
Thanks,
Christophe
The vadcq and vsbcq patterns had two problems:
- the adc / sbc part of the pattern did not mention the use of vfpcc
- the carry calcultation
I am still waiting for a review on this (I'll make the libgcc change
before committing if the rest is deemed ok).
Just FYI I have figured out what is making the last two test cases fail,
was waiting to commit this and open a bugzilla as recommend by Jakub,
but I'll write it up here before I fo
On 06/11/2025 23:10, Tobias Burnus wrote:
Andrew Stubbs wrote:
This adds support for using Cuda Managed Memory with omp_alloc. AMD
support
will be added in a future patch.
There is one new predefined allocator, "ompx_gnu_managed_mem_alloc",
plus a
corresponding memory space, which can be us
On Fri, 7 Nov 2025, Avinash Jayakar wrote:
> Hi,
>
> Thanks for reviewing v1 of the patch. Incorporated the changes mentioned in
> review comments.
> Bootstrapped and regtested on powerpc64le-linux-gnu and x86_64-linux-gnu.
> Kindly review. Is this ok for trunk?
>
> Changes from v1:
> - Streamli
Hi,
Thanks for reviewing v1 of the patch. Incorporated the changes mentioned in
review comments.
Bootstrapped and regtested on powerpc64le-linux-gnu and x86_64-linux-gnu.
Kindly review. Is this ok for trunk?
Changes from v1:
- Streamline guard checks in mult lowering.
- Check target support befor
Oh, I see, thanks Robin.
Pan
-Original Message-
From: Robin Dapp
Sent: Friday, November 7, 2025 6:02 PM
To: Li, Pan2 ; Robin Dapp ;
[email protected]
Cc: [email protected]; [email protected]; [email protected]; Chen,
Ken ; Liu, Hongtao ; Robin Dapp
Subject: Re: [PATC
On Fri, 7 Nov 2025 at 11:53, Christophe Lyon via Sourceware Forge
wrote:
>
> Hi gcc-patches mailing list,
> Christophe Lyon has requested that the following forgejo
> pull request
> be published on the mailing list.
>
> Created on: 2025-10-21 15:10:12+00:00
> Latest update: 2025-11-07 10:49:36+0
Hi gcc-patches mailing list,
Christophe Lyon has requested that the following forgejo
pull request
be published on the mailing list.
Created on: 2025-10-21 15:10:12+00:00
Latest update: 2025-11-07 10:49:36+00:00
Changes: 2 changed files, 33 additions, 2 deletions
Head revision: clyon/gcc-TEST re
From: Christophe Lyon
The operands of the floating-point version of vbicq were swapped, this
patch fixes this.
For this backport the testcase needs an adjustment: the code is less
optimized than with gcc-15, so we still generate the 0.0f constant and
a vbic instruction. We actually check that
On Fri, 7 Nov 2025 at 11:44, Christophe Lyon via Sourceware Forge
wrote:
>
> Hi gcc-patches mailing list,
> Christophe Lyon has requested that the following forgejo
> pull request
> be published on the mailing list.
>
> Created on: 2025-10-21 15:05:50+00:00
> Latest update: 2025-11-07 10:42:54+0
From: Christophe Lyon
The operands of the floating-point version of vbicq were swapped, this
patch fixes this.
For this backport the testcase needs an adjustment: the code is less
optimized than with gcc-15, so we still generate the 0.0f constant and
a vbic instruction. We actually check that
On 11/4/25 12:43, Jakub Jelinek wrote:
External email: Use caution opening links or attachments
On Tue, Nov 04, 2025 at 11:33:05AM +, Matthew Malcomson wrote:
We've been meaning to send this email for a while after the Cauldron.
IIUC you discussed this with Ramana there -- my understand
Hi gcc-patches mailing list,
Christophe Lyon has requested that the following forgejo
pull request
be published on the mailing list.
Created on: 2025-10-21 15:05:50+00:00
Latest update: 2025-11-07 10:42:54+00:00
Changes: 2 changed files, 33 additions, 2 deletions
Head revision: clyon/gcc-TEST re
Thank you Sandra, that looks much better.
R.
On 06/11/2025 22:41, Sandra Loosemore wrote:
> While working on other things, I noticed that the documentation for
> the -mbranch-protection= option was pretty garbled on both aarch64 and
> arm targets, with incorrect markup, too much syntax crammed in
On Thu, Nov 6, 2025 at 4:37 PM Robin Dapp wrote:
>
> Hi,
>
> The gather/scatter relaxation patches introduced a bug with
> vect_use_strided_gather_scatters_p. I didn't want to pass
> supported_offset_vectype and supported scale all the way from
> vect_truncate_gather_scatter_offset and
> vect_use
On Fri, 7 Nov 2025, Avinash Jayakar wrote:
>
> >
> > Please use { target avx2 } instead in both testcases.
> >
> > OK with those changes.
> > Richard.
>
> Thank you! Should it be committed in 13/14/15 releases as well?
If if ICEs also on branches sure, but please leave a week or so
to iron ou
Hi Jeff,
Thanks a lot for the feedback. We are adding tests and will send
patches again.
Best,
Djordje
From: Jeff Law
Sent: Friday, October 17, 2025 4:56 PM
To: Aleksa Paunovic ; [email protected]
Cc: Djordje Todorovic ; Chao-ying Fu
Subject: Re
The following addresses the latent issue that gsi_replace_with_seq
causes debug info to unnecessarily degrade and in this process
break the new immediate use iterator sanity checking. In particular
gsi_remove has side-effects on debug stmts even when operating
in non-permanent operation. But as w
1 - 100 of 111 matches
Mail list logo
