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

[Adrien Nader]

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 
> 
>  
> that removed some inline asm and replaced it with builtins. 
> Fixing/removing inline asm is sort of a hobby of mine.  Among other 
> things , people are usually 
> more comfortable reading and supporting code that has no asm.
> 
> Kai was generally supportive of the patch, but he suggested 
>  
> 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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[David Wohlferd]

On 10/8/2016 3:09 AM, Adrien Nader wrote:

> 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.

Seems like such an obvious question, doesn't it?  But I've struggled 
(repeatedly) to get an "official" answer to this.

The consensus (from worker bees, not project admins) seems to be that 
(probably) only clang and gcc will work (tho maybe ICC).  Also, KTietz 
once said that we need at least v4 of gcc (I'm not sure which of the v4 
features we depend on).

IMO, if we don't have someone on the dev team who is doing "regular" 
builds with a particular compiler (say at least once a month), then we 
don't really support it.  Like you said, it's just too easy to break 
something and never know it.

We already know of one popular C compiler for Windows that doesn't work: 
MSVC.  MSVC doesn't allow inline asm in x64, and mingw-w64 uses it all 
over the place.  If we aren't even going to support that, how much time 
should we spend coding for hypothetical "other" compilers?

You talked about adding autoconf checks to the build.  Yes, this could 
be done.  There are dozens of builtins that would need to be recreated 
as c code, and hundreds of places that use these builtins that would 
need to be re-tested.  Re-doing them all would be a "non-trivial" 
project.  All of which would be a huge waste of time if the reality is 
that we only support gcc and clang.

It seems like the better/faster/more complete fix would be just to add 3 
lines to the docs something like this:

The current versions of mingw-w64 are only tested/supported on these 
platforms:
- gcc v?.? and higher
- clang v?.? and higher

Even better would be to add a __MINGW_GNUC_PREREQ to _mingw.h.  If 
someone *is* using another compiler (or a really old one), this would 
help us find that out better than posting a message to the list and 
hoping to hear back from everyone.

For each mingw-w64 release, we can re-evaluate the minimum version 
number.  For the current mingw-w64 trunk (v5?), I could see this being 
set to 5.3.  That's (currently) gcc's oldest "Supported Release" (per 
https://gcc.gnu.org/).

Anyway, that's my take.  But I'm just a noisy newcomer.  Someone who 
knows both the history and the common uses of mingw-w64 is likely to 
have a different take on all this.

dw

--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public