Re: [PATCH V2] Machine Description: Add LEN_MASK_{GATHER_LOAD, SCATTER_STORE} pattern

> I am not sure why you mention 'len' in bytes. The 'trick' for then len_load/len_store patterns is to allow a QImode/byte-only length rather than elements. Regards Robin

Re: Ping [PATCH v4] Add condition coverage profiling

On 23/06/2023 19:28, Jan Hubicka wrote: >>> >>> gcc/ChangeLog: >>> >>> * builtins.cc (expand_builtin_fork_or_exec): Check >>> profile_condition_flag. >>> * collect2.cc (main): Add -fno-profile-conditions to OBSTACK. >>> * common.opt: Add new options -fprofile-conditions and >>>

GCC 10.4.1 Status Report (2023-06-30), branch frozen for release

Status == The gcc-10 branch is frozen for release and closing. All changes require release manager approval. Previous Report === https://gcc.gnu.org/pipermail/gcc/2023-June/241839.html

Re: Re: [PATCH V2] Machine Description: Add LEN_MASK_{GATHER_LOAD, SCATTER_STORE} pattern

>> I'll note >> that 'len' has issues with scatter/gather anyway since the trick of >> handling 'len' in bytes by only providing QImode variants doesn't work >> here. For RVV, we prefer ’len' in elements which perfectly match our RVV instruction ISA define. For example, for our indexed load: vs

Re: [PATCH v1 2/6] LoongArch: Added Loongson SX base instruction support.

On Fri, 2023-06-30 at 10:16 +0800, Chenghui Pan wrote: > +(define_c_enum "unspec" [ > +  UNSPEC_LSX_ASUB_S > +  UNSPEC_LSX_VABSD_U > +  UNSPEC_LSX_VAVG_S /* ... */ To me many of them can be modeled using RTL templates, instead of an unspec. -- Xi Ruoyao School of Aerospace Science and Technolog

Re: [PATCH] Machine Description: Add LEN_MASK_{GATHER_LOAD, SCATTER_STORE} pattern

> I personally prefer **NOT** to include BIAS in the gather/scatter > since I don't known how it will be used. It was not my intention to suggest to add BIAS here. This can be done by the respective targets when/if they support mask_*, not by you. What I meant is that I'm unsure whether to add a

Re: PR82943 - Suggested patch to fix

Hi Alexander, I suggest that you take a look at PR82649 before going too far down the road of fixing PDT bugs. This PR underlines just how wrong the PDT representation is - mea culpa! The mechanics for constructing PDTs are in decl.cc(gfc_get_pdt_instance). They need to be turned inside out to cr

Re: [PATCH v1 2/6] LoongArch: Added Loongson SX base instruction support.

On Fri, 2023-06-30 at 10:16 +0800, Chenghui Pan wrote: >   > +  int use_vecarg_p = TARGET_VECARG > +    && LSX_SUPPORTED_MODE_P (mode); > + >    memset (info, 0, sizeof (*info)); >    info->gpr_offset = cum->num_gprs; >    info->fpr_offset = cum->num_fprs; > @@ -535,7 +546,7 @@ loongarch_get_arg_in

[PATCH] tree-optimization/110381 - fix testcase

This adds a missing check_vect () to the execute testcase. Tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/110381 * gcc.dg/vect/pr110381.c: Add check_vect (). --- gcc/testsuite/gcc.dg/vect/pr110381.c | 4 1 file changed, 4 insertions(+) diff --git a/gcc/tes

Re: [PATCH v1 0/6] Add Loongson SX/ASX instruction support to LoongArch target.

On Fri, 2023-06-30 at 10:16 +0800, Chenghui Pan wrote: > These patches add the Loongson SX/ASX instruction support to the > LoongArch > target, and can be utilized by using the new "-mlsx" and > "-mlasx" option. > > Patches are bootstrapped and tested on loongarch64-linux-gnu target. > > Lulu Che

Re: [PATCH V2] Machine Description: Add LEN_MASK_{GATHER_LOAD, SCATTER_STORE} pattern

On Fri, 30 Jun 2023, juzhe.zh...@rivai.ai wrote: > From: Ju-Zhe Zhong > > Hi, Richi and Richard. > > This patch is adding LEN_MASK_{GATHER_LOAD,SCATTER_STORE} to allow targets > handle flow control by mask and loop control by length on gather/scatter > memory > operations. Consider this follow

[PATCH 3/3] rs6000: Teach legitimate_address_p about LEN_{LOAD, STORE} [PR110248]

Hi, This patch is to teach rs6000_legitimate_address_p to handle the queried rtx constructed for LEN_{LOAD,STORE}, since lxvl and stxvl doesn't support x-form or ds-form, so consider it as not legitimate when outer code is PLUS. This can help to fix SPEC2017 503.bwaves_r degradation as reported i

[PATCH 2/3] ivopts: Call valid_mem_ref_p with code_helper [PR110248]

Hi, As PR110248 shows, to get the expected query results for that case internal functions LEN_{LOAD,STORE} is unable to adopt some addressing modes, we need to pass down the related IFN code as well. This patch is to make IVOPTs pass down ifn code for USE_PTR_ADDRESS type uses, it adjusts the rel

[PATCH 1/3] targhooks: Extend legitimate_address_p with code_helper [PR110248]

Hi, As PR110248 shows, some middle-end passes like IVOPTs can query the target hook legitimate_address_p with some artificially constructed rtx to determine whether some addressing modes are supported by target for some gimple statement. But for now the existing legitimate_address_p only checks t

[PATCH] Collect both user and kernel events for autofdo tests and autoprofiledbootstrap

When we collect just user events for autofdo with lbr we get some events where branch sources are kernel addresses and branch targets are user addresses. Without kernel MMAP events create_gcov can't make sense of kernel addresses. Currently create_gcov fails if it can't map at least 95% of event

[PATCH] tree.h: Hide wi::from_mpz from GENERATOR_FILE

Hi, Similar to r0-85707-g34917a102a4e0c for PR35051, the uses of mpz_t should be guarded with "#ifndef GENERATOR_FILE". This patch is to fix it and avoid some possible build errors. Bootstrapped and regress-tested on x86_64-redhat-linux, and powerpc64{,le}-linux-gnu. And cross-build well on powe

Re: PR82943 - Suggested patch to fix

On Thu, Jun 29, 2023 at 10:38:42PM -0500, Alexander Westbrooks via Fortran wrote: > I have finished my testing, and updated my patch and relevant Changelogs. I > added 4 new tests and all the existing tests in the current testsuite > for gfortran passed or failed as expected. Do I need to attach t

PR108672 re-fixed after [PATCH] libstdc++: Synchronize PSTL with upstream

> Date: Mon, 26 Jun 2023 11:57:49 -0700 > From: Thomas Rodgers via Gcc-patches > On Wed, May 17, 2023 at 12:32 PM Jonathan Wakely wrote: > > All the actual code changes look good. Unfortunately, this overwrote the fix for PR108672. I take it there's a step missing from the synchronization proc

Re: PR82943 - Suggested patch to fix

Hello, I have finished my testing, and updated my patch and relevant Changelogs. I added 4 new tests and all the existing tests in the current testsuite for gfortran passed or failed as expected. Do I need to attach the test results here? The platform I tested on was a Docker container running in

Re: [PATCH] rs6000: Update the vsx-vector-6.* tests.

Hi Carl, on 2023/6/30 05:36, Carl Love wrote: > Kewen: > > On Wed, 2023-06-28 at 16:35 +0800, Kewen.Lin wrote: >>> Yea, I was going with a runnable test and didn't include the >>> instruction counts. Added back in. Rather then doing by processor >>> version (P8, P9, P10) I was able to do it by

Re: [PATCH] rs6000, __builtin_set_fpscr_rn add retrun value

On 6/29/23 4:13 AM, Kewen.Lin wrote: > on 2023/6/19 23:57, Carl Love wrote: >> The following patch changes the return type of the >> __builtin_set_fpscr_rn builtin from void to double. The return value >> is the current value of the various FPSCR fields DRN, VE, OE, UE, ZE, >> XE, NI, RN bit posi

[PATCH V2] Machine Description: Add LEN_MASK_{GATHER_LOAD, SCATTER_STORE} pattern

From: Ju-Zhe Zhong Hi, Richi and Richard. This patch is adding LEN_MASK_{GATHER_LOAD,SCATTER_STORE} to allow targets handle flow control by mask and loop control by length on gather/scatter memory operations. Consider this following case: #include void f (uint8_t *restrict a, uint8_t *rest

[PATCH v1 4/6] LoongArch: Added Loongson ASX vector directive compilation framework.

From: Lulu Cheng gcc/ChangeLog: * config/loongarch/genopts/loongarch-strings: Added compilation framework. * config/loongarch/genopts/loongarch.opt.in: Ditto. * config/loongarch/loongarch-c.cc (loongarch_cpu_cpp_builtins): Ditto. * config/loongarch/loongarch-def.

[PATCH v1 1/6] LoongArch: Added Loongson SX vector directive compilation framework.

From: Lulu Cheng gcc/ChangeLog: * config/loongarch/genopts/loongarch-strings: Added compilation framework. * config/loongarch/genopts/loongarch.opt.in: Ditto. * config/loongarch/loongarch-c.cc (loongarch_cpu_cpp_builtins): Ditto. * config/loongarch/loongarch-def.

[PATCH v1 0/6] Add Loongson SX/ASX instruction support to LoongArch target.

These patches add the Loongson SX/ASX instruction support to the LoongArch target, and can be utilized by using the new "-mlsx" and "-mlasx" option. Patches are bootstrapped and tested on loongarch64-linux-gnu target. Lulu Cheng (6): LoongArch: Added Loongson SX vector directive compilation fra

Re: Re: [PATCH] Machine Description: Add LEN_MASK_{GATHER_LOAD, SCATTER_STORE} pattern

Thanks for the comments. I will fix doc's description as you suggested. I personally prefer **NOT** to include BIAS in the gather/scatter since I don't known how it will be used. Let's wait for Richi or Richard more comments. Thanks. juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-06-29 2

RE: Re: [PATCH v3] Streamer: Fix out of range memory access of machine mode

That’s very cool, thanks Thomas for help! Let’s wait the AMD test running result for the final version of the patch. Pan From: juzhe.zh...@rivai.ai Sent: Friday, June 30, 2023 9:27 AM To: Thomas Schwinge ; Li, Pan2 ; gcc-patches ; rguenther ; jakub Cc: Robin Dapp ; jeffreyalaw ; Wang, Yanzh

Re: Re: [PATCH] RISC-V: Support vfwnmacc/vfwmsac/vfwnmsac combine lowering

>> I've triple checked this already. You mean you still didn't see vfwmul.vv ? That's odd. Let's wait for kito or Robin test this patch. Then, I believe they will know what I am saying. >> I would strongly suggest looking at a dependency height reduction >> pattern if you want to optimize that co

Re: [PATCH] RISC-V: Support vfwnmacc/vfwmsac/vfwnmsac combine lowering

On 6/29/23 19:14, juzhe.zh...@rivai.ai wrote: No, reduction patterns won't help. As I said in vfwmul patch. You should make sure your environment is working then try again. I've triple checked this already. I checked it again and your patch does not impact behavior, nor should it. I chec

Re: Re: [PATCH v3] Streamer: Fix out of range memory access of machine mode

Thanks a lot! Really appreciate your help ! That's really helpful for RVV (RISC-V vector). Could you merge your patch after you tested? Thanks. juzhe.zh...@rivai.ai From: Thomas Schwinge Date: 2023-06-30 04:14 To: Pan Li; gcc-patches@gcc.gnu.org; Richard Biener; Jakub Jelinek CC: juzhe.zh...@

Re: Re: [PATCH] RISC-V: Support vfwnmacc/vfwmsac/vfwnmsac combine lowering

No, reduction patterns won't help. As I said in vfwmul patch. You should make sure your environment is working then try again. Thanks. juzhe.zh...@rivai.ai From: Jeff Law Date: 2023-06-30 07:43 To: 钟居哲; gcc-patches CC: kito.cheng; kito.cheng; palmer; palmer; rdapp.gcc Subject: Re: [PATCH] R

Re: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

Hi, Jeff. That's odd. I think maybe you should first clean up your environment ? Or you didn't build up the toolchain correctly with this patch? Compile option: --param=riscv-autovec-preference=scalable -O3 -ffast-math Before this patch: https://godbolt.org/z/Y5d44WMqs fail.s: lw t5,0(sp) ble

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

On 6/29/23 17:46, juzhe.zhong wrote: You should try the example check the codegen before and after the patch. You will understand it. I've already done that. It makes _no_ difference on the godbold example. Jeff

Re: [PATCH] RISC-V: Support vfwnmacc/vfwmsac/vfwnmsac combine lowering

On 6/28/23 16:56, 钟居哲 wrote: juzhe.zh...@rivai.ai *From:* Jeff Law *Date:* 2023-06-29 06:43 *To:* 钟居哲 ; gcc-patches

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

On 6/28/23 16:00, 钟居哲 wrote: You can see here: https://godbolt.org/z/d78646hWb You patch doesn't help that code and your patch is a result of fundamentally misunderstanding combine's capabilities AFAICT. Jeff

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

On 6/28/23 16:00, 钟居哲 wrote: You can see here: https://godbolt.org/z/d78646hWb So just to be explicit, I see no difference with that test before/after your proposed change. Nor would I expect one based on my understanding of the patch. The explicit conve

[PATCH ver 3] rs6000: Update the vsx-vector-6.* tests.

GCC maintainers: Ver 3. Added __attribute__ ((noipa)) to the test files. Changed some of the scan-assembler-times checks to cover multiple similar instructions. Change the function check macro to a macro to generate a function to do the test and check the results. Retested on the various proce

Re: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

Or do you have better solution to make the case succeed to combine into vfwmul? I am ok with any solution. juzhe.zh...@rivai.ai From: Jeff Law Date: 2023-06-30 06:59 To: 钟居哲; gcc-patches CC: kito.cheng; kito.cheng; palmer; palmer; rdapp.gcc Subject: Re: [PATCH] RISC-V: Support vfwmul.vv combin

Re: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

>> Right now I don't see a need for this patch. No, we need this patch. With this patch, this following case can be combine into vfwmul.vv: #define TEST_TYPE(TYPE1, TYPE2)\ __attribute__ ((noipa)) void vwadd_##TYPE1_##TYPE2 (

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

On 6/28/23 16:00, 钟居哲 wrote: You can see here: https://godbolt.org/z/d78646hWb The first case can't genreate vfwmul.vv but second case succeed. Failed to match this instruction: (set (reg:VNx2DF 150 [ vect__11.50 ])     (if_then_else:VNx2DF (unspec:VNx2BI

Re: [PATCH] c++: fix up caching of level lowered ttps

On 6/1/23 17:42, Patrick Palka wrote: Due to level/depth mismatches between the template parameters of a level lowered ttp and the original ttp, the ttp comparison check added by r14-418-g0bc2a1dc327af9 never actually holds outside of erroneous cases. Moreover, it'd be good to cache the overall T

Re: [PATCH 2/19][front-end] C/C++ front-end: add pragma GCC novector

On 6/28/23 09:41, Tamar Christina wrote: Hi All, FORTRAN currently has a pragma NOVECTOR for indicating that vectorization should not be applied to a particular loop. ICC/ICX also has such a pragma for C and C++ called #pragma novector. As part of this patch series I need a way to easily turn

Re: [PATCH] rs6000: Update the vsx-vector-6.* tests.

Kewen: On Wed, 2023-06-28 at 16:35 +0800, Kewen.Lin wrote: > > Yea, I was going with a runnable test and didn't include the > > instruction counts. Added back in. Rather then doing by processor > > version (P8, P9, P10) I was able to do it by BE/LE. The > > instruction > > counts were the same

Re: [PATCH v1] RISC-V: Refactor vxrm_mode attr for type attr equal

On 6/29/23 00:00, pan2...@intel.com wrote: From: Pan Li This patch would like to refactor the vxrm_mode attr for duplicated eq_attr condition. The common condition of attr is extraced to one place instead of many places. Signed-off-by: Pan Li gcc/ChangeLog: * config/riscv/vector.

Extend ipa-fnsummary to skip __builtin_expect

Compute ipa-predicates for conditionals involving __builtin_expect_p std::vector allocator looks as follows: __attribute__((nodiscard)) struct pair * std::__new_allocator >::allocate (struct __new_allocator * const this, size_type __n, const void * D.27753) { bool _1; long int _2; long in

Re: [PATCH] analyzer: Fix regression bug after r14-1632-g9589a46ddadc8b [PR110198]

On Thu, 2023-06-29 at 20:45 +0200, priour...@gmail.com wrote: > From: benjamin priour > > See below formatting updates on my patch. > In mail > https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623140.html, > David Malcolm says regtesting failed for him. > > So I did it once more this morning

Re: [PATCH] testsuite: Use -fno-report-bug in gcc.dg/plugin/

On Thu, 2023-06-29 at 15:03 -0400, Marek Polacek wrote: > Certain downstream compilers (for example, in Fedora) default to > -freport-bug.  The extra output breaks the following tests.  We can > use > -fno-report-bug to fix that.  Patch verified with: > > $ make check RUNTESTFLAGS='--target_board=

Re: [PATCH v3] Streamer: Fix out of range memory access of machine mode

Hi! On 2023-06-29T11:29:57+0200, I wrote: > On 2023-06-21T15:58:24+0800, Pan Li via Gcc-patches > wrote: >> We extend the machine mode from 8 to 16 bits already. But there still >> one placing missing from the streamer. It has one hard coded array >> for the machine code like size 256. >> >> In

Re: [PATCH] i386: add -fno-stack-protector to two tests

On Fri, Jun 30, 2023 at 04:11:44AM +0800, Xi Ruoyao wrote: > On Fri, 2023-06-30 at 04:08 +0800, Xi Ruoyao wrote: > > On Thu, 2023-06-29 at 16:01 -0400, Marek Polacek via Gcc-patches wrote: > > > These tests fail when the testsuite is executed with -fstack- > > > protector-strong. > > > To avoid thi

Re: [PATCH] i386: add -fno-stack-protector to two tests

On Fri, Jun 30, 2023 at 04:11:44AM +0800, Xi Ruoyao via Gcc-patches wrote: > On Fri, 2023-06-30 at 04:08 +0800, Xi Ruoyao wrote: > > On Thu, 2023-06-29 at 16:01 -0400, Marek Polacek via Gcc-patches wrote: > > > These tests fail when the testsuite is executed with -fstack- > > > protector-strong. >

Re: [PATCH] i386: add -fno-stack-protector to two tests

On Fri, 2023-06-30 at 04:08 +0800, Xi Ruoyao wrote: > On Thu, 2023-06-29 at 16:01 -0400, Marek Polacek via Gcc-patches wrote: > > These tests fail when the testsuite is executed with -fstack- > > protector-strong. > > To avoid this, this patch adds -fno-stack-protector to dg-options. > > > > Teste

Re: [PATCH] i386: add -fno-stack-protector to two tests

On Thu, Jun 29, 2023 at 04:01:20PM -0400, Marek Polacek via Gcc-patches wrote: > These tests fail when the testsuite is executed with -fstack-protector-strong. > To avoid this, this patch adds -fno-stack-protector to dg-options. > > Tested on x86_64-pc-linux-gnu, ok for trunk? > > gcc/testsuite/C

Re: [PATCH] i386: add -fno-stack-protector to two tests

On Thu, 2023-06-29 at 16:01 -0400, Marek Polacek via Gcc-patches wrote: > These tests fail when the testsuite is executed with -fstack- > protector-strong. > To avoid this, this patch adds -fno-stack-protector to dg-options. > > Tested on x86_64-pc-linux-gnu, ok for trunk? LGTM, we've noticed the

[PATCH] i386: add -fno-stack-protector to two tests

These tests fail when the testsuite is executed with -fstack-protector-strong. To avoid this, this patch adds -fno-stack-protector to dg-options. Tested on x86_64-pc-linux-gnu, ok for trunk? gcc/testsuite/ChangeLog: * gcc.target/i386/pr104610.c: Use -fno-stack-protector. * gcc.ta

[PATCH] testsuite: Use -fno-report-bug in gcc.dg/plugin/

Certain downstream compilers (for example, in Fedora) default to -freport-bug. The extra output breaks the following tests. We can use -fno-report-bug to fix that. Patch verified with: $ make check RUNTESTFLAGS='--target_board=unix\{,-freport-bug\} plugin.exp' Tested x86_64-pc-linux-gnu, ok fo

Re: [PATCH] analyzer: Fix regression bug after r14-1632-g9589a46ddadc8b [PR110198]

From: benjamin priour See below formatting updates on my patch. In mail https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623140.html, David Malcolm says regtesting failed for him. So I did it once more this morning rebased on fresh trunk dc93a0f633b and target x86_64-linux-gnu, the output was

Re: [PATCH] aarch64: Remove architecture dependencies from intrinsics

On Tue, Jun 27, 2023 at 07:23:32AM +0100, Richard Sandiford wrote: > Andrew Carlotti via Gcc-patches writes: > > Many intrinsics currently depend on both an architecture version and a > > feature, despite the corresponding instructions being available within > > GCC at lower architecture versions.

Re: [PATCH] Relax type-printer regexp in libstdc++ test suite

On Thu, 29 Jun 2023 at 17:59, Tom Tromey wrote: > > Jonathan Wakely writes: > > > Looks good. OK for trunk, and OK to backport after some soak time on > trunk. Thanks. > > AdaCore doesn't need a backport of this, and I don't think it's > extremely important; so unless you want me to do it, I

Re: [PATCH] c++: unpropagated CONSTRUCTOR_MUTABLE_POISON [PR110463]

On 6/29/23 11:36, Marek Polacek wrote: On Thu, Jun 29, 2023 at 11:22:55AM -0400, Patrick Palka via Gcc-patches wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/13? -- >8 -- cp_fold is neglecting to propagate CONSTRUCTOR_MUTABLE_POISON when folding a CONSTRU

Re: [PATCH] c++: NSDMI instantiation during overload resolution [PR110468]

On 6/29/23 11:22, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/13/12? OK. -- >8 -- Here we find ourselves instantiating the NSDMI for A<1>::m when computing argument conversions during overload resolution, and thus tf_conv is set. This

Re: [PATCH] c++: Fix ICE with parameter pack of decltype(auto) [PR103497]

On 6/24/23 09:24, Nathaniel Shead wrote: On Fri, Jun 23, 2023 at 11:59:51AM -0400, Patrick Palka wrote: Hi, On Sat, 22 Apr 2023, Nathaniel Shead via Gcc-patches wrote: Bootstrapped and tested on x86_64-pc-linux-gnu. -- 8< -- This patch raises an error early when the decltype(auto) specifier

Re: [PATCH] Relax type-printer regexp in libstdc++ test suite

> Jonathan Wakely writes: > Looks good. OK for trunk, and OK to backport after some soak time on trunk. > Thanks. AdaCore doesn't need a backport of this, and I don't think it's extremely important; so unless you want me to do it, I don't plan to. I did check it in on trunk earlier today.

[COMMITTED] Tidy up the range normalization code.

There's a few spots where a range is being altered in-place, but we fail to call normalize the range. This patch makes sure we always call normalize_kind(), and that normalize_kind in turn, calls verify_range to make sure verything is canonical. gcc/ChangeLog: * value-range.cc (frange::s

[COMMITTED] Move maybe_set_nonzero_bits() to its only user.

gcc/ChangeLog: * tree-vrp.cc (maybe_set_nonzero_bits): Move from here... * tree-ssa-dom.cc (maybe_set_nonzero_bits): ...to here. * tree-vrp.h (maybe_set_nonzero_bits): Remove. --- gcc/tree-ssa-dom.cc | 65 + gcc/tree-vrp.cc |

Re: [PATCH] configure: Implement --enable-host-bind-now

On Thu, Jun 29, 2023 at 05:58:22PM +0200, Martin Jambor wrote: > Hi, > > On Tue, Jun 27 2023, Marek Polacek wrote: > > On Tue, Jun 27, 2023 at 01:39:16PM +0200, Martin Jambor wrote: > >> Hello, > >> > >> On Tue, May 16 2023, Marek Polacek via Gcc-patches wrote: > >> > As promised in the --enable-

Re: [PATCH] configure: Implement --enable-host-bind-now

Hi, On Tue, Jun 27 2023, Marek Polacek wrote: > On Tue, Jun 27, 2023 at 01:39:16PM +0200, Martin Jambor wrote: >> Hello, >> >> On Tue, May 16 2023, Marek Polacek via Gcc-patches wrote: >> > As promised in the --enable-host-pie patch, this patch adds another >> > configure option, --enable-host-bi

Re: [PATCH] c++: unpropagated CONSTRUCTOR_MUTABLE_POISON [PR110463]

On Thu, Jun 29, 2023 at 11:22:55AM -0400, Patrick Palka via Gcc-patches wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > trunk/13? > > -- >8 -- > > cp_fold is neglecting to propagate CONSTRUCTOR_MUTABLE_POISON when folding > a CONSTRUCTOR initializer, which for

[committed] cselib+expr+bitmap: Change return type of predicate functions from int to bool

gcc/ChangeLog: * cselib.h (rtx_equal_for_cselib_1): Change return type from int to bool. (references_value_p): Ditto. (rtx_equal_for_cselib_p): Ditto. * expr.h (can_store_by_pieces): Ditto. (try_casesi): Ditto. (try_tablejump): Ditto. (safe_from_p): Ditto. * sbi

[committed] libstdc++: Do not use off64_t in calls to copy_file_range [PR110462]

Tested x86_64-linux. Pushed to trunk. -- >8 -- Although the copy_file_range(2) man page shows the arguments as off64_t* that is not portable. For musl there is no off64_t type, as off_t is always 64-bit. Use the loff_t type which is always 64-bit even if off_t isn't. We could just use off_t becau

[PATCH] c++: unpropagated CONSTRUCTOR_MUTABLE_POISON [PR110463]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/13? -- >8 -- cp_fold is neglecting to propagate CONSTRUCTOR_MUTABLE_POISON when folding a CONSTRUCTOR initializer, which for the below testcase causes us to fail to reject a mutable member access of a constexpr variabl

[PATCH] c++: NSDMI instantiation during overload resolution [PR110468]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/13/12? -- >8 -- Here we find ourselves instantiating the NSDMI for A<1>::m when computing argument conversions during overload resolution, and thus tf_conv is set. This causes mark_used for the constructor used in the

[committed] libstdc++: Fix src/c++20/tzdb.cc for non-constexpr std::mutex

This build failure for riscv32-esp-elf was "reported" on the gcc-help list: https://gcc.gnu.org/pipermail/gcc-help/2023-June/142641.html Tested x86_64-linux. Pushed to trunk. -- >8 -- Building libstdc++ reportedly fails for targets without lock-free std::atomic which don't define __GTHREAD_MUTEX

Re: [PATCH] Introduce hardbool attribute for C

Hi, ALexandre, Thank you for the explanation. I am now clear with the interaction between hardbool and -ftrivial-auto-var-init, and also agree that clarifying the documentation on their interaction is good enough. Qing > On Jun 29, 2023, at 6:30 AM, Alexandre Oliva wrote: > > On Jun 28, 2023

Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

On 6/29/23 02:11, Richard Biener wrote: On Wed, 28 Jun 2023, Jeff Law wrote: On 6/28/23 22:04, Li, Pan2 wrote: It seems this patch may result in many test ICE failures on RISC-V backend. Could you help to double confirm about it follow the possible reproduce steps like blow? Thank you! I

Re: [PATCH] Machine Description: Add LEN_MASK_{GATHER_LOAD, SCATTER_STORE} pattern

Hi Juzhe, just looking at the documentation changes. > +@cindex @code{len_mask_gather_load@var{m}@var{n}} instruction pattern > +@item @samp{len_mask_gather_load@var{m}@var{n}} > +Like @samp{gather_load@var{m}@var{n}}, but takes an extra len operand > +as operand 5 and an extra mask operand as op

Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

>> Hi Robin: >> >>> diff --git a/gcc/lto/lto-lang.cc b/gcc/lto/lto-lang.cc >>> index 52d7626e92e..14d419c2013 100644 >>> --- a/gcc/lto/lto-lang.cc >>> +++ b/gcc/lto/lto-lang.cc >>> @@ -1050,7 +1050,7 @@ lto_type_for_mode (machine_mode mode, int unsigned_p) >>>else if (GET_MODE_CLASS (mode) == M

Re: [PATCH 10/11] riscv: thead: Add support for the XTheadMemIdx ISA extension

On 6/29/23 01:39, Christoph Müllner wrote: On Wed, Jun 28, 2023 at 8:23 PM Jeff Law wrote: On 6/28/23 06:39, Christoph Müllner wrote: +;; XTheadMemIdx overview: +;; All peephole passes attempt to improve the operand utilization of +;; XTheadMemIdx instructions, where one sign or zero ex

Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

Kito Cheng writes: > Hi Robin: > >> diff --git a/gcc/lto/lto-lang.cc b/gcc/lto/lto-lang.cc >> index 52d7626e92e..14d419c2013 100644 >> --- a/gcc/lto/lto-lang.cc >> +++ b/gcc/lto/lto-lang.cc >> @@ -1050,7 +1050,7 @@ lto_type_for_mode (machine_mode mode, int unsigned_p) >>else if (GET_MODE_CLASS

Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

Hi Robin: > diff --git a/gcc/lto/lto-lang.cc b/gcc/lto/lto-lang.cc > index 52d7626e92e..14d419c2013 100644 > --- a/gcc/lto/lto-lang.cc > +++ b/gcc/lto/lto-lang.cc > @@ -1050,7 +1050,7 @@ lto_type_for_mode (machine_mode mode, int unsigned_p) >else if (GET_MODE_CLASS (mode) == MODE_VECTOR_BOOL >

Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors

On Wed, Jun 28, 2023 at 1:26 PM Tejas Belagod wrote: > > > > > > From: Richard Biener > Date: Tuesday, June 27, 2023 at 12:58 PM > To: Tejas Belagod > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors > > On Tue, Jun 27, 2023 at 8:30 AM Tejas Belago

Re: [committed] libstdc++: Fix preprocessor conditions for std::from_chars [PR109921]

On Thu, 29 Jun 2023 at 14:50, Jonathan Wakely wrote: > > > On Thu, 1 Jun 2023 at 12:05, Jonathan Wakely > wrote: > >> On Thu, 1 Jun 2023 at 10:30, Christophe Lyon via Libstdc++ >> wrote: >> > >> > Hi, >> > >> > >> > On Wed, 31 May 2023 at 14:25, Jonathan Wakely via Gcc-patches < >> > gcc-patche

Re: [PATCH][RFC] target/110456 - avoid loop masking with zero distance dependences

On Thu, 29 Jun 2023, Richard Sandiford wrote: > Richard Biener writes: > > With applying loop masking to epilogues on x86_64 AVX512 we see > > some significant performance regressions when evaluating SPEC CPU 2017 > > that are caused by store-to-load forwarding fails across outer > > loop iterati

Re: [PATCH][RFC] target/110456 - avoid loop masking with zero distance dependences

Richard Biener writes: > With applying loop masking to epilogues on x86_64 AVX512 we see > some significant performance regressions when evaluating SPEC CPU 2017 > that are caused by store-to-load forwarding fails across outer > loop iterations when the inner loop does not iterate. Consider > >

[PATCH] LoongArch: Fix bug in loongarch_emit_stack_tie [PR110484].

From: Lulu Cheng Which may result in implicit references to $fp when frame_pointer_needed is false, causing regs_ever_live[$fp] to be true when $fp is not explicitly used, resulting in $fp being used as the target replacement register in the rnreg pass. The bug originates from SPEC2017 541.lee

Re: [committed] libstdc++: Fix preprocessor conditions for std::from_chars [PR109921]

On Thu, 1 Jun 2023 at 12:05, Jonathan Wakely wrote: > On Thu, 1 Jun 2023 at 10:30, Christophe Lyon via Libstdc++ > wrote: > > > > Hi, > > > > > > On Wed, 31 May 2023 at 14:25, Jonathan Wakely via Gcc-patches < > > gcc-patches@gcc.gnu.org> wrote: > > > > > Tested powerpc64le-linux. Pushed to trun

[PATCH][RFC] target/110456 - avoid loop masking with zero distance dependences

With applying loop masking to epilogues on x86_64 AVX512 we see some significant performance regressions when evaluating SPEC CPU 2017 that are caused by store-to-load forwarding fails across outer loop iterations when the inner loop does not iterate. Consider for (j = 0; j < m; ++j) for (i

Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

> This should probably use GET_MODE_PRECISION as well. > > OK if it bootstraps/tests on both aarch64 and riscv. > > Richard. I found a several other instances, also in the frontends that I'm not exactly sure about. I'm currently testing this but aarch64 bootstrap is still going to take a while,

Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

On Thu, Jun 29, 2023 at 11:10 AM Robin Dapp via Gcc-patches wrote: > > > Yeah, that part is OK, and was the case I was thinking about when > > I said OK yesterday. But now that we allow BITSIZE != PRECISION, > > it's possible for BITSIZE - PRECISION to be more than a full byte, > > in which case

Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

>> Since nobody else has provided a patch yet, is the attached OK as long >> as x86 bootstrap and testsuite are clean? > > Yes. Bootstrap and testsuite are good. Going to commit. Thanks. Regards Robin

[Committed] Add -mmove-max=128 -mstore-max=128 to pieces-memcmp-2.c

Adding -mmove-max=128 and -mstore-max=128 to the dg-options of the recently added gcc.target/i386/pieces-memcmp-2.c avoids changing the intent of this testcase when adding -march=cascadelake to RUNTESTFLAGS. Tested on x86_64-pc-linux-gnu. Committed as obvious. 2023-06-29 Roger Sayle gcc/tes

Re: [PATCH v2] mips: Fix overaligned function arguments [PR109435]

> Ohh, my fault: the `-flto` option should always be skipped, when run test. Right, if tests run with `-flto` option, they will fail. However, I do believe they are run only if LTO support is enabled, that's why my tests all passed without explicitly skipping that option. Your modification looks

Re: [PATCH] Introduce hardbool attribute for C

On Jun 28, 2023, Qing Zhao wrote: > In summary, Ada’s Boolean variables (whether it’s hardened or not) are > represented as > enumeration types in GNU IR. Not quite. Only boolean types with representation clauses are. Those without (such as Standard.Boolean) are BOOLEAN_TYPEs. But those witho

Re: [PATCH 2/2] AArch64: New RTL for ABDL

Oluwatamilore Adebayo writes: > From: oluade01 > > This patch adds new RTL for ABDL (sabdl, sabdl2, uabdl, uabdl2). > > gcc/ChangeLog: > > * config/aarch64/aarch64-simd.md > (vec_widen_abdl_lo_, vec_widen_abdl_hi_): > Expansions for abd vec widen optabs. > (aarch64_abdl_in

Re: [PATCH 1/2] Mid engine setup [SU]ABDL

Oluwatamilore Adebayo writes: > From: oluade01 > > This updates vect_recog_abd_pattern to recognize the widening > variant of absolute difference (ABDL, ABDL2). > > gcc/ChangeLog: > > * internal-fn.cc (widening_fn_p, decomposes_to_hilo_fn_p): > Add IFN_VEC_WIDEN_ABD to the switch stat

Re: Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

Yes. Thanks for taking care of it! juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-06-29 18:07 To: juzhe.zh...@rivai.ai; pan2.li; Richard Biener CC: rdapp.gcc; gcc-patches; jeffreyalaw; kito.cheng Subject: Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs Ah, the one sub-thread continued befo

Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

Ah, the one sub-thread continued before you were CC'ed. Sorry about that. Regards Robin

Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

> Currently, I have no ideal how to walk around this ICE in RISC-V port. > Do you have any suggestions? I'm already bootstrapping this patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623184.html I replied to all but it seems you got lost in the thread? Regards Robin

Re: [PATCH v2] mips: Fix overaligned function arguments [PR109435]

YunQiang Su 于2023年6月29日周四 14:04写道： > > Jovan Dmitrovic 于2023年6月27日周二 16:54写道： > > > > Hi, > > I am sending a revised patch, now with different tests for N64/N32 and O32 > > ABIs. > > For the O32 ABI, I've skipped the -O0 and -Os pipelines, considering there > > is a > > difference between exact

Re: RE: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

Hi， Richi. I tried to debug this ICE: (gdb) call print_gimple_stmt(stdout,stmt,0,0) vect_patt_2876.406_2862 = vect_patt_2877.405_2864 % { 6, ... }; (gdb) p type->type_common.mode $2 = E_VNx4HImode Currently, I have no ideal how to walk around this ICE in RISC-V port. Do you have any suggestions?

Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

On Thu, 29 Jun 2023, Robin Dapp wrote: > > I think GCN people wanted to make this code work for vectors, the > > most obvious local fix is to use element_precision (type) above. > > > > Note usually vector integer divisions are not a thing so this might > > explain why you're seeing this only wit

  1   2   >