[COMMITTED] xtensa: Improve bswap[sd]i2 insn patterns

From: Takayuki 'January June' Suwa This patch makes bswap[sd]i2 better register allocation, and reconstructs bswapsi2 in order to take advantage of GIMPLE manual byte-swapping recognition. gcc/ChangeLog: * config/xtensa/xtensa.md (bswapsi2): New expansion pattern.

Re: [PATCH v3 4/5] xtensa: Add setmemsi insn pattern

On Mon, May 23, 2022 at 8:52 AM Takayuki 'January June' Suwa wrote: > > This patch introduces setmemsi insn pattern of two kinds, unrolled loop and > small loop, for fixed small length and constant initialization value. > > gcc/ChangeLog: > > * gcc/config/xtensa/xtensa-protos.h >

Re: [PATCH v3 4/5] xtensa: Add setmemsi insn pattern

On Thu, May 26, 2022 at 8:00 PM Takayuki 'January June' Suwa wrote: > > On 2022/05/27 1:57, Max Filippov wrote: > > is that something that can be addressed in this patch? > > seems hard to resolve, because the RTL-generation pass passes only 68 > bytes in that case: ... > this behavior does not

Re: [PATCH v3 4/5] xtensa: Add setmemsi insn pattern

On 2022/05/27 1:57, Max Filippov wrote: is that something that can be addressed in this patch? seems hard to resolve, because the RTL-generation pass passes only 68 bytes in that case: void f(char *p); void g(void) { char c[72] = {0}; f(c); } without this patch, we would

[PATCH v3] RISC-V/testsuite: constraint some of tests to hard_float

Commit 9ddd44b58649d1d ("RISC-V: Provide `fmin'/`fmax' RTL pattern") added tests which check for hard float instructions which obviously fails on soft-float ABI builds. And my recent commit b646d7d279ae ("RISC-V: Inhibit FP <--> int register moves via tune param") is guilty of same crime. So

[PATCH v2] RISC-V/testsuite: constraint some of tests to hard_float

Commit 9ddd44b58649d1d ("RISC-V: Provide `fmin'/`fmax' RTL pattern") added tests which check for hard float instructions which obviously fails on soft-float ABI builds. So constraint with "dg-require-effective-target hard_float" This reduces bunch of new RV failures on trunk since that commit.

[PATCH] RISC-V/testsuite: constraint some of tests to hard_float

From: Vineet Gupta Commit 9ddd44b58649d1d ("RISC-V: Provide `fmin'/`fmax' RTL pattern") added tests which check for hard float instructions which obviously fails on soft-float ABI builds. So constraint with "dg-require-effective-target hard_float" This reduces bunch of new RV failures on trunk

[PATCH] c-family: fix attribute constructor ICE [PR90658]

Here the C compiler crashes because a FUNCTION_DECL got into get_priority -> default_conversion, and the C FE's version of d_c specifically asserts that it doesn't get a FUNCTION_DECL. All uses of default_conversion in c-attribs.cc are guarded by != IDENTIFIER_NODE && != FUNCTION_DECL, but

[PATCH] c++: Add !TYPE_P assert to type_dependent_expression_p [PR99080]

As discussed here: , type_dependent_expression_p should not be called with a type argument. I promised I'd add an assert so here it is. One place needed adjusting, the comment explains why. Bootstrapped/regtested on

[PATCH] libgompd: Add ompd_get/rel_display_control_vars

libgomp/ChangeLog 2022-05-27 Mohamed Atef * libgompd.map (ompd_get_display_control_vars, ompd_rel_display_control_vars): New global symbol versions. * env.c: (gompd_buffer, gompd_env_buff_size): New Variables. (dump_icvs): New function. (initialize_env): call dump_icvs. * ompd-icv.c:

Re: [PATCH] c++: cv-quals of dummy obj for non-dep memfn call [PR105637]

On Thu, 26 May 2022, Jason Merrill wrote: > On 5/26/22 14:57, Patrick Palka wrote: > > On Thu, 26 May 2022, Patrick Palka wrote: > > > > > Here we expect the calls to BaseClass::baseDevice resolve to the second, > > > third and fourth overloads respectively in light of the cv-qualifiers > > > of

[committed] libstdc++: Fix narrowing conversions for 16-bit size_t [PR105681]

Tested x86_64-linux, bootstrapped msp430-elf, pushed to trunk. -- >8 -- On a 16-bit target such as msp430 we get errors about narrowing long values to size_t, which is only 16-bit. When --enable-libstdcxx-pch is used the header breaks the build because of these narrowing errors.

[committed] libstdc++: Fix atomic and error_code printers for versioned namespace

Tested x86_64-linux, pushed to trunk. -- >8 -- This fixes the printers to work with std::__8::atomic and std::__v8::ios_errc and std::__v8::future_errc. libstdc++-v3/ChangeLog: * python/libstdcxx/v6/printers.py (StdErrorCodePrinter): Make lookup for ios_errc and future_errc

[committed] libstdc++: Move std::iostream_category() definition to new file

Tested x86_64-linux, pushed to trunk. -- >8 -- This fixes a missing symbol when the dual ABI is disabled, e.g. for the versioned namespace build. libstdc++-v3/ChangeLog: * src/c++11/Makefile.am: Add new source file. * src/c++11/Makefile.in: Regenerate. *

Re: [PATCH] Add a bit dislike for separate mem alternative when op is REG_P.

On 2022-05-24 23:39, liuhongt wrote: Rigt now, mem_cost for separate mem alternative is 1 * frequency which is pretty small and caused the unnecessary SSE spill in the PR, I've tried to rework backend cost model, but RA still not happy with that(regress somewhere else). I think the root cause

[PATCH v3] DSE: Use the constant store source if possible

On Thu, May 26, 2022 at 04:14:17PM +0100, Richard Sandiford wrote: > "H.J. Lu" writes: > > On Wed, May 25, 2022 at 12:30 AM Richard Sandiford > > wrote: > >> > >> "H.J. Lu via Gcc-patches" writes: > >> > On Mon, May 23, 2022 at 12:38:06PM +0200, Richard Biener wrote: > >> >> On Sat, May 21,

Re: [PATCH] c++: cv-quals of dummy obj for non-dep memfn call [PR105637]

On 5/26/22 14:57, Patrick Palka wrote: On Thu, 26 May 2022, Patrick Palka wrote: Here we expect the calls to BaseClass::baseDevice resolve to the second, third and fourth overloads respectively in light of the cv-qualifiers of 'this' in each case. But ever since r12-6075-g2decd2cabe5a4f, the

Re: [PATCH v2] c++: suppress -Waddress warnings with *_cast [PR105569]

On 5/26/22 09:33, Marek Polacek wrote: On Thu, May 26, 2022 at 09:26:16AM -0400, Jason Merrill wrote: On 5/25/22 16:25, Marek Polacek wrote: On Wed, May 18, 2022 at 09:43:47AM -0400, Jason Merrill wrote: On 5/16/22 13:06, Marek Polacek wrote: dynamic_cast can legally return nullptr, so I

Re: [PATCH, rs6000] Clean up the option_mask defines (part 1)

On Thu, 2022-05-26 at 13:31 -0500, Segher Boessenkool wrote: > > > > On Thu, May 26, 2022 at 09:40:18AM -0500, will schmidt wrote: > > On Thu, 2022-05-26 at 05:47 -0500, Segher Boessenkool wrote: > > > I'll dig a bit more, but would handle that in a separate > > patch. > > Can you please

Re: [x86 PATCH] Pre-reload splitter to transform and; cmp into not; test.

On Thu, May 26, 2022 at 8:41 PM Roger Sayle wrote: > > > A common idiom for testing if a specific set of bits is set in a value > is to use "(X & Y) == Y", which on x86 results in an AND followed by a > CMP. A slightly improved implementation is to instead use (~X & Y)==0, > that uses a NOT and

Re: [PATCH] c++: cv-quals of dummy obj for non-dep memfn call [PR105637]

On Thu, 26 May 2022, Patrick Palka wrote: > Here we expect the calls to BaseClass::baseDevice resolve to the second, > third and fourth overloads respectively in light of the cv-qualifiers > of 'this' in each case. But ever since r12-6075-g2decd2cabe5a4f, the > calls incorrectly resolve to the

[x86 PATCH] Pre-reload splitter to transform and;cmp into not;test.

A common idiom for testing if a specific set of bits is set in a value is to use "(X & Y) == Y", which on x86 results in an AND followed by a CMP. A slightly improved implementation is to instead use (~X & Y)==0, that uses a NOT and a TEST (or ANDN where available); still two "fast"

[PATCH] c++: cv-quals of dummy obj for non-dep memfn call [PR105637]

Here we expect the calls to BaseClass::baseDevice resolve to the second, third and fourth overloads respectively in light of the cv-qualifiers of 'this' in each case. But ever since r12-6075-g2decd2cabe5a4f, the calls incorrectly resolve to the first overload at instantiation time. This happens

Re: [PATCH, rs6000] Clean up the option_mask defines (part 1)

On Thu, May 26, 2022 at 09:40:18AM -0500, will schmidt wrote: > On Thu, 2022-05-26 at 05:47 -0500, Segher Boessenkool wrote: > > Yeah, the longer names are a bit annoying in any case. We'll get > > used > > to it (if those long lines are fixed ;-) ) > > Agree. I would not be opposed to somewhat

Re: [PATCH v4, rs6000] Add V1TI into vector comparison expand [PR103316]

On Thu, May 26, 2022 at 09:16:59AM -0400, David Edelsohn wrote: > Does Power10 fully support int128 in 32 bit mode? I would expect no, > so the additional test is required. It isn't supported on any 32-bit ABI, Power or not. It would simplify many things if it was though! Segher

Re: [PATCH 5/5] xtensa: Improve bswap[sd]i2 insn patterns

On Fri, May 13, 2022 at 6:35 AM Takayuki 'January June' Suwa wrote: > > This patch makes bswap[sd]i2 better register allocation, and reconstructs > bswapsi2 in order to take advantage of GIMPLE manual byte-swapping > recognition. > > gcc/ChangeLog: > > * gcc/config/xtensa/xtensa.md

Re: [PATCH v3 4/5] xtensa: Add setmemsi insn pattern

On Mon, May 23, 2022 at 8:52 AM Takayuki 'January June' Suwa wrote: > > This patch introduces setmemsi insn pattern of two kinds, unrolled loop and > small loop, for fixed small length and constant initialization value. > > gcc/ChangeLog: > > * gcc/config/xtensa/xtensa-protos.h >

Re: [PATCH 3/5] xtensa: Fix instruction counting regarding block move expansion

On Fri, May 13, 2022 at 6:35 AM Takayuki 'January June' Suwa wrote: > > This patch makes counting the number of instructions of the remainder > (modulo 4) part more accurate. > > gcc/ChangeLog: > > * gcc/config/xtensa/xtensa.cc (xtensa_expand_block_move): > Make instruction

Re: [PATCH 2/5] xtensa: Make use of IN_RANGE macro where appropriate

On Fri, May 13, 2022 at 6:35 AM Takayuki 'January June' Suwa wrote: > > No functional changes. > > gcc/ChangeLog: > > * gcc/config/xtensa/constraints.md (M, O): Use the macro. > * gcc/config/xtensa/predicates.md (addsubx_operand, > extui_fldsz_operand, >

Re: [PATCH 1/5] xtensa: Simplify EXTUI instruction maskimm validations

On Fri, May 13, 2022 at 6:35 AM Takayuki 'January June' Suwa wrote: > > No functional changes. > > gcc/ChangeLog: > > * gcc/config/xtensa/predicates.md (extui_fldsz_operand): Simplify. > * gcc/config/xtensa/xtensa.cc (xtensa_mask_immediate, print_operand): > Ditto. > --- >

[committed] libstdc++: Add constexpr to std::counted_iterator post-increment (LWG 3643)

Tested powerpc64le-linux, pushed to trunk. This can be backported to 11 and 12 too. -- >8 -- libstdc++-v3/ChangeLog: * include/bits/stl_iterator.h (counted_iterator::operator++(int)): Add 'constexpr' as per LWG 3643. * testsuite/24_iterators/counted_iterator/lwg3643.cc:

Re: [PATCH] AArch64: Cleanup option processing code

Wilco Dijkstra writes: > Further cleanup option processing. Remove the duplication of global > variables for CPU and tune settings so that CPU option processing is > simplified even further. Move global variables that need save and > restore due to target option processing into aarch64.opt. This

Re: [PATCH V4 2/3] RISC-V:Cache Management Operation instructions

Hi Simon: Good catch, those cache operations should take an address operand. On Thu, May 26, 2022 at 7:58 PM Simon Cook wrote: > > Hi, > > I've just tried using these builtins now these have landed in trunk, and > I have a question about the cbo builtins. > > Looking at the code being

Re: [PATCH v2] DSE: Use the constant store source if possible

"H.J. Lu" writes: > On Wed, May 25, 2022 at 12:30 AM Richard Sandiford > wrote: >> >> "H.J. Lu via Gcc-patches" writes: >> > On Mon, May 23, 2022 at 12:38:06PM +0200, Richard Biener wrote: >> >> On Sat, May 21, 2022 at 5:02 AM H.J. Lu via Gcc-patches >> >> wrote: >> >> > >> >> > When recording

[PATCH] c++: fix broken copy elision with nested TARGET_EXPRs [PR105550]

In this problem, we are failing to properly perform copy elision with a conditional operator, so this: constexpr A a = true ? A{} : A{}; fails with: error: 'A{((const A*)(&))}' is not a constant expression The whole initializer is TARGET_EXPR }> : TARGET_EXPR }>> where the outermost

[PATCH] ipa: Check cst type when propagating controled uses info (PR 105639)

Hi, PR 105639 shows that code with type-mismatches can trigger an assert after runnning into a branch that was inteded only for references to variables - as opposed to references to functions. Fixed by moving the condition from the assert to the guarding if statement. Bootstrapped and tested on

Re: [PATCH, rs6000] Clean up the option_mask defines (part 1)

On Thu, 2022-05-26 at 05:47 -0500, Segher Boessenkool wrote: > Hi! > Hi, Thanks Kewen and Segher for the reviews. Additional comments below. > On Thu, May 26, 2022 at 03:01:37PM +0800, Kewen.Lin wrote: > > on 2022/5/26 14:12, Kewen.Lin via Gcc-patches wrote: > > > on 2022/5/26 04:25, will

[PATCH] Mips: Enable asynchronous unwind tables with both ASAN and LSAN

Enable asynchronous unwind tables with both ASAN and TSAN for correct back-trace. LLVM currently enables asynchronous unwind tables for: ASAN, HWSAN, TSAN, MSAN, and DFSAN. HWSAN is currently available only on AArch64, while MSAN and DFSAN are not available at all. Also, LLVM checks is

Re: [PATCH v2] c++: suppress -Waddress warnings with *_cast [PR105569]

On Thu, May 26, 2022 at 09:26:16AM -0400, Jason Merrill wrote: > On 5/25/22 16:25, Marek Polacek wrote: > > On Wed, May 18, 2022 at 09:43:47AM -0400, Jason Merrill wrote: > > > On 5/16/22 13:06, Marek Polacek wrote: > > > > dynamic_cast can legally return nullptr, so I don't think it's helpful > >

Re: [PATCH v2] c++: suppress -Waddress warnings with *_cast [PR105569]

On 5/25/22 16:25, Marek Polacek wrote: On Wed, May 18, 2022 at 09:43:47AM -0400, Jason Merrill wrote: On 5/16/22 13:06, Marek Polacek wrote: dynamic_cast can legally return nullptr, so I don't think it's helpful for -Waddress to warn for if (dynamic_cast()) // ... More generally,

Re: [PATCH] c++: constrained partial spec forward decl [PR96363]

On 5/25/22 13:24, Patrick Palka wrote: Here during cp_parser_single_declaration for #2, we were calling associate_classtype_constraints for TPL (the primary template type) before maybe_process_partial_specialization could get a chance to notice that we're in fact declaring a distinct constrained

Re: [PATCH v4, rs6000] Add V1TI into vector comparison expand [PR103316]

On Thu, May 26, 2022 at 1:52 AM Kewen.Lin wrote: > > Hi Haochen, > > on 2022/5/26 13:30, HAO CHEN GUI wrote: > > Kewen, > > Thanks so much for your advice. Just one question about effective-target. > > > > For the test cases, it needs both power10_ok and int128 support. I saw > > some > >

[committed 3/3] libstdc++: Refactor includes for unordered containers

Tested powerpc64le-linux, pushed to trunk. -- >8 -- This moves some #include directives to the relevant place. For example, needs so should include it directly instead of relying on and to do so first. libstdc++-v3/ChangeLog: * include/bits/functional_hash.h (__is_fast_hash): Add

[committed 1/3] libstdc++: Make headers include their prerequisites

From: Nathan Sidwell Tested powerpc64le-linux, pushed to trunk. -- >8 -- These headers were relying on their includers having already included some prerequisites. That makes them unsuitable to be header-units. So directly include the needed headers. Reviewed-by: Jonathan Wakely

[committed 2/3] libstdc++: Remove some unnecessary includes

Tested powerpc64le-linux, pushed to trunk. -- >8 -- These headers do not use anything in directly, and it's included by and anyway, because they do need it. libstdc++-v3/ChangeLog: * include/bits/ranges_algobase.h: Do not include . * include/std/string: Likewise.

Re: [PATCH V4 2/3] RISC-V:Cache Management Operation instructions

Hi, I've just tried using these builtins now these have landed in trunk, and I have a question about the cbo builtins. Looking at the code being generated it looks like these builtins return an int and take no arguments, but reading the instructions these should instead take an int and

Re: [PATCH, rs6000] Clean up the option_mask defines (part 1)

Hi! On Thu, May 26, 2022 at 03:01:37PM +0800, Kewen.Lin wrote: > on 2022/5/26 14:12, Kewen.Lin via Gcc-patches wrote: > > on 2022/5/26 04:25, will schmidt via Gcc-patches wrote: > >> We have an assortment of MASK and OPTION_MASK #defines throughout > >> the rs6000 code, MASK_ALTIVEC and

Re: [PATCH][_GLIBCXX_INLINE_VERSION] Fix std::span pretty printer

On Thu, 26 May 2022 at 00:38, Jonathan Wakely wrote: > > On Thu, 26 May 2022 at 00:34, Jonathan Wakely wrote: > > > > On Wed, 25 May 2022 at 21:29, François Dumont via Libstdc++ > > wrote: > > > > > > Hi > > > > > > Here is a patch to fix std::span pretty printer in versioned > > >

[committed 1/2] libstdc++: Remove redundancy in test pathnames

Tested x86_64-linux, pushed to trunk. -- >8 -- Repeating "explicit_instantiation" in these long pathnames is not necessary. libstdc++-v3/ChangeLog: * testsuite/20_util/duration/requirements/explicit_instantiation/explicit_instantiation.cc: Moved to... *

[committed 2/2] libstdc++: Rename tests like .../wchar_t/1.cc to .../wchar_t.cc

Tested x86_64-linux, pushed to trunk. -- >8 -- There's no need to have directories containing a single test file, we can rename the files to the directory names and remove the directories. The dejagnu proc that filters out wchar_t tests just checks for "wchar_t" anywhere in the path, so will

[PATCH v2, rs6000] Fix ICE on expand bcd__ [PR100736]

Hi, This patch fixes the ICE reported in PR100736. It removes the condition check of finite math only flag not setting in "*_cc" pattern. With or without this flag, we still can use "cror" to check if either two bits of CC is set or not for "fp_two" codes. We don't need a reverse comparison

Re: [ping2][PATCH 0/8][RFC] Support BTF decl_tag and type_tag annotations

On 5/24/22 10:04 AM, David Faust wrote: On 5/24/22 09:03, Yonghong Song wrote: On 5/24/22 8:53 AM, David Faust wrote: On 5/24/22 04:07, Jose E. Marchesi wrote: On 5/11/22 11:44 AM, David Faust wrote: On 5/10/22 22:05, Yonghong Song wrote: On 5/10/22 8:43 PM, Yonghong Song

[PATCH 3/3][ARM] STAR-MC1 CPU Support - docs: Add star-mc1 core

Hi, This is the patch to add star-mc1 in the Arm -mtune and -mfix-cmse-cve-2021-35465 sections of gcc invoke.texi documentation. Is it OK for trunk? Regards, jasonwucjFrom b3bd24d842b6284f2b893caa658975d9d746be73 Mon Sep 17 00:00:00 2001 From: Chung-Ju Wu Date: Thu, 26 May 2022 05:15:13 +

[PATCH 2/3][ARM] STAR-MC1 CPU Support - arm: Add individual star-mc1 cost tables and cost functions

Hi, Attached is the patch to provide star-mc1 specific cost functions and tables. Given these individual implementation, developers are able to make their own adjustment to fine-tune star-mc1 performance without affecting other cpu configurations. Bootstrapped and tested on arm-none-eabi. Is

[PATCH 1/3][ARM] STAR-MC1 CPU Support - arm: Add star-mc1 core

Hi, STAR-MC1 is an embedded processor with armv8m architecture. Majorly it is designed to meet the requirements of AIoT application performance, power consumption and security. Early this month, star-mc1 is supported by the latest releases of MDK and CMSIS. For the completeness of Arm ecosystem,

Re: [PATCH, rs6000] Clean up the option_mask defines (part 1)

on 2022/5/26 14:12, Kewen.Lin via Gcc-patches wrote: > Hi Will, > > on 2022/5/26 04:25, will schmidt via Gcc-patches wrote: >> [PATCH, rs6000] Clean up the option_mask defines >> >> Hi, >> >> We have an assortment of MASK and OPTION_MASK #defines throughout >> the rs6000 code, MASK_ALTIVEC

Re: [PATCH] RISC-V: Don't unconditionally add m, a, f, d in arch-canonicalize

Back ported to releases/gcc-11 and releases/gcc-12 branch :) On Thu, May 26, 2022 at 5:33 AM Palmer Dabbelt wrote: > > On Wed, 25 May 2022 07:00:11 PDT (-0700), gcc-patches@gcc.gnu.org wrote: > > Committed, Thanks for fixing my stupid bug :P > > IMO this is a good candidate for a backport. > > >

Re: [PATCH, rs6000] Clean up the option_mask defines (part 1)

Hi Will, on 2022/5/26 04:25, will schmidt via Gcc-patches wrote: > [PATCH, rs6000] Clean up the option_mask defines > > Hi, > > We have an assortment of MASK and OPTION_MASK #defines throughout > the rs6000 code, MASK_ALTIVEC and OPTION_MASK_ALTIVEC as an example. > > We currently #define

Re: [PATCH] RISC-V: Add -mtune=thead-c906 to the invoke docs

LGTM, thanks :) On Thu, May 26, 2022 at 10:31 AM Palmer Dabbelt wrote: > > gcc/ChangeLog > > * doc/invoke.texi (RISC-V): Document -mtune=thead-c906. > > Signed-off-by: Palmer Dabbelt > --- > gcc/doc/invoke.texi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git