Thanks for your comment! Let me clarify a little: > Given that this proposal changes the ABI It explicitly does not. For 64 bit pointers, the fake pointers are 64 bit (pointers), passing them around is no ABI change. For 32 bit pointers, it will use 64 bit pointers *only* if it can rewrite everything, e.g., the pointers are never stored as 32 bit pointers into memory. This is the case 99% of the time because it is actually "hard" to store a 32 bit pointer on a 64 bit machine. As an example, if you store a pointer to `__shared__` memory, you usually do it as `void*`, `char*`, etc., which is 64 bit. You would need to declare the pointer as `__shared__` (or similar) to make the storage of the pointer 32 bit. In the unlikely case the 32 bit pointer is stored or passed to a function we can't rewrite, we will "unpack" it at the point where we can't keep it in 64 bit (see below). > One of the most important advantages of classic Asan is that it does not require users to sanitize libraries which your application depends on. We are not requiring to sanitize the world. You will, however, not get any checking in the parts of your code that is not instrumented. If you pass a sanitized/fake pointer to an outside function, e.g., pass it to a library, we will unpack it at the call site. Unpacking transforms the fake pointer into the respective real pointer. The library will then work as usual as it receives a non-sanitized pointer. All that said, the prototype presented above was aimed at GPUs, which generally have fewer outside dependencies (for performance reasons). Our current work on making it better on CPUs will allow users to specify what libraries/APIs have been sanitized to allow fake pointers to cross between translation units (and libraries), consequently getting sanitizing throughout. > I would assume it requires to recompile all program dependencies ... Again, only if you want to check the accesses in them.

@@jdoerfert Thank you, Johannes, for detailed explanation. Will you also support situations when sanitized code accesses raw pointer (to stack, global or heap) returned by unsanitized library function?

@@yugr Yes, already, and by design. The runtime check detects if a pointer is real and simply passed it through. No check, and followed by the raw access. Basically, if a pointer ever leaves the sanitized space, or was never in it as the allocation was not sanitized, it can be used with minimal penalty. Technically, we could even go back to a sanitized pointer, assuming the allocation was sanitized, but that's potentially expensive and not done yet.

Code like that can appear after several passes of inlining and optimizations, in which case it's not really possible for the programmer to spot "obviously bad" code like this.

nVidia and later AMD have not had consistent hardware and driver support. Only v1.2 is broadly supported by a wide range of hardware and driver combinations. To the point that v3.0 had to be revised to make everything beyond v1.2 optional features. (Companies all dream of maneuvering for an exclusive alternative, nvidia was supressing CUDA alternatives then AMD thought they could somehow ride ROCm to CUDA popularity while having none of the advantages.) It seems that SyCL is the real successor (Newest versions are no longer an extension of openCL.), and well supported by at least oneAPI and adaptiveCPP.

Bitcode is still in memory, the goal is to move the IR into different LLVMContext

He doesn't work for Yahoo, he just uses it for its email service. So he just wanted to clear up a potential confusion.

Just because of the `!`? Or which part do you find particularly ugly?

​@@jakobhellermann6974 I would not call it just but that is main part. Other is if using English words helps or hurts in the long run. Sure it makes it easier to learn, but do you want that in your code forever? And if they use words then why not use impl like rust, they had to use impls?

Speaker here. Yep, I should have known better than to cavalierly put 0x in front of my example numbers.

😅​@@danielthornburgh2085

something robotic? that says "... can't understand your query, as it apears to be a series of disjointed phrases-[laughter]"