Jeff Law writes:
> On 10/2/24 8:39 PM, Sam James wrote:
>> Valgrind doesn't error out by default which means bootstrap issues like
>> in PR116945 can easily be missed: pass --exit-errorcode=1 to handle this.
>> While here, also set --trace-children=yes to cover child processes
>> of tools invoked
Jakub Jelinek writes:
> On Fri, Oct 04, 2024 at 12:52:11PM +0100, Jonathan Wakely wrote:
>> This doesn't really belong in our testsuite, because the sole purpose of
>> the new test is to find bugs in the Glibc wrappers (like the one linked
>> below). But maybe it's a kindness to do it in our test
ChangeLog:
* MAINTAINERS: Add myself to write after approval.
---
Hello,
I just noticed that I wasn't yet in the write after approval section,
so I just committed this patch.
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ded5b3d4f643..92
Introduce a new RAII class diagnostic_output_file to track ownership
of the FILE * for SARIF output.
In particular, the .sarif file is now opened immediately, rather
than at the end of the compile, and so will fail earlier if the
file can't be opened.
Doing so fixes a couple of ICEs in -fdiagnost
On Fri, Oct 4, 2024 at 10:51 AM Andrew Carlotti wrote:
>
> This patch series adds 7 new flags for features that were previously available
> in GCC only as part of an architecture version. It also fixes one other
> instance where an architecture version was used in a check instead of a
> feature
Thanks for the reviews. I made the suggested change in the commit
message, committed, and pushed it:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=20ce363c557d6458ec3193ab4e7df760fbe34976
Thanks,
Saurabh
On 10/4/2024 10:09 AM, saurabh@arm.com wrote:
In ac4cdf5cb43c0b09e81760e2a1902ceebcf1
On Fri, 4 Oct 2024 at 19:37, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/backports?
OK for all branches (assuming we already have LWG 3392 on the branches).
>
> -- >8 --
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/ranges_base.h (__distance_fn::
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/backports?
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (__distance_fn::operator()):
Adjust iterator/sentinel overloads as per LWG 3664.
* testsuite/24_iterators/range_operations/distance.cc:
On Wed, Oct 02, 2024 at 06:13:38PM +0100, Andre Vieira wrote:
>
> This patch splits out FCMA as a feature from Armv8.3-A and adds it as a
> separate
> feature bit which now controls 'TARGET_COMPLEX'.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-arches.def (FCMA): New feature bit, can n
GCC does not emit tlbi instructions, so this only affects the flags
passed through to the assembler.
gcc/ChangeLog:
* config/aarch64/aarch64-arches.def (V8_7A): Add XS.
* config/aarch64/aarch64-option-extensions.def (XS): New flag.
diff --git a/gcc/config/aarch64/aarch64-arches.
gcc/ChangeLog:
* config/aarch64/aarch64-arches.def (V8_4A): Add RCPC2.
* config/aarch64/aarch64-option-extensions.def
(RCPC2): New flag.
(RCPC3): Add RCPC2 dependency.
* config/aarch64/aarch64.h (TARGET_RCPC2): Use new flag.
gcc/testsuite/ChangeLog:
GCC does not currently emit the wfet or wfit instructions, so this
primarily affects the flags passed through to the assembler.
gcc/ChangeLog:
* config/aarch64/aarch64-arches.def (V8_7A): Add WFXT.
* config/aarch64/aarch64-option-extensions.def (WFXT): New flag.
diff --git a/gcc
GCC does not currently emit the axflag or xaflag instructions, so this
primarily affects the flags passed through to the assembler.
gcc/ChangeLog:
* config/aarch64/aarch64-arches.def (V8_5A): Add FLAGM2.
* config/aarch64/aarch64-option-extensions.def (FLAGM2): New flag.
gcc/tests
gcc/ChangeLog:
* config/aarch64/aarch64-arches.def (V8_5A): Add FRINTTS
* config/aarch64/aarch64-option-extensions.def (FRINTTS): New flag.
* config/aarch64/aarch64.h (TARGET_FRINT): Use new flag.
* config/aarch64/arm_acle.h: Use new flag for frintts intrinsics.
gcc/ChangeLog:
* config/aarch64/aarch64-arches.def (V8_3A): Add JSCVT.
* config/aarch64/aarch64-option-extensions.def (JSCVT): New flag.
* config/aarch64/aarch64.h (TARGET_JSCVT): Use new flag.
* config/aarch64/arm_acle.h: Use new flag for jscvt intrinsics.
gcc/tes
This includes +fcma as a dependency of +sve, and means that we can
finally support fcma intrinsics on a64fx.
Also add fcma to the Features list in several cpunative testcases that
incorrectly included sve without fcma.
gcc/ChangeLog:
* config/aarch64/aarch64-arches.def (V8_3A): Add FCMA.
gcc/ChangeLog:
* config/aarch64/aarch64.cc
(aarch64_expand_epilogue): Use TARGET_PAUTH.
* config/aarch64/aarch64.md: Update comment.
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index
e7bb3278a27eca44c46afd26069d608218198a54..cf1107127fd5d9e
This patch series adds 7 new flags for features that were previously available
in GCC only as part of an architecture version. It also fixes one other
instance where an architecture version was used in a check instead of a feature
flag.
Bootstrapped and regression tested as a whole on aarch64. I
чт, 3 окт. 2024 г. в 12:19, Georg-Johann Lay :
>
> avr_out_sbxx_branch calls jump_over_one_insn_p which may clobber
> recog_data.operand as is calls extract on the next insn.
>
> A fix is to make a copy of avr_out_sbxx_branch`s incoming operands.
>
> Ok to apply?
Ok.
Please apply.
Denis.
>
> Joh
On Oct 4, 2024, at 9:40 AM, Georg-Johann Lay wrote:
>
> Some of the float64 and float32x test cases are using double built-ins
> and hence require double64plus resp. double_float32xplus, i.e. double
> is at least as good as float32x.
>
> This patch adds according dg-require-effective-target filt
пт, 4 окт. 2024 г. в 19:07, Christophe Lyon :
>
> On Fri, 4 Oct 2024 at 16:59, Siarhei Volkau wrote:
> >
> > Hello,
> >
> > пт, 4 окт. 2024 г. в 16:48, Christophe Lyon :
> > >
> > > Hi!
> > >
> > >
> > > On Mon, 8 Jul 2024 at 10:57, Siarhei Volkau wrote:
> > > >
> > > > ping
> > > >
> > > > чт,
On Thu, Oct 03, 2024 at 12:14:35PM -0400, Jason Merrill wrote:
> Agreed, the padding bits have indeterminate values (or erroneous in C++26),
> so it's correct for infoleak-1.c to complain about 4b.
I've been afraid what the kernel people would say about this change (because
reading Linus' mails sh
Some of the float64 and float32x test cases are using double built-ins
and hence require double64plus resp. double_float32xplus, i.e. double
is at least as good as float32x.
This patch adds according dg-require-effective-target filters.
(But only for test cases where I can verify that they are wo
Hi Saurabh,
This looks good, one little nit:
> gcc/ChangeLog:
>
> * config/aarch64/iterators.md: Move UNSPEC_COND_SMAX and
> UNSPEC_COND_SMIN to correct iterators.
This should also have the PR target/116934 before it - it's fine to change it
when you commit.
Speaking of which,
writes:
> In ac4cdf5cb43c0b09e81760e2a1902ceebcf1a135, I introduced a bug where
> I put the new unspecs, UNSPEC_COND_SMAX and UNSPEC_COND_SMIN, into the
> wrong iterator.
>
> I should have put new unspecs in SVE_COND_FP_MAXMIN but I put it in
> SVE_COND_FP_BINARY_REG instead. That was incorrect be
On Fri, 4 Oct 2024 at 16:59, Siarhei Volkau wrote:
>
> Hello,
>
> пт, 4 окт. 2024 г. в 16:48, Christophe Lyon :
> >
> > Hi!
> >
> >
> > On Mon, 8 Jul 2024 at 10:57, Siarhei Volkau wrote:
> > >
> > > ping
> > >
> > > чт, 20 июн. 2024 г. в 12:09, Siarhei Volkau :
> > > >
> > > > This patch deals wi
Hi,
The patch for 'arm: Fix missed CE optimization for armv8.1-m.main [PR
116444]' introduced regressions with arm targets that used 'noce' before.
This is because it would approve all noce optimisations without using
the default cost check. Not sure why this didn't show up in my original
test
On Thu, 2024-10-03 at 11:15 -0700, Andi Kleen wrote:
> > The only consumer I know of for the JSON time report data is in the
> > integration tests I wrote for -fanalyzer, which assumes that all
> > fields
> > are present when printing, and then goes on to use the "user" times
> > for
> > summarizin
Hello Christophe,
Christophe Lyon writes:
> On Fri, 1 Mar 2024 at 15:29, Richard Earnshaw (lists)
> wrote:
>>
>> On 01/03/2024 14:23, Andre Vieira (lists) wrote:
>> > Hi Thiago,
>> >
>> > Thanks for this, LGTM but I can't approve this, CC'ing Richard.
>> >
>> > Do have a nitpick, in the gcc/tes
On Fri, 4 Oct 2024, Jeff Law wrote:
> > More importantly may I ask you to review the second paragraph of commit
> > 6c3365e715fa ("RISC-V: Also handle sign extension in branch costing") to
> > see if any of the other issues referred there have also been now sorted
> > and mention that in the cha
On Fri, Oct 4, 2024 at 2:11 PM H.J. Lu wrote:
>
> Since naked functions should not enable stack protector, define
> TARGET_STACK_PROTECT_RUNTIME_ENABLED_P to disable stack protector
> for naked functions.
>
> gcc/
>
> PR target/116962
> * config/i386/i386.cc (ix86_stack_protect_runtime_enabled_p):
On Fri, 4 Oct 2024 at 15:05, Siddhesh Poyarekar wrote:
>
> On 2024-10-04 07:52, Jonathan Wakely wrote:
> > This doesn't really belong in our testsuite, because the sole purpose of
> > the new test is to find bugs in the Glibc wrappers (like the one linked
> > below). But maybe it's a kindness to d
On Fri, Oct 4, 2024 at 11:58 AM Jakub Jelinek wrote:
>
> Hi!
>
> The PR notes that we don't emit optimal code for C++ spaceship
> operator if the result is returned as an integer rather than the
> result just being compared against different values and different
> code executed based on that.
> So
On Fri, Oct 04, 2024 at 10:03:36AM -0400, Siddhesh Poyarekar wrote:
> > Add a new testcase that repeats 17_intro/names.cc but with
> > _FORTIFY_SOURCE defined, to find problems in Glibc fortify wrappers like
> > https://sourceware.org/bugzilla/show_bug.cgi?id=32052 (which is fixed
> > now).
> >
>
Hello,
пт, 4 окт. 2024 г. в 16:48, Christophe Lyon :
>
> Hi!
>
>
> On Mon, 8 Jul 2024 at 10:57, Siarhei Volkau wrote:
> >
> > ping
> >
> > чт, 20 июн. 2024 г. в 12:09, Siarhei Volkau :
> > >
> > > This patch deals with consequences but not the root cause though.
> > >
> > > There are 5 cases whic
On Thu, 3 Oct 2024, Jason Merrill wrote:
> On 10/3/24 12:38 PM, Jason Merrill wrote:
> > On 10/2/24 7:50 AM, Richard Biener wrote:
> > > This reduces peak memory usage by 20% for a specific testcase.
> > >
> > > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> > >
> > > It's very ugly so I
This patch adds parsing and translation of the 'to' and 'from' clauses
for the 'target update' construct in Fortran.From da8ab0cb38d2bc347cf902ec417b0397c28e24e2 Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung
Date: Fri, 4 Oct 2024 15:16:38 +0100
Subject: [PATCH 5/5] openmp, fortran: Add support
This patch adds support for iterators in the map clause of OpenMP target
constructs.
The parsing and translation of iterators in the front-end works the same
way as for the affinity and depend clauses, except for putting the
iterator into the OMP_CLAUSE_ITERATOR of the clause.
The iterator g
This patch extends the previous patch to cover to/from clauses in
'target update'.From 1c8bf84ec99fe2fd371e345f012eb0d84a923153 Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung
Date: Fri, 4 Oct 2024 15:16:21 +0100
Subject: [PATCH 3/5] openmp: Add support for iterators in 'target update'
clauses
Am 04.10.24 um 16:32 schrieb Jakub Jelinek:
On Fri, Oct 04, 2024 at 08:09:48AM -0600, Jeff Law wrote:
On 10/4/24 7:46 AM, Georg-Johann Lay wrote:
This patch implements TARGET_FLOATN_MODE which maps
_Float32[x] to SFmode and _Float64[x] to DFmode.
There is currently no library support for ext
This patch modifies the C and C++ parsers to accept an iterator as a map
type modifier, storing it in the OMP_CLAUSE_ITERATOR argument of the
clause. When finishing clauses, any clauses generated from a clause with
iterators also has the iterator applied to them.
During gimplification, check_o
This patch factors out the code to calculate the number of iterations
required and to generate the iteration loop into separate functions from
gimplify_omp_depend for reuse later.
I have also replaced the 'TREE_CODE (*tp) == TREE_LIST && ...' checks
used for detecting an iterator clause with a ma
This is a further improved patch series to that posted at:
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662138.html
The main change is that the expansion of the iterators is pushed back
further to the omp-lowering stage. This is because the recently
committed deep-mapping support (a
On 10/3/24 5:40 PM, Maciej W. Rozycki wrote:
More importantly may I ask you to review the second paragraph of commit
6c3365e715fa ("RISC-V: Also handle sign extension in branch costing") to
see if any of the other issues referred there have also been now sorted
and mention that in the chan
On Fri, Oct 04, 2024 at 08:09:48AM -0600, Jeff Law wrote:
>
>
> On 10/4/24 7:46 AM, Georg-Johann Lay wrote:
> > This patch implements TARGET_FLOATN_MODE which maps
> > _Float32[x] to SFmode and _Float64[x] to DFmode.
> >
> > There is currently no library support for extended float types,
> > but
On Fri, 04 Oct 2024 07:04:59 PDT (-0700), jeffreya...@gmail.com wrote:
On 10/4/24 1:23 AM, Tsung Chun Lin wrote:
0001-RISC-V-libgcc-Fix-incorrect-.cfi_offset-for-saving-r.patch
From 8b3c5ebe8aacbcc4ddf1be8dea9a555e7e1bcc39 Mon Sep 17 00:00:00 2001
From: Jim Lin
Date: Fri, 4 Oct 2024 14:48:1
On 10/3/24 5:40 PM, Maciej W. Rozycki wrote:
On Thu, 3 Oct 2024, Jeff Law wrote:
We can remove a couple of XFAILs in the rv32 space as it's behaving much more
like rv64 at this point.
I'm glad to see them gone. I have a couple of concerns with your change
though.
Given:
* gc
On 10/3/24 5:58 PM, Andrew Pinski wrote:
On Thu, Oct 3, 2024 at 4:41 PM Maciej W. Rozycki wrote:
On Thu, 3 Oct 2024, Jeff Law wrote:
We can remove a couple of XFAILs in the rv32 space as it's behaving much more
like rv64 at this point.
I'm glad to see them gone. I have a couple of co
On 10/4/24 7:46 AM, Georg-Johann Lay wrote:
This patch implements TARGET_FLOATN_MODE which maps
_Float32[x] to SFmode and _Float64[x] to DFmode.
There is currently no library support for extended float types,
but these settings are more reasonable for avr (and they make
more tests pass).
Ok
On 2024-10-04 10:03, Siddhesh Poyarekar wrote:
diff --git a/libstdc++-v3/testsuite/17_intro/names.cc
b/libstdc++-v3/testsuite/17_intro/names.cc
index 6b9a3639aad..bbf45b93dee 100644
--- a/libstdc++-v3/testsuite/17_intro/names.cc
+++ b/libstdc++-v3/testsuite/17_intro/names.cc
@@ -377,4 +377,11 @@
On 10/2/24 8:39 PM, Sam James wrote:
Valgrind doesn't error out by default which means bootstrap issues like
in PR116945 can easily be missed: pass --exit-errorcode=1 to handle this.
While here, also set --trace-children=yes to cover child processes
of tools invoked during the build.
Note th
On 10/4/24 1:23 AM, Tsung Chun Lin wrote:
0001-RISC-V-libgcc-Fix-incorrect-.cfi_offset-for-saving-r.patch
From 8b3c5ebe8aacbcc4ddf1be8dea9a555e7e1bcc39 Mon Sep 17 00:00:00 2001
From: Jim Lin
Date: Fri, 4 Oct 2024 14:48:12 +0800
Subject: [PATCH] RISC-V/libgcc: Fix incorrect .cfi_offset for s
On 2024-10-04 07:52, Jonathan Wakely wrote:
This doesn't really belong in our testsuite, because the sole purpose of
the new test is to find bugs in the Glibc wrappers (like the one linked
below). But maybe it's a kindness to do it in our testsuite, because we
already have this test in place, and
Hi!
On Mon, 8 Jul 2024 at 10:57, Siarhei Volkau wrote:
>
> ping
>
> чт, 20 июн. 2024 г. в 12:09, Siarhei Volkau :
> >
> > This patch deals with consequences but not the root cause though.
> >
> > There are 5 cases which are subjects to rewrite:
> > case #1:
> > mov ip, r1
> > add r2, ip
> >
This patch implements TARGET_FLOATN_MODE which maps
_Float32[x] to SFmode and _Float64[x] to DFmode.
There is currently no library support for extended float types,
but these settings are more reasonable for avr (and they make
more tests pass).
Ok for trunk?
Johann
--
AVR: Implement TARGET_FL
Hi Thiago,
On Fri, 1 Mar 2024 at 15:29, Richard Earnshaw (lists)
wrote:
>
> On 01/03/2024 14:23, Andre Vieira (lists) wrote:
> > Hi Thiago,
> >
> > Thanks for this, LGTM but I can't approve this, CC'ing Richard.
> >
> > Do have a nitpick, in the gcc/testsuite/ChangeLog: remove 'gcc/testsuite'
>
On 10/4/24 12:42 AM, Richard Biener wrote:
On Thu, Oct 3, 2024 at 3:15 AM Andrew Waterman wrote:
On Wed, Oct 2, 2024 at 4:41 PM Jeff Law wrote:
On 10/2/24 4:39 PM, Andrew Waterman wrote:
On Wed, Oct 2, 2024 at 5:56 AM Jeff Law wrote:
On 9/5/24 12:52 PM, Palmer Dabbelt wrote:
We
Hi Richard,
> On 1 Oct 2024, at 13:35, Richard Sandiford wrote:
>
> External email: Use caution opening links or attachments
>
>
> Kyrylo Tkachov writes:
>> Hi all,
>> I'd like to use a value of 64 bytes for the L1 cache size for Armv9-A
>> generic tuning.
>> As described in g:9a99559a478111f
There are more failures that I haven't found yet, because running make
check-parallel seems to take several days (because I'm running with
GLIBCXX_TESTSUITE_STDS=98,11,14,17,20,23,26).
We can fix the rest later. Pushed to trunk.
-- >8 --
Some of these are due to no longer using #pragma GCC syst
On Fri, 4 Oct 2024 at 13:53, Dmitry Ilvokhin wrote:
>
> On Fri, Oct 04, 2024 at 10:20:27AM +0100, Jonathan Wakely wrote:
> > On Fri, 4 Oct 2024 at 10:19, Jonathan Wakely wrote:
> > >
> > > On Fri, 4 Oct 2024 at 07:53, Richard Biener
> > > wrote:
> > > >
> > > > On Wed, Oct 2, 2024 at 8:26 PM Jo
The following adds basic support for single-lane SLP .GOMP_SIMD_LANE
vectorization, in particular it enables SLP discovery.
* tree-vect-slp.cc (no_arg_map): New.
(vect_get_operand_map): Handle IFN_GOMP_SIMD_LANE.
(vect_build_slp_tree_1): Likewise.
* tree-vect-stmts.
On Fri, Oct 04, 2024 at 10:20:27AM +0100, Jonathan Wakely wrote:
> On Fri, 4 Oct 2024 at 10:19, Jonathan Wakely wrote:
> >
> > On Fri, 4 Oct 2024 at 07:53, Richard Biener
> > wrote:
> > >
> > > On Wed, Oct 2, 2024 at 8:26 PM Jonathan Wakely wrote:
> > > >
> > > > On Wed, 2 Oct 2024 at 19:16, Jo
On 10/4/24 8:22 AM, Jakub Jelinek wrote:
On Fri, Oct 04, 2024 at 12:19:03PM +0200, Jakub Jelinek wrote:
Though, maybe the tests should have both the deprecated syntax and the
non-deprecated one...
Here is a variant of the patch which does that.
Tested on x86_64-linux and i686-linux, ok for tr
'omp allocate' permits to use a different (specified) allocator and
alignment for both stack/automatic and static/saved variables; the latter
takes only predefined allocators. Currently, only C and Fortran are
support for stack/automatic variables; static variables are rejected
before the attached
On Fri, 4 Oct 2024 at 13:28, Jakub Jelinek wrote:
>
> On Fri, Oct 04, 2024 at 12:52:11PM +0100, Jonathan Wakely wrote:
> > This doesn't really belong in our testsuite, because the sole purpose of
> > the new test is to find bugs in the Glibc wrappers (like the one linked
> > below). But maybe it's
On Fri, Oct 04, 2024 at 12:52:11PM +0100, Jonathan Wakely wrote:
> This doesn't really belong in our testsuite, because the sole purpose of
> the new test is to find bugs in the Glibc wrappers (like the one linked
> below). But maybe it's a kindness to do it in our testsuite, because we
> already h
On Fri, Oct 04, 2024 at 12:19:03PM +0200, Jakub Jelinek wrote:
> Though, maybe the tests should have both the deprecated syntax and the
> non-deprecated one...
Here is a variant of the patch which does that.
Tested on x86_64-linux and i686-linux, ok for trunk?
2024-10-04 Jakub Jelinek
The following fixes the order of decrementing the SLP mode and
the dumping.
Build on x86_64-unknown-linux-gnu, pushed.
* tree-vect-loop.cc (vect_analyze_loop_2): Derement 'slp'
before dumping which stage we're starting.
---
gcc/tree-vect-loop.cc | 6 +++---
1 file changed, 3 inse
Since naked functions should not enable stack protector, define
TARGET_STACK_PROTECT_RUNTIME_ENABLED_P to disable stack protector
for naked functions.
gcc/
PR target/116962
* config/i386/i386.cc (ix86_stack_protect_runtime_enabled_p): New
function.
(TARGET_STACK_PROTECT_RUNTIME_ENABLED_P): New.
Hi Andre,
> On 2 Oct 2024, at 19:13, Andre Vieira wrote:
>
> External email: Use caution opening links or attachments
>
>
> As per the AArch64 ISA FEAT_SME does not require FEAT_SVE2, so we are removing
> that false dependency in GCC. However, we chose for now to not support this
> combinatio
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660958.html
On Wed, Aug 21, 2024 at 09:41:31AM +1000, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> -- >8 --
>
> When compiling with '-fdeclone-ctor-dtor' (enabled by default with -Os),
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660957.html
On Wed, Aug 21, 2024 at 09:40:25AM +1000, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> -- >8 --
>
> The ICE in the linked PR is caused because maybe_clone_decl is not
> pre
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660956.html.
On Wed, Aug 21, 2024 at 09:38:44AM +1000, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> -- >8 --
>
> The Itanium ABI has specific rules for when virtual tables for dynamic
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660134.html.
On Thu, Sep 12, 2024 at 01:35:38PM -0400, Patrick Palka wrote:
> On Fri, 23 Aug 2024, Nathaniel Shead wrote:
>
> > On Thu, Aug 22, 2024 at 02:20:14PM -0400, Patrick Palka wrote:
> > > On Mon, 12 Aug 2024, Nathaniel Shead
Hi Andre,
> On 2 Oct 2024, at 19:13, Andre Vieira wrote:
>
> External email: Use caution opening links or attachments
>
>
> This patch series removes the requirement of SVE2 for SME, so when a user
> passes +sme, SVE2 is not enabled as a result of that.
> We do this to be compliant with the IS
Ping for -Wno-pragma-once-outside-header.
On Thursday, June 27th, 2024 at 11:00 AM, Ken Matsui
wrote:
>
>
> Ping.
>
>
> On Sat, Jun 15, 2024 at 10:30 PM Ken Matsui kmat...@gcc.gnu.org wrote:
>
> > This patch adds a warning switch for "#pragma once in main file". The
> > warning option name
This doesn't really belong in our testsuite, because the sole purpose of
the new test is to find bugs in the Glibc wrappers (like the one linked
below). But maybe it's a kindness to do it in our testsuite, because we
already have this test in place, and one Glibc bug was already found
thanks to Sam
On Fri, Oct 4, 2024 at 12:04 PM Jakub Jelinek wrote:
>
> Hi!
>
> The PR notes that the new pch_save/pch_restore methods I've added
> recently invoke UB if either m_classification_history.address ()
> or m_push_list.address () is NULL (which can happen if those vectors
> are empty (and in the pch_s
On Fri, Oct 4, 2024 at 11:20 AM Jonathan Wakely wrote:
>
> On Fri, 4 Oct 2024 at 10:19, Jonathan Wakely wrote:
> >
> > On Fri, 4 Oct 2024 at 07:53, Richard Biener
> > wrote:
> > >
> > > On Wed, Oct 2, 2024 at 8:26 PM Jonathan Wakely wrote:
> > > >
> > > > On Wed, 2 Oct 2024 at 19:16, Jonathan
On Fri, 4 Oct 2024 at 03:09, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14 and perhaps
> 13?
OK for all, thanks.
>
> -- >8 --
>
> This implements the following small LWG issues:
>
> 3848. adjacent_view, adjacent_transform_view and slide_view missing bas
Testing gcc.target/aarch64/sve/permute_2.c without the associated GCC
patch triggered an unrecognisable insn ICE for the svbfloat16_t tests.
This was because the implementation of general two-vector permutes
requires two TBLs and an ORR, with the ORR being represented as an
unspec for floating-poin
On Fri, Oct 4, 2024 at 12:12 PM Jakub Jelinek wrote:
>
> Hi!
>
> The following testcase ICEs, because the ix86_expand_int_compare
> optimization to use {,v}ptest assumes there are instructions for all
> 16-byte vector modes. That isn't the case, we only have one for
> V16QI, V8HI, V4SI, V2DI, V1T
For Advanced SIMD modes, aarch64_evpc_reencode tests whether
a permute in a narrow element mode can be done more cheaply
in a wider mode. For example, { 0, 1, 8, 9, 4, 5, 12, 13 }
on V8HI is a natural TRN1 on V4SI ({ 0, 4, 2, 6 }).
This patch extends the code to handle SVE data and predicate
mode
This is the main patch for PR116583. Previously, we only
supported VLA SLP permutations for which the output and inputs
have the same number of lanes, and for which that number of
lanes divides the number of vector elements.
The patch extends this to handle:
(1) "packs" of a single 2N-vector inp
The repeating_p case previously handled the specific situation
in which the inputs have N lanes and the output has N lanes,
where N divides the number of vector elements. In that case,
every output uses the same permute vector.
The code was therefore structured so that the outer loop only
constru
Taking the !repeating_p route for VLA vectors causes analysis
to fail, but it wasn't clear from the dump files when this
had happened, and which node caused it.
gcc/
PR tree-optimization/116583
* tree-vect-slp.cc (vectorizable_slp_permutation_1): Add more
dump messages.
---
The main patch for PR116583 needs to create variable indices into
an input vector. This pre-patch changes the types to allow that.
There is no pretty-print format for poly_uint64 because of issues
with passing C++ objects through "...".
gcc/
PR tree-optimization/116583
* tree-vec
This series should fix the target-independent parts of PR116583.
(We also need some target-specific patches, to be posted separately.)
The explanations are in the individual commit messages, but I've
attached a -b diff below in case my attempt to split the patch up
has just obfuscated things inste
Hello world,
the original messages seems to have been rejected because the patch was
too big. The patch (wich was not rejected for fortran@) can be found at
https://gcc.gnu.org/pipermail/fortran/2024-October/061127.html
Weitergeleitete Nachricht
Betreff: [patch, fortran] Imple
On Thu, Oct 03, 2024 at 12:39:59PM -0400, Jason Merrill wrote:
> * g++.dg/cpp26/unevalstr1.C
This patch didn't touch unevalstr2.C which now FAILs because of the new
warnings in C++23 mode (the testcase is target { c++11 && c++23_down }, so
isn't run in C++26).
The intent in both of those te
The first patch within the GSoC project "Offloading to a separate process
on the same host".
The project focuses on streamlining the debugging and development process
for code intended for offloading to devices like GPUs. It proposes a method
to execute offloaded code in a separate CPU process on t
Hi!
The following testcase ICEs, because the ix86_expand_int_compare
optimization to use {,v}ptest assumes there are instructions for all
16-byte vector modes. That isn't the case, we only have one for
V16QI, V8HI, V4SI, V2DI, V1TI, V4SF and V2DF, not for
V8HF nor V8BF.
The following patch fixes
On Fri, Oct 4, 2024 at 12:07 PM Jakub Jelinek wrote:
>
> Hi!
>
> While *minmax3_1 correctly uses
>if (MEM_P (operands[1]))
> operands[1] = force_reg (mode, operands[1]);
> to ensure operands[1] is not a MEM, *minmax3_2 does it wrongly
> by calling force_reg but ignoring its return value.
Hi!
While *minmax3_1 correctly uses
if (MEM_P (operands[1]))
operands[1] = force_reg (mode, operands[1]);
to ensure operands[1] is not a MEM, *minmax3_2 does it wrongly
by calling force_reg but ignoring its return value.
The following borderingly obvious patch fixes that, bootstrapped/reg
Hi!
The PR notes that the new pch_save/pch_restore methods I've added
recently invoke UB if either m_classification_history.address ()
or m_push_list.address () is NULL (which can happen if those vectors
are empty (and in the pch_save case nothing has been pushed into them
before either). While t
Hi!
The PR notes that we don't emit optimal code for C++ spaceship
operator if the result is returned as an integer rather than the
result just being compared against different values and different
code executed based on that.
So e.g. for
template
auto foo (T x, T y) { return x <=> y; }
for both
The following makes sure the emitted even/odd extraction scheme
follows one that ends up with actual trivial even/odd extract permutes.
When we choose a level 2 extract we generate { 0, 1, 4, 5, ... }
which for example the x86 backend doesn't recognize with just SSE
and QImode elements. So this no
Tested x86_64-linux (and tested the affected code by manually bodging
the _GLIBCXX_USE_PTHREAD_RWLOCK_T macro).
Pushed to trunk.
-- >8 --
C++20 deprecates implicit capture of 'this', so change [=] to [this] for
all lambda expressions in . This only shows up on targets
where _GLIBCXX_USE_PTHREAD_
When failing using forced SLP we do not print the non-SLP failure
mode which reads slightly different. Massage the expectation a bit.
Pushed.
* gcc.dg/vect/pr65947-8.c: Adjust.
---
gcc/testsuite/gcc.dg/vect/pr65947-8.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
When making the testcase use aligned accesses I botched up the
copy&paste. Fixed.
Pushed.
PR tree-optimization/99856
* gcc.dg/vect/pr99856.c: Fix copy&paste errors.
---
gcc/testsuite/gcc.dg/vect/pr99856.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gc
1 - 100 of 121 matches
Mail list logo
