> I think the right spot to fix this would be instead in initialize_icvs,
> change the
> icvs->wait_policy = 0;
> in there to
> icvs->wait_policy = -1;
> That way it will be the default for all the devices, not just the
> initial one.
It doesn't work, for the code that determines value of wait
Hongyu Wang 于2023年3月8日周三 16:07写道：
>
> > I think the right spot to fix this would be instead in initialize_icvs,
> > change the
> > icvs->wait_policy = 0;
> > in there to
> > icvs->wait_policy = -1;
> > That way it will be the default for all the devices, not just the
> > initial one.
>
> It do
On Wed, Mar 08, 2023 at 04:21:46PM +0800, Hongyu Wang wrote:
> Hongyu Wang 于2023年3月8日周三 16:07写道：
> >
> > > I think the right spot to fix this would be instead in initialize_icvs,
> > > change the
> > > icvs->wait_policy = 0;
> > > in there to
> > > icvs->wait_policy = -1;
> > > That way it wil
Tamar Christina writes:
> Ping,
>
> And updated the hook to allow to differentiate between ISAs.
>
> As Andy said before initializing a ranger instance is cheap but not free, and
> if
> the intention is to call it often during a pass it should be instantiated at
> pass startup and passed along to
As Andrew has been advising on this one, I'd prefer for him to review
it. However, he's on vacation this week. FYI...
Aldy
On Mon, Mar 6, 2023 at 12:22 PM Tamar Christina wrote:
>
> Ping.
>
> And updated the patch to reject cases that we don't expect or can handle
> cleanly for now.
>
> Boots
> Seems for many ICVs the default values are done through
> gomp_default_icv_values, but that doesn't cover wait_policy.
> For other vars, the defaults are provided through just initializers of
> those vars on the var definitions, e.g.:
> char *gomp_affinity_format_var = "level %L thread %i affinit
On Wed, Mar 08, 2023 at 04:54:20PM +0800, Hongyu Wang wrote:
> > Seems for many ICVs the default values are done through
> > gomp_default_icv_values, but that doesn't cover wait_policy.
> > For other vars, the defaults are provided through just initializers of
> > those vars on the var definitions,
Sandra Loosemore writes:
> On 2/23/23 03:27, Arsen Arsenović via Gcc-patches wrote:
>> I've rerendered the updated documentation with latest development
>> Texinfo (as some of the changes I made for the purposes of the GCC
>> manual still aren't in releases) at:
>>https://www.aarsen.me/~arse
Tamar Christina writes:
> Ping,
>
> And updating the hook.
>
> There are no new test as new correctness tests were added to the mid-end and
> the existing codegen tests for this already exist.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>
> Ok for master?
>
> Thanks,
> Tama
> -Original Message-
> From: Richard Sandiford
> Sent: Wednesday, March 8, 2023 9:18 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: Re: [PATCH 4/4]AArch64 Update div-bitmask to implement new
> optab instead
The following plugs one place in extract_muldiv where it should avoid
folding when sanitizing overflow.
I'm unsure about the testcase, I didn't find any that tests for
a runtime sanitizer error ...
Bootstrapped and tested on x86_64-unknown-linux-gnu.
OK?
PR middle-end/108995
* f
On Wed, 8 Mar 2023 at 07:25, Richard Biener wrote:
>
> On Wed, 8 Mar 2023, Alexander Monakov wrote:
>
> >
> > On Tue, 7 Mar 2023, Jonathan Wakely wrote:
> >
> > > > Shouldn't this use the idiom suggested in ansidecl.h, i.e.
> > > >
> > > > private:
> > > > DISABLE_COPY_AND_ASSIGN (auto_mpfr);
Hello,
I'd like to ping the patch below.
Martin
On Tue, Feb 21 2023, Martin Jambor wrote:
> Hi,
>
> the patch below fixes various issues in function
> update_specialized_profile. The main is removal of the assert which
> is bogus in the case of recursive cloning. The division of
> unexplained
Hello,
I'd like to ping the patch below.
Martin
On Tue, Feb 21 2023, Martin Jambor wrote:
> Hi,
>
> Looking into the behavior of profile count updating in PR 107925, I
> noticed that an option not considered possible was actually happening,
> and - with the guesswork in place to distribute unex
On Wed, Mar 08, 2023 at 10:13:39AM +, Jonathan Wakely wrote:
> On Wed, 8 Mar 2023 at 07:25, Richard Biener wrote:
> >
> > On Wed, 8 Mar 2023, Alexander Monakov wrote:
> >
> > >
> > > On Tue, 7 Mar 2023, Jonathan Wakely wrote:
> > >
> > > > > Shouldn't this use the idiom suggested in ansidecl.h,
Tamar Christina writes:
>> -Original Message-
>> > + (match_operand:VQN 4 "register_operand" "w")))]
>> >"TARGET_SIMD"
>> > + "#"
>> > + "&& true"
>> > + [(const_int 0)]
>> > {
>> > - unsigned HOST_WIDE_INT size
>> > -= (1ULL << GET_MODE_UNIT_BITSIZE (mode)) - 1;
>> >
Added .manifest file to the make rule for utf8rc-mingw32.o, latest patch
attached.
On Tue, 7 Mar 2023 at 15:27, Costas Argyris
wrote:
> Hi Jacek,
>
> "but I think it should work just fine if you didn't explicitly limit the
> patch to x86_64."
>
> I would think so too.
>
> Actually, even cygwin m
Hi Andrew,
attached are two patches related to GCN, one for libgomp.texi documenting an
env var
and a release-notes update in www docs.
OK? Comments?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter
Next try – this time with both patches.
On 08.03.23 12:05, Tobias Burnus wrote:
Hi Andrew,
attached are two patches related to GCN, one for libgomp.texi
documenting an env var
and a release-notes update in www docs.
OK? Comments?
Tobias
-
Siemens Electronic Design Automation
Completed the regression test and the RISC-V backend test without any surprise.
Pan
-Original Message-
From: Li, Pan2
Sent: Wednesday, March 8, 2023 3:34 PM
To: gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@sifive.com; rguent...@suse.de; Li, Pan2
Subject: [PATCH] RISC-V
Segher Boessenkool writes:
> Hi!
>
> On Mon, Mar 06, 2023 at 07:13:08PM +, Richard Sandiford wrote:
>> Segher Boessenkool writes:
>> > Most importantly, what makes you think this is a problem for aarch64
>> > only? If it actually is, you can fix it in the aarch64 config! Either
>> > with or
On 3/3/23 12:12, Richard Biener via Gcc-patches wrote:
> On Fri, Mar 3, 2023 at 9:30 AM Alexandre Oliva wrote:
>>
>> On Feb 17, 2023, Richard Biener wrote:
>>
* gimple-ssa-warn-access.cc
(pass_waccess::check_dangling_stores): Skip non-stores.
for gcc/testsuite/ChangeLog
On 2023/3/7 19:25, Richard Biener wrote:
It would be nice to avoid creating blocks / preserving labels we'll
immediately remove again. For that we do need some analysis
before creating basic-blocks that determines whether a label is
possibly reached by a non-falltru edge.
:
p = 0;
switch
On Wed, Mar 8, 2023 at 2:04 PM Martin Liška wrote:
>
> On 3/3/23 12:12, Richard Biener via Gcc-patches wrote:
> > On Fri, Mar 3, 2023 at 9:30 AM Alexandre Oliva wrote:
> >>
> >> On Feb 17, 2023, Richard Biener wrote:
> >>
> * gimple-ssa-warn-access.cc
> (pass_waccess::check_dangling_st
> Hi, Jan,
>
> I am studying one profiling feedback ICE bug with GCC8 recently.
> It’s an assertion failure inside the routine “compute_working_sets”of
> gcov-io.c:
>
> gcov_nonruntime_assert (ws_ix == NUM_GCOV_WORKING_SETS);
>
> After some debugging and study, I found that the corresponding .
On 08/03/2023 11:06, Tobias Burnus wrote:
Next try – this time with both patches.
On 08.03.23 12:05, Tobias Burnus wrote:
Hi Andrew,
attached are two patches related to GCN, one for libgomp.texi
documenting an env var
and a release-notes update in www docs.
OK? Comments?
LGTM
Andrew
This patch fixes the handling of surrogate code points in all standard
facets for transcoding Unicode that are based on std::codecvt. Surrogate
code points should always be treated as error. On the other hand
surrogate code units can only appear in UTF-16 and only when they come
in a proper pair.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps 12?
PR libstdc++/108362
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::__can_single_view): New concept.
(_Single::operator()): Constrain it. Move [[nodiscard]] to the
end of the funct
Honza,
Thanks a lot for your information.
> On Mar 8, 2023, at 8:19 AM, Jan Hubicka wrote:
>
>> Hi, Jan,
>>
>> I am studying one profiling feedback ICE bug with GCC8 recently.
>> It’s an assertion failure inside the routine “compute_working_sets”of
>> gcov-io.c:
>>
>> gcov_nonruntime_asser
The LWG 3820 testcase revealed a bug in _M_advance, which this patch
also fixes.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/std/ranges
(cartesian_product_view::_Iterator::_Iterator): Remove
constraint on default construct
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/ranges_util.h (view_interface::empty): Add
preferred overloads that use ranges::size when the range is
sized as per LWG 3715.
* testsuite/std/ranges/adaptors/lwg3715.
> Tested x86_64-pc-linux-gnu. Does this look good, or do we want to factor the
> flag clearing into a symtab_node counterpart to cgraph_node::reset?
>
> -- 8< --
>
> In 107897, by the time we are looking at the mangling clash, the
> alias has already been removed from the symbol table by analyze
On 3/8/23 10:53, Jan Hubicka wrote:
Tested x86_64-pc-linux-gnu. Does this look good, or do we want to factor the
flag clearing into a symtab_node counterpart to cgraph_node::reset?
-- 8< --
In 107897, by the time we are looking at the mangling clash, the
alias has already been removed from the
Hi all,
This is a series of patches/RFCs to implement support in GCC to be able
to target AArch64's libmvec functions that will be/are being added to glibc.
We have chosen to use the omp pragma '#pragma omp declare variant ...'
with a simd construct as the way for glibc to inform GCC what funct
Hi,
This patch replaces the uses of simd_clone_subparts with
TYPE_VECTOR_SUBPARTS and removes the definition of the first.
gcc/ChangeLog:
* omp-sind-clone.cc (simd_clone_subparts): Remove.
(simd_clone_init_simd_arrays): Replace simd_clone_subparts with
TYPE_VECTOR_SUBPARTS.
Hi,
This patch makes sure we copy over
DECL_FUNCTION_SPECIFIC_{TARGET,OPTIMIZATION} in parloops when creating
function clones. This is required for SVE clones as we will need to
enable +sve for them, regardless of the current target options.
I don't actually need the 'OPTIMIZATION' for this p
Hi,
This patch modifies this function in parloops to allow it to handle
loops with poly iteration counts.
gcc/ChangeLog:
* tree-parloops.cc (try_transform_to_exit_first_loop_alt):
Handle poly nits.
Is this OK for Stage 1?diff --git a/gcc/tree-parloops.cc b/gcc/tree-parloops.cc
inde
Hi,
This patch adds SVE support for simd clone generation when using 'omp
declare simd'. The design is based on what was discussed in PR 96342,
but I did not look at YangYang's patch as I wasn't sure of whether that
code's copyright had been assigned to FSF.
This patch also is not in accorda
Hi,
This RFC extends the omp-simd-clone pass to create simd clones for
functions with 'omp declare variant' pragmas that contain simd
constructs. This patch also implements AArch64's use for this functionality.
This requires two extra pieces of information be kept for each
simd-clone, a 'varia
Hi,
This RFC is to propose relaxing the flag needed to allow the creation of
simd clones from omp declare variants, such that we can use
-fopenmp-simd rather than -fopenmp.
This should only change the behaviour of omp simd clones and should not
enable any other openmp functionality, though I n
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
backports?
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h (move_iterator::_S_iter_concept):
Define.
(__cpp_lib_move_iterator_concept): Define for C++20.
(move_iterator::iterator_concept):
On 3/8/23 11:15, Jason Merrill wrote:
On 3/8/23 10:53, Jan Hubicka wrote:
Tested x86_64-pc-linux-gnu. Does this look good, or do we want to
factor the
flag clearing into a symtab_node counterpart to cgraph_node::reset?
-- 8< --
In 107897, by the time we are looking at the mangling clash, the
On 3/8/23 02:11, Arsen Arsenović wrote:
Sandra Loosemore writes:
On 2/23/23 03:27, Arsen Arsenović via Gcc-patches wrote:
I've rerendered the updated documentation with latest development
Texinfo (as some of the changes I made for the purposes of the GCC
manual still aren't in releases) at:
On Fri, Feb 24, 2023 at 06:35:03PM +, Qing Zhao wrote:
> Hi, Joseph and Richard,
>
> Could you please review this patch and let me know whether it’s ready
> for committing into GCC13?
>
> The fix to Bug PR101832 is an important patch for kernel security
> purpose. it's better to be put into
In this PR we are dealing with a missing .UBSAN_BOUNDS, so the
out-of-bounds access in the test makes the program crash before
a UBSan diagnostic was emitted. In C and C++, c_genericize gets
a[b] = a[b] | c;
but in C, both a[b] are one identical shared tree (not in C++ because
cp_fold/ARRAY_RE
On 7 March 2023 07:21:23 CET, juzhe.zh...@rivai.ai wrote:
>From: Ju-Zhe Zhong
>
>+class vleff : public function_base
>+{
>+public:
>+ unsigned int call_properties (const function_instance &) const override
>+ {
>+return CP_READ_MEMORY | CP_WRITE_CSR;
>+ }
>+
>+ gimple *fold (gimple_folder
On Wed, 2023-03-08 at 05:58 +0100, Hans-Peter Nilsson wrote:
> Committed as obvious.
> -- >8 --
> The recently added tests missed checking for "fopenmp" (see
> other tests where "-fopenmp" is passed), which makes them
> fail on non-openmp systems.
Sorry about that; thanks for the fix.
Dave
Hi Bernhard!
On 2023-03-01T22:28:56+0100, Bernhard Reutner-Fischer via Gcc-patches
wrote:
> // POSIX: free(NULL) is perfectly valid
> // quote: If ptr is a null pointer, no action shall occur.
> @ rule1 @
> expression e;
> @@
>
> - if (e != NULL)
> - { free(e); }
> + free (e);
Nice, Coccinelle
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc: Remove magic number.
---
gcc/config/riscv/riscv-vector-builtins-bases.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/riscv/riscv-vector-builtins-bases.cc
b/gcc/config/ri
Address comment and fix it in this V2 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613608.html
juzhe.zh...@rivai.ai
From: Bernhard Reutner-Fischer
Date: 2023-03-09 05:16
To: juzhe.zhong; gcc-patches
CC: kito.cheng; Ju-Zhe Zhong
Subject: Re: [PATCH] RISC-V: Add fault first load C
Sandra Loosemore writes:
> On 3/8/23 02:11, Arsen Arsenović wrote:
>> Sandra Loosemore writes:
>>
>>> On 2/23/23 03:27, Arsen Arsenović via Gcc-patches wrote:
I've rerendered the updated documentation with latest development
Texinfo (as some of the changes I made for the purposes of
On Wed, Mar 08, 2023 at 11:58:51AM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > An #ifdef is a way of making a change that is not finished yet not hurt
> > the other targets. It still hurts generic development, which indirectly
> > hurts all targets.
>
> Seems like this might
PR109073 shows a problem where GCC 11 and GCC 10 do not accept a const
__vector_pair pointer operand to some MMA builtins, which GCC 12 and later
correctly accept. Fixed here by initializing the builtins to accept const
pointers.
This patch was tested in both GCC 11 and GCC 10 on powerpc64le-linu
On 3/8/23 14:22, Arsen Arsenović wrote:
Sandra Loosemore writes:
On 3/8/23 02:11, Arsen Arsenović wrote:
Sandra Loosemore writes:
On 2/23/23 03:27, Arsen Arsenović via Gcc-patches wrote:
I've rerendered the updated documentation with latest development
Texinfo (as some of the changes I m
On Wed, Mar 8, 2023 at 5:09 PM Sandra Loosemore wrote:
>
> On 3/8/23 14:22, Arsen Arsenović wrote:
> >
> > Sandra Loosemore writes:
> >
> >> On 3/8/23 02:11, Arsen Arsenović wrote:
> >>> Sandra Loosemore writes:
> >>>
> On 2/23/23 03:27, Arsen Arsenović via Gcc-patches wrote:
> > I've r
From: mayshao-oc
Hi Jakub:
This is backport of the fix for PR target/100758 from mainline to the gcc12
release branch. Because the bug still exists in gcc12 on Zhaoxin platform, and
it will incur ISA feature detection failure, we want to fix it as the
mainline.This patch has been retested ag
Hi Jakub:
This is backport of the fix for PR target/100758 from mainline to the gcc11
release branch. Because the bug still exists in gcc11 on Zhaoxin platform, and
it will incur ISA feature detection failure, we want to fix it as the
mainline.This patch has been retested against the gcc11 bra
From: mayshao-oc
Hi Jakub:
This is backport of the fix for PR target/100758 from mainline to the gcc10
release branch. Because the bug still exists in gcc10 on Zhaoxin platform, and
it will incur ISA feature detection failure, we want to fix it as the
mainline.This patch has been retested ag
On 2/23/23 03:27, Arsen Arsenović via Gcc-patches wrote:
The GCC manual has multiple indices. By creating an appendix which
lists them, we help makeinfo present a more accessible way for the
reader to see all the indices.
gcc/ChangeLog:
* doc/gcc.texi: Add the Indices appendix, to make
Pushed in alignment with the list in our coding conventions.
Gerald
---
htdocs/gcc-13/porting_to.html | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-13/porting_to.html b/htdocs/gcc-13/porting_to.html
index 733bb254..170da096 100644
--- a/htdocs/gcc-13/porting_to.
On Thu, 2 Mar 2023, Jakub Jelinek wrote:
> --- a/htdocs/gcc-13/porting_to.html
> +++ b/htdocs/gcc-13/porting_to.html
> +GCC 13 implements in C++ excess precision
> support
> +which has been implemented just in the C front-end before. The new behavior
> is
> +enabled by default in -std=c++NN mod
2023-03-05 Michael Collison
* tree-vect-loop-manip.cc (vect_do_peeling): Use
result of constant_lower_bound instead of vf in case
vf is not a compile time constant.
---
gcc/tree-vect-loop-manip.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/t
62 matches
Mail list logo
