Hi, It's a really delayed reply, dw asked me to join the conversation.
On 08/09/13 13:07, Kai Tietz wrote: > Hi, > > sorry for the delayed answer per mail. > > 2013/8/9 dw <limegreenso...@yahoo.com>: >> So, no response here, other than a few (brief) comments on irc. >> >> It's hard to know how to advocate for a patch when I'm not sure what the >> objections are. But it seems likely that that biggest areas of concern >> aren't the changes to the inline asm, but the files I'm deleting from >> \intrinsc\. > Yes, I asked that on irc. IMHO it has some advantages to have some of > those functions used by static-library instead of calling into a DLL. > This might make a performance difference. We spare here one indirect > jump ... and there is still the opportunity that things getting better > optimized with LTO. Hmm, if you care about optimization, then inlines are the way to go. Having them in static library can only help to accidentally not use inlines in some obscure cases, which will decrease optimizations. >> With that in mind, let me try to clarify why I'm proposing deleting these >> files. >> >> RtlSecureZeroMemory.c - This function is NOT defined by MSDN as an >> intrinsic. This means that it is NOT provided automatically by the compiler >> as a builtin, and in fact is not available from any MS library or DLL. The >> only place the function exists is as an inline in winnt.h. The same as what >> mingw-w64 does. > Sure, but we want to make sure that this function is present. So we > want to provide it in libmingwex.a anyway, even if it is no intrinsic. > The need to add it to libmingwex is that this function isn't present > on all supported Windoof OSes, so we need to handle that. As far as I understand, they are never present in any Windows version. >> I have no >> idea. But I do see that it is not protected with an #ifdef to limit it to >> that platform. Further, MS defines a non-intrinsic version (but still >> FORCEINLINE) of these functions in winnt.h, which mingw-w64 also provides. > Yes, we should provide it IMHO. It might not fit into category of > intrinsic on all platforms, nevertheless it fits more to this category > then into another IMHO. *If* we want them at all, that's fine. But I tend to agree that we don't. >> In general: >> >> - These deletes bring mingw-w64 in line with MS. > That isn't necessarily the thing we want. I admit that in point of > incompatiblity, we should think pretty hard about it, if we want to do > that, but by default we have the goal of having a working environment > for gcc (and other FOSS) compilers. > >> - Mingw-64 provides no means to access these functions from the library. > This can be enforced by gcc's options to disable inlines and then > those functions are there by the lib as fallback. I think it's not the case for always_inline (aka. FORCEINLINE). Cheers, Jacek ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
