[PATCH] Rename local variable subleaf_level to max_subleaf_level.

This minor fix is preapproved in [1]. Committed to trunk. [1] https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626758.html gcc/ChangeLog: * common/config/i386/cpuinfo.h (get_available_features): Rename local variable subleaf_level to max_subleaf_level. --- gcc/common/config

Re: [PATCH V2] [X86] Workaround possible CPUID bug in Sandy Bridge.

On Wed, Aug 9, 2023 at 8:38 AM Uros Bizjak wrote: > > On Wed, Aug 9, 2023 at 8:37 AM Liu, Hongtao wrote: > > > > > > > > > -Original Message- > > > From: Uros Bizjak > > > Sent: Wednesday, August 9, 2023 2:33 PM > > > To: Liu, Hongtao > > > Cc: gcc-patches@gcc.gnu.org > > > Subject: Re:

Re: [PATCH V2] [X86] Workaround possible CPUID bug in Sandy Bridge.

On Wed, Aug 9, 2023 at 8:37 AM Liu, Hongtao wrote: > > > > > -Original Message- > > From: Uros Bizjak > > Sent: Wednesday, August 9, 2023 2:33 PM > > To: Liu, Hongtao > > Cc: gcc-patches@gcc.gnu.org > > Subject: Re: [PATCH V2] [X86] Workaround possible CPUID bug in Sandy > > Bridge. > >

RE: [PATCH V2] [X86] Workaround possible CPUID bug in Sandy Bridge.

> -Original Message- > From: Uros Bizjak > Sent: Wednesday, August 9, 2023 2:33 PM > To: Liu, Hongtao > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH V2] [X86] Workaround possible CPUID bug in Sandy > Bridge. > > On Wed, Aug 9, 2023 at 3:48 AM liuhongt wrote: > > > > > Please rath

[PATCH] VECT: Support loop len control on EXTRACT_LAST vectorization

From: Ju-Zhe Zhong Hi, this patch is adding loop len control on extract_last autovectorization. Consider this following case: #include #define EXTRACT_LAST(TYPE) \ TYPE __attribute__ ((noinline, noclone)) \ test_##TYPE (TYPE *x, int n, TYPE value) \ {

Re: [PATCH V2] [X86] Workaround possible CPUID bug in Sandy Bridge.

On Wed, Aug 9, 2023 at 3:48 AM liuhongt wrote: > > > Please rather do it in a more self-descriptive way, as proposed in the > > attached patch. You won't need a comment then. > > > > Adjusted in V2 patch. > > Don't access leaf 7 subleaf 1 unless subleaf 0 says it is > supported via EAX. > > Intel

Re: RISC-V: Added support for CRC.

On Tue, 8 Aug 2023, Jeff Law wrote: > If the compiler can identify a CRC and collapse it down to a table or clmul, > that's a major win and such code does exist in the real world. That was the > whole point behind the Fedora experiment -- to determine if these things are > showing up in the real

RE: Intel AVX10.1 Compiler Design and Support

> -Original Message- > From: Richard Biener > Sent: Tuesday, August 8, 2023 8:45 PM > To: Jiang, Haochen > Cc: Jakub Jelinek ; gcc-patches@gcc.gnu.org; > ubiz...@gmail.com; Liu, Hongtao > Subject: Re: Intel AVX10.1 Compiler Design and Support > > On Tue, Aug 8, 2023 at 10:15 AM Jiang, H

RE: Intel AVX10.1 Compiler Design and Support

> -Original Message- > From: Richard Biener > Sent: Wednesday, August 9, 2023 1:38 PM > To: Phoebe Wang > Cc: Hongtao Liu ; Joseph Myers > ; Jiang, Haochen ; gcc- > patc...@gcc.gnu.org; ubiz...@gmail.com; Liu, Hongtao > ; Zhang, Annita ; Wang, > Phoebe ; x86-64-abi a...@googlegroups.com>

[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: __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 0/2] RISC-V: __builtin_riscv_pause for all environment

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 sample(void) > { > __builtin_riscv_pause(); > } Compi

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

From: Tsukasa OI 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. --- gcc/common/config/riscv/riscv-common

Re: [PATCH V2] [X86] Workaround possible CPUID bug in Sandy Bridge.

On Wed, Aug 9, 2023 at 3:48 AM liuhongt wrote: > > > Please rather do it in a more self-descriptive way, as proposed in the > > attached patch. You won't need a comment then. > > > > Adjusted in V2 patch. > > Don't access leaf 7 subleaf 1 unless subleaf 0 says it is > supported via EAX. > > Intel

Re: Intel AVX10.1 Compiler Design and Support

> Am 09.08.2023 um 06:02 schrieb Phoebe Wang via Gcc-patches > : > > I have some proposals about unifying ABI on AVX10 for both 256-bit and > 512-bit. > > > > Proposal 1: Promote attribute from AVX10-256 to AVX10-512 for any function > which has 512-bit or above vectors in passing/returnin

Re: Intel AVX10.1 Compiler Design and Support

I have some proposals about unifying ABI on AVX10 for both 256-bit and 512-bit. Proposal 1: Promote attribute from AVX10-256 to AVX10-512 for any function which has 512-bit or above vectors in passing/returning arguments. Problem: Binary cannot run on AVX10-256 only target. Reason: When user

RE: Intel AVX10.1 Compiler Design and Support

I have some proposals about unifying ABI on AVX10 for both 256-bit and 512-bit. Proposal 1: Promote attribute from AVX10-256 to AVX10-512 for any function which has 512-bit or above vectors in passing/returning arguments. Problem: Binary cannot run on AVX10-256 only target. Reason: When user trie

Re: [PATCH] RISC-V: Fix error combine of pred_mov pattern

Hi Jeff, > The pattern's operand 0 explicitly allows MEMs as do the constraints. > So forcing the operand into a register just seems like it's papering > over the real problem. The added of force_reg code is address the problem preduced after address the error combine. The more restrict condti

Re: [PATCH 2/9] LoongArch: Fix default ISA setting

On Sun, 2023-08-06 at 20:49 +0800, Jiajie Chen via Gcc-patches wrote: > When loongarch_arch_target is called, la_target has not been > initialized, thus the macro LARCH_ACTUAL_ARCH always equals to zero. > > This commit fixes by expanding the macro and reading the latest value. > It permits -march

[PATCH v3] Mode-Switching: Fix SET_SRC ICE when CLOBBER insn

From: Pan Li In same cases, like gcc/testsuite/gcc.dg/pr78148.c in RISC-V, there will be only 1 operand when SET_SRC in create_pre_exit. For example as below. (insn 13 9 14 2 (clobber (reg/i:TI 10 a0)) "gcc/testsuite/gcc.dg/pr78148.c":24:1 -1 (expr_list:REG_UNUSED (reg/i:TI 10 a0) (nil)))

Re: [PATCH 1/9] LoongArch: Introduce loongarch32 target

Hi Jiajie, Thanks for you contribution. But we need some time to define/write/public ilp32d abi doc. Jiajie Chen via Gcc-patches writes: > Introduce loongarch32 target and ilp32 abi variants. The ilp32d abi > variant is selected as the default abi of loongarch32 target. > > contrib/ChangeLog:

Re: Intel AVX10.1 Compiler Design and Support

On Wed, Aug 9, 2023 at 10:14 AM Hongtao Liu wrote: > > On Wed, Aug 9, 2023 at 9:21 AM Hongtao Liu wrote: > > > > On Wed, Aug 9, 2023 at 3:55 AM Joseph Myers wrote: > > > > > > Do you have any comments on the interaction of AVX10 with the > > > micro-architecture levels defined in the ABI (and su

Re: Intel AVX10.1 Compiler Design and Support

On Wed, Aug 9, 2023 at 9:21 AM Hongtao Liu wrote: > > On Wed, Aug 9, 2023 at 3:55 AM Joseph Myers wrote: > > > > Do you have any comments on the interaction of AVX10 with the > > micro-architecture levels defined in the ABI (and supported with > > glibc-hwcaps directories in glibc)? Given that t

Re: Intel AVX10.1 Compiler Design and Support

On Wed, Aug 9, 2023 at 10:06 AM Hongtao Liu wrote: > > On Tue, Aug 8, 2023 at 8:45 PM Richard Biener via Gcc-patches > wrote: > > > > On Tue, Aug 8, 2023 at 10:15 AM Jiang, Haochen via Gcc-patches > > wrote: > > > > > > Hi Jakub, > > > > > > > So, what does this imply for the current ISAs? > > >

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 8, 2023 at 8:45 PM Richard Biener via Gcc-patches wrote: > > On Tue, Aug 8, 2023 at 10:15 AM Jiang, Haochen via Gcc-patches > wrote: > > > > Hi Jakub, > > > > > So, what does this imply for the current ISAs? > > > > AVX10 will imply AVX2 on the ISA level. And we suppose AVX10 is an >

[PATCH V2] [X86] Workaround possible CPUID bug in Sandy Bridge.

> Please rather do it in a more self-descriptive way, as proposed in the > attached patch. You won't need a comment then. > Adjusted in V2 patch. Don't access leaf 7 subleaf 1 unless subleaf 0 says it is supported via EAX. Intel documentation says invalid subleaves return 0. We had been relying

Re: Intel AVX10.1 Compiler Design and Support

On Wed, Aug 9, 2023 at 3:55 AM Joseph Myers wrote: > > Do you have any comments on the interaction of AVX10 with the > micro-architecture levels defined in the ABI (and supported with > glibc-hwcaps directories in glibc)? Given that the levels are cumulative, > should we take it that any future l

[PATCH v2] Re: [WIP] Have -Wpointer-sign be enabled by -Wextra, too [PR109836]

On Tue, May 30, 2023 at 5:42 PM Eric Gallager wrote: > > PR109836 is a request to have -Wpointer-sign enabled by default. There > were points of disagreement raised in the bug report, so I figured > that maybe as a compromise, the warning could just be enabled by > -Wextra, as well (I have in fact

Re: RISC-V: Added support for CRC.

On 8/8/23 17:31, Andrew Pinski wrote: On Tue, Aug 8, 2023 at 4:17 PM Jeff Law via Gcc-patches wrote: On 8/8/23 10:38, Alexander Monakov wrote: On Tue, 8 Aug 2023, Jeff Law wrote: That was my thinking at one time. Then we started looking at the distros and found enough crc implementat

Re: RISC-V: Added support for CRC.

On Tue, Aug 8, 2023 at 4:17 PM Jeff Law via Gcc-patches wrote: > > > > On 8/8/23 10:38, Alexander Monakov wrote: > > > > On Tue, 8 Aug 2023, Jeff Law wrote: > > > >> That was my thinking at one time. Then we started looking at the distros > >> and > >> found enough crc implementations in there t

Re: RISC-V: Added support for CRC.

On 8/8/23 10:38, Alexander Monakov wrote: On Tue, 8 Aug 2023, Jeff Law wrote: That was my thinking at one time. Then we started looking at the distros and found enough crc implementations in there to change my mind about the overall utility. The ones I'm familiar with are all table-based

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

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 per previous discussions that libtool commit > 3334f7ed5851ef1e96b052f2984

Re: [committed][RISC-V] Fix 20010221-1.c with zicond

On 8/8/23 15:52, Maciej W. Rozycki wrote: On Fri, 4 Aug 2023, Jeff Law via Gcc-patches wrote: It's also something I kept meaning to resolve and your submission just gave me the proper motivation to move zicond forward. The target specific bits you did lined up perfectly with the community f

[PATCH] libstdc++: fix memory clobbering in std::vector [PR110879]

Because of the recent change in _M_realloc_insert and _M_default_append, call to deallocate was ordered after assignment to class members of std::vector (in the guard destructor), which is causing said members to be call-clobbered. This is preventing further optimization, the compiler is unable to

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

Hi Joseph > On 8 Aug 2023, at 20:41, Joseph Myers wrote: > > 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 per previous discussions that libto

Re: [RFC v2] RISC-V: Add Ztso atomic mappings

On 7/31/23 22:04, Jeff Law wrote: On 7/17/23 15:28, Patrick O'Neill wrote: The RISC-V Ztso extension currently has no effect on generated code. With the additional ordering constraints guarenteed by Ztso, we can emit more optimized atomic mappings than the RVWMO mappings. This PR defines a

Re: [PATCH v3] RISC-V: Add Ztso atomic mappings

On Tue, 08 Aug 2023 14:52:14 PDT (-0700), Patrick O'Neill wrote: The RISC-V Ztso extension currently has no effect on generated code. With the additional ordering constraints guarenteed by Ztso, we can emit more optimized atomic mappings than the RVWMO mappings. This PR implements the Ztso psABI

Re: [PATCH] preprocessor: c++: Support `#pragma GCC target' macros [PR87299]

On 7/31/23 22:22, Lewis Hyatt via Gcc-patches wrote: `#pragma GCC target' is not currently handled in preprocess-only mode (e.g., when running gcc -E or gcc -save-temps). As noted in the PR, this means that if the target pragma defines any macros, those macros are not effective in preprocess-only

[PATCH v3] RISC-V: Add Ztso atomic mappings

The RISC-V Ztso extension currently has no effect on generated code. With the additional ordering constraints guarenteed by Ztso, we can emit more optimized atomic mappings than the RVWMO mappings. This PR implements the Ztso psABI mappings[1]. [1] https://github.com/riscv-non-isa/riscv-elf-psabi

Re: [committed][RISC-V] Fix 20010221-1.c with zicond

On Fri, 4 Aug 2023, Jeff Law via Gcc-patches wrote: > It's also something I kept meaning to resolve and your submission just gave me > the proper motivation to move zicond forward. The target specific bits you > did lined up perfectly with the community feedback on the original VRULL > implementa

Re: RV64 Zicond ICE (was Re: [committed][RISC-V]Don't reject constants in cmov condition)

On 8/8/23 11:21, Vineet Gupta wrote: Hi Jeff, On 8/7/23 13:36, Jeff Law wrote: This test is too aggressive.  Constants have VOIDmode, so we need to let the through this phase of conditional move support. Fixes several missed conditional moves with the trunk. Committed to the trunk, As

[committed] [RISC-V] Fix bug in condition canonicalization for zicond

Vineet's glibc build triggered an ICE building glibc with the latest zicond bits. It's a minor issue in the canonicalization of the condition. When we need to canonicalize the condition we use an SCC insn to handle the primary comparison with the output going into a temporary with the final

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

On 8/8/23 13:24, Edwin Lu wrote: diff --git a/gcc/testsuite/gcc.target/riscv/attribute-1.c b/gcc/testsuite/gcc.target/riscv/attribute-1.c index bc919c586b6..4b077c980a4 100644 --- a/gcc/testsuite/gcc.target/riscv/attribute-1.c +++ b/gcc/testsuite/gcc.target/riscv/attribute-1.c @@ -2,5 +2,20 @

Re: [PATCH] c++: parser cleanup, remove dummy arguments

On 7/31/23 17:52, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Now that cp_parser_constant_expression accepts a null non_constant_p, we can transitively remove dummy arguments in the call chain. Running dg.exp and counting the # of is_rvalue_consta

Re: [PATCH] c++: improve debug_tree for templated types/decls

On 7/31/23 20:34, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- gcc/cp/ChangeLog: * ptree.cc (cxx_print_decl): Check for DECL_LANG_SPECIFIC and TS_DECL_COMMON only when necessary. Print DECL_TEMPLATE_INFO for all decls that h

Re: [PATCH v10 4/5] libstdc++: Use new built-in trait __is_function for std::is_function

On Thu, 13 Jul 2023 at 03:41, Ken Matsui via Libstdc++ < libstd...@gcc.gnu.org> wrote: > This patch gets std::is_function to dispatch to new built-in trait > __is_function. > > libstdc++-v3/ChangeLog: > > * include/std/type_traits (is_function): Use __is_function built-in > trait.

Re: [PATCH v4 4/4] libstdc++: Optimize is_compound trait performance

On Tue, 18 Jul 2023 at 08:44, Ken Matsui via Libstdc++ < libstd...@gcc.gnu.org> wrote: > This patch optimizes the performance of the is_compound trait by > dispatching to the new __is_arithmetic built-in trait. > > libstdc++-v3/ChangeLog: > > * include/std/type_traits (is_compound): Use __

Re: [PATCH 04/14] c++: use _P() defines from tree.h

On 8/2/23 12:51, Patrick Palka via Gcc-patches wrote: On Thu, Jun 1, 2023 at 2:11 PM Bernhard Reutner-Fischer wrote: Hi David, Patrick, On Thu, 1 Jun 2023 18:33:46 +0200 Bernhard Reutner-Fischer wrote: On Thu, 1 Jun 2023 11:24:06 -0400 Patrick Palka wrote: On Sat, May 13, 2023 at 7:26 P

Re: [PATCH v2 2/3] libstdc++: Optimize is_arithmetic performance by __is_arithmetic built-in

On Tue, 8 Aug 2023 at 21:09, Jonathan Wakely wrote: > > > On Sat, 15 Jul 2023 at 05:57, Ken Matsui via Libstdc++ < > libstd...@gcc.gnu.org> wrote: > >> This patch optimizes the performance of the is_arithmetic trait by >> dispatching to the new __is_arithmetic built-in trait. >> >> libstdc++-v3/C

Re: [RFC] c++: extend cold, hot attributes to classes

On 8/3/23 07:07, Javier Martinez via Gcc-patches wrote: Most code is cold. This patch extends support for attribute ((cold)) to C++ Classes, Unions, and Structs (RECORD_TYPES and UNION_TYPES) to benefit from encapsulation - reducing the verbosity of using the attribute where deserved. The ((hot))

Re: [PATCH v2] libstdc++: Define _GLIBCXX_HAS_BUILTIN_TRAIT

On Wed, 19 Jul 2023 at 20:33, Ken Matsui via Libstdc++ < libstd...@gcc.gnu.org> wrote: > This patch defines _GLIBCXX_HAS_BUILTIN_TRAIT macro, which will be used > as a flag to toggle the use of built-in traits in the type_traits header > through _GLIBCXX_NO_BUILTIN_TRAITS macro, without needing to

Re: [PATCH] libstdc++: Define _GLIBCXX_HAS_BUILTIN_TRAIT

On Wed, 19 Jul 2023 at 19:48, Patrick Palka via Libstdc++ < libstd...@gcc.gnu.org> wrote: > On Tue, 18 Jul 2023, Ken Matsui via Libstdc++ wrote: > > > This patch defines _GLIBCXX_HAS_BUILTIN_TRAIT, which will be used as a > > flag to toggle built-in traits in the type_traits header. Through this >

Re: [PATCH v2 3/3] libstdc++: Optimize is_fundamental performance by __is_arithmetic built-in

On Tue, 18 Jul 2023 at 07:25, Ken Matsui via Libstdc++ < libstd...@gcc.gnu.org> wrote: > Hi, > > I took a benchmark for this. > > > https://github.com/ken-matsui/gcc-benches/blob/main/is_fundamental-disjunction.md#mon-jul-17-105937-pm-pdt-2023 > > template > struct is_fundamental > : public std::b

Re: [PATCH v2 3/3] libstdc++: Optimize is_fundamental performance by __is_arithmetic built-in

On Tue, 18 Jul 2023 at 07:28, Ken Matsui via Libstdc++ < libstd...@gcc.gnu.org> wrote: > I will eventually work on disjunction to somehow optimize, but in the > meantime, this might be a better implementation. Of course, my > benchmark could be wrong. > You should use __or_ internally in libstdc+

Re: [PATCH v2 2/3] libstdc++: Optimize is_arithmetic performance by __is_arithmetic built-in

On Sat, 15 Jul 2023 at 05:57, Ken Matsui via Libstdc++ < libstd...@gcc.gnu.org> wrote: > This patch optimizes the performance of the is_arithmetic trait by > dispatching to the new __is_arithmetic built-in trait. > > libstdc++-v3/ChangeLog: > > * include/std/type_traits (is_arithmetic): Us

Re: [PATCH] libstdc++: Use __bool_constant entirely

On Sat, 15 Jul 2023 at 04:02, Ken Matsui via Libstdc++ < libstd...@gcc.gnu.org> wrote: > This patch uses __bool_constant entirely instead of integral_constant > in the type_traits header, specifically for true_type, false_type, > and bool_constant. > > libstdc++-v3/ChangeLog: > > * include

Re: [PATCH v3 1/3] c++, libstdc++: Implement __is_arithmetic built-in trait

On Sat, 22 Jul 2023 at 14:51, François Dumont via Libstdc++ < libstd...@gcc.gnu.org> wrote: > > On 18/07/2023 08:27, Ken Matsui via Libstdc++ wrote: > > This patch implements built-in trait for std::is_arithmetic. > > > > gcc/cp/ChangeLog: > > > > * cp-trait.def: Define __is_arithmetic. > >

Re: [PATCH] c++: Report invalid id-expression in decltype [PR100482]

On 8/7/23 22:48, Nathaniel Shead wrote: Sorry, noticed I provided the wrong version of the test. Here is the correct version (not relying on 'namespace std' being implicitly defined). Bootstrapped + regtested on x86_64-pc-linux-gnu. Pushed, thanks! -- 8< -- This patch ensures that any errors

Re: [RFC] GCC Security policy

On Tue, 8 Aug 2023, David Malcolm via Gcc-patches wrote: > However, consider a situation in which someone attempted to, say, embed > libgccjit inside a web browser to generate machine code from > JavaScript, where the JavaScript is potentially controlled by an > attacker. I think we want to expli

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

On Tue, Aug 08, 2023 at 04:54:46PM +0200, 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 {

Re: Intel AVX10.1 Compiler Design and Support

Do you have any comments on the interaction of AVX10 with the micro-architecture levels defined in the ABI (and supported with glibc-hwcaps directories in glibc)? Given that the levels are cumulative, should we take it that any future levels will be ones supporting 512-bit vector width for AVX

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

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 per previous discussions that libtool commit 3334f7ed5851ef1e96b052f2984c4acdbf39e20c will need reverting

Re: [RFC] GCC Security policy

On 8/8/23 13:46, David Edelsohn wrote: > I believe that upstream projects for components that are imported > into GCC should be responsible for their security policy, including > libgo, gofrontend, libsanitizer (other than local patches), zlib, > libtool, libphobos, libcody, libffi, eventually Rust

Re: [PATCH] c++: follow DR 2386 and update implementation of get_tuple_size [PR110216]

On 8/6/23 14:15, gnaggnoyil wrote: DR 2386 updated the tuple_size requirements for structured binding and it now requires tuple_size to be considered only if std::tuple_size names a complete class type with member value. GCC before this patch does not follow the updated requrements, and this patc

Re: [PATCH] bpf: Fixed GC mistakes in BPF builtins code.

Thanks! Pushed to master. Jose E. Marchesi writes: > Hi Cuper. > > OK. Hopefully all the roots are marked now to avoid these nodes being > collected. > > Thanks. > >> Hi everyone, >> >> This patch fixes BPF CO-RE builtins support that missed information for >> garbage collector (GC). >> >> The

Re: [PATCH][GCC] aarch64: Add support for Cortex-A520 CPU

Richard Ball writes: > This patch adds support for the Cortex-A520 CPU to GCC. > > No regressions on aarch64-none-elf. > > Ok for master? > > > gcc/ChangeLog: > >     * config/aarch64/aarch64-cores.def (AARCH64_CORE): Add > Cortex-A520 CPU. >     * config/aarch64/aarch64-tune.md: Regene

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

On Tue, Aug 8, 2023 at 12:44 AM Richard Biener via Gcc-patches wrote: > > On Tue, Aug 8, 2023 at 2:55 AM Andrew Pinski via Gcc-patches > wrote: > > > > 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

Re: [PATCH] bpf: Fixed GC mistakes in BPF builtins code.

Hi Cuper. OK. Hopefully all the roots are marked now to avoid these nodes being collected. Thanks. > Hi everyone, > > This patch fixes BPF CO-RE builtins support that missed information for > garbage collector (GC). > > The BPF CO-RE implementation defines several data structures that keep >

Re: RV64 Zicond ICE (was Re: [committed][RISC-V]Don't reject constants in cmov condition)

On 8/8/23 11:21, Vineet Gupta wrote: Hi Jeff, On 8/7/23 13:36, Jeff Law wrote: This test is too aggressive.  Constants have VOIDmode, so we need to let the through this phase of conditional move support. Fixes several missed conditional moves with the trunk. Committed to the trunk, As

Re: [RFC] GCC Security policy

On Tue, Aug 8, 2023 at 1:36 PM Ian Lance Taylor wrote: > On Tue, Aug 8, 2023 at 7:37 AM Jakub Jelinek wrote: > > > > BTW, I think we should perhaps differentiate between production ready > > libraries (e.g. libgcc, libstdc++, libgomp, libatomic, libgfortran, > libquadmath, > > libssp) vs. e.g. t

Re: [RFC] GCC Security policy

On Tue, Aug 8, 2023 at 7:37 AM Jakub Jelinek wrote: > > BTW, I think we should perhaps differentiate between production ready > libraries (e.g. libgcc, libstdc++, libgomp, libatomic, libgfortran, > libquadmath, > libssp) vs. e.g. the sanitizer libraries which are meant for debugging and > I belie

[PATCH] bpf: Fixed GC mistakes in BPF builtins code.

Hi everyone, This patch fixes BPF CO-RE builtins support that missed information for garbage collector (GC). The BPF CO-RE implementation defines several data structures that keep builtin information throught all of the compilation flow aside from code. This intentionally avoids having the buil

RV64 Zicond ICE (was Re: [committed][RISC-V]Don't reject constants in cmov condition)

Hi Jeff, On 8/7/23 13:36, Jeff Law wrote: This test is too aggressive.  Constants have VOIDmode, so we need to let the through this phase of conditional move support. Fixes several missed conditional moves with the trunk. Committed to the trunk, As discussed this morning, this triggers an

[committed] i386: Do not sanitize upper part of V2SFmode reg with -fno-trapping-math [PR110832]

Also introduce -m[no-]partial-vector-fp-math option to disable trapping V2SF named patterns in order to avoid generation of partial vector V4SFmode trapping instructions. The new option is enabled by default, because even with sanitization, a small but consistent speed up of 2 to 3% with Polyhedro

Re: [PATCH] Add -Wdisabled-optimization warning for not optimizing sibling calls

On Tue, 2023-08-08 at 08:05 +0200, Richard Biener wrote: > On Mon, Aug 7, 2023 at 9:04 PM Bradley Lucier > wrote: > > > > Thank you for your comments.  I have a few questions. > > > > > I don't think this specific case qualifies for -Wdisabled- > > > optimization. > > > The diagnostic is for cas

Re: [PATCH] rtl-optimization/110587 - speedup find_hard_regno_for_1

On 8/8/23 10:49, Vladimir Makarov wrote: On 8/7/23 09:18, Richard Biener wrote: On Wed, 2 Aug 2023, Richard Biener wrote: On Mon, 31 Jul 2023, Jeff Law wrote: On 7/31/23 04:54, Richard Biener via Gcc-patches wrote: On Tue, 25 Jul 2023, Richard Biener wrote: The following applies a mi

Re: [PATCH] rtl-optimization/110587 - speedup find_hard_regno_for_1

On 8/7/23 09:18, Richard Biener wrote: On Wed, 2 Aug 2023, Richard Biener wrote: On Mon, 31 Jul 2023, Jeff Law wrote: On 7/31/23 04:54, Richard Biener via Gcc-patches wrote: On Tue, 25 Jul 2023, Richard Biener wrote: The following applies a micro-optimization to find_hard_regno_for_1, r

Re: RISC-V: Added support for CRC.

On Tue, 8 Aug 2023, Jeff Law wrote: > That was my thinking at one time. Then we started looking at the distros and > found enough crc implementations in there to change my mind about the overall > utility. The ones I'm familiar with are all table-based and look impossible to pattern-match (and

Re: [RFC] GCC Security policy

> On Aug 8, 2023, at 11:55 AM, Siddhesh Poyarekar wrote: > > On 2023-08-08 11:48, David Malcolm wrote: >> On Tue, 2023-08-08 at 09:33 -0400, Paul Koning via Gcc-patches wrote: >>> >>> On Aug 8, 2023, at 9:01 AM, Jakub Jelinek via Gcc-patches wrote: On Tue, Aug 08, 2023

Re: [RFC] GCC Security policy

On 08/08/2023 15:40, Siddhesh Poyarekar wrote: On 2023-08-08 10:37, Jakub Jelinek wrote: On Tue, Aug 08, 2023 at 10:30:10AM -0400, 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

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

Hello, On Tue, 8 Aug 2023, Martin Uecker via Gcc-patches wrote: > There at least three different size expression which could > make sense. Consider > > short foo { int a; short b; char t[]; };  > > Most people seem to use > > sizeof(struct foo) + N * sizeof(foo->t); > > which for N == 3 yield

Re: [PATCH] RISC-V: Fix error combine of pred_mov pattern

On 8/8/23 05:57, Lehua Ding wrote: Hi, This patch fix PR110943 which will produce some error code. This is because the error combine of some pred_mov pattern. Consider this code: ``` #include void foo9 (void *base, void *out, size_t vl) { int64_t scalar = *(int64_t*)(base + 100);

Re: [RFC] GCC Security policy

On 2023-08-08 11:48, David Malcolm wrote: On Tue, 2023-08-08 at 09:33 -0400, Paul Koning via Gcc-patches wrote: On Aug 8, 2023, at 9:01 AM, Jakub Jelinek via Gcc-patches wrote: On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc- patches wrote: There's probably external tools

Re: [RFC] GCC Security policy

On Tue, 2023-08-08 at 09:33 -0400, Paul Koning via Gcc-patches wrote: > > > > On Aug 8, 2023, at 9:01 AM, Jakub Jelinek via Gcc-patches > > wrote: > > > > On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc- > > patches wrote: > > > There's probably external tools to do this, not s

Re: RISC-V: Added support for CRC.

On 8/8/23 09:22, Alexander Monakov wrote: Jeff, as I understand this all is happening only because Coremark contains use of bitwise CRC that affects benchmark scores. In another universe where - Coremark was careful to checksum outputs outside of timed sections, or - implemented CRC in a man

Re: RISC-V: Added support for CRC.

On Thu, 3 Aug 2023, Jeff Law wrote: > The end goal here is to actually detect bitwise CRC implementations in the > gimple optimizers and turn them into table lookups or carryless multiplies in > RTL. > > Mariam has that working end-to-end and has proposed a talk for the Cauldron on > the topic.

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

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. 2023-08-08 Christophe Lyon gcc/testsuite/ PR analyzer/110426 * gcc

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

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 a; short b; char t[]; };  Most people seem to use sizeof(struct foo) + N

Re: [RFC] GCC Security policy

On 2023-08-08 10:37, Jakub Jelinek wrote: On Tue, Aug 08, 2023 at 10:30:10AM -0400, 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. BTW, I think we should perh

Re: [RFC] GCC Security policy

On Tue, Aug 08, 2023 at 10:30:10AM -0400, 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. BTW, I think we should perhaps differentiate between productio

Re: [RFC] GCC Security policy

On 2023-08-08 10:14, David Edelsohn wrote: On Tue, Aug 8, 2023 at 10:07 AM Siddhesh Poyarekar > wrote: On 2023-08-08 10:04, Richard Biener wrote: > On Tue, Aug 8, 2023 at 3:35 PM Ian Lance Taylor mailto:i...@google.com>> wrote: >> >> On Tue, Aug 8,

Re: [committed][RISC-V]Don't reject constants in cmov condition

On 8/7/23 17:42, Vineet Gupta wrote: On 8/7/23 13:36, Jeff Law wrote: Fixes several missed conditional moves with the trunk. I'm curious, how do you know what's missing. Does ifc have some stats like autovec which explicitly reports missed opportunities ? Xiao's testcases :-) I haven't

RE: [PATCH v1] RISC-V: Enhance the test case for RVV vfsub/vfrsub rounding

Committed, thanks Jeff. Pan -Original Message- From: Jeff Law Sent: Tuesday, August 8, 2023 10:10 PM To: Li, Pan2 ; gcc-patches@gcc.gnu.org Cc: juzhe.zh...@rivai.ai; kito.ch...@sifive.com; Wang, Yanzhang Subject: Re: [PATCH v1] RISC-V: Enhance the test case for RVV vfsub/vfrsub round

Re: [PATCH] vect: Add a popcount fallback.

> Presumably this is an alternative to the approach Juzhe posted a week > or two ago and ultimately dropped? Yeah, I figured having a generic fallback could help more targets. We can still have a better expander if we see the need. Regards Robin

Re: [PATCH] vect: Add a popcount fallback.

On 8/8/23 02:55, Robin Dapp via Gcc-patches wrote: Looks reasonable to me - I couldn't read from above whether you did testing on riscv and thus verified the runtime correctness of the fallback? If not may I suggest to force matching the pattern on a target you can test for this purpose? I t

Re: [RFC] GCC Security policy

On Tue, Aug 8, 2023 at 10:07 AM Siddhesh Poyarekar wrote: > On 2023-08-08 10:04, Richard Biener wrote: > > On Tue, Aug 8, 2023 at 3:35 PM Ian Lance Taylor wrote: > >> > >> On Tue, Aug 8, 2023 at 6:02 AM Jakub Jelinek via Gcc-patches > >> wrote: > >>> > >>> On Tue, Aug 08, 2023 at 02:52:57PM +02

Re: [PATCH v1] RISC-V: Enhance the test case for RVV vfsub/vfrsub rounding

On 8/2/23 01:59, Pan Li via Gcc-patches wrote: From: Pan Li This patch would like to enhance the vfsub/vfrsub rounding API test for below 2 purposes. * The non-rm API has no frm related insn generated. * The rm API has the frm backup/restore/set insn generated. Signed-off-by: Pan Li gcc/

Re: [RFC] GCC Security policy

On 2023-08-08 10:04, Richard Biener wrote: On Tue, Aug 8, 2023 at 3:35 PM Ian Lance Taylor wrote: On Tue, Aug 8, 2023 at 6:02 AM Jakub Jelinek via Gcc-patches wrote: On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc-patches wrote: There's probably external tools to do this,

Re: [RFC] GCC Security policy

On Tue, Aug 8, 2023 at 3:35 PM Ian Lance Taylor wrote: > > On Tue, Aug 8, 2023 at 6:02 AM Jakub Jelinek via Gcc-patches > wrote: > > > > On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc-patches > > wrote: > > > There's probably external tools to do this, not sure if we should >

Re: Re: [PATCH] RISC-V: Allow CONST_VECTOR for VLS modes.

>> Looks like just a line-break change and the line is not too long? Yes. >> This seems a bit inconsistent from a caller's perspective >> as we also do emit_insn (gen_vec_series, ...) without extra move >> at another spot. Can we handle this directly in expand_vec_series? I'am not sure. I change

  1   2   >