This fixes a problem found by someone trying to use the new RISC-V interrupt
attribute support. With a slightly non-trivial example, and the -g option, we
get an abort in dwarf2cfi for an inconsistent CFI state. This is my fault
for not making the new interrupt return patterns look enough like re
On Mon, Jul 2, 2018 at 8:04 PM, Kito Cheng wrote:
> Does it possible just combine those pattern into simple_return
> pattern, and then check the function type and output correct return
> instruction in riscv_output_return?
There might be problems with optimizations thinking this is a regular
retu
On 07/05/2018 09:51 AM, Palmer Dabbelt wrote:
When I try to build it I see "Unsupported RISC-V target
riscv-unknown-elf", so there's at least some extra autoconf wizadry that
needs to happen in here. I'm actually not sure what the "riscv-*"
tuples are supposed to do so I've added Liviu as I do
On Thu, Jul 5, 2018 at 11:31 AM, Liviu Ionescu wrote:
> If this is really a problem I guess you can blacklist it somehow.
> But this proves once again that Linux native compilers and cross embedded
> toolchains should be processed differently.
It isn't a major problem. There is the issue that t
I was asked about Ada support, so I tried cross building a native RISC-V Linux
Ada compiler, and it turned out to be possible with a little bit of work. I
just started with the MIPS support, and then fixed everything that was
obviously wrong: endianness, error numbers, signal numbers, struct_sigac
These are some patches I needed to complete my cross build of a native
riscv linux Ada compiler. Some paths were different on the build machine
and host machine. I needed to pass options into gnatmake to work around this,
and that required fixing some makefile rules to use $(GNATMAKE) instead of
Support for riscv-* was added to config.sub upstream, so we need to handle it
in gcc configure. Just one place needs to be fixed for now to make this work.
Tested with riscv{32,64}-{elf,linux} and riscv-elf cross builds.
Committed.
Jim
gcc/
* config.gcc (riscv*-*-*): When setti
On Thu, Jul 5, 2018 at 12:22 PM, Liviu Ionescu wrote:
>> On 5 Jul 2018, at 22:17, Jim Wilson wrote:
>> ... I can fix the gcc config.sub to make it work.
> Or you can edit `gcc/config.gcc` and trigger an error for `riscv-linux*`.
I added patches to binutils and gcc to make riscv-
On Fri, Jul 6, 2018 at 12:18 AM, Arnaud Charlet wrote:
>> These are some patches I needed to complete my cross build of a native
>> riscv linux Ada compiler. Some paths were different on the build machine
>> and host machine. I needed to pass options into gnatmake to work around
>> this,
>> and
On Fri, Jul 6, 2018 at 12:16 AM, Arnaud Charlet wrote:
>> Ada is a low priority side project for me, so if you want non-trivial changes
>> it may be a while before I can get to them. There is a lot of other stuff
>> higher on my priority list at the moment, such as getting native gdb support
>> w
On Sat, Jul 7, 2018 at 12:25 AM, Andreas Schwab wrote:
> On Jul 05 2018, Jim Wilson wrote:
>
>> Tested with native riscv-linux bootstrap with Ada enabled.
>
> I'm getting a lot of errors from the assembler "non-constant .uleb128 is
> not supported" when tryin
On Fri, Jul 6, 2018 at 12:55 AM, Eric Botcazou wrote:
>> Ada doesn't use trampolines if you define...
>>
>> > + Always_Compatible_Rep : constant Boolean := False;
>>
>> ...this to False.
>
> And also define TARGET_CUSTOM_FUNCTION_DESCRIPTORS for the architecture.
I tried adding the missing
Thanks to Eric Botcazou, this eliminates almost all of the remaining Ada
testsuite failures by adding a missing definition for the target specific
handling of function descriptors.
Tested with a native riscv64-linux bootstrap with Ada, and running the Ada
testsuite. There are only 4 failures left
On Sat, Jul 7, 2018 at 9:41 AM, Eric Botcazou wrote:
> You're welcome. Are the 4 remaining failures related to stack checking?
FAIL: gnat.dg/debug11.adb scan-assembler-times 0x5a.*DW_AT_discr_list 1
FAIL: gnat.dg/debug11.adb scan-assembler-times 0x80.*DW_AT_discr_list 1
FAIL: gnat.dg/trampoline4
On Sat, Jul 7, 2018 at 10:06 AM, Andreas Schwab wrote:
> On Jul 07 2018, Jim Wilson wrote:
>
>> If you build and install binutils, and then build and install gcc, the
>> build will work.
>
> Not if the compiler was built in a canadian cross. That's the only way
&
On Sat, Jul 7, 2018 at 11:30 AM, Andreas Schwab wrote:
> On Jul 07 2018, Jim Wilson wrote:
>> if you have separate binutils and gcc source trees, the build should
>> work.
>
> It's not the canadian cross build that fails, but the subsequent native
> build using the (
On Sat, Jul 7, 2018 at 2:43 PM, Andreas Schwab wrote:
> On Jul 07 2018, Jim Wilson wrote:
>
>> This is also presumably what the debian, fedora, and gentoo folks did
>> to get their first native compiler. They didn't report any problems.
>
> Of course, they didn&
On Thu, Jul 12, 2018 at 7:53 AM, Kito Cheng wrote:
> ping.
> On Fri, Jul 6, 2018 at 4:38 PM Kito Cheng wrote:
>>
>> Hi all:
>>
>> This patch implemented TARGET_MERGE_DECL_ATTRIBUTES hook to check the
>> interrupter is all compatible, tested with rv32ima and rv64ima elf
>> toolchain.
>>
>> gcc/Cha
This eliminates one Ada testsuite failure, by adding riscv*-*-* for the list
of targets that expect this warning. This was pre-approved by Eric Botcazou.
Tested with a riscv64-linux native Ada testsuite run. There was one less
failure with this patch.
Committed.
Jim
gcc/testsuite/
On Thu, Jul 12, 2018 at 8:56 AM, Pierre-Marie de Rodat
wrote:
> I don’t have much more to say than debug11.adb’s comment ;-)
>
>> This testcase checks that in the DWARF description of the variant type
>> below, the C discriminant is properly described as unsigned, hence the
>> 0x5a
>> ('Z') and 0x
This fixes an oversight. I suspect that there was a RISC-V QEMU bug allowing
stacks to be executable by default, so we didn't see the problem until we
started running the gcc testsuite on hardware. This was also confused by the
late ABI change to the cache flush support when upstreaming the glibc
On Mon, Jul 16, 2018 at 3:24 AM, Andreas Schwab wrote:
> * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: New file.
>
I'm not familiar with the details of these baseline symbol files.
When I try running "make new-abi-baseline" on my Fedora riscv64-linux
system using top of tree,
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
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, in
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 r
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 co
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 wit
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 wo
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 co
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 multilib
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 appro
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
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 chec
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
>
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, 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
On Mon, Oct 21, 2019 at 5:26 AM Andrew Burgess
wrote:
> Below is a new versions of this patch, I believe that this addresses
> the review comments from the earlier version. In addition this has
> been tested using Jim's idea of forcing -msave-restore (if the flag is
> not otherwise given) and I n
On Wed, Oct 23, 2019 at 4:16 AM Richard Biener
wrote:
> Note I delayed thinking about relaxing the single-vector-size
> constraint in the vectorizer until after we're SLP only because
> that looked more easily done there. I also remember patches
> relaxing this a bit from RISCV folks.
Probably n
On Fri, Oct 25, 2019 at 10:40 AM Craig Blackmore
wrote:
> This patch aims to allow more load/store instructions to be compressed by
> replacing a load/store of 'base register + large offset' with a new load/store
> of 'new base + small offset'. If the new base gets stored in a compressed
> registe
FYI the testcase I'm using to test the patch. Some of the functions
get smaller, some of them get bigger, and some don't change in size
but should when compiled for an rv64 target.
Jim
void
store1z (int *array)
{
array[200] = 0;
array[201] = 0;
array[202] = 0;
array[203] = 0;
}
void
stor
On Fri, Oct 25, 2019 at 10:40 AM Craig Blackmore
wrote:
> The sched2 pass undoes some of the addresses generated by the RISC-V
> shorten_memrefs code size optimization (patch 1/2) and consequently increases
> code size. This patch prevents sched-deps.c from changing an address if it is
> expected
The RISC-V backend wants to use a libcall when optimizing for size if
more than 6 instructions are needed. Emit_move_complex asks for no
libcalls. This case requires 8 insns for rv64 and 16 insns for rv32,
so we get fallback code that emits a loop. Commit_one_edge_insertion
doesn't allow code in
On Thu, Oct 31, 2019 at 4:41 PM Jim Wilson wrote:
> gcc/
> PR middle-end/92263
> * expr.c (emit_move_complex): Only use BLOCK_OP_NO_LIBCALL when
> optimize_insn_for_speed_p is true.
>
> gcc/testsuite/
> PR middle-end/92263
>
Using -mno-fdiv gives linker errors unless we build the missing divide
routines in libgcc always. There is at least one university project
designing RISC-V parts without FP divide that wants to use the option.
Tested by hand with single-float and double-float builds to verify that
the -mno-fdiv o
On Mon, Nov 11, 2019 at 3:45 AM Andreas Schwab wrote:
> Only ubsan is supported so far. This has been tested on openSUSE
> Tumbleweed, there are no testsuite failures.
>
> * configure.tgt (riscv64-*-linux*): Enable build.
I tried this on my riscv64 Fedora system, and I get a build error.
On Mon, Nov 11, 2019 at 3:45 AM Andreas Schwab wrote:
> Only ubsan is supported so far. This has been tested on openSUSE
> Tumbleweed, there are no testsuite failures.
>
> * configure.tgt (riscv64-*-linux*): Enable build.
With a workaround for the ipc_perm/mode issue, I can reproduce the
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_offset f
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 h
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 (DEP_CON
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 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 ha
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 some
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 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 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 patter
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
> func
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 doesn'
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 in
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): Def
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 docs
On Tue, Jan 21, 2020 at 12:22 AM Jakub Jelinek wrote:
> I only see one spot where it has been added and then
> 2019-06-06 Florian Weimer
>
> * sysdeps/unix/sysv/linux/riscv/flush-icache.c: Do not use
> internal GCC preprocessor identifier __has_include__.
> which corrected it to
On Mon, Jan 20, 2020 at 6:44 PM Kito Cheng wrote:
> Thanks, fixed and committed, and it's OK to commit to gcc 8/9 next week?
Yes, that is OK with me.
Jim
On Tue, Jan 21, 2020 at 12:36 AM Jakub Jelinek wrote:
> 2020-01-21 Jakub Jelinek
>
> PR target/9
> * config/riscv/riscv.c (riscv_rtx_costs) : Verify
> the last two operands are CONST_INT_P before using them as such.
>
> * gcc.c-torture/compile/pr9.c: New
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 riscv64-lin
The RISC-V toolchain doesn't support leb128 because of linker relaxation
to reduce code size. This prevents us from computing the leb128 size of a
value at compile time. So do a configure time gas feature check regardless
of gas version.
The libiconv configure change comes from the recent config
ping
Jim
On Thu, Jan 30, 2020 at 2:36 PM Jim Wilson wrote:
>
> The RISC-V toolchain doesn't support leb128 because of linker relaxation
> to reduce code size. This prevents us from computing the leb128 size of a
> value at compile time. So do a configure time gas feature chec
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
* config/riscv/ri
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 t
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 -> we
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
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 b
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 tr
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
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:
>
> https://github.com/riscv-collab/riscv-binu
On Tue, Sep 28, 2021 at 3:05 PM Christoph Muellner <
cmuell...@ventanamicro.com> wrote:
> We talked about this in the T&R 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
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.
>
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): C
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
ABI
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.
>
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 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
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
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 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, t1
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.
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 definite
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 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 s
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 woul
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
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 thre
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 targ
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 indente
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
>
On Wed, Jul 8, 2015 at 3:54 PM, Jeff Law wrote:
> On 07/07/2015 10:29 AM, Jim Wilson wrote:
> This is critically important as various parts of the compiler will take a
> degenerate PHI node and propagate the RHS of the PHI into the uses of the
> LHS of the PHI -- without doing any con
On Tue, Jul 7, 2015 at 2:35 PM, Richard Biener
wrote:
> On July 7, 2015 6:29:21 PM GMT+02:00, Jim Wilson
> wrote:
>>signed sub-word locals. Thus to detect the need for a conversion, you
>>have to have the decls, and we don't have them here. There is also
>
> It pr
On Tue, Jul 14, 2015 at 9:13 AM, Richard Earnshaw
wrote:
> We went through this a couple of weeks back. The backend documentation
> for PROMOTE_MODE says:
I disagree that this is a fully resolved issue. I see clear problems
with how the ARM port uses PROMOTE_MODE.
> " For most machines, the ma
On Wed, Jul 15, 2015 at 6:04 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 14 Jul 2015, Jim Wilson wrote:
>
>> Now that we do have the problem, we can't fix it without an ARM port ABI
>> change, which is undesirable, so we may have to fix it with a MI change.
>
> W
problem may no longer be necessary. I haven't looked at
that.
Jim
Index: gcc/c/ChangeLog
===
--- gcc/c/ChangeLog (revision 229395)
+++ gcc/c/ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2015-10-26 Jim Wilson
+
+ PR debug/66068
1 - 100 of 467 matches
Mail list logo
