On 06/26/13 23:57, dw wrote:
>> I still don't get, why we need those functions in crt.
> The problem is that in MSVC it it perfectly legal to just copy/paste the 
> prototype for one of the intrinsics in your file and use it (see example 
> below).  It is NOT necessary to include intrin.h.  If we want to support 
> this (and I was told we do), then duplicating the functions in the 
> library is the only approach I can think of.

Hmm, yeah, I missed that point. Well, that won't work well (at least
this way), but I agree we have to support it one way or another. Maybe
placing them in (almost) always included file would do the trick, but
that has other problems. That said, I'm fine with your crt solution.

>> - MSVC does not allow referencing them by pointer.
> Depends on the function.  For example _rotl can be either an intrinsic, 
> or resolved from the library.  Compile this code and you will see _rotl 
> used as an intrinsic.  Uncomment the pointer, and see _rotl resolved 
> from the library at the same time as the intrinsic is being used.  While 
> I'm not prepared to say how *useful* this is, it can be done.
>
> extern "C" {
> unsigned int __cdecl _rotl(unsigned int, int);
> }
>
> #pragma intrinsic(_rotl)
>
> int main(int argc, char* argv[])
> {
>      //void *v = _rotl;
>      return _rotl(argc, 2);
> }

Sure, but _rotl is exported from msvcrt.dll, so it's a different issue.
Thus, we don't need it in our crt (and that's what we do, AFAICS).
>> This is not acceptable IMO. This is way too common in Windows world to 
>> include only windows.h-like headers and use Interlocked* functions. We 
>> should support this as first-class code, not using some sort of fallback.
> Ok.  How would you propose we do that?  MSVC does it by having code in 
> the compiler.  That doesn't seem like an option for us.  If users don't 
> include intrin, and we're not allowed to resolve things from the 
> library, what does that leave?
>
> Perhaps I should point out that the current winnt.h *does* include 
> intrin.h for x64 (unless CYGWIN).  And my proposed change includes it 
> for both x86 & x64 (unless CYGWIN).

While I wasn't fun of adding new header in your previous patch (why
would we do that if it's included only from one file, intrin.h,
anyway?), we may add (yet another:/) new header for those shared intrins
and include it both from winnt.h and intrin.h.


Thanks,
Jacek

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to