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 |Added
> -
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/bugzilla/show_bug.cgi?id=106265
>
> --- Comment #5 from Richard Biener ---
> So why do we even
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:
>
>What|Removed |Added
> ---
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 Andrew Waterman wrote:
>
> Appendix A of the RISC-V ISA manual says that lr.w.aq + sc.
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 Dan Lustig)
On Mon, Mar 7, 2022 at 3:25 PM patrick at rivosinc dot com via
Gcc-bugs wrote:
>
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 the resolution of the ticket, but
just for the record, trapping is _not_ an option the ISA pe
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
label addresses at assembly time. RISC-V linker relaxations foil the
assumption that those di
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.
The same phenomenon happens in the x86-64 -mcmodel=kernel case.
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
models, which we should eventually lift by introducing larger code
models.
Note that it's pos
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, asb at lowrisc dot org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005
>
> Ale
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)
>> Thanks Alex -- you're correct that this is a documentation/code mismatch. I
>> just talked to A
11 matches
Mail list logo
