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: [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: [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, libback

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 p

[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 allo

[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 pr

[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 m

[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 gfc_length_one_charac

[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. -

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

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 breakag

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: 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: [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, 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 on

[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: [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 > __builtin_{add

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 for

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) +

[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

[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 sites

[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 thi

[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: * diagnostic-format

[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 ch

[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 refact

[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 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 diagnostic-s

[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 ignor

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'

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] RIS

[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 optimizat

[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. Ar

[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 * config/i386/mmx.md

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 wrote:

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 "-O

[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 instructio

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 standard

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 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; > +c

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] 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 (hw

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; jeffreya...@gma

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, Aug

[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 pat

[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 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" in

[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 "pause

[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 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 pat

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 'obvio

[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) >

[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 usab

[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 def

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; juzhe.zh...@

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 operands[8],

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: F

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 mai

[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

[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: * config/riscv/riscv-

[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 ab

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

(test for warnings, line 42) === gnat Summary === # of expected passes 3401 # of unexpected failures 4 # of expected failures 23 # of unsupported tests 10 gnatmake ver

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

On Thu, Aug 10, 2023 at 2:49 AM liuhongt wrote: > > 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/

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

On Thu, Aug 10, 2023 at 3:13 AM liuhongt 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 standardizing options to

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

On Thu, Aug 10, 2023 at 2:01 PM Uros Bizjak via Gcc-patches wrote: > > On Thu, Aug 10, 2023 at 2:49 AM liuhongt wrote: > > > > 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. > > >

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

On Thu, Aug 10, 2023 at 2:04 PM Uros Bizjak via Gcc-patches wrote: > > On Thu, Aug 10, 2023 at 3:13 AM liuhongt 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_sc

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

On Thu, Aug 10, 2023 at 2:06 PM Hongtao Liu wrote: > > On Thu, Aug 10, 2023 at 2:01 PM Uros Bizjak via Gcc-patches > wrote: > > > > On Thu, Aug 10, 2023 at 2:49 AM liuhongt wrote: > > > > > > Also add ix86_partial_vec_fp_math to to condition of V2HF/V4HF named > > > patterns in order to avoid ge

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

On Wed, 9 Aug 2023, Jakub Jelinek wrote: > 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 wi

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

On Wed, 9 Aug 2023, Joseph Myers wrote: > 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 beca

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

Am Mittwoch, dem 09.08.2023 um 20:10 + schrieb Qing Zhao: > > > On Aug 9, 2023, at 12:21 PM, Michael Matz wrote: ... > > By definition, the sizeof() of a struct with FAM might not be the same as the > non-FAM one. > i.e, for the following two structures, one with FAM, the other with fixed

<    1   2