Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

[David Grayson]

Hello, gcc-help.

There is an incompatibility between libstdc++ and the headers provided
by Microsoft and mingw-w64, because libstdc++ uses __in as a parameter
name in several places while the Microsoft headers define __in as a
preprocessor macro as part of their Source Annotation Language.

You can see several uses of __in in Microsoft-style code here:

https://github.com/Microsoft/Windows-driver-samples/search?q=__in

I would be willing to create, test, and submit a patch that changes
libstdc++ to use ___in (with three underscores) to avoid this issue.
I expect that to be a pretty safe change that doesn't break anything.
Maybe I would add a test to help prevent this from happening in the
future.  Would the GCC maintainers consider accepting such a patch?

Please note that I'm not trying to assign blame, I'm just trying to
get Qt to compile with the latest mingw-w64 without using hacky
workarounds.

--David

On Thu, May 11, 2017 at 7:29 AM, Liu Hao  wrote:
> On 2017/5/11 21:51, David Grayson wrote:
>> Unfortunately, my patch seems to break several classes in libstdc++,
>> preventing Qt from building.  The problem is that driverspecs.h defines
>> __in to be empty so we can compile Microsoft-type code that uses __in as a
>> source annotation on function parameters while GCC's libstdc++ uses __in as
>> the name of an input argument for many of its methods:
>>
>> $ egrep -lr '\b__in\b' /mingw32/include/
>> /mingw32/include/c++/6.3.0/bits/basic_string.h
>> /mingw32/include/c++/6.3.0/bits/basic_string.tcc
>> /mingw32/include/c++/6.3.0/bits/istream.tcc
>> /mingw32/include/c++/6.3.0/bits/locale_facets.h
>> /mingw32/include/c++/6.3.0/ext/random.tcc
>> /mingw32/include/c++/6.3.0/ext/vstring.tcc
>> /mingw32/include/c++/6.3.0/istream
>> /mingw32/include/c++/6.3.0/tr1/tuple
>> /mingw32/include/c++/6.3.0/tr1/utility
>> /mingw32/include/c++/6.3.0/tr2/bool_set
>> /mingw32/include/c++/6.3.0/tr2/bool_set.tcc
>> /mingw32/include/c++/6.3.0/tuple
>> /mingw32/include/c++/6.3.0/utility
>>
>> One of the errors I get looks like this:
>>
>> /nix/.../include/c++/6.3.0/utility:208:57: error: no matching function for
>> call to 'move()'
>>   { return __pair_get<_Int>::__move_get(std::move(__in)); }
>>
>> I don't think this is necessarily a problem with mingw-w64, or a problem
>> with that patch.  Adrien Nader's attitude on this mailing list in
>> 2015-11-03 was "Really, there's a platform and software is built on top of
>> it; it is that software that is supposed to adapt to the platform."  
>> Microsoft
>> Windows and mingw-w64 are platforms that define __in to have a special
>> meaning.  The software built on that platform (libstdc++) should adapt to
>> the platform.
> I CC'd gcc-help. Hope it helps.
> Anyway Windows headers are really a can of worms (think about the macros
> `min` and `max` for example).
>
>> One odd thing is that our __in gets defined in driverspecs.h, while
>> Microsoft defines their __in in sal.h.  But specstrings.h (for both
>> mingw-w64 and Microsoft) includes both sal.h and driverspecs.h so that
>> shouldn't affect when the bug appears.
> Both headers seem to be out of sync for years. I hope they can be
> updated someday.

--
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] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

[David Grayson]

Oh, I thought we should just get libstdc++ to patch their project.  I would
look for __in and any other badly-named parameters, and perhaps add a third
underscore to their names or something like that.  In the long term, that
would be nicer, because then users can have Microsoft-style code and
libstdc++ code used in the same translation unit and they don't have to
remember to use a guard on the include.

--David

On Thu, May 11, 2017 at 7:24 AM, Kai Tietz  wrote:

> Yes, that is a bit annoying ... sadly we can't do much about it.
>
> So I would suggest to add a guard to the include, so that it is
> user-defined, if this header should be included, or not.
> This might be a work-a-round for this, which should work for most.
>
> Regards,
> Kai
>
> 2017-05-11 15:51 GMT+02:00 David Grayson :
> > Unfortunately, my patch seems to break several classes in libstdc++,
> > preventing Qt from building.  The problem is that driverspecs.h defines
> > __in to be empty so we can compile Microsoft-type code that uses __in as
> a
> > source annotation on function parameters while GCC's libstdc++ uses __in
> as
> > the name of an input argument for many of its methods:
> >
> > $ egrep -lr '\b__in\b' /mingw32/include/
> > /mingw32/include/c++/6.3.0/bits/basic_string.h
> > /mingw32/include/c++/6.3.0/bits/basic_string.tcc
> > /mingw32/include/c++/6.3.0/bits/istream.tcc
> > /mingw32/include/c++/6.3.0/bits/locale_facets.h
> > /mingw32/include/c++/6.3.0/ext/random.tcc
> > /mingw32/include/c++/6.3.0/ext/vstring.tcc
> > /mingw32/include/c++/6.3.0/istream
> > /mingw32/include/c++/6.3.0/tr1/tuple
> > /mingw32/include/c++/6.3.0/tr1/utility
> > /mingw32/include/c++/6.3.0/tr2/bool_set
> > /mingw32/include/c++/6.3.0/tr2/bool_set.tcc
> > /mingw32/include/c++/6.3.0/tuple
> > /mingw32/include/c++/6.3.0/utility
> >
> > One of the errors I get looks like this:
> >
> > /nix/.../include/c++/6.3.0/utility:208:57: error: no matching function
> for
> > call to 'move()'
> >  { return __pair_get<_Int>::__move_get(std::move(__in)); }
> >
> > I don't think this is necessarily a problem with mingw-w64, or a problem
> > with that patch.  Adrien Nader's attitude on this mailing list in
> > 2015-11-03 was "Really, there's a platform and software is built on top
> of
> > it; it is that software that is supposed to adapt to the platform."
> Microsoft
> > Windows and mingw-w64 are platforms that define __in to have a special
> > meaning.  The software built on that platform (libstdc++) should adapt to
> > the platform.
> >
> > One odd thing is that our __in gets defined in driverspecs.h, while
> > Microsoft defines their __in in sal.h.  But specstrings.h (for both
> > mingw-w64 and Microsoft) includes both sal.h and driverspecs.h so that
> > shouldn't affect when the bug appears.
> >
> > --David Grayson
> >
> > On Wed, May 10, 2017 at 9:44 AM, David Grayson 
> > wrote:
> >
> >> Yeah, sorry, I only sent those patches to LH by mistake.  Yes, I
> purposely
> >> used the same include guard name as Microsoft.
> >>
> >> --David
> >>
> >> On Wed, May 10, 2017 at 8:55 AM, Liu Hao  wrote:
> >>
> >>>
> >>>
> >>>
> >>>  Forwarded Message 
> >>> Subject:Re: [Mingw-w64-public] [PATCH] Include driverspecs.h in
> >>> specstrings.h.
> >>> Date:   Wed, 10 May 2017 08:24:25 -0700
> >>> From:   David Grayson 
> >>> To: Liu Hao 
> >>>
> >>>
> >>>
> >>> OK, thanks.  I've attached a new patch where the #include is after the
> >>> __cplusplus stuff.
> >>>
> >>> I also included a second patch that will add an include guard for
> >>> specstrings.h, since Microsoft seems to do that too.
> >>>
> >>> driverspecs.h is also missing an include guard but it is part of the
> >>> React DDK so I didn't want to mess around with editing at the moment.
> >>>
> >>> --David
> >>>
> >>> On Tue, May 9, 2017 at 9:07 PM, Liu Hao >> lh_mo...@126.com>> wrote:
> >>>
> >>> On 2017/5/10 10:34, David Grayson wrote:
> >>>
> >>> This patch adds "#include " near the end of
> >>> specstrings.h,
> >>> because the same is done in Microsoft's version of
> >>> specstrings.h.  With
> >>> this patch, I am able to build Microsoft's devcon utility
> without
> >>> modification.  Thanks!
> >>>
> >>> You must `#include` that header AFTER the `#ifdef __cplusplus ...
> >>> #endif` block.
> >>>
> >>> Anyway, this header seems short of a header guard. I shall ask
> >>> someone for sure.
> >>>
> >>> -- Best regards,
> >>> LH_Mouse
> >>>
> >>>
> >>>
> >>> 
> >>> --
> >>> 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
> 

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

[Liu Hao]

On 2017/5/11 21:51, David Grayson wrote:
> Unfortunately, my patch seems to break several classes in libstdc++,
> preventing Qt from building.  The problem is that driverspecs.h defines
> __in to be empty so we can compile Microsoft-type code that uses __in as a
> source annotation on function parameters while GCC's libstdc++ uses __in as
> the name of an input argument for many of its methods:
> 
> $ egrep -lr '\b__in\b' /mingw32/include/
> /mingw32/include/c++/6.3.0/bits/basic_string.h
> /mingw32/include/c++/6.3.0/bits/basic_string.tcc
> /mingw32/include/c++/6.3.0/bits/istream.tcc
> /mingw32/include/c++/6.3.0/bits/locale_facets.h
> /mingw32/include/c++/6.3.0/ext/random.tcc
> /mingw32/include/c++/6.3.0/ext/vstring.tcc
> /mingw32/include/c++/6.3.0/istream
> /mingw32/include/c++/6.3.0/tr1/tuple
> /mingw32/include/c++/6.3.0/tr1/utility
> /mingw32/include/c++/6.3.0/tr2/bool_set
> /mingw32/include/c++/6.3.0/tr2/bool_set.tcc
> /mingw32/include/c++/6.3.0/tuple
> /mingw32/include/c++/6.3.0/utility
> 
> One of the errors I get looks like this:
> 
> /nix/.../include/c++/6.3.0/utility:208:57: error: no matching function for
> call to 'move()'
>   { return __pair_get<_Int>::__move_get(std::move(__in)); }
> 
> I don't think this is necessarily a problem with mingw-w64, or a problem
> with that patch.  Adrien Nader's attitude on this mailing list in
> 2015-11-03 was "Really, there's a platform and software is built on top of
> it; it is that software that is supposed to adapt to the platform."  Microsoft
> Windows and mingw-w64 are platforms that define __in to have a special
> meaning.  The software built on that platform (libstdc++) should adapt to
> the platform.
I CC'd gcc-help. Hope it helps.
Anyway Windows headers are really a can of worms (think about the macros 
`min` and `max` for example).

> One odd thing is that our __in gets defined in driverspecs.h, while
> Microsoft defines their __in in sal.h.  But specstrings.h (for both
> mingw-w64 and Microsoft) includes both sal.h and driverspecs.h so that
> shouldn't affect when the bug appears.
Both headers seem to be out of sync for years. I hope they can be 
updated someday.


-- 
Best regards,
LH_Mouse


--
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] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

[Kai Tietz]

Yes, that is a bit annoying ... sadly we can't do much about it.

So I would suggest to add a guard to the include, so that it is
user-defined, if this header should be included, or not.
This might be a work-a-round for this, which should work for most.

Regards,
Kai

2017-05-11 15:51 GMT+02:00 David Grayson :
> Unfortunately, my patch seems to break several classes in libstdc++,
> preventing Qt from building.  The problem is that driverspecs.h defines
> __in to be empty so we can compile Microsoft-type code that uses __in as a
> source annotation on function parameters while GCC's libstdc++ uses __in as
> the name of an input argument for many of its methods:
>
> $ egrep -lr '\b__in\b' /mingw32/include/
> /mingw32/include/c++/6.3.0/bits/basic_string.h
> /mingw32/include/c++/6.3.0/bits/basic_string.tcc
> /mingw32/include/c++/6.3.0/bits/istream.tcc
> /mingw32/include/c++/6.3.0/bits/locale_facets.h
> /mingw32/include/c++/6.3.0/ext/random.tcc
> /mingw32/include/c++/6.3.0/ext/vstring.tcc
> /mingw32/include/c++/6.3.0/istream
> /mingw32/include/c++/6.3.0/tr1/tuple
> /mingw32/include/c++/6.3.0/tr1/utility
> /mingw32/include/c++/6.3.0/tr2/bool_set
> /mingw32/include/c++/6.3.0/tr2/bool_set.tcc
> /mingw32/include/c++/6.3.0/tuple
> /mingw32/include/c++/6.3.0/utility
>
> One of the errors I get looks like this:
>
> /nix/.../include/c++/6.3.0/utility:208:57: error: no matching function for
> call to 'move()'
>  { return __pair_get<_Int>::__move_get(std::move(__in)); }
>
> I don't think this is necessarily a problem with mingw-w64, or a problem
> with that patch.  Adrien Nader's attitude on this mailing list in
> 2015-11-03 was "Really, there's a platform and software is built on top of
> it; it is that software that is supposed to adapt to the platform."  Microsoft
> Windows and mingw-w64 are platforms that define __in to have a special
> meaning.  The software built on that platform (libstdc++) should adapt to
> the platform.
>
> One odd thing is that our __in gets defined in driverspecs.h, while
> Microsoft defines their __in in sal.h.  But specstrings.h (for both
> mingw-w64 and Microsoft) includes both sal.h and driverspecs.h so that
> shouldn't affect when the bug appears.
>
> --David Grayson
>
> On Wed, May 10, 2017 at 9:44 AM, David Grayson 
> wrote:
>
>> Yeah, sorry, I only sent those patches to LH by mistake.  Yes, I purposely
>> used the same include guard name as Microsoft.
>>
>> --David
>>
>> On Wed, May 10, 2017 at 8:55 AM, Liu Hao  wrote:
>>
>>>
>>>
>>>
>>>  Forwarded Message 
>>> Subject:Re: [Mingw-w64-public] [PATCH] Include driverspecs.h in
>>> specstrings.h.
>>> Date:   Wed, 10 May 2017 08:24:25 -0700
>>> From:   David Grayson 
>>> To: Liu Hao 
>>>
>>>
>>>
>>> OK, thanks.  I've attached a new patch where the #include is after the
>>> __cplusplus stuff.
>>>
>>> I also included a second patch that will add an include guard for
>>> specstrings.h, since Microsoft seems to do that too.
>>>
>>> driverspecs.h is also missing an include guard but it is part of the
>>> React DDK so I didn't want to mess around with editing at the moment.
>>>
>>> --David
>>>
>>> On Tue, May 9, 2017 at 9:07 PM, Liu Hao > lh_mo...@126.com>> wrote:
>>>
>>> On 2017/5/10 10:34, David Grayson wrote:
>>>
>>> This patch adds "#include " near the end of
>>> specstrings.h,
>>> because the same is done in Microsoft's version of
>>> specstrings.h.  With
>>> this patch, I am able to build Microsoft's devcon utility without
>>> modification.  Thanks!
>>>
>>> You must `#include` that header AFTER the `#ifdef __cplusplus ...
>>> #endif` block.
>>>
>>> Anyway, this header seems short of a header guard. I shall ask
>>> someone for sure.
>>>
>>> -- Best regards,
>>> LH_Mouse
>>>
>>>
>>>
>>> 
>>> --
>>> 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
>>>
>>>
>>
> --
> 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

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

[David Grayson]

Unfortunately, my patch seems to break several classes in libstdc++,
preventing Qt from building.  The problem is that driverspecs.h defines
__in to be empty so we can compile Microsoft-type code that uses __in as a
source annotation on function parameters while GCC's libstdc++ uses __in as
the name of an input argument for many of its methods:

$ egrep -lr '\b__in\b' /mingw32/include/
/mingw32/include/c++/6.3.0/bits/basic_string.h
/mingw32/include/c++/6.3.0/bits/basic_string.tcc
/mingw32/include/c++/6.3.0/bits/istream.tcc
/mingw32/include/c++/6.3.0/bits/locale_facets.h
/mingw32/include/c++/6.3.0/ext/random.tcc
/mingw32/include/c++/6.3.0/ext/vstring.tcc
/mingw32/include/c++/6.3.0/istream
/mingw32/include/c++/6.3.0/tr1/tuple
/mingw32/include/c++/6.3.0/tr1/utility
/mingw32/include/c++/6.3.0/tr2/bool_set
/mingw32/include/c++/6.3.0/tr2/bool_set.tcc
/mingw32/include/c++/6.3.0/tuple
/mingw32/include/c++/6.3.0/utility

One of the errors I get looks like this:

/nix/.../include/c++/6.3.0/utility:208:57: error: no matching function for
call to 'move()'
 { return __pair_get<_Int>::__move_get(std::move(__in)); }

I don't think this is necessarily a problem with mingw-w64, or a problem
with that patch.  Adrien Nader's attitude on this mailing list in
2015-11-03 was "Really, there's a platform and software is built on top of
it; it is that software that is supposed to adapt to the platform."  Microsoft
Windows and mingw-w64 are platforms that define __in to have a special
meaning.  The software built on that platform (libstdc++) should adapt to
the platform.

One odd thing is that our __in gets defined in driverspecs.h, while
Microsoft defines their __in in sal.h.  But specstrings.h (for both
mingw-w64 and Microsoft) includes both sal.h and driverspecs.h so that
shouldn't affect when the bug appears.

--David Grayson

On Wed, May 10, 2017 at 9:44 AM, David Grayson 
wrote:

> Yeah, sorry, I only sent those patches to LH by mistake.  Yes, I purposely
> used the same include guard name as Microsoft.
>
> --David
>
> On Wed, May 10, 2017 at 8:55 AM, Liu Hao  wrote:
>
>>
>>
>>
>>  Forwarded Message 
>> Subject:Re: [Mingw-w64-public] [PATCH] Include driverspecs.h in
>> specstrings.h.
>> Date:   Wed, 10 May 2017 08:24:25 -0700
>> From:   David Grayson 
>> To: Liu Hao 
>>
>>
>>
>> OK, thanks.  I've attached a new patch where the #include is after the
>> __cplusplus stuff.
>>
>> I also included a second patch that will add an include guard for
>> specstrings.h, since Microsoft seems to do that too.
>>
>> driverspecs.h is also missing an include guard but it is part of the
>> React DDK so I didn't want to mess around with editing at the moment.
>>
>> --David
>>
>> On Tue, May 9, 2017 at 9:07 PM, Liu Hao  lh_mo...@126.com>> wrote:
>>
>> On 2017/5/10 10:34, David Grayson wrote:
>>
>> This patch adds "#include " near the end of
>> specstrings.h,
>> because the same is done in Microsoft's version of
>> specstrings.h.  With
>> this patch, I am able to build Microsoft's devcon utility without
>> modification.  Thanks!
>>
>> You must `#include` that header AFTER the `#ifdef __cplusplus ...
>> #endif` block.
>>
>> Anyway, this header seems short of a header guard. I shall ask
>> someone for sure.
>>
>> -- Best regards,
>> LH_Mouse
>>
>>
>>
>> 
>> --
>> 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
>>
>>
>
--
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] [PATCH] intrincs: check for __rdtsc

[Martell Malone]

Thanks Kai,

We probably don't need to push and pop because this is not a header to be
installed

Updated diff

diff --git a/mingw-w64-crt/intrincs/rdtsc.c b/mingw-w64-crt/intrincs/rdtsc.c
index fd9cb75d..bf9c03b3 100644
--- a/mingw-w64-crt/intrincs/rdtsc.c
+++ b/mingw-w64-crt/intrincs/rdtsc.c
@@ -4,11 +4,14 @@
  * No warranty is given; refer to the file DISCLAIMER.PD within this
package.
  */
-#ifdef __clang__
-#define __IA32INTRIN_H
-#endif
 #include 
+/* Clang has support for MSVC builtins, GCC doesn't */
+#ifndef __has_builtin
+  #define __has_builtin(x) 0
+#endif
+
+#if !__has_builtin(__rdtsc)
 unsigned __int64 __rdtsc(void)
 {
 #ifdef _WIN64
@@ -21,4 +24,4 @@ unsigned __int64 __rdtsc(void)
   : "=a" (val1), "=d" (val2));
   return ((unsigned __int64)val1) | (((unsigned __int64)val2) << 32);
 }
-
+#endif

On Thu, May 11, 2017 at 1:15 PM, Kai Tietz  wrote:

> Hmm, where is the corresponding pop_macro pragma?
>
> Regards,
> Kai
>
> 2017-05-11 14:09 GMT+02:00 Martell Malone :
> >>
> >> While it's not "good form" to have the prototype
> >> in multiple places...
> >
> > Attached updated diff
> >
> > Please Review
> >
> > diff --git a/mingw-w64-crt/intrincs/rdtsc.c b/mingw-w64-crt/intrincs/
> rdtsc.c
> > index fd9cb75d..7c5adeb0 100644
> > --- a/mingw-w64-crt/intrincs/rdtsc.c
> > +++ b/mingw-w64-crt/intrincs/rdtsc.c
> > @@ -4,11 +4,15 @@
> >   * No warranty is given; refer to the file DISCLAIMER.PD within this
> > package.
> >   */
> > -#ifdef __clang__
> > -#define __IA32INTRIN_H
> > -#endif
> >  #include 
> > +/* Clang has support for MSVC builtins, GCC doesn't */
> > +#pragma push_macro("__has_builtin")
> > +#ifndef __has_builtin
> > +  #define __has_builtin(x) 0
> > +#endif
> > +
> > +#if !__has_builtin(__rdtsc)
> >  unsigned __int64 __rdtsc(void)
> >  {
> >  #ifdef _WIN64
> > @@ -21,4 +25,4 @@ unsigned __int64 __rdtsc(void)
> >: "=a" (val1), "=d" (val2));
> >return ((unsigned __int64)val1) | (((unsigned __int64)val2) <<
> 32);
> >  }
> > -
> > +#endif
> >
> > On Sun, Apr 16, 2017 at 3:06 AM, David Wohlferd 
> > wrote:
> >
> >> On 4/14/2017 7:14 AM, Martell Malone wrote:
> >> > Updated clang no longer defines __IA32INTRIN_H so lets do this
> properly.
> >>
> >> It appears that the only use for  in that file is the
> >> prototype for __rdtsc.  While it's not "good form" to have the prototype
> >> in multiple places...
> >>
> >> > I assume intrin-impl.h is only ever included by intrin.h?
> >>
> >> Fraid not.
> >>
> >> mingw-w64-headers\include\winbase.h:#include 
> >> mingw-w64-headers\include\winnt.h:#include 
> >>
> >> > If not I will have to find a way to deal with __has_builtin in both
> files
> >>
> >>
> >> 
> >> --
> >> 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
> >>
> > 
> --
> > 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
>
> 
> --
> 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
>
--
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] [PATCH] intrincs: check for __rdtsc

[Martell Malone]

>
> While it's not "good form" to have the prototype
> in multiple places...

Attached updated diff

Please Review

diff --git a/mingw-w64-crt/intrincs/rdtsc.c b/mingw-w64-crt/intrincs/rdtsc.c
index fd9cb75d..7c5adeb0 100644
--- a/mingw-w64-crt/intrincs/rdtsc.c
+++ b/mingw-w64-crt/intrincs/rdtsc.c
@@ -4,11 +4,15 @@
  * No warranty is given; refer to the file DISCLAIMER.PD within this
package.
  */
-#ifdef __clang__
-#define __IA32INTRIN_H
-#endif
 #include 
+/* Clang has support for MSVC builtins, GCC doesn't */
+#pragma push_macro("__has_builtin")
+#ifndef __has_builtin
+  #define __has_builtin(x) 0
+#endif
+
+#if !__has_builtin(__rdtsc)
 unsigned __int64 __rdtsc(void)
 {
 #ifdef _WIN64
@@ -21,4 +25,4 @@ unsigned __int64 __rdtsc(void)
   : "=a" (val1), "=d" (val2));
   return ((unsigned __int64)val1) | (((unsigned __int64)val2) << 32);
 }
-
+#endif

On Sun, Apr 16, 2017 at 3:06 AM, David Wohlferd 
wrote:

> On 4/14/2017 7:14 AM, Martell Malone wrote:
> > Updated clang no longer defines __IA32INTRIN_H so lets do this properly.
>
> It appears that the only use for  in that file is the
> prototype for __rdtsc.  While it's not "good form" to have the prototype
> in multiple places...
>
> > I assume intrin-impl.h is only ever included by intrin.h?
>
> Fraid not.
>
> mingw-w64-headers\include\winbase.h:#include 
> mingw-w64-headers\include\winnt.h:#include 
>
> > If not I will have to find a way to deal with __has_builtin in both files
>
>
> 
> --
> 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
>
--
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