[PATCH v1] Match: Support form 1 for scalar signed integer .SAT_ADD

From: Pan Li This patch would like to support the form 1 of the scalar signed integer .SAT_ADD. Aka below example: Form 1: #define DEF_SAT_S_ADD_FMT_1(T) \ T __attribute__((noinline))\ sat_s_add_##T##_fmt_1 (T x, T y) \ {

[committed] libgomp.texi: Add OpenMP TR13 routines to @menu (commented out)

Not user visible but I use this to keep track of both implemented OpenMP runtime routines that still have to be documented and of still to be implemented (and then documented) routines. This commit (r15-2713-g1a5734135d265a) adds those routines added in OpenMP's third 6.0 preview (Technical Re

[PATCH v3] Improve bad error message with stray semicolon in initializer (and related) [PR101232]

Hi, could someone review this patch? This is built on top of the v2 from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101232 the only difference is fix for error59.C I have tested it on x86_64 Ubuntu 22 machine. Regards Franciszek --- Author: Franciszek Witt Date: Mon Aug 5 09:00:35 2024 +

[PATCH v1] RISC-V: Update .SAT_TRUNC dump check due to middle-end change

From: Pan Li Due to recent middle-end change, update the .SAT_TRUNC expand dump check from 2 to 4. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/unop/vec_sat_u_trunc-1.c: Adjust asm check times from 2 to 4. Signed-off-by: Pan Li --- .../gcc.target/riscv/rvv/autovec/

Don't override 'LIBS' if '--enable-languages=rust'; use 'CRAB1_LIBS' (was: [PATCH 005/125] gccrs: libgrust: Add format_parser library)

Hi! On 2024-08-01T16:56:01+0200, Arthur Cohen wrote: > Compile libformat_parser and link to it. > --- a/gcc/rust/Make-lang.in > +++ b/gcc/rust/Make-lang.in > +LIBS += -ldl -lpthread That's still not correct. I've pushed to trunk branch commit 816c4de4d062c89f5b7a68f68f29b2b033f5b136 "Don't ov

[PATCH] RISC-V: Clarify that Vector Crypto Extensions require Vector Extensions[PR116150]

PR 116150: Zvk* and Zvb* extensions requires v or zve* extension, but on gcc v is implied. gcc/ChangeLog: * common/config/riscv/riscv-common.cc: Removed the zvk extension's implicit expansion of v extension. * config/riscv/arch-canonicalize: Ditto. * config/ris

Inline 'gcc/rust/Make-lang.in:RUST_LIBDEPS' (was: [PATCH 006/125] gccrs: Add 'gcc/rust/Make-lang.in:LIBFORMAT_PARSER')

Hi! On 2024-08-01T16:56:02+0200, Arthur Cohen wrote: > --- a/gcc/rust/Make-lang.in > +++ b/gcc/rust/Make-lang.in > @@ -212,6 +212,9 @@ RUST_ALL_OBJS = $(GRS_OBJS) $(RUST_TARGET_OBJS) > rust_OBJS = $(RUST_ALL_OBJS) rust/rustspec.o > > LIBPROC_MACRO_INTERNAL = > ../libgrust/libproc_macro_inter

Re: [PATCH] fortran: Fix a pasto in gfc_check_dependency

On Fri, Aug 02, 2024 at 06:29:27PM +0200, Mikael Morin wrote: > I agree with all of that. Sure keeping the condition around would be the > safest. I'm just afraid of keeping code that would remain dead. > > > > > And the pasto fix would guess fix > > > > aliasing_dummy_5.f90 with > > > > a

Re: [PATCH] Make may_trap_p_1 return false for constant pool references [PR116145]

Jeff Law writes: > On 8/2/24 2:23 PM, Andrew Pinski wrote: >> On Wed, Jul 31, 2024 at 9:41 AM Richard Sandiford >> wrote: >>> >>> The testcase contains the constant: >>> >>>arr2 = svreinterpret_u8(svdup_u32(0x0a0d5c3f)); >>> >>> which was initially hoisted by hand, but which gimple optimisers

Re: [Patch, Fortran] PR104626 ICE in gfc_format_decoder, at fortran/error.cc:1071

Hi Jerry, looks ok to me. Thanks for taking care. - Andre On Fri, 2 Aug 2024 10:44:58 -0700 Jerry D wrote: > Hi all, > > Doing some catchup here. I plan to commit the following shortly. This is > one of Steve's patches posted on bugzilla. > > I have created a new test case. > > Regression test

Re: [PATCH 05/15] arm: [MVE intrinsics] add vcvt shape

On 11/07/2024 22:42, Christophe Lyon wrote: + bool + check (function_checker &c) const override + { +if (c.mode_suffix_id == MODE_none) + return true; + +unsigned int bits = c.type_suffix (0).element_bits; +return c.require_immediate_range (1, 1, bits); + } When trying t

Re: [RFC v3 3/3] c: Add __lengthof__() operator

[CC += Kees, Qing] Hi Joseph, On Sun, Aug 04, 2024 at 08:34:24PM GMT, Alejandro Colomar wrote: > On Sun, Aug 04, 2024 at 08:02:25PM GMT, Martin Uecker wrote: > D'oh! I screwed it. I wanted to have written this: > > $ cat star.c > void foo(char (*a)[3][*], int (*x)[__lengthof__(*a)

Re: [RFC v3 3/3] c: Add __lengthof__() operator

On Mon, Aug 05, 2024 at 11:45:56AM +0200, Alejandro Colomar wrote: > [CC += Kees, Qing] > > Hi Joseph, > > On Sun, Aug 04, 2024 at 08:34:24PM GMT, Alejandro Colomar wrote: > > On Sun, Aug 04, 2024 at 08:02:25PM GMT, Martin Uecker wrote: > > D'oh! I screwed it. I wanted to have written this: > >

Re: [RFC][PATCH] SVE intrinsics: Fold svdiv (svptrue, x, x) to ones

Jennifer Schmitz writes: > This patch folds the SVE intrinsic svdiv into a vector of 1's in case > 1) the predicate is svptrue and > 2) dividend and divisor are equal. > This is implemented in the gimple_folder for signed and unsigned > integers. Corresponding test cases were added to the existing

Re: [PATCH v1] RISC-V: Update .SAT_TRUNC dump check due to middle-end change

lgtm juzhe.zh...@rivai.ai From: pan2.li Date: 2024-08-05 16:01 To: gcc-patches CC: juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; Pan Li Subject: [PATCH v1] RISC-V: Update .SAT_TRUNC dump check due to middle-end change From: Pan Li Due to recent middle-end change, update the .SAT_TRUNC e

[x86_64 PATCH] Refactor V2DI arithmetic right shift expansion for STV.

This patch refactors ashrv2di RTL expansion into a function so that it may be reused by a pre-reload splitter, such that DImode right shifts may be considered candidates during the Scalar-To-Vector (STV) pass. Currently DImode arithmetic right shifts are not considered potential candidates during

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

On Thu, Jul 25, 2024 at 4:47 PM FX Coudert wrote: > Can you post an updated version of the patch, following the first round of > review? > > FX Sorry for a delay, done. I dropped a change to the test file, since you have fixed it appropriately, and switched to Apple libm convention for flags,

[PATCH v2] Hard register constraints

This is a follow-up of https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654013.html What has changed? - Rebased and fixed an issue in constrain_operands which manifested after late-combine. - Introduced new test cases for Arm, Intel, POWER, RISCV, S/390 for 32- and 64-bit where appropriate (i

Re: [RFC v3 3/3] c: Add __lengthof__() operator

Am Montag, dem 05.08.2024 um 11:50 +0200 schrieb Jakub Jelinek: > On Mon, Aug 05, 2024 at 11:45:56AM +0200, Alejandro Colomar wrote: > > [CC += Kees, Qing] > > > > Hi Joseph, > > > > On Sun, Aug 04, 2024 at 08:34:24PM GMT, Alejandro Colomar wrote: > > > On Sun, Aug 04, 2024 at 08:02:25PM GMT, Mar

[PATCH] vect: Allow unsigned-to-signed promotion in vect_look_through_possible_promotion [PR115707]

The function vect_look_through_possible_promotion() fails to figure out root definition if casts involves more than two promotions with sign change as: long a = (long)b; // promotion cast -> int b = (int)c; // promotion cast, sign change -> unsigned short c = ...; For this case, the

[PATCH] vect: Add missed opcodes in vect_get_smallest_scalar_type [PR115228]

Some opcodes are missed when determining the smallest scalar type for a vectorizable statement. Currently, this bug does not cause any problem, because vect_get_smallest_scalar_type is only used to compute max nunits vectype, and even statement with missed opcode is incorrectly bypassed, the max nu

Re: [PATCH] vect: Allow unsigned-to-signed promotion in vect_look_through_possible_promotion [PR115707]

On Mon, Aug 5, 2024 at 12:34 PM Feng Xue OS wrote: > > The function vect_look_through_possible_promotion() fails to figure out root > definition if casts involves more than two promotions with sign change as: > > long a = (long)b; // promotion cast > -> int b = (int)c; // promotion cast

Re: [PATCH] vect: Add missed opcodes in vect_get_smallest_scalar_type [PR115228]

On Mon, Aug 5, 2024 at 12:36 PM Feng Xue OS wrote: > > Some opcodes are missed when determining the smallest scalar type for a > vectorizable statement. Currently, this bug does not cause any problem, > because vect_get_smallest_scalar_type is only used to compute max nunits > vectype, and even st

Re: [PATCH] vect: Multistep float->int conversion only with no trapping math

On Fri, Aug 2, 2024 at 2:43 PM Juergen Christ wrote: > > Do not convert floats to ints in multiple step if trapping math is > enabled. This might hide some inexact signals. > > Also use correct sign (the sign of the target integer type) for the > intermediate steps. This only affects undefined b

Re: [PATCH v1] Match: Add type_has_mode_precision_p check for SAT_TRUNC [PR116202]

On Sun, Aug 4, 2024 at 1:47 PM wrote: > > From: Pan Li > > The .SAT_TRUNC matching can only perform the type has its mode > precision. > > g_12 = (long unsigned int) _2; > _13 = MIN_EXPR ; > _3 = (_Bool) _13; > > The above pattern cannot be recog as .SAT_TRUNC (g_12) because the dest > only has 1

Re: [PATCH] tree-reassoc.cc: PR tree-optimization/116139 Don't assert when forming fully-pipelined FMAs on wide MULT targets

On Mon, Aug 5, 2024 at 8:49 AM Kyrylo Tkachov wrote: > > Hi all, > > The code in get_reassociation_width that forms FMAs aggressively when > they are fully pipelined expects the FMUL reassociation width in the > target to be less than for FMAs. This doesn't hold for all target > tunings. > > This

Re: [PATCH v1] Match: Support form 1 for scalar signed integer .SAT_ADD

On Mon, Aug 5, 2024 at 9:14 AM wrote: > > From: Pan Li > > This patch would like to support the form 1 of the scalar signed > integer .SAT_ADD. Aka below example: > > Form 1: > #define DEF_SAT_S_ADD_FMT_1(T) \ > T __attribute__((noinline))\ > sat_s_add_##T##_fmt

Re: [PATCH v2] RISC-V: xtheadmemidx: Fix mode test for pre/post-modify addressing

On Thu, Jul 25, 2024 at 5:40 PM Palmer Dabbelt wrote: > > On Thu, 25 Jul 2024 08:37:05 PDT (-0700), christoph.muell...@vrull.eu wrote: > > On Thu, Jul 25, 2024 at 5:19 PM Palmer Dabbelt wrote: > >> > >> On Thu, 25 Jul 2024 08:10:25 PDT (-0700), jeffreya...@gmail.com wrote: > >> > > >> > > >> > On

Re: [PATCHv2 2/2] libiberty/buildargv: handle input consisting of only white space

Jeff Law writes: > On 7/29/24 6:51 AM, Andrew Burgess wrote: >> Thomas Schwinge writes: >> >>> Hi! >>> >>> On 2024-02-10T17:26:01+, Andrew Burgess wrote: --- a/libiberty/argv.c +++ b/libiberty/argv.c >>> @@ -439,17 +442,8 @@ expandargv (int *argcp, char ***argvp) } >

Re: [RFC v3 3/3] c: Add __lengthof__() operator

Hi Martin, On Sun, Aug 04, 2024 at 11:39:26AM GMT, Martin Uecker wrote: > > BTW, I still don't understand what `if (! TYPE_DOMAIN (type))` means, > > within array_type_nelts_minus_one(). What code triggers that condition? > > Am I missing error handling for that? Thanks! > > For incomplete arra

Re: [RFC v3 3/3] c: Add __lengthof__() operator

On Mon, Aug 05, 2024 at 01:55:50PM GMT, Alejandro Colomar wrote: > Hi Martin, > > On Sun, Aug 04, 2024 at 11:39:26AM GMT, Martin Uecker wrote: > > > BTW, I still don't understand what `if (! TYPE_DOMAIN (type))` means, > > > within array_type_nelts_minus_one(). What code triggers that condition?

Re: [RFC v3 3/3] c: Add __lengthof__() operator

On Mon, Aug 05, 2024 at 01:57:35PM GMT, Alejandro Colomar wrote: > On Mon, Aug 05, 2024 at 01:55:50PM GMT, Alejandro Colomar wrote: > > Hi Martin, > > > > On Sun, Aug 04, 2024 at 11:39:26AM GMT, Martin Uecker wrote: > > > > BTW, I still don't understand what `if (! TYPE_DOMAIN (type))` means, > >

Re: [RFC v3 3/3] c: Add __lengthof__() operator

On Mon, Aug 05, 2024 at 01:58:18PM GMT, Alejandro Colomar wrote: > On Mon, Aug 05, 2024 at 01:57:35PM GMT, Alejandro Colomar wrote: > > On Mon, Aug 05, 2024 at 01:55:50PM GMT, Alejandro Colomar wrote: > > > Hi Martin, > > > > > > On Sun, Aug 04, 2024 at 11:39:26AM GMT, Martin Uecker wrote: > > > >

Re: [PATCH] fortran: Fix a pasto in gfc_check_dependency

Le 05/08/2024 à 10:59, Jakub Jelinek a écrit : On Fri, Aug 02, 2024 at 06:29:27PM +0200, Mikael Morin wrote: I agree with all of that. Sure keeping the condition around would be the safest. I'm just afraid of keeping code that would remain dead. And the pasto fix would guess fix aliasing_dum

Re: [PATCH v2] Hard register constraints

Am 05.08.24 um 12:28 schrieb Stefan Schulze Frielinghaus: This is a follow-up of https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654013.html What has changed? - Rebased and fixed an issue in constrain_operands which manifested after late-combine. - Introduced new test cases for Arm, Intel,

[MAINTAINERS] Add my email address to write after approval and DCO.

Add my email address to write after approval and DCO. Pushed to trunk: 219b09215f530e4a4a3763746986b7068e00f000 Signed-off-by: Jennifer Schmitz mailto:jschm...@nvidia.com>> ChangeLog: * MAINTAINERS: Add myself. 0001-MAINTAINERS-Add-my-email-address-to-write-after-appr.patch Description:

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

The test has been observed to pass on most architectures including RISC-V: https://godbolt.org/z/8nYEvW6n1 Origin issue see: https://gcc.gnu.org/PR79356#c11 Update RISC-V target to to pass list. gcc/testsuite/ChangeLog: * gcc.dg/attr-alloc_size-11.c: Add RISC-V to the list of ta

[COMMITED] gimple ssa: Fix a typo in gimple-ssa-sccopy.cc

Hello, just commited this as obvious. Filip Kastl -- 8< -- Fixes a misplaced comment in gimple-ssa-sccopy.cc. The comment belongs to a bitmap definition but was instead placed before the beginning of a namespace block. gcc/ChangeLog: * gimple-ssa-sccopy.cc: Move a misplaced comment.

Re: [PATCH] AArch64: Set instruction attribute of TST to logics_imm

Pushed to trunk: 7268d7249b3ca31bf322de99b1d59baf06f83eb3 > On 30 Jul 2024, at 13:39, Richard Sandiford wrote: > > External email: Use caution opening links or attachments > > > Jennifer Schmitz mailto:jschm...@nvidia.com>> writes: >> As suggested in >> https://gcc.gnu.org/pipermail/gcc-patche

RE: [PATCH v1] Match: Add type_has_mode_precision_p check for SAT_TRUNC [PR116202]

> Isn't that now handled by the direct_internal_fn_supported_p check? That is, > by the caller which needs to verify the matched operation is supported by > the target? type_strictly_matches_mode_p doesn't help here (include the un-committed one). It will hit below case and return true directly a

[PATCH] c++/modules: Fix merging of GM entities in partitions [PR114950]

Bootstrapped and regtested (so far just modules.exp) on x86_64-pc-linux-gnu, OK for trunk if full regtest passes? -- >8 -- Currently name lookup generally seems to assume that all entities declared within a named module (partition) are attached to said module, which is not true for GM entities (e

Re: [x86_64 PATCH] Refactor V2DI arithmetic right shift expansion for STV.

On Mon, Aug 5, 2024 at 12:22 PM Roger Sayle wrote: > > > This patch refactors ashrv2di RTL expansion into a function so that it may > be reused by a pre-reload splitter, such that DImode right shifts may be > considered candidates during the Scalar-To-Vector (STV) pass. Currently > DImode arithme

[PATCH] Explicitly document that the "counted_by" attribute is only supported in C

As discussed in PR116016:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016#c48 We should explicitly document this limitation and issue error messages for C++. The "counted_by" attribute currently is only supported in C, mention this explicitly in documentation and also issue error when see "cou

Re: [RFC v3 3/3] c: Add __lengthof__() operator

Am Montag, dem 05.08.2024 um 13:59 +0200 schrieb Alejandro Colomar: > On Mon, Aug 05, 2024 at 01:58:18PM GMT, Alejandro Colomar wrote: > > On Mon, Aug 05, 2024 at 01:57:35PM GMT, Alejandro Colomar wrote: > > > On Mon, Aug 05, 2024 at 01:55:50PM GMT, Alejandro Colomar wrote: > > > > Hi Martin, > > >

Re: [PATCH v1] Match: Add type_has_mode_precision_p check for SAT_TRUNC [PR116202]

On Mon, Aug 5, 2024 at 3:04 PM Li, Pan2 wrote: > > > Isn't that now handled by the direct_internal_fn_supported_p check? That > > is, > > by the caller which needs to verify the matched operation is supported by > > the target? > > type_strictly_matches_mode_p doesn't help here (include the un-c

[patch,avr,v2] PR115830: Make better use of SREG

This is a second take on improving SREG (condition code) usage for avr. The difference to the 1st patch is that I added a paragraph to avr.md that explains why we don't use cmpelim: - The achievable compare mode may depend on the availability of a scratch register. SELECT_CC_MODE doesn't prov

RE: [PATCH v1] Match: Support form 1 for scalar signed integer .SAT_ADD

Thanks Richard for comments. > The convert looks odd to me given @0 is involved in both & operands. The convert is introduced as the GIMPLE IL is somehow different for int8_t when compares to int32_t or int64_t. There are some additional ops convert to unsigned for plus, see below line 8-9 and

Re: [PATCH] Explicitly document that the "counted_by" attribute is only supported in C

On Mon, Aug 05, 2024 at 01:33:01PM +, Qing Zhao wrote: > As discussed in > PR116016:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016#c48 > > We should explicitly document this limitation and issue error messages for > C++. > > The "counted_by" attribute currently is only supported in C,

Re: [PATCH v1] RISC-V: Update .SAT_TRUNC dump check due to middle-end change

On 8/5/24 2:01 AM, pan2...@intel.com wrote: From: Pan Li Due to recent middle-end change, update the .SAT_TRUNC expand dump check from 2 to 4. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/unop/vec_sat_u_trunc-1.c: Adjust asm check times from 2 to 4. OK jeff

Re: [PATCH v2] Hard register constraints

On Mon, Aug 05, 2024 at 02:19:50PM +0200, Georg-Johann Lay wrote: > Am 05.08.24 um 12:28 schrieb Stefan Schulze Frielinghaus: > > This is a follow-up of > > https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654013.html > > > > What has changed? > > > > - Rebased and fixed an issue in constrain_

Re: [PATCH] vect: Multistep float->int conversion only with no trapping math

Am Mon, Aug 05, 2024 at 01:00:31PM +0200 schrieb Richard Biener: > On Fri, Aug 2, 2024 at 2:43 PM Juergen Christ wrote: > > > > Do not convert floats to ints in multiple step if trapping math is > > enabled. This might hide some inexact signals. > > > > Also use correct sign (the sign of the targ

Re: [PATCH] RISC-V: Minimal support for Zimop extension.

On 8/4/24 8:20 PM, Jiawei wrote: 在 2024/8/5 8:45, Jeff Law 写道: On 8/2/24 9:32 AM, Jiawei wrote: https://github.com/riscv/riscv-isa-manual/blob/main/src/zimop.adoc gcc/ChangeLog: * common/config/riscv/riscv-common.cc: New extension. * config/riscv/riscv.opt: New mask. gcc/testsu

Re: [PATCH] middle-end/111821 - compile-time/memory-hog with large copy

On 8/2/24 6:50 AM, Richard Biener wrote: The following fixes a compile-time/memory-hog when performing a large aggregate copy to a small object allocated to a register. While store_bit_field_1 called by store_integral_bit_field will do nothign for accesses outside of the target the loop over t

Re: [PATCH v2] RISC-V: Add support to vector stack-clash protection

On 8/1/24 2:16 PM, Raphael Zinsly wrote: On Thu, Aug 1, 2024 at 3:40 PM Jeff Law wrote: On 8/1/24 6:01 AM, Raphael Moreira Zinsly wrote: +/* Both prologue temp registers are used in the vector probe loop for when + stack-clash protection is enabled, so we need to copy SP to a new register

Re: [PATCH v2] RISC-V: Add deprecation warning to LP64E abi

On 7/30/24 6:32 PM, Patrick O'Neill wrote: gcc/ChangeLog: PR 116152 * config/riscv/riscv.cc (riscv_option_override): Add deprecation warning. gcc/testsuite/ChangeLog: * gcc.target/riscv/predef-9.c: Add check for warning. OK jeff

RE: Support streaming of poly_int for offloading when it's degree <= accel's NUM_POLY_INT_COEFFS

> -Original Message- > From: Jakub Jelinek > Sent: Friday, August 2, 2024 5:43 PM > To: Prathamesh Kulkarni > Cc: Richard Biener ; Richard Sandiford > ; gcc-patches@gcc.gnu.org > Subject: Re: Support streaming of poly_int for offloading when it's > degree <= accel's NUM_POLY_INT_COEFFS

Re: [PATCH] PR tree-optimization/57371: Optimize (float)i == 16777222.0f sometimes.

On 7/28/24 6:01 AM, Roger Sayle wrote: This patch improves the tree-level optimization of (fptype)ivar != CST in match.pd (historically tracked under PR 57371). Joseph Myers' description in comment #1 provides an excellent overview of the issues, that historically it's the trapping behaviour

Re: Support streaming of poly_int for offloading when it's degree <= accel's NUM_POLY_INT_COEFFS

On Mon, Aug 05, 2024 at 02:24:00PM +, Prathamesh Kulkarni wrote: > gcc/ChangeLog: > PR ipa/96265 > PR ipa/111937 > * data-streamer-in.cc (streamer_read_poly_uint64): Remove code for > streaming, and call poly_int_read_common instead. > (streamer_read_poly_int64):

Re: [RFC][PATCH] SVE intrinsics: Fold svdiv (svptrue, x, x) to ones

> On 5 Aug 2024, at 12:01, Richard Sandiford wrote: > > External email: Use caution opening links or attachments > > > Jennifer Schmitz writes: >> This patch folds the SVE intrinsic svdiv into a vector of 1's in case >> 1) the predicate is svptrue and >> 2) dividend and divisor are equal. >>

Re: [PATCH-1v4] Value Range: Add range op for builtin isinf

On 7/23/24 4:39 PM, Andrew MacLeod wrote: the range is in r, and is set to [0,0].  this is the false part of what is being returned for the range. the "return true" indicates we determined a range, so use what is in R. returning false means we did not find a range to return, so r is garbage

Re: Ping^4 [PATCH-2v4] Value Range: Add range op for builtin isfinite

On 7/21/24 8:10 PM, HAO CHEN GUI wrote: Hi, Gently ping it. https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653094.html OK. Sorry for the delays. jeff

Re: Ping^4 [PATCH-3v2] Value Range: Add range op for builtin isnormal

On 7/21/24 8:09 PM, HAO CHEN GUI wrote: Hi, Gently ping it. https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653095.html Also OK. jeff

Re: [PATCHv2, expand] Add const0 move checking for CLEAR_BY_PIECES optabs

On 7/26/24 2:55 AM, HAO CHEN GUI wrote: Hi Jeff, 在 2024/7/24 5:57, Jeff Law 写道: On 7/21/24 7:58 PM, HAO CHEN GUI wrote: Hi,    This patch adds const0 move checking for CLEAR_BY_PIECES. The original vec_duplicate handles duplicates of non-constant inputs. But 0 is a constant. So even a pl

Re: [PATCH] Fix Wstringop-overflow-47.c warning in RISC-V target.

On 7/15/24 10:08 PM, Jiawei wrote: 在 2024/07/16 8:28, Jeff Law 写道: IIRC these fails are dependent upon whether or not the statements turn into vector stores or not. So to remove the xfail don't you have to know if vector is enabled/ disabled? I am not sure, I tried to enable with RVV,

Re: [PATCH] testsuite: Add RISC-V to targets not xfailing gcc.dg/attr-alloc_size-11.c:50, 51.

On 8/5/24 6:26 AM, Jiawei wrote: The test has been observed to pass on most architectures including RISC-V: https://godbolt.org/z/8nYEvW6n1 Origin issue see: https://gcc.gnu.org/PR79356#c11 Update RISC-V target to to pass list. gcc/testsuite/ChangeLog: * gcc.dg/attr-alloc_size-11.c

Re: [PATCH] RISC-V: Minimal support for Zimop extension.

在 2024/8/5 22:15, Jeff Law 写道: On 8/4/24 8:20 PM, Jiawei wrote: 在 2024/8/5 8:45, Jeff Law 写道: On 8/2/24 9:32 AM, Jiawei wrote: https://github.com/riscv/riscv-isa-manual/blob/main/src/zimop.adoc gcc/ChangeLog: * common/config/riscv/riscv-common.cc: New extension. * config/riscv

Re: [PATCH] RISC-V: Minimal support for Zimop extension.

On 8/5/24 9:21 AM, Jiawei wrote: Thanks Jeff! I think I do not have the permissions in the binutils repo, let me contact Nelson to ask him give  some help. Sounds good. Thanks for taking care of this. I just wish I'd noticed the patch a month ago so that we could have included it in the

Re: [RFC v3 3/3] c: Add __lengthof__() operator

Hi Martin, On Mon, Aug 05, 2024 at 03:35:06PM GMT, Martin Uecker wrote: > > > > > > For incomplete arrays, basically we have the following different > > > > > > variants for arrays: > > > > > > > > > > > > T[ ] incomplete: !TYPE_DOMAIN > > > > > > T[1] constant size: TYPE_MAX_VALUE == INTEGER_CS

Re: [PATCH v2] Hard register constraints

Am 05.08.24 um 15:59 schrieb Stefan Schulze Frielinghaus: On Mon, Aug 05, 2024 at 02:19:50PM +0200, Georg-Johann Lay wrote: Am 05.08.24 um 12:28 schrieb Stefan Schulze Frielinghaus: This is rather unfortunate but I couldn't find a way how to validate register names during genoutput. If no one

Re: [PATCH v2] c++, coroutines: Simplify separation of the user function body and ramp.

On 8/3/24 11:40 AM, Iain Sandoe wrote: On 2 Aug 2024, at 15:19, Jason Merrill wrote: On 8/2/24 6:50 AM, Iain Sandoe wrote: This version simplifies the process by extrating the second case directly typo thanks, fixed. +static bool +use_eh_spec_block (tree fn) +{ + return (flag_excepti

Re: [PATCH] c++: permit errors inside uninstantiated templates [PR116064]

On 8/2/24 4:18 PM, Patrick Palka wrote: On Fri, 2 Aug 2024, Patrick Palka wrote: On Fri, 2 Aug 2024, Jason Merrill wrote: On 8/1/24 2:52 PM, Patrick Palka wrote: In recent versions of GCC we've been diagnosing more and more kinds of errors inside a template ahead of time. This is a largely

Re: [PATCH v2] c++: fix -Wdangling-reference false positive [PR115987]

On 8/2/24 3:22 PM, Marek Polacek wrote: On Thu, Aug 01, 2024 at 05:20:43PM -0400, Jason Merrill wrote: On 8/1/24 4:19 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This fixes another false positive. When a function is taking a temporary of scal

Re: [PATCH] testsuite: Add RISC-V to targets not xfailing gcc.dg/attr-alloc_size-11.c:50, 51.

在 2024/8/5 23:21, Jeff Law 写道: On 8/5/24 6:26 AM, Jiawei wrote: The test has been observed to pass on most architectures including RISC-V: https://godbolt.org/z/8nYEvW6n1 Origin issue see: https://gcc.gnu.org/PR79356#c11 Update RISC-V target to to pass list. gcc/testsuite/ChangeLog:    

[x86_64 PATCH] Support memory destinations and wide immediate constants in STV.

Hi Uros, Very many thanks for the quick review and approval. Here's another. This patch implements two improvements/refinements to the i386 backend's Scalar-To-Vector (STV) pass. The first is to support memory destinations in binary logic operations, and the second is to provide more accurate c

Re: [PATCH] c++: remove function/var concepts code

On 8/2/24 2:12 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu. Comments? -- >8 -- This patch removes vestigial Concepts TS code as discussed in . In particular, it removes code related to function/variable

Re: [RFC][PATCH] SVE intrinsics: Fold svdiv (svptrue, x, x) to ones

Kyrylo Tkachov writes: >> On 5 Aug 2024, at 12:01, Richard Sandiford wrote: >> >> External email: Use caution opening links or attachments >> >> >> Jennifer Schmitz writes: >>> This patch folds the SVE intrinsic svdiv into a vector of 1's in case >>> 1) the predicate is svptrue and >>> 2) div

Re: [RFC v3 3/3] c: Add __lengthof__() operator

Am Montag, dem 05.08.2024 um 17:27 +0200 schrieb Alejandro Colomar: > Hi Martin, > ... > > But I think you might make it unnecessarily complicated. It > > should be sufficient to look at the outermost size. You > > can completely ignore thatever happens There > > should be three cases if I am n

[COMMITTED, BPF] bpf: do not emit BPF non-fetching atomic instructions

When GCC finds a call to one of the __atomic_OP_fetch built-ins in which the return value is not used it optimizes it into the corresponding non-fetching atomic operation. Up to now we had definitions in gcc/config/bpf/atomic.md to implement both atomic_OP and atomic_fetch_OP sets of insns: ato

Re: [RFC][PATCH] SVE intrinsics: Fold svdiv (svptrue, x, x) to ones

> On 5 Aug 2024, at 18:00, Richard Sandiford wrote: > > External email: Use caution opening links or attachments > > > Kyrylo Tkachov writes: >>> On 5 Aug 2024, at 12:01, Richard Sandiford >>> wrote: >>> >>> External email: Use caution opening links or attachments >>> >>> >>> Jennifer S

Re: [PATCH] RISC-V: Clarify that Vector Crypto Extensions require Vector Extensions[PR116150]

On 8/5/24 01:23, Liao Shihua wrote: PR 116150: Zvk* and Zvb* extensions requires v or zve* extension, but on gcc v is implied. gcc/ChangeLog: * common/config/riscv/riscv-common.cc: Removed the zvk extension's implicit expansion of v extension. * config/riscv/arch-

Re: [PATCH] Explicitly document that the "counted_by" attribute is only supported in C

> On Aug 5, 2024, at 09:53, Jakub Jelinek wrote: > > On Mon, Aug 05, 2024 at 01:33:01PM +, Qing Zhao wrote: >> As discussed in >> PR116016:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016#c48 >> >> We should explicitly document this limitation and issue error messages for >> C++. >>

Re: [PATCH] Explicitly document that the "counted_by" attribute is only supported in C

On Mon, Aug 05, 2024 at 04:46:09PM +, Qing Zhao wrote: > So, you want me to add counted_by test-suite for C23? (Which should be > supported) > Okay, but I will do it in another separate patch since this patch is for C++. > > The C++11/C23 standard attributes are more strict on where they can

Re: [PATCH] c++: permit errors inside uninstantiated templates [PR116064]

On Mon, 5 Aug 2024, Jason Merrill wrote: > On 8/2/24 4:18 PM, Patrick Palka wrote: > > On Fri, 2 Aug 2024, Patrick Palka wrote: > > > > > On Fri, 2 Aug 2024, Jason Merrill wrote: > > > > > > > On 8/1/24 2:52 PM, Patrick Palka wrote: > > > > > In recent versions of GCC we've been diagnosing more

Re: [PATCH] Explicitly document that the "counted_by" attribute is only supported in C

> On Aug 5, 2024, at 12:51, Jakub Jelinek wrote: > > On Mon, Aug 05, 2024 at 04:46:09PM +, Qing Zhao wrote: >> So, you want me to add counted_by test-suite for C23? (Which should be >> supported) >> Okay, but I will do it in another separate patch since this patch is for C++. >>> The C++11

Re: [PATCH] c++: permit errors inside uninstantiated templates [PR116064]

On 8/5/24 1:14 PM, Patrick Palka wrote: On Mon, 5 Aug 2024, Jason Merrill wrote: On 8/2/24 4:18 PM, Patrick Palka wrote: On Fri, 2 Aug 2024, Patrick Palka wrote: On Fri, 2 Aug 2024, Jason Merrill wrote: On 8/1/24 2:52 PM, Patrick Palka wrote: In recent versions of GCC we've been diagnosin

Re: [RFC v3 3/3] c: Add __lengthof__() operator

Hi Martin, On Mon, Aug 05, 2024 at 06:05:15PM GMT, Martin Uecker wrote: > > > > However, if I turn on -Wvla, both get a warning: > > > > len.c: At top level: > > len.c:288:1: warning: ISO C90 forbids variable length array ‘x’ [-Wvla] > > 288 | void foo(char (*a)[3][*], int (*x)[__l

Re: [PATCH] Explicitly document that the "counted_by" attribute is only supported in C

On 8/5/24 9:53 AM, Jakub Jelinek wrote: On Mon, Aug 05, 2024 at 01:33:01PM +, Qing Zhao wrote: As discussed in PR116016:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016#c48 We should explicitly document this limitation and issue error messages for C++. The "counted_by" attribute current

Re: [PATCH] Explicitly document that the "counted_by" attribute is only supported in C

On Mon, Aug 05, 2024 at 01:48:25PM -0400, Jason Merrill wrote: > On 8/5/24 9:53 AM, Jakub Jelinek wrote: > > On Mon, Aug 05, 2024 at 01:33:01PM +, Qing Zhao wrote: > > > As discussed in > > > PR116016:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016#c48 > > > > > > We should explicitly doc

[pushed] wwwdocs: news: Adjust link to 2015 ACM Software System Award

Pushed. Gerald --- htdocs/news.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/news.html b/htdocs/news.html index 6fac4ea5..bb04a682 100644 --- a/htdocs/news.html +++ b/htdocs/news.html @@ -196,7 +196,7 @@ [2016-06-03] wwwdocs: -http://awards.acm.org/a

[PATCH] testsuite: Fix struct size check [PR116155]

The size of "struct only_fam_2" is dependent on the alignment of the flexible array member "b", and not on the type of the preceding bit-fields. For most targets the two are equal. But on default_packed targets like pru-unknown-elf, the alignment of int is not equal to the size of int, so the tes

Re: [PATCH,c++,wwwdocs] bugs: Remove old "export" non-bug

On Mon, 22 Jul 2024, Jonathan Wakely wrote: >> We have been carrying this note on the "original" export feature for ages, >> and I believe it's not actually a FAQ, if it ever was. >> >> Jonathan moved this down when adding a note on ADL last fall. >> >> I now propose to drop it. > Sounds good to me

Re: [PATCH] Explicitly document that the "counted_by" attribute is only supported in C

On Aug 5, 2024, at 13:54, Jakub Jelinek wrote: On Mon, Aug 05, 2024 at 01:48:25PM -0400, Jason Merrill wrote: On 8/5/24 9:53 AM, Jakub Jelinek wrote: On Mon, Aug 05, 2024 at 01:33:01PM +, Qing Zhao wrote: As discussed in PR116016:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016#c48 We s

Re: [PATCH] c++: remove function/var concepts code

On Mon, Aug 05, 2024 at 12:00:04PM -0400, Jason Merrill wrote: > On 8/2/24 2:12 PM, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu. Comments? > > > > -- >8 -- > > This patch removes vestigial Concepts TS code as discussed in > >

Re: [PATCH] c++: remove function/var concepts code

On 8/5/24 2:44 PM, Marek Polacek wrote: On Mon, Aug 05, 2024 at 12:00:04PM -0400, Jason Merrill wrote: I think we also want to adjust the 'concept bool' handling in cp_parser_decl_specifier_seq: /* Warn for concept as a decl-specifier. We'll rewrite these as concept declarations l

[PATCH] doc: Rephrase GM2 Limitations section

I noticed a non-working link, then some other details in that section. Here is a suggestion to rework it a bit. Okay? Gerald >From 83e856355a94bd78afbf19eed32ca1726658f581 Mon Sep 17 00:00:00 2001 From: Gerald Pfeifer Date: Mon, 5 Aug 2024 21:06:20 +0200 Subject: [PATCH] doc: Rephrase GM2 Li

[pushed] wwwdocs: news: Switch MMIX links to https

Pushed. Gerald --- htdocs/news.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/news.html b/htdocs/news.html index bb04a682..a8850dd4 100644 --- a/htdocs/news.html +++ b/htdocs/news.html @@ -1228,7 +1228,7 @@ GCC 3.0.3 has been released. November 3, 2001 Hans-Pe

[pushed] wwwdocs: gcc-3.4: Switch GNU Classpath link to https

Pushed. Gerald --- htdocs/gcc-3.4/changes.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/gcc-3.4/changes.html b/htdocs/gcc-3.4/changes.html index 76b4ce87..64042080 100644 --- a/htdocs/gcc-3.4/changes.html +++ b/htdocs/gcc-3.4/changes.html @@ -735,7 +735,7 @@ and

Re: [PATCH 1/8] fortran: Add tests covering inline MINLOC/MAXLOC without DIM [PR90608]

Hi Mikael, I had only a quick glance at this patch, but am a little concerned about the tests involving nans. E.g.: + subroutine check_all_nans() +real, allocatable :: a(:,:,:) +real :: nan +integer, allocatable :: m(:) +nan = 0 +nan = nan / nan +allocate(a(3,3,3), sou

Re: [PATCH] c++: permit errors inside uninstantiated templates [PR116064]

On Mon, 5 Aug 2024, Jason Merrill wrote: > On 8/5/24 1:14 PM, Patrick Palka wrote: > > On Mon, 5 Aug 2024, Jason Merrill wrote: > > > > > On 8/2/24 4:18 PM, Patrick Palka wrote: > > > > On Fri, 2 Aug 2024, Patrick Palka wrote: > > > > > > > > > On Fri, 2 Aug 2024, Jason Merrill wrote: > > > > >

Re: [PATCH] c++: remove function/var concepts code

On Mon, Aug 05, 2024 at 02:52:32PM -0400, Jason Merrill wrote: > On 8/5/24 2:44 PM, Marek Polacek wrote: > > On Mon, Aug 05, 2024 at 12:00:04PM -0400, Jason Merrill wrote: > > > > I think we also want to adjust the 'concept bool' handling in > > > cp_parser_decl_specifier_seq: > > > > > > >

  1   2   >