[PATCH v2] vect: Check that vector factor is a compile-time constant

2023-03-08 Thread Michael Collison
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

Re: [wwwdocs] gcc-13/porting_to.html: Document C++ -fexcess-precision=standard

2023-03-08 Thread Gerald Pfeifer
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

[pushed] wwwdocs: gcc-13: Spell front end (noun) without dash

2023-03-08 Thread Gerald Pfeifer
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 ---

Re: [PATCH v2 1/5] docs: Create Indices appendix

2023-03-08 Thread Sandra Loosemore
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

[gcc10 backport] i386: Call get_available_features for all CPUs with max_level >= 1 [PR100758]

2023-03-08 Thread mayshao
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

[gcc11 backport] i386: Call get_available_features for all CPUs with max_level >= 1 [PR100758]

2023-03-08 Thread mayshao
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

[gcc12 backport] i386: Call get_available_features for all CPUs with max_level >= 1 [PR100758]

2023-03-08 Thread mayshao
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

Re: [PATCH v2 0/5] A small Texinfo refinement

2023-03-08 Thread Andrew Pinski via Gcc-patches
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

Re: [PATCH v2 0/5] A small Texinfo refinement

2023-03-08 Thread Sandra Loosemore
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

[PATCH] rs6000: Accept const pointer operands for MMA builtins [PR109073]

2023-03-08 Thread Peter Bergner via Gcc-patches
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

Re: [PATCH] combine: Try harder to form zero_extends [PR106594]

2023-03-08 Thread Segher Boessenkool
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

Re: [PATCH v2 0/5] A small Texinfo refinement

2023-03-08 Thread Arsen Arsenović via Gcc-patches
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

Re: Re: [PATCH] RISC-V: Add fault first load C/C++ support

2023-03-08 Thread juzhe.zhong
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

[PATCH V2] RISC-V: Add fault first load C/C++ support

2023-03-08 Thread juzhe . zhong
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

Re: [PATCH][stage1] Remove conditionals around free()

2023-03-08 Thread Thomas Schwinge
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,

Re: [PATCH] testsuite: Fix omp-parallel-for-get-min.c and -for-1.c for non-openmp

2023-03-08 Thread David Malcolm via Gcc-patches
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

Re: [PATCH] RISC-V: Add fault first load C/C++ support

2023-03-08 Thread Bernhard Reutner-Fischer via Gcc-patches
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

[PATCH] ubsan: missed -fsanitize=bounds for compound ops [PR108060]

2023-03-08 Thread Marek Polacek via Gcc-patches
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

Re: [V4][PATCH 0/2] Handle component_ref to a structure/union field including FAM for builtin_object_size

2023-03-08 Thread Kees Cook via Gcc-patches
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

Re: [PATCH v2 0/5] A small Texinfo refinement

2023-03-08 Thread Sandra Loosemore
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:

Re: [PATCH RFC] c++: lambda mangling alias issues [PR107897]

2023-03-08 Thread Jason Merrill via Gcc-patches
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,

[PATCH] libstdc++: Implement P2520R0 changes to move_iterator's iterator_concept

2023-03-08 Thread Patrick Palka via Gcc-patches
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.

[RFC 6/X] omp: Allow creation of simd clones from omp declare variant with -fopenmp-simd flag

2023-03-08 Thread Andre Vieira (lists) via Gcc-patches
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

[RFC 5/X] omp: Create simd clones from 'omp declare variant's

2023-03-08 Thread Andre Vieira (lists) via Gcc-patches
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

[RFC 4/X] omp, aarch64: Add SVE support for 'omp declare simd' [PR 96342]

2023-03-08 Thread Andre Vieira (lists) via Gcc-patches
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

[PATCH 3/X] parloops: Allow poly number of iterations

2023-03-08 Thread Andre Vieira (lists) via Gcc-patches
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

[PATCH 2/X] parloops: Copy target and optimizations when creating a function clone

2023-03-08 Thread Andre Vieira (lists) via Gcc-patches
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

[PATCH 1/X] omp: Replace simd_clone_subparts with TYPE_VECTOR_SUBPARTS

2023-03-08 Thread Andre Vieira (lists) via Gcc-patches
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.

[RFC 0/X] Implement GCC support for AArch64 libmvec

2023-03-08 Thread Andre Vieira (lists) via Gcc-patches
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

Re: [PATCH RFC] c++: lambda mangling alias issues [PR107897]

2023-03-08 Thread Jason Merrill via Gcc-patches
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

Re: [PATCH RFC] c++: lambda mangling alias issues [PR107897]

2023-03-08 Thread Jan Hubicka via Gcc-patches
> 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

[PATCH] libstdc++: Implement LWG 3715 changes to view_interface::empty

2023-03-08 Thread Patrick Palka via Gcc-patches
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. *

[PATCH] libstdc++: Implement LWG 3820/3849 changes to cartesian_product_view

2023-03-08 Thread Patrick Palka via Gcc-patches
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

Re: HELP: Questions on multiple PROGRAM_SUMMARY sections in a profiling data file

2023-03-08 Thread Qing Zhao via Gcc-patches
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: >> >>

[PATCH] libstdc++: Make views::single/iota/istream SFINAE-friendly [PR108362]

2023-03-08 Thread Patrick Palka via Gcc-patches
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

[PATCH] libstdc++: Fix handling of surrogate CP in codecvt [PR108976]

2023-03-08 Thread Dimitrij Mijoski via Gcc-patches
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.

Re: [Patch] GCN update for wwwdocs / libgomp.texi

2023-03-08 Thread Andrew Stubbs
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

Re: HELP: Questions on multiple PROGRAM_SUMMARY sections in a profiling data file

2023-03-08 Thread Jan Hubicka via Gcc-patches
> 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

Re: [PATCH] -Wdangling-pointer: don't mark SSA lhs sets as stores

2023-03-08 Thread Richard Biener via Gcc-patches
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 >

[PATCH v3] gcov: Fix "do-while" structure in case statement leads to incorrect code coverage [PR93680]

2023-03-08 Thread Xionghu Luo via Gcc-patches
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

Re: [PATCH] -Wdangling-pointer: don't mark SSA lhs sets as stores

2023-03-08 Thread Martin Liška
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

Re: [PATCH] combine: Try harder to form zero_extends [PR106594]

2023-03-08 Thread Richard Sandiford via Gcc-patches
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

RE: [PATCH] RISC-V: Bugfix for rvv bool mode size adjustment

2023-03-08 Thread Li, Pan2 via Gcc-patches
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]

Re: [Patch] GCN update for wwwdocs / libgomp.texi

2023-03-08 Thread Tobias Burnus
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

[Patch] GCN update for wwwdocs / libgomp.texi

2023-03-08 Thread Tobias Burnus
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

Re: Enable UTF-8 code page in driver and compiler on 64-bit mingw host [PR108865]

2023-03-08 Thread Costas Argyris via Gcc-patches
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

Re: [PATCH 4/4]AArch64 Update div-bitmask to implement new optab instead of target hook [PR108583]

2023-03-08 Thread Richard Sandiford via Gcc-patches
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; >> >

Re: [PATCH] [RFC] RAII auto_mpfr and autp_mpz

2023-03-08 Thread Jakub Jelinek via Gcc-patches
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

Re: [PATCH 2/2] ipa-cp: Improve updating behavior when profile counts have gone bad

2023-03-08 Thread Martin Jambor
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

Re: [PATCH 1/2] ipa-cp: Fix various issues in update_specialized_profile (PR 107925)

2023-03-08 Thread Martin Jambor
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 >

Re: [PATCH] [RFC] RAII auto_mpfr and autp_mpz

2023-03-08 Thread Jonathan Wakely via Gcc-patches
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

[PATCH] middle-end/108995 - avoid folding when sanitizing overflow

2023-03-08 Thread Richard Biener via Gcc-patches
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 *

RE: [PATCH 4/4]AArch64 Update div-bitmask to implement new optab instead of target hook [PR108583]

2023-03-08 Thread Tamar Christina via Gcc-patches
> -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

Re: [PATCH 4/4]AArch64 Update div-bitmask to implement new optab instead of target hook [PR108583]

2023-03-08 Thread Richard Sandiford via Gcc-patches
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, >

Re: [PATCH v2 0/5] A small Texinfo refinement

2023-03-08 Thread Arsen Arsenović via Gcc-patches
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: >>

Re: [PATCH] libgomp: Fix default value of GOMP_SPINCOUNT [PR 109062]

2023-03-08 Thread Jakub Jelinek via Gcc-patches
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

Re: [PATCH] libgomp: Fix default value of GOMP_SPINCOUNT [PR 109062]

2023-03-08 Thread Hongyu Wang via Gcc-patches
> 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

Re: [PATCH 2/4][ranger]: Add range-ops for widen addition and widen multiplication [PR108583]

2023-03-08 Thread Aldy Hernandez via Gcc-patches
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. > >

Re: [PATCH 3/4]middle-end: Implement preferred_div_as_shifts_over_mult [PR108583]

2023-03-08 Thread Richard Sandiford via Gcc-patches
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

Re: [PATCH] libgomp: Fix default value of GOMP_SPINCOUNT [PR 109062]

2023-03-08 Thread Jakub Jelinek via Gcc-patches
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

Re: [PATCH] libgomp: Fix default value of GOMP_SPINCOUNT [PR 109062]

2023-03-08 Thread Hongyu Wang via Gcc-patches
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

Re: [PATCH] libgomp: Fix default value of GOMP_SPINCOUNT [PR 109062]

2023-03-08 Thread Hongyu Wang via Gcc-patches
> 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