On Thu, 9 Feb 2023, Jakub Jelinek wrote:
> Martin Liska mentioned that porting_to.html doesn't mention
> the C++ excess precision changes. Not really sure if porting_to
> should document those, but I think changes.html certainly should.
Do you think this is a widely spread issue for existing soft
On Fri, Jan 06, 2023 at 12:20:33PM +, Andrew Stubbs wrote:
> > > +/* Ensure the the in-branch simd clones are used on targets that support
> > > + them. These counts include all call and definitions. */
> > > +
> > > +/* { dg-skip-if "" { x86_64-*-* } { "-flto" } { "" } } */
> >
> > Drop l
Hi!
On 2023-02-02T00:55:01-0500, Flavio Cruz wrote:
> contrib/ChangeLog:
> * config-list.mk: Add x86_64-gnu to list of archs.
>
> Signed-off-by: Flavio Cruz
Thanks, pushed to GCC master branch in
commit e635681dd26abf8243b49f6fd39d3582d57225ba
"Add x86_64-gnu target to contrib/config-list
The following fixes a latent issue when we mark control edges but
end up with marking a block with no stmts necessary. In this case
we fail to mark dependent control edges of that block.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
Does this look OK?
Thanks,
Richard.
PR tree-op
Hi!
On 2011-04-13T06:49:31-0400, Joern Rennecke wrote:
> [...]
> This Makefile is supposed to give coverage of all the main configure targets
> and notable variants that enable different config files.
> [...]
> --- contrib/config-list.mk(revision 0)
> +++ contrib/config-list.mk(revision
From: Ju-Zhe Zhong
According to RVV ISA, vsmul are not supported for EEW=64 in Zve64*,
so add Full 'V' extension required into predicate of vsmul intrinsics.
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-functions.def (vsmul): Change
iterators.
---
gcc/config/riscv/riscv-vector
Oops, realizes I forgot to fill in the test results, there were no issues 😊
> -Original Message-
> From: Gcc-patches bounces+tamar.christina=arm@gcc.gnu.org> On Behalf Of Tamar
> Christina via Gcc-patches
> Sent: Thursday, February 9, 2023 5:22 PM
> To: gcc-patches@gcc.gnu.org
> Cc: n
Oops, realizes I forgot to fill in the test results, there were no issues 😊
> -Original Message-
> From: Gcc-patches bounces+tamar.christina=arm@gcc.gnu.org> On Behalf Of Tamar
> Christina via Gcc-patches
> Sent: Thursday, February 9, 2023 5:17 PM
> To: gcc-patches@gcc.gnu.org
> Cc: n
This fixes an oversight to when removing the hard limits on using
generic vectors for the vectorizer to enable both SLP and BB
vectorization to use those. The vectorizer relies on vector lowering
to expand plus, minus and negate to bit operations but vector
lowering has a hard limit on the minimum
Richard Biener via Gcc-patches writes:
> This fixes an oversight to when removing the hard limits on using
> generic vectors for the vectorizer to enable both SLP and BB
> vectorization to use those. The vectorizer relies on vector lowering
> to expand plus, minus and negate to bit operations but
On Fri, 10 Feb 2023, Richard Sandiford wrote:
> Richard Biener via Gcc-patches writes:
> > This fixes an oversight to when removing the hard limits on using
> > generic vectors for the vectorizer to enable both SLP and BB
> > vectorization to use those. The vectorizer relies on vector lowering
>
Updated version attached.
On 31.01.23 12:20, Jakub Jelinek via Gcc-patches wrote:
On Tue, Jan 24, 2023 at 04:24:07PM +0100, Tobias Burnus wrote:
+ if (code->op == EXEC_OMP_LOOP)
+; /* Already rejected in resolve_omp_clauses. */
I don't understand why is this needed. Sure, the vast
On Thu, 9 Feb 2023, Tamar Christina wrote:
> Hi All,
>
> As discussed in the ticket, this replaces the approach for optimizing the
> div by bitmask operation from a hook into optabs implemented through
> add_highpart.
>
> In order to be able to use this we need to check whether the current preci
I think I'm misunderstanding, but: it seems like we're treating the
add highpart optabs as companions to the mul highpart optabs. But AIUI,
the add highpart optab is used such that, for an N-bit mode, we do
an N-bit addition followed by a shift by N/2. Is that right?
The mul highpart optabs inste
On Fri, 10 Feb 2023, Richard Sandiford wrote:
> I think I'm misunderstanding, but: it seems like we're treating the
> add highpart optabs as companions to the mul highpart optabs. But AIUI,
> the add highpart optab is used such that, for an N-bit mode, we do
> an N-bit addition followed by a shif
I was asking in the 1/2 review whether we need the optab, but that
decision doesn't affect the other patterns, so:
Tamar Christina writes:
> Hi All,
>
> This replaces the custom division hook with just an implementation through
> add_highpart. For NEON we implement the add highpart (Addition + e
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, February 10, 2023 1:36 PM
> To: Tamar Christina via Gcc-patches
> Cc: Tamar Christina ; nd ;
> rguent...@suse.de; j...@ventanamicro.com
> Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask
> by using new
Hi Andrew!
On 2022-03-08T11:30:57+, Hafiz Abid Qadeer wrote:
> From: Andrew Stubbs
>
> This adds support for using Cuda Managed Memory with omp_alloc. It will be
> used as the underpinnings for "requires unified_shared_memory" in a later
> patch.
>
> There are two new predefined allocators,
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Friday, February 10, 2023 1:36 PM
>> To: Tamar Christina via Gcc-patches
>> Cc: Tamar Christina ; nd ;
>> rguent...@suse.de; j...@ventanamicro.com
>> Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatchi
On 2/10/23 02:45, Richard Biener wrote:
On Fri, Feb 10, 2023 at 1:02 AM Andrew MacLeod via Gcc-patches
wrote:
I was about to ping on this, and then found it in my drafts.. Doh!
get_range_global() can invoke tree.cc::nonnull_arg_p() if the item being
queried is a pointer and a parameter. Th
On Thu, 9 Feb 2023, Patrick Palka wrote:
> On Thu, 9 Feb 2023, Jason Merrill wrote:
>
> > On 2/9/23 09:36, Patrick Palka wrote:
> > > On Sun, 5 Feb 2023, Jason Merrill wrote:
> > >
> > > > On 2/3/23 15:51, Patrick Palka wrote:
> > > > > On Mon, 30 Jan 2023, Jason Merrill wrote:
> > > > >
> > >
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, February 10, 2023 2:31 PM
> To: Tamar Christina
> Cc: Tamar Christina via Gcc-patches ; nd
> ; rguent...@suse.de; j...@ventanamicro.com
> Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask
> by using new
Hi!
Re OpenMP 'pinned' memory allocator trait semantics vs. 'omp_realloc':
On 2022-01-13T13:53:03+, Andrew Stubbs wrote:
> On 05/01/2022 17:07, Andrew Stubbs wrote:
>> [...], I'm working on an implementation using mmap instead of malloc
>> for pinned allocations. [...]
> This means that la
Thanks, Kees.
If there is no objection, I will update my patches with this. And send the
updated patches soon.
Qing
> On Feb 9, 2023, at 11:46 AM, Kees Cook wrote:
>
> On Thu, Feb 09, 2023 at 02:40:57PM +, Qing Zhao wrote:
>> So, the major question here is:
>>
>> in addition to the C99 s
On 10/02/2023 14:21, Thomas Schwinge wrote:
Is the correct fix the following (conceptually like
'linux_memspace_alloc' cited above), or is there something that I fail to
understand?
static void *
linux_memspace_calloc (omp_memspace_handle_t memspace, size_t size, int
pin)
{
On 10/02/2023 15:11, Thomas Schwinge wrote:
Hi!
Re OpenMP 'pinned' memory allocator trait semantics vs. 'omp_realloc':
On 2022-01-13T13:53:03+, Andrew Stubbs wrote:
On 05/01/2022 17:07, Andrew Stubbs wrote:
[...], I'm working on an implementation using mmap instead of malloc
for pinned a
Tamar Christina writes:
>> > a/gcc/tree-vect-patterns.cc b/gcc/tree-vect-patterns.cc index
>> >
>> 6934aebc69f231af24668f0a1c3d140e97f55487..e39d7e6b362ef44eb2fc467f33
>> 69
>> > de2afea139d6 100644
>> > --- a/gcc/tree-vect-patterns.cc
>> > +++ b/gcc/tree-vect-patterns.cc
>> > @@ -3914,12 +3914,82
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, February 10, 2023 3:57 PM
> To: Tamar Christina
> Cc: Tamar Christina via Gcc-patches ; nd
> ; rguent...@suse.de; j...@ventanamicro.com
> Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask
> by using new
On 02/09, Hongtao Liu wrote:
> On Mon, Dec 19, 2022 at 3:59 PM Dan Li via Gcc-patches
> wrote:
> >
> > This series of patches is mainly used to support the control flow
> > integrity protection of the linux kernel [1], which is similar to
> > -fsanitize=kcfi in clang 16.0 [2,3].
> >
> > I hope tha
On 02/08, Peter Collingbourne wrote:
> On Sun, Dec 18, 2022 at 10:06 PM Dan Li wrote:
> >
> > This series of patches is mainly used to support the control flow
> > integrity protection of the linux kernel [1], which is similar to
> > -fsanitize=kcfi in clang 16.0 [2,3].
> >
> > I hope that this fe
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Friday, February 10, 2023 3:57 PM
>> To: Tamar Christina
>> Cc: Tamar Christina via Gcc-patches ; nd
>> ; rguent...@suse.de; j...@ventanamicro.com
>> Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatchi
On Mon, Sep 26, 2022 at 06:27:25PM -0400, Lewis Hyatt via Gcc-patches wrote:
> May I please ping this patch again? Joseph suggested that it would be best if
> a C++ maintainer has a look at it. This is one of just a few places left where
> we don't handle UTF-8 properly in libcpp, it would be reall
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, February 10, 2023 4:25 PM
> To: Tamar Christina
> Cc: Tamar Christina via Gcc-patches ; nd
> ; rguent...@suse.de; j...@ventanamicro.com
> Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask
> by using new
> From: Vladimir Makarov via Gcc-patches
> Date: Thu, 9 Feb 2023 22:49:34 +0100
> The patch was successfully bootstrapped (--enable-languages=all) and
> tested on x86, x86-64, aarch64
Sorry, but this (also) caused test-suite regressions,
perhaps just for cris-elf. I've opened 108754 and will
a
The following patch is for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500
The patch improves compilation speed. Compilation time of the biggest
test in the PR decreases from 1235s to 709s.
The patch was successfully bootstrapped on x86-64.
commit 02371cdd755d2b53fb580d3e8209c44e0c45c337
On Fri, 10 Feb 2023, Patrick Palka wrote:
> On Thu, 9 Feb 2023, Patrick Palka wrote:
>
> > On Thu, 9 Feb 2023, Jason Merrill wrote:
> >
> > > On 2/9/23 09:36, Patrick Palka wrote:
> > > > On Sun, 5 Feb 2023, Jason Merrill wrote:
> > > >
> > > > > On 2/3/23 15:51, Patrick Palka wrote:
> > > > >
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Friday, February 10, 2023 4:25 PM
>> To: Tamar Christina
>> Cc: Tamar Christina via Gcc-patches ; nd
>> ; rguent...@suse.de; j...@ventanamicro.com
>> Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatchi
On Fri, Feb 10, 2023 at 11:30 AM Jakub Jelinek wrote:
>
> On Mon, Sep 26, 2022 at 06:27:25PM -0400, Lewis Hyatt via Gcc-patches wrote:
> > May I please ping this patch again? Joseph suggested that it would be best
> > if
> > a C++ maintainer has a look at it. This is one of just a few places left
Richard Sandiford writes:
> Final pattern statements (those not in DEF_SEQ) always have the same
> type and value as the original statements. We wouldn't see mismatched
> precisions if we were only looking at final pattern statements.
>
> Like you say, the 16-bit addition didn't exist before vect
On Fri, Feb 10, 2023 at 11:58:03AM -0500, Lewis Hyatt wrote:
> On Fri, Feb 10, 2023 at 11:30 AM Jakub Jelinek wrote:
> >
> > On Mon, Sep 26, 2022 at 06:27:25PM -0400, Lewis Hyatt via Gcc-patches wrote:
> > > May I please ping this patch again? Joseph suggested that it would be
> > > best if
> > >
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, February 10, 2023 4:57 PM
> To: Tamar Christina
> Cc: Tamar Christina via Gcc-patches ; nd
> ; rguent...@suse.de; j...@ventanamicro.com
> Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask
> by using new
The following patch should solve
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108754
The patch simply switches off a new optimization for targets using the
old reload pass.
The patch was successfully bootstrapped on x86-64.
commit 7757567358a84c3774cb972350bd7ea299daaa8d
Author: Vladimir
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Friday, February 10, 2023 4:57 PM
>> To: Tamar Christina
>> Cc: Tamar Christina via Gcc-patches ; nd
>> ; rguent...@suse.de; j...@ventanamicro.com
>> Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatchi
This patch did not get committed in a timely manner after it was OK'd. In
revisiting the patch some issues were found that have lead me to resubmit
for review -
Specifically -
The original commit to add C++20 atomic_flag::test did not include the free
functions for atomic_flag_test[_explicit]
The
> Am 10.02.2023 um 19:12 schrieb Richard Sandiford via Gcc-patches
> :
>
> Tamar Christina writes:
>>> -Original Message-
>>> From: Richard Sandiford
>>> Sent: Friday, February 10, 2023 4:57 PM
>>> To: Tamar Christina
>>> Cc: Tamar Christina via Gcc-patches ; nd
>>> ; rguent...@sus
citeseer.ist.psu.edu stalls, whereas citeseerx.ist.psu.edu responds.
Switch to https on the way.
Pushed.
Gerald
---
htdocs/news/profiledriven.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/news/profiledriven.html b/htdocs/news/profiledriven.html
index cac172b4..8
On 2/10/23 13:34, Richard Biener wrote:
In any case, if you disagree I don’t' really see a way forward aside from
making this its own pattern
running it before the overwidening pattern.
I think we should look to see if ranger can be persuaded to provide the
range of the 16-bit addition, eve
> The following fixes a latent issue when we mark control edges but
> end up with marking a block with no stmts necessary. In this case
> we fail to mark dependent control edges of that block.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> Does this look OK?
>
> Thanks,
> Richard.
On RISC-V, conditional-zero (i.e., move a register value or zero to a
destination register) instructions are part if the Zicond extension.
To support architectures that have similar constructs, we define a
canonical RTL representation that can be used in if-conversion.
Signed-off-by: Philipp Tomsi
This adds the RISC-V Zicond extension to the option parsing.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: Recognize "zicond"
as part of an architecture string.
* config/riscv/riscv-opts.h (MASK_ZICOND): Define.
(TARGET_ZICOND): Define.
Signed-off-by: Phil
Adds a pattern to map the output of noce_try_store_flag_mask
if-conversion in the combiner onto vt.maskc; the input patterns
supported are similar to the following:
(set (reg/v/f:DI 75 [ ])
(and:DI (neg:DI (ne:DI (reg:DI 82)
(const_int 0 [0])))
(reg/v
The (proposed, but about to be frozen) Zicond extension adds 2
unconditional R-type instructions that can be used to build branchless
sequences that have conditional-arithmetic/bitwise/select semantics
and integrate will with the RISC-V architecture.
See the Zicond specification for details:
This adds the xventanacondops extension to the option parsing and as a
default for the ventana-vt1 core:
gcc/Changelog:
* common/config/riscv/riscv-common.cc: Recognize
"xventanacondops" as part of an architecture string.
* config/riscv/riscv-opts.h (MASK_XVENTANACONDOPS
When if-conversion in noce_try_store_flag_mask starts the sequence off
with an order-operator, our patterns for czero.eqz/nez will receive
the result of the order-operator as a register argument; consequently,
they can't know that the result will be either 1 or 0.
To convey this information (and m
When if-conversion encounters sequences using immediates, the
sequences can't trivially map back onto czero.eqz/czero.nezt (even if
benefitial) due to czero.eqz/czero.nez not having immediate forms.
This adds a splitter to rewrite opportunities for Zicond that operate
on an immediate by first putt
Users might use explicit arithmetic operations to create a mask and
then and it, in a sequence like
cond = (bits >> SHIFT) & 1;
mask = ~(cond - 1);
val &= mask;
which will present as a single-bit sign-extract.
Dependening on what combination of XVentanaCondOps and Zbs are
available, th
Some architectures, as it the case on RISC-V with the proposed
ZiCondOps and the vendor-defined XVentanaCondOps, define a
conditional-zero instruction that is equivalent to:
- the positive form: rd = (rc != 0) ? rs : 0
- the negated form: rd = (rc == 0) ? rs : 0
While noce_try_store_flag_mask
While the positive case "if ((bits >> SHAMT) & 1)" for SHAMT 0..10 can
trigger conversion into efficient branchless sequences
- with Zbs (bexti + neg + and)
- with Zicond (andi + czero.nez)
the inverted/negated case results in
andi a5,a0,1024
seqz a5,a5
neg a5,a5
and a5,a5,a1
due to how
The vendor-defined XVentanaCondOps extension adds two instructions
with semantics identical to Zicond.
This plugs the 2 new instruction in using the canonical RTX, which
also matches the combiner-input for noce_try_store_flag_mask and
noce_try_store_flag, defined for conditional-zero.
For documen
On Fri, Feb 10, 2023 at 2:47 PM Philipp Tomsich
wrote:
>
> Some architectures, as it the case on RISC-V with the proposed
> ZiCondOps and the vendor-defined XVentanaCondOps, define a
> conditional-zero instruction that is equivalent to:
> - the positive form: rd = (rc != 0) ? rs : 0
> - the neg
Integration testing shows this patch fixes all 9 known false positives
from -Wanalyzer-deref-before-check within ImageMagick-7.1.0-57, and
eliminates 34 further as-yet unassessed such diagnostics, without
eliminating the 1 known true positive.
This improves the rate of true positives for the warni
On Fri, Feb 10, 2023 at 2:43 PM Philipp Tomsich
wrote:
>
> On RISC-V, conditional-zero (i.e., move a register value or zero to a
> destination register) instructions are part if the Zicond extension.
> To support architectures that have similar constructs, we define a
> canonical RTL representatio
GCC extension accepts the case when a struct with a C99 flexible array member
is embedded into another struct or union (possibly recursively).
__builtin_object_size should treat such struct as flexible size.
gcc/c/ChangeLog:
PR tree-optimization/101832
* c-decl.cc (finish_struct):
on structure with C99 flexible array member being nested in another structure.
This is also fixed PR77650.
" GCC extension accepts a structure containing a ISO C99 "flexible array
member", or a union containing such a structure (possibly recursively)
to be a member of a structure.
There are thr
These are the 3rd version of the patches for PR101832, to fix
builtin_object_size to correctly handle component_ref to a
structure/union field that includes a flexible array member.
also includes a documentation update for the GCC extension on embedding
a structure/union with flexible array member
On Fri, 10 Feb 2023 at 18:25, Thomas Rodgers wrote:
>
> This patch did not get committed in a timely manner after it was OK'd. In
> revisiting the patch some issues were found that have lead me to resubmit for
> review -
>
> Specifically -
>
> The original commit to add C++20 atomic_flag::test d
Casual observation from a random reader that's sometimes hit by
testresults acting up:
On Thu, 9 Feb 2023, Dimitrij Mijoski via Gcc-patches wrote:
> libstdc++-v3/ChangeLog:
>
> * testsuite/22_locale/codecvt/codecvt_unicode.cc: Rename
> functions.
> * testsuite/22_locale/code
On 2/9/23 02:48, Andreas Schwab via Gcc-patches wrote:
PR target/108723
* gcc.target/riscv/shorten-memrefs-1.c: Adjust patterns to skip
over cfi directives.
* gcc.target/riscv/shorten-memrefs-2.c: Likewise.
* gcc.target/riscv/shorten-memrefs-3.c: Likewise.
* gcc.target/riscv/shorten-memrefs-4.
From: Pan Li
PR 108185
PR 108654
The bytesize of the vbool*_t isn't well defined. This patch
adjust the rvv bool modes with actually mode size in bytes.
However, only allow mode tieable when exactly equal for the
rvv bool types, aka vbool1_t, vbool
On 2/6/23 06:40, Jonathan Yong wrote:
On 1/18/23 10:44, i.nixman--- via Gcc-patches wrote:
hello again!
the final version of the path for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
successfully bootstraped for x86_64-mingw32 and x86_64-linux.
could anyone apply it please?
best!
On 2023-02-11 06:32, Jonathan Yong wrote:
On 2/6/23 06:40, Jonathan Yong wrote:
On 1/18/23 10:44, i.nixman--- via Gcc-patches wrote:
hello again!
the final version of the path for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
successfully bootstraped for x86_64-mingw32 and x86_64-linu
71 matches
Mail list logo
