On Mon, Mar 31, 2025 at 11:34 PM Robin Dapp wrote:
>
> >> Yeah...and I also don't like the magic "ceil(AVL / 2) ≤ vl ≤ VLMAX if
> >> AVL < (2 * VLMAX)" rule...
> >
> > +1, spec has some description about this but I am not sure if I really get
> > the point.
> >
> > From Spec:
> >
> > "For exampl
On Mon, Mar 3, 2025 at 3:40 PM Vineet Gupta wrote:
>
> On 3/3/25 15:18, Andrew Waterman wrote:
> >> So in some convoluted way both the above scenarios have callee-saved
> >> semantics
> >> for FRM, except for the leaf function which unconditionally sets FRM wher
On Mon, Mar 3, 2025 at 2:37 PM Vineet Gupta wrote:
>
> Hi Pan, Andrew
>
> I'm trying to understand the semantics of FRM as it intersects with calling
> convention.
> psABI is not explicit about it and refers to C standard [1]
>
> > On 2/14/25 03:39, Li, Pan2 wrote:
>
> [snip]
>
>
> > With option "
The code change looks good to me. I defer to y'all's judgment as to
how it slots into the release.
On Sat, Feb 8, 2025 at 9:33 AM Jeff Law wrote:
>
>
>
> On 2/7/25 9:34 PM, Vineet Gupta wrote:
> > A couple of Vector pseudoinstructions use x0 scalar which being regfile
> > crosser could be ineffi
Replacing x0 with 0 when possible is fine; it should never hurt and
might help on some uarches. (Of course, future versions of those
uarches will eventually be forced to improve handling of x0, anyway,
since as Vineet notes, some of the interesting cases don't have
immediate forms.)
But I don't t
On Fri, Feb 7, 2025 at 5:51 AM Jeff Law wrote:
>
>
>
> On 2/7/25 5:59 AM, Andrew Waterman wrote:
> > This patch runs counter to the ABI spec, which states that vxrm is not
> > preserved across calls and is volatile upon function entry [1]. vxrm
> > does not play the
This patch runs counter to the ABI spec, which states that vxrm is not
preserved across calls and is volatile upon function entry [1]. vxrm
does not play the same role as frm plays in the calling convention.
(I won't get into the rationale in this email, but the rationale isn't
especially importan
On Fri, Oct 11, 2024 at 6:26 AM Jeff Law wrote:
>
> I probably spent way more time on this than it's worth...
>
> I was looking at the code we generate for vector SAD and noticed that we
> were being a bit silly. Specifically:
>
> li a4,0# 272 [c=4 l=4] *movsi_interna
On Wed, Oct 2, 2024 at 4:41 PM Jeff Law wrote:
>
>
>
> On 10/2/24 4:39 PM, Andrew Waterman wrote:
> > On Wed, Oct 2, 2024 at 5:56 AM Jeff Law wrote:
> >>
> >>
> >>
> >> On 9/5/24 12:52 PM, Palmer Dabbelt wrote:
> >>> We have cheap
On Wed, Oct 2, 2024 at 5:56 AM Jeff Law wrote:
>
>
>
> On 9/5/24 12:52 PM, Palmer Dabbelt wrote:
> > We have cheap logical ops, so let's just move this back to the default
> > to take advantage of the standard branch/op hueristics.
> >
> > gcc/ChangeLog:
> >
> > PR target/116615
> > *
On Thu, Sep 5, 2024 at 2:52 PM Jeff Law wrote:
>
>
>
> On 9/5/24 12:52 PM, Palmer Dabbelt wrote:
> > We have cheap logical ops, so let's just move this back to the default
> > to take advantage of the standard branch/op hueristics.
> >
> > gcc/ChangeLog:
> >
> > PR target/116615
> > *
As is normally the case when it comes to matters of RISC-V
International, Palmer is taking the least-charitable interpretation
and then adding a generous dollop of falsehoods. The RVA23U64 profile
is set to be ratified soon, and that's our intended target for apps
processors.
On Tue, Sep 3, 2024
On Fri, Jul 19, 2024 at 11:08 AM Jeff Law wrote:
>
>
>
> On 7/19/24 2:55 AM, demin.han wrote:
> > Currently, some binops of vector vs double scalar under RV32 can't
> > translated to vf but vfmv+vxx.vv.
> >
> > The cause is that vec_duplicate is also expanded to broadcast for double
> > mode
> >
On Thu, Aug 15, 2024 at 9:23 PM Jeff Law wrote:
>
>
>
> On 8/13/24 10:16 PM, Li, Pan2 wrote:
> >> How specifically is it avoided for SI? ISTM it should have the exact
> >> same problem with a constant like 0x8000 in SImode on rv64 which is
> >> going to be extended to 0x8000.
> >
+1 to any change that reduces the number of fflags accesses.
On Fri, Jun 28, 2024 at 5:54 PM Vineet Gupta wrote:
>
> Currently isfinite and isnormal use float compare instructions with fp
> flags save/restored around them. Our perf team complained this could be
> costly in uarch. RV Base ISA alr
On Tue, Jun 4, 2024 at 10:31 AM Patrick O'Neill wrote:
>
> On 6/3/24 20:00, Kito Cheng wrote:
>
> Hi Patrick:
>
> One dumb question around Zaamo and Zalrsc, could we still got correct
> atomic semantic with only Zaamo or only Zalrsc? I guess Zalrsc only
> probably ok, but how about Zaamo only?
>
>
On Tue, May 7, 2024 at 9:46 AM Jonathan Wakely wrote:
>
> On Tue, 7 May 2024 at 17:39, Jonathan Wakely wrote:
> >
> > On Tue, 7 May 2024 at 17:33, Jeff Law wrote:
> > >
> > >
> > >
> > > On 5/7/24 9:36 AM, Andreas Schwab wrote:
> > > > On Mai 07 2024, Jonathan Wakely wrote:
> > > >
> > > >> +#ifd
On Tue, Apr 30, 2024 at 8:54 PM Jeff Law wrote:
>
>
> In doing some preparation work for using zbkb's pack instructions for
> constant synthesis I figured it would be wise to get a sense of how well
> our constant synthesis is actually working and address any clear issues.
>
> So the first glaring
On Tue, Mar 19, 2024 at 1:05 PM Vineet Gupta wrote:
>
>
>
> On 3/19/24 06:10, Jeff Law wrote:
> > On 3/19/24 12:48 AM, Andrew Waterman wrote:
> >> On Mon, Mar 18, 2024 at 5:28 PM Vineet Gupta wrote:
> >>> On 3/16/24 13:21, Jeff Law wrote:
t type; the range of the integral types isn't supposed to
affect the result. The original code was correct in this regard, too.
>
> There's also a pair of changes to the ISA in 2020 that added the
> conversion inexact handling requirement, it was a grey area before. I
> don'
On Mon, Mar 18, 2024 at 5:28 PM Vineet Gupta wrote:
>
>
>
> On 3/16/24 13:21, Jeff Law wrote:
> > | 59944:add s0,sp,2047 <
> > | 59948:mv a2,a0
> > | 5994c:mv a3,a1
> > | 59950:mv a0,sp
> > | 59954:li a4,1
> > | 59958:lui a1,0x1
On Fri, Mar 1, 2024 at 4:07 AM Robin Dapp wrote:
>
> Hi Han,
>
> in addition to what Juzhe mentioned (and that late-combine is going
> to handle such cases) it should be noted that register pressure
> should not be the only consideration here. Many uarchs have a higher
> latency for register-file
On Fri, Dec 15, 2023 at 1:38 PM Jeff Law wrote:
>
>
>
> On 12/12/23 20:54, Palmer Dabbelt wrote:
> > I can't actually find anything in the ISA manual that makes Ztso imply
> > A. In theory the memory ordering is just a different thing that the set
> > of availiable instructions (ie, Ztso without
On Fri, Oct 27, 2023 at 6:44 AM Jeff Law wrote:
>
>
>
> On 10/27/23 01:37, juzhe.zh...@rivai.ai wrote:
> > LGTM from my side.
> >
> > The original integer division COST seems too low.
> Almost certainly, though there may be good reasons why it was initially
> set so low. I'm generally hesitant to
On Fri, Oct 27, 2023 at 6:55 AM Jeff Law wrote:
>
>
>
> On 10/27/23 01:49, Robin Dapp wrote:
> >> @@ -346,7 +346,7 @@ static const struct riscv_tune_param rocket_tune_info
> >> = {
> >> {COSTS_N_INSNS (4), COSTS_N_INSNS (5)}, /* fp_mul */
> >> {COSTS_N_INSNS (20), COSTS_N_INSNS (20)},
On Tue, Oct 10, 2023 at 8:26 PM Jeff Law wrote:
>
>
>
> On 10/10/23 18:24, Andrew Waterman wrote:
> > I remembered another concern since we discussed this patch privately.
> > Using ra for long calls results in a sequence that will corrupt the
> > return-address sta
I remembered another concern since we discussed this patch privately.
Using ra for long calls results in a sequence that will corrupt the
return-address stack. Corrupting the RAS is potentially more costly
than mispredicting a branch, since it can result in a cascading
sequence of mispredictions a
Vineet,
Your understanding of the ABI is correct; both int and unsigned int
arguments must already be sign-extended. The sext.w is semantically
unnecessary; the bltu could correctly reference a1 instead of a6.
Good luck eliminating it!
Andrew
On Mon, Sep 18, 2023 at 12:45 PM Vineet Gupta wro
Note this is a size-speed tradeoff, as the Zcb extension has a
16-bit-wide C.NOT instruction. Might want to suppress this
optimization when Zcb is present and the function is being optimized
for size.
On Mon, Sep 11, 2023 at 9:52 AM Jivan Hakobyan via Gcc-patches
wrote:
>
> In the case when we
On Sun, Aug 13, 2023 at 12:53 PM Philipp Tomsich
wrote:
>
> On Sat, 12 Aug 2023 at 01:31, Jeff Law via Gcc-patches
> wrote:
> >
> >
> >
> > On 8/9/23 16:39, Tsukasa OI wrote:
> > > On 2023/08/10 5:05, Jeff Law wrote:
> >
> > >> I'd tend to think we do not want to expose the intrinsic unless the
>
On Sat, Jul 1, 2023 at 7:04 AM Jeff Law wrote:
>
>
>
> On 7/1/23 02:00, Andrew Waterman wrote:
>
> >
> > Yeah, that might end up being a false economy for superscalars.
> >
> > In general, I wouldn't recommend spending too many cleverness beans on
>
On Fri, Jun 30, 2023 at 5:36 PM Palmer Dabbelt wrote:
>
> On Fri, 30 Jun 2023 17:25:54 PDT (-0700), Andrew Waterman wrote:
> > On Fri, Jun 30, 2023 at 5:13 PM Vineet Gupta wrote:
> >>
> >>
> >>
> >> On 6/30/23 16:50, Andrew Waterman wrote:
> &g
On Fri, Jun 30, 2023 at 5:13 PM Vineet Gupta wrote:
>
>
>
> On 6/30/23 16:50, Andrew Waterman wrote:
> > I don't believe this is correct; the subtraction is needed to account
> > for the fact that the low part might be negative, resulting in a
> > borrow from
I don't believe this is correct; the subtraction is needed to account
for the fact that the low part might be negative, resulting in a
borrow from the high part. See the output for your test case below:
$ cat test.c
#include
int main()
{
unsigned long result, tmp;
asm (
"li %1,-252645
This turns out to be a de-optimization for implementations with any
amount of temporal execution (which is most machines with LMUL > 1 and
even some machines with LMUL <= 1). Scalar instructions are generally
cheaper than multi-cycle-occupancy vector operations, so reducing
scalar work by increasi
On Fri, May 5, 2023 at 2:42 PM Hans Boehm wrote:
>
> I think A.6-tso also needs to change the last line in the table from lr.aqrl
> ... sc to lr.aq ... sc.rl, otherwise I think we have problems with a
> subsequent A.7-tso generated l.aq . Otherwise I agree.
>
> I certainly agree that, given the
On Sat, Apr 29, 2023 at 8:06 AM Jeff Law via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
>
>
>
> On 4/28/23 20:55, Li, Pan2 wrote:
> > Thanks Jeff for comments.
> >
> > It makes sense to me. For the EQ operator we should have CONSTM1.
> That's not the way I interpret the RVV documentation. Of co
On Fri, Mar 17, 2023 at 6:16 AM Philipp Tomsich
wrote:
>
> On Fri, 17 Mar 2023 at 09:31, Richard Biener
> wrote:
> >
> > On Thu, Mar 16, 2023 at 4:27 PM Manolis Tsamis
> > wrote:
> > >
> > > For this C testcase:
> > >
> > > void g();
> > > void f(unsigned int *a)
> > > {
> > > if (++*a == 1)
On Sat, Feb 18, 2023 at 1:30 PM Palmer Dabbelt wrote:
>
> On Sat, 18 Feb 2023 13:06:02 PST (-0800), jeffreya...@gmail.com wrote:
> >
> >
> > On 2/18/23 11:26, Palmer Dabbelt wrote:
> >> On Fri, 17 Feb 2023 06:02:40 PST (-0800), gcc-patches@gcc.gnu.org wrote:
> >>> Hi all,
> >>> If we have division
On Sat, Dec 17, 2022 at 2:21 AM Andreas Schwab wrote:
>
> On Dez 17 2022, Andrew Waterman wrote:
>
> > On Sat, Dec 17, 2022 at 2:10 AM Andreas Schwab
> > wrote:
> >>
> >> On Dez 17 2022, Andrew Waterman wrote:
> >>
> >> > It took me a
On Sat, Dec 17, 2022 at 2:10 AM Andreas Schwab wrote:
>
> On Dez 17 2022, Andrew Waterman wrote:
>
> > It took me a few minutes to understand the purpose of this chicanery, but
> > there's indeed a contradiction in the ISA spec. HINT instructions _do_
> > affect
It took me a few minutes to understand the purpose of this chicanery, but
there's indeed a contradiction in the ISA spec. HINT instructions _do_
affect architectural state in a limited fashion--namely, updating the PC.
So, it's incorrect to say that PAUSE changes no architectural state.
Because th
On Fri, Dec 16, 2022 at 1:59 PM Palmer Dabbelt wrote:
>
> On Fri, 16 Dec 2022 12:01:04 PST (-0800), jeffreya...@gmail.com wrote:
> >
> >
> > On 12/14/22 04:36, juzhe.zh...@rivai.ai wrote:
> >> From: Ju-Zhe Zhong
> >>
> >> Since store instructions doesn't care about tail policy, we remove
> >> vst
On Thu, Nov 17, 2022 at 10:52 AM Philipp Tomsich
wrote:
>
> On Thu, 17 Nov 2022 at 19:33, Andrew Waterman wrote:
> >
> > Am I wrong to worry that this will increase dynamic instruction count
> > when used in a loop? The obvious code is more efficient when the
> >
Am I wrong to worry that this will increase dynamic instruction count
when used in a loop? The obvious code is more efficient when the
constant loads can be hoisted out of a loop. Or does the cost model
account for this somehow?
On Sun, Nov 13, 2022 at 12:50 PM Philipp Tomsich
wrote:
>
> Use Z
On Tue, Nov 8, 2022 at 10:11 AM Jakub Jelinek wrote:
>
> On Tue, Nov 08, 2022 at 09:44:40AM -0800, Andrew Waterman wrote:
> > On Tue, Nov 8, 2022 at 3:20 AM Jakub Jelinek via Gcc-patches
> > wrote:
> > >
> > > On Mon, Nov 07, 2022 at 04:41:23PM +0100, Aldy H
On Tue, Nov 8, 2022 at 3:20 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Mon, Nov 07, 2022 at 04:41:23PM +0100, Aldy Hernandez wrote:
> > As suggested upthread, I have also adjusted update_nan_sign() to drop
> > the NAN sign to VARYING if both operands are NAN. As an optimization
> > I keep the
I'm surprised by the hard-coded 128-byte cache line size. If we need
to hard-code a value, it should be 64 (in accordance with the RVA
profiles, see https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc),
but ideally this would be queried dynamically.
On Thu, Oct 27, 2022 at 3:51 AM Xi
I agree with Kito; I don't support merging this patch. My reasoning is twofold:
- The default settings should be fairly neutral, avoiding codegen that
severely disadvantages some targets. Misaligned memory accesses are
certainly a problematic case in that respect. (And it's highly
asymmetric: t
On Fri, May 13, 2022 at 3:38 AM Philipp Tomsich
wrote:
> On Fri, 13 May 2022 at 12:00, Christoph Müllner
> wrote:
> >
> > On Wed, May 11, 2022 at 2:02 AM Palmer Dabbelt
> wrote:
> > >
> > > [Sorry for cross-posting to a bunch of lists, I figured it'd be best to
> > > have all the discussions in
Neither K nor J is an extension that exists, and so it doesn't make
sense to mandate any particular ordering. The better change would be
to delete the letters `k' and `j' from that string, so that we aren't
enforcing constraints that don't serve a useful purpose.
cf.
https://github.com/riscv/ris
LGTM, thanks for correcting this oversight in my patch.
On Thu, Jan 27, 2022 at 2:09 PM Maciej W. Rozycki wrote:
>
> Document new `auipc' and `bitmanip' `type' attributes added respectively
> with commit 88108b27dda9 ("RISC-V: Add sifive-7 pipeline description.")
> and commit 283b1707f237 ("RISC
On Thu, Jan 20, 2022 at 12:30 PM Palmer Dabbelt wrote:
>
> On Thu, 20 Jan 2022 07:44:25 PST (-0800), ma...@embecosm.com wrote:
> > RISC-V FMIN and FMAX machine instructions are IEEE-754-conformant[1]:
> >
> > "For FMIN and FMAX, if at least one input is a signaling NaN, or if both
> > inputs are q
On Thu, Jul 22, 2021 at 10:27 AM Palmer Dabbelt wrote:
>
> On Thu, 22 Jul 2021 06:29:46 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
> > Could you add a testcase? Otherwise LGTM.
> >
> > Option: -O2 -mtune=thead-c906 -march=rv64gc -mabi=lp64
> > void foo(char *dst){
> >__builtin_memset(dst, 0,
On Thu, Apr 29, 2021 at 3:02 PM Jim Wilson wrote:
>
> 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
On Wed, Apr 28, 2021 at 1:18 PM Jim Wilson wrote:
>
> 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
>
On Tue, Apr 27, 2021 at 12:18 AM Levy Hsu wrote:
>
> From: LevyHsu
>
> Added implementation for builtin overflow detection, new patterns are listed
> below.
>
> ---
> Addition:
>
> signed addition (SImode with RV32 || DImode with RV64):
I've got a contrary opinion:
Since HINTs are guaranteed to execute as no-ops--e.g., this one is
just a FENCE instruction, which is already a mandatory part of the
base ISA--they don't _need_ to be called out as separate extensions in
the toolchain.
Although there's nothing fundamentally wrong wit
I'm having trouble understanding why different ports chose their
various constants--e.g., SPARC uses 1<<29 for 32-bit and 1<<43 for
64-bit, whereas x86 uses 1<<29 and 0x7fff8000, respectively. So I
can't comment on the choice of the constant 1<<36 for RISC-V. But
isn't it a problem that 1<<36 is
IIRC, I didn't use this approach originally because I wanted to avoid
the additional dynamic instruction. But I agree that code size is the
more important metric for users of this feature. LGTM.
On Thu, Jul 30, 2020 at 1:56 PM Maciej W. Rozycki via Gcc-patches
wrote:
>
> Rewrite code sequences
On Wed, Jun 24, 2020 at 5:56 PM Jim Wilson wrote:
>
> 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
> > > V
Thank you!
On Wed, May 6, 2020 at 12:43 AM Jakub Jelinek wrote:
>
> Hi!
>
> Similarly to the fixes on many other targets, riscv needs to use TARGET_EXPR
> to avoid having the create_tmp_var_raw temporaries without proper DECL_CONTEXT
> and not mentioned in local decls.
>
> Committed as obvious t
Nevertheless, as Jim observed, it's a great burden on the RISC-V
backend maintainers to support all these passes. Are you saying WD is
willing to put its money where its mouth is and will provide active
support for these passes?
On Thu, Oct 31, 2019 at 2:42 AM Nidal Faour wrote:
>
> A tests case
I don't know enough to say whether the legitimize_address hook is
sufficient for the intended purpose, but I am sure that RISC-V's
concerns are not unique: other GCC targets have to cope with
offset-size constraints that are coupled to register-allocation
constraints.
On Sat, Oct 26, 2019 at 11:2
x5 is used as an alternate link register, so using it for sibcalls
will confuse hardware return-address stacks and reduce performance for
implementations that have one.
The reason I excluded a0-a7 is that those are used to pass arguments
to the sibcallee. It's of course possible that's more restr
Thanks, Tom.
On Sun, Nov 12, 2017 at 8:44 AM, Tom de Vries
wrote:
> Hi,
>
> this patch wraps riscv.h's ASM_OUTPUT_LABELREF in "do {} while (0)".
>
> Build for riscv64.
>
> Committed as obvious.
>
> Thanks,
> - Tom
>
Thanks for caring enough about our patches to even notice the grammar :)
On Tue, Oct 31, 2017 at 11:09 PM, Sandra Loosemore
wrote:
> On 10/31/2017 10:27 PM, Andrew Waterman wrote:
>>
>> I have to disagree. It's standard to not hyphenate an
>> adverb-adjective compound,
I have to disagree. It's standard to not hyphenate an
adverb-adjective compound, since they tend not to be ambiguous. But
if the standard in the GCC documentation is to hyphenate, I will not
stand in the way!
On Tue, Oct 31, 2017 at 8:47 PM, Sandra Loosemore
wrote:
> On 10/31/2017 06:54 PM, Pal
Thank you for the fix and the cleanup, Jeff!
Approved.
And thanks for the reminder about the MAINTAINERS file.
On Tue, Feb 7, 2017 at 2:45 AM, Kyrill Tkachov
wrote:
> Hi all,
>
> I tried building a cc1 for riscv-x-elf and I got a build error about
> INT16_MAX not being defined on my system.
> I think it's not a standard macro. This patch
On Tue, Jan 31, 2017 at 10:01 AM, Richard Henderson wrote:
> On 01/30/2017 04:53 PM, Andrew Waterman wrote:
>> The ISA spec references an out-of-date calling convention, and will be
>> removed in the next revision to orthogonalize the ABI from the ISA.
>> We are in the proce
On Tue, Jan 31, 2017 at 10:32 AM, Richard Henderson wrote:
> On 01/30/2017 05:10 PM, Andrew Waterman wrote:
>>>> +(define_expand "clear_cache"
>>>> + [(match_operand 0 "pmode_register_operand")
>>>> + (match_operand 1 "pmode_re
On Fri, Jan 20, 2017 at 10:41 PM, Richard Henderson wrote:
> On 01/11/2017 06:30 PM, Palmer Dabbelt wrote:
>>
>> +(define_register_constraint "f" "TARGET_HARD_FLOAT ? FP_REGS : NO_REGS"
>> + "A floating-point register (if available).")
>> +
>
>
> I know this is the Traditional Way, but I do wonde
Thanks for the feedback, Richard. We've addressed the bulk of it, and
added some explanatory comments in the few cases where the current
implementation makes sense, but for less than obvious reasons. We
will submit a v2 patch set reflecting these changes in the next couple
of days.
A few respons
On Fri, Jan 20, 2017 at 10:53 PM, Richard Henderson wrote:
> On 01/11/2017 06:30 PM, Palmer Dabbelt wrote:
>>
>> +__riscv_save_12:
>> + addi sp, sp, -112
>> + li t1, 0
>> + sd s11, 8(sp)
>> + j .Ls10
>> +
>> +__riscv_save_11:
>> +__riscv_save_10:
>> + addi sp, sp, -112
>> + li t1, -16
>
>
>
name.
>
> Stefan O'Rear wrote on the RISC-V sw-dev list that he would prefer to
> encode the ABI specifier as part of the ld.so filename and put
> everything in /lib instead of differentiating the directory by XLEN,
> which would keep things largely similar to the other Linux pl
On Thu, Jan 12, 2017 at 1:38 PM, Joseph Myers wrote:
> On Wed, 11 Jan 2017, Palmer Dabbelt wrote:
>
>> +#include
>
> This is included in system.h, so don't include it here.
OK.
>
>> + error ("unknown cpu `%s' for -mtune", cpu_string);
>
> This is using very-old-style `' quotes. Diagnostics sh
On Thu, Jan 12, 2017 at 2:30 PM, Joseph Myers wrote:
> On Wed, 11 Jan 2017, Palmer Dabbelt wrote:
>
>> +static void
>> +riscv_parse_arch_string (const char *isa, int *flags)
>
> This should be passed the location from riscv_handle_option...
>
>> + error ("-march=%s: ISA string must begin with
Thanks again for your feedback.
On Thu, Jan 12, 2017 at 3:30 PM, Joseph Myers wrote:
> On Wed, 11 Jan 2017, Palmer Dabbelt wrote:
>
>> +riscv*-*-linux*)
>> + tmake_file="${tmake_file} t-softfp-sfdf riscv/t-softfp${host_address}
>> t-softfp riscv/t-elf riscv/t-elf${host_address}"
>> + ext
On Thu, Jan 12, 2017 at 3:42 PM, Joseph Myers wrote:
> On Wed, 11 Jan 2017, Palmer Dabbelt wrote:
>
> As I understand it, you have -m options that can change the ABI between
> 32-bit and 64-bit. In such a case you mustn't check for riscv*64*-*-*
> target triplets in the testsuite, since that beha
Thank you for taking the time to give us feedback.
On Thu, Jan 12, 2017 at 9:30 AM, Joseph Myers wrote:
> General observation: I see no documentation (no changes to .texi files)
> anywhere in this patch series. I also don't see updates to config-list.mk
> to add RISC-V targets to the set that bu
ilure in test
gcc.dg/atomic/stdatomic-op-1.c, and I've confirmed that this patch
fixes it. x86_64-unknown-linux still bootstraps, but that is admittedly
of little significance, since it doesn't use these routines.
2015-01-09 Andrew Waterman
* fop_n.c (libat_fetch_op): Align
64-unknown-linux still bootstraps, but that is admittedly
of little significance, since that target doesn't use these routines.
FYI, I don't have commit access.
2015-01-09 Andrew Waterman
* fop_n.c (libat_fetch_op): Align address to word boundary.
---
libatomic/fop_n.c | 6 +++--
Thank you for approving the patch. I neglected to mention that I do
not have write access. Would you or someone else be so kind as to
commit this?
On Fri, Nov 7, 2014 at 5:20 AM, Richard Henderson wrote:
> On 11/06/2014 09:24 PM, Andrew Waterman wrote:
>> 2014-10-23 Andrew
x27;m working on as a failure in test
gcc.dg/atomic/c11-atomic-exec-2.c, and I've confirmed that this patch
fixes it. I also verified that x86_64-unknown-linux still bootstraps
(which is admittedly vacuous, since x86-64 doesn't exercise this code).
2014-10-23 Andrew Waterma
inux still bootstraps
(which is admittedly vacuous, since x86-64 doesn't exercise this code).
2014-10-23 Andrew Waterman
* cas_n.c (libat_compare_exchange): Add missing cast.
---
libatomic/cas_n.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libatomic/cas_n.c b/li
86 matches
Mail list logo
