Am Freitag, den 26.11.2021, 15:48 + schrieb Jonathan Wakely:
> On Fri, 26 Nov 2021 at 15:41, Martin Uecker wrote:
> > Am Freitag, den 26.11.2021, 09:24 + schrieb Jonathan Wakely:
> > > On Fri, 26 Nov 2021 at 09:00, Martin Uecker via Gcc
> > > wrote:
> > > > Am Freitag, den 26.11.2021, 09
On Fri, 26 Nov 2021 at 16:58, Gabriel Ravier wrote:
>
>
> On 11/26/21 16:48, Jonathan Wakely via Gcc wrote:
> > On Fri, 26 Nov 2021 at 15:41, Martin Uecker wrote:
> >> Am Freitag, den 26.11.2021, 09:24 + schrieb Jonathan Wakely:
> >>> On Fri, 26 Nov 2021 at 09:00, Martin Uecker via Gcc
> >>
On 11/26/21 16:48, Jonathan Wakely via Gcc wrote:
On Fri, 26 Nov 2021 at 15:41, Martin Uecker wrote:
Am Freitag, den 26.11.2021, 09:24 + schrieb Jonathan Wakely:
On Fri, 26 Nov 2021 at 09:00, Martin Uecker via Gcc wrote:
Am Freitag, den 26.11.2021, 09:29 +0100 schrieb Eric Botcazou:
T
On Fri, 26 Nov 2021 at 15:41, Martin Uecker wrote:
>
> Am Freitag, den 26.11.2021, 09:24 + schrieb Jonathan Wakely:
> > On Fri, 26 Nov 2021 at 09:00, Martin Uecker via Gcc wrote:
> > > Am Freitag, den 26.11.2021, 09:29 +0100 schrieb Eric Botcazou:
> > > > > This is a silent and dangerous inco
Am Freitag, den 26.11.2021, 09:24 + schrieb Jonathan Wakely:
> On Fri, 26 Nov 2021 at 09:00, Martin Uecker via Gcc wrote:
> > Am Freitag, den 26.11.2021, 09:29 +0100 schrieb Eric Botcazou:
> > > > This is a silent and dangerous incorrect code generation issue.
> > >
> > > Let's avoid this kin
On Fri, 26 Nov 2021 at 09:00, Martin Uecker via Gcc wrote:
>
> Am Freitag, den 26.11.2021, 09:29 +0100 schrieb Eric Botcazou:
> > > This is a silent and dangerous incorrect code generation issue.
> >
> > Let's avoid this kind of FUD, please, builtins are low-level devices and
> > people must know
Am Freitag, den 26.11.2021, 09:29 +0100 schrieb Eric Botcazou:
> > This is a silent and dangerous incorrect code generation issue.
>
> Let's avoid this kind of FUD, please, builtins are low-level devices and
> people must know what they are doing and be prepared for caveats.
Sorry, I do not thin
> This is a silent and dangerous incorrect code generation issue.
Let's avoid this kind of FUD, please, builtins are low-level devices and
people must know what they are doing and be prepared for caveats.
> If these functions are not meant to be used to exising
> data, then at least the documen
Am Sonntag, den 07.11.2021, 10:08 +0100 schrieb Martin Uecker:
> It would be great if somebody could take a look at
> PR96159.
>
> It seems we do not do atomic accesses correctly
> when the alignment is insufficient for a lockfree
> access, but I think we should fall back to a
> library call in t
Am Montag, den 08.11.2021, 11:59 + schrieb Jonathan Wakely:
> On Sun, 7 Nov 2021, 09:08 Martin Uecker wrote:
>
> > It would be great if somebody could take a look at
> > PR96159.
> >
> > It seems we do not do atomic accesses correctly
> > when the alignment is insufficient for a lockfree
> >
On Sun, 7 Nov 2021, 09:08 Martin Uecker wrote:
>
> It would be great if somebody could take a look at
> PR96159.
>
> It seems we do not do atomic accesses correctly
> when the alignment is insufficient for a lockfree
> access, but I think we should fall back to a
> library call in this case (as cl
Am Sonntag, den 07.11.2021, 10:24 +0100 schrieb Florian Weimer:
> * Martin Uecker via Gcc:
>
> > It would be great if somebody could take a look at
> > PR96159.
> >
> > It seems we do not do atomic accesses correctly
> > when the alignment is insufficient for a lockfree
> > access, but I think w
* Martin Uecker via Gcc:
> It would be great if somebody could take a look at
> PR96159.
>
> It seems we do not do atomic accesses correctly
> when the alignment is insufficient for a lockfree
> access, but I think we should fall back to a
> library call in this case (as clang does).
>
> This is
It would be great if somebody could take a look at
PR96159.
It seems we do not do atomic accesses correctly
when the alignment is insufficient for a lockfree
access, but I think we should fall back to a
library call in this case (as clang does).
This is very unfortunate as it is an important
f
Hi all,
the following code compiles into a mov instruction
on x86_64. I wonder why. The struct has alignment 4,
so a mov might not be atomic if the struct is not
alligned to its full size. For this reason,
I expected a call to libatomic insteadÂ
(LLVM does this). What am I missing?
The docume
On Wed, 2015-09-23 at 16:15 +0200, Sebastian Huber wrote:
> On 10/09/15 19:52, David Edelsohn wrote:
> > https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html
>
> Is there specific reason why the SYNC L,E (Elemental Memory Barriers)
> defined by Power-ISA V2.07 doesn't appear in this table?
Pro
On 10/09/15 19:52, David Edelsohn wrote:
https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html
Is there specific reason why the SYNC L,E (Elemental Memory Barriers)
defined by Power-ISA V2.07 doesn't appear in this table?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-
Thanks a lot for this fast answer.
Am 10.09.2015 um 19:52 schrieb David Edelsohn:
https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html
On Thu, Sep 10, 2015 at 1:39 PM, Bernhard Schommer
wrote:
I just ran into something strange using gcc 8.4.3 for powerpc.
A call to the __atomic_load functio
https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html
On Thu, Sep 10, 2015 at 1:39 PM, Bernhard Schommer
wrote:
> I just ran into something strange using gcc 8.4.3 for powerpc.
> A call to the __atomic_load function:
>
> __atomic_load(&Buf, &buf, __ATOMIC_SEQ_CST);
>
> expands to:
>
> sync
> lis
I just ran into something strange using gcc 8.4.3 for powerpc.
A call to the __atomic_load function:
__atomic_load(&Buf, &buf, __ATOMIC_SEQ_CST);
expands to:
sync
lis 9,Buf@ha
lwz 9,Buf@l(9)
cmpw 7,9,9
bne- 7,$+4
isync
stw 9,8(1)
However the PowerISA_V2.07 manual suggest in Appendix B.2.3 (Saf
20 matches
Mail list logo
