Just as a clarifying point for terminology: Let's define "intrinsic" functions to be a compiler-provided[1] routine (as opposed RTL provided) which you must #include a header file to use. Thus, it is a normal interface within the language, not an extension to the language itself. Then, let's define "builtin" functions to be compiler-provided routines for which you need not include a header. Thus, they are built directly into the language. There are a lot of other usages and definitions we might use, but these seem common in GCC and Clang communities and express a useful distinction for this discussion, so I suggest adopting this interpretation.
[1]: Note that there may exist (although at the moment I can't think of one) intrinsics where the *interface* is provided by the compiler, but the implementation is transparently provided via some RTL. This is typically opaque to the user though, so I think it's fair to say they are compiler-provided -- that is all a user of the routine need worry about. Those which are unavailable On Wed, Oct 2, 2013 at 4:46 AM, Timur Iskhodzhanov <[email protected]> wrote: > > Not yet; we do it in the ASan runtime library though as we want to > include as few headers as possible in order to avoid implicit > dependencies from the standard library that might cause bad things > when you intercept/wrap standard functions in the tool. Generally speaking, I think it is reasonable for sanitizers to use the headers shipped with the compiler such as Intrin.h... If needed you could specifically use them in a freestanding mode. Naturally, you'll want to watch out for just the situation I mention above with silent RTL dependencies, but I expect that to be quite rare. 2013/10/1 Warren Hunt <[email protected]>: > Yes, we're not presently supporting the usage model where you can simply > declare the intrinsics like you would for cl.exe. We had a pretty extensive > discussion about what constitutes a "builtin" versus what constitutes an > "intrinsic" and the requirements for headers. Weirdly in MS world you have > to declare most "builtins" before you can use them but there are exceptions > like __debugbreak(). Ultimately we have an agreement that it would be nice > to support the microsoft intrinsics as builtins (i.e. not require the > header, and potentially not even a definition) but that will take more work > plumbing somewhat redundant builtins through clang and it was decided that > the current approach is both reasonable and expedient. OK, this looks reasonable. > Did you find a case in chrome where they are declaring an intrinsic without including "intrin.h"? Not yet; we do it in the ASan runtime library though as we want to include as few headers as possible in order to avoid implicit dependencies from the standard library that might cause bad things when you intercept/wrap standard functions in the tool. > On Tue, Oct 1, 2013 at 6:44 AM, Timur Iskhodzhanov <[email protected]> > wrote: >> >> Please see the comment at >> http://llvm.org/bugs/show_bug.cgi?id=13283#c5 for the details. >> >> For some reason, the value of *_Addend at the end of the function is >> wrong if we include <intrin.h>; >> also, it fails to compile if we declare the function without including >> the header. >> >> 2013/10/1 Warren Hunt <[email protected]>: >> > I've tested them under a variety cases. Are you concerned about the (- >> > _Value) clause? >> > >> > -Warren >> > >> > >> > On Mon, Sep 30, 2013 at 3:58 AM, Timur Iskhodzhanov >> > <[email protected]> >> > wrote: >> >> >> >> 2013/9/28 Warren Hunt <[email protected]>: >> >> > +static __inline__ >> >> > long __cdecl _InterlockedExchangeAdd(long volatile *_Addend, long >> >> > _Value); >> >> > ... >> >> > +static __inline__ short __attribute__((__always_inline__, >> >> > __nodebug__)) >> >> > +_InterlockedExchangeAdd16(short volatile *_Addend, short _Value) { >> >> > + return __atomic_add_fetch(_Addend, _Value, 0) - _Value; >> >> > +} >> >> > +static __inline__ long __attribute__((__always_inline__, >> >> > __nodebug__)) >> >> > +_InterlockedExchangeAdd(long volatile *_Addend, long _Value) { >> >> > + return __atomic_add_fetch(_Addend, _Value, 0) - _Value; >> >> > +} >> >> >> >> Are you sure this is a correct/complete implementation? >> >> http://llvm.org/bugs/show_bug.cgi?id=13283#c5 >> > >> > > > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
