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
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
>
riscv port Andrew Waterman
-riscv port Jim Wilson
+riscv port Jim Wilson
rs6000/powerpc portDavid Edelsohn
rs6000/powerpc portSegher Boessenkool
rs6000 vector extnsAldy Hernandez
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
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):
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.
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
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:
>
>
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 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
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
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 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 ->
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
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 Thu, Jun 24, 2021 at 7:26 PM ALO via Gcc wrote:
> foo.c: In function '__fp16 foo(__fp16, __fp16)':
> foo.c:6:23: error: call of overloaded 'exp(__fp16&)' is ambiguous
> 6 | return a + std::exp(b);
> | ^
>
No, there isn't a solution for this. You might want to try an ARM port
clang/gcc to
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 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, 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 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 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
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
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 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 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 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 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,
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 Sat, Apr 3, 2021 at 6:24 PM Simon Marchi via Gcc wrote:
> The default debug format (when using only -g) for the AVR target is
> stabs. Is there a reason for it not being DWARF, and would it be
> possible to maybe consider possibly thinking about making it default to
> DWARF? I am asking
On Wed, Mar 31, 2021 at 8:27 AM PKU via Gcc wrote:
> I’m trying to get my school to sign the copyright disclaimer.
> Unfortunately the officials are reluctant to do that. Can anyone suggest
> what to do next?
>
Maybe the PLCT Lab at the Chinese Academy of Sciences can help. They are
doing GCC
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
On Wed, Feb 24, 2021 at 9:30 AM Maciej W. Rozycki wrote:
> On Wed, 24 Feb 2021, Jiaxun Yang wrote:
>
> > For RISC-V, %pcrel_lo shall point to the label of corresponding
> %pcrel_hi,
> > like
> >
> > .LA0:
> > auipca0, %pcrel_hi(sym)
> > addi a0, a0, %pcrel_lo(.LA0)
>
> I
On Wed, Feb 24, 2021 at 6:18 AM Jiaxun Yang wrote:
> I found it's very difficult for GCC to generate this kind of pcrel_lo
> expression,
> RTX label_ref can't be lower into such LOW_SUM expression.
>
Yes, it is difficult. You need to generate a label, and put the label
number in an unspec in
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
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
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
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
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
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
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,
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 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 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 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 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
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 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
I'm not aware of any other target that has a similar feature, so I thought
a bit of discussion first might be useful.
For most ISAs, there is one organization that owns it, and does development
internally, in private. For RISC-V, the ISA is owned by RISC-V
International which has no developers.
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 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
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 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 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 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 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
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: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 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 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 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 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 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 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 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 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 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
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 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, 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 Mon, Nov 2, 2020 at 11:45 PM Jojo R wrote:
> From origin insn seqs, I think the insn 'r500=unspec[r100] 300’ is in
> Good place because of the bypass of my pipeline description, it is not
> needed to schedule.
> ...
> Is there any way to control my case ?
> Or my description of pipeline is
# 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 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 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 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 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 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 Wed, Sep 30, 2020 at 11:35 PM Richard Biener
wrote:
> On Wed, Sep 30, 2020 at 10:01 PM Jim Wilson wrote:
> > We have a lot of examples in gcc/testsuite/gcc.target/riscv/rvv that
> > we are using for testing the vector support.
>
> That doesn't seem to exist (but maybe i
On Tue, Sep 29, 2020 at 11:40 PM Richard Biener
wrote:
> But this also doesn't work on GIMPLE. On GIMPLE riscv_vlen would
> be a barrier for code motion if you make it __attribute__((returns_twice))
> since then abnormal edges distort the CFG in a way preventing such motion.
At the gimple
On Tue, Sep 29, 2020 at 7:22 PM 夏 晋 wrote:
> vint16m1_t foo3(vint16m1_t a, vint16m1_t b){
> vint16m1_t add = a+b;
> vint16m1_t mul = a*b;
> vsetvl_e8m1(32);
> return add + mul;
> }
Taking another look at your example, you have type confusion. Using
vsetvl to specify an element width of
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 Tue, Sep 29, 2020 at 3:47 AM 夏 晋 via Gcc wrote:
> I tried to set the "vlen" after the add & multi, as shown in the following
> code:
> vf32 x3,x4;
> void foo1(float16_t* input, float16_t* output, int vlen){
> vf32 add = x3 + x4;
> vf32 mul = x3 * x4;
> __builtin_riscv_vlen(vlen);
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 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
On Wed, Sep 23, 2020 at 7:51 AM Ilya Leoshkevich via Gcc
wrote:
> Is this restriction still valid today? Is there a reason we can't
> introduce new pseudos in a splitter before LRA?
See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
for an example of what can go wrong when a splitter
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
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 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
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 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
>
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
>
1 - 100 of 828 matches
Mail list logo
