On Sun, Feb 16, 2020 at 9:02 PM Kito Cheng wrote:
> It cause the __builtin_strlen not optimized/folded in test_local_cpy_4,
> and the reason is blocked by __builtin_memcpy, it's same issue in
> strlenopt-80.c, so I there is two way to fix this issue:
Another possible solution is to use
{
On Mon, Feb 17, 2020 at 9:57 PM Kito Cheng wrote:
> * config/riscv/riscv.c (riscv_output_move) Using fmv.x.w/fmv.w.x
> rather than fmv.x.s/fmv.s.x.
Looks good to me also.
By the way, since you are listed as one of the riscv port maintainers,
you could make changes like this
On Fri, Feb 21, 2020 at 1:04 AM Kito Cheng wrote:
> * config/riscv/riscv.c (riscv_emit_float_compare): Change the code gen
> for LTGT.
> (riscv_rtx_costs): Update cost model for LTGT.
Thanks. This looks good to me.
Jim
On Tue, Feb 18, 2020 at 9:29 PM Kito Cheng wrote:
> * config/riscv/riscv.c (riscv_emit_float_compare): Change the code gen
> for LTGT.
I think you should update riscv_rtx_costs also. The comment is now
wrong for LTGT, and the cost calculation is wrong too. Looks like it
should
Avoid paradoxical subregs when caller save. This reduces stack frame size
due to smaller loads and stores, and more frequent rematerialization.
Tested with cross riscv32-elf and riscv64-linux build and check, with no
regressions.
Committed.
Jim
PR target/93532
*
Musl and lld don't support TLS copy relocs, and don't want to add support
for this feature which is unique to RISC-V. Only GNU ld and glibc support
them. In the pasbi discussion, people have pointed out various problems
with using them, so we are deprecating them. There doesn't seem to be an
On Mon, Jan 20, 2020 at 12:04 AM Kito Cheng wrote:
> gcc/ChangeLog
>
> PR target/93304
> * config/riscv/riscv-protos.h (riscv_hard_regno_rename_ok): New.
> * config/riscv/riscv.c (riscv_hard_regno_rename_ok): New.
> * config/riscv/riscv.h (HARD_REGNO_RENAME_OK):
On Mon, Jan 20, 2020 at 5:44 AM Nathan Sidwell wrote:
> I've pushed this to master, to address 80005
>
> __has_include is funky in that it is macro-like from the POV of #ifdef
> ...
With this patch, __has_include__ no longer works. There is a use of
this in the RISC-V glibc port. I see the
Found with an rtl checking enabled build and check. This triggered failures
in the gcc.target/riscv/save-restore* tests. We are using XINT to access an
XWINT value; INTVAL is the preferred solution.
Since existing tests trigger it we don't need a new one. Tested with
riscv32-elf and
On Thu, Mar 12, 2020 at 2:38 AM Richard Biener via Gcc-patches
wrote:
>
> On Thu, Mar 12, 2020 at 4:06 AM Jeff Law via Gcc-patches
> wrote:
> >
> > On Wed, 2020-03-11 at 13:04 +, Nidal Faour via Gcc-patches wrote:
> > > This patch is a code density oriented and attempt to remove redundant
>
On Wed, Feb 19, 2020 at 3:40 AM Craig Blackmore
wrote:
> On 10/12/2019 18:28, Craig Blackmore wrote:
> Thank you for your review. I have posted an updated patch below which I think
> addresses your comments.
>
> Ping
>
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00712.html
This looks OK.
On Tue, Mar 31, 2020 at 2:07 AM Kito Cheng wrote:
> - Implied rule are introduced into latest RISC-V isa spec.
>
> - Only implemented D implied F-extension. Zicsr and Zifence are not
> implement yet, so the rule not included in this patch.
When I try this patch, I see an error:
On Tue, Mar 31, 2020 at 2:06 AM Kito Cheng wrote:
> - The arch string rule has changed in latest spec, it introduced new
>multi-letter extension prefix with 'h' and 'z', and drop `sx`. also
>adjust parsing order for 's' and 'x'.
This looks OK to me.
Jim
On Fri, Apr 10, 2020 at 2:20 AM Kito Cheng wrote:
> - Implied rule are introduced into latest RISC-V ISA spec.
> - Only implemented D implied F-extension. Zicsr and Zifence are not
> implement yet, so the rule not included in this patch.
> - Pass preprocessed arch string to arch.
> -
On Fri, Apr 10, 2020 at 2:20 AM Kito Cheng wrote:
> - The arch string rule has changed in latest spec, it introduced new
>multi-letter extension prefix with 'h' and 'z', and drop `sx`. also
>adjust parsing order for 's' and 'x'.
This is OK.
Jim
On Sun, Mar 29, 2020 at 3:03 PM Andreas Schwab wrote:
> * config/host-linux.c (TRY_EMPTY_VM_SPACE) [__riscv && __LP64__]:
> Define.
Looks like the same address already used by the aarch64 and ia64
ports, so it seems safe. OK.
Jim
This fixes a bug reported to the RISC-V sw-dev mailing list late last year.
https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/JV5Jdh4UjVw
Keith Packard wote the obvious patch to fix it. I tested it with cross builds
for riscv32-newlib and riscv64-linux. There were no
On Sun, Apr 12, 2020 at 7:54 PM Kito Cheng wrote:
> On Sat, Apr 11, 2020 at 1:48 AM Jim Wilson wrote:
> > Do we really need this now? It is a new feature not a bug fix, so it
> > might be better to wait until we reach stage1. We have limited time
> > to test this befo
On Mon, Apr 27, 2020 at 10:08 AM Craig Blackmore
wrote:
> Thanks for the review. I have updated the following patch with those changes.
This looks good, and the tree is open for development work again, so I
committed both parts 1 and 2 and pushed it.
One weird thing is that while the patch
On Tue, Mar 17, 2020 at 2:42 PM Maciej W. Rozycki wrote:
> On Tue, 18 Feb 2020, Kito Cheng wrote:
> > - fmv.x.s/fmv.s.x renamed to fmv.x.w/fmv.w.x in the latest RISC-V ISA
> >manual.
>
> The new mnemonics have been supported by GAS for a little while now and
> the old ones have been
On Fri, Mar 20, 2020 at 8:41 AM Nathan Sidwell wrote:
> If it could be tested on arm &| riscv, that'd be additional verification.
I did riscv testing, both cross and native, and didn't see any new
problems with the patch.
Jim
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.
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
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
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
>
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
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
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
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
This is potentially a sequence of 3 shifts, we which optimize to a sequence
of 2 shifts. This can happen when unsigned int is used for array indexing.
Tested with cross toolchain build and check for riscv32-elf and riscv64-linux.
There were no regressions. The new test fails without the patch
On Tue, May 26, 2020 at 12:12 AM Richard Biener wrote:
> From a look at the series description below you seem to add a new way
> of doing loads for this. Did you review other ISAs (those I'm not
> familiar with myself too much are SVE, RISC-V and GCN) in GCC whether
> they have similar support
The ISA manual specifies that divide by zero always returns -1 as the result.
We were failing to do that when the dividend was negative.
Tested with cross toolchain builds for riscv32-elf and riscv64-linux. There
were no regressions.
Committed.
Jim
libgcc/
* config/riscv/div.S
On Fri, May 29, 2020 at 1:53 AM MOSER Virginie via Gcc-patches
wrote:
> The assembly code in libgcc/config/riscv/div.S does not handle the division
> by zero as specified in the riscv-spec v2.2 chapter 6.2 in case of signed
> division:
This looks OK. There are some administrative comments to
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,
> +#
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
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
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
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
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:
>
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
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.
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
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
>
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
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
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
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
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
> *
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
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
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
On Wed, Jun 10, 2020 at 1:08 AM Kito Cheng wrote:
> * config/riscv/riscv.c (gpr_save_reg_order): New.
> (riscv_expand_prologue): Use riscv_gen_gpr_save_insn to gen gpr_save.
> (riscv_gen_gpr_save_insn): New.
> ...
Looks good to me. Though these two new functions should
On Wed, Jun 10, 2020 at 1:08 AM Kito Cheng wrote:
> * config/riscv/riscv-protos.h (riscv_output_gpr_save): Remove.
> * config/riscv/riscv-sr.c (riscv_sr_match_prologue): Update
> value.
> * config/riscv/riscv.c (riscv_output_gpr_save): Remove.
> *
On Fri, Jun 12, 2020 at 7:30 AM 戎杰杰(无音) wrote:
> - The first version for vector extension and verified on rv64imafdcv linux
> target with qemu.
There is no RISC-V vector extension. There is only a draft proposal
to add one to the ISA. Our policy has always been to wait for draft
proposals to
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.
> > *
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
>
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.
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
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
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
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
> > >
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
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
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
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
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
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
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
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:
>
> *
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
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:
>
>
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
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,
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
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
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
>
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
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
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
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
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
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
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
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
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
# 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
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_
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
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
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:
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
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
>
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.
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.
>
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:
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
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
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
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
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
701 - 800 of 828 matches
Mail list logo