<p dir="ltr">Just as a clarifying point for terminology:</p>
<p dir="ltr">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.</p>
<p dir="ltr">[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 <br>
</p>
<p dir="ltr">On Wed, Oct 2, 2013 at 4:46 AM, Timur Iskhodzhanov <<a href="mailto:timurrrr@google.com">timurrrr@google.com</a>> wrote:<br>
><br>
> Not yet; we do it in the ASan runtime library though as we want to<br>
> include as few headers as possible in order to avoid implicit<br>
> dependencies from the standard library that might cause bad things<br>
> when you intercept/wrap standard functions in the tool.<br></p>
<p dir="ltr">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.</p>
<div class="gmail_quot<blockquote class=" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2013/10/1 Warren Hunt <<a href="mailto:whunt@google.com">whunt@google.com</a>>:<br>
> Yes, we're not presently supporting the usage model where you can simply<br>
> declare the intrinsics like you would for cl.exe. We had a pretty extensive<br>
> discussion about what constitutes a "builtin" versus what constitutes an<br>
> "intrinsic" and the requirements for headers. Weirdly in MS world you have<br>
> to declare most "builtins" before you can use them but there are exceptions<br>
> like __debugbreak(). Ultimately we have an agreement that it would be nice<br>
> to support the microsoft intrinsics as builtins (i.e. not require the<br>
> header, and potentially not even a definition) but that will take more work<br>
> plumbing somewhat redundant builtins through clang and it was decided that<br>
> the current approach is both reasonable and expedient.<br>
<br>
OK, this looks reasonable.<br>
<br>
> Did you find a case in chrome where they are declaring an intrinsic without including "intrin.h"?<br>
<br>
Not yet; we do it in the ASan runtime library though as we want to<br>
include as few headers as possible in order to avoid implicit<br>
dependencies from the standard library that might cause bad things<br>
when you intercept/wrap standard functions in the tool.<br>
<br>
> On Tue, Oct 1, 2013 at 6:44 AM, Timur Iskhodzhanov <<a href="mailto:timurrrr@google.com">timurrrr@google.com</a>><br>
> wrote:<br>
>><br>
>> Please see the comment at<br>
>> <a href="http://llvm.org/bugs/show_bug.cgi?id=13283#c5" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=13283#c5</a> for the details.<br>
>><br>
>> For some reason, the value of *_Addend at the end of the function is<br>
>> wrong if we include <intrin.h>;<br>
>> also, it fails to compile if we declare the function without including<br>
>> the header.<br>
>><br>
>> 2013/10/1 Warren Hunt <<a href="mailto:whunt@google.com">whunt@google.com</a>>:<br>
>> > I've tested them under a variety cases. Are you concerned about the (-<br>
>> > _Value) clause?<br>
>> ><br>
>> > -Warren<br>
>> ><br>
>> ><br>
>> > On Mon, Sep 30, 2013 at 3:58 AM, Timur Iskhodzhanov<br>
>> > <<a href="mailto:timurrrr@google.com">timurrrr@google.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> 2013/9/28 Warren Hunt <<a href="mailto:whunt@google.com">whunt@google.com</a>>:<br>
>> >> > +static __inline__<br>
>> >> > long __cdecl _InterlockedExchangeAdd(long volatile *_Addend, long<br>
>> >> > _Value);<br>
>> >> > ...<br>
>> >> > +static __inline__ short __attribute__((__always_inline__,<br>
>> >> > __nodebug__))<br>
>> >> > +_InterlockedExchangeAdd16(short volatile *_Addend, short _Value) {<br>
>> >> > + return __atomic_add_fetch(_Addend, _Value, 0) - _Value;<br>
>> >> > +}<br>
>> >> > +static __inline__ long __attribute__((__always_inline__,<br>
>> >> > __nodebug__))<br>
>> >> > +_InterlockedExchangeAdd(long volatile *_Addend, long _Value) {<br>
>> >> > + return __atomic_add_fetch(_Addend, _Value, 0) - _Value;<br>
>> >> > +}<br>
>> >><br>
>> >> Are you sure this is a correct/complete implementation?<br>
>> >> <a href="http://llvm.org/bugs/show_bug.cgi?id=13283#c5" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=13283#c5</a><br>
>> ><br>
>> ><br>
><br>
><br>
_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
</div>