I recently proposed a patch <https://sourceforge.net/p/mingw-w64/discussion/723797/thread/577a3f52/#84f8/9579/874a> that removed some inline asm and replaced it with builtins. Fixing/removing inline asm is sort of a hobby of mine. Among other things <https://gcc.gnu.org/wiki/DontUseInlineAsm>, people are usually more comfortable reading and supporting code that has no asm.
Kai was generally supportive of the patch, but he suggested <https://sourceforge.net/p/mingw-w64/discussion/723797/thread/577a3f52/#e14f> having a fallback in case the builtin wasn't supported by the compiler. That sounds like a good idea. By detecting whether a feature is supported, we get the best performance if it is supported, while still supporting as many compilers as possible. But how do you detect this? I started with google to see if gcc had some 'trick' for this. Which turned up a very promising sounding "__has_builtin". This would make the code very simple: #if __has_builtin(__builtin_bswap16) However, those links all turned out to be for clang. gcc doesn't support <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970> __has_builtin(). Argh. So, I can test for gcc separately. After all, there's __GNUC__, right? I have to figure out what gcc version added this builtin (which is a pain). But that gets me something like this: #if (defined(__has_builtin) && __has_builtin(__builtin_bswap16)) || __GNUC__ >= 4 Except clang also defines __GNUC__ (I know, right?). So that brings me to something like this: #if (defined(__has_builtin) && __has_builtin(__builtin_bswap16)) || (!defined(__clang__) && __GNUC__ >= 4) But that's only going to work for clang and gcc. What about other compilers? Some of them also define __GNUC__. While this sounded so simple at the start, the more I look into this, the more of a challenge this becomes. Trying to make a chart of what compiler supports what features and uses which defines... And if I wanted to test it, I'd have to find and install a bunch of different compilers and different versions of the compilers... Blech. So how can I do this generically? Some projects use autoconfig to check for compiler support for various features. Is that the right answer here? Becoming discouraged, I looked to see how this was being handled for other builtins in mingw-w64. And mostly, there isn't any checking. Both builtins and gcc's "extended asm" syntax are routinely just assumed to be available: __CRT_INLINE float __cdecl fabsf (float x) { #if defined(__x86_64__) || defined(__arm__) return __builtin_fabsf (x); #else float res = 0.0F; __asm__ __volatile__ ("fabs;" : "=t" (res) : "0" (x)); return res; #endif } So I'm kinda stuck. I don't speak autoconfig. And I'm certainly not prepared to go thru the whole project and 'fix' all the places that use (potentially undefined) builtins. A quick check suggests there are ~50 different builtins being used in over 200 places. And I'm not sure what the 'fallback' would be in all cases. That doesn't even count the places that use gcc's extended asm. Despite my efforts, there's still a bunch of code that uses this (non-standard) feature. While I understand Kai's intention to keep the project as generic as possible, I have to wonder how practical that is. And from what I see in the code, that's currently more of a wish than reality. While it might be possible, it's not currently being done. Maybe I'm missing something. Is there a detection trick? An assumption that everybody knows that I'm not factoring in? Did I misunderstand Kai's suggestion? Hopefully one of you long-time mingw-w64 experts can provide some guidance here. But if the existing code doesn't do this detection (and if no one is objecting), maybe the answer here is to just accept that the project is defined for specific compilers. Trying to make mingw-w64 generic enough to compile under MSVC (as an example) would be a big project, and is almost certainly not worth the time. dw ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
