On Fri, 4 Oct 2024 at 10:00, Kyrylo Tkachov wrote:
>
>
>
> > On 3 Oct 2024, at 21:44, Christophe Lyon wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > Add prototypes for __init_cpu_features_resolver and
> > __init_cpu_features to avoid warnings due to -Wmissing-
This is a regression present on the 14 branch only: the expander gets confused
when trying to insert the finalizer of a procedure that contains a package as
a subunit. The offending code no longer exists on the mainline so this adds
the minimal fix to address the issue.
Tested on x86-64/Linux,
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
пт, 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
> > > >
> > > > чт,
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
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 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
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 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
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, 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 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
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 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
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Thursday, October 3, 2024 4:45 PM
> To: Richard Sandiford
> Cc: Soumya AR ; Tamar Christina
> ; gcc-patches@gcc.gnu.org; Richard Earnshaw
> ; Jennifer Schmitz ;
> Pengxuan Zheng (QUIC)
> Subject: Re: [PATCH] aarch64: Optimise calls to l
0001-RISC-V-libgcc-Fix-incorrect-.cfi_offset-for-saving-r.patch
Description: Binary data
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
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
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!
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
> >
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
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 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 Thu, Oct 3, 2024 at 6:09 PM Andrew Pinski wrote:
>
> While looking into the ifcombine, I noticed that rewrite_to_defined_overflow
> was rewriting already defined code. In the previous attempt at fixing this,
> the review mentioned we should not be calling rewrite_to_defined_overflow
> in those
On Thu, Oct 3, 2024 at 6:09 PM Andrew Pinski wrote:
>
> After fixing loop-im to do the correct overflow rewriting
> for pointer types too. We end up with code like:
> ```
> _9 = (unsigned long) &g;
> _84 = _9 + 18446744073709551615;
> _11 = _42 + _84;
> _44 = (signed char *) _11;
> ...
>
> On 3 Oct 2024, at 21:44, Christophe Lyon wrote:
>
> External email: Use caution opening links or attachments
>
>
> Since
> Commit c608ada288ced0268c1fd4136f56c34b24d4
> Author: Zac Walker
> CommitDate: 2024-01-23 15:32:30 +
>
> Ifdef `.hidden`, `.type`, and `.size` pseudo
gcc/testsuite/ChangeLog:
* c-c++-common/analyzer/flex-without-call-summaries.c: Add missing
brace.
* c-c++-common/analyzer/malloc-callbacks.c: Ditto.
* gcc.dg/Wstringop-overflow-79.c: Ditto.
* gcc.dg/Wstringop-overflow-80.c: Ditto.
---
.../analyzer/flex-without-ca
This didn't show up until the previous commit which fixed the directive
syntax. The indexing was off for the notes.
gcc/testsuite/ChangeLog:
* gcc.dg/Wstringop-overflow-79.c: Fix index for notes.
* gcc.dg/Wstringop-overflow-80.c: Ditto.
---
gcc/testsuite/gcc.dg/Wstringop-overflow
On Fri, 4 Oct 2024 at 10:50, Kyrylo Tkachov wrote:
>
>
>
> > On 3 Oct 2024, at 21:44, Christophe Lyon wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > When --enable-werror is enabled when running the top-level configure,
> > it passes --enable-werror-always to s
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 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'
>
As in https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663185.html,
this patch guards the simplification x / y * y == x -> x % y == 0 in
match.pd for vector types by a check for:
1) Support of the mod optab for vectors OR
2) Application before vector lowering for non-VL vectors.
The patch
> On 1 Oct 2024, at 6:17 PM, Richard Sandiford
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> Soumya AR writes:
>> Currently, we vectorize CTZ for SVE by using the following operation:
>> .CTZ (X) = (PREC - 1) - .CLZ (X & -X)
>>
>> Instead, this patch expands CTZ t
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
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/
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, 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
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
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
On Fri, Oct 4, 2024, 12:07 AM Richard Biener
wrote:
> On Thu, Oct 3, 2024 at 6:09 PM Andrew Pinski
> wrote:
> >
> > After fixing loop-im to do the correct overflow rewriting
> > for pointer types too. We end up with code like:
> > ```
> > _9 = (unsigned long) &g;
> > _84 = _9 + 1844674407370
Hi Victor,
> -Original Message-
> From: Victor Do Nascimento
> Sent: Wednesday, October 2, 2024 5:26 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Tamar Christina ; richard.guent...@gmail.com;
> Victor Do Nascimento
> Subject: [PATCH] middle-end: reorder masking priority of math functions
>
>
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
'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 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
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 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
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
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 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
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
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
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 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).
> >
>
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, 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 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
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
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,
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
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
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::
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
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
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 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.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
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 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
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
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:
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
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
> On 3 Oct 2024, at 21:44, Christophe Lyon wrote:
>
> External email: Use caution opening links or attachments
>
>
> Add prototypes for __init_cpu_features_resolver and
> __init_cpu_features to avoid warnings due to -Wmissing-prototypes.
>
>libgcc/
>* config/aarch64/cpuinfo.
On Thu, 3 Oct 2024, Jason Merrill wrote:
> On 10/2/24 7:53 AM, Richard Biener wrote:
> > For a specific testcase a lot of compile-time is spent in re-hashing
> > hashtable elements upon expansion. The following records the hash
> > in the hash element. This speeds up compilation by 20%.
> >
> >
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 because the
SVE_COND_
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
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
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.
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
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
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
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
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
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.
---
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 Wakely wrote:
> > > >
> > > > On Wed, 2 Oct 2024 at 19:15, Dmitry Ilvokhi
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 Wakely wrote:
> > >
> > > On Wed, 2 Oct 2024 at 19:15, Dmitry Ilvokhin wrote:
> > > >
> > > > Instead of looping over every byte of the tail
On 10/4/24 09:32, Tamar Christina wrote:
Hi Victor,
-Original Message-
From: Victor Do Nascimento
Sent: Wednesday, October 2, 2024 5:26 PM
To: gcc-patches@gcc.gnu.org
Cc: Tamar Christina ; richard.guent...@gmail.com;
Victor Do Nascimento
Subject: [PATCH] middle-end: reorder masking pr
> On 3 Oct 2024, at 21:44, Christophe Lyon wrote:
>
> External email: Use caution opening links or attachments
>
>
> When --enable-werror is enabled when running the top-level configure,
> it passes --enable-werror-always to subdirs. Some of them, like
> libgcc, ignore it.
>
> This patch ad
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 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
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
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/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/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),
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
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
1 - 100 of 121 matches
Mail list logo
