Something needs to happen with shared, and soon.

[Iain Buclaw]

On 14 November 2012 17:50, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> 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';