>I'm not saying that we should ever >dereference an unaligned pointer.>All I'm asking for is that pointer arithmetic >will be well-defined for>all pointer types even when the address is >unaligned -- and I think>this won't affect any optimisers. In fact it >won't even require a>change to any modern compilers.Correct....the only missing thing is the guarantee that it works same way on all platfroms.>By the way I do realise that this will all fall >apart when it comes to>"pointer tagging". If someone uses the lower >3 bits of a pointer to>store extra info, and if I then relocate the >object into unaligned>memory and do arithmetic on a pointer inside >it, then I'll corrupt the>pointer tag. I realise that.That's not a problem, because if you want to tag a pointer you need to wrap it inside a structure, and you can delete all member operators that modify the pointer value inside that structure.And when you want to get the raw pointer back, you just mask out the tag bits, and get the pointer bits intact.Maybe you should reformulate your thread's question. Instead of asking for the feature, maybe ask who is breaking it, if there is none, then it can be standardized.Sent from my Galaxy
-------- Original message --------From: Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Date: 1/29/25 1:39 PM (GMT+01:00) To: std-proposals_at_[hidden] Cc: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]> Subject: Re: [std-proposals] Make all data pointers intercompatible On Tue, Jan 28, 2025 at 3:40 PM Jens Maurer wrote:>> > double *ptr = reinterpret_cast<double*>(0x7fff934a9d83);> >> > Then I want "++ptr" to add 8 to it, giving 0x7FFF934A9D8B. I want this> > to be well-defined behaviour.>> It is an important optimizer assumption that all values> of a given type "pointer to T" are suitably aligned for "T".I've been mulling this over. Let's say we have a double*, and thatalignof(double) == 8.If we increment this pointer or do any arithmetic on it, then anx86_64 CPU will simply do: add rdi, 8There isn't any optimisation that can be performed here. I can't thinkof another CPU that would do something differently that would allowfor any kind of optimisation here.But when it comes to dereferencing the pointer, this is whereoptimisation can come into it. There is the "movsd" instruction formoving a floating-point number:    movsd xmm0, [aligned address]And then there's the "movups" instruction for moving a floating-pointinto unaligned memory: movups xmm0, [unaligned address]I'm not saying that we should ever dereference an unaligned pointer.All I'm asking for is that pointer arithmetic will be well-defined forall pointer types even when the address is unaligned -- and I thinkthis won't affect any optimisers. In fact it won't even require achange to any modern compilers.By the way I do realise that this will all fall apart when it comes to"pointer tagging". If someone uses the lower 3 bits of a pointer tostore extra info, and if I then relocate the object into unalignedmemory and do arithmetic on a pointer inside it, then I'll corrupt thepointer tag. I realise that.-- Std-Proposals mailing listStd-Proposals_at_[hidden]://lists.isocpp.org/mailman/listinfo.cgi/std-proposals