https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005
Patrick O'Neill changed:
What|Removed |Added
CC||patrick at rivosinc dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005
--- Comment #10 from James Y Knight ---
I suppose since it doesn't affect most common platforms, nobody's noticed the
brokenness yet?
ARM is probably the most common architecture which is missing atomics on common
CPU models, but when targeting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005
--- Comment #9 from Jim Wilson ---
Oops, hitting tab doesn't work as expected. Trying again...
This looks like a generic GCC problem, not a RISC-V specific problem. Or
perhaps, not a gcc bug at all.
For instance, if I build an armv6t2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005
--- Comment #8 from Jim Wilson ---
This looks like a generic GCC problem, not a RISC-V specific problem.
For instance, if I build an armv6t2 compiler I get
bl __atomic_fetch_add_4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005
--- Comment #7 from James Y Knight ---
(In reply to Jim Wilson from comment #6)
> On Thu, 2018-05-31 at 15:07 +, foom at fuhm dot net wrote:
> > (But also, why doesn't it implement __atomic_add_fetch inline?)
>
> If you don't have atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005
--- Comment #6 from Jim Wilson ---
On Thu, 2018-05-31 at 15:07 +, foom at fuhm dot net wrote:
> (But also, why doesn't it implement __atomic_add_fetch inline?)
If you don't have atomic instructions, then we call an out-of-line
function that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005
Jim Wilson changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005
--- Comment #5 from Jim Wilson ---
On Thu, 2018-05-31 at 05:40 +, asb at lowrisc dot org wrote:
> Actually I think this bug is wider in scope than I first thought. GCC
> will also
> intermix __atomic libcalls and inline instruction sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005
--- Comment #3 from Alex Bradbury ---
(In reply to Andrew Waterman from comment #2)
> 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.
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
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
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005
Alex Bradbury changed:
What|Removed |Added
CC||asb at lowrisc dot org
13 matches
Mail list logo
