Paul-Antoine Arras wrote:
This patch introduces the OMP_DISPATCH tree node, as well as two new clauses
`nocontext` and `novariants`. It defines/exposes interfaces that will be
used in subsequent patches that add front-end and middle-end support, but
nothing generates these nodes yet.
LGTM. Than
Hi Saurabh,
> On 30 Sep 2024, at 10:36 PM, Saurabh Jha wrote:
>
> External email: Use caution opening links or attachments
>
>
> Hi Soumya,
>
> Thank you for the patch. Two clarifications:
>
> In the instruction pattern's output string, why did you add the 'Z'
> prefix before operands? (%0 -
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.
gcc/ChangeLog:
PR other/116945
PR other/116947
* gcc.cc (execute): Pass --error-exitcode=2 to Valgrind.
---
gcc/gcc.cc | 7 +++
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 that this only handles tools invoke during t
--enable-checking=valgrind has two functions:
1) run generator programs with Valgrind;
2) run GCC itself with Valgrind (GCC invokes Valgrind in the driver).
These two patches make sure that Valgrind is told to abort on errors
rather than warning-and-continuing, allowing issues to go undetected
or
On Wed, 2024-10-02 at 14:14 -0700, Andi Kleen wrote:
> From: Andi Kleen
>
> Time vars normally use times(2) to get the user/sys/wall time, which
> is always a
> system call. I don't think the system time is very useful because
> most overhead
> is in user time. If we only use the wall (or monoton
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 have cheap logical ops, so let's just move this back to the default
> >>> to
Early-RA was considering throwing instructions as being dead and removing
them even if -fno-delete-dead-exceptions was in use. This fixes that oversight.
Built and tested for aarch64-linux-gnu.
PR target/116927
gcc/ChangeLog:
* config/aarch64/aarch64-early-ra.cc (early_ra::is_de
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 have cheap logical ops, so let's just move this back to the default
to take advantage of the standard branch/op hueristics.
gcc/ChangeLog:
PR ta
On Wed, Oct 2, 2024 at 5:56 AM Jeff Law wrote:
>
>
>
> On 9/5/24 12:52 PM, Palmer Dabbelt wrote:
> > We have cheap logical ops, so let's just move this back to the default
> > to take advantage of the standard branch/op hueristics.
> >
> > gcc/ChangeLog:
> >
> > PR target/116615
> > *
From: qing zhao
Hi, this is the 2nd version of the patch.
compared to the 1st version, the major changes are to address Marek and
Jacub's comments.
bootstrapped and regression tested on both x86 and aarch64.
Okay for committing?
thanks.
Qing
==
When handling the counted
On Fri, Sep 13, 2024 at 12:24 AM Jonathan Wakely wrote:
>
> I'll wait for Linaro CI to confirm this works, and then push.
>
> I didn't see the regression because I only tested on x86_64.
You never pushed this fix.
Thanks,
Andrew
>
> -- >8 --
>
> This aarch64-*-* test needs an update for the dia
On 10/2/24 3:20 PM, Marek Polacek wrote:
On Sat, Sep 28, 2024 at 08:39:12AM +0200, Jakub Jelinek wrote:
On Fri, Sep 27, 2024 at 04:01:33PM +0200, Jakub Jelinek wrote:
So, I think we should go with (but so far completely untested except
for pr78687.C which is optimized with Marek's patch and the
From: Andi Kleen
Time vars normally use times(2) to get the user/sys/wall time, which is always a
system call. I don't think the system time is very useful because most overhead
is in user time. If we only use the wall (or monotonic) time modern OS have an
optimized path to get it directly from a
Hi Andre,
Am 02.10.24 um 10:49 schrieb Andre Vehreschild:
Hi Harald,
we could do something like this:
diff --git a/gcc/fortran/primary.cc b/gcc/fortran/primary.cc
index d73d5eaed84..5000906f5f2 100644
--- a/gcc/fortran/primary.cc
+++ b/gcc/fortran/primary.cc
@@ -2823,6 +2823,16 @@ check_substr
On Tue, Oct 1, 2024 at 5:04 AM Richard Biener wrote:
>
> The following adds SLP support for vectorizing single-lane inductions
> with variable length vectors.
This introduces a bootstrap failure on aarch64 due to a maybe
uninitialized variable.
inlined from ‘bool vectorizable_induction(loop_
Tested x86_64-linux.
-- >8 --
This change also requires implementing the proposed resolution of LWG
3216 so that std::make_shared and std::allocate_shared still work, and
the proposed resolution of LWG 3891 so that std::expected still works.
libstdc++-v3/ChangeLog:
* include/bits/shared
Is the g++ test change OK?
Tested x86_64-linux.
-- >8 --
The issue was approved at the recent St. Louis meeting, requiring
support for bounded arrays, but only without arguments to initialize the
array elements.
libstdc++-v3/ChangeLog:
* include/bits/stl_construct.h (construct_at): Sup
On Wed, 2 Oct 2024 at 17:48, Matthew Malcomson wrote:
>
> Thanks Jonathan,
>
> I agree with your point that having just the check against one of the
> overloaded versions is not very robust and having multiple checks against
> different versions would be better.
>
> Unfortunately — while asking
Tested x86_64-linux.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/chrono_io.h (__formatter_chrono::_M_c): Add
[[unlikely]] attribute to condition for missing %c format in
locale. Use %T instead of %H:%M:%S in fallback.
---
libstdc++-v3/include/bits/chrono_io.h | 4 ++-
Tested x86_64-linux.
-- >8 --
Implement Peter Dimov's suggestion for resolving LWG 4118, which is to
use +d.count() so that character types are promoted to an integer type
before formatting them. This didn't have unanimous consensus in the
committee as Howard Hinnant proposed that we should forma
On Sat, Sep 28, 2024 at 08:39:12AM +0200, Jakub Jelinek wrote:
> On Fri, Sep 27, 2024 at 04:01:33PM +0200, Jakub Jelinek wrote:
> > So, I think we should go with (but so far completely untested except
> > for pr78687.C which is optimized with Marek's patch and the above testcase
> > which doesn't h
On Wed, 2 Oct 2024 at 19:25, 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, unroll loop manually
> > > using switch statement, then compilers (a
Hi,
> -Original Message-
> From: Richard Sandiford
> Sent: Monday, September 30, 2024 6:33 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; ktkac...@gcc.gnu.org
> Subject: Re: [PATCH 2/2]AArch64: support encoding integer immediates us
Patrick Palka writes:
> On Wed, 2 Oct 2024, Jonathan Wakely wrote:
>
>> I think we should do this.
>>
>> Tested x86_64-linux.
>>
>> -- >8 --
>>
>> Too many users don't know about -D_GLIBCXX_ASSERTIONS and so are missing
>> valuable checks for C++ standard library preconditions. This change
>>
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, unroll loop manually
> > using switch statement, then compilers (at least GCC and Clang) will
> > generate a jump table [1], which is
On Wed, 2 Oct 2024 at 19:15, Dmitry Ilvokhin wrote:
>
> Instead of looping over every byte of the tail, unroll loop manually
> using switch statement, then compilers (at least GCC and Clang) will
> generate a jump table [1], which is faster on a microbenchmark [2].
>
> [1]: https://godbolt.org/z/a
Instead of looping over every byte of the tail, unroll loop manually
using switch statement, then compilers (at least GCC and Clang) will
generate a jump table [1], which is faster on a microbenchmark [2].
[1]: https://godbolt.org/z/aE8Mq3j5G
[2]: https://quick-bench.com/q/ylYLW2R22AZKRvameYYtbYxa
On Wed, 2 Oct 2024, Jonathan Wakely wrote:
> I think we should do this.
>
> Tested x86_64-linux.
>
> -- >8 --
>
> Too many users don't know about -D_GLIBCXX_ASSERTIONS and so are missing
> valuable checks for C++ standard library preconditions. This change
> enables libstdc++ assertions by defa
gcc.dg/strict-flex-array-3.c used hard-coded values instead of
__SIZEOF_INT__ or equivalent expressions. Fixed as obvious.
Plus, on AVR, printf doesn't support %zd, so that expect() is
now special-cased.
Johann
--
testsuite/52641 - Make gcc.dg/strict-flex-array-3.c work on int != 32 bits.
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 not be
used as an extension in the command-line.
* config/aarc
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
combination of features and will diagnose the combination of FEAT_SME without
FEAT_SVE2 as unsupported by GCC. We may choose to support this
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 ISA and behave in a compatible manner to
other toolchains, to prevent unexpected behavior when switching between them.
However, for th
On Wed, 2 Oct 2024 at 17:39, Jonathan Wakely wrote:
>
> On Wed, 25 Sept 2024 at 18:22, François Dumont wrote:
> >
> > Hi
> >
> > Once https://gcc.gnu.org/pipermail/libstdc++/2024-September/059568.html
> > will be accepted we will be able fix this long lasting issue that
> > std::stable_sort and s
On Mon, 13 May 2024 at 05:34, François Dumont wrote:
>
> libstdc++: [_Hashtable] Fix some implementation inconsistencies
>
> Get rid of the different usages of the mutable keyword except in
> _Prime_rehash_policy where it is preserved for abi compatibility
> reason.
>
> Fix com
> On Oct 2, 2024, at 12:05, Jakub Jelinek wrote:
>
> On Wed, Oct 02, 2024 at 11:48:16AM -0400, Marek Polacek wrote:
>>> + error_at (DECL_SOURCE_LOCATION (field_decl),
>>> + "argument %qE to the %qE attribute is not a field declaration"
>>> + " in the same structure as %qD", fieldname,
>>>
> On Oct 2, 2024, at 11:48, Marek Polacek wrote:
>
> On Wed, Oct 02, 2024 at 03:26:26PM +, Qing Zhao wrote:
>> From: qing zhao
>>
>> When handling the counted_by attribute, if the corresponding field
>> doesn't exit, in additiion to issue error, we should also remove
>> the already added
gcc/testsuite/ChangeLog:
* c-c++-common/gomp/declare-variant-2.c: Adjust dg-error directives.
* c-c++-common/gomp/adjust-args-1.c: New test.
* c-c++-common/gomp/adjust-args-2.c: New test.
* c-c++-common/gomp/dispatch-1.c: New test.
* c-c++-common/gomp/dispat
This patch adds C++ support for the `dispatch` construct and the `adjust_args`
clause. It relies on the c-family bits comprised in the corresponding C front
end patch for pragmas and attributes.
Additional C/C++ common testcases are provided in a subsequent patch in the
series.
gcc/cp/ChangeLog:
libgomp/ChangeLog:
* libgomp.texi:
---
libgomp/libgomp.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index c6464ece32e..7026f32f867 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -294,8 +294,8 @@ T
This patch adds support for the `dispatch` construct and the `adjust_args`
clause to the Fortran front-end.
Handling of `adjust_args` across translation units is missing due to PR115271.
gcc/fortran/ChangeLog:
* dump-parse-tree.cc (show_omp_clauses): Handle novariants and nocontext
This patch adds support to the C front-end to parse the `dispatch` construct and
the `adjust_args` clause. It also includes some common C/C++ bits for pragmas
and attributes.
Additional common C/C++ testcases are in a later patch in the series.
gcc/c-family/ChangeLog:
* c-attribs.cc (c_c
This is a respin of my patchset implementing both the `dispatch` construct and
the `adjust_args` clause to the `declare variant` directive. The previous
submission can be found there:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659719.html
Compared to v3, this new iteration handles Tobi
This patch adds middle-end support for the `dispatch` construct and the
`adjust_args` clause. The heavy lifting is done in `gimplify_omp_dispatch` and
`gimplify_call_expr` respectively. For `adjust_args`, this mostly consists in
emitting a call to `gomp_get_mapped_ptr` for the adequate device.
For
This patch introduces the OMP_DISPATCH tree node, as well as two new clauses
`nocontext` and `novariants`. It defines/exposes interfaces that will be
used in subsequent patches that add front-end and middle-end support, but
nothing generates these nodes yet.
gcc/ChangeLog:
* builtin-types
Thanks Jonathan,
I agree with your point that having just the check against one of the
overloaded versions is not very robust and having multiple checks against
different versions would be better.
Unfortunately - while asking the clang folk about this I realised that clang
doesn't expose the r
gcc.dg/pr113596.c alloca'tes up to 8 KiB on stack,
which is too much for AVR. This patch requests less
memory on AVR.
Johann
--
AVR: Make gcc.dg/pr113596.c work.
gcc/testsuite/
* gcc.dg/pr113596.c: Require less memory so it works on AVR.
diff --git a/gcc/testsuite/gcc.dg
On Wed, 25 Sept 2024 at 18:22, François Dumont wrote:
>
> Hi
>
> Once https://gcc.gnu.org/pipermail/libstdc++/2024-September/059568.html
> will be accepted we will be able fix this long lasting issue that
> std::stable_sort and std::inplace_merge are forcing the functor to take
> const& parameters
Given the categorization of math built-in functions as `ECF_CONST',
when if-converting their uses, their calls are not masked and are thus
called with an all-true predicate.
This, however, is not appropriate where built-ins have library
equivalents, wherein they may exhibit highly architecture-spe
On Wed, Oct 02, 2024 at 11:48:16AM -0400, Marek Polacek wrote:
> > + error_at (DECL_SOURCE_LOCATION (field_decl),
> > + "argument %qE to the %qE attribute is not a field declaration"
> > + " in the same structure as %qD", fieldname,
> > + (get_attribute_name (attr
The AArch64 FEAT_FAMINMAX extension introduces instructions for
computing the floating point absolute maximum and minimum of the
two vectors element-wise.
This patch introduces SVE2 faminmax intrinsics. The intrinsics of this
extension are implemented as the following builtin functions:
* sva[max
The AArch64 FEAT_FAMINMAX extension introduces instructions for
computing the floating point absolute maximum and minimum of the
two vectors element-wise.
This patch adds code generation for famax and famin in terms of existing
unspecs. With this patch:
1. famax can be expressed as taking UNSPEC_
From: Saurabh Jha
This patch series is a revised version of:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664209.html
The second commit of the previous patch series was reviewed and has been
commited separately. This patch contains first and third commit of the
previous patch.
The cha
On Wed, Oct 02, 2024 at 03:26:26PM +, Qing Zhao wrote:
> From: qing zhao
>
> When handling the counted_by attribute, if the corresponding field
> doesn't exit, in additiion to issue error, we should also remove
> the already added non-existing "counted_by" attribute from the
> field_decl.
>
From: qing zhao
When handling the counted_by attribute, if the corresponding field
doesn't exit, in additiion to issue error, we should also remove
the already added non-existing "counted_by" attribute from the
field_decl.
bootstrapped and regression tested on both x86 and aarch64.
Okay for comm
gcc.dg/pr93820-2.c requires int32, thus added
dg-require-effective-target int32.
Johann
--
testsuite/52641 - Require int32 for gcc.dg/pr93820-2.c.
PR testsuite/52641
gcc/testsuite/
* gcc.dg/pr93820-2.c: Add dg-require-effective-target int32.
diff --git a/gcc/te
On 10/1/24 13:10, Richard Biener wrote:
On Mon, Sep 30, 2024 at 8:40 PM Tamar Christina wrote:
Hi Victor,
Thanks! This looks good to me with one minor comment:
-Original Message-
From: Victor Do Nascimento
Sent: Monday, September 30, 2024 2:34 PM
To: gcc-patches@gcc.gnu.org
Cc: Tam
> Am 02.10.2024 um 15:48 schrieb Richard Sandiford :
>
> Before running a test with specific torture options, gcc-dg-runtest
> sets the global variable torture_current_flags to the set of torture
> options that will be used. However, it never unset the variable
> afterwards, which meant that
This test failed on int != 32-bit targets due to
a[0] = b[0] = INT_MIN instead of using INT32_MIN.
Johann
--
testsuite/52641 - Fix gcc.dg/signbit-6.c for int != 32-bit targets.
PR testsuite/52641
gcc/testsuite/
* gcc.dg/signbit-6.c (main): Initialize a[0] and b[
On Wed, 2 Oct 2024, Jakub Jelinek wrote:
> Hi!
>
> In the Cauldron IPA/LTO BoF we've discussed toplevel asms and it was
> discussed it would be nice to tell the compiler something about what
> the toplevel asm does. Sure, I'm aware the kernel people said they
> aren't willing to use something
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, October 2, 2024 1:50 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: Re: [PATCH]middle-end: support SLP early break
>
> On Tue, 1 Oct 2024, Tamar Christina wrote:
>
> > Hi all,
>
The SVE ACLE code has two ways of handling overloaded functions.
One, used by C, is to define a single dummy function for each unique
overloaded name, with resolve_overloaded_builtin then resolving calls
to real non-overloaded functions. The other, used by C++, is to
define a separate function for
This patch tries to make check-function-bodies automatically
choose between reading the regular assembly file and reading the
LTO assembly file. There should only ever be one right answer,
since check-function-bodies doesn't make sense on slim LTO output.
Maybe this will turn out to be impossible
Before running a test with specific torture options, gcc-dg-runtest
sets the global variable torture_current_flags to the set of torture
options that will be used. However, it never unset the variable
afterwards, which meant that the last options would hang around
and potentially confuse later non
On 10/2/24 4:45 AM, Gerald Pfeifer wrote:
Hi Jeff,
going through doc/install.texi I noticed there is same really old note on
h8300-hms, even predating egcs. :-) Shall we drop that?
Yea, I'd think so. I don't think we even have the -hms configurations
anymore (they were COFF based IIRC).
Hi Jason,
On 2 Oct 2024, at 0:18, Jason Merrill wrote:
> On 10/1/24 12:44 PM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 30 Sep 2024, at 19:56, Jason Merrill wrote:
>>
>>> On 9/23/24 4:44 AM, Simon Martin wrote:
Hi Jason,
On 20 Sep 2024, at 18:01, Jason Merrill wrote:
> On
I missed one that's actually hit quite a lot, hashing of the canonical
type TYPE_HASH.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed as obvious
after the previous approval.
Richard.
* pt.cc (iterative_hash_template_arg): Use iterative_hash_hashval_t
to hash TYPE_HAS
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'd appreciate suggestions on how to handle such
situations better?
gcc/cp/
* pt.cc (coerce_template_parms): R
On 9/5/24 12:52 PM, Palmer Dabbelt wrote:
We have cheap logical ops, so let's just move this back to the default
to take advantage of the standard branch/op hueristics.
gcc/ChangeLog:
PR target/116615
* config/riscv/riscv.h (LOGICAL_OP_NON_SHORT_CIRCUIT): Remove.
So on the BP
On Wed, Oct 02, 2024 at 01:59:03PM +0200, Richard Biener wrote:
> As you are using input constraints to mark symbol uses maybe we can
> use output constraints with a magic identifier (and a constraint letter
> specifying 'identifier'):
>
> asm (".globl %0; %0: ret" : "_D" (extern int foo()) : ...)
On Tue, 1 Oct 2024, Tamar Christina wrote:
> Hi all,
>
> This patch introduces feature parity for early break int the SLP only
> vectorizer.
>
> The approach taken here is to treat the early exits as root statements for an
> SLP tree. This means that we don't need any changes to build_slp to su
I accidentally forgot to include RISC-V in the title of the patch.
Please ignore this patch since I have sent a fixed one.
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664305.html
Sorry for the inconvenience.
From: Dusan Stojkovic
Sent: Wednesday, October
Jakub Jelinek writes:
> And for kernel perhaps we should add some new option which allows
> some dumb parsing of the toplevel asms and gather something from that
> parsing.
See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107779
> The restrictions I've implemented are:
> 1) asm qualifiers
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Wednesday, October 2, 2024 1:09 PM
> To: Richard Sandiford
> Cc: Tamar Christina ; Jennifer Schmitz
> ; gcc-patches@gcc.gnu.org; Kyrylo Tkachov
>
> Subject: Re: [PATCH] [PR113816] AArch64: Use SVE bit op reduction for vector
> reduction
This patch is a new version of:
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662745.html
> Can you elaborate a bit on that? Rearranging the CFG shouldn't matter
> in general and relying on the specific TARGET_SFB_ALU feels overly
> specific.
> Why does the same register in the if_then
This patch is a new version of:
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662745.html
> Can you elaborate a bit on that? Rearranging the CFG shouldn't matter
> in general and relying on the specific TARGET_SFB_ALU feels overly
> specific.
> Why does the same register in the if_then
> On 2 Oct 2024, at 13:43, Richard Sandiford wrote:
>
> External email: Use caution opening links or attachments
>
>
> Tamar Christina writes:
>> Hi Jennifer,
>>
>>> -Original Message-
>>> From: Richard Sandiford
>>> Sent: Tuesday, October 1, 2024 12:20 PM
>>> To: Jennifer Schmitz
On Wed, 2 Oct 2024, Jakub Jelinek wrote:
> Hi!
>
> In the Cauldron IPA/LTO BoF we've discussed toplevel asms and it was
> discussed it would be nice to tell the compiler something about what
> the toplevel asm does. Sure, I'm aware the kernel people said they
> aren't willing to use something li
This patch is a new version of:
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662745.html
> Can you elaborate a bit on that? Rearranging the CFG shouldn't matter
> in general and relying on the specific TARGET_SFB_ALU feels overly
> specific.
> Why does the same register in the if_then
On 10/2/24 7:49 AM, Richard Biener wrote:
Using iterative_hash_object is expensive compared to using
iterative_hash_hashval_t which is fit for integer sized values.
The following reduces the number of perf cycles spent in
iterative_hash_template_arg and iterative_hash combined by 20%.
Bootstrapp
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%.
There's probably module-related uses that need to be adjusted.
Bootstrap failed (guess I was expecting t
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'd appreciate suggestions on how to handle such
situations better?
gcc/cp/
* pt.cc (coerce_template_parms): Release expanded argument
vector when
Using iterative_hash_object is expensive compared to using
iterative_hash_hashval_t which is fit for integer sized values.
The following reduces the number of perf cycles spent in
iterative_hash_template_arg and iterative_hash combined by 20%.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
The testcase XPASSes now and should do so everywhere I think.
Pushed.
* gcc.dg/vect/vect-double-reduc-5.c: Adjust.
---
gcc/testsuite/gcc.dg/vect/vect-double-reduc-5.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/vect/vect-double-reduc-5.c
Tamar Christina writes:
> Hi Jennifer,
>
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Tuesday, October 1, 2024 12:20 PM
>> To: Jennifer Schmitz
>> Cc: gcc-patches@gcc.gnu.org; Kyrylo Tkachov
>> Subject: Re: [PATCH] [PR113816] AArch64: Use SVE bit op reduction for vector
>>
We can now SLP the loop. There's PR116583 tracking that this still
fails for VLA vectors when load-lanes doesn't support a group of
size 8. We can't express this right now so the testcase keeps
FAILing for aarch64 with SVE (but passes now for riscv).
Pushed.
* gcc.dg/vect/slp-12a.c: Adj
On Wed, Oct 2, 2024 at 1:03 PM Jakub Jelinek wrote:
>
> Hi!
>
> In the Cauldron IPA/LTO BoF we've discussed toplevel asms and it was
> discussed it would be nice to tell the compiler something about what
> the toplevel asm does. Sure, I'm aware the kernel people said they
> aren't willing to use
We can now vectorize the first loop with SLP when using V2SImode
vectors since then we can handle the non-power-of-two interleaving.
We can also SLP the second loop reliably now after adding induction
support for VLA vectors.
Pushed.
* gcc.dg/vect/slp-19c.c: Adjust expectation.
---
gcc/t
The testcase now passes, we can handle double reductions with multiple
types fine.
Pushed.
* gcc.dg/vect/vect-double-reduc-5.c: Un-XFAIL everywhere.
---
gcc/testsuite/gcc.dg/vect/vect-double-reduc-5.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/gcc/testsuite/g
Hi!
In the Cauldron IPA/LTO BoF we've discussed toplevel asms and it was
discussed it would be nice to tell the compiler something about what
the toplevel asm does. Sure, I'm aware the kernel people said they
aren't willing to use something like that, but perhaps other projects
do. And for kerne
The condition on "vectorizing stmts using SLP" needs to match that
of "vectorized 1 loops", obviously.
Pushed.
PR testsuite/116596
* gcc.dg/vect/slp-11a.c: Fix.
---
gcc/testsuite/gcc.dg/vect/slp-11a.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsui
I think we should do this.
Tested x86_64-linux.
-- >8 --
Too many users don't know about -D_GLIBCXX_ASSERTIONS and so are missing
valuable checks for C++ standard library preconditions. This change
enables libstdc++ assertions by default when compiling with -O0 so that
we diagnose more bugs by d
We could also use this in all containers (and node handles) and in
the control block created by std::allocate_shared.
To use it for containers we will need to decide whether to change the
non-standard std::_Destroy(FwdIter, FwdIter, Allocator&) to use this, or
whether to add a new _Destroy_static
Tested x86_64-linux.
-- >8 --
This simplifies the implementation of std::aligned_storage. For the
unstable ABI it also fixes the bug where its size is too large when the
default alignment is used. We can't fix that for the stable ABI though,
so just add a comment about the bug.
libstdc++-v3/Chan
The v1 patch included fixes to a new file for the POSIX-2008 locale,
config/locale/ieee_1003.1-2008/time_members.cc, but I haven't actually
pushed the POSIX-2008 locale to trunk yet. So this v2 patch removes the
changes to that file, and if/when I push the POSIX-2008 work this fix
will be in there
Nobody had any comments, so I've pushed it to trunk now.
On Thu, 26 Sept 2024 at 13:57, Jonathan Wakely wrote:
>
> Does this rounding heuristic seem reasonable? I have discussed it with
> Howard and he agreed that rounding "2024-09-22 18:34:56" up to the next
> day, 2024-09-23, could be surprisin
Hi Jeff,
going through doc/install.texi I noticed there is same really old note on
h8300-hms, even predating egcs. :-) Shall we drop that?
Gerald
gcc:
PR target/69374
* doc/install.texi (Specific) : Drop GCC 2.6
ABI change note.
---
gcc/doc/install.texi | 5 -
1 f
Tested x86_64-linux. Pushed to trunk.
-- >8 --
For 32-bit targets __INT64_TYPE__ expands to long long, which gives a
pedwarn for C++98 mode, causing:
FAIL: 17_intro/headers/c++1998/all_pedantic_errors.cc -std=gnu++98 (test for
excess errors)
Excess errors:
.../bits/postypes.h:64: error: ISO C+
contrib/ChangeLog:
* gcc-changelog/git_commit.py (GitCommit):
Add support for 'Cc: ' and 'Link: ' tags.
Cc: Jason Merrill
Signed-off-by: Alejandro Colomar
---
contrib/gcc-changelog/git_commit.py | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/contrib/gcc
This operator is similar to sizeof but can only be applied to an array,
and returns its number of elements.
FUTURE DIRECTIONS:
- We should make it work with array parameters to functions,
and somehow magically return the number of elements of the array,
regardless of it being really a poin
1 - 100 of 111 matches
Mail list logo
