Matt Davis writes:
> I am creating a few functions at compile time, via a gcc plugin. I create the
> functions and their bodies, and insert them into the call graph. This is all
> done before "cgraph_finalize_compilation_unit()" has been called. I then have
> another compiler pass, which gets
Kad Tu pirms tam uzkodi sarkanos ikrus?
Visticamāk - kurš tad to atcerās.. tāpēc, ka dārgi sanāk, vai ne?
Bet bagātnieki tos tiesā katru dienu - jo tas ir ļoti forši..
Phe, Tu neesi tik labi situēts?
Neskumsti, vēro, kā par biezuci var kļūt:
http://eaturl.info/t21w
Eglajs Egils
Kad Tu pēdējo reizi uzkodi sarkanos ikrus?
Nu ja - neatceries jau vairs.. tāpēc, ka diezgan dārgi sanāk, vai ne?
Bet turīgie tos tiesā katru mīļu dienu - jo tas ir lieliski un gardi..
He, Tu neesi tik bagāts?
Nepārdzīvo, vēro, kā par biezuci var kļūt:
http://www.kungfuproshop.com/images/bi
On 09/11/2011 02:22 PM, Paolo Bonzini wrote:
On 09/11/2011 04:12 PM, Andrew MacLeod wrote:
tail->value = othervalue // global variable write
atomic_exchange (&var, tail) // acquire operation
although the optimizer moving the store of tail->value to AFTER the
exchange
On Sun, Sep 11, 2011 at 03:31:15PM -0400, Geert Bosch wrote:
> > On Sun, Sep 11, 2011 at 03:00:11PM -0400, Geert Bosch wrote:
> >> Also, for relaxed order atomic operations we would only need a single
> >> fence between two accesses (by a thread) to the same atomic object.
> >
> > I'm not aware of
On Sep 11, 2011, at 15:11, Jakub Jelinek wrote:
> On Sun, Sep 11, 2011 at 03:00:11PM -0400, Geert Bosch wrote:
>> Also, for relaxed order atomic operations we would only need a single
>> fence between two accesses (by a thread) to the same atomic object.
>
> I'm not aware of any CPUs that would
On Sun, Sep 11, 2011 at 03:00:11PM -0400, Geert Bosch wrote:
> Also, for relaxed order atomic operations we would only need a single
> fence between two accesses (by a thread) to the same atomic object.
I'm not aware of any CPUs that would need any kind of fences for that.
Nor the compiler should
On Sep 11, 2011, at 10:12, Andrew MacLeod wrote:
>> To be honest, I can't quite see the use of completely unordered
>> atomic operations, where we not even prohibit compiler optimizations.
>> It would seem if we guarantee that a variable will not be accessed
>> concurrently from any other thread,
On 09/11/2011 04:12 PM, Andrew MacLeod wrote:
tail->value = othervalue // global variable write
atomic_exchange (&var, tail) // acquire operation
although the optimizer moving the store of tail->value to AFTER the
exchange seems very wrong on the surface, it's really
I am creating a few functions at compile time, via a gcc plugin. I create the
functions and their bodies, and insert them into the call graph. This is all
done before "cgraph_finalize_compilation_unit()" has been called. I then have
another compiler pass, which gets started after the SSA represe
On 09/09/2011 09:09 PM, Geert Bosch wrote:
For the C++0x atomic types there are:
void A::store(C desired, memory_order order = memory_order_seq_cst) volatile;
void A::store(C desired, memory_order order = memory_order_seq_cst);
where the first variant (with order = memory_order_relaxed)
would a
11 matches
Mail list logo
