Re: [Patch] gcc.c-torture/compile/103818.c: enable for llp64 too

On 2/28/23 02:10, Hans-Peter Nilsson wrote: On Sun, 26 Feb 2023, Jonathan Yong via Gcc-patches wrote: Patch OK for master branch? I did not see any obvious issues to exclude LLP64 specifically. I see "lp64 || lp64" in that patch (which should preferably have been sent inline, as it's harder

Ping: [PATCH v4] rs6000: Fix incorrect RTL for Power LE when removing the UNSPECS [PR106069]

Hi Segher, Ping this for stage 4... On 2023/2/10 10:59, Xionghu Luo via Gcc-patches wrote: Resend this patch... v4: Update per comments. v3: rename altivec_vmrghb_direct_le to altivec_vmrglb_direct_le to match the actual output ASM vmrglb. Likewise for all similar xxx_direct_le patterns. v2:

Re: [PATCH] RISC-V: Fix wrong partial subreg check for bsetidisi

I encountered a miscompilation case with zbs, where bseti without sign extension emitted from bsetidisi pattern leads to wrong output. Take pr68648.c as an example, -march=rv64gc_zba_zbb_zbs -O3 did not generate sext.w in int bar (void) and led to a wrong value in a0. It seems that the partial

[PATCH] RISC-V: Fix wrong partial subreg check for bsetidisi

From: Lin Sinan The partial subreg check should be for subreg operand(operand 1) instead of the immediate operand(operand 2). This change also fix pr68648.c in zbs. gcc/ChangeLog: * config/riscv/bitmanip.md: Fix wrong index in the check. --- gcc/config/riscv/bitmanip.md | 2 +- 1

[PATCH] RISC-V: Allow const0_rtx operand in max/min

From 73e743348a49a7fffcf2e328b8179e8dbbc3b2b4 Mon Sep 17 00:00:00 2001 From: Lin Sinan Date: Tue, 28 Feb 2023 00:44:55 +0800 Subject: [PATCH] RISC-V: Allow const0_rtx operand in max/min Optimize cases that use max[u]/min[u] against a zero constant. E.g., the case int f(int x) { return x >= 0 ? x

[PATCH] MIPS: Add buildtime option to set msa default

From: Junxian Zhu Add buildtime option to decide whether will compiler build with `-mmsa` option default. gcc/ChangeLog: * config.gcc: add -with-{no-}msa build option. * config/mips/mips.h: Likewise. * doc/install.texi: Likewise. Signed-off-by: Junxian Zhu ---

Re: [Patch] gcc.dg/overflow-warn-9.c: exclude from LLP64

On Mon, 27 Feb 2023, Jonathan Yong via Gcc-patches wrote: > This test is for LP64 only, exclude LLP64 too. > Patch OK? I may be confused, but you're not making use of the "llp64" effective target, there instead excluding/including lp64 / ilp32 in sets that not obviously mean "exclude LLP64".

[PATCHv2, rs6000] Merge two vector shift when their sources are the same

Hi, This patch merges two "vsldoi" insns when their sources are the same. Particularly, it is simplified to be one move if the total shift is multiples of 16 bytes. Bootstrapped and tested on powerpc64-linux BE and LE with no regressions. Thanks Gui Haochen ChangeLog 2023-02-28 Haochen

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

Hi Richard Sandiford, After some investigation, I am not sure if it is possible to make it general without any changes to exact_div. We can add one method like below to get the unit poly for all possible N. template inline POLY_CONST_RESULT (N, Ca, Ca) normalize_to_unit (const poly_int_pod ) {

Re: [patch, libgfortran] Initailize some variable to get rid of nuisance warnings.

Pushed, thanks for feedback On 2/26/23 11:54 PM, Tobias Burnus wrote: Just side remarks, the 0 init in the patch is fine. On 27.02.23 03:53, Jerry D via Gcc-patches wrote: regarding PACK: since this is a bogus warning as the compiler does not realize that dim >= 1, wouldn't a gcc_assert

Re: [Patch] gcc.c-torture/compile/103818.c: enable for llp64 too

On Sun, 26 Feb 2023, Jonathan Yong via Gcc-patches wrote: > Patch OK for master branch? I did not see any obvious issues to exclude LLP64 > specifically. I see "lp64 || lp64" in that patch (which should preferably have been sent inline, as it's harder to quote an attached patch, QED). Sending

Ping: [PATCH] testsuite: Tweak gcc.dg/attr-aligned.c for CRIS

Ping... > From: Hans-Peter Nilsson > Date: Thu, 16 Feb 2023 21:05:29 +0100 > Asking for the lines outside the "#if __CRIS__" part. > Ok to commit? > > -- >8 -- > tm.texi says for BIGGEST_ALIGNMENT (from which > __BIGGEST_ALIGNMENT__ is derived): "Biggest alignment that > any data type can

[COMMITTED] testsuite: No xfail infoleak-vfio_iommu_type1.c bogus for default_packed

Committed as obvious after sanity-checking cris-elf and native x86_64-linux. -- >8 -- There are no messages about padding for targets that don't pad, i.e. default_packed. Noticed for cris-elf, verified for pru-elf at gcc-testresults@. testsuite: *

[COMMITTED] testsuite: Shorten multiline pattern message to the same for fail and pass

As recommended by testsuite maintainer: Regression analysis works only if the string is the same. testsuite: * lib/multiline.exp (handle-multiline-outputs): Shorten message to the same for fail and pass. --- gcc/testsuite/lib/multiline.exp | 4 ++-- 1 file changed, 2

[COMMITTED] testsuite: Remove xfail gcc.dg/tree-ssa/pr91091-2.c RHS ! natural_alignment_32

Committed as obvious. -- >8 -- Reacting to a long-standing XPASS for CRIS. This one is slightly brown paper-bag level; it was never the here-removed xfailed scan that failed and I didn't notice that XPASS when reporting success on the commit as a whole. It's not logical to re-read what was

[COMMITTED] testsuite: Add CRIS to targets not xfailing gcc.dg/attr-alloc_size-11.c:50, 51

Reacting to a long-standing XPASS for CRIS. Maybe better do as https://gcc.gnu.org/PR79356#c11 suggests: xfail it for x86 only ...except I see m68k also does not xpass. testsuite: PR testsuite/79356 * gcc.dg/attr-alloc_size-11.c: Add CRIS to the list of targets excluding

Re: [PATCH] c++: unevaluated array new-expr size constantness [PR108219]

On 2/22/23 14:45, Patrick Palka wrote: Here we're mishandling the unevaluated array new-expressions due to a supposed non-constant array size ever since r12-5253-g4df7f8c79835d569, made us no longer perform constant evaluation of non-manifestly-constant expressions within unevaluated contexts.

Re: [PATCH] c++: Add target hook for emit_support_tinfos [PR108883]

On Mon, Feb 27, 2023 at 06:26:04PM -0500, Jason Merrill wrote: > > The following patch instead adds a target hook which allows the backend > > to temporarily tweak registered types such that emit_support_tinfos > > emits whatever is needed. > > Why handle these types differently from the DFP

Re: [PATCH] c++: variable template and targ deduction [PR108550]

On Mon, Feb 27, 2023 at 06:21:13PM -0500, Jason Merrill wrote: > On 2/23/23 10:54, Marek Polacek wrote: > > On Thu, Feb 23, 2023 at 10:17:22AM -0500, Patrick Palka wrote: > > > On Wed, 22 Feb 2023, Marek Polacek wrote: > > > > > > > In this test, we get a bogus error because we failed to deduce

Ping: [PATCH, V3] PR 107299, GCC does not build on PowerPC when long double is IEEE 128-bit

This is the most important patch to look at: | Date: Wed, 14 Dec 2022 15:29:02 -0500 | From: Michael Meissner | Subject: [PATCH, V3] PR 107299, GCC does not build on PowerPC when long double is IEEE 128-bit | Message-ID: -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432

Re: [PATCH] c++: Add target hook for emit_support_tinfos [PR108883]

On 2/23/23 05:23, Jakub Jelinek wrote: Hi! _Float16 and decltype(0.0bf16) types are on x86 supported only with -msse2. On x86_64 that is the default, but on ia32 it is not. We should still emit fundamental type tinfo for those types in libsupc++.a/libstdc++.*, regardless of whether

Re: [PATCH] c++: Fix up -fcontracts option description [PR108890]

On 2/23/23 05:26, Jakub Jelinek wrote: Hi! This translation PR mentioned the description is a little bit weird. Ok for trunk? OK. 2023-02-23 Jakub Jelinek PR translation/108890 * c.opt (fcontracts): Fix description. --- gcc/c-family/c.opt.jj 2023-02-01

Re: [PATCH] c++: variable template and targ deduction [PR108550]

On 2/23/23 10:54, Marek Polacek wrote: On Thu, Feb 23, 2023 at 10:17:22AM -0500, Patrick Palka wrote: On Wed, 22 Feb 2023, Marek Polacek wrote: In this test, we get a bogus error because we failed to deduce the auto in constexpr auto is_pointer_v = is_pointer::value; to bool. Then

Re: [PATCH] c++: non-dependent variable template-id [PR108848]

On 2/23/23 16:52, Patrick Palka wrote: Here we're incorrectly treating the non-dependent variable template-id tag as dependent ever since r226642 gave variable TEMPLATE_ID_EXPR an empty type which causes the call to finish_template_variable from finish_id_expression_1 to be dead code at template

Re: [PATCH] c++: ICE with constexpr variable template [PR107938]

On 2/23/23 18:51, Marek Polacek wrote: Since r11-557, cp_finish_decl can call check_initializer even in a template for a constexpr initializer. That ultimately leads to convert_for_assignment and check_address_or_pointer_of_packed_member, where we crash, because it doesn't expect that the

Re: [PATCH, rs6000] Tweak modulo define_insns to eliminate register copy

On Mon, Feb 27, 2023 at 04:03:56PM -0600, Pat Haugen wrote: > On 2/27/23 2:53 PM, Segher Boessenkool wrote: > >"Slightly". It takes 12 cycles for the two in parallel (64-bit, p9), > >but 17 cycles for the "cheaper" sequence (divd+mulld+subf, 12+5+2). It > >is all worse if the units are busy of

Re: [PATCH] optabs: Fix up expand_doubleword_shift_condmove for shift_mask == 0 [PR108803]

Hi! On Mon, Feb 27, 2023 at 08:11:09PM +0100, Jakub Jelinek wrote: > (insn 52 48 53 2 (set (reg:CC 66 cc) > (compare:CC (reg:SI 130) > (const_int 0 [0]))) "pr108803.c":12:25 437 {cmpsi} > (expr_list:REG_DEAD (reg:SI 130) > (expr_list:REG_EQUAL (compare:CC

Re: [PATCH] optabs: Fix up expand_doubleword_shift_condmove for shift_mask == 0 [PR108803]

On Mon, Feb 27, 2023 at 09:54:06PM +0100, Jakub Jelinek wrote: > Even if the target-independent code doesn't know what the target dependent > code will do, I don't see how it could emit it safely. I always understood RTL to not have anything like C "undefined behavior", but be closer in general

RE: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]

> -Original Message- > From: Richard Sandiford > Sent: Monday, February 27, 2023 9:33 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

Re: [PATCH, rs6000] Tweak modulo define_insns to eliminate register copy

On 2/27/23 2:53 PM, Segher Boessenkool wrote: Hi! On Mon, Feb 27, 2023 at 02:12:23PM -0600, Pat Haugen wrote: On 2/27/23 11:08 AM, Segher Boessenkool wrote: On Mon, Feb 27, 2023 at 09:11:37AM -0600, Pat Haugen wrote: The define_insns for the modulo operation currently force the target

Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]

Tamar Christina via Gcc-patches writes: >> -Original Message- >> From: Richard Sandiford >> Sent: Monday, February 27, 2023 12:12 PM >> To: Tamar Christina >> Cc: Tamar Christina via Gcc-patches ; nd >> ; rguent...@suse.de; j...@ventanamicro.com >> Subject: Re: [PATCH 1/2]middle-end:

Re: [PATCH] Fortran: fix corner case of IBITS intrinsic [PR108937]

On Mon, Feb 27, 2023 at 09:54:38PM +0100, Harald Anlauf via Fortran wrote: > > as found by the reporter, the result of the intrinsic IBITS > differed from other compilers (e.g. Intel, NAG) for the corner > case that the LEN argument was equal to BIT_SIZE(I), which is > explicitly allowed by the

Re: [PATCH] optabs: Fix up expand_doubleword_shift_condmove for shift_mask == 0 [PR108803]

On Mon, Feb 27, 2023 at 09:01:15PM +, Richard Sandiford via Gcc-patches wrote: > Jakub Jelinek writes: > > On Mon, Feb 27, 2023 at 08:43:27PM +, Richard Sandiford wrote: > >> My argument was that !SHIFT_COUNT_TRUNCATED and > >> C?Z_DEFINED_VALUE_AT_ZERO==0 mean that the behaviour is

[PATCH] i386: Do not constrain fmod and remainder patterns with flag_finite_math_only [PR108922]

According to Intel ISA manual, fprem and fprem1 return NaN when invalid arithmetic exception is generated. This is documented in Table 8-10 of the ISA manual and makes these two instructions fully IEEE compatible. The reverted patch was based on the data from table 3-30 and 3-31 of the Intel ISA

Re: [PATCH] optabs: Fix up expand_doubleword_shift_condmove for shift_mask == 0 [PR108803]

Jakub Jelinek writes: > On Mon, Feb 27, 2023 at 08:43:27PM +, Richard Sandiford wrote: >> My argument was that !SHIFT_COUNT_TRUNCATED and >> C?Z_DEFINED_VALUE_AT_ZERO==0 mean that the behaviour is undefined >> only in the sense that target-independent code doesn't know what >> the behaviour

Re: [PATCH, rs6000] Tweak modulo define_insns to eliminate register copy

Hi! On Mon, Feb 27, 2023 at 02:12:23PM -0600, Pat Haugen wrote: > On 2/27/23 11:08 AM, Segher Boessenkool wrote: > >On Mon, Feb 27, 2023 at 09:11:37AM -0600, Pat Haugen wrote: > >>The define_insns for the modulo operation currently force the target > >>register > >>to a distinct reg in

[PATCH] Fortran: fix corner case of IBITS intrinsic [PR108937]

Dear all, as found by the reporter, the result of the intrinsic IBITS differed from other compilers (e.g. Intel, NAG) for the corner case that the LEN argument was equal to BIT_SIZE(I), which is explicitly allowed by the standard. We actually had an inconsistency for this case between code

Re: [PATCH] optabs: Fix up expand_doubleword_shift_condmove for shift_mask == 0 [PR108803]

On Mon, Feb 27, 2023 at 08:43:27PM +, Richard Sandiford wrote: > My argument was that !SHIFT_COUNT_TRUNCATED and > C?Z_DEFINED_VALUE_AT_ZERO==0 mean that the behaviour is undefined > only in the sense that target-independent code doesn't know what > the behaviour is. !SHIFT_COUNT_TRUNCATED

Re: [PATCH] optabs: Fix up expand_doubleword_shift_condmove for shift_mask == 0 [PR108803]

Jakub Jelinek writes: > On Mon, Feb 27, 2023 at 07:51:21PM +, Richard Sandiford wrote: >> I think RTL and gimple are different in that respect. >> SHIFT_COUNT_TRUNCATED's effect on shifts is IMO a bit like >> CTZ_DEFINED_VALUE_AT_ZERO's effect on CTZ: it enumerates common >> target-specific

Re: [PATCH, rs6000] Tweak modulo define_insns to eliminate register copy

On 2/27/23 11:08 AM, Segher Boessenkool wrote: Hi! On Mon, Feb 27, 2023 at 09:11:37AM -0600, Pat Haugen wrote: The define_insns for the modulo operation currently force the target register to a distinct reg in preparation for a possible future peephole combining div/mod. But this can lead to

Re: [PATCH] optabs: Fix up expand_doubleword_shift_condmove for shift_mask == 0 [PR108803]

On Mon, Feb 27, 2023 at 07:51:21PM +, Richard Sandiford wrote: > I think RTL and gimple are different in that respect. > SHIFT_COUNT_TRUNCATED's effect on shifts is IMO a bit like > CTZ_DEFINED_VALUE_AT_ZERO's effect on CTZ: it enumerates common > target-specific behaviour, but doesn't turn

Re: [PATCH] optabs: Fix up expand_doubleword_shift_condmove for shift_mask == 0 [PR108803]

Jakub Jelinek writes: > On Mon, Feb 27, 2023 at 03:34:11PM +, Richard Sandiford wrote: >> > The following testcase is miscompiled on aarch64. The problem is that >> > aarch64 with TARGET_SIMD is !SHIFT_COUNT_TRUNCATED target with >> > targetm.shift_truncation_mask (DImode) == 0 which has

Re: [PATCH] optabs: Fix up expand_doubleword_shift_condmove for shift_mask == 0 [PR108803]

On Mon, Feb 27, 2023 at 03:34:11PM +, Richard Sandiford wrote: > > The following testcase is miscompiled on aarch64. The problem is that > > aarch64 with TARGET_SIMD is !SHIFT_COUNT_TRUNCATED target with > > targetm.shift_truncation_mask (DImode) == 0 which has HAVE_conditional_move > > true.

Re: [PATCH] testsuite: Don't include multiline regexps in the the pass/fail log

On Feb 27, 2023, at 9:59 AM, Hans-Peter Nilsson wrote: > >> From: Mike Stump >> Date: Mon, 27 Feb 2023 09:41:18 -0800 > >>> diff --git a/gcc/testsuite/lib/multiline.exp >>> b/gcc/testsuite/lib/multiline.exp >>> index 84ba9216642e..5eccf2bbebc1 100644 >>> --- a/gcc/testsuite/lib/multiline.exp

Re: [PR100127] Test for coroutine header in clang-compatible tests

On Feb 22, 2023, at 12:04 PM, Alexandre Oliva wrote: > > That would change what gets tested with clang, I suppose, but I hope > that's for the better. I wondered what to do at the #else above, and > decided to spell it a little differently. Retested on x86_64-linux-gnu > (trunk) and

Re: [PATCH] testsuite: Don't include multiline regexps in the the pass/fail log

> From: Mike Stump > Date: Mon, 27 Feb 2023 09:41:18 -0800 > > diff --git a/gcc/testsuite/lib/multiline.exp > > b/gcc/testsuite/lib/multiline.exp > > index 84ba9216642e..5eccf2bbebc1 100644 > > --- a/gcc/testsuite/lib/multiline.exp > > +++ b/gcc/testsuite/lib/multiline.exp > > > -

Re: [PATCH] testsuite: Don't include multiline regexps in the the pass/fail log

On Feb 24, 2023, at 9:54 AM, Hans-Peter Nilsson via Gcc-patches wrote: > > Ok to commit? Ok. Thanks. > diff --git a/gcc/testsuite/lib/multiline.exp b/gcc/testsuite/lib/multiline.exp > index 84ba9216642e..5eccf2bbebc1 100644 > --- a/gcc/testsuite/lib/multiline.exp > +++

Re: [PATCH, rs6000] Tweak modulo define_insns to eliminate register copy

Hi! On Mon, Feb 27, 2023 at 09:11:37AM -0600, Pat Haugen wrote: > The define_insns for the modulo operation currently force the target > register > to a distinct reg in preparation for a possible future peephole combining > div/mod. But this can lead to cases of a needless copy being inserted.

Re: [Patch] gcc.dg/memchr-3.c: fix for LLP64

Jonathan Yong via Gcc-patches writes: > Attached patch OK? > > gcc.dg/memchr-3.c: fix for LLP64 > > gcc/testsuite/ChangeLog: > > PR middle-end/97956 > * gcc.dg/memchr-3.c (memchr): fix long to size_t in > prototype. > > From

Re: [Patch] gcc.dg/overflow-warn-9.c: exclude from LLP64

Jonathan Yong via Gcc-patches writes: > This test is for LP64 only, exclude LLP64 too. > Patch OK? OK, thanks. Richard > From fbc83ae10df1a0e10c302fb0fee13092eb65818e Mon Sep 17 00:00:00 2001 > From: Jonathan Yong <10wa...@gmail.com> > Date: Mon, 27 Feb 2023 09:49:31 + > Subject: [PATCH]

Re: [PATCH] Fix RTL simplifications of FFS, POPCOUNT and PARITY.

Hi! On Sun, Feb 26, 2023 at 01:10:41PM -, Roger Sayle wrote: > This patch teaches simplify-rtx.cc to err on the side of caution, by never > creating (new) FFS, POPCOUNT or PARITY rtx with mismatched modes, > matching the documentation. > * simplify-rtx.cc

Re: [PATCH] swap: Fix incorrect lane extraction by vec_extract() [PR106770]

Hi! On Wed, Jan 04, 2023 at 01:58:19PM +0530, Surya Kumari Jangala wrote: > In the routine rs6000_analyze_swaps(), special handling of swappable > instructions is done even if the webs that contain the swappable > instructions are not optimized, i.e., the webs do not contain any > permuting

Re: [PATCH] Fixup possible VR_ANTI_RANGE value_range issues

On 2/27/23 14:58, Richard Biener wrote: After fixing PR107561 the following avoids looking at VR_ANTI_RANGE ranges where it doesn't seem obvious the code does the correct thing here (lower_bound and upper_bound do not work as expected). I do realize there's some confusion here, and some of

Re: [PATCH] simplify-rtx: Fix VOIDmode operand handling in simplify_subreg [PR108805]

Uros Bizjak writes: > On Fri, Feb 17, 2023 at 8:38 AM Richard Biener wrote: >> >> On Thu, 16 Feb 2023, Uros Bizjak wrote: >> >> > simplify_subreg can return VOIDmode const_int operand and will >> > cause ICE in simplify_gen_subreg when this operand is passed to it. >> > >> > The patch prevents

Re: [ada] fix unknown type name 'cpu_set_t'

On Feb 27 2023, 宋冬生 via Gcc-patches wrote: > diff --git a/gcc/ada/adaint.h b/gcc/ada/adaint.h > index 987432c93..fa8ddaf13 100644 > --- a/gcc/ada/adaint.h > +++ b/gcc/ada/adaint.h > @@ -319,6 +319,9 @@ extern void *__gnat_lwp_self > (void); > > /* Routines for

Re: [gcc r13-6315] MIPS: Add pattern for clo

On Fri, 24 Feb 2023, YunQiang Su via Gcc-cvs wrote: > https://gcc.gnu.org/g:19aa3900bca808b49417a7aef295b5f1a583c298 > > commit r13-6315-g19aa3900bca808b49417a7aef295b5f1a583c298 > Author: Junxian Zhu > Date: Fri Feb 17 16:35:56 2023 +0800 > > MIPS: Add pattern for clo We are in Stage

Re: [PATCH] optabs: Fix up expand_doubleword_shift_condmove for shift_mask == 0 [PR108803]

Jakub Jelinek writes: > Hi! > > The following testcase is miscompiled on aarch64. The problem is that > aarch64 with TARGET_SIMD is !SHIFT_COUNT_TRUNCATED target with > targetm.shift_truncation_mask (DImode) == 0 which has HAVE_conditional_move > true. If a doubleword shift (in this case

[ada] fix unknown type name 'cpu_set_t'

Hi, When building ada with musl, I encountered the following error: make[7]: Entering directory '/opt/gcc-build/gcc/build/gcc/ada/rts' /opt/gcc-build/gcc/build/./gcc/xgcc -B/opt/gcc-build/gcc/build/./gcc/ -B/opt/gcc-13/aarch64-linux-musl/usr/aarch64-linux-musl/bin/

Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

Never mind, wish you have a good holiday. Thanks for pointing this out, the if part cannot take care of poly_int with N > 2. As I understand, we need to make it general for all the N of poly_int. Thus I would like to double confirm with you about how to make it general. I suppose there will be

Re: [PATCH] don't declare header-defined functions both static and inline, pt 2

On Thu, 16 Feb 2023, Patrick Palka wrote: > This fixes some header-defined functions that are undesirably declared > static and weren't caught by the "^static inline" pattern used in the > previous patch. > > gcc/ChangeLog: > > * hash-table.h (gt_pch_nx): Remove static. > *

[PATCH, rs6000] Tweak modulo define_insns to eliminate register copy

Don't force target of modulo into a distinct register. The define_insns for the modulo operation currently force the target register to a distinct reg in preparation for a possible future peephole combining div/mod. But this can lead to cases of a needless copy being inserted. Fixed with the

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

FWIW, this patch looks good to me. I'd argue it's a regression fix of kinds, in that the current code was correct before variable VF and became incorrect after variable VF. It might be possible to trigger the problem on SVE too, with a sufficiently convoluted test case. (Haven't tried though.)

[committed] libstdc++: Add Doxygen comment for string::resize_and_overwite

Here's what I committed, including the fix for the typo Daniel spotted. Pushed to trunk. -- >8 -- This is a complicated API that should be clearly documented. Also improve the comment on basic_ios::_M_setstate. libstdc++-v3/ChangeLog: * include/bits/basic_ios.h

Fwd: [V2][PATCH] Fixing PR107411

Ping. Qing Begin forwarded message: From: Qing Zhao mailto:qing.z...@oracle.com>> Subject: [V2][PATCH] Fixing PR107411 Date: February 21, 2023 at 9:46:04 AM EST To: ja...@redhat.com, rguent...@suse.de Cc:

Re: [PATCH] constraint: fix relaxed memory and repeated constraint handling

"Victor L. Do Nascimento" writes: > The function `constrain_operands' lacked the logic to consider relaxed > memory constraints when "traditional" memory constraints were not > satisfied, creating potential issues as observed during the reload > compilation pass. > > In addition, it was observed

Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

Sorry for the slow reply, been away for a couple of weeks. "incarnation.p.lee--- via Gcc-patches" writes: > From: Pan Li > > Fix the bug of the rvv bool mode precision with the adjustment. > The bits size of vbool*_t will be adjusted to > [1, 2, 4, 8, 16, 32, 64] according to

Re: [PATCH 1/4]middle-end: Revert can_special_div_by_const changes [PR108583]

On Mon, 27 Feb 2023, Tamar Christina wrote: > Hi All, > > This reverts the changes for the CAN_SPECIAL_DIV_BY_CONST hook. > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > > Ok for master? OK (you don't need approval for such reversion). Thanks, Richard. > Thanks, >

[PATCH] Fixup possible VR_ANTI_RANGE value_range issues

After fixing PR107561 the following avoids looking at VR_ANTI_RANGE ranges where it doesn't seem obvious the code does the correct thing here (lower_bound and upper_bound do not work as expected). Bootstrapped and tested on x86_64-unknown-linux-gnu. OK? Thanks, Richard. *

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

Hi All, This replaces the custom division hook with just an implementation through add_highpart. For NEON we implement the add highpart (Addition + extraction of the upper highpart of the register in the same precision) as ADD + LSR. This representation allows us to easily optimize the sequence

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

Hi All, As Richard S wanted, this now implements a hook preferred_div_as_shifts_over_mult that indicates whether a target prefers that the vectorizer decomposes division as shifts rather than multiplication when possible. In order to be able to use this we need to check whether the current

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

Hi All, This adds range-ops for widening addition and widening multiplication. I couldn't figure out how to write a test for this. It looks like there are self tests but not a way to write standalone ones? I did create testcases in the patch 3/4 which tests the end result. Bootstrapped

[PATCH 1/4]middle-end: Revert can_special_div_by_const changes [PR108583]

Hi All, This reverts the changes for the CAN_SPECIAL_DIV_BY_CONST hook. Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. Ok for master? Thanks, Tamar gcc/ChangeLog: PR target/108583 * doc/tm.texi (TARGET_VECTORIZE_CAN_SPECIAL_DIV_BY_CONST): Remove. *

Re: [PATCH] s390: Add LEN_LOAD/LEN_STORE support.

On 2/27/23 11:13, Robin Dapp wrote: >> Do you really need a copy of the address register? Couldn't you just do a >> src = adjust_address (operands[1], BLKmode, 0); >> You create a paradoxical subreg of the QImode input but vll actually >> uses the whole 32 bit value. Couldn't we end up with

Re: [PATCH 2/2, GCC12] AArch64: Gate various crypto intrinsics availability based on features

Tejas Belagod writes: > The 64-bit variant of PMULL{2} and AES instructions are available if FEAT_AES > is implemented according to the Arm ARM [1]. Similarly FEAT_SHA1 and > FEAT_SHA256 enable the use of SHA1 and SHA256 instruction variants. > This patch fixes arm_neon.h to correctly reflect

Re: [PATCH 1/2, GCC12] AArch64: Update transitive closures of aes, sha2 and sha3 extensions

Tejas Belagod writes: > Transitive closures of architectural extensions have to be manually maintained > for AARCH64_OPT_EXTENSION list. Currently aes, sha2 and sha3 extensions add > AARCH64_FL_SIMD has their dependency - this does not automatically pull in the > transitive dependence of

[Patch,v3] Fortran/OpenMP: Fix mapping of array descriptors and deferred-length strings

And another re-diff for GCC 13/mainline, updating gcc/testsuite/ (The last change is related to the "[OG12,committed] Update dg-dump-scan for ..." discussion + OG12 https://gcc.gnu.org/g:e4de87a2309 / https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612871.html ) On 23.02.23 17:42,

RE: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]

> -Original Message- > From: Richard Sandiford > Sent: Monday, February 27, 2023 12:12 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

Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]

Tamar Christina writes: > Hi, > >> > I avoided open coding it with add and shift because it creates a 4 >> > instructions (and shifts which are typically slow) dependency chain >> > instead of a load and multiply. This change, unless the target is >> > known to optimize it further is unlikely to

Re: [PATCH] xtensa: Make use of CLAMPS instruction if configured

On Sun, Feb 26, 2023 at 9:27 AM Takayuki 'January June' Suwa wrote: > > This patch introduces the use of CLAMPS instruction when the instruction > is configured. > > /* example */ > int test(int a) { > if (a < -512) > return -512; > if (a > 511) > return 511; >

[PATCH] gcc: xtensa: add XCHAL_HAVE_{CLAMPS, DEPBITS, EXCLUSIVE, XEA3} to dynconfig

gcc/ * config/xtensa/xtensa-dynconfig.cc (xtensa_get_config_v2) (xtensa_get_config_v3): New functions. include/ * xtensa-dynconfig.h (xtensa_config_v3): New struct. (xtensa_get_config_v3): New declaration. (XCHAL_HAVE_CLAMPS, XCHAL_HAVE_DEPBITS,

[OG12,committed] Update dg-dump-scan for ... (was: [Patch] Fortran/OpenMP: Fix mapping of array descriptors and deferred-length strings)

Hi Thomas, On 25.02.23 10:11, Thomas Schwinge wrote: Do to the scan patterns need adjusting, or is something wrong? The former. Regarding: * gfortran.dg/goacc/finalize-1.f - for 'acc exit data': !$ACC EXIT DATA FINALIZE DELETE (del_f_p(2:5)) Here, 'map\\(to:del_f_p [pointer set]'

[PING 3] [PATCH] swap: Fix incorrect lane extraction by vec_extract() [PR106770]

Hello, Ping https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609374.html Thanks, Surya On 04/01/23 1:58 pm, Surya Kumari Jangala via Gcc-patches wrote: > swap: Fix incorrect lane extraction by vec_extract() [PR106770] > > In the routine rs6000_analyze_swaps(), special handling of

[PATCH] rs6000: Inline lrint and lrintf

Hello All: Here is the patch for Inline lrint and lrintf. Currently glibc don't use __builtin_lrint as they inline lrint with fctid/fctiw instruction. With the below changes such inlines are not required and lrint builtin can be used. Bootstrapped and regtested on powerpc64-linux-gnu.

RE: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]

Hi, > > I avoided open coding it with add and shift because it creates a 4 > > instructions (and shifts which are typically slow) dependency chain > > instead of a load and multiply. This change, unless the target is > > known to optimize it further is unlikely to be beneficial. And by the > >

[PATCH] RISC-V: Add permutation C/C++ support

From: Ju-Zhe Zhong gcc/ChangeLog: * config/riscv/riscv-protos.h (enum vlen_enum): New enum. (slide1_sew64_helper): New function. * config/riscv/riscv-v.cc (compute_vlmax): Ditto. (get_unknown_min_value): Ditto. (force_vector_length_operand): Ditto.

[Patch] c-c++-common/Warray-bounds.c: fix excess warnings on LLP64

Attached patch OK? Excess errors on x86_64-w64-mingw32: /home/user/p/gcc/src/gcc-git/gcc/testsuite/c-c++-common/Warray-bounds.c:50:3: warning: array subscript 4611686018427387902 is above array bounds of 'struct S16[]' [-Warray-bounds=]

Re: [PING] Re: [PATCH 2/2] Corrected pr25521.c target matching.

Hi Jeff, Please, please, give me some feedback on this one. I just don't want to have to keep asking you for time on this small pending patches that I also have to keep track on. I realized your committed the other one. Thank you ! Best regards, Cupertino Cupertino Miranda writes: > PING

Re: [PATCH] s390: Add LEN_LOAD/LEN_STORE support.

> Do you really need a copy of the address register? Couldn't you just do a > src = adjust_address (operands[1], BLKmode, 0); > You create a paradoxical subreg of the QImode input but vll actually > uses the whole 32 bit value. Couldn't we end up with uninitialized > bytes being used as part of

[Patch] gcc.dg/memchr-3.c: fix for LLP64

Attached patch OK? gcc.dg/memchr-3.c: fix for LLP64 gcc/testsuite/ChangeLog: PR middle-end/97956 * gcc.dg/memchr-3.c (memchr): fix long to size_t in prototype. From 194eb3d43964276beeaea14ebee4b241799cd966 Mon Sep 17 00:00:00 2001 From:

RE: [PATCH][committed] aarch64: Fix typo in comment for aarch64_abs

> -Original Message- > From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Kyrylo > Tkachov via Gcc-patches > Sent: Monday, February 27, 2023 10:00 AM > To: gcc-patches@gcc.gnu.org > Subject: [PATCH][committed] aarch64: Fix typo in comment for > aarch64_abs > >

[PATCH][committed] aarch64: Fix typo in comment for aarch64_abs

Pushing as obvious. gcc/ChangeLog: * config/aarch64/aarch64.md (aarch64_abs): Fix typo in comment. typo.patch Description: typo.patch

[Patch] gcc.dg/overflow-warn-9.c: exclude from LLP64

This test is for LP64 only, exclude LLP64 too. Patch OK?From fbc83ae10df1a0e10c302fb0fee13092eb65818e Mon Sep 17 00:00:00 2001 From: Jonathan Yong <10wa...@gmail.com> Date: Mon, 27 Feb 2023 09:49:31 + Subject: [PATCH] gcc.dg/overflow-warn-9.c: exclude from LLP64 gcc/testsuite/ChangeLog: *

Re: [PATCH] diagnostics: fix crash with -fdiagnostics-format=json-file

PING^4 On 2/17/23 15:52, Martin Liška wrote: PING^3 On 2/1/23 14:13, Martin Liška wrote: PING^2 On 1/24/23 14:34, Martin Liška wrote: PING^1 On 1/10/23 16:10, Martin Liška wrote: On 1/6/23 14:21, David Malcolm wrote: On Fri, 2023-01-06 at 12:33 +0100, Martin Liška wrote: Patch can

[PATCH] RISC-V: Remove void_type_node of void_args for vsetvlmax intrinsic

From: Ju-Zhe Zhong This patch is to fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108927. PR108927 gcc/ChangeLog: * config/riscv/riscv-vector-builtins.cc: Remove void_type_node. --- gcc/config/riscv/riscv-vector-builtins.cc | 5 ++--- 1 file changed, 2 insertions(+), 3