There's a rather sour test in the testsuite (runnable/test42.d : test7290) that looks at the address of the object, and infers locality based on the value of the address.

This is very problematic and doesn't actually reliably test the feature, as it makes big assumptions about the behaviour of what the compiler does. Such as:

a) No functions are inlined.
b) There isn't any optimisations in place that omit the frame pointer from
the function.
c) The compiler pushes the objects on the stack in a deterministic order
when building under optimisations.

There needs to be a better defined test for this as the current one is extremely implementation specific and fragile.

Only thought that immediately comes to mind other than pulling the test out of the testsuite is to overload _d_allocmemory to ensure that it is never called.


eg:

void* _d_allocmemory (size_t sz)
{
  assert(false);
}

void test7290()
{
  int add = 2;
  scope sdg = (int a) => a + add;  // OK, is a stack allocation.
  auto hdg = (int a) => a + add;  // Fails as _d_allocmemory is called to
initialise closure.
}


Though this would break test54 in that same file (would need to move it
out).

Thoughts?


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

You could possibly pass sdg.ptr to the gc (allocsize?) to check if it's on
the heap or not.

On Thu, Mar 28, 2013 at 3:32 AM, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

> There's a rather sour test in the testsuite (runnable/test42.d : test7290) that looks at the address of the object, and infers locality based on the value of the address.
>
> This is very problematic and doesn't actually reliably test the feature, as it makes big assumptions about the behaviour of what the compiler does. Such as:
>
> a) No functions are inlined.
> b) There isn't any optimisations in place that omit the frame pointer from
> the function.
> c) The compiler pushes the objects on the stack in a deterministic order
> when building under optimisations.
>
> There needs to be a better defined test for this as the current one is extremely implementation specific and fragile.
>
> Only thought that immediately comes to mind other than pulling the test out of the testsuite is to overload _d_allocmemory to ensure that it is never called.
>
>
> eg:
>
> void* _d_allocmemory (size_t sz)
> {
>   assert(false);
> }
>
> void test7290()
> {
>   int add = 2;
>   scope sdg = (int a) => a + add;  // OK, is a stack allocation.
>   auto hdg = (int a) => a + add;  // Fails as _d_allocmemory is called to
> initialise closure.
> }
>
>
> Though this would break test54 in that same file (would need to move it
> out).
>
> Thoughts?
>
>
> Regards
> --
> Iain Buclaw
>
> *(p < e ? p++ : p) = (c & 0x0f) + '0';
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>

On Mar 28, 2013 12:41 AM, "Daniel Murphy" <yebblies@gmail.com> wrote:
>
> You could possibly pass sdg.ptr to the gc (allocsize?) to check if it's
on the heap or not.
>

That could certainly be better.  :)

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';