Well, that brought me one step further: configure did work, but I needed to
add the option --disable-multilib to exclude the 32-bits versions.
That gave me the makefiles to start the build, but then:
"gmake install" failed on the directory ./fixincludes.
Copying that from gcc/fixincludes did not h
gcc.dg/vect/slp-28.c is now vectorized as expected even on targets
without vect32.
Tested on x86_64-unknown-linux-gnu and aarch64-linux, pushed.
* gcc.dg/vect/slp-28.c: Adjust.
---
gcc/testsuite/gcc.dg/vect/slp-28.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --g
Ah, right, will try that.
Regards,
Arjen
Op di 22 jul 2025 om 08:28 schreef Andrew Pinski :
> On Mon, Jul 21, 2025 at 11:21 PM Arjen Markus
> wrote:
> >
> > I am trying to build the branch via WSL on my Windows machine, but
> configure reports that it cannot find the mpc.h include file. It is
On Mon, Jul 21, 2025 at 11:21 PM Arjen Markus wrote:
>
> I am trying to build the branch via WSL on my Windows machine, but configure
> reports that it cannot find the mpc.h include file. It is correct - that is
> lacking, but installing or reinstalling mpc does not help. The program I want
> t
I am trying to build the branch via WSL on my Windows machine, but
configure reports that it cannot find the mpc.h include file. It is correct
- that is lacking, but installing or reinstalling mpc does not help. The
program I want to test can be found here:
https://github.com/arjenmarkus/memos-on-p
On Mon Jul 21, 2025 at 6:27 PM CEST, Stefan Schulze Frielinghaus wrote:
> Bootstrapped successfully on s390x and tests dg.exp=asm-hard-reg-\*.c
> and s390.exp=asm-hard-reg-\*.c are successful, too. Ok for mainline?
FYI, I've created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121201, you may
wan
> -Original Message-
> From: Prathamesh Kulkarni
> Sent: 08 July 2025 08:37
> To: gcc-patches@gcc.gnu.org
> Cc: Matthew Malcomson ; Joseph Myers
> ; Thomas Schwinge ; Sam
> James
> Subject: [v2] PR81358: Enable automatic linking of libatomic
>
> External email: Use caution opening lin
So while debugging Austin's work to support the spacemit x60 in the BPI
we found that even though his pipeline description had mappings for all
the vector instructions, they were still getting matched by the
generic-vector-ooo DFA.
The core problem is that DFA never restricted itself to a tune
On Tue, Jul 22, 2025 at 4:47 AM H.J. Lu wrote:
>
> For TLS calls:
>
> 1. UNSPEC_TLS_GD:
>
> (parallel [
> (set (reg:DI 0 ax)
> (call:DI (mem:QI (symbol_ref:DI ("__tls_get_addr")))
> (const_int 0 [0])))
> (unspec:DI [(symbol_ref:DI ("e") [flags 0x50])
>
On 7/19/25 2:22 PM, Andrew Pinski wrote:
When we have an empty function, things can go wrong with
cfi_startproc/cfi_endproc and a few other things like exceptions. So if
the only thing the function does is a call to __builtin_unreachable,
let's replace that with a __builtin_trap instead if the
On 7/21/25 5:59 PM, Andrew Pinski wrote:
On Mon, Jul 21, 2025 at 4:46 PM Jeff Law wrote:
On 7/19/25 2:22 PM, Andrew Pinski wrote:
When we have an empty function, things can go wrong with
cfi_startproc/cfi_endproc and a few other things like exceptions. So if
the only thing the function d
On Mon, Jul 21, 2025 at 4:46 PM Jeff Law wrote:
>
>
>
> On 7/19/25 2:22 PM, Andrew Pinski wrote:
> > When we have an empty function, things can go wrong with
> > cfi_startproc/cfi_endproc and a few other things like exceptions. So if
> > the only thing the function does is a call to __builtin_unre
On 7/19/25 2:22 PM, Andrew Pinski wrote:
When we have an empty function, things can go wrong with
cfi_startproc/cfi_endproc and a few other things like exceptions. So if
the only thing the function does is a call to __builtin_unreachable,
let's replace that with a __builtin_trap instead if the
gcc/
* doc/extend.texi (Common Function Attributes)
(Common Variable Attributes): Document btf_decl_tag attribute.
(Common Type Attributes): Document btf_type_tag attribute.
---
gcc/doc/extend.texi | 79 +
1 file changed, 79 inser
On Mon, Jul 21, 2025 at 2:19 PM Martin Uecker wrote:
> Am Montag, dem 21.07.2025 um 04:29 -0700 schrieb Bill Wendling:
> > On Sun, Jul 20, 2025 at 4:41 AM Martin Uecker wrote:
> > But first, as of this time, all of our efforts over the past several
> > months to get an agreement on a syntax suita
Add a couple of tests to ensure that BTF type/decl tags do not interfere
with generation of BPF CO-RE relocations.
gcc/testsuite/
* gcc.target/bpf/core-btf-tag-1.c: New test.
* gcc.target/bpf/core-btf-tag-2.c: New test.
---
gcc/testsuite/gcc.target/bpf/core-btf-tag-1.c | 23 ++
Translate DW_TAG_GNU_annotation DIEs created for C attributes
btf_decl_tag and btf_type_tag into an in-memory representation in the
CTF/BTF container. They will be output in BTF as BTF_KIND_DECL_TAG and
BTF_KIND_TYPE_TAG records.
The new CTF kinds used to represent these annotations, CTF_K_DECL_T
Support the btf_decl_tag and btf_type_tag attributes in BTF by creating
and emitting BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG records,
respectively, for them.
Some care is required when -gprune-btf is in effect to avoid emitting
decl or type tags for declarations or types which have been pruned and
The btf_decl_tag and btf_type_tag attributes provide a means to annotate
declarations and types respectively with arbitrary user provided
strings. These strings are recorded in debug information for
post-compilation uses, and despite the name they are meant to be
recorded in DWARF as well as BTF.
[v5: https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689539.html
Changes from v5:
Patch 1 (C attribs):
- Change btf_type_tag attribute handler to treat btf_type_tag applied to a
function_type node as applying to the return type instead. This is to make
it easier to specify type_tag on
Add two new c-family attributes, "btf_type_tag" and "btf_decl_tag"
along with attribute handlers for them.
gcc/c-family/
* c-attribs.cc (c_common_attribute_table): Add btf_decl_tag and
btf_type_tag attributes.
(handle_btf_decl_tag_attribute): New handler for btf_decl_tag.
On Mon, Jul 21, 2025 at 4:13 AM Tamar Christina wrote:
>
> > -Original Message-
> > From: Kyrylo Tkachov
> > Sent: Monday, July 21, 2025 11:36 AM
> > To: Tamar Christina
> > Cc: GCC Patches ; Richard Sandiford
> > ; Andrew Pinski ; Alex Coplan
> > ; Remi Machet ; Jennifer Schmitz
> >
>
On 7/11/25 2:57 AM, Kuan-Lin Chen wrote:
This patch add support for XAndesvbfhcvt ISA extension.
This extension defines instructions to perform vector floating-point
conversion between the BFLOAT16 floating-point data and the IEEE-754 32-bit
single-precision floating-point (SP) data in a vecto
On 7/11/25 2:57 AM, Kuan-Lin Chen wrote:
This extension defines instructions to perform scalar floating-point
conversion between the BFLOAT16 floating-point data and the IEEE-754
32-bit single-precision floating-point (SP) data in a scalar
floating point register.
gcc/ChangeLog:
* co
On 7/11/25 2:57 AM, Kuan-Lin Chen wrote:
This patch adds support for the XAndesperf ISA extension.
The 32-bit AndeStar V5 extension includes branch instructions,
load effective address instructions, and string processing
instructions for performance improvement.
New INSN patterns are added int
On Mon, Jul 21, 2025 at 11:26:08AM -0400, Jason Merrill wrote:
> On 7/18/25 5:11 PM, Marek Polacek wrote:
> > On Thu, Jul 17, 2025 at 06:44:08PM -0400, Jason Merrill wrote:
> > > On 7/17/25 6:25 PM, Jakub Jelinek wrote:
> > > > On Thu, Jul 17, 2025 at 05:31:27PM -0400, Jason Merrill wrote:
> > > >
On 7/11/25 2:57 AM, Kuan-Lin Chen wrote:
This patch add basic support for the following XAndes ISA extensions:
XANDESPERF
XANDESBFHCVT
XANDESVBFHCVT
XANDESVSINTLOAD
XANDESVPACKFPH
XANDESVDOT
gcc/ChangeLog:
* config/riscv/riscv-ext.def: Include riscv-ext-andes.def.
* config/r
Am Montag, dem 21.07.2025 um 04:29 -0700 schrieb Bill Wendling:
> On Sun, Jul 20, 2025 at 4:41 AM Martin Uecker wrote:
> > I think the question is not whether this could be done somehow,
> > but whether it should. Why design a language feature that requires
> > storing tokens and parsing it outsi
On Mon, Jul 21, 2025 at 4:16 AM Stefan Schulze Frielinghaus
wrote:
>
> On Sat, Jul 19, 2025 at 08:26:22AM -0600, Jeff Law wrote:
> >
> >
> > On 7/17/25 2:24 AM, Stefan Schulze Frielinghaus wrote:
> > > On Wed, Jul 09, 2025 at 03:48:43PM +0200, Stefan Schulze Frielinghaus
> > > wrote:
> > > > This
On Sun, Jul 20, 2025 at 7:41 PM Hongtao Liu wrote:
>
> On Thu, Jul 17, 2025 at 11:22 PM H.J. Lu wrote:
> >
> > For TLS calls:
> >
> > 1. UNSPEC_TLS_GD:
> >
> > (parallel [
> > (set (reg:DI 0 ax)
> > (call:DI (mem:QI (symbol_ref:DI ("__tls_get_addr")))
> > (const_i
For TLS calls:
1. UNSPEC_TLS_GD:
(parallel [
(set (reg:DI 0 ax)
(call:DI (mem:QI (symbol_ref:DI ("__tls_get_addr")))
(const_int 0 [0])))
(unspec:DI [(symbol_ref:DI ("e") [flags 0x50])
(reg/f:DI 7 sp)] UNSPEC_TLS_GD)
(clobber (reg:DI 5 di))]
I forgot to wrap windows_create_symlink in a #ifdef in the first version,
so I added the #ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS. That is the only change.
This patch adds symlink support on Windows.
I tested it on x86_64-w64-mingw32 with msys2.
A few notes about this patch:
1. Symlinks can only be
On 7/21/25 20:52, Andre Vehreschild wrote:
Hi Toon,
the coarray_native branch is not where Jerry has put the caf_shmem
patches. Coarray native is an older branch, that used a different
approach to shared memory coarrays. Caf_shmem is partially based on it.
The branch Jerry has build is
rem
Bump. Regarding the formatting problems, I addressed this by attaching a patch
file directly to the ticket
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117468) which avoids any e-mail
formatting issues. I did the same for PR117366
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117366). Please t
This patch adds symlink support on Windows.
I tested it on x86_64-w64-mingw32 with msys2.
A few notes about this patch:
1. Symlinks can only be created while running as admin, or if Developer Mode
is enabled on Windows 10/11.
2. Symlinks on Windows are either file symlinks or directory symlinks
On 7/17/25 7:45 AM, Dusan Stojkovic wrote:
Hi Jeff,
So I'm not sure this transformation is correct.
Let's consider the case where a5 has the value 0x at the
"li" instruction.
a5 = 0xff00
li a4, -65536 // a4 = 0x
srai a5,a5,32 // a5 = 0xf
Hi Toon,
the coarray_native branch is not where Jerry has put the caf_shmem patches.
Coarray native is an older branch, that used a different approach to shared
memory coarrays. Caf_shmem is partially based on it.
The branch Jerry has build is
remotes/origin/devel/gfortran-test
- AndreAndr
This fixes an old issue whereby violations of the style check -gnatyc are
sometimes reported as violations of -gnatyt instead.
Tested on x86-64/Linux, applied on the mainline and 15 branch.
2025-07-21 Eric Botcazou
PR ada/121184
* styleg.adb (Check_Comment): Use consistent w
Subject: [PATCH] cobol: Improved linemap and diagnostic handling;
PIC validation. [PR120402]
Implementation of PICTURE string validation for PR120402. Expanded some
printf
format attributes. Improved debugging and diagnostic messages. Improved
linemap and line location tracking in support of d
On 7/19/25 20:40, Jerry D wrote:
Yes, this is why we need additional testers.
For those who need some guidance to the test branch:
$ git clone git://gcc.gnu.org/git/gcc.git
$ cd gcc
$ git checkout remotes/origin/devel/gfortran-test
$ git switch -c gfortran-test
If you already have an existi
On Jul 21 2025, Stefan Schulze Frielinghaus wrote:
> diff --git a/gcc/genpreds.cc b/gcc/genpreds.cc
> index c6a2983419a..4f8beeb0514 100644
> --- a/gcc/genpreds.cc
> +++ b/gcc/genpreds.cc
> @@ -1184,7 +1184,12 @@ write_insn_constraint_len (void)
>puts ("default: break;\n"
> "}\n"
On 7/19/25 5:06 PM, Jerry D wrote:
On 7/19/25 2:26 PM, Thomas Koenig wrote:
I wrote:
I have grave concerns.
At the last (to me an Nicolas) known state, before he was ousted
from the project, there were known race conditions, which can
cause freezing and/or data corruption.
I believe these ha
This is a trivial patch to add a few missing types to pipeline models
that are mostly complete.
In particular this adds the "ghost" to mips-p8700.md and the "sv_vc" and
"sf_vc_se" types to xiangshan.md.
There are definitely some bigger issues to solve in this space. But
this is a trivial fi
Bootstrapped successfully on s390x and tests dg.exp=asm-hard-reg-\*.c
and s390.exp=asm-hard-reg-\*.c are successful, too. Ok for mainline?
-- >8 --
The GNU extension rawmemchr cannot be used. Therefore, replace it by a
simple loop.
gcc/ChangeLog:
* genpreds.cc (write_insn_constraint_l
On Mon, Jul 21, 2025 at 12:07 AM Richard Biener
wrote:
>
> On Mon, Jul 21, 2025 at 1:30 AM Andrew Pinski
> wrote:
> >
> > I have seen this a few places though the testcase from PR 95906
> > is an obvious place where this shows up for sure.
> > This convert `cmp - 1` into `-icmp` as that form is
From: Luc Grosheintz
The mdspan::is_{,always}_{unique,strided,exhaustive} methods only call
their counterparts in mdspan::mapping_type. The standard specifies that
the methods of mdspan::mapping_type are noexcept, but doesn't specify if
the methods of mdspan are noexcept.
Libc++ strengthened the
On Mon, Jul 21, 2025 at 2:40 PM Jonathan Wakely
wrote:
> OK
>
Merged to trunk.
>
> On Mon, 21 Jul 2025, 12:10 Luc Grosheintz,
> wrote:
>
>> Previously, the default ctor of mdspan was never noexcept, even if all
>> members of mdspan were nothrow default constructible.
>>
>> This commit makes mds
This commit implements the C++26 feature std::dims described in P2389R2.
It sets the feature testing macro to 202406 and adds tests.
Also fixes the test mdspan/version.cc
libstdc++-v3/ChangeLog:
* include/bits/version.def (mdspan): Set value for C++26.
* include/bits/version.h: R
On Mon, Jul 21, 2025 at 2:45 PM Jonathan Wakely
wrote:
>
>
> On Mon, 21 Jul 2025, 12:08 Luc Grosheintz,
> wrote:
>
>> The mdspan::is_{,always}_{unique,strided,exhaustive} methods only call
>> their counterparts in mdspan::mapping_type. The standard specifies that
>> the methods of mdspan::mappin
On Mon, Jul 21, 2025 at 11:03:08PM +0800, Xi Ruoyao wrote:
> On Mon, 2025-07-21 at 16:57 +0200, Stefan Schulze Frielinghaus wrote:
> > The generated file tm-preds.h contains now:
> >
> > static inline size_t
> > insn_constraint_len (char fc, const char *str)
> > {
> > ...
> >
> > if (str[0] =
On 7/18/25 5:17 PM, Marek Polacek wrote:
On Thu, Jul 17, 2025 at 05:20:31PM -0400, Jason Merrill wrote:
On 7/16/25 5:59 PM, Marek Polacek wrote:
On Mon, Jul 14, 2025 at 12:52:41PM -0400, Jason Merrill wrote:
On 7/11/25 5:49 PM, Marek Polacek wrote:
On Thu, Jul 10, 2025 at 02:13:06PM -0400, Ja
On 7/18/25 5:11 PM, Marek Polacek wrote:
On Thu, Jul 17, 2025 at 06:44:08PM -0400, Jason Merrill wrote:
On 7/17/25 6:25 PM, Jakub Jelinek wrote:
On Thu, Jul 17, 2025 at 05:31:27PM -0400, Jason Merrill wrote:
On 7/16/25 10:49 AM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-g
Hi Stefan,
> The generated file tm-preds.h contains now:
>
> static inline size_t
> insn_constraint_len (char fc, const char *str)
> {
> ...
>
> if (str[0] == '{')
> return ((const char *) rawmemchr (str + 1, '}') - str) + 1;
> return 1;
> }
>
> For some reason on all targets I tested,
On Mon, 2025-07-21 at 16:57 +0200, Stefan Schulze Frielinghaus wrote:
> The generated file tm-preds.h contains now:
>
> static inline size_t
> insn_constraint_len (char fc, const char *str)
> {
> ...
>
> if (str[0] == '{')
> return ((const char *) rawmemchr (str + 1, '}') - str) + 1;
>
On Mon, Jul 21, 2025 at 08:02:12PM +0530, swamy sangamesh wrote:
> Hi All,
>
> I see a build failure on AIX.
>
> g++ -std=c++14 -c -g -DIN_GCC-fno-exceptions -fno-rtti
> -fasynchronous-unwind-tables -W -Wall -Wno-error=narrowing -Wwrite-strings
> -Wcast-qual -Wno-format -Wmissing-format-att
I just saw a patch by Jakub Jelinek that fixed the omission of
exporting std::dextents also addressed by this patch.
Since this is also mentioned in the commit message, I think it's
least work if I immediately create v3.
On 7/21/25 09:43, Luc Grosheintz wrote:
This commit implements the C++26 f
Hi Stefan,
> Thanks for clarification. Since the late time changes were rather a
> nit/fixup, I committed the v5 patches as
>
> r16-2376-g9791950017c90c
> r16-2375-gcbf17db978c663
> r16-2374-ga51c146ebce41b
this patch broke Solaris bootstrap (and no doubt every non-glibc
platform as well):
In f
Hi All,
I see a build failure on AIX.
g++ -std=c++14 -c -g -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-error=narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute
-Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long
This commit introduces support for the target_version attribute in the c
frontend, following the behavior defined in the Arm C Language Extension.
Key changes include:
- During pushdecl, the compiler now checks whether the current symbol is
part of a multiversioned set.
- New versions are add
Adds some aarch64 C fmv diagnostic tests.
This mostly tests C front end code, but has to be target specific at FMV
is requires specifying target extensions.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/mv-and-mvc-error1.c: New test.
* gcc.target/aarch64/mv-and-mvc-error2.c: New
Add tests covering many FMV errors for Aarch64, including
redeclaration, and mixing target_clones and target_versions.
gcc/testsuite/ChangeLog:
* g++.target/aarch64/mv-and-mvc-error1.C: New test.
* g++.target/aarch64/mv-and-mvc-error2.C: New test.
* g++.target/aarch64/mv-a
This patch introduces the TARGET_REJECT_FUNCTION_CLONE_VERSION hook
which is used to determine if a target_clones version string parses.
If true is returned, a warning is emitted and from then on the version
is ignored.
This is as specified in the Arm C Language Extension. The purpose of this
is
This patch is an overhaul of how FMV name mangling works. Previously
mangling logic was duplicated in several places across both target
specific and independent code. This patch changes this such that all
mangling is done in targetm.mangle_decl_assembler_name (including for the
dispatched symbol an
This patch removes the warning for target_version and target_clones in aarch64
as it is now spec compliant.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_process_target_version_attr):
Remove warning.
* config/aarch64/aarch64.opt: Mark -Wno-experimental-fmv-target
Adds an optimisation in FMV to redirect to a specific target if possible.
A call is redirected to a specific target if both:
- the caller can always call the callee version
- and, it is possible to rule out all higher priority versions of the callee
fmv set. That is estabilished either by the ca
Add support for a FMV set defined by a combination of target_clones and
target_version definitions.
Additionally, change is_function_default_version to consider a function
declaration annotated with target_clones containing default to be a
default version.
Lastly, add support for the case that a
This change refactors FMV handling in the frontend to allows greater
reasoning about versions in shared code.
This is needed for allowing target_clones and target_versions to be used
together in a function set, as there is then two distinct concerns when
encountering two declarations that previous
This patch changes the semantics of target_version and target_clones attributes
to match the behavior described in the Arm C Language extension.
The changes to behavior are:
- The scope and signature of an FMV function set is now that of the default
version.
- The FMV resolver is now created at
Adds the target_version and target_clones attributes to diagnostic messages
for target_version semantics.
This is because the target_version/target_clones attributes affect the identity
of the decls, so need to be represented in diagnostics for them.
After this change diagnostics look like:
c:
`
This is similar to clone_function_name and its siblings but takes an
identifier tree node rather than a function declaration.
This is to be used in conjunction with the identifier node stored in
cgraph_function_version_info::assembler_name to mangle FMV functions in
later patches.
gcc/ChangeLog:
This is a quick refactor of the riscv target processing code
to take a string_slice rather than a decl.
The reason for this is to enable it to work with target_clones
where merging logic requires reasoning about each version string
individually in the front end.
This refactor primarily serves jus
Hi All,
Updating this to highlight patches still needing review and remove committed
patches.
The particular important patches of note are:
- fmv: Refactor FMV name mangling.
This changes x86 FMV mangling, and removes of duplicated code from several
backends.
- fmv: Change target_version sem
On Mon, 21 Jul 2025, Robin Dapp wrote:
> > There is currently no way to mimic this, the original idea would have been
> > that you record the per stmt info during add_stmt cost hook time and then
> > process that data at finish_cost time.
> >
> > With SLP you could in theory walk the SLP graph via
A recent commit improved the macro VERIFY to eliminate the need for
certain parens. This commit updates the test code in
23_containers/mdspan
libstdc++-v3/ChangeLog:
* testsuite/23_containers/mdspan/extents/ctor_ints.cc: Remove
superfluous parens.
* testsuite/23_contain
The following makes us use the SLP graph and its recorded vector
types to perform alignment analysis even for loops. This avoids
accessing STMT_VINFO_VECTYPE we want to get rid of.
Bootstrap and regtest ongoing on x86_64-unknown-linux-gnu.
* tree-vect-data-refs.cc (vect_analyze_data_refs
On Mon, 21 Jul 2025, 12:18 Luc Grosheintz, wrote:
> TLDR; there should be patches in review for everything reported
> here.
>
> Thank you for running the libc++ tests! Let me know if you change
> your mind and think it would be good if I learnt to run their tests.
> I'm optimistic (or deluded) I
On Mon, 21 Jul 2025, 12:08 Luc Grosheintz, wrote:
> The mdspan::is_{,always}_{unique,strided,exhaustive} methods only call
> their counterparts in mdspan::mapping_type. The standard specifies that
> the methods of mdspan::mapping_type are noexcept, but doesn't specify if
> the methods of mdspan a
OK
On Mon, 21 Jul 2025, 12:10 Luc Grosheintz, wrote:
> Previously, the default ctor of mdspan was never noexcept, even if all
> members of mdspan were nothrow default constructible.
>
> This commit makes mdspan conditionally nothrow default constructible.
> A similar strengthening happens in lib
This patch LGTM
On Mon, Jul 21, 2025 at 5:24 AM Andreas Schwab wrote:
>
> I'll add this to clarify:
>
> temp1 is used by the probe loop for the step size, but we need the final
> address of the stack after the loop which resides in temp2.
>
> --
> Andreas Schwab, SUSE Labs, sch...@suse.de
> GPG K
From: Mikael Morin
gcc/fortran/ChangeLog:
* trans-decl.cc (gfc_trans_deferred_vars): Fix indentation.
---
gcc/fortran/trans-decl.cc | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
index 43bd7be54c
Thanks Robin, double check the local run is PASS for the CI reported failure,
so will commit it soon.
517889:PASS: gcc.dg/vect/pr116125.c -flto -ffat-lto-objects (test for excess
errors)
517891:PASS: gcc.dg/vect/pr116125.c -flto -ffat-lto-objects execution test
Pan
-Original Message-
F
Very much appreciated. Thank you!
- Andre
On Mon, 21 Jul 2025 13:38:56 +0200
Arjen Markus wrote:
> I have a not-so-trivial, but compact test case for you. I will try it out
> with the receipe you gave :).
>
> Regards,
>
> Arjen
>
> Op ma 21 jul 2025 om 13:31 schreef Andre Vehreschild :
>
>
I have a not-so-trivial, but compact test case for you. I will try it out
with the receipe you gave :).
Regards,
Arjen
Op ma 21 jul 2025 om 13:31 schreef Andre Vehreschild :
> Hi all,
>
> we are looking for people having old and/or modern Fortran codes available
> that use Coarrays more or less
Hi all,
we are looking for people having old and/or modern Fortran codes available
that use Coarrays more or less intensively. Jerry has build a test branch on
gcc's git, so testing is easier than usual:
> For those who need some guidance to the test branch:
>
> $ git clone git://gcc.gnu.org/git
On Sun, Jul 20, 2025 at 4:41 AM Martin Uecker wrote:
> I think the question is not whether this could be done somehow,
> but whether it should. Why design a language feature that requires
> storing tokens and parsing it outside the original context?
Fine, and I'm willing to have this discussion,
There is currently no way to mimic this, the original idea would have been
that you record the per stmt info during add_stmt cost hook time and then
process that data at finish_cost time.
With SLP you could in theory walk the SLP graph via the instances vector of
the vinfo. But I’m not sure w
TLDR; there should be patches in review for everything reported
here.
Thank you for running the libc++ tests! Let me know if you change
your mind and think it would be good if I learnt to run their tests.
I'm optimistic (or deluded) I can eventually figure it out.
On 7/15/25 13:35, Jonathan Wake
I need some extra shift varieties in the mode-independent code, but the macros
don't permit insns that don't have QI/HI variants. This fixes the problem, and
adds the new functions for the follow-up patch to use.
gcc/ChangeLog:
* config/gcn/gcn.cc (GEN_VNM_NOEXEC): Use USE_QHF.
(
Add new variant of he gather_load and scatter_store instructions that take the
offsets in DImode. This is not the natural width for offsets in the
instruction set, but we can use them to compute a vector of absolute addresses,
which does work.
This enables the autovectorizer to use gather/scatter
These new insns allow more efficient use of scalar inputs to 64-bit vector
add and mul. Also, the patch adjusts the existing mul.._dup because it was
actually a dup2 (the vec_duplicate is on the second input), and that was
inconveniently inconsistent.
The patterns are generally useful, but will b
This patch series allows the gather/scatter to support 64-bit offsets,
in addition to the 32-bit offsets already supported.
64-bit offsets are not natively supported by the hardware instructions,
but the vector of addresses can be precomputed, so we can make it work.
If the middle-end can use SImo
On Sat, Jul 19, 2025 at 08:26:22AM -0600, Jeff Law wrote:
>
>
> On 7/17/25 2:24 AM, Stefan Schulze Frielinghaus wrote:
> > On Wed, Jul 09, 2025 at 03:48:43PM +0200, Stefan Schulze Frielinghaus wrote:
> > > This is a follow-up to
> > > https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684181.html
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Monday, July 21, 2025 11:36 AM
> To: Tamar Christina
> Cc: GCC Patches ; Richard Sandiford
> ; Andrew Pinski ; Alex Coplan
> ; Remi Machet ; Jennifer Schmitz
>
> Subject: Re: [PATCH 2/2] aarch64: Allow CPU tuning to avoid INS-(W|X)ZR
>
Previously, the default ctor of mdspan was never noexcept, even if all
members of mdspan were nothrow default constructible.
This commit makes mdspan conditionally nothrow default constructible.
A similar strengthening happens in libc++.
libstdc++-v3/ChangeLog:
* include/std/mdspan (mdsp
The mdspan::is_{,always}_{unique,strided,exhaustive} methods only call
their counterparts in mdspan::mapping_type. The standard specifies that
the methods of mdspan::mapping_type are noexcept, but doesn't specify if
the methods of mdspan are noexcept.
Libc++ strengthened the exception guarantee fo
Checking our implementation of against the testsuite of libc++,
revealed differences in noexcept guarantees [1].
Libc++ performed two types of strengthening. These patches contain
simiar or same strengthening.
Thank you, for running the libc++ tests.
[1]: https://gcc.gnu.org/pipermail/libstdc++
This fixes a miscompilation issue introduced by the enablement of
combined loop peeling and versioning. A test case that reproduces the
issue is included in the patch.
When performing loop peeling, GCC usually inserts a skip-vector check.
This ensures that after peeling, there are enough remaining
This patch fixes a segmentation fault issue that can occur in vectorized
loops with an early break. When GCC vectorizes such loops, it may insert
a versioning check to ensure that data references (DRs) with speculative
loads are aligned. The check normally requires DRs to be aligned to the
vector m
With bools we can have the usual mismatch between mask and data
use. Catch that, like we do elsewhere.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
PR tree-optimization/121194
* tree-vect-loop.cc (vectorizable_lc_phi): Verify
vector types are compatible.
> On 21 Jul 2025, at 11:43, Kyrylo Tkachov wrote:
>
> Hi Tamar,
>
>> On 21 Jul 2025, at 11:12, Tamar Christina wrote:
>>
>> Hi Kyrill,
>>
>>> -Original Message-
>>> From: Kyrylo Tkachov
>>> Sent: Friday, July 18, 2025 10:40 AM
>>> To: GCC Patches
>>> Cc: Tamar Christina ; Richard
1 - 100 of 117 matches
Mail list logo