Re: [PATCH, rs6000] Add TARGET_FLOAT128_HW guard for quad-precision insns

Hi Haochen, on 2024/7/11 13:50, HAO CHEN GUI wrote: > Hi, > This patch adds TARGET_FLOAT128_HW into pattern conditions for quad- > precision insns. Also it removes FLOAT128_IEEE_P check from pattern > conditions if the mode of pattern is IEEE128 as the mode iterator - > IEEE128 already checks wi

RE: [PATCH 10/10] autovectorizer: Test autovectorization of different dot-prod modes.

Hi Victor, > -Original Message- > From: Victor Do Nascimento > Sent: Wednesday, July 10, 2024 3:06 PM > To: gcc-patches@gcc.gnu.org > Cc: Richard Sandiford ; Richard Earnshaw > ; Victor Do Nascimento > > Subject: [PATCH 10/10] autovectorizer: Test autovectorization of different > dot- >

[PATCH 1/3 v3] RISC-V: Add vector type of BFloat16 format

v3: Rebase v2: Rebase The vector type of BFloat16 format is added in this patch, subsequent extensions to zvfbfmin and zvfwma need to be based on this patch. Signed-off-by: Feng Wang gcc/ChangeLog: * config/riscv/genrvv-type-indexer.cc (bfloat16_type): Generate bf16 vector_ty

[PATCH 1/2] gcov: Cache source files

Cache the source files as they are read, rather than discarding them at the end of output_lines (), and move the reading of the source file to the new function slurp. This patch does not really change anything other than moving the file reading out of output_file, but set gcov up for more interact

[PATCH 2/3 v3] RISC-V: Add Zvfbfmin and Zvfbfwma intrinsic

v3: Modify warning message in riscv.cc v2: Rebase Accroding to the intrinsic doc, the 'Zvfbfmin' and 'Zvfbfwma' intrinsic functions are added by this patch. Signed-off-by: Feng Wang gcc/ChangeLog: * config/riscv/riscv-vector-builtins-bases.cc (class vfncvtbf16_f): Add 'Zvfbfm

[PATCH 3/3 v3] RISC-V: Add md files for vector BFloat16

V3: Add Bfloat16 vector insn in generic-vector-ooo.md v2: Rebase Accroding to the BFloat16 spec, some vector iterators and new pattern are added in md files. Signed-off-by: Feng Wang gcc/ChangeLog: * config/riscv/generic-vector-ooo.md: Add def_insn_reservation for vector BFloat16.

RE: [PATCH 02/10] autovectorizer: Add basic support for convert optabs

Hi Victor, > -Original Message- > From: Victor Do Nascimento > Sent: Wednesday, July 10, 2024 3:06 PM > To: gcc-patches@gcc.gnu.org > Cc: Richard Sandiford ; Richard Earnshaw > ; Victor Do Nascimento > > Subject: [PATCH 02/10] autovectorizer: Add basic support for convert optabs > > Giv

[pushed] Ensure function.end_line in source_info.lines

Ensure that the function.end_line in the lines vector for the source file, even if it is not explicitly touched by a basic block. This ensures consistency with what you would expect. For example, this file has sources[sum.cc].lines.size () == 23 and main.end_line == 2 without adjusting sources.line

[pushed] Add function filtering to gcov

Add the --include and --exclude flags to gcov to control what functions to report on. This is meant to make gcov more practical as an when writing test suites or performing other coverage experiments, which tends to focus on a few functions at the time. This really shines in combination with the -t

Re: [PATCH 1/1] AArch64: Add LUTI ACLE for SVE2

Hi Vladimir, > On 10 Jul 2024, at 15:34, vladimir.miloser...@arm.com wrote: > > External email: Use caution opening links or attachments > > > This patch introduces support for LUTI2/LUTI4 ACLE for SVE2. > > LUTI instructions are used for efficient table lookups with 2-bit > or 4-bit indices.

Re: [PATCH 1/1] AArch64: Add LUTI ACLE for SVE2

> On 11 Jul 2024, at 09:18, Kyrylo Tkachov wrote: > > External email: Use caution opening links or attachments > > > Hi Vladimir, > >> On 10 Jul 2024, at 15:34, vladimir.miloser...@arm.com wrote: >> >> External email: Use caution opening links or attachments >> >> >> This patch introduces

[PATCH] RISC-V: skip vector tests if target not supporting v extension

The original method tried to overwrite the march option when the target doesn't support v exctension, which caused unexpected compile and runtime test failures This patch change the way to handle targets that don't support v extension by simply skip the test cases that requires v extension The te

Re: [PATCH 03/10] aarch64: Fix aarch64 backend-use of (u|s|us)dot_prod patterns.

Hi Victor, > On 10 Jul 2024, at 16:05, Victor Do Nascimento > wrote: > > External email: Use caution opening links or attachments > > > Given recent changes to the dot_prod standard pattern name, this patch > fixes the aarch64 back-end by implementing the following changes: > > 1. Add 2nd mo

Re: [PATCH 1/3 v3] RISC-V: Add vector type of BFloat16 format

OK for this patch set, I know you already got LGTM from JuZhe or me before, so just an explicitly ack to let you know it's still OK once CI is passed. On Thu, Jul 11, 2024 at 3:11 PM Feng Wang wrote: > > v3: Rebase > v2: Rebase > The vector type of BFloat16 format is added in this patch, > subseq

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

Hi, The builtin isinf is not folded at front end if the corresponding optab exists. It causes the range evaluation failed on the targets which has optab_isinf. For instance, range-sincos.c will fail on the targets which has optab_isinf as it calls builtin_isinf. This patch fixed the problem by

Re: [PATCH] fixincludes: skip stdio_stdarg_h on darwin

> On 10 Jul 2024, at 16:45, Iain Sandoe wrote: >> On 10 Jul 2024, at 16:25, FX Coudert wrote: >> >> I found another useless fixincludes on darwin, but this one was a bit harder >> to diagnose. GCC trunk applies a fix to on modern Darwin: it is >> stdio_stdarg_h. That fix is actually part o

Re: Ping^3 [PATCH-1v3] Value Range: Add range op for builtin isinf

Hi Ruoyao, Thanks for your info. I updated my patch and sent it for review. Thanks Gui Haochen 在 2024/7/10 22:01, Xi Ruoyao 写道: > On Wed, 2024-07-10 at 21:54 +0800, Xi Ruoyao wrote: >> On Mon, 2024-07-01 at 09:11 +0800, HAO CHEN GUI wrote: >>> Hi, >>>   Gently ping it. >>> https://gcc.gnu.org/p

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

Hi Jeff, 在 2024/7/11 6:25, Jeff Law 写道: > OK.  But given this patch is several months old, can you re-bootstrap & test  > before committing to the trunk. Thanks. I will rebase the patch and test it again. Thanks Gui Haochen

Re: [Fortran, Patch, PR 96992, V4] Fix Class arrays of different ranks are rejected as storage association argument

Hi Harald, thank you very much for ok'ing this large patch. Merged as gcc-15-1965-ge4f2f46e015 Looking forward to get (no) bug reports ;-) Thanks again, Andre On Wed, 10 Jul 2024 20:52:37 +0200 Harald Anlauf wrote: > Hi Andre, > > Am 10.07.24 um 10:45 schrieb Andre Vehreschild: > > Hi Harald

[Patch, tree-optimization, predcom] Improve unroll factor for predictive commoning

Hello All: Unroll factor is determined with max distance across loop iterations. The logic for determining the loop unroll factor is based on data dependency across loop iterations. The max distance across loop iterations is the unrolling factor that helps in predictive commoning. Bootstrapped a

[PATCH v1] RISC-V: Add testcases for vector .SAT_SUB in zip benchmark

From: Pan Li This patch would like to add the test cases for the vector .SAT_SUB in the zip benchmark. Aka: Form in zip benchmark: #define DEF_VEC_SAT_U_SUB_ZIP(T1, T2) \ void __attribute__((noinline))\ vec_sat_u_sub_##T1##_#

[PATCH] tree-optimization/115868 - ICE with .MASK_CALL in simdclone

The following adjusts mask recording which didn't take into account that we can merge call arguments from two vectors like _50 = {vect_d_1.253_41, vect_d_1.254_43}; _51 = VIEW_CONVERT_EXPR(mask__19.257_49); _52 = (unsigned int) _51; _53 = _Z3bazd.simdclone.7 (_50, _52); _54 = BIT_FIELD_R

[PATCH] tree-optimization/115867 - ICE with simdcall vectorization in masked loop

When only a loop mask is to be supplied for the inbranch arg to a simd function we fail to handle integer mode masks correctly. We need to guess the number of elements represented by it. This assumes that excess arguments are all for masks, I wasn't able to create a simdclone with more than one i

Re: [PATCH 10/10] autovectorizer: Test autovectorization of different dot-prod modes.

On Thu, Jul 11, 2024 at 9:03 AM Tamar Christina wrote: > > Hi Victor, > > > -Original Message- > > From: Victor Do Nascimento > > Sent: Wednesday, July 10, 2024 3:06 PM > > To: gcc-patches@gcc.gnu.org > > Cc: Richard Sandiford ; Richard Earnshaw > > ; Victor Do Nascimento > > > > Subject

[PATCH 1/4] vect: Shorten name of macro SLP_TREE_NUMBER_OF_VEC_STMTS

This patch series are recomposed and split from https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655974.html. As I will add a new field tightly coupled with "vec_stmts_size", if following naming conversion as original, the new macro would be very long. So better to choose samely meaningful but

Re: [Patch, tree-optimization, predcom] Improve unroll factor for predictive commoning

On Thu, Jul 11, 2024 at 10:30 AM Ajit Agarwal wrote: > > Hello All: > > Unroll factor is determined with max distance across loop iterations. > The logic for determining the loop unroll factor is based on > data dependency across loop iterations. > > The max distance across loop iterations is the

[PATCH 2/4] vect: Fix inaccurate vector stmts number for slp reduction with lane-reducing

Vector stmts number of an operation is calculated based on output vectype. This is over-estimated for lane-reducing operation. Sometimes, to workaround the issue, we have to rely on additional logic to deduce an exactly accurate number by other means. Aiming at the inconvenience, in this patch, we

Re: [Fortran, Patch, PR 96992, V4] Fix Class arrays of different ranks are rejected as storage association argument

On Thu, Jul 11, 2024 at 10:04 AM Andre Vehreschild wrote: > > Hi Harald, > > thank you very much for ok'ing this large patch. Merged as > gcc-15-1965-ge4f2f46e015 > > Looking forward to get (no) bug reports ;-) This seems to break bootstrap with ../../gcc/gcc/fortran/trans-array.cc: In function

[PATCH 3/4] vect: Support multiple lane-reducing operations for loop reduction [PR114440]

For lane-reducing operation(dot-prod/widen-sum/sad) in loop reduction, current vectorizer could only handle the pattern if the reduction chain does not contain other operation, no matter the other is normal or lane-reducing. This patches removes some constraints in reduction analysis to allow mult

[PATCH 4/4] vect: Optimize order of lane-reducing statements in loop def-use cycles

When transforming multiple lane-reducing operations in a loop reduction chain, originally, corresponding vectorized statements are generated into def-use cycles starting from 0. The def-use cycle with smaller index, would contain more statements, which means more instruction dependency. For example

Re: [Fortran, Patch, PR 96992, V4] Fix Class arrays of different ranks are rejected as storage association argument

On Thu, Jul 11, 2024 at 10:54 AM Richard Biener wrote: > > On Thu, Jul 11, 2024 at 10:04 AM Andre Vehreschild wrote: > > > > Hi Harald, > > > > thank you very much for ok'ing this large patch. Merged as > > gcc-15-1965-ge4f2f46e015 > > > > Looking forward to get (no) bug reports ;-) > > This seem

Re: [Fortran, Patch, PR 96992, V4] Fix Class arrays of different ranks are rejected as storage association argument

On Thu, Jul 11, 2024 at 11:04 AM Andre Vehreschild wrote: > > Hi Richard, > > I am sorry to hear that. Shall I revert? I would suggest to instead fix by initializing the variable with NULL (and a comment). > - Andre > On Thu, 11 Jul 2024 10:57:48 +0200 > Richard Biener wrote: > > > On Thu, Jul

Re: [Fortran, Patch, PR 96992, V4] Fix Class arrays of different ranks are rejected as storage association argument

Hi Richard, I am sorry to hear that. Shall I revert? - Andre On Thu, 11 Jul 2024 10:57:48 +0200 Richard Biener wrote: > On Thu, Jul 11, 2024 at 10:54 AM Richard Biener > wrote: > > > > On Thu, Jul 11, 2024 at 10:04 AM Andre Vehreschild > > wrote: > > > > > > Hi Harald, > > > > > > thank you

[pushed] wwwdocs: gcc-3.*: Drop FTP links to kernel tarballs

Most browsers these days do not support FTP any longer, and while kernel.org offers downloads via other means, realistically, who is going to download 2.4.0 or 2.4.18 kernels anyways? --- htdocs/gcc-3.0/criteria.html | 4 +--- htdocs/gcc-3.1/criteria.html | 4 +--- htdocs/gcc-3.3/criteria.html | 4

Re: [Fortran, Patch, PR 96992, V4] Fix Class arrays of different ranks are rejected as storage association argument

Hi Richard, would that be sufficient? Bootstrap is still running for me... From c30c2cf829a094ba5e4c2c31333bed6e8c0d32af Mon Sep 17 00:00:00 2001 From: Andre Vehreschild Date: Thu, 11 Jul 2024 11:21:04 +0200 Subject: [PATCH] [Fortran] Fix bootstrap broken by gcc-15-1965-ge4f2f46e015 gcc/fortran

[pushed] wwwdocs: news: Update Google Summer of Code 2014 project link

Quite a different link - kudos to Google for the proper redirect alerting of the change _and_ providing the new URL. Pushed. Gerald --- htdocs/news.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/news.html b/htdocs/news.html index f13a8249..5e782349 100644 --- a/

Re: [PATCH 2/4] vect: Fix inaccurate vector stmts number for slp reduction with lane-reducing

On Thu, Jul 11, 2024 at 10:53 AM Feng Xue OS wrote: > > Vector stmts number of an operation is calculated based on output vectype. > This is over-estimated for lane-reducing operation. Sometimes, to workaround > the issue, we have to rely on additional logic to deduce an exactly accurate > number

RE: Lower zeroing array assignment to memset for allocatable arrays

> -Original Message- > From: Harald Anlauf > Sent: Thursday, July 11, 2024 12:53 AM > To: Prathamesh Kulkarni ; gcc- > patc...@gcc.gnu.org; fort...@gcc.gnu.org > Subject: Re: Lower zeroing array assignment to memset for allocatable > arrays > > External email: Use caution opening links

[PATCH v2 2/2] arm: [MVE intrinsics] Improve vdupq_n implementation

This patch makes the non-predicated vdupq_n MVE intrinsics use vec_duplicate rather than an unspec. This enables the compiler to generate better code sequences (for instance using vmov when possible). The patch renames the existing mve_vdup pattern into @mve_vdupq_n, and removes the now useless @

[PATCH v2 1/2] arm: [MVE intrinsics] fix vdup iterator

This patch fixes a bug where the mode iterator for mve_vdup should be MVE_VLD_ST instead of MVE_vecs: V2DI and V2DF (thus vdup.64) are not supported by MVE. 2024-07-02 Jolen Li Christophe Lyon gcc/ * config/arm/mve.md (mve_vdup): Fix mode iterator. --- gcc/config

Re: [PATCH v2 1/3] c++: Introduce USING_DECLs for non-function usings [PR114683]

On Tue, Jul 09, 2024 at 05:43:59PM -0400, Jason Merrill wrote: > On 7/9/24 9:44 AM, Nathaniel Shead wrote: > > On Mon, Jul 08, 2024 at 12:26:41PM -0400, Jason Merrill wrote: > > > For a using-decl in the same scope as the original decl, won't this > > > replace > > > it so only the using-decl is v

Re: [PATCH v1] RISC-V: Add testcases for vector .SAT_SUB in zip benchmark

LGTM juzhe.zh...@rivai.ai From: pan2.li Date: 2024-07-11 16:29 To: gcc-patches CC: juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; Pan Li Subject: [PATCH v1] RISC-V: Add testcases for vector .SAT_SUB in zip benchmark From: Pan Li This patch would like to add the test cases for the vector .

RE: [PATCH v1] RISC-V: Add testcases for vector .SAT_SUB in zip benchmark

Committed, thanks Juzhe. Pan From: juzhe.zh...@rivai.ai Sent: Thursday, July 11, 2024 6:32 PM To: Li, Pan2 ; gcc-patches Cc: kito.cheng ; jeffreyalaw ; Robin Dapp ; Li, Pan2 Subject: Re: [PATCH v1] RISC-V: Add testcases for vector .SAT_SUB in zip benchmark LGTM

[patch,avr,applied] Tidy up subtract + zero_extend insns

There are currently five insns and five splits that handle subtraction where the subtrahend is zero-extended to the mode of the minuend. This patch represents them as one insn (and one split) using mode iterators. Applied as obvious. Johann -- AVR: Tidy up subtract-and-zero_extend insns. The

[PATCH V2] rs6000: Don't pass -many to the assembler [PR112868]

Hi All, The following patch has been bootstrapped and regtested with default configuration [--enable-checking=yes] and with --enable-checking=release on powerpc64le-linux. This patch removes passing the -many assembler option for release builds. Now, GCC no longer passes -many under any conditio

Re: [PATCH V2] rs6000: Don't pass -many to the assembler [PR112868]

jeevitha writes: > Hi All, > > The following patch has been bootstrapped and regtested with default > configuration > [--enable-checking=yes] and with --enable-checking=release on > powerpc64le-linux. > > This patch removes passing the -many assembler option for release builds. Now, > GCC no lo

RE: [PATCH][ivopts]: perform affine fold on unsigned addressing modes known not to overflow. [PR114932]

On Wed, 10 Jul 2024, Tamar Christina wrote: > > -Original Message- > > From: Richard Biener > > Sent: Thursday, June 20, 2024 8:55 AM > > To: Tamar Christina > > Cc: gcc-patches@gcc.gnu.org; nd ; bin.ch...@linux.alibaba.com > > Subject: RE: [PATCH][ivopts]: perform affine fold on unsigne

[PATCH] LoongArch: Add support to annotate tablejump

This is per the request from the kernel developers. For generating the ORC unwind info, the objtool program needs to analysis the control flow of a .o file. If a jump table is used, objtool has to correlate the jump instruction with the table. On x86 (where objtool was initially developed) it's

[PATCH] LoongArch: Implement scalar isinf, isnormal, and isfinite via fclass

Doing so can avoid loading FP constants from the memory. It also partially fixes PR 66462 as fclass does not signal on sNaN. gcc/ChangeLog: * config/loongarch/loongarch.md (extendsidi2): Add ("=r", "f") alternative and use movfr2gr.s for it. The spec clearly states movfr

Re: [Fortran, Patch, PR 96992, V4] Fix Class arrays of different ranks are rejected as storage association argument

On Thu, Jul 11, 2024 at 11:24 AM Andre Vehreschild wrote: > > Hi Richard, > > would that be sufficient? Bootstrap is still running for me... Yes. Richard. > From c30c2cf829a094ba5e4c2c31333bed6e8c0d32af Mon Sep 17 00:00:00 2001 > From: Andre Vehreschild > Date: Thu, 11 Jul 2024 11:21:04 +0200

RE: [PATCH][ivopts]: use affine_tree when comparing IVs during candidate selection [PR114932]

On Wed, 10 Jul 2024, Tamar Christina wrote: > > > > I might also point back to the idea I threw in somewhere, adding > > > > OEP_VALUE (or a better name) to the set of flags accepted by > > > > operand_equal_p. You mentioned hashing IIRC but I don't see the patches > > > > touching hashing? > > >

[PATCH v2 00/11] aarch64: Extend aarch64_feature_flags to 128 bits

The end goal of the series is to change the definition of aarch64_feature_flags from a uint64_t typedef to a class with 128 bits of storage. This class is a new template bitmap type that uses operator overloading to mimic the existing integer interface as much as possible. The changes are mostly

[PATCH v2 01/11] aarch64: Remove unused global aarch64_tune_flags

gcc/ChangeLog: * config/aarch64/aarch64.cc (aarch64_tune_flags): Remove unused global variable. (aarch64_override_options_internal): Remove dead assignment. diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc index 7f0cc47d0f071de9297068baa85c6d5fc

[PATCH v2 02/11] aarch64: Move AARCH64_NUM_ISA_MODES definition

AARCH64_NUM_ISA_MODES will be used within aarch64-opts.h in a later commit. gcc/ChangeLog: * config/aarch64/aarch64.h (DEF_AARCH64_ISA_MODE): Move to... * config/aarch64/aarch64-opts.h (DEF_AARCH64_ISA_MODE): ...here. diff --git a/gcc/config/aarch64/aarch64-opts.h b/gcc/config/

[PATCH 2/2] RISC-V: Allow uninitialized preferred_else_value for RVV

From: YunQiang Su PR target/115840. In riscv_preferred_else_value, we create an uninitialized tmp var for else value, instead of the 0 (as default_preferred_else_value) or the pre-exists VAR (as aarch64 does), so that we can use agnostic policy. The problem is that `warn_uninit` will emit a war

[PATCH 1/2] Add allow_uninitialized to tree_base.u.bits for VAR_DECL

From: YunQiang Su Uninitialized internal temp variable may be useful in some case, such as for COND_LEN_MUL etc on RISC-V with V extension: If an const or pre-exists VAR is used, we have to use "undisturbed" policy; if an uninitialized VAR is used, we can use "agnostic". With "agnostic", the micr

[PATCH v2 04/11] aarch64: Introduce aarch64_isa_mode type

Currently there are many places where an aarch64_feature_flags variable is used, but only the bottom three isa mode bits are set and read. Using a separate data type for these value makes it more clear that they're not expected or required to have any of their upper feature bits set. It will also

[PATCH v2 06/11] aarch64: Decouple feature flag option storage type

The awk scripts that process the .opt files are relatively fragile and only handle a limited set of data types correctly. The unrecognised aarch64_feature_flags type is handled as a uint64_t, which happens to be correct for now. However, that assumption will change when we extend the mask to 128

[PATCH v2 07/11] aarch64: Add explicit bool cast to return value

gcc/ChangeLog: * config/aarch64/aarch64.cc (aarch64_valid_sysreg_name_p): Add bool cast. diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc index 69f481ecfc848e6c5b61516c2f7b8bff5cd4f8b8..229e438115c268f876c6d77e1fcc4faa2f7d231b 100644 --- a/gcc/config/a

[PATCH v2 03/11] aarch64: Eliminate a temporary variable.

The name would become misleading in a later commit anyway, and I think this is marginally more readable. gcc/ChangeLog: * config/aarch64/aarch64.cc (aarch64_override_options): Remove temporary variable. diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc i

[PATCH v2 08/11] aarch64: Add bool conversion to TARGET_* macros

Use a new AARCH64_HAVE_ISA macro in TARGET_* definitions, and eliminate all the AARCH64_ISA_* feature macros. gcc/ChangeLog: * config/aarch64/aarch64-c.cc (aarch64_define_unconditional_macros): Use TARGET_V8R macro. (aarch64_update_cpp_builtins): Use TARGET_* macros.

[PATCH v2 09/11] aarch64: Use constructor explicitly in get_flags_off

gcc/ChangeLog: * config/aarch64/aarch64-feature-deps.h (get_flags_off): Construct aarch64_feature_flags (0) explicitly. diff --git a/gcc/config/aarch64/aarch64-feature-deps.h b/gcc/config/aarch64/aarch64-feature-deps.h index 79126db88254b89f74a8583d50a77bc27865e265..a14ae22b729

RE: [PATCH]middle-end: Implement conditonal store vectorizer pattern [PR115531]

On Wed, 10 Jul 2024, Tamar Christina wrote: > > > > > > > > > + } > > > > > + > > > > > + if (new_code == ERROR_MARK) > > > > > + { > > > > > + /* We couldn't flip the condition, so invert the mask > > > > > instead. */ > > > > > + itype = TREE_TYPE (cmp_ls); > > > > > +

[PATCH v2 05/11] aarch64: Define aarch64_get_{asm_|}isa_flags

Building an aarch64_feature_flags value from data within a gcc_options or cl_target_option struct will get more complicated in a later commit. Use a macro to avoid doing this manually in more than one location. gcc/ChangeLog: * common/config/aarch64/aarch64-common.cc (aarch64_hand

[PATCH v2 11/11] aarch64: Extend aarch64_feature_flags to 128 bits

Replace the existing uint64_t typedef with a bbitmap<2> typedef. Most of the preparatory work was carried out in previous commits, so this patch itself is fairly small. gcc/ChangeLog: * common/config/aarch64/aarch64-common.cc (aarch64_set_asm_isa_flags): Store a second uint64_t v

[PATCH v2 10/11] Add new bbitmap class

This class provides a constant-size bitmap that can be used as almost a drop-in replacement for bitmaps stored in integer types. The implementation is entirely within the header file and uses recursive templated operations to support effective optimisation and usage in constexpr expressions. This

Re: [PATCH 2/2] RISC-V: Allow uninitialized preferred_else_value for RVV

On Thu, Jul 11, 2024 at 2:13 PM YunQiang Su wrote: > > From: YunQiang Su > > PR target/115840. > > In riscv_preferred_else_value, we create an uninitialized tmp var > for else value, instead of the 0 (as default_preferred_else_value) > or the pre-exists VAR (as aarch64 does), so that we can use a

Re: [PATCH 1/2] Add allow_uninitialized to tree_base.u.bits for VAR_DECL

On Thu, Jul 11, 2024 at 2:14 PM YunQiang Su wrote: > > From: YunQiang Su > > Uninitialized internal temp variable may be useful in some case, > such as for COND_LEN_MUL etc on RISC-V with V extension: If an > const or pre-exists VAR is used, we have to use "undisturbed" > policy; if an uninitiali

[PATCH v2] RISC-V: NO_WARNING preferred else value for RVV

From: YunQiang Su PR target/115840. In riscv_preferred_else_value, we create an uninitialized tmp var for else value, instead of the 0 (as default_preferred_else_value) or the pre-exists VAR (as aarch64 does), so that we can use agnostic policy. The problem is that `warn_uninit` will emit a war

Re: [PATCH 2/2] RISC-V: Allow uninitialized preferred_else_value for RVV

Richard Biener 于2024年7月11日周四 20:21写道： > > On Thu, Jul 11, 2024 at 2:13 PM YunQiang Su wrote: > > > > From: YunQiang Su > > > > PR target/115840. > > > > In riscv_preferred_else_value, we create an uninitialized tmp var > > for else value, instead of the 0 (as default_preferred_else_value) > > or

Re: [PATCH] fixincludes: skip stdio_stdarg_h on darwin

Hi Iain, Sorry about that, thanks for reverting. It appears to be a SDK version issue, so my analysis of the old SDK versions was incorrect. Could you try (when you get some time) the attached patch on one of the versions that was broken by my earlier patch? (darwin19 or darwin21). FX test.

Re: [PATCH 2/2] RISC-V: Allow uninitialized preferred_else_value for RVV

On Thu, Jul 11, 2024 at 2:45 PM YunQiang Su wrote: > > Richard Biener 于2024年7月11日周四 20:21写道： > > > > On Thu, Jul 11, 2024 at 2:13 PM YunQiang Su wrote: > > > > > > From: YunQiang Su > > > > > > PR target/115840. > > > > > > In riscv_preferred_else_value, we create an uninitialized tmp var > > >

[i386] adjust flag_omit_frame_pointer in a single function [PR113719] (was: Re: [PATCH] [i386] restore recompute to override opts after change [PR113719])

On Jul 4, 2024, Alexandre Oliva wrote: > On Jul 3, 2024, Rainer Orth wrote: > Hmm, I wonder if leaf frame pointer has to do with that. It did, in a way. The first two patches for PR113719 have each regressed gcc.dg/ipa/iinline-attr.c on a different target. The reason for this instabi

RE: [PATCH][ivopts]: perform affine fold on unsigned addressing modes known not to overflow. [PR114932]

-Original Message- > From: Richard Biener > Sent: Thursday, July 11, 2024 12:39 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; bin.ch...@linux.alibaba.com > Subject: RE: [PATCH][ivopts]: perform affine fold on unsigned addressing modes > known not to overflow. [PR114932] >

Re: [PATCH 3/3] RISC-V: load and store-lanes with SLP

On Wed, 10 Jul 2024, Richard Sandiford wrote: > Richard Biener writes: > > The following is a prototype for how to represent load/store-lanes > > within SLP. I've for now settled with having a single load node > > with multiple permute nodes acting as selection, one for each loaded lane > > and

Re: [PATCH] c++, coroutines, contracts: Handle coroutine and void functions [PR110871,PR110872,PR115434].

On Jul 9, 2024, Iain Sandoe wrote: >if (!gimple_seq_empty_p (n) && !gimple_seq_empty_p (e)) >{ > geh_else *stmt = gimple_build_eh_else (n, e); > gimple_seq_add_stmt (&cleanup, stmt); > } > Which essentially says “if either of the sub-expressions to this are empty, > then do n

[PATCH] [libstdc++] [testsuite] xfail 128bit from_chars on all aarch64-*-*

Having observed failures of these two tests on yet another aarch64 operating system, and having concluded that the conditions that trigger the problem ought to be present on all aarch64 targets, I'm now matching any aarch64 target_os to enable the workaround. Regstrapped on x86_64-linux-gnu, als

[PATCH] [libstdc++] [testsuite] require dfprt on some tests

On a target that doesn't enable decimal float components in libgcc (because the libc doens't define all required FE_* macros), but whose compiler supports _Decimal* types, the effective target requirement dfp passes, but several tests won't link because the runtime support they depend on is missi

[PATCH] [libstdc++] [testsuite] avoid arbitrary errno codes

Passing an arbitrary error number to strerror* functions doesn't seem to be portable; 19_diagnostics/system_error/cons-1.cc is hitting runtime errors in the block that attempts to instantiate a std:;system_error for error number 95. The range of errno macros defined on this target doesn't reach

RE: [PATCH][ivopts]: use affine_tree when comparing IVs during candidate selection [PR114932]

> -Original Message- > From: Richard Biener > Sent: Thursday, July 11, 2024 1:10 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; bin.ch...@linux.alibaba.com > Subject: RE: [PATCH][ivopts]: use affine_tree when comparing IVs during > candidate > selection [PR114932] > > On W

[PATCH] [analyzer] [testsuite] avoid unexpected null dereference warning

The analyzer testsuite, on a customer's own operating system, reports a potential NULL pointer dereference in flex-without-call-summaries.c. I'm not sure why it shows up on that system, but not on others, but the test is not meant to test for that warning, so I'm silencing it. Regstrapped on x86

Re: [Fortran, Patch, PR 96992, V4] Fix Class arrays of different ranks are rejected as storage association argument

Hi Richard, bootstrap finally passed and the fix is now merged as gcc-15-1971-gb9513c6746b Thanks for your patience. - Andre On Thu, 11 Jul 2024 14:01:02 +0200 Richard Biener wrote: > On Thu, Jul 11, 2024 at 11:24 AM Andre Vehreschild > wrote: > > > > Hi Richard, > > > > would that be suffi

Re: [PATCH 03/10] aarch64: Fix aarch64 backend-use of (u|s|us)dot_prod patterns.

Kyrylo Tkachov writes: > Hi Victor, > >> On 10 Jul 2024, at 16:05, Victor Do Nascimento >> wrote: >> >> External email: Use caution opening links or attachments >> >> >> Given recent changes to the dot_prod standard pattern name, this patch >> fixes the aarch64 back-end by implementing the fo

[Patch, Fortran, PR88624, v1] Fix Rejects allocatable coarray passed as a dummy argument

Hi all, attached patch fixes using of coarrays as dummy arguments. The coarray dummy argument was not dereferenced correctly, which is fixed now. Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline. Regards, Andre -- Andre Vehreschild * Email: vehre ad gcc dot gnu dot org Fro

Re: [PATCH v2] RISC-V: NO_WARNING preferred else value for RVV

Lgtm, thanks :) YunQiang Su 於 2024年7月11日 週四，20:45寫道： > From: YunQiang Su > > PR target/115840. > > In riscv_preferred_else_value, we create an uninitialized tmp var > for else value, instead of the 0 (as default_preferred_else_value) > or the pre-exists VAR (as aarch64 does), so that we can use

[Patch, Fortran, PR84244, v1] Fix ICE in recompute_tree_invariant_for_addr_expr, at tree.c:4535

Hi all, the attached patch fixes a segfault in the compiler, where for pointer components of a derived type the caf_token in the component was not set, when the derived was previously used outside of a coarray. Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline? Regards, And

Re: [PATCH 03/10] aarch64: Fix aarch64 backend-use of (u|s|us)dot_prod patterns.

> On 11 Jul 2024, at 15:41, Richard Sandiford wrote: > > External email: Use caution opening links or attachments > > > Kyrylo Tkachov writes: >> Hi Victor, >> >>> On 10 Jul 2024, at 16:05, Victor Do Nascimento >>> wrote: >>> >>> External email: Use caution opening links or attachments >

Re: [PATCH 01/10] optabs: Make all `*dot_prod_optab's modeled as conversions

Victor Do Nascimento writes: > Given the specification in the GCC internals manual defines the > {u|s}dot_prod standard name as taking "two signed elements of the > same mode, adding them to a third operand of wider mode", there is > currently ambiguity in the relationship between the mode of the

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

I have no issues with any of the range-op work in this patch series,  but I am unequipped to review the floating point aspects of any of the patches. We just need someone to signoff that this properly reflects those builtins. Andrew On 7/11/24 03:32, HAO CHEN GUI wrote: Hi, The builtin i

Re: [PATCH] [libstdc++] [testsuite] avoid arbitrary errno codes

On Thu, 11 Jul 2024 at 14:23, Alexandre Oliva wrote: > > > Passing an arbitrary error number to strerror* functions doesn't seem > to be portable; 19_diagnostics/system_error/cons-1.cc is hitting > runtime errors in the block that attempts to instantiate a > std:;system_error for error number 95.

[PATCH] s390: Align *cjump_64 and *icjump_64

During machine reorg we optimize backward jumps and transform insns as e.g. (jump_insn 118 117 119 (set (pc) (if_then_else (ne (reg:CCRAW 33 %cc) (const_int 8 [0x8])) (label_ref 134) (pc))) "dec_math_1.f90":204:8 discrim 1 2161 {*cjump_64} (expr

Re: [PATCH] [libstdc++] [testsuite] require dfprt on some tests

On Thu, 11 Jul 2024 at 14:22, Alexandre Oliva wrote: > > > On a target that doesn't enable decimal float components in libgcc > (because the libc doens't define all required FE_* macros), but whose > compiler supports _Decimal* types, the effective target requirement > dfp passes, but several test

Re: [PATCH] [libstdc++] [testsuite] require dfprt on some tests

On Thu, 11 Jul 2024 at 15:28, Jonathan Wakely wrote: > > On Thu, 11 Jul 2024 at 14:22, Alexandre Oliva wrote: > > > > > > On a target that doesn't enable decimal float components in libgcc > > (because the libc doens't define all required FE_* macros), but whose > > compiler supports _Decimal* ty

Re: [PATCH] [libstdc++] [testsuite] xfail 128bit from_chars on all aarch64-*-*

On Thu, 11 Jul 2024 at 14:21, Alexandre Oliva wrote: > > > Having observed failures of these two tests on yet another aarch64 > operating system, and having concluded that the conditions that > trigger the problem ought to be present on all aarch64 targets, I'm > now matching any aarch64 target_os

Re: [PATCH] [libstdc++] [testsuite] xfail 128bit from_chars on all aarch64-*-*

On Jul 11 2024, Jonathan Wakely wrote: > On Thu, 11 Jul 2024 at 14:21, Alexandre Oliva wrote: >> >> >> Having observed failures of these two tests on yet another aarch64 >> operating system, and having concluded that the conditions that >> trigger the problem ought to be present on all aarch64 ta

Re: [PATCH] gimple ssa: Teach switch conversion to optimize powers of 2 switches

> > > > +/* Check that the "exponential index transform" can be applied to this > > > > switch. > > > > + > > > > + See comment of the exp_index_transform function for details about > > > > this > > > > + transformation. > > > > + > > > > + We want: > > > > + - This form of the switch is

Re: [PATCH] s390: Align *cjump_64 and *icjump_64

On Thu, Jul 11, 2024 at 04:29:19PM +0200, Stefan Schulze Frielinghaus wrote: > During machine reorg we optimize backward jumps and transform insns as > e.g. > > (jump_insn 118 117 119 (set (pc) > (if_then_else (ne (reg:CCRAW 33 %cc) > (const_int 8 [0x8])) > (lab

Re: [PATCH] s390: Align *cjump_64 and *icjump_64

On Thu, Jul 11, 2024 at 05:09:41PM +0200, Stefan Schulze Frielinghaus wrote: > I didn't have the schedule for 11.5 RC in mind which is tomorrow and the > release a week afterwards. I hope this is still appropriate for 11.5? >From my side, if Andreas or somebody else approves it, it is tested on 1

Re: [PATCH v2 1/3] c++: Introduce USING_DECLs for non-function usings [PR114683]

On 7/11/24 6:22 AM, Nathaniel Shead wrote: On Tue, Jul 09, 2024 at 05:43:59PM -0400, Jason Merrill wrote: On 7/9/24 9:44 AM, Nathaniel Shead wrote: On Mon, Jul 08, 2024 at 12:26:41PM -0400, Jason Merrill wrote: For a using-decl in the same scope as the original decl, won't this replace it so o

Re: [PATCH v2 01/11] aarch64: Remove unused global aarch64_tune_flags

Hi Andrew, > On 11 Jul 2024, at 14:11, Andrew Carlotti wrote: > > External email: Use caution opening links or attachments > > > gcc/ChangeLog: > >* config/aarch64/aarch64.cc >(aarch64_tune_flags): Remove unused global variable. >(aarch64_override_options_internal): Re

  1   2   >