https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #39 from GCC Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:9846b0916c1a9b9f3e9df4657670ef4419617134
commit r15-2147-g9846b0916c1a9b9f3e9df4657670ef4419617134
Author: mayshao
Date: Thu Jul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #38 from Mayshao-oc at zhaoxin dot com ---
vmovdqu is also atomic in Zhaoxin processors if it meets three requirements:
1. the address of its memory operand must be 16-byte aligned
2. vmovdqu is vex.128 not vex.256
3. the memory type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #37 from Mayshao-oc at zhaoxin dot com ---
vmovdqu is also atomic in Zhaoxin processors if it meets three requirements:
1. the address of its memory operand must be 16-byte aligned
2. vmovdqu is vex.128 not vex.256
3. the memory type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #36 from Richard Henderson ---
(In reply to Mayshao-oc from comment #34)
> (In reply to Jakub Jelinek from comment #17)
> > Fixed for AMD on the library side too.
> > We need a statement from Zhaoxin and VIA for their CPUs.
>
> Sorr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #35 from Uroš Bizjak ---
(In reply to Mayshao-oc from comment #34)
> Can we extend this patch to Zhaoxin processors as well?
Just post the enablement patch to gcc-patches@ mailing list.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #34 from Mayshao-oc at zhaoxin dot com ---
(In reply to Jakub Jelinek from comment #17)
> Fixed for AMD on the library side too.
> We need a statement from Zhaoxin and VIA for their CPUs.
Sorry for the late reply.
We guarantee that V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #33 from Segher Boessenkool ---
Yes, exactly. It was the X server I think? I try to forget such horrors :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #32 from Andrew Pinski ---
(In reply to Segher Boessenkool from comment #31)
> Yes, there was a user who incorrectly used memcpy on non-memory memory.
>From what I remember (it was also reported about aarch64 at one point too), one
o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #31 from Segher Boessenkool ---
Yes, there was a user who incorrectly used memcpy on non-memory memory.
This is not valid, and never has been.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #30 from Florian Weimer ---
(In reply to Segher Boessenkool from comment #29)
> (In reply to Florian Weimer from comment #28)
> > Maybe this belongs in the ABI manual? For example, the POWER ABI says that
> > memcpy needs to work on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #29 from Segher Boessenkool ---
(In reply to Florian Weimer from comment #28)
> Maybe this belongs in the ABI manual? For example, the POWER ABI says that
> memcpy needs to work on device memory.
Huh?!
Where do you see this? The w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #28 from Florian Weimer ---
(In reply to Peter Cordes from comment #27)
> (In reply to Alexander Monakov from comment #26)
> > Sure, the right course of action seems to be to simply document that atomic
> > types and built-ins are me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #27 from Peter Cordes ---
(In reply to Alexander Monakov from comment #26)
> Sure, the right course of action seems to be to simply document that atomic
> types and built-ins are meant to be used on "common" (writeback) memory
Agree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #26 from Alexander Monakov ---
Sure, the right course of action seems to be to simply document that atomic
types and built-ins are meant to be used on "common" (writeback) memory, and no
guarantees can be given otherwise, because it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #25 from Peter Cordes ---
(In reply to Alexander Monakov from comment #24)
>
> I think it's possible to get UC/WC mappings via a graphics/compute API (e.g.
> OpenGL, Vulkan, OpenCL, CUDA) on any OS if you get a mapping to device
> m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #24 from Alexander Monakov ---
(In reply to Peter Cordes from comment #23)
> But at least on Linux, I don't think there's a way for user-space to even
> ask for a page of WT or WP memory (or UC or WC). Only WB memory is easily
> ava
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
Peter Cordes changed:
What|Removed |Added
CC||peter at cordes dot ca
--- Comment #23 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #22 from Xi Ruoyao ---
(In reply to Jakub Jelinek from comment #21)
> What about loads? That is even more important than the stores. While
> atomic store can be worst case done through cmpxchg16b, even when it is
> slower, we can't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #21 from Jakub Jelinek ---
What about loads? That is even more important than the stores. While atomic
store can be worst case done through cmpxchg16b, even when it is slower, we
can't use cmpxchg16b on atomic load because we don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #20 from Xi Ruoyao ---
>From Mayshao (Zhaoxin engineer):
"On Zhaoxin CPUs with AVX, the VMOVDQA instruction is atomic if the accessed
memory is Write Back, but it's not guaranteed for other memory types."
Is it allowed to use VMOVD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #19 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:60880f3afc82f55b834643e449883dd5b6ad057a
commit r11-10385-g60880f3afc82f55b834643e449883dd5b6ad057a
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #18 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:86dea99d8525bf49d51636332d6be440e51b931a
commit r12-8920-g86dea99d8525bf49d51636332d6be440e51b931a
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #17 from Jakub Jelinek ---
Fixed for AMD on the library side too.
We need a statement from Zhaoxin and VIA for their CPUs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #16 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:4a7a846687e076eae58ad3ea959245b2bf7fdc07
commit r13-4048-g4a7a846687e076eae58ad3ea959245b2bf7fdc07
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #15 from Alexander Monakov ---
Ah, there will be an mfence after the vmovdqa when necessary for an atomic
store, thanks (I missed that because the testcase doesn't scan for mfence).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #14 from Jakub Jelinek ---
For ordering guarantees I assume (already since the r12-7689 change) that
VMOVDQA behaves the same as MOVL/MOVQ.
This PR was about whether there is a quarantee that VMOVDQA will be an atomic
load or store p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #12 from Jakub Jelinek ---
I've posted the patches (so far only lightly tested):
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606021.html
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606022.html
It is still Sund
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
Xi Ruoyao changed:
What|Removed |Added
Summary|gcc and libatomic can use |gcc and libatomic can use
29 matches
Mail list logo