https://bugs.kde.org/show_bug.cgi?id=369459
Julian Seward changed:
What|Removed |Added
Resolution|--- |FIXED
Status|CONFIRMED
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #26 from Julian Seward ---
Documentation updated in r16404. Closing.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #25 from Paul Osmialowski ---
ok, now it builds and works.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #24 from Julian Seward ---
(In reply to Paul Osmialowski from comment #23)
> Are you sure you applied this patch on VEX part too?
Duh. Not enough coffee (etc). Committed, r3371.
--
You are receiving this mail because:
You are watching a
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #23 from Paul Osmialowski ---
Are you sure you applied this patch on VEX part too?
m_machine.c: In function 'vgPlain_parse_cpuinfo':
m_machine.c:810:10: error: 'VexArchInfo {aka struct }' has no member
named 'arm64_requires_fallback_LLSC'
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #22 from Julian Seward ---
Autodetection of Cavium cores and hence auto-enablement of the
fallback implementation, was added in r16380.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #21 from Julian Seward ---
(In reply to Paul Osmialowski from comment #19)
> I tested the fix on our dual-CPU (2x48 ThunderX cores) Linux machine and I
> can confirm that it worked.
Thanks for testing it!
--
You are receiving this mail be
https://bugs.kde.org/show_bug.cgi?id=369459
Ivo Raisr changed:
What|Removed |Added
Ever confirmed|0 |1
CC||i
https://bugs.kde.org/show_bug.cgi?id=369459
Paul Osmialowski changed:
What|Removed |Added
CC||pawel.osmialow...@foss.arm.
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #18 from Julian Seward ---
(In reply to Julian Seward from comment #17)
> Fixed. [..]
Andrew, can you test the fix, please?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #17 from Julian Seward ---
Fixed. It appears to work, to the extent that I can actually test it
without access to the hardware in question. r3352, r16309. Use
--sim-hints=fallback-llsc to use the alternative implementation.
--
You are r
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #16 from Julian Seward ---
I would be happy to make a generalised version of Maran's fixes,
so as to get arm{32,64} working on these cores. I don't really
want it to be the default implementation though, since we lose
correctness w.r.t. th
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #15 from Julian Seward ---
(In reply to Peter Maydell from comment #14)
> [..] so you might find your
> autodetect test code passed but later generated code didn't.
True.
> Plus on big.LITTLE you might later be running on a CPU with a
> d
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #14 from Peter Maydell ---
I think the assertion about "real world code not caring" is based on some
popular CPUs not having an ll/sc combination (like x86!), and so portable
atomicity primitives can't assume you don't get ABA because they h
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #13 from Andrew Pinski ---
(In reply to Julian Seward from comment #12)
> Andrew, do you know how well Maran's proposal
> https://bugs.kde.org/show_bug.cgi?id=344524#c8 worked on MIPS64r3 (Octeon 3)
> ?
> IOW is it worth taking and generalis
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #12 from Julian Seward ---
Andrew, do you know how well Maran's proposal
https://bugs.kde.org/show_bug.cgi?id=344524#c8 worked on MIPS64r3 (Octeon 3) ?
IOW is it worth taking and generalising?
--
You are receiving this mail because:
You ar
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #11 from Julian Seward ---
(In reply to Andrew Pinski from comment #10)
Another possibility is to run a test sequence on the host CPU at startup,
whilst we are still single threaded, containing LL, SC and some stores in
between, and see if i
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #10 from Andrew Pinski ---
>Andrew, is there a way to automatically detect the relevant cores at
startup time
You could scan /proc/cpuinfo for the "CPU implementer" value of 0x43 ('C') but
that only catches the current cores which have this
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #9 from Julian Seward ---
Maybe we could use Maran's proposal for fixing the same problem on
MIPS OCTEON3. https://bugs.kde.org/show_bug.cgi?id=344524#c8 (and 9
and 10).
This provides a correct implementation, including coverage of ABA
cas
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #8 from Peter Maydell ---
FWIW QEMU is switching to emulating atomics (including ll/sc) via a common
"cmpxchg" IR operation (which is then implemented in the backend via an ll/sc
loop or whatever the host CPU has). This results in not-strict
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #7 from Julian Seward ---
Hmm, I see stuff like this:
9858: 885ffe62ldaxr w2, [x19]
985c: 6b1f005fcmp w2, wzr
9860: 54fff7e1b.ne975c <__pthread_mutex_lock+0x44>
9864:
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #6 from Julian Seward ---
(In reply to Andrew Pinski from comment #5)
> One idea I have is to pattern match on the ldxr/stxr sequence and produce a
> single instruction in the IR and then decode them after the fact.
On consideration, I thin
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #5 from Andrew Pinski ---
Opps pressed save too soon.
One idea I have is to pattern match on the ldxr/stxr sequence and produce a
single instruction in the IR and then decode them after the fact.
--
You are receiving this mail because:
Yo
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #4 from Andrew Pinski ---
(In reply to Julian Seward from comment #3)
> Andrew, do you know which implementation this is? eg is it a Cortex
> A-something,
> or something else?
It is a custom ARMv8-a core produced by Cavium. It is not a co
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #3 from Julian Seward ---
Andrew, do you know which implementation this is? eg is it a Cortex
A-something,
or something else?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=369459
Peter Maydell changed:
What|Removed |Added
CC||peter.mayd...@linaro.org
--- Comment #2 from Pe
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #1 from Andrew Pinski ---
This is very much related to https://bugs.kde.org/show_bug.cgi?id=344524 (which
is recorded for MIPS and it just happens both are Cavium cores too).
--
You are receiving this mail because:
You are watching all bug
27 matches
Mail list logo
