Good morning, I'd like to bump this thread too; sorry for the inbox flux. I'm mostly interested in moving forward the general question of compiler support and feature detection or listing.
On Sat, Jul 16, 2016, dw wrote: > 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? [snip] > 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: [snip] > 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. Can anyone help list which compilers are used together with mingw-w64 in one way or another? Do some only use parts of mingw-w64 (like headers but not libs)? Considering the build system of the project, the way to handle such situation is to add checks in configure.ac with AC_CHECK_FUNC(S) or similar[1]. These macros are fairly simple to use and to understand (they try to build some trivial code that uses the functions you pass as argument). I think it makes sense to group all the bswap functions under a single check for now: I don't think there are many compilers with only half of them. That would solve the issue with building from a POSIX environment but setups that don't use the configure step will have to update to handl this too; anyway, until they do, they still have working code thanks to the fallback. Yet, it would also be useful to know which compilers are used or we are bound to repeatedly break them. Please, report in this thread if you use something else than GCC or Clang. Thanks, [1] https://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Generic-Functions.html -- Adrien Nader ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
