Re: [PATCH v3 04/11] riscv: thead: Add support for the XTheadBs ISA extension

On Wed, Mar 1, 2023 at 1:19 AM Hans-Peter Nilsson wrote: > > > > On Tue, 28 Feb 2023, Christoph Müllner wrote: > > > On Sun, Feb 26, 2023 at 12:42 AM Hans-Peter Nilsson > > wrote: > > > > > > On Fri, 24 Feb 2023, Christoph Muellner wrote: > > > > diff --git a/gcc/config/riscv/thead.md

[PATCH] tree-optimization/108950 - widen-sum reduction ICE

When we end up with a widen-sum with an invariant smaller operand the reduction code uses a wrong vector type for it, causing IL checking ICEs. The following fixes that and the inefficiency of using a widen-sum with a widenend invariant operand as well by actually performing the check the

[PATCH, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]

Hi, The patch escalates the failure when Hollerith constant to real conversion fails in native_interpret_expr. It finally reports an "Unclassifiable statement" error. The patch of pr95450 added a verification for decoding/encoding checking in native_interpret_expr. native_interpret_expr may

[PATCH] rs6000/test: Adjust scalar-test-data-class-1[45].c with int128

Hi, Test cases scalar-test-data-class-1[45].c adopts type __int128 which requires to check int128 effective target, otherwise the testing on them will fail at -m32. This patch is to add int128 effective target requirement. Tested on powerpc64-linux-gnu P7/P8/P9 and powerpc64le-linux-gnu P9/P10.

[PATCH] rs6000/test: Adjust pr101384-2.c for P9 [PR108813]

Hi, Compiled with cpu type Power9 or later, GCC generates xxspltib rather than vspltis*, so adjust the test case scanning content accordingly. Tested on powerpc64-linux-gnu P7/P8/P9 and powerpc64le-linux-gnu P9/P10. I'm going to push this soon if no objections. BR, Kewen - PR

[PATCH] rs6000/test: Adjust fold-vec-extract-double.p9.c for BE [PR108810]

Hi, On BE, the extracted index for the leftmost element is 0 rather than 1, adjust the test case accordingly. Tested on powerpc64-linux-gnu P7/P8/P9 and powerpc64le-linux-gnu P9/P10. I'm going to push this soon if no objections. BR, Kewen - PR testsuite/108810

[PATCH] rs6000/test: Adjust scalar-test-neg-8.c with lp64 [PR108730]

Hi, The built-in function scalar_test_neg_qp is under stanza ieee128-hw, that is TARGET_FLOAT128_HW. Since we don't have float128 hardware support on 32-bit as follows: if (TARGET_FLOAT128_HW && !TARGET_64BIT) { if ((rs6000_isa_flags_explicit & OPTION_MASK_FLOAT128_HW) != 0) error

[PATCH] rs6000/test: Adjust two bfp test cases with has_arch_ppc64 [PR108729]

Hi, Two test cases scalar-test-data-class-12.c and vec-test-data-class-9.c fail on Power9 BE testing at -m32, they adopts a built-in function scalar_insert_exp which requires powerpc64 support. This patch is to make them to check has_arch_ppc64 effective target requirement. Tested on

Re: [PATCH 1/2] testsuite: Fix analyzer errors for newlib-errno

> From: David Malcolm > Date: Tue, 28 Feb 2023 21:25:34 -0500 > On Wed, 2023-03-01 at 01:59 +0100, Hans-Peter Nilsson wrote: > > > From: David Malcolm > > > Date: Tue, 28 Feb 2023 14:12:47 -0500 > > > > > On Tue, 2023-02-28 at 19:47 +0100, Hans-Peter Nilsson wrote: > > > > Ok to commit? > > >

Re: [PATCH 1/2] testsuite: Fix analyzer errors for newlib-errno

On Wed, 2023-03-01 at 01:59 +0100, Hans-Peter Nilsson wrote: > > From: David Malcolm > > Date: Tue, 28 Feb 2023 14:12:47 -0500 > > > On Tue, 2023-02-28 at 19:47 +0100, Hans-Peter Nilsson wrote: > > > Ok to commit? > > > -- >8 -- > > > Investigating analyzer tesstsuite errors for cris-elf.  The

[PATCH] RISC-V: Optimize the MASK opt generation

The Mask flag in the single TargetVariable is not enough due to more and more extensions were added.So I optimize the defination of Mask flag, please refer to the below case: There are some new MASK flags for 'v' extension(ZVL32B,ZVL64B,...,ZVL65536B), but these MASK flags can't store into

Re: [PATCH 1/2] testsuite: Fix analyzer errors for newlib-errno

> From: David Malcolm > Date: Tue, 28 Feb 2023 14:12:47 -0500 > On Tue, 2023-02-28 at 19:47 +0100, Hans-Peter Nilsson wrote: > > Ok to commit? > > -- >8 -- > > Investigating analyzer tesstsuite errors for cris-elf. The same are > > seen for pru-elf according to posts to gcc-testresults@. > > >

Re: [PATCH v3 04/11] riscv: thead: Add support for the XTheadBs ISA extension

On Tue, 28 Feb 2023, Christoph Müllner wrote: > On Sun, Feb 26, 2023 at 12:42 AM Hans-Peter Nilsson wrote: > > > > On Fri, 24 Feb 2023, Christoph Muellner wrote: > > > diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md > > > index 158e9124c3a..2c684885850 100644 > > > ---

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

On Tue, 28 Feb 2023, Jonathan Yong wrote: > On 2/28/23 03:06, Hans-Peter Nilsson wrote: > > > > 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"

Re: [PATCH] amdgcn: Enable SIMD vectorization of math functions

On Tue, Feb 28, 2023 at 3:02 PM Kwok Cheung Yeung wrote: > > Hello > > This patch implements the TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION > target hook for the AMD GCN architecture, such that when vectorized, > calls to builtin standard math functions such as asinf, exp, pow etc. > are

[PATCH] amdgcn: Enable SIMD vectorization of math functions

Hello This patch implements the TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION target hook for the AMD GCN architecture, such that when vectorized, calls to builtin standard math functions such as asinf, exp, pow etc. are converted to calls to the recently added vectorized math functions for

Re: [PATCH] ubsan: Honor -fstrict-flex-arrays= in -fsanitize=bounds [PR108894]

On Tue, Feb 28, 2023 at 07:19:40PM +, Qing Zhao wrote: > Understood. > So, your patch fixed this bug, and then [0] arrays are instrumented by > default with this patch. > > > Well, it would complain about > > struct S { int a; int b[0]; int c; } s; > > ... [1] ... > > for C++, but not for

[wwwdocs] Document synchronized_value addition to libstdc++

Pushed to wwwdocs. --- htdocs/gcc-13/changes.html | 3 +++ 1 file changed, 3 insertions(+) diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html index a803f501..811d9bdf 100644 --- a/htdocs/gcc-13/changes.html +++ b/htdocs/gcc-13/changes.html @@ -324,6 +324,9 @@ a

Re: [PATCH] ubsan: Honor -fstrict-flex-arrays= in -fsanitize=bounds [PR108894]

> On Feb 28, 2023, at 12:49 PM, Jakub Jelinek wrote: > > On Tue, Feb 28, 2023 at 04:13:28PM +, Qing Zhao wrote: >>> On Feb 28, 2023, at 3:26 AM, Jakub Jelinek via Gcc-patches >>> wrote: >>> I think -fstrict-flex-arrays* options can be considered as language >>> mode changing options, by

Re: [PATCH 2/2] testsuite: Fix analyzer errors for newlib-fd

On Tue, 2023-02-28 at 19:49 +0100, Hans-Peter Nilsson wrote: > Ok to commit?  OK

Re: [PATCH 1/2] testsuite: Fix analyzer errors for newlib-errno

On Tue, 2023-02-28 at 19:47 +0100, Hans-Peter Nilsson wrote: > Ok to commit? > -- >8 -- > Investigating analyzer tesstsuite errors for cris-elf.  The same are > seen for pru-elf according to posts to gcc-testresults@. > > For glibc, errno is #defined as: >  extern int *__errno_location (void)

[PATCH 2/2] testsuite: Fix analyzer errors for newlib-fd

Ok to commit? (After this, there's gcc.dg/analyzer/flex-without-call-summaries.c left to do.) -- >8 -- Investigating analyzer testsuite errors for cris-elf. The same are seen for pru-elf according to posts to gcc-testresults@. The test fd-access-mode-target-headers.c uses the analyzer "sm-fd"

[PATCH 1/2] testsuite: Fix analyzer errors for newlib-errno

Ok to commit? -- >8 -- Investigating analyzer tesstsuite errors for cris-elf. The same are seen for pru-elf according to posts to gcc-testresults@. For glibc, errno is #defined as: extern int *__errno_location (void) __THROW __attribute_const__; # define errno (*__errno_location ()) while for

Re: [Patch] harden-sls-6.c: fix warning on LLP64

On Wed, Feb 15, 2023 at 01:44:08PM +, Jonathan Yong via Gcc-patches wrote: > gcc/testsuite/ChangeLog: > > * gcc.target/i386/harden-sls-6.c: fix warning on LLP64 > targets. > > Attached patch OK? > From c0572a1e95c6f569980d6b7454c8dc293f07389e Mon Sep 17 00:00:00 2001 > From:

Re: [PATCH v3 04/11] riscv: thead: Add support for the XTheadBs ISA extension

On Sun, Feb 26, 2023 at 12:42 AM Hans-Peter Nilsson wrote: > > On Fri, 24 Feb 2023, Christoph Muellner wrote: > > diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md > > index 158e9124c3a..2c684885850 100644 > > --- a/gcc/config/riscv/thead.md > > +++ b/gcc/config/riscv/thead.md >

Re: [PATCH] ubsan: Honor -fstrict-flex-arrays= in -fsanitize=bounds [PR108894]

On Tue, Feb 28, 2023 at 04:13:28PM +, Qing Zhao wrote: > > On Feb 28, 2023, at 3:26 AM, Jakub Jelinek via Gcc-patches > > wrote: > > I think -fstrict-flex-arrays* options can be considered as language > > mode changing options, by default flexible member-like arrays are > > handled like

Re: [RFC PATCH v1 08/10] ifcvt: add if-conversion to conditional-zero instructions

On Mon, 13 Feb 2023, Jeff Law via Gcc-patches wrote: > 3. The canaonical conditional-zero-or-value assumes the target can do a > generic SEQ/SNE of two register values. As you know, on RISC-V we have > SEQZ/SNEZ. So we've added another fallback path to handle that case in > noce_emit_condzero.

[Patch] OpenMP/Fortran: Fix handling of optional is_device_ptr + bind(C) [PR108546]

(That's a[11/12/13 Regression] P2 regression) The problem is that an is-present check on the receiver side (inside the target region) does not make much sense; the != NULL check needs to be done before the GOMP_target_ext but it *is* already there. (Having the check inside the target region

Re: [PATCH] ubsan: Honor -fstrict-flex-arrays= in -fsanitize=bounds [PR108894]

Hi, Jakub, Thanks a lot for fixing this issue. I have several questions in below: > On Feb 28, 2023, at 3:26 AM, Jakub Jelinek via Gcc-patches > wrote: > I think -fstrict-flex-arrays* options can be considered as language > mode changing options, by default flexible member-like arrays are >

Re: [PATCH] c++: Don't recurse on DECL_INITIAL for DECL_EXPR on non-VAR_DECLs [PR108606]

On 2/22/23 04:06, Jakub Jelinek wrote: Hi! The r13-2965-g73d9b0e5947e16 change changed the line touched in this patch from return RECUR (tmp, want_rval); to return RECUR (DECL_INITIAL (tmp), want_rval); This is on DECL_EXPR handling code, where tmp can be lots of different trees

Re: [PATCH] [vxworks] make wint_t and wchar_t the same distinct type

On 2/22/23 10:23, Alexandre Oliva wrote: Hello, Jason, On Feb 17, 2023, Jason Merrill wrote: On 2/17/23 23:04, Alexandre Oliva wrote: We used to define WINT_TYPE to WCHAR_TYPE, so that both wint_t and wchar_t mapped to the same underlying type, but this caused a glitch in

Re: [PATCH] Accept pmf-vbit-in-delta extra warning

On 2/22/23 11:03, Alexandre Oliva wrote: On Feb 17, 2023, Jason Merrill wrote: On 2/17/23 23:02, Alexandre Oliva wrote: cp_build_binary_op, that issues -Waddress warnings, issues an extra warning on arm targets, that g++.dg/warn/Waddress-5.C does not expect when comparing a

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

Hi Richard Sandiford, Just tried the overloaded constant divisors with below print div, it works as you mentioned, ! printf ("can_div_away_from_zero_p (mode_precision[E_%smode], " "BITS_PER_UNIT, _size[E_%smode]);\n", m->name, m->name); template inline typename if_nonpoly::type

[PATCH 1/2] gcc: xtensa: add data alignment properties to dynconfig

gcc/ * config/xtensa/xtensa-dynconfig.cc (xtensa_get_config_v4): New function. include/ * xtensa-dynconfig.h (xtensa_config_v4): New struct. (XCHAL_DATA_WIDTH, XCHAL_UNALIGNED_LOAD_EXCEPTION) (XCHAL_UNALIGNED_STORE_EXCEPTION, XCHAL_UNALIGNED_LOAD_HW)

[PATCH 2/2] gcc: xtensa: adjust STRICT_ALIGNMENT per hardware capabilities

gcc/ * config/xtensa/xtensa.h (STRICT_ALIGNMENT): Make it 0 when the hardware supports both unaligned loads and stores. --- gcc/config/xtensa/xtensa.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gcc/config/xtensa/xtensa.h b/gcc/config/xtensa/xtensa.h

[PATCH 4/5] Sanitize irange::num_pairs

irange::num_pairs has odd behavior for VR_ANTI_RANGE where it claims there are two pairs when there's actually only one. The following is now able to get rid of this, also fixing irange::legacy_upper_bound which special-cased ~[-INF, up] to return +INF instead of properly doing that when up is

[PATCH 3/5] Avoid upper/lower_bound (1) on VR_ANTI_RANGE

simplify_using_ranges::two_valued_val_range_p has odd code to verify that an anti-range is two-valued which relies on num_pairs () returning two for anti-ranges despite there's only one pair and relying on lower/upper_bound treating that argument specially. I cannot convince myself that's even

[PATCH 5/5] Sanitize legacy_{lower,upper}_bound

* value-range.h (irange::legacy_lower_bound): Remove pair argument. (irange::legacy_upper_bound): Likewise. (irange::lower_bound): Commonize asserts, adjust. (irange::upper_bound): Likewise. * value-range.cc (irange::legacy_lower_bound): Remove

[PATCH 2/5] fend off anti-ranges from value-range-storage

The following avoids the need to special-case storage requirement and copying for irange_storage_slot by making sure we canonicalize such ranges to int_range<2>. * tree-ssanames.cc (range_info_set_range): If receiving an anti-range recurse with a temporary int_range<2>. *

[PATCH 1/5] fix anti-range dumping

when vrange_printer::visit gets a VR_ANTI_RANGE it should print it as such, not just print the first element as range. When irange::num_pairs and upper/lower_bound are fixed that would no longer print a canonicalized anti-range. * value-range-pretty-print.cc (vrange_printer::visit):

[PATCH 0/5] Fix irange::legacy_upper_bound

This series fixes irange::legacy_upper_bound behavior for VR_ANTI_RANGE (actually [4/5] does). It turns out the interesting behavior is relied on in multiple spots (maybe not so many but fixing things lead to fixing more things when trying to understand what happens). So apart from fixing this

Re: [PATCH] lto: Fix up lto_fixup_prevailing_type [PR108910]

On Tue, 28 Feb 2023, Jakub Jelinek wrote: > On Tue, Feb 28, 2023 at 12:05:20PM +, Richard Biener via Gcc-patches > wrote: > > > + p = _POINTER_TO (TREE_TYPE (t)); > > > + else if (TREE_CODE (t) == REFERENCE_TYPE && !TYPE_REF_IS_RVALUE > > > (t)) > > > + p = _REFERENCE_TO (TREE_TYPE

[Patch] OpenMP: Ignore side-effects when finding struct comps [PR108545]

(This is marked as P1 regression) Since the structure handling updates, a hash is now used to find expressions which are identical; unfortunately, this mishandles 'volatile' vars as expressions involving them are not regarded as identical. This leads to spurious *multiple* 'map(struct:x' that

Re: RISC-V: Add divmod instruction support

On Mon, 20 Feb 2023, Alexander Monakov wrote: > > > That's the kind of stuff I'd expect to happen at the tree level though, > > > before expand. > > > > The GIMPLE pass forming divmod could indeed choose to emit the > > div + mul/sub sequence instead if an actual divmod pattern isn't available.

Re: [PATCH] lto: Fix up lto_fixup_prevailing_type [PR108910]

On Tue, Feb 28, 2023 at 12:05:20PM +, Richard Biener via Gcc-patches wrote: > > + p = _POINTER_TO (TREE_TYPE (t)); > > + else if (TREE_CODE (t) == REFERENCE_TYPE && !TYPE_REF_IS_RVALUE (t)) > > + p = _REFERENCE_TO (TREE_TYPE (t)); > > + if (p) > > + { > > + tree t2; > > +

Re: [PATCH] lto: Fix up lto_fixup_prevailing_type [PR108910]

On Tue, 28 Feb 2023, Jakub Jelinek wrote: > On Tue, Feb 28, 2023 at 09:43:37AM +, Richard Biener wrote: > > We try to make sure to put all built types into the type merging > > machinery, so I think it shouldn't happen - but then I cannot rule > > it out. I'm also not sure whether duplicates

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

Tamar Christina writes: >> -Original Message- >> From: Richard Sandiford >> Sent: Tuesday, February 28, 2023 11:09 AM >> 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

Re: [PATCH] lto: Fix up lto_fixup_prevailing_type [PR108910]

On Tue, Feb 28, 2023 at 09:43:37AM +, Richard Biener wrote: > We try to make sure to put all built types into the type merging > machinery, so I think it shouldn't happen - but then I cannot rule > it out. I'm also not sure whether duplicates would really pose > a problem here (other than

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

> -Original Message- > From: Richard Sandiford > Sent: Tuesday, February 28, 2023 11:09 AM > 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: >> -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

Re: [Patch] OpenMP: Handle descriptors in target's firstprivate [PR104949]

Hi! I'm currently reviewing 'gomp_copy_host2dev', 'ephemeral' in a different context, and a question came up here; commit r13-706-g49d1a2f91325fa8cc011149e27e5093a988b3a49 "OpenMP: Handle descriptors in target's firstprivate [PR104949]": On 2022-05-11T19:33:00+0200, Tobias Burnus wrote: > this

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

On 2/28/23 03:06, Hans-Peter Nilsson wrote: 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

[PATCH] MIPS: Bugfix for fix Dejagnu issues with RTL checking enabled.

From: Robert Suchanek gcc/ChangeLog: * config/mips/mips.cc (mips_set_text_contents_type): Modified parameter * config/mips/mips-protos.h (mips_set_text_contents_type): Likewise Signed-off-by: Xin Liu --- gcc/config/mips/mips-protos.h | 2 +- gcc/config/mips/mips.c| 4 ++-- 2

[PATCH] c++: Emit fundamental tinfos for all _Float*/decltype(0.0bf16) types unconditionally [PR108883]

Hi! On Tue, Feb 28, 2023 at 12:51:06AM +0100, Jakub Jelinek via Gcc-patches wrote: > And then there is a question whether we want to emit rtti for > _Float{16,32,64,128}, _Float{32,64,128}x and decltype(0.0bf16) regardless > of whether the target supports them at all or not. If the answer to

Re: Fwd: [V2][PATCH] Fixing PR107411

On Mon, 27 Feb 2023, Qing Zhao wrote: > Ping. OK. Thanks, Richard. > 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, >

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

Understood, thanks for the explanations and suggestions. Let me have a try and keep you posted. Pan From: Richard Sandiford Sent: Tuesday, February 28, 2023 17:50 To: Li, Pan2 Cc: 盼 李 ; incarnation.p.lee--- via Gcc-patches ; juzhe.zh...@rivai.ai ;

[committed] libstdc++: Do not use memmove for 1-element ranges [PR108846]

Tested powerpc64le-linux. Pushed to trunk. -- >8 -- This avoids overwriting tail padding when algorithms like std::copy are used to write a single value through a pointer to a base subobject. The pointer arithmetic on a Base* is valid for N==1, but the copy/move operation needs to be done using

[committed] libstdc++: Add likely/unlikely attributes to implementation

Tested powerpc64le-linux. Pushed to trunk. -- >8 -- For the common case of converting valid text this improves performance significantly. libstdc++-v3/ChangeLog: * src/c++11/codecvt.cc: Add [[likely]] and [[unlikely]] attributes. --- libstdc++-v3/src/c++11/codecvt.cc | 92

[committed] libstdc++: Fix uses_allocator_construction_args for pair [PR108952]

Tested powerpc64le-linux. Pushed to trunk. -- >8 -- This implements LWG 3527 which fixes the handling of pair in std::uses_allocator_construction_args. libstdc++-v3/ChangeLog: PR libstdc++/108952 * include/bits/uses_allocator_args.h (uses_allocator_construction_args):

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

"Li, Pan2" writes: > 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) >

Re: [PATCH] lto: Fix up lto_fixup_prevailing_type [PR108910]

On Tue, 28 Feb 2023, Jakub Jelinek wrote: > On Tue, Feb 28, 2023 at 08:58:20AM +, Richard Biener wrote: > > > Without LTO, TYPE_POINTER_TO/TYPE_REFERENCE_TO chains are only maintained > > > inside of build_{pointer,reference}_type_for_mode and those routines > > > ensure that the

Re: [PATCH] Fixup possible VR_ANTI_RANGE value_range issues

On Mon, 27 Feb 2023, Aldy Hernandez wrote: > > > 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

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

On Tue, 28 Feb 2023 at 06:00, Lin Sinan wrote: > > 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. Good catch. Reviewed-by:

[PATCH v2] 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] lto: Fix up lto_fixup_prevailing_type [PR108910]

On Tue, Feb 28, 2023 at 08:58:20AM +, Richard Biener wrote: > > Without LTO, TYPE_POINTER_TO/TYPE_REFERENCE_TO chains are only maintained > > inside of build_{pointer,reference}_type_for_mode and those routines > > ensure that the pointer/reference type added to the chain is really > >

Re: [PATCH] ubsan: Honor -fstrict-flex-arrays= in -fsanitize=bounds [PR108894]

On Tue, Feb 28, 2023 at 09:02:47AM +, Richard Biener wrote: > > While this isn't really a regression, the -fstrict-flex-arrays* > > option is new in GCC 13 and so I think we should make -fsanitize=bounds > > play with it well from the beginning. > > > > The current behavior is that

Re: [PATCH] ubsan: Honor -fstrict-flex-arrays= in -fsanitize=bounds [PR108894]

On Tue, 28 Feb 2023, Jakub Jelinek wrote: > Hi! > > While this isn't really a regression, the -fstrict-flex-arrays* > option is new in GCC 13 and so I think we should make -fsanitize=bounds > play with it well from the beginning. > > The current behavior is that -fsanitize=bounds considers all

Re: [PATCH] lto: Fix up lto_fixup_prevailing_type [PR108910]

On Tue, 28 Feb 2023, Jakub Jelinek wrote: > Hi! > > Without LTO, TYPE_POINTER_TO/TYPE_REFERENCE_TO chains are only maintained > inside of build_{pointer,reference}_type_for_mode and those routines > ensure that the pointer/reference type added to the chain is really > unqualified (including

[PATCH] ubsan: Honor -fstrict-flex-arrays= in -fsanitize=bounds [PR108894]

Hi! While this isn't really a regression, the -fstrict-flex-arrays* option is new in GCC 13 and so I think we should make -fsanitize=bounds play with it well from the beginning. The current behavior is that -fsanitize=bounds considers all trailing arrays as flexible member-like arrays and both