https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94136
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94173
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93202
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85492
--- Comment #10 from Andrew Waterman ---
Thanks for the suggestion. Let's go with the CFI-directive approach.
On Sat, Apr 28, 2018 at 5:45 AM, aurelien at aurel32 dot net
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85492
>
> --- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005
--- Comment #2 from Andrew Waterman ---
I realize the documentation doesn't concur with me, but as long as gcc
and libgcc agree on the lock-freeness of the routines, I don't see the
harm. (wrt. rv32ia, at least.)
On Wed, May 30, 2018 at 10:40 PM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91420
--- Comment #2 from Andrew Waterman ---
The RISC-V code models currently in existence place a 2 GiB limit on
the extent of the statically linked portion of a binary. Rather than
a bug, I would describe this as a limitation of the existing code
m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91420
--- Comment #4 from Andrew Waterman ---
In -O2, the compiler materializes ("x" + INT_MIN) by loading that
symbol+offset into a register in one shot, whereas in -O0 it loads the
address of "x" into a register, then adds INT_MIN to that register.
T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91602
--- Comment #2 from Andrew Waterman ---
Yeah, this is a bit a rat hole. Of course there's nothing about
RISC-V that precludes the use of the leb128 data formats. We fib that
they aren't supported to prevent the DWARF emitters from subtracting
l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89835
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85185
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87690
--- Comment #5 from Andrew Waterman ---
FWIW, I agree with your last paragraph
On Wed, Oct 24, 2018 at 7:54 AM wilson at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87690
>
> Jim Wilson cha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82106
--- Comment #3 from Andrew Waterman ---
I believe Alex is correct, in that this is an implementation artifact that
can be fixed without breaking the ABI.
On Tue, Sep 5, 2017 at 9:26 AM asb at lowrisc dot org <
gcc-bugzi...@gcc.gnu.org> wrote:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79418
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79912
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82717
--- Comment #3 from Andrew Waterman ---
On Wed, Oct 25, 2017 at 12:27 PM, asb at lowrisc dot org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82717
>
> --- Comment #2 from Alex Bradbury ---
> (In reply to palmer from comment #1)
>> Tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104831
--- Comment #3 from Andrew Waterman ---
Appendix A of the RISC-V ISA manual says that lr.w.aq + sc.w.aqrl
should suffice. I see the patch puts aqrl on both the load and store,
which, while correct, appears to be stronger than necessary.
(cc Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104831
--- Comment #4 from Andrew Waterman ---
Correction: Appendix A recommends lr.w.aqrl + sc.w.rl.
https://github.com/riscv/riscv-isa-manual/blob/9ec8c0105dbf1492b57f6cafdb90a268628f476a/src/memory.tex#L1150-L1152
On Mon, Mar 7, 2022 at 3:51 PM And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104831
--- Comment #8 from Andrew Waterman ---
Cool, thanks, Patrick.
On Mon, Mar 7, 2022 at 6:58 PM patrick at rivosinc dot com via
Gcc-bugs wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104831
>
> Patrick O'Neill changed:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106531
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106531
--- Comment #3 from Andrew Waterman ---
The lengthy-ISA-name problem will be addressed to a great extent by the
forthcoming introduction of ISA profiles. Although I agree the status quo is
ugly and overly verbose, I recommend against introducin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106338
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106601
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106691
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106691
--- Comment #3 from Andrew Waterman ---
Relaxation to gp happens at link time, and because of the relatively small
load/store offsets, the small-data limit is actually useful. I don't think we
should turn it off, because when we relax to gp, we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102211
--- Comment #7 from Andrew Waterman ---
On Tue, Sep 7, 2021 at 10:55 PM wilson at gcc dot gnu.org via Gcc-bugs
wrote:
>
> The hardware may trap if
> you access a 32-bit value which is not properly NaN-boxed.
I don't think the following affects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585
--- Comment #9 from Andrew Waterman ---
On Wed, Dec 7, 2022 at 7:02 PM palmer at gcc dot gnu.org via Gcc-bugs
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585
>
> palmer at gcc dot gnu.org changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108248
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108247
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108248
--- Comment #3 from Andrew Waterman ---
Yikes. Thanks for the explanation, Jeff.
(cc Kito Cheng: at some point, we should revisit the pipeline modeling of Zb*
instructions for sifive-7. The short version is that all Zb* instructions can
execu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
--- Comment #6 from Andrew Waterman ---
To be clear, `li rx, 4096' isn't unsupported: it's a
very-much-supported idiom for `lui rx, 1`.
On Mon, Jul 11, 2022 at 11:45 PM rguenth at gcc dot gnu.org via
Gcc-bugs wrote:
>
> https://gcc.gnu.org/bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114087
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111502
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111502
--- Comment #6 from Andrew Waterman ---
Ack, I misunderstood your earlier message. You're of course right that the
load/load/shift/or sequence is preferable to the load/load/store/store/load
sequence, on just about any practical implementation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116318
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116615
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114809
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578
--- Comment #9 from Andrew Waterman ---
For my M1 running Ventura 13.6, NaN payloads _are_ propagated, sign bit
included. This test prints fffc0080:
int main()
{
volatile long long ll = 0x8010;
volatile double d;
memcpy((char*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112295
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112478
--- Comment #2 from Andrew Waterman ---
Although I sketched the first draft of this patch, it’s Jeff Law who brought it
to fruition. He is more suited to help than I am.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106531
--- Comment #5 from Andrew Waterman ---
Yeah, RISC-V International decided to define B = {Zba, Zbb, Zbs}: note, not
Zbc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115687
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115922
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111926
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118734
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118057
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118356
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118949
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118945
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119100
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
50 matches
Mail list logo