assume, assert, enforce, @safe

[Artur Skawina via Digitalmars-d]

On 07/31/14 17:37, Daniel Gibson via Digitalmars-d wrote:
> Am 31.07.2014 17:26, schrieb Artur Skawina via Digitalmars-d:
>> On 07/31/14 15:44, Daniel Gibson via Digitalmars-d wrote:
>>> And don't forget this (rather old) case: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8537
>>> (I really don't get why anyone would want such an optimization: I want an optimizer to use clever inlining, use SSE etc where it makes sense and stuff like that - but not to remove code I wrote.)
>>
>> That is actually not a bug, but a perfectly valid optimization. The
>> compiler isn't clairvoyant and can not know that some data that you
>> wrote, but never read back, matters.
> 
> I don't want the compiler to care about that. When I tell it to write something, I want it to do that, even if it might look like nonsense (if anything, it could create a warning).

This approach becomes completely impractical once generic code (templates)
enters the picture. But even for simple cases, it does not work. Keep in
mind that D initializes every object by default...


>> The solution is to tell the compiler that you really need that newly
>> (over-)written data. Eg
>>
>>     asm {"" : : "m" (*cast(typeof(password[0])[9999999]*)password.ptr); }
> 
> inline asm is not portable

That's why a portable compiler barrier interface is needed.
But this was just an example showing a zero-cost solution. A portable
fallback is always possible (the bug report was about C code -- there,
a loop that reads the data and stores a copy into a volatile location
would work).

artur