Repository navigation
x86 _rdtsc has wrong return type #559
Description
Activity
This is in accordance with Intel's documentation.
core::archimplements the Intel's spec as close as possible. Bugs in the spec should be reported to Intel, but the spec uses signed integers in many places in which it could use unsigned ones. Why? No idea.FYI the main reason we decided to implement the spec 1:1 is that we don't have the manpower to design a new API for each of the tens of thousand intrinsics that belong in
core::arch.
FWIW you can write a thin wrapper that transmutes
i64into anu64if you prefer that API in stable Rust (its a no-op). Also, clang probably just did the same thing as GCC to be compatible with it.@gnzlbg I have raised an issue with Intel about this intrinsics. Hopefully they'll reply and fix their spec.
Reacted by Gerd ZellwegerI have raised an issue with Intel about this intrinsics. Hopefully they'll reply and fix their spec.
So I don't hold my hopes up here because this would be a breaking change, so I'd suspect that nothing will happen. However, Intel and other vendors do send errata and make breaking changes every now and then, and I'm interested in seeing how we would deal with that.
@GabrielMajeri in the mean time, this particular function is defined in the Intel spect as just reading the content of a register, so it doesn't really matter whether the return value is a signed or unsigned integer (or an
[u8; 8]or whatever) as long as it is 64-bit wide. Its "the user"s job to interpret those bits as appropriate. I don't know what the value of the register "means" when the sign bit is set, but I'd expect it will just be an unsigned integer.I have a crate in progress to strongly type all intel intrinsics here and expose them using a safe API when possible: https://github.com/gnzlbg/typed_arch I'll take a PR that implemented the rdtsc intrinsics with a "better" and safe API.
EDIT: do you have a link to the Intel issue / bug report / tracking id?
@gnzlbg Well I submitted a comment to this forum thread which is where the Intrinsics guide told me to post issues to.
The comment is still waiting for moderator approval, and then I'll wait for a reply from Intel staff.
Edit: the comment is approved now, we just need to waitTo me it just looks like an issue with their documentation, considering they did mess up the types in their intrinsics guide before.
@GabrielMajeri is there an acknowledgment of the bug or where you contacted about it ? Otherwise it might be worth it to start a new thread there just about that.
I've tried submitting another message, although it seems the intrinsics guide is not exactly a priority. I wouldn't consider it to be an official specification in any way, just a helpful resource for developers who are looking for documentation on how to use the intrinsics.
Reacted by gnzlbgSadly, there does not appear to be a real "specification" of Intel compiler C intrinsics beyond the intrinsics guide. I'm going to merge the PR, and try to update stdsimd upstream doing a crater run with it. Maybe we can fix it.
- added a commit that references this issue
on Jul 5, 2019 - added a commit that references this issue
on May 14, 2026
This issue is related to the recently stabilised x86 intrinsic function
_rdtscThe issue is that the function is defined to return a signed
i64. This is in accordance with Intel's documentation. However, that is not how most people define it, including C/C++ compilers.This is how GCC defines it:
This Clang example proves it also defines it as
unsigned long long.Now, I'm confused. Since the timestamp counter is a monotonically increasing timer, it wouldn't make sense to return negative values. In fact, I think it is allowed to return values with the most significant bit set (which would make the returned value negative, unless transmuted). Is the mismatch intended?