[PATCH 2/2] Ada: Finalization of constrained subtypes of unconstrained synchronized private extensions

=== gnat Summary === # of expected passes 3401 # of unexpected failures 4 # of expected failures 23 # of unsupported tests 10 gnatmake version 14.0.0 20230809 (experimental)

[PATCH] sso-string@gnu-versioned-namespace [PR83077]

Hi I've eventually completed this work. This evolution will allow to build libstdc++ without dual abi and using cxx11 abi. For the moment such a config is only accessible through the --enable-symvers=gnu-versioned-namespace configuration.     libstdc++: [_GLIBCXX_INLINE_VERSION] Use cxx11

[PATCH v1] RISC-V: Support RVV VFMACC rounding mode intrinsic API

From: Pan Li This patch would like to support the rounding mode API for the VFMACC for the below samples. * __riscv_vfmacc_vv_f32m1_rm * __riscv_vfmacc_vv_f32m1_rm_m * __riscv_vfmacc_vf_f32m1_rm * __riscv_vfmacc_vf_f32m1_rm_m Signed-off-by: Pan Li gcc/ChangeLog: *

[PATCH 1/2] Ada: Synchronized private extensions are always limited

3402 # of unexpected failures4 # of expected failures 23 # of unsupported tests 10 gnatmake version 14.0.0 20230809 (experimental) Richard Wai ANNEXI-STRAYLINE ada-synchronized-private-types-are-limited.patch Description: Binary data

RE: [PATCH v3] RISC-V: Refactor RVV frm_mode attr for rounding mode intrinsic

Committed with some cleanup in change log, thanks Kito. Pan From: Kito Cheng Sent: Thursday, August 10, 2023 11:14 AM To: Li, Pan2 Cc: GCC Patches ; 钟居哲 ; Jeff Law ; Wang, Yanzhang ; Kito Cheng Subject: Re: [PATCH v3] RISC-V: Refactor RVV frm_mode attr for rounding mode intrinsic LGTM

RE: Re: [PATCH] RISC-V: Fix VLMAX AVL incorrect local anticipate [VSETVL PASS]

Thanks Jeff. Ported to gcc-13 with minor changes to test cases. Pan -Original Message- From: Gcc-patches On Behalf Of juzhe.zh...@rivai.ai Sent: Thursday, August 10, 2023 8:50 AM To: jeffreyalaw ; gcc-patches Cc: kito.cheng ; Kito.cheng ; Robin Dapp Subject: Re: Re: [PATCH] RISC-V:

Re: [PATCH v3] RISC-V: Refactor RVV frm_mode attr for rounding mode intrinsic

LGTM 於 2023年8月10日 週四 11:12 寫道： > From: Pan Li > > The frm_mode attr has some assumptions for each define insn as below. > > 1. The define insn has at least 9 operands. > 2. The operands[9] must be frm reg. > 3. The operands[9] must be const int. > > Actually, the frm operand can be

RE: [PATCH v2] RISC-V: Refactor RVV frm_mode attr for rounding mode intrinsic

Thanks Kito, update it in PATCH v3, and passed riscv/rvv.exp already. https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626918.html Pan -Original Message- From: Kito Cheng Sent: Thursday, August 10, 2023 10:21 AM To: Li, Pan2 Cc: Kito Cheng ; gcc-patches@gcc.gnu.org;

[PATCH v3] RISC-V: Refactor RVV frm_mode attr for rounding mode intrinsic

From: Pan Li The frm_mode attr has some assumptions for each define insn as below. 1. The define insn has at least 9 operands. 2. The operands[9] must be frm reg. 3. The operands[9] must be const int. Actually, the frm operand can be operands[8], operands[9] or operands[10], and not all the

[PATCH 1/1] RISC-V: Make "prefetch.i" built-in usable

From: Tsukasa OI The "__builtin_riscv_zicbop_cbo_prefetchi" built-in function was terribly broken so that practically unusable. It emitted "prefetch.i" but with no meaningful arguments. Though incompatible, this commit completely changes the function prototype of this built-in and makes it

[PATCH 0/1] RISC-V: Make "prefetch.i" built-in usable

Hello, I found that a built-in function "__builtin_riscv_zicbop_cbo_prefetchi" is terribly broken so that this is practically unusable. It emits the "prefetch.i" machine instruction HINT but with no usable arguments. Contents of a.c: > void function_to_be_called(void); > > void sample(void) >

Re: [Patch, fortran] PR109684 - compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

On 8/9/23 7:58 AM, Paul Richard Thomas via Fortran wrote: I took a look at my calendar and decided to backport right away. r13-7703-ged049e5d5f36cc0f4318cd93bb6b33ed6f6f2ba7 BTW It is a regression :-) Paul On Wed, 9 Aug 2023 at 12:10, Paul Richard Thomas wrote: Committed to trunk as

[RFC PATCH 0/2] RISC-V: Make __builtin_riscv_pause 'Zihintpause' only

**WARNING** Following patch sets are exclusive: 1. [RFC PATCH v2] RISC-V: __builtin_riscv_pause for all environment 2. [RFC PATCH] RISC-V: Make __builtin_riscv_pause 'Zihintpause' only (this) See for the background of this

[RFC PATCH 2/2] RISC-V: Fix documentation of __builtin_riscv_pause

From: Tsukasa OI This built-in does not imply the 'Xgnuzihintpausestate' extension. It does not change architectural state (because all HINTs are prohibited from doing that). gcc/ChangeLog: * doc/extend.texi: Fix the description of __builtin_riscv_pause. --- gcc/doc/extend.texi | 6

[RFC PATCH 1/2] RISC-V: Make __builtin_riscv_pause 'Zihintpause' only

From: Tsukasa OI The "pause" RISC-V hint instruction requires the 'Zihintpause' extension (in the assembler). However, GCC emits "pause" unconditionally, making an assembler error while compiling code with __builtin_riscv_pause while the 'Zihintpause' extension disabled. Despite that the

[RFC PATCH v2 1/2] RISC-V: __builtin_riscv_pause for all environment

From: Tsukasa OI The "pause" RISC-V hint instruction requires the 'Zihintpause' extension (in the assembler). However, GCC emits "pause" unconditionally, making an assembler error while compiling code with __builtin_riscv_pause while the 'Zihintpause' extension disabled. However, the "pause"

[RFC PATCH v2 2/2] RISC-V: Fix documentation of __builtin_riscv_pause

From: Tsukasa OI This built-in does not imply the 'Xgnuzihintpausestate' extension. It does not change architectural state (because all HINTs are prohibited from doing that). gcc/ChangeLog: * doc/extend.texi: Fix the description of __builtin_riscv_pause. --- gcc/doc/extend.texi | 6

[RFC PATCH v2 0/2] RISC-V: __builtin_riscv_pause for all environment

**WARNING** Following patch sets are exclusive: 1. [RFC PATCH v2] RISC-V: __builtin_riscv_pause for all environment (this) 2. [RFC PATCH] RISC-V: Make __builtin_riscv_pause 'Zihintpause' only See for the background of this

Re: [PATCH v2] RISC-V: Refactor RVV frm_mode attr for rounding mode intrinsic

Yeah, no further comment from me :) On Thu, Aug 10, 2023 at 10:16 AM Li, Pan2 wrote: > > Thanks kito. It makes sense, should not reach default, may I prepare v3(add > gcc_unreachable to default) if no more comments? > > Pan > > -Original Message- > From: Kito Cheng > Sent: Thursday,

RE: [PATCH v2] RISC-V: Refactor RVV frm_mode attr for rounding mode intrinsic

Thanks kito. It makes sense, should not reach default, may I prepare v3(add gcc_unreachable to default) if no more comments? Pan -Original Message- From: Kito Cheng Sent: Thursday, August 10, 2023 10:12 AM To: Li, Pan2 Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai;

Re: [PATCH] libatomic: Improve ifunc selection on AArch64

On 8/9/23 19:11, Richard Henderson wrote: On 8/4/23 08:05, Wilco Dijkstra via Gcc-patches wrote: +#ifdef HWCAP_USCAT + +#define MIDR_IMPLEMENTOR(midr)    (((midr) >> 24) & 255) +#define MIDR_PARTNUM(midr)    (((midr) >> 4) & 0xfff) + +static inline bool +ifunc1 (unsigned long hwcap) +{ +  if

Re: [PATCH] libatomic: Improve ifunc selection on AArch64

On 8/4/23 08:05, Wilco Dijkstra via Gcc-patches wrote: +#ifdef HWCAP_USCAT + +#define MIDR_IMPLEMENTOR(midr) (((midr) >> 24) & 255) +#define MIDR_PARTNUM(midr) (((midr) >> 4) & 0xfff) + +static inline bool +ifunc1 (unsigned long hwcap) +{ + if (hwcap & HWCAP_USCAT) +return true; + if

Re: [PATCH v2] RISC-V: Refactor RVV frm_mode attr for rounding mode intrinsic

> +/* Get the frm mode with given CONST_INT rtx, the default mode is > + FRM_DYN. */ > +enum floating_point_rounding_mode > +get_frm_mode (rtx operand) > +{ > + gcc_assert (CONST_INT_P (operand)); > + > + switch (INTVAL (operand)) > +{ > +case FRM_RNE: > + return FRM_RNE; > +

RE: [PATCH] Support -m[no-]gather -m[no-]scatter to enable/disable vectorization for all gather/scatter instructions.

> -Original Message- > From: Xi Ruoyao > Sent: Thursday, August 10, 2023 9:48 AM > To: Liu, Hongtao ; gcc-patches@gcc.gnu.org > Cc: richard.guent...@gmail.com; ubiz...@gmail.com; hubi...@ucw.cz > Subject: Re: [PATCH] Support -m[no-]gather -m[no-]scatter to enable/disable > vectorization

Re: [PATCH] Support -m[no-]gather -m[no-]scatter to enable/disable vectorization for all gather/scatter instructions.

On Thu, 2023-08-10 at 09:11 +0800, liuhongt via Gcc-patches wrote: > Currently we have 3 different independent tunes for gather > "use_gather,use_gather_2parts,use_gather_4parts", > similar for scatter, there're > "use_scatter,use_scatter_2parts,use_scatter_4parts" > > The patch support 2

[PATCH] Support -m[no-]gather -m[no-]scatter to enable/disable vectorization for all gather/scatter instructions.

Currently we have 3 different independent tunes for gather "use_gather,use_gather_2parts,use_gather_4parts", similar for scatter, there're "use_scatter,use_scatter_2parts,use_scatter_4parts" The patch support 2 standardizing options to enable/disable vectorization for all gather/scatter

RISC-V: Enable Hoist to GCSE simple constants

-/* { dg-final { scan-assembler-times {j\s+\.L[0-9]+\s+\.L[0-9]+:\s+vlm\.v} 1 { target { no-opts "-O0" no-opts "-O1" no-opts "-Os" no-opts "-Oz" no-opts "-funroll-loops" no-opts "-g" } } } } */ +/* { dg-final { scan-assembler-times {j\s+\.L[0-9]+\s+\.L[0-9]+:\s+vlm\.v} 1 { target { no-opts

Re: Re: [PATCH] RISC-V: Fix VLMAX AVL incorrect local anticipate [VSETVL PASS]

Yes. I think so. Will backport GCC 13 soon. juzhe.zh...@rivai.ai From: Jeff Law Date: 2023-08-10 01:01 To: Juzhe-Zhong; gcc-patches CC: kito.cheng; kito.cheng; rdapp.gcc Subject: Re: [PATCH] RISC-V: Fix VLMAX AVL incorrect local anticipate [VSETVL PASS] On 8/9/23 04:51, Juzhe-Zhong

[PATCH] i386: Do not sanitize upper part of V2HFmode and V4HFmode reg with -fno-trapping-math [PR110832]

Also add ix86_partial_vec_fp_math to to condition of V2HF/V4HF named patterns in order to avoid generation of partial vector V8HFmode trapping instructions. Bootstrapped and regtseted on x86_64-pc-linux-gnu{-m32,} Ok for trunk? gcc/ChangeLog: PR target/110832 *

[PATCH] RISC-V: Enable Hoist to GCSE simple constants

Hoist want_to_gcse_p () calls rtx_cost () to compute max distance for hoist candidates . For a const with cost 1 backend currently returns 0, causing Hoist to bail and elide GCSE. Note that constants requiring more than 1 insns to setup were working already since backend is returning 1 as well.

[PATCH] Fix PR 110954: wrong code with cmp | !cmp

This was an oversight on my part not realizing that comparisons in generic can have a non-boolean type. This means if we have `(f < 0) | !(f < 0)` we would optimize this to -1 rather than just 1. This patch just adds the check for the type of the comparisons to be boolean type to keep the

RE: [PATCH] RISC-V: Fix VLMAX AVL incorrect local anticipate [VSETVL PASS]

Committed to trunk, thanks Jeff. Pan -Original Message- From: Gcc-patches On Behalf Of Jeff Law via Gcc-patches Sent: Thursday, August 10, 2023 1:01 AM To: Juzhe-Zhong ; gcc-patches@gcc.gnu.org Cc: kito.ch...@gmail.com; kito.ch...@sifive.com; rdapp@gmail.com Subject: Re: [PATCH]

Re: [RFC PATCH 0/2] RISC-V: __builtin_riscv_pause for all environment

On 2023/08/10 5:05, Jeff Law wrote: > > > On 8/9/23 00:11, Tsukasa OI via Gcc-patches wrote: >> Hello, >> >> I found that a built-in function "__builtin_riscv_pause" is not usable >> unless we enable the 'Zihintpause' extension explicitly (still, this >> built-in exists EVEN IF the 'Zihintpause'

[PATCH v4 7/8] diagnostics: libcpp: Assign real locations to the tokens inside _Pragma strings

Currently, the tokens obtained from a destringified _Pragma string do not get assigned proper locations while they are being lexed. After the tokens have been obtained, they are reassigned the same location as the _Pragma token, which is sufficient to make things like _Pragma("GCC diagnostic

[PATCH v4 6/8] diagnostics: Full support for generated data locations

Previous patches in this series have laid the groundwork for supporting source code locations in memory ("generated data") rather than ordinary files. This patch completes the support by adding awareness of such locations to all places that need to support them. The main changes are to

[PATCH v4 5/8] diagnostics: Support testing generated data in input.cc selftests

Add selftests for the new capabilities in input.cc related to source code locations that are stored in memory rather than ordinary files. gcc/ChangeLog: * input.cc (temp_source_file::do_linemap_add): New function. (line_table_case::line_table_case): Add GENERATED_DATA argument.

[PATCH v4 3/8] diagnostics: Refactor class file_cache_slot

Class file_cache_slot in input.cc is used to query specific lines of source code from a file when needed by diagnostics infrastructure. This will be extended in a subsequent patch to support obtaining the source code from in-memory generated buffers rather than from a file. The present patch

[PATCH v4 4/8] diagnostics: Support obtaining source code lines from generated data buffers

This patch enhances location_get_source_line(), which is the primary interface provided by the diagnostics infrastructure to obtain the line of source code corresponding to a given location, so that it understands generated data locations in addition to normal file-based locations. This involves

[PATCH v4 8/8] diagnostics: Support generated data locations in SARIF output

The diagnostics routines for SARIF output need to read the source code back in, so that they can generate "snippet" and "content" records, so they need to be able to cope with generated data locations. Add support for that in diagnostic-format-sarif.cc. gcc/ChangeLog: *

[PATCH v4 1/8] libcpp: Add LC_GEN linemaps to support in-memory buffers

Add a new linemap reason LC_GEN which enables encoding the location of data that was generated during compilation and does not appear in any source file. There could be many use cases, such as, for instance, referring to the content of builtin macros (not yet implemented, but an easy lift after

[PATCH v4 2/8] libcpp: diagnostics: Support generated data in expanded locations

The previous patch in this series introduced the concept of LC_GEN line maps. This patch continues on the path to using them to improve _Pragma diagnostics, by adding a new source_id SRC member to struct expanded_location, which is populated by linemap_expand_location. This member allows call

[PATCH v4 0/8] diagnostics: libcpp: Overhaul locations for _Pragma tokens

On Mon, Jul 31, 2023 at 06:39:15PM -0400, Lewis Hyatt wrote: > On Fri, Jul 28, 2023 at 6:58 PM David Malcolm wrote: > > > > On Fri, 2023-07-21 at 19:08 -0400, Lewis Hyatt wrote: > > > Add a new linemap reason LC_GEN which enables encoding the location > > > of data > > > that was generated during

Re: [PATCH V2] riscv: generate builtin macro for compilation with strict alignment:

Hi Vineet, On 8/8/2023 2:02 PM, Vineet Gupta wrote: Maybe add a comment that in absence of -m[no-]strict-align, we use the cpu tune param -> slow_unaligned_access and that default mcpu is rocket which has that set to _slow. That sounds good to me! +#if defined(__riscv_unaligned_avoid)

Re: [PATCH v2] analyzer: More features for CPython analyzer plugin [PR107646]

On Wed, 2023-08-09 at 15:22 -0400, Eric Feng wrote: > Thank you for your help in getting dg-require-python-h working! I can > confirm that the FAILs are related to differences between the -- > cflags > affecting the gimple seen by the analyzer. For this reason, I have > changed it to --includes

Re: [PATCH 0/12] GCC _BitInt support [PR102989]

On Wed, 9 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > - _Complex _BitInt(N) isn't supported; again mainly because none of the psABIs > mention how those should be passed/returned; in a limited way they are > supported internally because the internal functions into which >

[PING 2][PATCH 0/9] Add btf_decl_tag C attribute

Ping for this series. https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624156.html Thanks On 7/11/23 14:57, David Faust via Gcc-patches wrote: > Hello, > > This series adds support for a new attribute, "btf_decl_tag" in GCC. > The same attribute is already supported in clang, and is used by

Re: Intel AVX10.1 Compiler Design and Support

On Wed, Aug 09, 2023 at 08:43:00PM +, Joseph Myers wrote: > At this point it seems appropriate to remind people of another ABI > consideration for vector extensions. glibc's libmvec defines vector > versions of various functions, including AVX512 ones (of course those > function versions

Re: [patch] libgomp: cuda.h and omp_target_memcpy_rect cleanup (was: [patch] OpenMP: Call cuMemcpy2D/cuMemcpy3D for nvptx for omp_target_memcpy_rect)

Hi Tobias! On 2023-07-28T13:51:41+0200, Tobias Burnus wrote: > On 27.07.23 23:00, Thomas Schwinge wrote: >>> + else if (src_devicep != NULL >>> +&& (dst_devicep == NULL >>> +|| (dst_devicep->capabilities >>> +& GOMP_OFFLOAD_CAP_SHARED_MEM)))

RE: Intel AVX10.1 Compiler Design and Support

On Wed, 9 Aug 2023, Wang, Phoebe via Gcc-patches wrote: > Proposal 3: Change the ABI of 512-bit vector and always be > passed/returned from memory. Changing ABIs like that for existing code that has worked for some time on existing hardware is a bad idea. At this point it seems appropriate to

Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> On Aug 8, 2023, at 10:54 AM, Martin Uecker wrote: > > > > I am sure this has been discussed before, but seeing that you > test for a specific formula, let me point out the following: > > There at least three different size expression which could > make sense. Consider > > short foo { int

Re: [PATCH] testsuite: Fix gcc.dg/analyzer/allocation-size-multiline-[123].c [PR 110426]

On Tue, 2023-08-08 at 15:01 +, Christophe Lyon wrote: > For 32-bit newlib targets (e.g. arm-eabi)  int32_t is "long int". > > Like previous patches in these tests, update the matching regexps to > match "aka (long )?int". > > Tested on arm-eabi and aarch64-linux-gnu. Sorry about this

Re: [PATCH 00/24] Sync shared build infrastructure with binutils-gdb

On Wed, 9 Aug 2023, Arsen Arsenović via Gcc-patches wrote: > Joseph Myers writes: > > > On Tue, 8 Aug 2023, Arsen Arsenović via Gcc-patches wrote: > > > >> Yes. Libtool was forked over a decade ago. My next project is syncing > >> upstream and us back up. Unsure about pkg.m4. > > > > Note as

[PATCH 3/3] testsuite: Use distinct explicit error codes in value_9.f90

Use distinct error codes, so that we can spot directly from the testsuite log which case is failing. gcc/testsuite/ChangeLog: * gfortran.dg/value_9.f90 (val, val4, sub, sub4): Take the error codes from the arguments. (p): Update calls: pass explicit distinct error codes.

[PATCH 1/3] fortran: New predicate gfc_length_one_character_type_p

Introduce a new predicate to simplify conditionals checking for a character type whose length is the constant one. gcc/fortran/ChangeLog: * gfortran.h (gfc_length_one_character_type_p): New inline function. * check.cc (is_c_interoperable): Use

[PATCH 2/3] fortran: Fix length one character dummy arg type [PR110419]

Revision r14-2171-g8736d6b14a4dfdfb58c80ccd398981b0fb5d00aa changed the argument passing convention for length 1 value dummy arguments to pass just the single character by value. However, the procedure declarations weren't updated to reflect the change in the argument types. This change does the

[PATCH 0/3] fortran: fix length one character dummy args [PR110419]

Hello, I propose with this patchset a fix for the test value_9.f90 which has been failing on 32 bits powerpc since it was added a few weeks back (see PR110360 and PR110419). The problem is an argument type mismatch between a procedure declaration, and the argument value for a call of that same

[pushed] analyzer: remove default return value from region_model::on_call_pre

Previously, the code for simulating calls to external functions in region_model::on_call_pre wrote a default svalue to the LHS of the call statement, which could be further overwritten by known_function subclasses. Unfortunately, this led to messy hacks, such as when the default svalue was an

Re: [PATCH 3/12] phiopt: Fix phiopt ICE on vops [PR102989]

On Wed, Aug 09, 2023 at 01:06:22PM -0700, Andrew Pinski wrote: > That was my next thought, returning NULL from > single_non_singleton_phi_for_edges if it would return a virtual OP > might be better even. > Either version of these patches are ok with me (though I am not the > maintainer here). In

Re: [RFC] GCC Security policy

On 2023-08-09 14:17, David Edelsohn wrote: On Wed, Aug 9, 2023 at 1:33 PM Siddhesh Poyarekar > wrote: On 2023-08-08 10:30, Siddhesh Poyarekar wrote: >> Do you have a suggestion for the language to address libgcc, >> libstdc++, etc. and libiberty,

Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> On Aug 9, 2023, at 12:21 PM, Michael Matz wrote: > > Hello, > > On Wed, 9 Aug 2023, Qing Zhao wrote: > >> Although this is an old FAM related issue that does not relate to my current >> patch >> (and might need to be resolved in a separate patch). I think that it’s >> necessary to have

Re: [PATCH 3/12] phiopt: Fix phiopt ICE on vops [PR102989]

On Wed, Aug 9, 2023 at 1:01 PM Jakub Jelinek wrote: > > On Wed, Aug 09, 2023 at 11:27:48AM -0700, Andrew Pinski wrote: > > Maybe it is better to punt for VOPS after the call to > > single_non_singleton_phi_for_edges since none of functions called > > afterwards support VOPs. > > That is something

Re: [RFC PATCH 0/2] RISC-V: __builtin_riscv_pause for all environment

On 8/9/23 00:11, Tsukasa OI via Gcc-patches wrote: Hello, I found that a built-in function "__builtin_riscv_pause" is not usable unless we enable the 'Zihintpause' extension explicitly (still, this built-in exists EVEN IF the 'Zihintpause' extension is disabled). Contents of a.c: void

Re: [PATCH 3/12] phiopt: Fix phiopt ICE on vops [PR102989]

On Wed, Aug 09, 2023 at 11:27:48AM -0700, Andrew Pinski wrote: > Maybe it is better to punt for VOPS after the call to > single_non_singleton_phi_for_edges since none of functions called > afterwards support VOPs. > That is something like: > diff --git a/gcc/tree-ssa-phiopt.cc

Re: [PATCH] RISC-V: Remove non-existing 'Zve32d' extension

On 8/9/23 00:09, Tsukasa OI via Gcc-patches wrote: Since this extension does not exist, this commit prunes this from the defined extension version table. gcc/ChangeLog: * common/config/riscv/riscv-common.cc(riscv_ext_version_table): Remove 'Zve32d' from the version list.

Re: [PATCH] RISC-V: Handle no_insn in TARGET_SCHED_VARIABLE_ISSUE.

On 5/29/23 06:46, Jeff Law wrote: On 5/29/23 05:01, Jin Ma wrote: Reference: https://github.com/gcc-mirror/gcc/commit/d0bc0cb66bcb0e6a5a5a31a9e900e8ccc98e34e5 RISC-V should also be implemented to handle no_insn patterns for pipelining. gcc/ChangeLog: * config/riscv/riscv.cc

Re: RISC-V: Folding memory for FP + constant case

On 7/12/23 14:59, Jivan Hakobyan via Gcc-patches wrote: Accessing local arrays element turned into load form (fp + (index << C1)) + C2 address. In the case when access is in the loop we got loop invariant computation. For some reason, moving out that part cannot be done in loop-invariant

[PATCH v2] analyzer: More features for CPython analyzer plugin [PR107646]

Thank you for your help in getting dg-require-python-h working! I can confirm that the FAILs are related to differences between the --cflags affecting the gimple seen by the analyzer. For this reason, I have changed it to --includes for now. To be sure, I tested on Python 3.8 as well and it works

[PATCH] MATCH: [PR110937/PR100798] (a ? ~b : b) should be optimized to b ^ -(a)

This adds a simple match pattern for this case. I noticed it a couple of different places. One while I was looking at code generation of a parser and also while I was looking at locations where bitwise_inverted_equal_p should be used more. Committed as approved after bootstrapped and tested on

Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On Mon, Aug 07, 2023 at 04:33:13PM +, Qing Zhao wrote: > What’s the testing case for the one that failed? > If it’s > > __builtin_dynamic_object_size(p->array, 0/2) without the allocation > information in the routine, > then with the current algorithm, gcc cannot deduce the size for the

PING^3: [PATCH V4, rs6000] Disable generation of scalar modulo instructions

Ping. On 6/30/23 2:26 PM, Pat Haugen via Gcc-patches wrote: Updated from prior version to address latest review comment (simplify umod3). Disable generation of scalar modulo instructions. It was recently discovered that the scalar modulo instructions can suffer noticeable performance issues

Re: [PATCH 3/12] phiopt: Fix phiopt ICE on vops [PR102989]

On Wed, Aug 9, 2023 at 11:17 AM Jakub Jelinek via Gcc-patches wrote: > > Hi! > > I've ran into ICE on gcc.dg/torture/bitint-42.c with -O1 or -Os > when enabling expensive tests, and unfortunately I can't reproduce without > _BitInt. The IL before phiopt3 has: >[local count: 203190070]: > #

[PATCH 10/12] C _BitInt support [PR102989]

Hi! This patch adds the C FE support, c-family support, small libcpp change so that 123wb and 42uwb suffixes are handled plus glimits.h change to define BITINT_MAXWIDTH macro. The previous patches really do nothing without this, which enables all the support. 2023-08-09 Jakub Jelinek

[PATCH 9/12] libgcc _BitInt support [PR102989]

Hi! This patch adds the library helpers for multiplication, division + modulo and casts from and to floating point (both binary and decimal). As described in the intro, the first step is try to reduce further the passed in precision by skipping over most significant limbs with just zeros or sign

[PATCH 7/12] ubsan: _BitInt -fsanitize=undefined support [PR102989]

Hi! The following patch introduces some -fsanitize=undefined support for _BitInt, but some of the diagnostics is limited by lack of proper support in the library. I've filed https://github.com/llvm/llvm-project/issues/64100 to request proper support, for now some of the diagnostics might have

[PATCH 6/12] i386: Enable _BitInt on x86-64 [PR102989]

Hi! The following patch enables _BitInt support on x86-64, the only target which has _BitInt specified in psABI. 2023-08-09 Jakub Jelinek PR c/102989 * config/i386/i386.cc (classify_argument): Handle BITINT_TYPE. (ix86_bitint_type_info): New function.

Re: [RFC] GCC Security policy

On Wed, Aug 9, 2023 at 1:33 PM Siddhesh Poyarekar wrote: > On 2023-08-08 10:30, Siddhesh Poyarekar wrote: > >> Do you have a suggestion for the language to address libgcc, > >> libstdc++, etc. and libiberty, libbacktrace, etc.? > > > > I'll work on this a bit and share a draft. > > Hi David, > >

[PATCH 4/12] Middle-end _BitInt support [PR102989]

Hi! The following patch introduces the middle-end part of the _BitInt support, a new BITINT_TYPE, handling it where needed, except the lowering pass and sanitizer support. 2023-08-09 Jakub Jelinek PR c/102989 * tree.def (BITINT_TYPE): New type. * tree.h (TREE_CHECK6,

[PATCH 3/12] phiopt: Fix phiopt ICE on vops [PR102989]

Hi! I've ran into ICE on gcc.dg/torture/bitint-42.c with -O1 or -Os when enabling expensive tests, and unfortunately I can't reproduce without _BitInt. The IL before phiopt3 has: [local count: 203190070]: # .MEM_428 = VDEF <.MEM_367> bitint.159 = VIEW_CONVERT_EXPR(*.LC3); goto ;

[PATCH 2/12] lto-streamer-in: Adjust assert [PR102989]

Hi! With _BitInt(575) or any other _BitInt(513) or larger constants we can run into this assertion. MAX_BITSIZE_MODE_ANY_INT is just a value from which WIDE_INT_MAX_PRECISION is derived. 2023-08-09 Jakub Jelinek PR c/102989 * lto-streamer-in.cc (lto_input_tree_1): Assert

[PATCH 1/12] expr: Small optimization [PR102989]

Hi! Small optimization to avoid testing modifier multiple times. 2023-08-09 Jakub Jelinek PR c/102989 * expr.cc (expand_expr_real_1) : Add an early return for EXPAND_WRITE or EXPAND_MEMORY modifiers to avoid testing it multiple times. --- gcc/expr.cc.jj

[PATCH 0/12] GCC _BitInt support [PR102989]

Hi! The following patch series introduces support for C23 bit-precise integer types. In short, they are similar to other integral types in many ways, just aren't subject for integral promotions if smaller than int and they can have even much wider precisions than ordinary integer types. This

Re: [PATCH v9] RISC-V: Add the 'zfa' extension, version 0.2

Hi Jin Ma, On 5/16/23 00:06, jinma via Gcc-patches wrote: On 5/15/23 07:16, Jin Ma wrote: Do we also need to check Z[FDH]INX too? Otherwise it looks pretty good. We just need to wait for everything to freeze and finalization on the assembler interface. jeff Yes, you are right, we also

Re: [PATCH] aarch64: enable mixed-types for aarch64 simdclones

On Wed, Aug 09, 2023 at 06:27:20PM +0100, Richard Sandiford wrote: > Jakub Jelinek writes: > > On Wed, Aug 09, 2023 at 05:55:28PM +0100, Richard Sandiford wrote: > >> Jakub: do you remember what the reason was? I don't mind dropping > >> "function", but it feels weird to drop the quotes around

Re: [RFC] GCC Security policy

On 2023-08-08 10:30, Siddhesh Poyarekar wrote: Do you have a suggestion for the language to address libgcc, libstdc++, etc. and libiberty, libbacktrace, etc.? I'll work on this a bit and share a draft. Hi David, Here's what I came up with for different parts of GCC, including the runtime

Re: [PATCH] aarch64: enable mixed-types for aarch64 simdclones

Jakub Jelinek writes: > On Wed, Aug 09, 2023 at 05:55:28PM +0100, Richard Sandiford wrote: >> Jakub: do you remember what the reason was? I don't mind dropping >> "function", but it feels weird to drop the quotes around "simd". >> Seems like, if we do that, there'll one day be a patch to add >>

Re: [PATCH] aarch64: enable mixed-types for aarch64 simdclones

On Wed, Aug 09, 2023 at 05:55:28PM +0100, Richard Sandiford wrote: > Jakub: do you remember what the reason was? I don't mind dropping > "function", but it feels weird to drop the quotes around "simd". > Seems like, if we do that, there'll one day be a patch to add > them back. :) Because in

Re: [PATCH] aarch64: enable mixed-types for aarch64 simdclones

On 09/08/2023 17:55, Richard Sandiford wrote: "Andre Vieira (lists)" writes: On 08/08/2023 11:51, Richard Sandiford wrote: "Andre Vieira (lists)" writes: warning_at (DECL_SOURCE_LOCATION (node->decl), 0, - "unsupported return type %qT for % functions", +

Re: [PATCH] RISC-V: Fix VLMAX AVL incorrect local anticipate [VSETVL PASS]

On 8/9/23 04:51, Juzhe-Zhong wrote: Realize we have a bug in VSETVL PASS which is triggered by strided_load_run-1.c in RV32 system. FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/strided_load_run-1.c execution test FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/strided_load_run-1.c

Re: [PATCH] aarch64: enable mixed-types for aarch64 simdclones

"Andre Vieira (lists)" writes: > Here is my new version, see inline response to your comments. > > New cover letter: > > This patch enables the use of mixed-types for simd clones for AArch64, > adds aarch64 as a target_vect_simd_clones and corrects the way the > simdlen is chosen for

[PATCH v3] tree-optimization/110279- Check for nested FMA in reassoc

Hi, The previous version of this patch tries to solve two problems at the same time. For better clarity, I'll separate them and only deal with the "nested" FMA in this version. I plan to propose another patch in avoiding bad shaped FMA (deferring FMA). Other changes: 1. Added new testcases for

Re: [PATCH] Handle in-order reductions when SLP vectorizing non-loops

On 8/9/23 07:51, Alexander Monakov wrote: On Wed, 9 Aug 2023, Richard Biener via Gcc-patches wrote: The following teaches the non-loop reduction vectorization code to handle non-associatable reductions. Using the existing FOLD_LEFT_PLUS internal functions might be possible but I'd have to

Re: [PATCH v4] Implement new RTL optimizations pass: fold-mem-offsets.

On 8/7/23 08:33, Manolis Tsamis wrote: This is a new RTL pass that tries to optimize memory offset calculations by moving them from add immediate instructions to the memory loads/stores. For example it can transform this: addi t4,sp,16 add t2,a6,t4 shl t3,t2,1 ld a2,0(t3)

Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

Hello, On Wed, 9 Aug 2023, Qing Zhao wrote: > Although this is an old FAM related issue that does not relate to my current > patch > (and might need to be resolved in a separate patch). I think that it’s > necessary to have > more discussion on this old issue and resolve it. > > The first

[PATCH] VR-VALUES: Simplify comparison using range pairs

If `A` has a range of `[0,0][100,INF]` and the comparison of `A < 50`. This should be optimized to `A <= 0` (which then will be optimized to just `A == 0`). This patch implement this via a new function which sees if the constant of a comparison is in the middle of 2 range pairs and change the

Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

Hi, Martin, Thanks for raising this issue. Although this is an old FAM related issue that does not relate to my current patch (and might need to be resolved in a separate patch). I think that it’s necessary to have more discussion on this old issue and resolve it. The first thing that I’d

verify

verify

[PATCH] rs6000, add overloaded DFP quantize support

GCC maintainers: The following patch adds four built-ins for the decimal floating point (DFP) quantize instructions on rs6000. The built-ins are for 64-bit and 128-bit DFP operands. The patch also adds a test case for the new builtins. The Patch has been tested on Power 10LE and Power 9

Re: [PATCH ver 3] rs6000: Fix __builtin_altivec_vcmpne{b,h,w} implementation

Kewen: On Wed, 2023-08-09 at 16:47 +0800, Kewen.Lin wrote: > > Patch has been tested on Power 8 LE/BE, Power 9 LE/BE and Power 10 > > LE > > with no regressions. > > Okay for trunk with two nits below fixed, thanks! Thanks for all the help with the patch. Fixed the nits below, compiled and

Re: [PATCH] aarch64: enable mixed-types for aarch64 simdclones

Here is my new version, see inline response to your comments. New cover letter: This patch enables the use of mixed-types for simd clones for AArch64, adds aarch64 as a target_vect_simd_clones and corrects the way the simdlen is chosen for non-specified simdlen clauses according to the

Re: [Patch, fortran] PR109684 - compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

I took a look at my calendar and decided to backport right away. r13-7703-ged049e5d5f36cc0f4318cd93bb6b33ed6f6f2ba7 BTW It is a regression :-) Paul On Wed, 9 Aug 2023 at 12:10, Paul Richard Thomas wrote: > > Committed to trunk as 'obvious' in >

  1   2   >