[PATCH v3] RISC-V: Implement .SAT_TRUNC for vector unsigned int

From: Pan Li This patch would like to implement the .SAT_TRUNC for the RISC-V backend. With the help of the RVV Vector Narrowing Fixed-Point Clip Instructions. The below SEW(S) are supported: * e64 => e32 * e64 => e16 * e64 => e8 * e32 => e16 * e32 => e8 * e16 => e8 Take below example to see

Re: [PATCH v8 09/12] Delay caller error reporting for musttail

On Sat, Jul 6, 2024 at 7:08 PM Andi Kleen wrote: > > On Fri, Jul 05, 2024 at 01:45:17PM +0200, Richard Biener wrote: > > On Sat, Jun 22, 2024 at 9:00 PM Andi Kleen wrote: > > > > > > Move the error reporting for caller attributes to be > > > after the tail call discovery, so that we can give prop

Re: [PATCH v8 07/12] Enable musttail tail conversion even when not optimizing

On Sat, Jul 6, 2024 at 6:07 PM Andi Kleen wrote: > > > > +class pass_musttail : public gimple_opt_pass > > > +{ > > > +public: > > > + pass_musttail (gcc::context *ctxt) > > > +: gimple_opt_pass (pass_data_musttail, ctxt) > > > + {} > > > + > > > + /* opt_pass methods: */ > > > + /* This p

Re: [PATCH] rs6000: Remove vcond{,u} expanders

On Mon, Jul 8, 2024 at 8:24 AM Kewen.Lin wrote: > > Hi, > > As PR114189 shows, middle-end will obsolete vcond, vcondu > and vcondeq optabs soon. This patch is to remove all > vcond{,u} expanders in rs6000 port and adjust the function > rs6000_emit_vector_cond_expr which is called by those > expan

[PATCH] rs6000: Remove vcond{,u} expanders

Hi, As PR114189 shows, middle-end will obsolete vcond, vcondu and vcondeq optabs soon. This patch is to remove all vcond{,u} expanders in rs6000 port and adjust the function rs6000_emit_vector_cond_expr which is called by those expanders as static. Bootstrapped and regtested on powerpc64-linux-g

Re: Support bitwise and/andnot/abs/neg/copysign/xorsign op for V8BF/V16BF/V32BF

On Thu, Jul 4, 2024 at 11:24 AM Levy Hsu wrote: > > This patch extends support for BF16 vector operations in GCC, including > bitwise AND, ANDNOT, ABS, NEG, COPYSIGN, and XORSIGN for V8BF, V16BF, and > V32BF modes. > Bootstrapped and tested on x86_64-linux-gnu. ok for trunk? > > gcc/ChangeLog: >

Re: [PATCH v2] RISC-V: Implement .SAT_TRUNC for vector unsigned int

+ if (double_mode == E_VOIDmode && quad_mode == E_VOIDmode) Why we have VOID mode ? I still don't understand the codes. juzhe.zh...@rivai.ai From: pan2.li Date: 2024-07-08 12:48 To: gcc-patches CC: juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; Pan Li Subject: [PATCH v2] RISC-V: Implement .S

Re: Re: [PATCH 0/2] fix RISC-V zcmp popretz [PR113715]

On 2024-07-07 22:53  Jeff Law wrote: > > > >On 6/8/24 2:36 PM, Jeff Law wrote: >> >> >> On 6/5/24 8:42 PM, Fei Gao wrote: >> But let's back up and get a good explanation of what the problem is. Based on patch 2/2 it looks like we have lost an assignment to the return register.

[PATCH] Rename __{float, double}_u to __x86_{float, double}_u to avoid pulluting the namespace.

I have a build failure on NetBSD as the namespace pollution avoidance causes a direct hit with the system /usr/include/math.h === In file included from /usr/src/local/gcc/obj/gcc/include/emmintrin.h:31, from /usr

Re: Re: [PATCH 2/2] [RISC-V] c implies zca, and conditionally zcf & zcd

On 2024-07-06 22:15  Jeff Law wrote: > > > >On 7/5/24 3:56 AM, Fei Gao wrote: >> According to Zc-1.0.4-3.pdf from >> https://github.com/riscvarchive/riscv-code-size-reduction/releases/tag/v1.0.4-3 >> The rule is that: >> 1. C always implies Zca >> 2. C+F implies Zcf (RV32 only) >> 3. C+D implies Z

[PATCH v2] RISC-V: Implement .SAT_TRUNC for vector unsigned int

From: Pan Li This patch would like to implement the .SAT_TRUNC for the RISC-V backend. With the help of the RVV Vector Narrowing Fixed-Point Clip Instructions. The below SEW(S) are supported: * e64 => e32 * e64 => e16 * e64 => e8 * e32 => e16 * e32 => e8 * e16 => e8 Take below example to see

[PATCH] c++/modules: Keep entity mapping info across duplicate_decls [PR99241]

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/14? -- >8 -- When duplicate_decls finds a match with an existing imported declaration, it clears DECL_LANG_SPECIFIC of the olddecl and replaces it with the contents of newdecl; this clears DECL_MODULE_ENTITY_P causing an ICE if the s

Re: [PATCH V2] x86: Update branch hint for Redwood Cove.

On Thu, Jul 4, 2024 at 9:30 AM liuhongt wrote: > > From: "H.J. Lu" > > >The above reads like it would be worth splitting branc_prediction_hits > >into branch_prediction_hints_taken and branch_prediction_hints_not_taken > >given not-taken is the default and thus will just increase code size? > >Ac

Re: [PATCH] Fix MinGW option -mcrtdll=

On 7/5/24 09:53, Pali Rohár wrote: On Monday 24 June 2024 10:03:26 Jonathan Yong wrote: On 6/23/24 16:40, Pali Rohár wrote: Add missing msvcr40* and msvcrtd* cases to CPP_SPEC and document missing _UCRT macro and msvcr71* case. Fixes commit 453cb585f0f8673a5d69d1b420ffd4b3f53aca00. Thanks, pu

[PING^0][Patch, rs6000, middle-end] v6: Add implementation for different targets for pair mem fusion

Ping ! Please let me know OK for trunk. Thanks & Regards Ajit Forwarded Message Subject: [Patch, rs6000, middle-end] v6: Add implementation for different targets for pair mem fusion Date: Tue, 2 Jul 2024 14:15:02 +0530 From: Ajit Agarwal To: Alex Coplan , Richard Sandiford ,

Re: [PATCH v1] RISC-V: Implement .SAT_TRUNC for vector unsigned int

+/* Expand the standard name ustrunc2 for vector mode, we can leverage + the vector fixed point vector narrowing fixed-point clip directly. */ + +void +expand_vec_ustrunc (rtx op_0, rtx op_1, machine_mode vec_mode, + machine_mode double_mode, machine_mode quad_mode) +{ + insn_code icode; +

Re: [x86 SSE PATCH] Some AVX512 ternlog expansion refinements.

On Sun, Jul 7, 2024 at 5:00 PM Roger Sayle wrote: > > > Hi Hongtao, > This should address concerns about the remaining use of force_reg. > 51@@ -25793,15 +25792,20 @@ ix86_expand_ternlog_binop (enum rtx_code code, machine_mode mode, 52 if (GET_MODE (op1) != mode) 53 op1 = gen_lowpart (mod

Ping^3: [PATCH 0/3] Recover in-tree libiconv build support

Arsen Arsenović writes: > Another gentle ping on this patch series. Could it be merged into > trunk? And another! Sorry about them being sparse - I was quite busy in the meanwhile. -- Arsen Arsenović signature.asc Description: PGP signature

Re: [PATCH v2 01/12] OpenMP: metadirective tree data structures and front-end interfaces

On 5/31/24 06:22, Tobias Burnus wrote: I have to admit that I don't really see the use of metadirective_p as …   int -omp_context_selector_matches (tree ctx) +omp_context_selector_matches (tree ctx, bool metadirective_p, bool delay_p) ... +    if (metadirective_p && delay_p) +   

[pushed] libstdc++: Tweak two links in configuration docs

Business as usual; pushed. Gerald libstdc++-v3: * doc/xml/manual/configure.xml: Update Autobook 14 link. Update GCC installation instructions link. * doc/html/manual/configure.html: Regenerate. --- libstdc++-v3/doc/html/manual/configure.html | 4 ++-- libstdc++-v3/doc/xm

[pushed] wwwdocs: readings: Update Edsger W. Dijkstra's home page

--- htdocs/readings.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/readings.html b/htdocs/readings.html index ae1b52bb..f0d44d6f 100644 --- a/htdocs/readings.html +++ b/htdocs/readings.html @@ -469,7 +469,7 @@ names. Historical material - for your enjoyment.

[pushed] maintainer-scripts: Switch bug reporting URL to https

So, this required quite some detective work to understand why https://gcc.gnu.org/onlinedocs/gcc/Bug-Reporting.html still referred to http://gcc.gnu.org/bugs/ *without* https from the following makeinfo snippet Bugs should be reported to the bug database at @value{BUGURL}. in gcc/doc/bugre

[pushed] doc: Remove dubious example around bug reporting

Really, that's probably something from some old compilers in the 90s; no point in confusing people with such history as interesting as it may be. Gerald gcc: * doc/bugreport.texi (Bug Criteria): Remove dubious example. --- gcc/doc/bugreport.texi | 5 - 1 file changed, 5 deletions(-

[pushed] wwwdocs: news: Standardize OpenMP references

Use OpenMP X.Y instead of OpenMP vX.Y. Use https for web links. --- htdocs/news.html | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/htdocs/news.html b/htdocs/news.html index 4a104520..f13a8249 100644 --- a/htdocs/news.html +++ b/htdocs/news.html @@ -302,10 +302,10 @

[PATCH 1/1] config: Handle dash in library name for AC_LIB_LINKAGEFLAGS_BODY

From: "Ijaz, Abdul B" For a library with dash in the name like yaml-cpp the AC_LIB_LINKAGEFLAGS_BODY function generates a with_libname_type argument variable name with a dash but this results in configure error. Since dashes are not allowed in the variable name. This change handles such cases a

[PATCH 0/1] config: Handle dash in library name for AC_LIB_LINKAGEFLAGS_BODY

From: "Ijaz, Abdul B" Hi All, This change fixes the handling of dash(-) in the library names like yaml-cpp for the AC_LIB_LINKAGEFLAGS_BODY script function of the file "config/lib-link.m4" and used by the autoconf tool. This is my first patch for GCC so adding this summary of the change in 0/1

Re: [PATCH] fixincludes: bypass the math_exception fix on __cplusplus

On Mon, 10 Jun 2024, Rainer Orth wrote: > I'd have loved to remove fixes that mention obsolete Solaris versions, > but refrained from doing so when there was no way of knowing that no > innocent would be harmed. Doing so early in stage 1 (like now ;-) might be a good trade off? If nobody reports

[pushed] wwwdocs: gcc-14: Use hyphen in compile-time

--- htdocs/gcc-14/changes.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 9a1b0c8a..29958fd5 100644 --- a/htdocs/gcc-14/changes.html +++ b/htdocs/gcc-14/changes.html @@ -621,7 +621,7 @@ You may also want to chec

Re: [PATCH][wwwdocs] changes.html changes for AArch64 for GCC 14.1

On Tue, 2 Apr 2024, Kyrylo Tkachov wrote: > Here's a writeup of the AArch64 changes to highlight in GCC 14.1. If > there's something you'd like to highlight feel free to comment or add a > patch yourself. I don't expect the list to be exhaustive. > > It's been a busy release for AArch64! Indeed

Re: [RFC WIP] RAW_DATA_CST for #embed optimization

> Am 07.07.2024 um 17:14 schrieb Jakub Jelinek : > > On Sun, Jul 07, 2024 at 09:02:57AM +0200, Richard Biener wrote: >> I see. I was wondering because PCH includes are not resolved. That said, >> it sounds like #embed is sadly defined on The preprocessor side rather >> than in the language w

Re: [RFC/PATCH] libgcc: sh: Use soft-fp for non-hosted SH3/SH4

On 7/6/24 6:12 PM, Oleg Endo wrote: This is almost certainly a poorly written pattern. I just fixed a bunch of these, but not this one. Essentially a recent change in the generic parts of the compiler is exposing some bugs in the SH backend. The patterns were written and tested to the b

Re: [RFC WIP] RAW_DATA_CST for #embed optimization

On Sun, Jul 07, 2024 at 09:02:57AM +0200, Richard Biener wrote: > I see. I was wondering because PCH includes are not resolved. That said, > it sounds like #embed is sadly defined on The preprocessor side rather > than in the language where it would have been easy to constrain uses to > those tha

[committed] c++: Simplify uses of LAMBDA_EXPR_EXTRA_SCOPE

On Sun, Jun 16, 2024 at 12:18:10PM +1000, Nathaniel Shead wrote: > No functional change intended; OK for trunk? > In retrospect, committing as obvious after bootstrap+regtest. > -- >8 -- > > I noticed there already exists a getter to get the scope of a lambda > from its type directly rather tha

Re: [PATCH 0/2] fix RISC-V zcmp popretz [PR113715]

On 6/8/24 2:36 PM, Jeff Law wrote: On 6/5/24 8:42 PM, Fei Gao wrote: But let's back up and get a good explanation of what the problem is. Based on patch 2/2 it looks like we have lost an assignment to the return register. To someone not familiar with this code, it sounds to me like we've

Re: [PATCH 1/1] ada: Make the names of uninstalled cross-gnattools consistent across builds

On Thu, 4 Jul 2024, Arnaud Charlet wrote: > The change is OK, thanks. I have committed it now, thank you for your review. Maciej

[PATCH] c++/modules: Conditionally start timer during lazy load [PR115165]

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? Or should I include a testcase? I haven't reduced one from using the full contents of C++23 yet but I can do so if you prefer. -- >8 -- While lazy loading, instantiation of pendings can sometimes recursively perform name lookup a

[committed] libstdc++: Fix std::find for non-contiguous iterators [PR115799]

Tested x86_64-linux. Pushed to trunk. -- >8 -- The r15-1857 change didn't correctly restrict the new optimization to contiguous iterators. libstdc++-v3/ChangeLog: PR libstdc++/115799 * include/bits/stl_algo.h (find): Use 'if constexpr' so that memchr optimization is a di

[committed] libstdc++: Fix memchr path in std::ranges::find for non-common range [PR115799]

Tested x86_64-linux. Pushed to trunk. -- >8 -- The memchr optimization introduced in r15-1857 needs to advance the start iterator instead of returning the sentinel. libstdc++-v3/ChangeLog: PR libstdc++/115799 * include/bits/ranges_util.h (__find_fn): Return iterator inst

Re: [RFC] tree-if-conv: Handle nonzero masked elements [PR115336].

> Am 07.07.2024 um 11:26 schrieb Robin Dapp : > >  >> >> Yeah, I think so. I guess for RVV there's a choice between: >> >> (1) making the insn predicate accept all else values and making >>the insn emit an explicit blend between the loaded result >>and the else value >> >> (2) maki

Re: [RFC/PATCH] libgcc: sh: Use soft-fp for non-hosted SH3/SH4

Hi! The default sh-elf configuration has no multi-libs for SH3 and SH4 variants without FPU (from what I can see). So it won't use soft-fp so much during sim testing. So please change to soft-fp for sh*, not just SH3/SH4. Got it, done that locally, and will update patch once tested. Here's

Re: [RFC] tree-if-conv: Handle nonzero masked elements [PR115336].

> Yeah, I think so. I guess for RVV there's a choice between: > > (1) making the insn predicate accept all else values and making > the insn emit an explicit blend between the loaded result > and the else value > > (2) making the insn predicate only accept “undefined” (SCRATCH in > r

[PATCH] fortran: Remove useless nested end of scalarization chain handling

Hello, this is another small cleanup I had lying around. Regression-tested on x86_64-linux. Ok for master? -- 8< -- Remove the special handling of end of nested scalarization chains, which advanced the chain to an element of a parent chain when the current one was reaching its end. That handli

[x86 SSE PATCH] Some AVX512 ternlog expansion refinements.

Hi Hongtao, This should address concerns about the remaining use of force_reg. This patch replaces the call to force_reg in ix86_expand_ternlog_binop with gen_reg_rtx and emit_move_insn, the last place where force_reg may be called (indirectly) from ix86_expand_ternlog. This patch also cleans up

[PATCH] fortran: Move definition of variable closer to its uses

Hello, I have found this small cleanup lying in a local branch. Regression-tested on x86_64-linux, OK for master? -- 8< -- No change of behaviour, this makes a variable easier to track. gcc/fortran/ChangeLog: * trans-array.cc (gfc_trans_preloop_setup): Use a separate variable f

Re: [RFC WIP] RAW_DATA_CST for #embed optimization

> Am 06.07.2024 um 16:56 schrieb Jakub Jelinek : > > On Sat, Jul 06, 2024 at 02:45:45PM +0200, Richard Biener wrote: >>> Anyway, thoughts on this before I spend too much time on it? >> >> Why do we have an "element type"? Would >> >> int a[] = { >> #embed "cc1plus" >> }; >> >> be valid? >