The line in question is:
return (Data*) (((size_t) ptr) & ((1ul << 48) - 1)); }
The bug derives from the fact that 1ul is shorter than 48. Swapping it to ull seems to possibly break the comparison guard bits you're using to accelerate the indirected tables. This isn't surprising as that swap is not semantically equivalent.
elephant in the room: this is probably not an actual bug, just a defect.
While this is safe on all machines+compilers I am aware of, it is technically UB and should be avoided. I work in an env where most warns are compile errors and I'm not at liberty to fix this. I'd love a hand with this but I recognize that redoing your bitwise math to support my situation is........ pretty silly as asks go. Still! Is there any chance you could fix this and a few similar issues in bigatomic, epoch, and lock? Or direct me to where a fixed version of those files might be?
This work is absolutely lovely, and I'm really excited to bench it in my use-case. Thank you so much!
--J
The line in question is:
return (Data*) (((size_t) ptr) & ((1ul << 48) - 1)); }The bug derives from the fact that 1ul is shorter than 48. Swapping it to ull seems to possibly break the comparison guard bits you're using to accelerate the indirected tables. This isn't surprising as that swap is not semantically equivalent.
elephant in the room: this is probably not an actual bug, just a defect.
While this is safe on all machines+compilers I am aware of, it is technically UB and should be avoided. I work in an env where most warns are compile errors and I'm not at liberty to fix this. I'd love a hand with this but I recognize that redoing your bitwise math to support my situation is........ pretty silly as asks go. Still! Is there any chance you could fix this and a few similar issues in bigatomic, epoch, and lock? Or direct me to where a fixed version of those files might be?
This work is absolutely lovely, and I'm really excited to bench it in my use-case. Thank you so much!
--J