Re: [PATCH v4][GCC13] RISC-V: Provide `fmin'/`fmax' RTL patterns

On Tue, Feb 8, 2022 at 4:35 AM Maciej W. Rozycki wrote: > gcc/ > * config/riscv/riscv.md (UNSPEC_FMIN, UNSPEC_FMAX): New > constants. > (fmin3, fmax3): New insns. > ... I tried testing on some of the hardware I have. Both the HiFive Unleashed (2018) and HiFive

Re: [RFC][PATCH] c++/46476 - implement -Wunreachable-code-return

On Mon, Nov 29, 2021 at 5:21 PM Martin Sebor via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > There are some other "unusual" cases worth a look, such as missing > context of any kind except for like and column: > > elfnn-riscv.c:3346:7: warning: statement after return is not reachable >

[PATCH] Update my email address.

riscv port Andrew Waterman -riscv port Jim Wilson +riscv port Jim Wilson rs6000/powerpc portDavid Edelsohn rs6000/powerpc portSegher Boessenkool rs6000 vector extnsAldy Hernandez

Re: RISCV: Add zmmul extension

On Wed, Oct 27, 2021 at 12:14 AM Kito Cheng wrote: > Otherwise it is LGTM, but I'm just surprised it's still 0.1 and not frozen > yet. > We should have binutils support first before we have gcc support. Otherwise that may lead to binutils errors later when zmmul gets passed down to binutils. I

[PATCH] RISC-V: Pattern name fix mul*3_highpart -> smul*3_highpart.

From: Geng Qi No known code changes, just fixes an inconsistency that was noticed. Committed. Jim gcc/ * config/riscv/riscv.md (mulv4): Call gen_smul3_highpart. (mulditi3): Call muldi3_highpart. (muldi3_highpart): Rename to muldi3_highpart. (mulsidi3):

Re: [PATCH] RISC-V: Pattern name fix mulm3_highpart -> smulm3_highpart.

On Mon, Sep 27, 2021 at 4:38 AM Geng Qi via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > gcc/ChangeLog: > * config/riscv/riscv.md > (muldi3_highpart): Rename to muldi3_highpart. > (mulditi3): Emit muldi3_highpart. > (mulsi3_highpart): Rename to mulsi3_highpart.

Re: [RFC PATCH 0/8] RISC-V: Bit-manipulation extension.

On Tue, Sep 28, 2021 at 3:05 PM Christoph Muellner < cmuell...@ventanamicro.com> wrote: > We talked about this in the T meeting on Monday. > Philipp Tomsich mentioned, that he has a patchset from earlier this > year, which adds support for Zbs. > He proposed to rebase it and send it to the list

Re: [RFC PATCH 0/8] RISC-V: Bit-manipulation extension.

On Mon, Sep 27, 2021 at 4:20 AM Christoph Muellner < cmuell...@ventanamicro.com> wrote: > In case somebody wants to test this patchset, a patchset for Binutils > is required as well. > AFAIK here would be the Binutils branch with the required changes: > >

Re: [RFC PATCH 0/8] RISC-V: Bit-manipulation extension.

On Thu, Sep 23, 2021 at 12:57 AM Kito Cheng wrote: > Bit manipulation extension[1] is finishing the public review and waiting > for > the rest of the ratification process, I believe that will become a ratified > extension soon, so I think it's time to submit to upstream for review now > :) > We

Re: [PATCH] configure: Update --help output for --with-multilib-list

On Fri, Sep 17, 2021 at 4:39 AM Jonathan Wakely via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > The list of architectures that support the option is incomplete. > > gcc/ChangeLog: > > * configure.ac: Fix --with-multilib-list description. > * configure: Regenerate. > > OK for

Re: [PATCH] Fix SFmode subreg of DImode and TImode

On Tue, Sep 7, 2021 at 12:12 AM Michael Meissner via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > This patch fixes the breakage in the PowerPC due to a recent change in > SUBREG > behavior. While it is arguable that the patch that caused the breakage > should > be reverted, this patch should

Re: [PATCH 2/2] RISC-V: Implement TARGET_COMPUTE_MULTILIB

On Tue, Aug 31, 2021 at 5:22 PM Jim Wilson wrote: > On Wed, Jul 21, 2021 at 2:28 AM Kito Cheng wrote: > >> Use TARGET_COMPUTE_MULTILIB to search the multi-lib reuse for >> riscv*-*-elf*, >> according following rules: >> > > I find the other_cond support a

Re: [PATCH 2/2] RISC-V: Implement TARGET_COMPUTE_MULTILIB

On Wed, Jul 21, 2021 at 2:28 AM Kito Cheng wrote: > Use TARGET_COMPUTE_MULTILIB to search the multi-lib reuse for > riscv*-*-elf*, > according following rules: > I find the other_cond support a bit confusing. Is this for -mcmodel perhaps? Why not just say that if so? match_score: weigth ->

Re: [PATCH 1/2] Add TARGET_COMPUTE_MULTILIB hook to override multi-lib result.

On Wed, Jul 21, 2021 at 2:28 AM Kito Cheng wrote: > Create a new hook to let target could override the multi-lib result, > the motivation is RISC-V might have very complicated multi-lib re-use > rule*, which is hard to maintain and use current multi-lib scripts, > we even hit the "argument list

Re: [PATCH 1/2] RISC-V: Add arch flags for T-HEAD.

On Tue, Jul 13, 2021 at 11:06 AM Palmer Dabbelt wrote: > Is there are documentation as to what this "theadc" extension is? > The best doc I know of is https://github.com/isrc-cas/c910-llvm The README is in Chinese, but google translate does a decent job on it. If you want more details, you

[PATCH] RISC-V: Enable riscv attributes by default for all riscv targets.

These were only enabled for embedded elf originally because that was the safe option, and linux had no obvious use for them. But now that we have new extensions coming like V that affect process state and ABIs, the attributes are expected to be useful for linux, and may be required by the psABI.

Re: [PATCH v2] REE: PR rtl-optimization/100264: Handle more PARALLEL SET expressions

On Mon, May 10, 2021 at 5:39 AM Christoph Muellner wrote: > gcc/ChangeLog: > PR rtl-optimization/100264 > * ree.c (get_sub_rtx): Ignore SET expressions without register > destinations and remove assertion, as it is not valid anymore > with this new behaviour. >

Re: [PATCH 1/2] REE: PR rtl-optimization/100264: Handle more PARALLEL SET expressions

On Fri, Apr 30, 2021 at 4:10 PM Christoph Müllner via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > On Sat, May 1, 2021 at 12:48 AM Jeff Law wrote: > > On 4/26/2021 5:38 AM, Christoph Muellner via Gcc-patches wrote: > > > [ree] PR rtl-optimization/100264: Handle more PARALLEL SET expressions >

Re: [PATCH] RISC-V: Generate helpers for cbranch4

On Wed, May 5, 2021 at 12:23 PM Christoph Muellner wrote: > gcc/ > PR 100266 > * config/rsicv/riscv.c (riscv_block_move_loop): Simplify. > * config/rsicv/riscv.md (cbranch4): Generate helpers. > OK. Committed. Though I had to fix the ChangeLog entry. It was

Re: [PATCH v2 09/10] RISC-V: Provide programmatic implementation of CAS [PR 100266]

On Wed, May 5, 2021 at 12:37 PM Christoph Muellner wrote: > The existing CAS implementation uses an INSN definition, which provides > the core LR/SC sequence. Additionally to that, there is a follow-up code, > that evaluates the results and calculates the return values. > This has two drawbacks:

Re: [PATCH] RISC-V: Implement __clear_cache via __builtin__clear_cache

On Thu, Apr 29, 2021 at 10:02 PM Palmer Dabbelt wrote: > This was reported as Bug 94136, which is a year old but was categorized > as a documentation bug. I believe that categorization was incorrect: > having an empty __clear_cache library routine is simply incorrect It affects almost all

Re: [PATCH] doc/options.texi: Fix the discription of 'Negative'.

On Wed, Apr 28, 2021 at 2:25 AM Geng Qi via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > gcc/ChangeLog: > * doc/options.texi (Negative): Fix the discription so that it > matches > the code implementation of prune_options(). > This matches my testing as mentioned in another

Re: About implementation of the Negative property of options.

On Fri, Apr 30, 2021 at 1:03 AM gengqi-linux wrote: > Thanks for your replies. > I would suggest filing a bug report, and adding useful info from this thread to the bug report. Then we can track it. Jim

Re: [PATCH] RISC-V: For '-march' and '-mabi' options, add 'Negative' property mentions itself.

On Wed, Apr 28, 2021 at 1:30 AM Geng Qi via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > gcc/ChangeLog: > * config/riscv/riscv.opt (march=,mabi=): Negative itself. > Thanks. I committed this. Do we need to backport to release branches? This looks like an uncommon problem, or we

Re: About implementation of the Negative property of options.

On Wed, Apr 28, 2021 at 1:11 PM Joseph Myers wrote: > Could you please explain the bug at the *user-visible* level? That is, > the particular options passed to the compiler, how those options behave, > and how you think they should behave instead. I added this to the riscv.opt file to create

Re: [PATCH] [RISCV] Add Pattern for builtin overflow

On Wed, Apr 28, 2021 at 10:43 PM Levy Hsu wrote: > From: LevyHsu > > Added implementation for builtin overflow detection, new patterns are > listed below. > This looks OK. You are missing a ChangeLog entry. I added one. I had to fix some whitespace and formatting issues. Open parens should

Re: [PATCH] [RISCV] Add Pattern for builtin overflow

On Wed, Apr 28, 2021 at 4:04 PM Andrew Waterman wrote: > > This is a good suggestion, but in the interests of making forward > progress here, I'd like to accept the patch and then file these as > bugzillas as ways to further improve the patch. > > Agreed, these potential improvements are

Re: [PATCH 00/10] [RISC-V] Atomics improvements [PR100265/PR100266]

On Mon, Apr 26, 2021 at 5:45 AM Christoph Muellner wrote: > This series provides a cleanup of the current atomics implementation > of RISC-V: > This looks OK to me, other than the issue with address instructions emitted inside the lr/sc loop. That could be fixed with a follow up patch though.

Re: [PATCH] [RISCV] Add Pattern for builtin overflow

On Tue, Apr 27, 2021 at 12:45 AM Andrew Waterman wrote: > > signed addition (SImode with RV64): > > add t0, t1, t2 > > sext.w t3, t0 > > bne t0, t3, overflow > > The following version has the same instruction count but offers more ILP: > > add t0, t1, t2 > addw t3,

Re: [PATCH 10/10] RISC-V: Provide programmatic implementation of CAS [PR 100266]

On Mon, Apr 26, 2021 at 5:46 AM Christoph Muellner wrote: > The existing CAS implementation uses an INSN definition, which provides > the core LR/SC sequence. Additionally to that, there is a follow-up code, > that evaluates the results and calculates the return values. > This has two drawbacks:

Re: [PATCH v2 0/5] RISC-V big endian support

On Fri, Mar 19, 2021 at 9:22 AM Kito Cheng via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > On Mon, Mar 15, 2021 at 5:42 AM Marcus Comstedt wrote: > > I've now delved a bit deeper into the failure of the testcase > > gcc.c-torture/compile/pr35318.c on big endian RV32. > Looking at this

Re: add rv64im{,c,fc} multilibs

On Tue, Feb 23, 2021 at 2:17 AM Alexandre Oliva wrote: > I take your response as confirming my expectation that the defaults are > to remain unchanged for now, and I will thus proceed under this > assumption. > If we add default multilibs for you, then to be fair, we need to add default

Re: [PATCH] RISC-V: Zihintpause: add __builtin_riscv_pause

On Thu, Jan 7, 2021 at 12:50 AM Kito Cheng wrote: > My point is tracking info and consistent behavior/scheme with other > extensions, so personally I strongly prefer it should be guarded with > -march. > It is a hint. We should allow it even if the architecture extension is not enabled. For

Re: [PATCH] RISC-V: Add implementation for builtin overflow

On Thu, Jan 21, 2021 at 2:25 AM Levy wrote: > Added implementation for builtin overflow detection, new patterns are > listed below. > For rv32 SImode and rv64 DImode, the unsigned add/sub and signed/unsigned mul patterns seem to give the same result as the default code generation. That has me

[PATCH] RISC-V: Avoid zero/sign extend for volatile loads. Fix for 97417.

From: Levy Hsu This expands sub-word loads as a zero/sign extended load, followed by a subreg. This helps eliminate unnecessary zero/sign extend insns after the load, particularly for volatiles, but also in some other cases. Testing shows that it gives consistent code size decreases. Tested

[PATCH] RISC-V: Shorten memrefs improvement, partial fix 97417.

We already have a check for riscv_shorten_memrefs in riscv_address_cost. This adds the same check to riscv_rtx_costs. Making this work also requires a change to riscv_compressed_lw_address_p to work before reload by checking the offset and assuming any pseudo reg is OK. Testing shows that this

Re: [PATCH] PR target/98878 - Incorrect multilib list for riscv*-rtems

On Thu, Feb 4, 2021 at 2:02 AM Kito Cheng wrote: > * gcc.c (print_multilib_info): Check all required argument is > provided > by default arg. > This looks OK to me, but... > > - /* If this directory requires any default arguments, we can skip > + /* If this directory

Re: [RFC] test builtin ratio for loop distribution

On Wed, Jan 27, 2021 at 4:40 AM Alexandre Oliva wrote: > This patch attempts to fix a libgcc codegen regression introduced in > gcc-10, as -ftree-loop-distribute-patterns was enabled at -O2. > > RISC-V doesn't have any setmemM pattern, so the loops above end up > "optimized" into memset calls,

Re: [PATCH] RISC-V: Fix -march option parsing when `p` extension exists.

On Thu, Jan 21, 2021 at 10:49 PM Kito Cheng wrote: > I think this patch is small enough to accept without FSF copyright > assignment, and he is also on the way of the process, what do you > think? > I see the copyright assignments on file at the FSF when I checked today. Jim

Re: [PATCH v2 0/2] RISC-V: Introduce new architecture extension test macros

On Thu, Jan 7, 2021 at 1:55 AM Kito Cheng wrote: > This patch set introduce new set of architecture extension test macros > which is accept on riscv-c-api-doc[1] recently. > > The motivation of this scheme is have an unify naming scheme for > extension macro and add the capability to checking

Re: [PATCH] Fix array-quals-1.c for RISC-V

On Wed, Jan 6, 2021 at 1:17 AM Kito Cheng wrote: > RISC-V will put those variable on srodata rather than rodata. > gcc/testsuite/ChangeLog: > * gcc.dg/array-quals-1.c: Allow srodata. > OK. Jim

Re: [PATCH] Add missing varasm DECL_P check.

On Wed, Dec 9, 2020 at 7:14 PM H.J. Lu wrote: > A testcase? > A testcase requires the RISC-V select_section target hook, so it isn't going to be very useful. I don't see any other linux targets that have this hook defined. Just a few embedded targets. The testcase is

Re: V3 [PATCH 0/2] Switch to a new section if the SECTION_RETAIN bit doesn't match

On Wed, Dec 9, 2020 at 6:14 PM H.J. Lu wrote: > I tested it with glibc build. Glibc build issue is the reason I > didn't combine 2 patches into one. > If GCC does issue a warning, which it should, we will change glibc. > OK. Thanks. Then I won't worry about this glibc for now. Jim

[PATCH] Add missing varasm DECL_P check.

This fixes a riscv64-linux bootstrap failure. get_constant_section calls the select_section target hook, and select_section calls get_named_section which calls get_section. So it is possible to have a constant not a decl in both of these functions. They already call DECL_P checks everywhere

Re: V3 [PATCH 0/2] Switch to a new section if the SECTION_RETAIN bit doesn't match

On Tue, Dec 8, 2020 at 4:51 AM H.J. Lu via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > When SECTION_RETAIN is used, definitions marked with used attribute and > unmarked definitions are placed in a section with the same name. Instead > of issue an error: > Have you tested glibc builds with

Re: [PATCH V2] RISC-V: Explicitly call python when using multilib generator

On Wed, Dec 9, 2020 at 12:30 PM Simon Cook wrote: > I believe this way of invoking python should be better than just > hardcoding python, instead using the interpreter that was called for the > first script. > I'm not a python expert. I would suggest asking Kito to review the patch. Avoiding

Re: [PATCH] RISC-V: Explicitly call python when using multilib generator

On Wed, Dec 9, 2020 at 7:02 AM Jakub Jelinek via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > On Wed, Dec 09, 2020 at 03:57:51PM +0100, Matthias Klose wrote: > > On 12/9/20 3:03 PM, Simon Cook wrote: > > > When building GCC for RISC-V with the --with-multilib-generator option, > > > it may not

Re: [PATCH] PR target/98152: Checking python is available before using

On Sat, Dec 5, 2020 at 10:12 PM Kito Cheng wrote: > gcc/ChangeLog: > > * config.gcc (riscv*-*-*): Checking python, python3 or python2 > is available, and skip doing with_arch canonicalize if no python > available. > Looks good to me. Jim

Re: [committed] Fix mcore multilib specification

On Tue, Dec 1, 2020 at 3:24 PM Jeff Law via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > > Kito's recent change to multilib handling seems to have exposed a latent > mcore bug. > > The mcore 210 does not support little endian. Yet we try to build a > mcore-210 little-endian multilibs. > > I

Re: [PATCH] RISC-V: Canonicalize --with-arch

On Tue, Dec 1, 2020 at 12:13 AM Kito Cheng wrote: > - We would like to canonicalize the arch string for --with-arch for >easier handling multilib, so split canonicalization part to a stand >along script to shared the logic. > > gcc/ChangeLog: > > *

Re: [PATCH] RISC-V: Always define MULTILIB_DEFAULTS

On Fri, Nov 20, 2020 at 10:38 PM Kito Cheng wrote: > On Sat, Nov 21, 2020 at 6:12 AM Jim Wilson wrote: > > On Fri, Nov 20, 2020 at 12:34 AM Kito Cheng > wrote: > > > > > - Define MULTILIB_DEFAULTS can reduce the total number of multilib if > > >

Re: [PATCH] Fix print_multilib_info when default arguments appear in the option list with '!'

On Thu, Nov 26, 2020 at 1:04 AM Kito Cheng wrote: > * gcc.c (print_multilib_info): Check default arguments not > appeared in multi-lib option list with '!' > OK. Jim

Re: [PATCH] RISC-V: Always define MULTILIB_DEFAULTS

On Fri, Nov 20, 2020 at 12:34 AM Kito Cheng wrote: > - Define MULTILIB_DEFAULTS can reduce the total number of multilib if >the default arch and ABI are listed in the multilib config. > It looks like a good idea, but it doesn't seem to work. A toolchain configured without specifying

Re: RISC-V: Support version controling for ISA standard extensions

On Thu, Nov 12, 2020 at 11:27 PM Kito Cheng wrote: > Current GCC implementation is RISC-V ISA 2.2, this patch set implement > v20190608 and v20191213, and also add option > -misa-spec=[2.2|20190608|20191213] to change the default ISA spec version. > > There is one major incompatible > > That

Re: [PATCH 3/3] RISC-V: Support version controling for ISA standard extensions

On Thu, Nov 12, 2020 at 11:28 PM Kito Cheng wrote: > +#ifndef HAVE_AS_MARCH_ZIFENCE > + /* Skip since older binutils don't recognize zifencei, > + we mad a mistake that is binutils 2.35 support zicsr but not support > + zifencei. */ > + skip_zifencei = true; > +#endif > I'd suggest

Re: [PATCH 2/3] RISC-V: Support zicsr and zifencei extension for -march.

On Thu, Nov 12, 2020 at 11:29 PM Kito Cheng wrote: > - CSR related instructions and fence instructions has to be splitted from >baseline ISA, zicsr and zifencei are corresponding sub-extension. > It is actually only fence.i that is split off. fence is still part of the base ISA. This is

Re: [PATCH v1 1/2] Simplify shifts wider than the bitwidth of types

On Tue, Nov 17, 2020 at 8:46 AM Jakub Jelinek via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > On Tue, Nov 17, 2020 at 05:29:57PM +0100, Philipp Tomsich wrote: > > > > In other words, the change to VRP canonicalizes what a lshift_expr > with an > > > > shift-amount outside of the type width

Re: [PATCH v1 2/2] RISC-V: Adjust predicates for immediate shift operands

On Mon, Nov 16, 2020 at 2:45 PM Philipp Tomsich wrote: > This is an de-optimization only, if applied without patch 1 from the > series: the change to VRP ensures that the backend will never see a shift > wider than the immediate field. > The problem is that if a negative shift-amount makes it to

Re: [PATCH v1 1/2] Simplify shifts wider than the bitwidth of types

On Mon, Nov 16, 2020 at 10:57 AM Philipp Tomsich wrote: > This adds simplify_using_ranges::simplify_lshift_using_ranges to > detect and rewrite such cases. If the intersection of meaningful > shift amounts for the underlying type and the value-range computed > for the shift-amount (whether an

Re: [PATCH v1 2/2] RISC-V: Adjust predicates for immediate shift operands

On Mon, Nov 16, 2020 at 10:57 AM Philipp Tomsich wrote: > In case a negative shift operand makes it through into the backend, > it will be treated as unsigned and truncated (using a mask) to fit > into the range 0..31 (for SImode) and 0..63 (for DImode). > This is a de-optimization. This

Re: [PATCH v2] PR target/97682 - Fix to reuse t1 register between call address and epilogue.

On Thu, Nov 12, 2020 at 10:56 PM Monk Chiang wrote: > - When expanding the call pattern, choose t1 register be a jump register. > Epilogue also uses a t1 register to adjust Stack point. The call > pattern > and epilogue will initial t1 twice, if both are generated in the same >

Re: [PATCH] Add a new pattern in 4-insn combine

On Tue, Nov 10, 2020 at 4:18 PM Jeff Law via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > > On 11/8/20 7:48 PM, HAO CHEN GUI via Gcc-patches wrote: > > ChangeLog > > > > * combine.c (combine_validate_cost): Add an argument for newi1pat. > > (try_combine): Add a 4-insn combine

Re: [PATCH] Asan changes for RISC-V.

On Fri, Nov 13, 2020 at 11:12 AM Jeff Law wrote: > > On 10/28/20 5:58 PM, Jim Wilson wrote: > > We have only riscv64 asan support, there is no riscv32 support as yet. > So I > > need to be able to conditionally enable asan support for the riscv > target. I > > impl

Re: [PATCH] PR target/97682 - Fix to reuse t1 register between call address and epilogue.

On Mon, Nov 9, 2020 at 11:15 PM Monk Chiang wrote: > diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h > index 172c7ca7c98..3bd1993c4c9 100644 > --- a/gcc/config/riscv/riscv.h > +++ b/gcc/config/riscv/riscv.h > @@ -342,9 +342,13 @@ extern const char *riscv_default_mtune (int argc,

Re: [PATCH] RISC-V: Enable ifunc if it was supported in the binutils for linux toolchain.

On Tue, Nov 10, 2020 at 7:33 PM Nelson Chu wrote: > gcc/ > * configure: Regenerated. > * configure.ac: If ifunc was supported in the binutils for > linux toolchain, then set enable_gnu_indirect_function to yes. > Looks good. I committed and pushed it. I see

Re: [PATCH] match.pd: undistribute (a << s) & C, when C = (M << s) and exact_log2(M - 1)

On Wed, Nov 11, 2020 at 2:55 AM Jakub Jelinek via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > On Wed, Nov 11, 2020 at 11:43:34AM +0100, Philipp Tomsich wrote: > > The patch addresses this by disallowing that rule, if an exact > power-of-2 is > > seen as C1. The reason why I would prefer to

Re: [PATCH] [PING^2] Asan changes for RISC-V.

Original message here https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557406.html This has non-RISC-V changes, so I need a global reviewer to look at it. Jim On Wed, Nov 4, 2020 at 12:10 PM Jim Wilson wrote: > > > On Wed, Oct 28, 2020 at 4:59 PM Jim Wilson wrote: > >

Re: [PATCH v2] Add bypass_p cost check in flag_sched_last_insn_heuristic

On Thu, Nov 5, 2020 at 6:10 PM Jojo R wrote: > gcc/ > * haifa-sched.c (rank_for_schedule): Add bypass_p > cost check in flag_sched_last_insn_heuristic. > > + || (INSN_CODE (DEP_PRO (dep1)) >= 0 && bypass_p (DEP_PRO (dep1)) > + && recog_memoized

Re: [PATCH v2] Replace dep_list_size with dep_list_costs for better scheduling

On Thu, Nov 5, 2020 at 6:03 PM Jojo R wrote: > gcc/ > * haifa-sched.c (dep_list_costs): New. > (rank_for_schedule): Use dep_list_costs. > When you post a patch, you should explain what the patch is doing and why this is better than the code that was there before. It is

Re: [PATCH] [PING] Asan changes for RISC-V.

On Wed, Oct 28, 2020 at 4:59 PM Jim Wilson wrote: > We have only riscv64 asan support, there is no riscv32 support as yet. So > I > need to be able to conditionally enable asan support for the riscv > target. I > implemented this by returning zero from the asan_shadow_

[PATCH] Asan changes for RISC-V.

# of unsupported tests 224 === g++ Summary === # of expected passes2002 # of unexpected failures6 # of unresolved testcases 1 # of unsupported tests 175 OK? Jim 2020-10-28 Jim Wilson gcc/ * config/riscv/riscv.c (riscv_as

Re: [PATCH v2] RISC-V: Add configure option: --with-multilib-config to flexible config multi-lib settings.

On Mon, Oct 19, 2020 at 2:35 AM Kito Cheng wrote: > - I was consider to implmenet this into `--with-multilib-list` option, >but I am not sure who will using that with riscv*-*-elf*, so I decide to >using another option name for that. > I believe that --with-multllib-list is only useful

Re: [PATCH] RISC-V: Extend syntax for the multilib-generator

On Wed, Oct 21, 2020 at 7:36 PM Jim Wilson wrote: > > > On Fri, Oct 16, 2020 at 2:34 AM Kito Cheng wrote: > >> +# Example 2: >> +# rv32imafd-ilp32d--c*b >> +# means that, in addition to rv32imafd, these configurations can also >> use the >> +# rv3

Re: [PATCH] RISC-V: Extend syntax for the multilib-generator

On Fri, Oct 16, 2020 at 2:34 AM Kito Cheng wrote: > +# Example 2: > +# rv32imafd-ilp32d--c*b > +# means that, in addition to rv32imafd, these configurations can also use > the > +# rv32imafd-ilp32d libraries: rv32imafd-ilp32dc, rv32imafd-ilp32db, > +#

Re: [PATCH] RISC-V: Add support for -mcpu option.

On Tue, Oct 13, 2020 at 3:09 AM Kito Cheng wrote: > - The behavior of -mcpu basically equal to -march plus -mtune, but it >has lower priority than -march and -mtune. This looks OK to me. I noticed a few things while testing. These don't need to be fixed before the patch is committed.

Re: [RISC-V] Add support for AddressSanitizer on RISC-V GCC

On Tue, Aug 25, 2020 at 12:39 PM Jim Wilson wrote: > On Wed, Aug 19, 2020 at 1:02 AM Joshua via Gcc-patches > wrote: > > * config/riscv/riscv.c (asan_shadow_offset): Implement the offset > > of asan shadow memory for risc-v. > > (asan_shadow_offse

[PATCH][GCC 10] Fix build failure with zstd versio9n 1.2.0 or older.

Backported from master: 2020-09-29 Jim Wilson gcc/ PR bootstrap/97183 * configure.ac (gcc_cv_header_zstd_h): Check ZSTD_VERISON_NUMBER. * configure: Regenerated. --- gcc/configure| 11 --- gcc/configure.ac | 7 ++- 2 files

Re: [PATCH] Fix GCC 10+ build failure with zstd version 1.2.0 or older.

On Tue, Sep 29, 2020 at 1:20 AM Richard Biener wrote: > > On Tue, Sep 29, 2020 at 2:46 AM Jim Wilson wrote: > > > > Extends the configure check for zstd.h to also verify the zstd version, > > since gcc requires features that only exist in 1.3.0 and newer. Without >

[PATCH] Fix GCC 10+ build failure with zstd version 1.2.0 or older.

Extends the configure check for zstd.h to also verify the zstd version, since gcc requires features that only exist in 1.3.0 and newer. Without this patch we get a build error for lto-compress.c when using an old zstd version. Tested with builds using zstd 0.5.1, 1.2.0, 1.3.0, and 1.3.3, and

Re: [PATCH] RISC-V/libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

On Sun, Aug 30, 2020 at 11:39 PM Kito Cheng wrote > Hi Maciej: > LGTM, thanks for your patch! I don't see this patch in the FSF GCC tree. Maciej are you going to commit it? Or do you want us to commit it for you? Jim

Re: [PATCH] RISC-V: Define __riscv_cmodel_medany for PIC mode.

On Thu, Sep 24, 2020 at 10:46 PM Kito Cheng wrote: > > - According the conclusion in RISC-V C API document, we decide to deprecat >the __riscv_cmodel_pic marco > > - __riscv_cmodel_pic is deprecated and will removed in next GCC >release. Looks good to me. By the way, you can self

Re: [RISC-V] Add support for AddressSanitizer on RISC-V GCC

On Wed, Aug 19, 2020 at 1:02 AM Joshua via Gcc-patches wrote: > * config/riscv/riscv.c (asan_shadow_offset): Implement the offset of > asan shadow memory for risc-v. > (asan_shadow_offset): new macro definition. When I try the patch, I get asan errors complaining about memory

Re: [RISC-V] Add support for AddressSanitizer on RISC-V GCC

On Thu, Jul 30, 2020 at 5:31 AM Joshua via Gcc-patches wrote: > +/* Implement TARGET_ASAN_SHADOW_OFFSET. */ > + > +static unsigned HOST_WIDE_INT > +riscv_asan_shadow_offset (void) > +{ > + return HOST_WIDE_INT_UC (0x1000); > +} Is there a reason why you used 0x1000? Looking at other

Re: [RISC-V] Add support for AddressSanitizer on RISC-V GCC

On Thu, Jul 30, 2020 at 6:28 AM Martin Liška wrote: > What's the reason for sending the same patch multiple times > from a different sender? I see 3 in the gcc.gnu.org email archive, and I saw 3 on the NNTP feed from gmane, but it seems only one of them ended up in my gmail inbox. The other two

Re: [PATCH] aarch64: Delete duplicated option docs.

Ping. ccing the aarch64 maintainers. If I don't get a response, I will just commit this as obvious. Jim On Sun, Jul 12, 2020 at 4:52 PM Jim Wilson wrote: > > Noticed while reviewing the RISC-V -mstack-protector-guard docs. The, and > could maybe be added as a separate patch.

Re: [PATCH v2] [RISC-V] Add support for TLS stack protector canary access

On Sun, Jul 19, 2020 at 7:04 PM cooper wrote: > Ping > > On 2020/7/13 下午4:15, cooper wrote: > > gcc/ > > * config/riscv/riscv-opts.h (stack_protector_guard): New enum. > > * config/riscv/riscv.c (riscv_option_override): Handle > > the new options. > > *

Re: [PATCH] RISC-V: Add ZFINX support

On Sun, Jul 26, 2020 at 11:40 PM wangtao (CH) wrote: > This is the patch to support ZFINX of RISC-V, which option is like > -march=rv32gc_zfinx. The ZFINX means f-registers in x-registers under RV-F > and RV-D extension. For more details, please refer to >

Re: [PATCH] [RISC-V] Add support for TLS stack protector canary access

On Tue, Jul 7, 2020 at 7:51 PM cooper wrote: > gcc/ > * config/riscv/riscv-opts.h (stack_protector_guard): New enum. > * config/riscv/riscv.c (riscv_option_override): Handle > the new options. > * config/riscv/riscv.md (stack_protect_set): New pattern to handle >

[PATCH] aarch64: Delete duplicated option docs.

Noticed while reviewing the RISC-V -mstack-protector-guard docs. The AArch64 section has two identical copies of the docs for this option. * doc/invoke.texi (AArch64 Options): Delete duplicate -mstack-protector-guard docs. --- gcc/doc/invoke.texi | 18 -- 1 file

Re: [PATCH] RISC-V: Fix regular expression in target-specific test

On Fri, Jul 10, 2020 at 6:53 AM Simon Cook wrote: > Some square brackets were missing escape characters, causing DejaGnu to > try and call a proc with the name "at". > > gcc/testsuite/ChangeLog: > > * gcc.target/riscv/read-thread-pointer.c: Fix escaping on > regular expression.

Re: [PATCH] RISC-V: Implment __builtin_thread_pointer

On Tue, Jul 7, 2020 at 2:52 AM Kito Cheng wrote: > gcc/ChangeLog: > * gcc/config/riscv/riscv.md (): New. > (TP_REGNUM): Ditto. > * doc/extend.texi (Target Builtins): Add RISC-V built-in section. > Document __builtin_thread_pointer. > gcc/testsuite/ChangeLog: >

Re: [PATCH] RISC-V: Disable remove unneeded save-restore call optimization if there are any arguments on stack.

On Tue, Jul 7, 2020 at 12:28 AM Kito Cheng wrote: > gcc/ChangeLog: > * config/riscv/riscv-sr.c (riscv_remove_unneeded_save_restore_calls): > Abort if any arguments on stack. > gcc/testsuite/ChangeLog > * gcc.target/riscv/save-restore-9.c: New. Looks good to me. Jim

Re: [PATCH] RISC-V: Preserve arch version info during normalizing arch string

On Tue, Jun 30, 2020 at 8:16 PM Kito Cheng wrote: > I agree the version of G is kind of problematic for GCC implementation, > That reminds me there was a long discussion[1] last year, > The conclusion is version of G is too confusing, it might just don't > accept any version for G. > I thought it

Re: [PATCH v2] RISC-V: Handle multi-letter extension for multilib-generator

On Wed, Jul 1, 2020 at 12:13 AM Kito Cheng wrote: > * config/riscv/multilib-generator (arch_canonicalize): Handle > multi-letter extension. > Using underline as separator between different extensions. Looks fine to me. Though I was expecting you to just commit the patch

Re: [PATCH] RISC-V: Preserve arch version info during normalizing arch string

On Mon, Jun 29, 2020 at 7:00 PM Kito Cheng wrote: > - Arch version should preserved if user explicitly specified the version. > e.g. > After normalize, -march=rv32if3d should be -march=rv32i_f3p0d > instead of-march=rv32ifd. This looks good to me. > +explicit_version_p(false) I'd

Re: [PATCH] RISC-V: Handle multi-letter extension for multilib-generator

On Mon, Jun 29, 2020 at 7:35 PM Kito Cheng wrote: > * config/riscv/multilib-generator (arch_canonicalize): Handle > multi-letter extension. > Using underline as separator between different extensions. This looks good to me. > + # Multi-letter extension must in

Re: [RFC/PATCH] IFN: Fix mask_{load,store} optab support macros

On Wed, Jun 24, 2020 at 1:35 AM Richard Sandiford wrote: > Richard Biener writes: > > AVX512 would have V16SImode and SImode because the mask would have > > an integer mode? Likewise I could imagine RISC-V using V4SImode and > > V4QImode > > or however their mask registers look like. RISC-V

Re: [PATCH 1/7 v5] ifn/optabs: Support vector load/store with length

On Tue, Jun 23, 2020 at 5:21 AM Richard Sandiford wrote: > MVE and Power both set inactive lanes to zero. But I'm not sure about RVV. > AIUI, for RVV the approach instead would be to reduce the effective vector > length for the final iteration of the vector loop, and I'm not sure > whether in

Re: [PATCH] RISC-V: Normalize arch string in driver time

On Fri, Jun 19, 2020 at 2:53 AM Kito Cheng wrote: > * config/riscv/riscv.h (DRIVER_SELF_SPECS): New. This looks good to me. This has the side effect that we are now passing -march twice to cc1 and as, but that should be harmless as the last one wins. I think this makes the

Re: [PATCH] RISC-V: Fix ICE on riscv_gpr_save_operation_p [PR95683]

On Mon, Jun 15, 2020 at 7:41 AM Kito Cheng wrote: > gcc/ChangeLog: > > PR target/95683 > * config/riscv/riscv.c (riscv_gpr_save_operation_p): Remove > assertion and turn it into a early exit check. > > gcc/testsuite/ChangeLog > > PR target/95683 > *

  1   2   3   4   5   >