On 14 November 2012 17:50, Andrei Alexandrescu <[email protected]> wrote: > On 11/14/12 9:15 AM, David Nadlinger wrote: >> >> On Wednesday, 14 November 2012 at 14:16:57 UTC, Andrei Alexandrescu wrote: >>> >>> On 11/14/12 1:20 AM, Walter Bright wrote: >>>> >>>> On 11/13/2012 11:37 PM, Jacob Carlborg wrote: >>>>> >>>>> If the compiler should/does not add memory barriers, then is there a >>>>> reason for >>>>> having it built into the language? Can a library solution be enough? >>>> >>>> >>>> Memory barriers can certainly be added using library functions. >>> >>> >>> The compiler must understand the semantics of barriers such as e.g. it >>> doesn't hoist code above an acquire barrier or below a release barrier. >> >> >> Again, this is true, but it would be a fallacy to conclude that >> compiler-inserted memory barriers for »shared« are required due to this >> (and it is »shared« we are discussing here!). >> >> Simply having compiler intrinsics for atomic loads/stores is enough, >> which is hardly »built into the language«. > > > Compiler intrinsics ====== built into the language. > > Andrei >
Not necessarily. For example, printf is a compiler intrinsic for GDC, but it's not built into the language in the sense of the compiler *provides* the codegen for it. Though it is aware of what it is and what it does, so can perform relevant optimisations around the use of it. Regards, -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
