Am 08.03.2013 19:54, schrieb Walter Bright:
>
> On 3/8/2013 4:40 AM, Johannes Pfau wrote:
>>
>> So please explain what's illegal in this concrete example #2.
>
> If it lives in a register, then exception handling recovery won't work on it.
It only lives in the register for a very short time though. "User-exceptions" can't happen at that time at all*. The only thing that can happen is a memory/access violation exception if we call a invalid function pointer or if we have a stack overflow in the called function.

A code example for that: https://gist.github.com/jpf91/5123683

But do you really think it's important that we support recovering from these errors? On posix these generate signals anyway (there's etc.linux.memoryerror which turns that into exceptions, but that doesn't work here and is more a hack than in any way supported). For windows this creates access violations errors and there's usually no guarantee that you can recover safely from these.

We already argue that you can't safely recover from OutOfMemoryErrors, but you can recover from stack overflow / access violations? I think we even had documented somewhere that destructors might not be called when "Errors" are thrown.


(* The dtor is also not called if we throw in the postblit. At that time the value is not yet moved into the register. But that is not only when calling a function: even in simple cases if a postblit fails with exceptions the dtor is not run for copies so I take it this is intentional)
https://gist.github.com/jpf91/5123738

-- 
Johannes Pfau

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 3/9/2013 2:18 AM, Johannes Pfau wrote:
> Am 08.03.2013 19:54, schrieb Walter Bright:
>>
>> On 3/8/2013 4:40 AM, Johannes Pfau wrote:
>>>
>>> So please explain what's illegal in this concrete example #2.
>>
>> If it lives in a register, then exception handling recovery won't work on it.
> It only lives in the register for a very short time though.

What's the point, then? The compiler will cache fields in registers anyway.

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Am 10.03.2013 07:20, schrieb Walter Bright:
>
> On 3/9/2013 2:18 AM, Johannes Pfau wrote:
>> Am 08.03.2013 19:54, schrieb Walter Bright:
>>>
>>> On 3/8/2013 4:40 AM, Johannes Pfau wrote:
>>>>
>>>> So please explain what's illegal in this concrete example #2.
>>>
>>> If it lives in a register, then exception handling recovery won't work on it.
>> It only lives in the register for a very short time though.
>
> What's the point, then? The compiler will cache fields in registers anyway.
The point is passing it in a register should be faster than passing it on the stack or even passing by reference.

However, thinking about it I found another issue which shows that we have to pass non-PODs (at least those with destructors) by reference. I filed a bug report for dmd here:

http://d.puremagic.com/issues/show_bug.cgi?id=9704

I also filed a bug report for gdc. Fixing will have to wait till the above bug is fixed though cause the fix may need frontend changes and without the above fix non-PODs can't be implemented in gdc because of gcc-specific details.
http://gdcproject.org/bugzilla/show_bug.cgi?id=42

-- 
Johannes Pfau

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals