On 06/27/13 14:44, m...@morous.org wrote: >> 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. > I am not sure whether it is a good idea so take it only as an input for > further consideration.
It has both its advantages and problems. The nice things is that intrins would just work as good as we may emulate them, even if the code just adds declarations for those functions. The problem is that, well, they should not be always declared, so there is potential for conflicts as well as additional code to parse on *each* compiled file. > Alternative approach might perhaps be to adapt gcc > specs file so gcc acts as if the option "-include path/to/intrin.h" is > used. That's something I meant to look at for a while, but for a different reason. I've seen a few cases in code ported from MSVC assuming that macros like _M_IX86 are defined by compiler and no includes are needed. We provide them in _mingw_mac.h, so if you include (almost) any our header, this will be present, but that's not enough for config.h-like things. A header inside toolchain that is always included by GCC would be nice, flexible way to support such cases. Cheers, 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
