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 <[email protected]> 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 > [email protected] > http://lists.puremagic.com/mailman/listinfo/dmd-internals >
_______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
