Re: [boost] Fw: [atomic] review results

Subject: Re: [boost] Fw: [atomic] review results
From: Tim Blechmann (tim_at_[hidden])
Date: 2011-11-08 06:30:58

> > then how do other compilers/library implementations behave? you said
> > that
> > gcc doesn't follow the suggestion of the standard to avoid per-process
> > states.
> 
> well gcc certainly follows the recommendation of the standard by making the
> *lock-free* atomics both address-free and free from process state, I don't
> read the standard as suggesting (or even requiring) anything for emulated
> atomics

in my reading the sentence `The implementation should not depend on any per-
process state' is not restricted to lock-free atomics, but i am not a native 
speaker and i could be wrong.

> > cacheline sizes vary, but a compiler might optimize for a commonly used
> > value. however i've been hit more than once by compilers, which are
> > changing the size of structs.
> 
> under what circumstances did the sizes change? Currently I cannot imagine
> this *not* being an ABI violation

iirc a struct { int i; void*p}; had a size of 16 bytes or 12 bytes depending 
if it was packed or not.
but also empty-base-class optimization should change the size of a class.

cheers, tim