[Mingw-w64-public] Detecting if __builtin_bswap16 is supported

[dw <lim...@ya...>]

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