Am Thu, 7 Nov 2013 16:14:59 +0000 schrieb Iain Buclaw <ibuc...@ubuntu.com>:
> On 3 November 2013 10:20, Johannes Pfau <nos...@example.com> wrote: > > > Am Sun, 3 Nov 2013 02:10:20 +0000 > > schrieb Iain Buclaw <ibuc...@ubuntu.com>: > > > > > last time I > > > checked, returning 0 disables aliasing rules from taking effect. > > > > That should work. Alias set 0 is a special alias set which conflicts > > with everything. I'll check if it works as expected. > > > > > This is taken from hunks in the 2.064 merge I'm testing: > > Pastebin link here: http://pastebin.com/jxQQL68N > Some probably stupid questions about this patch: // If the type is a dynamic array, use the alias set of the basetype. What exactly does happen in that case? The Tarray type is the two-field type consisting of length and ptr, right? Currently TypeDArray->toCtype constructs a two_field_type with size_t and typeof(Element)*. So according to the C aliasing rules, the TypeDArray alias set does already conflict with size_t and Element*. It does not conflict with Element. But I don't know why it should conflict with Element if we're talking about the slice type here. It would allow code like this to work: "char[] a; char* b = (cast(char*)&a)" but I don't see why this should work, it's illegal anyway? Also, AFAICS it does not help with the problem in std.algorithm: char[] a; //cast(ubyte[])a generates: *cast(ubyte[]*)&a; Do you think this cast should be illegal in D? I think if we want to support strict aliasing for the code above we'll have to do what gcc does for pointers: http://code.metager.de/source/xref/gnu/gcc/gcc/alias.c#819 Put all array slices - regardless of element type - into the same alias set and make size_t and void* subsets of this alias set. // Permit type-punning when accessing a union Isn't that already guaranteed by GCC? See: http://code.metager.de/source/xref/gnu/gcc/gcc/alias.c#982 Unions have all their member types added as subsets. So as long as the reference is through the union GCC knows the union type and it'll conflict with all member types. But even if we make those changes to aliasing rules, we'll have to fix many places in phobos. For example: https://github.com/D-Programming-Language/phobos/blob/master/std/math.d#L1965 real value; ushort* vu = cast(ushort*)&value; AFAICS this will always be invalid with strict aliasing. https://github.com/D-Programming-Language/phobos/blob/master/std/uuid.d#L468 casts ubyte[16]* to size_t* also illegal, AFAICS. Are there any statistics about the performance improvements with strict aliasing? I'm not really sold on the idea of strict aliasing, right now it looks to me as if it's mainly a way to introduce subtle, hard to debug and often latent bugs (As whether you really see a problem depends on optimization) http://stackoverflow.com/questions/1225741/performance-impact-of-fno-strict-aliasing
