enable -fms-extensions by default on the mingw-w64 target

[martell]

Summary

As of commit b8a164 mingw-w64 support clang with -fms-extensions.
We can built the mingw-w64 crt with clang now also.
As we are dropping support for mingw.org I think switching to this would be a good move
rather then using the gcc hacks we currently comply to

http://sourceforge.net/p/mingw-w64/mingw-w64/ci/b8a16418409d88215cce97727a42cc25eb011f3e/

[compnerd]

Please add a unit test for this.

[rnk]

Will Clang be able to compile the last few stable mingw-w64 releases with this change? I'd like that to keep working.

[martell]

In D14180#279651, @rnk wrote:

Will Clang be able to compile the last few stable mingw-w64 releases with this change? I'd like that to keep working.

Clang has not been able to compile mingw-w64 crt for the last few releases.
I have only added support for this on HEAD.

There would be a drawback though.
Clang would not like older mingw-w64 headers.

[rnk]

In D14180#279962, @martell wrote:

In D14180#279651, @rnk wrote:

Will Clang be able to compile the last few stable mingw-w64 releases with this change? I'd like that to keep working.

Clang has not been able to compile mingw-w64 crt for the last few releases.
I have only added support for this on HEAD.

Right, I'm not worried about that.

There would be a drawback though.
Clang would not like older mingw-w64 headers.

This is what I'm worried about. :) Can you elaborate on what would break?

[martell]

This is what I'm worried about. :) Can you elaborate on what would break?

Essentially mingw-w64 has a few header defines for working around builtings such as __rtdsc and the interlocked functions and some other builtins
As soon as one of these headers are included it would result in a compile time error as it would collide with what clang now provides.

I have talked to jon_y the 4.x maintainer about this before.
We could port back my patches to next 4.x release which i believe is 4.0.4.
But essentially older versions of mingw-w64 that doesn't respect the compiler may have the builtins would not work.

We don't have to make this break now of course but we should do it at some point?

[rnk]

I'd like clang to work out of the box with mingw-w64 releases from at least the past year. You're mostly interested in the non-builtin parts of -fms-extensions, like declspec and UUID, right? One way we could do this is to enable -fms-extensions in mingw but then suppress the builtins in that environment, or have some other flag to enable them.

You can then change the mingw headers to use __has_builtin(_InterlockedCompareExchange) to provide compatibility with either mode.

[martell]

In D14180#280184, @rnk wrote:

You're mostly interested in the non-builtin parts of -fms-extensions, like declspec and UUID, right?

Yes that would be one of the main reasons, gcc is very lacking in this department :)

You can then change the mingw headers to use __has_builtin(_InterlockedCompareExchange) to provide compatibility with either mode.

Yes I could do this but this still won't work with the the existing mingw toolchains that don't have this in their headers right?
I can update head to support both though yes

[rnk]

! In D14180#280193, @martell wrote:

You can then change the mingw headers to use __has_builtin(_InterlockedCompareExchange) to provide compatibility with either mode.

Yes I could do this but this still won't work with the the existing mingw toolchains that don't have this in their headers right?
I can update head to support both though yes

I'm suggesting that we can make the builtins available in an MSVC environment, rather than making them available in an MS extensions environment. This should be compatible with old mingw headers, and then we can flip this default.

[martell]

I tried testing __has_builtin(_InterlockedCompareExchangeAdd) as it seem to not exist even when -fms-extensions is passed
Is this a bug or it is intended ?

[rnk]

In D14180#299183, @martell wrote:

I tried testing __has_builtin(_InterlockedCompareExchangeAdd) as it seem to not exist even when -fms-extensions is passed
Is this a bug or it is intended ?

Neither Clang nor MSDN have anything by that name. Do you mean _InterlockedExchangeAdd? __has_builtin should find that.

[ismail]

Hi,

[martell]

@rnk you are correct.
mingw-w64 has been updated accordingly
http://sourceforge.net/p/mingw-w64/mingw-w64/ci/61c374ded91a7de66f42f85a9f0cf9ee20/

So where do we go from here ?

Kind Regards
Martell

[rnk]

In D14180#300193, @martell wrote:

@rnk you are correct.
mingw-w64 has been updated accordingly
http://sourceforge.net/p/mingw-w64/mingw-w64/ci/61c374ded91a7de66f42f85a9f0cf9ee20/

So where do we go from here ?

Let's disable the _Interlocked* family of builtins when targeting mingw, and then flip this flag here. That way we'll work with old mingw's, and in two years we can enable the builtins in mingw. We'll also let mingw get at the rest of -fms-extensions.

lib/Driver/Tools.cpp

 
   // -fms-extensions=0 is default.
   if (Args.hasFlag(options::OPT_fms_extensions, options::OPT_fno_ms_extensions,
-                   IsWindowsMSVC))
+                   IsWindowsMSVC || IsWindowsGNU))
     CmdArgs.push_back("-fms-extensions");
 
   // -fno-use-line-directives is default.