My responses: - While I don't really see the benefit, I'm ok with putting the inline implementations in their own .h file. And it's going to feel odd putting an include at the *bottom* of a file.
- While duplicating the work (and adding an additional .c file) is a pain, having the implementations in two places (even the ones MS says can only be inline) is ok with me. - Since there isn't any way to stop people from doing it, people can put intrinsic prototypes into their own files if they want to. Of course unlike MSVC, they will only get the static library versions not the inlines without intrin.h. - Putting intrinsic prototypes in *system headers* (other than intrin.h) seems like a bad idea. Without including intrin.h, any code that uses it will end up using the library version instead of the inline version. But perhaps most importantly: - I believe we should consider intrin.h the "right" definition for gcc's version of the MSVC intrinsics. Anything that conflicts with it needs to be changed. If we agree on these points, I'll send another email laying out the specific changes I want to make. If that looks good, I'll start work on a patch. dw ------------------------------------------------------------------------------ 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
