from:"dw"

On 7/7/2016 4:49 PM, Ozkan Sezer wrote:
> On 7/8/16, dw <limegreenso...@yahoo.com> wrote:
>> In any case, did you have a chance to look at the patch?
> Unfortunately no. Kai would be the guy for reviewing asm stuff.

Ok then.  I hope he has the time.

How about the .c files?  They become pretty simple after this patch is 
applied, but still.

I have some thoughts about the ARM stuff (maybe using the same approach 
I'm using for the i386?), but I don't really speak ARM. Does André hang 
out here?

dw

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
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] Issues with vsscanf - first draft

On 7/7/2016 4:06 PM, Ozkan Sezer wrote:
> Two copies of this message arrived: the one from your yahoo
> account is sent to spam folder by gmail and doesn't have the
> patch. The one from your limegreensocks went properly into the
> inbox and does have the patch.  Something to do with yahoo
> perhaps?

The one from yahoo went thru the Mingw-w64 mailing list.  The one from 
LimeGreenSocks.com (which was rejected by the list since it isn't a 
member) also had you on the To line.

While I don't discount yahoo as a possible factor, I'm thinking the 
problem is the list.

In any case, did you have a chance to look at the patch?

dw

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
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] Issues with vsscanf - first draft

On 7/7/2016 6:45 AM, Ozkan Sezer wrote:

On 7/7/16, dw <limegreenso...@yahoo.com> wrote:

I was looking to see if there was any more inline asm that could be
removed from mingw-w64. That brought me to vsscanf (and friends). This
looked to be a messy bit of code that could probably use a review.

As I started looking through it, I found what I believe to be a bunch of
flaws (see
https://codereview.stackexchange.com/questions/133266/turn-a-vsscanf-call-into-a-sscanf-call).

I started trying to clean it up, but eventually decided that the only
way to really make this 'clean' was to re-write it in pure assembly.
Which I have done.

I've got a first draft attached. I don't know that this follows
standard mingw-w64 coding conventions, but it follows Windows coding
standards better than the existing code.

My question is: Now what?

The patch is written. I've tested it and it looks like it works. Where
do we go from here?

Comments and advice are welcome. Remember to regen Makefile.in if you
want to build this.

There are no patches attached.

Umm. Hmm. Looking in my 'Sent Items' there is. But looking at the
list archives, there isn't.

I've attached it again, but since I'm not sure what went wrong the first
time, I've also put it at http://www.limegreensocks.com/m6.patch (just
in case).

dw
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [Patch] Issues with vsscanf - first draft

I was looking to see if there was any more inline asm that could be 
removed from mingw-w64.  That brought me to vsscanf (and friends). This 
looked to be a messy bit of code that could probably use a review.


As I started looking through it, I found what I believe to be a bunch of 
flaws (see 
https://codereview.stackexchange.com/questions/133266/turn-a-vsscanf-call-into-a-sscanf-call). 
I started trying to clean it up, but eventually decided that the only 
way to really make this 'clean' was to re-write it in pure assembly.  
Which I have done.


I've got a first draft attached.  I don't know that this follows 
standard mingw-w64 coding conventions, but it follows Windows coding 
standards better than the existing code.


My question is: Now what?

The patch is written.  I've tested it and it looks like it works. Where 
do we go from here?


Comments and advice are welcome.  Remember to regen Makefile.in if you 
want to build this.


dw
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] intrin-impl.h and @cc

2015-11-18 Thread dw

GCC 6.0 has introduced a new feature that allows inline asm to return 
flag registers (see 
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#FlagOutputOperands). There 
are a couple dozen intrinsics in intrin-impl.h that would benefit from 
using this.


There is a define that signals if the gcc feature is available, so 
backward compatibility is straight-forward.  I have updated 
intrin-impl.h and run it thru my test suite.  It looks good.


The patch is attached, but I'm no expert with git, so I'm not sure the 
format is correct.  If it would be easier, I can just attach the .h file.


For people who want to know the nitty gritty:

Before this feature, you had to write code like this:

   asm("bt $0, %1 ; setc %0" : "=q" (a) : "r" (value) : "cc");

This would generate code like this:

bt $0, %ebx
setc %al <- Convert flags to byte
testb   %al, %al <-- Convert byte back to flags
jne .L5
leaq.LC1(%rip), %rcx
callprintf

Using @cc, this code

   asm("bt $0, %1" : "=@ccc" (a) : "r" (value) );

produces this output:

bt $0, %ebx
jc  .L5 <- Use the flags directly
leaq.LC1(%rip), %rcx
callprintf

dw
commit 527ef2be12fefe658cdf9a43fdc69601d005057c
Author: David Wohlferd <d...@limegreensocks.com>
Date:   Tue Nov 17 13:13:30 2015 -0800

Support gcc 6 flag constraints

Signed-off-by: David Wohlferd <d...@limegreensocks.com>

diff --git a/mingw-w64-headers/include/psdk_inc/intrin-impl.h b/mingw-w64-headers/include/psdk_inc/intrin-impl.h
index 7b2882e..9645e24 100644
--- a/mingw-w64-headers/include/psdk_inc/intrin-impl.h
+++ b/mingw-w64-headers/include/psdk_inc/intrin-impl.h
@@ -66,6 +66,20 @@ __INTRINSICS_USEINLINE
 #ifndef _INTRIN_MAC_
 #define _INTRIN_MAC_
 
+/* GCC v6 added support for outputting flags.  This allows better code to be
+   produced for a number of intrinsics. */
+#ifndef __GCC_ASM_FLAG_OUTPUTS__
+#define __FLAGCONSTRAINT "=qm"
+#define __FLAGSET "\n\tsetc %[old]"
+#define __FLAGCLOBBER1 , "cc"
+#define __FLAGCLOBBER2 "cc"
+#else
+#define __FLAGCONSTRAINT "=@ccc"
+#define __FLAGSET
+#define __FLAGCLOBBER1
+#define __FLAGCLOBBER2
+#endif
+
 /* This macro is used by __stosb, __stosw, __stosd, __stosq */
 
 /* Parameters: (FunctionName, DataType, Operator)
@@ -109,9 +123,9 @@ __INTRINSICS_USEINLINE
 { \
unsigned char old; \
__asm__ __volatile__ (z \
-  : [old] "=qm" (old), [Base] "+m" (*Base) \
+  : [old] __FLAGCONSTRAINT (old), [Base] "+m" (*Base) \
   : [Offset] a "r" (Offset) \
-  : "memory", "cc"); \
+  : "memory" __FLAGCLOBBER1); \
return old; \
 }
 #elif defined(__arm__) || defined(_ARM_)
@@ -193,6 +207,9 @@ Parameters: (FunctionName, DataType, Segment)
DataType: unsigned __LONG32 or unsigned __int64
Statement: BSF or BSR */
 
+/* GCC v6 added support for outputting flags.  This allows better code to be
+   produced for a number of intrinsics. */
+#ifndef __GCC_ASM_FLAG_OUTPUTS__
 #define __buildbitscan(x, y, z) unsigned char x(unsigned __LONG32 *Index, y Mask) \
 { \
y n; \
@@ -203,6 +220,18 @@ Parameters: (FunctionName, DataType, Segment)
*Index = n; \
return Mask!=0; \
 }
+#else
+#define __buildbitscan(x, y, z) unsigned char x(unsigned __LONG32 *Index, y Mask) \
+{ \
+   y n; \
+   unsigned char old; \
+   __asm__ (z \
+  : "=@ccnz" (old), [Index] "=r" (n) \
+  : [Mask] "r" (Mask)); \
+   *Index = n; \
+   return old; \
+}
+#endif
 
 /* This macro is used by _bittest & _bittest64
 
@@ -216,10 +245,10 @@ Parameters: (FunctionName, DataType, OffsetConstraint)
 #define __buildbittest(x, y, z, a) unsigned char x(const y *Base, y Offset) \
 { \
unsigned char old; \
-   __asm__ ("bt{" z " %[Offset],%[Base] | %[Base],%[Offset]} ; setc %[old]" \
-  : [old] "=rm" (old) \
+   __asm__ ("bt{" z " %[Offset],%[Base] | %[Base],%[Offset]}" __FLAGSET \
+  : [old] __FLAGCONSTRAINT (old) \
   : [Offset] a "r" (Offset), [Base] "rm" (*Base) \
-  : "cc"); \
+  : __FLAGCLOBBER2); \
return old; \
 }
 
@@ -236,10 +265,10 @@ Parameters: (FunctionName, DataType, Statement, OffsetConstraint)
 #define __buildbittestand(x, y, z, a, b) unsigned char x(y *Base, y Offset) \
 { \
unsigned char old; \
-   __asm__ (z "{" b " %[Offset],%[Base] | %[Base],%[Offset]} ; setc %[old]" \
-  : [old] "=r" (old), [Base] "+rm" (*Base) \
+   __asm__ (z "{" b " %[Offset],%[Base] | %[Base],%[Offset]}" __FLAGSET \
+  : [old] __FLAGCONSTRAINT (old), [Base] "+rm" (*Base) \
   : [Offset] a "r" (Offset)

Re: [Mingw-w64-public] lrotl (final)

2015-02-26 Thread dw

A question has been asked about why I deleted the #pragma push_macro 
and #pragma pop_macro that was there around the old lrotl.


The problem push/pop was trying to solve is quite simple. In 
x86intrin.h, there is a line like this:


#define _lrotl(a,b) __rolq((a), (b))

Now, with that in mind, what happens in intrin.h if you have this 
*after* that #define:


unsigned long __cdecl _lrotl(unsigned long _Val,int _Shift);

It ends up mangling it.  So, what the existing code does is:

#pragma push_macro (_lrotl) // Save the definition
#undef _lrotl // Temporarily delete it
unsigned long __cdecl _lrotl(unsigned long _Val,int _Shift);
#pragma pop_macro (_lrotl)  // Restore it

The effect of this is that intrin.h was able to do a prototype for 
_lrotl even if x86intrin.h has done a #define, without permanently 
deleting the #define.


Now, why don't we need it anymore?

There are 2 parts to this answer:

1) If you are including intrin.h, there is an inline (non-asm) version 
of lrotl defined in intrin-impl.h.  We don't need to push/pop a 
definition since we're *removing* x86intrin's mappings to rolq and 
making our own.  Among other things, this means the definition is there 
for non-x86 platforms.  And it avoids gcc's bug (#61662).  Also, our 
code will work on that day in the future when longs become 128 bit...


2) If you are including stdlib.h, we only do the #undef's if we see that 
the buggy version of x86intrin.h was included.  Otherwise, we leave 
x86intrin's definitions there in case intrin.h is never included.


Hope this helps explain my thinking here.  If I have missed something, 
please let me know.


dw

On 2/21/2015 12:03 PM, dw wrote:


On 2/19/2015 10:47 AM, Martell Malone wrote:

This has ended up in my spam folder as it did not pass some yahoo checks.
I assume others have the same issue which is why there was no reply.

Could you give me a commit msg to go with the signed off so we can 
look at getting it merged


How about something along the lines of: _lrotl gave wrong answer on LLP64.

However, before you proceed, you should be aware that kai had some 
comments about the patch.  I haven't replied before now because while 
I don't agree with his comments, providing convincing reasons why is hard.


He asked:

1) why disallowing to save user's macro-definitions anymore?

Presumably this refers to the #undefs I have in the patch.  They are 
there to remove the buggy definitions of lrotl and lrotr that are in 
x86intrin.h (actually i86intrin.h) in gcc builds prior to 4.9.2.  They 
also resolve conflicts between the implementation defined in 
intrin-impl.h and i86intrin.h.


As for disallowing saving user's macro-definitions, I'm not sure I 
follow.  If someone wants to override the definitions for lrotl (an 
odd thing to do, but possible), they would do the same thing for lrotl 
that they would do for any of the other functions implemented in 
intrin-impl.h: Include the header, *then* define the replacement 
macro.  For example, trying to do #define __stosb __mystosb *before* 
including intrin.h wouldn't have the desired effect (since it would 
also rename the implementation).  And if you do #define _lrotl _myrotl 
*after* including intrin.h, everything works as expected.  No sure 
what I have disallowed.


2) I would like to see instead of use of 'long' the macro '__LONG32'

This requires a bit more thought. For 32bit and 64bit native Windows 
(LLP64 
http://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models), 
his suggestion and my current implementation return exactly the same 
results.  The only case where they return different results is 
cigwin64 (LP64).


The key question here is: If longs are 64bits, what would you expect 
mingw-w64's _lrotr(1,1) to return?  0x8000 (kai's suggestion)?  Or 
0x8000 (my patch)?  An argument could be made for either.


Does using one approach or the other make things easier if users 
mistakenly send a 64bit long to LONG32 or vice versa?  No, it doesn't, 
so that doesn't add support to either his approach or mine.


Probably the most compelling reason to decide one way or the other is 
that doing what kai suggests produces results that are inconsistent 
with what gcc itself does in x86intrin.h.  Following his approach (on 
LP64 systems), if you #include x86intrin.h, _lrotl(1,1) would return 
0x8000, while #include intrin.h would return 0x8000. 
Returning different results depending on which headers are included 
seems bad.  I believe being consistent with gcc (my current patch) so 
that _lrotl always returns the same result is the better plan.


There may be circumstances I haven't considered that would change my 
mind, but currently I see no reason to change this patch.


dw



On Wed, Feb 11, 2015 at 9:56 AM, dw limegreenso...@yahoo.com 
mailto:limegreenso...@yahoo.com wrote:


I wasn't completely satisfied with my previous patch for lrotl
(which is why I didn't push

Re: [Mingw-w64-public] lrotl (final)

2015-02-21 Thread dw



On 2/19/2015 10:47 AM, Martell Malone wrote:

This has ended up in my spam folder as it did not pass some yahoo checks.
I assume others have the same issue which is why there was no reply.

Could you give me a commit msg to go with the signed off so we can 
look at getting it merged


How about something along the lines of: _lrotl gave wrong answer on LLP64.

However, before you proceed, you should be aware that kai had some 
comments about the patch.  I haven't replied before now because while I 
don't agree with his comments, providing convincing reasons why is hard.


He asked:

1) why disallowing to save user's macro-definitions anymore?

Presumably this refers to the #undefs I have in the patch.  They are 
there to remove the buggy definitions of lrotl and lrotr that are in 
x86intrin.h (actually i86intrin.h) in gcc builds prior to 4.9.2. They 
also resolve conflicts between the implementation defined in 
intrin-impl.h and i86intrin.h.


As for disallowing saving user's macro-definitions, I'm not sure I 
follow.  If someone wants to override the definitions for lrotl (an odd 
thing to do, but possible), they would do the same thing for lrotl that 
they would do for any of the other functions implemented in 
intrin-impl.h: Include the header, *then* define the replacement macro.  
For example, trying to do #define __stosb __mystosb *before* including 
intrin.h wouldn't have the desired effect (since it would also rename 
the implementation).  And if you do #define _lrotl _myrotl *after* 
including intrin.h, everything works as expected. No sure what I have 
disallowed.


2) I would like to see instead of use of 'long' the macro '__LONG32'

This requires a bit more thought. For 32bit and 64bit native Windows 
(LLP64 
http://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models), his 
suggestion and my current implementation return exactly the same 
results.  The only case where they return different results is cigwin64 
(LP64).


The key question here is: If longs are 64bits, what would you expect 
mingw-w64's _lrotr(1,1) to return?  0x8000 (kai's suggestion)? Or 
0x8000 (my patch)?  An argument could be made for either.


Does using one approach or the other make things easier if users 
mistakenly send a 64bit long to LONG32 or vice versa?  No, it doesn't, 
so that doesn't add support to either his approach or mine.


Probably the most compelling reason to decide one way or the other is 
that doing what kai suggests produces results that are inconsistent with 
what gcc itself does in x86intrin.h.  Following his approach (on LP64 
systems), if you #include x86intrin.h, _lrotl(1,1) would return 
0x8000, while #include intrin.h would return 0x8000.  
Returning different results depending on which headers are included 
seems bad.  I believe being consistent with gcc (my current patch) so 
that _lrotl always returns the same result is the better plan.


There may be circumstances I haven't considered that would change my 
mind, but currently I see no reason to change this patch.


dw



On Wed, Feb 11, 2015 at 9:56 AM, dw limegreenso...@yahoo.com 
mailto:limegreenso...@yahoo.com wrote:


I wasn't completely satisfied with my previous patch for lrotl
(which is why I didn't push to get it committed).  The changes for
intrin.h and intrin-impl.h were fine, but I wasn't satisfied with
the changes to stdlib.h.  Now that I've had a chance to think
about it again, I finally settled on this (attached).

It performs pretty much the same as what's in the current file (to
avoid potential breakage) while making at least some attempt to
fix the problem that can occur with old (broken) versions of
x86intrin.h.

My previous post attempted to try to do mappings, but that just
leads to conflicts with other headers and undefined symbols.

Comments?  Suggestions?  Or can we finally call this done?

dw


--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot
Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and
more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
mailto:Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved

[Mingw-w64-public] lrotl (final)

2015-02-11 Thread dw

I wasn't completely satisfied with my previous patch for lrotl (which is 
why I didn't push to get it committed).  The changes for intrin.h and 
intrin-impl.h were fine, but I wasn't satisfied with the changes to 
stdlib.h.  Now that I've had a chance to think about it again, I finally 
settled on this (attached).


It performs pretty much the same as what's in the current file (to avoid 
potential breakage) while making at least some attempt to fix the 
problem that can occur with old (broken) versions of x86intrin.h.


My previous post attempted to try to do mappings, but that just leads to 
conflicts with other headers and undefined symbols.


Comments?  Suggestions?  Or can we finally call this done?

dw
From d11d4e0560e9c086d9b8d85005bee28a1a0de787 Mon Sep 17 00:00:00 2001
From: David Wohlferd d...@limegreensocks.com
Date: Wed, 11 Feb 2015 01:20:30 -0800
Subject: [PATCH] Signed-off-by: David Wohlferd d...@limegreensocks.com

---
 mingw-w64-headers/crt/intrin.h   | 19 +--
 mingw-w64-headers/crt/stdlib.h   | 30 +++-
 mingw-w64-headers/include/psdk_inc/intrin-impl.h | 24 +++
 3 files changed, 49 insertions(+), 24 deletions(-)

diff --git a/mingw-w64-headers/crt/intrin.h b/mingw-w64-headers/crt/intrin.h
index db4d7cd..0b2343f 100644
--- a/mingw-w64-headers/crt/intrin.h
+++ b/mingw-w64-headers/crt/intrin.h
@@ -72,6 +72,10 @@ extern C {
 
 #include x86intrin.h
 
+/* Before 4.9.2, x86intrin.h had broken versions of these. */
+#undef _lrotl
+#undef _lrotr
+
 #if defined(__cplusplus)
 }
 #endif
@@ -430,19 +434,8 @@ extern C {
 __MACHINEIA64(__MINGW_EXTENSION __int64 __load128_acq(void *,__int64 *))
 __MACHINEZ(void __cdecl longjmp(jmp_buf,int))
 
-#pragma push_macro (_lrotl)
-#undef _lrotl
-#pragma push_macro (_lrotr)
-#undef _lrotr
-#ifdef __x86_64__
-__MACHINE(__MINGW_EXTENSION unsigned long long __cdecl _lrotl(unsigned long long,int))
-__MACHINE(__MINGW_EXTENSION unsigned long long __cdecl _lrotr(unsigned long long,int))
-#else
-__MACHINE(unsigned __LONG32 __cdecl _lrotl(unsigned __LONG32,int))
-__MACHINE(unsigned __LONG32 __cdecl _lrotr(unsigned __LONG32,int))
-#endif
-#pragma pop_macro (_lrotl)
-#pragma pop_macro (_lrotr)
+/* __MACHINE(unsigned long __cdecl _lrotl(unsigned long,int)) moved to psdk_inc/intrin-impl.h */
+/* __MACHINE(unsigned long __cdecl _lrotr(unsigned long,int)) moved to psdk_inc/intrin-impl.h */
 
 __MACHINEI(__MINGW_EXTENSION unsigned __int64 __ll_lshift(unsigned __int64,int))
 __MACHINEI(__MINGW_EXTENSION __int64 __ll_rshift(__int64,int))
diff --git a/mingw-w64-headers/crt/stdlib.h b/mingw-w64-headers/crt/stdlib.h
index 492f2dd..dfc5ae4 100644
--- a/mingw-w64-headers/crt/stdlib.h
+++ b/mingw-w64-headers/crt/stdlib.h
@@ -536,19 +536,27 @@ float __cdecl __MINGW_NOTHROW strtof(const char * __restrict__ _Str,char ** __re
   _CRTIMP int __cdecl _atodbl_l(_CRT_DOUBLE *_Result,char *_Str,_locale_t _Locale);
   _CRTIMP int __cdecl _atoldbl_l(_LDOUBLE *_Result,char *_Str,_locale_t _Locale);
   _CRTIMP int __cdecl _atoflt_l(_CRT_FLOAT *_Result,char *_Str,_locale_t _Locale);
-#pragma push_macro (_lrotr)
-#pragma push_macro (_lrotl)
+
+#if defined(__INTRIN_H_) || \
+   (defined(_X86INTRIN_H_INCLUDED)  \
+ ((__MINGW_GCC_VERSION = 40902) || defined(__LP64__) || defined(_X86_)))
+
+/* We already have bug-free prototypes and inline definitions for _lrotl
+   and _lrotr from either intrin.h or x86intrin.h. */
+
+#else
+
+/* Remove buggy x86intrin.h definitions if present (see gcc bug 61662). */
 #undef _lrotr
 #undef _lrotl
-#ifdef __x86_64__
-  __MINGW_EXTENSION unsigned long long __cdecl _lrotl(unsigned long long _Val,int _Shift);
-  __MINGW_EXTENSION unsigned long long __cdecl _lrotr(unsigned long long _Val,int _Shift);
-#else
-  unsigned long __cdecl _lrotl(unsigned long _Val,int _Shift);
-  unsigned long __cdecl _lrotr(unsigned long _Val,int _Shift);
-#endif
-#pragma pop_macro (_lrotl)
-#pragma pop_macro (_lrotr)
+
+/* These prototypes work for x86, x64 (native Windows), and cyginwin64. */
+unsigned long __cdecl _lrotl(unsigned long,int);
+unsigned long __cdecl _lrotr(unsigned long,int);
+
+#endif /* defined(__INTRIN_H_) || \
+(defined(_X86INTRIN_H_INCLUDED)  \
+   ((__MINGW_GCC_VERSION = 40902) || defined(__LP64__))) */
 
   _CRTIMP void __cdecl _makepath(char *_Path,const char *_Drive,const char *_Dir,const char *_Filename,const char *_Ext);
   _onexit_t __cdecl _onexit(_onexit_t _Func);
diff --git a/mingw-w64-headers/include/psdk_inc/intrin-impl.h b/mingw-w64-headers/include/psdk_inc/intrin-impl.h
index 71d6096..fd7d38a 100644
--- a/mingw-w64-headers/include/psdk_inc/intrin-impl.h
+++ b/mingw-w64-headers/include/psdk_inc/intrin-impl.h
@@ -509,6 +509,30 @@ supports ReadWriteBarrier, map all 3 to do the same. */
 extern C {
 #endif
 
+/* Before 4.9.2, ia32intrin.h had broken versions of these. */
+#undef _lrotl
+#undef _lrotr
+
+#if __INTRINSIC_PROLOG(_lrotl

Re: [Mingw-w64-public] MinGW-W64 and patching a program

2015-02-09 Thread dw

Is being alive a requirement here?

I would guess that this is due, at least in part, to 
__pei386_runtime_relocator().  There's some discussion of this here:

https://sourceforge.net/p/mingw-w64/mailman/message/32721440/

The fact that it has to change the protection on the program's memory 
regions so it can write to them suggests this may be what you are 
looking for.

dw

On 2/9/2015 11:06 PM, niXman wrote:
 niXman 2015-02-09 15:15:
 Hi,

 I use VMProtect[1] in a project that I build using MinGW-W64.
 VMProtect, among other things, provides the 'bool
 VMProtectIsValidImageCRC()' function which determines whether the
 program image has been patched in the memory.
 The problem is that this function always returns 'false', as if the
 program image has been patched.
 I have addressed to the VMProtect support service, and we was told that
 the problem is that MinGW-W64 itself patches the program image[2](in
 russian), and I want to know:
 1)is this true?
 2)what does MinGW-W64 do this for?
 3)is it possible to do something in the effect that MinGW not doing
 this?


 Thanks.

 [1] http://www.vmpsoft.com/
 [2] http://www.vmpsoft.com/forum/viewtopic.php?f=2t=1253
 ping? Is there anyone alive? ;)


 --
 Dive into the World of Parallel Programming. The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net/
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] cygwin and mingw-w64

2015-02-05 Thread dw

I'm not sure if this is a cygwin question or a mingw-w64 question.

I'm working on fixing the _lrotl stuff.  The changes for intrin.h and 
intrin-impl.h were easy.  But for whatever reason, MS duplicates the 
prototypes for this function in stdlib.h.  I have started to update 
mingw-w64's stdlib.h, but I'm having problems testing one of the 
permutations.  Specifically, the case where longs are 8 bytes.

I'm using cygwin64 to try to test this.  However, my attempts to build 
this either result in 4 byte longs, or in NOT using the mingw-w64 stdlib.h.

I am no cygwin expert, so I guess my first question is: Is there 
actually a plausible case where this can ever happen (8 byte longs + 
mingw-w64's stdlib.h)?

While I suppose that instead of just using #include stdlib.h, I 
*could* hard code a path to bypass the cygwin's stdlib.h and go straight 
to mingw-w64's, but does that make any sense at all?

If mingw-w64's stdlib.h doesn't need to support 8 byte longs, this patch 
gets much easier.  But if it does, what's the approach to test it?

dw

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] How to recognize symlinks in WIN32?

2015-01-14 Thread dw


I'm not quite sure what you are looking for.  However, maybe this will help:

I created an NTFS symbolic file link with (data.raw is just a normal file):

   mklink c:\idelme\data2.raw c:\idelme\data.raw

From there, I was able to see that it was a symbolic link with:

#include windows.h
#include stdio.h

void TestMe(const char *name)
{
   printf(name: %s\n, name);
   DWORD d = GetFileAttributes(name);
   printf(%x %d\n, d, d  FILE_ATTRIBUTE_REPARSE_POINT);

   WIN32_FIND_DATA ffd;
   HANDLE h = FindFirstFile(name, ffd);

   printf(%x\n\n, ffd.dwReserved0);
   CloseHandle(h);
}

int main()
{
   TestMe(C:\\idelme\\data.raw);
   TestMe(C:\\idelme\\data2.raw);
}

Data.raw does not have the FILE_ATTRIBUTE_REPARSE_POINT attribute set.  
Similarly, ffd.dwReserved0 is 0.
Data2.raw DOES have the FILE_ATTRIBUTE_REPARSE_POINT attribute.  And 
ffd.dwReserved0 shows IO_REPARSE_TAG_SYMLINK.


FWIW.

dw

On 1/14/2015 9:33 AM, Greg Jung wrote:

Hi Folks,
  I've been trying to program a recognition of NTFS symbolic link 
files;  What I;ve gleaned

from MSDN procedures don't seem to work.  Below are coded three methods

1) (untested) open file and call GetFileInformationByHandleEx.  I 
can't get winbase.h header definitions recognized
 2) GetFileAttributes() works ok for Junctions doesn't recognize 
symlink files

 3) FindFirstEx . same result as 2)

There must be a way, since cygwin 'ls -a' and msys2 'ls -a'  commands 
will show links.


 in the calling routine, I modify result of stat() with system calls:
#ifdef _WIN32
int addlink = 0;
fstat_win32(filename.c_str(), addlink);
int actStat = stat(filename.c_str(), statStruct);
if( addlink != 0) cout   addlink came back   endl;
statStruct.st_mode |= addlink;
#else
int actStat = lstat( testDir.c_str(), statStruct);
#endif

where fstat_win32 now has a graveyard full of attempts: ( When a 
directory link is encountered, however, the test succeeeds.)


  void fstat_win32(const string filepath, int st_mode)
{
DWORD dwattrib, reparsetag;
DString st;
st=filepath;
#if 1
//
//  This method has not been tested: it will not compile - 
GetFileInformationByHandleEx

//  does not get through from the winbase.h header
//
HANDLEhFile;
BOOL success;
DWORD fattrib[2];
hFile = CreateFile( (TCHAR *)st.c_str(),
FILE_GENERIC_READ,
FILE_SHARE_READ | FILE_SHARE_WRITE,
0,
OPEN_EXISTING,
FILE_FLAG_OPEN_REPARSE_POINT,
  0);
if (hFile == INVALID_HANDLE_VALUE) {
CloseHandle(hFile);
cout   stat_win32: could not open  + st  endl;
return;
   }
else {
success = GetFileInformationByHandleEx(hFile,
 FileAttributeTagInfo,
 fattrib,
 sizeof(fattrib));
dwattrib = fattrib[0];
reparsetag = fattrib[1];
}
CloseHandle(hFile);

//dwattrib = GetFileAttributes( (TCHAR *)st.c_str()); // This 
doesn't work to find symlinks

if( (dwattrib  FILE_ATTRIBUTE_REPARSE_POINT) != 0 )  {
st_mode |= S_IFLNK;
cout   fstat_win32: symbolic link detected and flagged!!  
 filepath ;

}
 else st_mode=0;
#elif 0
DWORD dwlen;
HANDLEhFind;
BOOLfoundnext;
WIN32_FIND_DATA FindFileData;
// This doesn't work to find symlinks
hFind = FindFirstFileEx( (TCHAR *) st.c_str(),
 FindExInfoStandard,
 FindFileData,
 FindExSearchNameMatch, NULL, 0);
if (hFind == INVALID_HANDLE_VALUE)
return;
dwattrib = FindFileData.dwFileAttributes;
if( (dwattrib  FILE_ATTRIBUTE_REPARSE_POINT) != 0 )  {
st_mode |= S_IFLNK;
cout   fstat_win32: symbolic link detected and flagged!!  
 filepath ;

dwattrib = FindFileData.dwReserved0;
// IO_REPARSE_TAG_SYMLINK _MOUNT_POINT etc.
}
   FindClose(hFind);
#endif
return;
}



--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] adding dos stub program with ld to PE binary

2014-12-07 Thread dw


Maybe something like this (attached)?

This program opens up an exe and re-writes the stub.  The resulting code 
will launch .\16.exe (IOW a file named 16.exe in the current 
directory) when run as 16 bit.  It's got commenting and error checking.


It's not exactly what you were asking for, but perhaps it can give you 
what you need?


dw

On 12/5/2014 2:26 PM, bulk 88 wrote:

 Date: Fri, 5 Dec 2014 09:49:55 +0100
 From: ktiet...@googlemail.com
 To: mingw-w64-public@lists.sourceforge.net
 Subject: Re: [Mingw-w64-public] adding dos stub program with ld to 
PE binary


 2014-12-05 6:45 GMT+01:00 bulk88 bul...@hotmail.com:
  What is the GCC ld equivalent of Visual C's -stub ?
  http://msdn.microsoft.com/en-us/library/7z0585h5.aspx I need to 
add a MZ

  header-ed dos program to my PE binary instead of the default This
  program cannot be run in DOS mode program.
 

 Hmm, interesting option. AFAI know does ld do not provide such
 feature. It wouldn't be too hard to implement it.
 So sorry, for now this feature isn't present.

 Kai

I found the default dos header lives in 
_bfd_XXi_only_swap_filehdr_out() but that code is beyond what I can do.


// dos2.cpp : Re-writes stub in executable

#include stdio.h

#define BYTESINPARAGRAPH 16

typedef unsigned short WORD;
typedef long LONG;

typedef struct _IMAGE_DOS_HEADER {
WORD   e_magic;
WORD   e_cblp;
WORD   e_cp;
WORD   e_crlc;
WORD   e_cparhdr;
WORD   e_minalloc;
WORD   e_maxalloc;
WORD   e_ss;
WORD   e_sp;
WORD   e_csum;
WORD   e_ip;
WORD   e_cs;
WORD   e_lfarlc;
WORD   e_ovno;
WORD   e_res[4];
WORD   e_oemid;
WORD   e_oeminfo;
WORD   e_res2[10];
LONG   e_lfanew;
  } IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;

/* Here's the code that's (currently) in newcode:

; Adjust the program size to 20 paragraphs
mov bx,20
mov ah,4a
int 21

; Set ds and es to cs
push cs
pop ds
push cs
pop es

; Exe name is at DS:DX
; Parameter block is at ES:BX
mov ax,4b00
mov bx,1a
mov dx,28
int 21

; Exit using return code from EXEC as exit code
mov ah, 4c
int 21

; Followed by 14 0 bytes for the parameter block
; and the asciiz file name (.\16.exe) to run.

*/

const unsigned char newcode[] = {
0xBB, 0x20, 0x00, 0xB4, 0x4A, 0xCD, 0x21, 0x0E, 
0x1F, 0x0E, 0x07, 0xB8, 0x00, 0x4B, 0xBB, 0x1A, 
0x00, 0xBA, 0x28, 0x00, 0xCD, 0x21, 0xB4, 0x4C, 
0xCD, 0x21, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
'.', '\\', '1', '6', '.', 'e', 'x', 'e', 0x00};

int main(int argc, char *argv[])
{
if (sizeof(newcode)  64)
{
printf(new code block is too big.\n);
return 1;
}

if (argc != 2)
{
printf(Usage: dos2 filename\n\nRe-writes stub in executable.\n);
return 1;
}

FILE *f = fopen(argv[1], r+);
if (f == NULL)
{
printf(Can't open %S.\n, argv[1]);
return 1;
}

IMAGE_DOS_HEADER dh;
size_t bytesread = fread(dh, 1, sizeof(dh), f);

if (bytesread  sizeof(dh))
{
printf(Only read %d bytes instead of %d.\n, bytesread, sizeof(dh));
fclose(f);
return 1;
}

if (dh.e_magic != 0x5A4D) // MZ
{
printf(Missing MZ signature.\n);
fclose(f);
return 1;
}

if (dh.e_cparhdr  4)
{
printf(Header not big enough to be PE.\n);
fclose(f);
return 1;
}

if (dh.e_lfanew == 0)
{
printf(No new exe header.\n);
fclose(f);
return 1;
}

int seekres = fseek(f, dh.e_cparhdr * BYTESINPARAGRAPH, SEEK_SET);

if (seekres != 0)
{
printf(Can't seek to offset %d.\n, dh.e_cparhdr * BYTESINPARAGRAPH);
fclose(f);
return 1;
}

int writeres = fwrite(newcode, 1, sizeof(newcode), f);

if (writeres != sizeof(newcode))
{
printf(Only wrote %d bytes instead of %d.\n, writeres, 
sizeof(newcode));
fclose(f);
return 1;
}

fclose(f);
printf(Operation succeeded!\n);

return 0;
}
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] adding dos stub program with ld to PE binary

2014-12-06 Thread dw

I have seen code that adds or removes sections from PE files after they 
are created, but it's non-trivial.  Apparently offsets in the PE file 
are all absolute (rather than relative to the section), so adding more 
code at the beginning of the file mucks everything up.


Can you cheat a bit?  How about leaving your proposed stub as a 
separate exe? Then open your 32bit exe and overwrite 64 bytes of stub 
the ld creates with something that launches your stub program? Some 
variation of:


push cs
pop ds ; Used with DX for asciiz file name
push cs
pop es ; Used with BX for Launch
mov ax, 0x4b00 ; Function code for DOS Exec
mov dx,?? ; offset from 0x40 of asciiz file name
mov bx, 0x40 ; location to put psp
int 21 ; Launch exe
mov ah, 0x4c ; Function code for Exit to DOS
; Leave al return code from Launch unchanged
int 21 ; Exit to DOS
16.exe\0

I believe that even including the file name, that's less than 30 bytes.  
Room to spare.  So now when my32bitapp.exe is run, it turns around and 
launches 16.exe.  Tada!


dw

On 12/5/2014 2:26 PM, bulk 88 wrote:



 Date: Fri, 5 Dec 2014 09:49:55 +0100
 From: ktiet...@googlemail.com
 To: mingw-w64-public@lists.sourceforge.net
 Subject: Re: [Mingw-w64-public] adding dos stub program with ld to 
PE binary


 2014-12-05 6:45 GMT+01:00 bulk88 bul...@hotmail.com:
  What is the GCC ld equivalent of Visual C's -stub ?
  http://msdn.microsoft.com/en-us/library/7z0585h5.aspx I need to 
add a MZ

  header-ed dos program to my PE binary instead of the default This
  program cannot be run in DOS mode program.
 

 Hmm, interesting option. AFAI know does ld do not provide such
 feature. It wouldn't be too hard to implement it.
 So sorry, for now this feature isn't present.

 Kai

I found the default dos header lives in 
_bfd_XXi_only_swap_filehdr_out() but that code is beyond what I can do.



--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fw: Re: Re: Potential memory leaks in exception handling?

2014-11-01 Thread dw

Thank you for checking this.

If I read this right, the leaking that was coming from the exceptions 
during static linking was eliminated using this patch. That seems like a 
good thing.

There are 2 leaks left, but they are always leaking.  I know one of them 
is argv[0] (the currently running program).  Probably makes sense to 
leave this alone.  Not sure what the 16byte thing is, but it doesn't 
seem to be cumulative, so I'm not much motivated to seek it out.

dw

On 10/31/2014 11:27 PM, lh_mouse wrote:
 I have applied the patch and here are test results:

 /// using original mingw-w64 shared libs - 2 leaked 
 ///
 E:\Desktopg++ test.cpp -std=c++11

 E:\Desktopa
 ++exception caught, e = 12345

 /// using original mingw-w64 static libs - a number 
 leaked ///
 E:\Desktopg++ test.cpp -std=c++11 -static

 E:\Desktopa
 --exception caught, e = 12345
 

 /// using patched mingw-w64 shared libs - 2 leaked 
 ///
 E:\Desktopg++ test.cpp -nodefaultlibs -L E:\Desktop\temp\lib32 -std=c++11 
 -lstdc++ -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32 
 -lshell32 -luser32 -lkernel32 -liconv -lmingw32 -lgcc_s -lgcc -lmoldname 
 -lmingwex -lmsvcrt

 E:\Desktopa
 ++exception caught, e = 12345

 /// using original mingw-w64 static libs - 2 leaked 
 ///
 E:\Desktopg++ test.cpp -nodefaultlibs -L E:\Desktop\temp\lib32 -std=c++11 
 -lstdc++ -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32 
 -lshell32 -luser32 -lkernel32 -liconv -lmingw32 -lgcc -lgcc_eh -lmoldname 
 -lmingwex -lmsvcrt -static

 E:\Desktopa
 exception caught, e = 12345
 --

 (Stud PE reported no malloc() or free() was imported from msvcrt.dll.)

 --
 Best regards,
 lh_mouse
 2014-11-01

 -
 发件人：dw limegreenso...@yahoo.com
 发送日期：2014-11-01 11:18
 收件人：mingw-w64-public,lh_mouse
 抄送：
 主题：Re: [Mingw-w64-public] Potential memory leaks in exception handling?


 AFAIK mingw-w64 uses callbacks to reclaim TLS memory. In the first
 case, upon destruction of the static object there were 5 blocks of
 memory unfreed; and in the second case there were 6. If we say there
 was no memory leak in case 1, then there must be in case 2, IMO.
 I've tried this myself, and I think I'm seeing what you are seeing. It
 looks to me like the problem comes from ___w64_mingwthr_add_key_dtor
 in tlsthrd.c.  In this routine, calloc is called to create a
 __mingwthr_key_t.  However, I don't believe that memory ever gets freed.

 In theory it could get freed in ___w64_mingwthr_remove_key_dtor (at
 least there is a free for it there), but apparently that routine never
 gets called.

 Maybe it was supposed to be freed in __mingwthr_run_key_dtors when it
 gets called?
 So, I believe I have the patch for this (attached).  lh_mouse, can you
 confirm?

 Note that the way you were checking your code (test2.cpp) is flawed,
 since some of the frees occur after the destructor of your counter. As
 an alternative, try adding putchar('+') in malloc and putchar('-') in
 free, and count the pluses and minuses in the output.

 Turns out it's not much of a leak, and the memory can't be freed until
 application shutdown (or possibly at dll unload time) since it is used
 right up until the last minute.

 dw




 --
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Potential memory leaks in exception handling?

2014-10-31 Thread dw



AFAIK mingw-w64 uses callbacks to reclaim TLS memory. In the first 
case, upon destruction of the static object there were 5 blocks of 
memory unfreed; and in the second case there were 6. If we say there 
was no memory leak in case 1, then there must be in case 2, IMO.


I've tried this myself, and I think I'm seeing what you are seeing. It 
looks to me like the problem comes from ___w64_mingwthr_add_key_dtor 
in tlsthrd.c.  In this routine, calloc is called to create a 
__mingwthr_key_t.  However, I don't believe that memory ever gets freed.


In theory it could get freed in ___w64_mingwthr_remove_key_dtor (at 
least there is a free for it there), but apparently that routine never 
gets called.


Maybe it was supposed to be freed in __mingwthr_run_key_dtors when it 
gets called?


So, I believe I have the patch for this (attached).  lh_mouse, can you 
confirm?


Note that the way you were checking your code (test2.cpp) is flawed, 
since some of the frees occur after the destructor of your counter. As 
an alternative, try adding putchar('+') in malloc and putchar('-') in 
free, and count the pluses and minuses in the output.


Turns out it's not much of a leak, and the memory can't be freed until 
application shutdown (or possibly at dll unload time) since it is used 
right up until the last minute.


dw
From e9adda2479244cbf3681c379b2573362eace6308 Mon Sep 17 00:00:00 2001
From: David Wohlferd d...@limegreensocks.com
Date: Fri, 31 Oct 2014 20:00:04 -0700
Subject: [PATCH] Fix memory leak.

Signed-off-by: David Wohlferd d...@limegreensocks.com
---
 mingw-w64-crt/crt/tlsthrd.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/mingw-w64-crt/crt/tlsthrd.c b/mingw-w64-crt/crt/tlsthrd.c
index 5d858a6..c367ca1 100644
--- a/mingw-w64-crt/crt/tlsthrd.c
+++ b/mingw-w64-crt/crt/tlsthrd.c
@@ -133,6 +133,14 @@ __mingw_TLScallback (HANDLE __UNUSED_PARAM(hDllHandle),
   __mingwthr_run_key_dtors();
   if (__mingwthr_cs_init == 1)
 {
+  __mingwthr_key_t volatile *keyp, *t;
+  for (keyp = key_dtor_list; keyp; )
+  {
+t = keyp-next;
+free((void *)keyp);
+keyp = t;
+  }
+  key_dtor_list = NULL;
   __mingwthr_cs_init = 0;
   DeleteCriticalSection (__mingwthr_cs);
 }
-- 
1.9.4.msysgit.0

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Slow pseudo-relocations

2014-10-24 Thread dw


 Ups, that was unintended to send an empty mail :)

I did wonder.  I assumed it was just a ping.

 So, here is a patch.

Your patch does not look right.  You have added the new checks using ||?

 It would be great if somebody could verify that the reported
 issue is solved by it.

Yes, this is the hard part.  Vadim seems to be able to produce this with 
no problem, but I'm having no luck getting it to happen at all.

BTW, what is __MINGW64_VERSION_MAJOR for?  Is there a time when it might 
not be defined in pseudo-reloc?  If it is defined, we end up checking 
the page attributes twice.

FWIW, my patch (which I haven't been able to test either) looks like 
this (removes the duplicate check):

--- mingw-w64-crt/crt/pseudo-reloc.c 
---
index 4e7f31b..7709208 100644
@@ -206,7 +206,8 @@ mark_section_writable (LPVOID addr)
return;
  }

-  if (b.Protect != PAGE_EXECUTE_READWRITE  b.Protect != PAGE_READWRITE)
+  if (b.Protect != PAGE_EXECUTE_READWRITE  b.Protect != PAGE_READWRITE
+   b.Protect != PAGE_EXECUTE_WRITECOPY  b.Protect != 
PAGE_WRITECOPY)
  {
if (!VirtualProtect (b.BaseAddress, b.RegionSize,
 PAGE_EXECUTE_READWRITE,
@@ -259,16 +260,17 @@ restore_modified_sections (void)
  static void
  __write_memory (void *addr, const void *src, size_t len)
  {
-  MEMORY_BASIC_INFORMATION b;
-  DWORD oldprot;
-  int call_unprotect = 0;
-
if (!len)
  return;

  #ifdef __MINGW64_VERSION_MAJOR
+  /* Mark the section writable once, and unset it in
+   * restore_modified_sections */
mark_section_writable ((LPVOID) addr);
-#endif
+#else
+  MEMORY_BASIC_INFORMATION b;
+  DWORD oldprot = 0;
+  int call_unprotect = 0;

if (!VirtualQuery (addr, b, sizeof(b)))
  {
@@ -277,18 +279,25 @@ __write_memory (void *addr, const void *src, 
size_t len)
  }

/* Temporarily allow write access to read-only protected memory. */
-  if (b.Protect != PAGE_EXECUTE_READWRITE  b.Protect != PAGE_READWRITE)
+  if (b.Protect != PAGE_EXECUTE_READWRITE  b.Protect != PAGE_READWRITE
+   b.Protect != PAGE_WRITECOPY  b.Protect != 
PAGE_EXECUTE_WRITECOPY)
  {
call_unprotect = 1;
VirtualProtect (b.BaseAddress, b.RegionSize, PAGE_EXECUTE_READWRITE,
oldprot);
  }
+#endif

/* write the data. */
memcpy (addr, src, len);
+
+#ifndef __MINGW64_VERSION_MAJOR
/* Restore original protection. */
-  if (call_unprotect  b.Protect != PAGE_EXECUTE_READWRITE  
b.Protect != PAGE_READWRITE)
+  if (call_unprotect
+   b.Protect != PAGE_EXECUTE_READWRITE  b.Protect != PAGE_READWRITE
+   b.Protect != PAGE_WRITECOPY  b.Protect != 
PAGE_EXECUTE_WRITECOPY)
  VirtualProtect (b.BaseAddress, b.RegionSize, oldprot, oldprot);
+#endif
  }

  #define RP_VERSION_V1 0

--



--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Slow pseudo-relocations

2014-10-14 Thread dw

I have created a fix for this, but I'm having trouble testing it.  My 
relocations always end up on pages marked PAGE_EXECUTE_READ.  To see 
Vadim's problem, I need PAGE_EXECUTE_WRITECOPY.


Vadim, can you provide any more context here?  OS (W7? W8?), 32bit?  
64bit?  Using LoadLibrary? LoadLibraryEx?  Are the exported symbols 
marked in any particular way (dllexport? __attribute__?)?  Maybe you use 
a special linker script to combine sections?  Any chance of a code 
sample showing the problem?


Anyone who knows something about how page protections are assigned or 
how relocs might end up in different sections, please feel free to 
enlighten me.


dw

On 8/19/2014 1:02 PM, Vadim Chugunov wrote:
No, sorry, I don't have the setup to build mingw.  Not likely that I 
will have time to do it any time soon either.
I meant this as a bug report.  I hope the problem has been 
investigated sufficiently for mingw devs to act on it.


Vadim


On Mon, Aug 18, 2014 at 9:34 PM, dw limegreenso...@yahoo.com 
mailto:limegreenso...@yahoo.com wrote:


Did you ever get this sorted out?

dw


On 8/15/2014 10:53 PM, dw wrote:

So, it looks like what has happened is that newer OSs (ie =
Vista) set the page protect to PAGE_EXECUTE_WRITECOPY when doing
a LoadLibrary.  This is a (relatively) new flag and apparently
Mingw still assumes the old values are always in use.

There are 3 places in pseudo-reloc.c that do comparisons of
b.Protect to PAGE_EXECUTE_READWRITE.  I believe all three should
also check for PAGE_EXECUTE_WRITECOPY.

It also looks like a minor perf improvement in __write_memory is
possible by adding an #else for that VirtualQuery /
VirtualProtect stuff:

static void
__write_memory (void *addr, const void *src, size_t len)
{
  if (!len)
return;

#ifdef __MINGW64_VERSION_MAJOR

  /* Mark the section writable once, and unset it in
   * restore_modified_sections. */
  mark_section_writable ((LPVOID) addr);

#else/* __MINGW64_VERSION_MAJOR */

  MEMORY_BASIC_INFORMATION b;
  DWORD oldprot = 0;
  int call_unprotect = 0;

  if (!VirtualQuery (addr, b, sizeof(b)))
{
  __report_error (  VirtualQuery failed for %d bytes at
address %p,
  (int) sizeof(b), addr);
}

  /* Temporarily allow write access to read-only protected
memory.  */
  if (b.Protect != PAGE_EXECUTE_READWRITE  b.Protect !=
PAGE_READWRITE  b.Protect != PAGE_EXECUTE_WRITECOPY)
{
  call_unprotect = 1;
  VirtualProtect (b.BaseAddress, b.RegionSize,
PAGE_EXECUTE_READWRITE,
  oldprot);
}

#endif /* __MINGW64_VERSION_MAJOR */

  /* write the data. */
  memcpy (addr, src, len);

#ifndef __MINGW64_VERSION_MAJOR

  /* Restore original protection. */
  if (call_unprotect  b.Protect != PAGE_EXECUTE_READWRITE 
b.Protect != PAGE_READWRITE  b.Protect != PAGE_EXECUTE_WRITECOPY)
VirtualProtect (b.BaseAddress, b.RegionSize, oldprot, oldprot);

#endif /* __MINGW64_VERSION_MAJOR */
}

If setting the protection in mark_section_writable was
unsuccessful (unlikely as that is), trying to set it again here
is not likely to help.

NB: I haven't tried this, but you have the setup to test it
anyway.  Also, this code snippet only fixes 2 of the 3 places
that use PAGE_EXECUTE_WRITECOPY.  Remember to change the
comparison in mark_section_writable() as well.

FWIW,
dw

On 8/15/2014 8:17 PM, Vadim Chugunov wrote:

Okay, I was wrong about __MINGW64_VERSION_MAJOR: it *was* defined.

What apparently happens is that the VirtualQuery() call that
follows mark_section_writable(), returns page protection status
of 0x80 (PAGE_EXECUTE_WRITECOPY), which is unexpected by the
relocator code, so it falls back to calling VirtualProtect() per
relocation entry.

I am not entirely sure how this situation comes about, but here
you go...

On Fri, Aug 15, 2014 at 1:01 AM, Vadim Chugunov
vadi...@gmail.com mailto:vadi...@gmail.com wrote:

Hi,
I am trying to figure out the cause of a slow application
startup, and the evidence I have so far, points to mingw's
_pei386_runtime_relocator() routine as the culprit.   When I
start my app under debugger, I see this function calling
VirtualProtect() about a zillion times in a row.

Looking at the source, I see that
__pei386_runtime_relocator() is supposed to change memory
protection just once per executable section, but only if
__MINGW64_VERSION_MAJOR is defined at compilation time.
Otherwise,  it reverts to changing protection once per
relocation entry, for compatibility (?).
Unfortunately, I don't see any headers included by
pseudo-reloc.c that would define this symbol.  And, indeed,
the behavior I am seeing

Re: [Mingw-w64-public] [PATCH] stdio/math: Various implementations and more for ARM (v2)

2014-09-21 Thread dw


On 9/20/2014 8:07 AM, André Hentschel wrote:
 Am 19.09.2014 um 17:30 schrieb Kai Tietz:
 2014-09-19 1:34 GMT+02:00 dw limegreenso...@yahoo.com:
 For the parts that are working around a compiler bug:

 - Does it make sense to list the bug number in the comment?
 I think it makes sense in general.  Only important thing should be to
 mark bug-number, that it belongs to SF bug-tracker.  We might want to
 change in future bug-tracker and so we would loose relation.

 - If the bug has been fixed, what about using __GNUC__ and __GNUC_MINOR__ to
 limit the code?
 Well, depends on the nature of code.  If it is a general bug-fix, then
 I don't see the need for __GNUC__/__GNUC_MINOR__ guarding (btw we have
 in _mingw.h some helper-macros for checking easier gcc-version).
 For compiler-specific bugs, it makes sense.  Only questional point
 here is how we treat reviews for new-compilers, as the reason for
 compiler-related bug-fixes might be resolved in future version.

 dw
 Kai
 I guess the problem might be related to the early state of changes to gcc for 
 armv7-pe support, so i don't see a point in reporting a bug

I'm just envisioning someone looking at this code many years from now 
trying to figure out why it is there and whether it is still needed.  A 
bug number is a simple way to convey this information, but there are others.

dw

--
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Slow pseudo-relocations

2014-08-20 Thread dw

Well, I've done what I can to diagnose this.  It's up to the mingw devs 
from here.


dw

On 8/19/2014 1:04 PM, Vadim Chugunov wrote:
No, sorry, I don't have the setup to build mingw. Not likely that I 
will have time to do it any time soon either.
I meant this as a bug report.  I hope the problem has been 
investigated sufficiently for mingw devs to act on it.


Vadim



On Mon, Aug 18, 2014 at 9:34 PM, dw limegreenso...@yahoo.com 
mailto:limegreenso...@yahoo.com wrote:


Did you ever get this sorted out?

dw


On 8/15/2014 10:53 PM, dw wrote:

So, it looks like what has happened is that newer OSs (ie =
Vista) set the page protect to PAGE_EXECUTE_WRITECOPY when doing
a LoadLibrary.  This is a (relatively) new flag and apparently
Mingw still assumes the old values are always in use.

There are 3 places in pseudo-reloc.c that do comparisons of
b.Protect to PAGE_EXECUTE_READWRITE.  I believe all three should
also check for PAGE_EXECUTE_WRITECOPY.

It also looks like a minor perf improvement in __write_memory is
possible by adding an #else for that VirtualQuery /
VirtualProtect stuff:

static void
__write_memory (void *addr, const void *src, size_t len)
{
  if (!len)
return;

#ifdef __MINGW64_VERSION_MAJOR

  /* Mark the section writable once, and unset it in
   * restore_modified_sections. */
  mark_section_writable ((LPVOID) addr);

#else/* __MINGW64_VERSION_MAJOR */

  MEMORY_BASIC_INFORMATION b;
  DWORD oldprot = 0;
  int call_unprotect = 0;

  if (!VirtualQuery (addr, b, sizeof(b)))
{
  __report_error ( VirtualQuery failed for %d bytes at
address %p,
  (int) sizeof(b), addr);
}

  /* Temporarily allow write access to read-only protected memory. */
  if (b.Protect != PAGE_EXECUTE_READWRITE  b.Protect !=
PAGE_READWRITE  b.Protect != PAGE_EXECUTE_WRITECOPY)
{
  call_unprotect = 1;
  VirtualProtect (b.BaseAddress, b.RegionSize,
PAGE_EXECUTE_READWRITE,
  oldprot);
}

#endif /* __MINGW64_VERSION_MAJOR */

  /* write the data. */
  memcpy (addr, src, len);

#ifndef __MINGW64_VERSION_MAJOR

  /* Restore original protection. */
  if (call_unprotect  b.Protect != PAGE_EXECUTE_READWRITE 
b.Protect != PAGE_READWRITE  b.Protect != PAGE_EXECUTE_WRITECOPY)
VirtualProtect (b.BaseAddress, b.RegionSize, oldprot, oldprot);

#endif /* __MINGW64_VERSION_MAJOR */
}

If setting the protection in mark_section_writable was
unsuccessful (unlikely as that is), trying to set it again here
is not likely to help.

NB: I haven't tried this, but you have the setup to test it
anyway.  Also, this code snippet only fixes 2 of the 3 places
that use PAGE_EXECUTE_WRITECOPY.  Remember to change the
comparison in mark_section_writable() as well.

FWIW,
dw

On 8/15/2014 8:17 PM, Vadim Chugunov wrote:

Okay, I was wrong about __MINGW64_VERSION_MAJOR: it *was* defined.

What apparently happens is that the VirtualQuery() call that
follows mark_section_writable(), returns page protection status
of 0x80 (PAGE_EXECUTE_WRITECOPY), which is unexpected by the
relocator code, so it falls back to calling VirtualProtect() per
relocation entry.

I am not entirely sure how this situation comes about, but here
you go...

On Fri, Aug 15, 2014 at 1:01 AM, Vadim Chugunov
vadi...@gmail.com mailto:vadi...@gmail.com wrote:

Hi,
I am trying to figure out the cause of a slow application
startup, and the evidence I have so far, points to mingw's
_pei386_runtime_relocator() routine as the culprit.   When I
start my app under debugger, I see this function calling
VirtualProtect() about a zillion times in a row.

Looking at the source, I see that
__pei386_runtime_relocator() is supposed to change memory
protection just once per executable section, but only if
__MINGW64_VERSION_MAJOR is defined at compilation time.
Otherwise,  it reverts to changing protection once per
relocation entry, for compatibility (?).
Unfortunately, I don't see any headers included by
pseudo-reloc.c that would define this symbol.  And, indeed,
the behavior I am seeing at runtime indicates that if was
not defined...

Am I reading this right?

Thanks!
Vadim







--


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org

Re: [Mingw-w64-public] Slow pseudo-relocations

2014-08-15 Thread dw

So, it looks like what has happened is that newer OSs (ie = Vista) set 
the page protect to PAGE_EXECUTE_WRITECOPY when doing a LoadLibrary.  
This is a (relatively) new flag and apparently Mingw still assumes the 
old values are always in use.


There are 3 places in pseudo-reloc.c that do comparisons of b.Protect to 
PAGE_EXECUTE_READWRITE.  I believe all three should also check for 
PAGE_EXECUTE_WRITECOPY.


It also looks like a minor perf improvement in __write_memory is 
possible by adding an #else for that VirtualQuery / VirtualProtect stuff:


static void
__write_memory (void *addr, const void *src, size_t len)
{
  if (!len)
return;

#ifdef __MINGW64_VERSION_MAJOR

  /* Mark the section writable once, and unset it in
   * restore_modified_sections. */
  mark_section_writable ((LPVOID) addr);

#else/* __MINGW64_VERSION_MAJOR */

  MEMORY_BASIC_INFORMATION b;
  DWORD oldprot = 0;
  int call_unprotect = 0;

  if (!VirtualQuery (addr, b, sizeof(b)))
{
  __report_error (  VirtualQuery failed for %d bytes at address %p,
  (int) sizeof(b), addr);
}

  /* Temporarily allow write access to read-only protected memory.  */
  if (b.Protect != PAGE_EXECUTE_READWRITE  b.Protect != 
PAGE_READWRITE  b.Protect != PAGE_EXECUTE_WRITECOPY)

{
  call_unprotect = 1;
  VirtualProtect (b.BaseAddress, b.RegionSize, PAGE_EXECUTE_READWRITE,
  oldprot);
}

#endif /* __MINGW64_VERSION_MAJOR */

  /* write the data. */
  memcpy (addr, src, len);

#ifndef __MINGW64_VERSION_MAJOR

  /* Restore original protection. */
  if (call_unprotect  b.Protect != PAGE_EXECUTE_READWRITE  
b.Protect != PAGE_READWRITE  b.Protect != PAGE_EXECUTE_WRITECOPY)

VirtualProtect (b.BaseAddress, b.RegionSize, oldprot, oldprot);

#endif /* __MINGW64_VERSION_MAJOR */
}

If setting the protection in mark_section_writable was unsuccessful 
(unlikely as that is), trying to set it again here is not likely to help.


NB: I haven't tried this, but you have the setup to test it anyway. 
Also, this code snippet only fixes 2 of the 3 places that use 
PAGE_EXECUTE_WRITECOPY.  Remember to change the comparison in 
mark_section_writable() as well.


FWIW,
dw

On 8/15/2014 8:17 PM, Vadim Chugunov wrote:

Okay, I was wrong about __MINGW64_VERSION_MAJOR: it *was* defined.

What apparently happens is that the VirtualQuery() call that follows 
mark_section_writable(), returns page protection status of 0x80 
(PAGE_EXECUTE_WRITECOPY), which is unexpected by the relocator code, 
so it falls back to calling VirtualProtect() per relocation entry.


I am not entirely sure how this situation comes about, but here you go...

On Fri, Aug 15, 2014 at 1:01 AM, Vadim Chugunov vadi...@gmail.com 
mailto:vadi...@gmail.com wrote:


Hi,
I am trying to figure out the cause of a slow application startup,
and the evidence I have so far, points to mingw's
_pei386_runtime_relocator() routine as the culprit.   When I start
my app under debugger, I see this function calling
VirtualProtect() about a zillion times in a row.

Looking at the source, I see that __pei386_runtime_relocator() is
supposed to change memory protection just once per executable
section, but only if __MINGW64_VERSION_MAJOR is defined at
compilation time.  Otherwise,  it reverts to changing protection
once per relocation entry, for compatibility (?).
Unfortunately, I don't see any headers included by pseudo-reloc.c
that would define this symbol. And, indeed, the behavior I am
seeing at runtime indicates that if was not defined...

Am I reading this right?

Thanks!
Vadim

(mingw version = i686-4.9.0-win32-dwarf-rt_v3-rev2)




--


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] _lrotl and _lrotr

2014-07-27 Thread dw



And while I think it would be a good idea to add this function to 
intrin-impl.h so that this intrinsic function would be, well, 
intrinsic (instead of imported), that seems like a discussion for 
another day.


Hey, it's another day...

I originally thought it would make sense to do this incrementally, but 
perhaps I should have gone straight to the final answer.  This patch 
adds _lrotl/_lrotr to intrin-impl instead of just fixing the 
prototypes.  Shouldn't be any surprises.  Note that this is a 
replacement for the other patch, not in addition to.


dw
diff --git a/mingw-w64-headers/crt/intrin.h b/mingw-w64-headers/crt/intrin.h
index db4d7cd..88c585b 100644
--- a/mingw-w64-headers/crt/intrin.h
+++ b/mingw-w64-headers/crt/intrin.h
@@ -72,6 +72,10 @@ extern C {
 
 #include x86intrin.h
 
+/* Before 4.9.2, ia32intrin.h had broken versions of these. */
+#undef _lrotl
+#undef _lrotr
+
 #if defined(__cplusplus)
 }
 #endif
@@ -430,19 +434,8 @@ extern C {
 __MACHINEIA64(__MINGW_EXTENSION __int64 __load128_acq(void *,__int64 *))
 __MACHINEZ(void __cdecl longjmp(jmp_buf,int))
 
-#pragma push_macro (_lrotl)
-#undef _lrotl
-#pragma push_macro (_lrotr)
-#undef _lrotr
-#ifdef __x86_64__
-__MACHINE(__MINGW_EXTENSION unsigned long long __cdecl _lrotl(unsigned long long,int))
-__MACHINE(__MINGW_EXTENSION unsigned long long __cdecl _lrotr(unsigned long long,int))
-#else
-__MACHINE(unsigned __LONG32 __cdecl _lrotl(unsigned __LONG32,int))
-__MACHINE(unsigned __LONG32 __cdecl _lrotr(unsigned __LONG32,int))
-#endif
-#pragma pop_macro (_lrotl)
-#pragma pop_macro (_lrotr)
+/* __MACHINE(unsigned long __cdecl _lrotl(unsigned long,int)) moved to psdk_inc/intrin-impl.h */
+/* __MACHINE(unsigned long __cdecl _lrotr(unsigned long,int)) moved to psdk_inc/intrin-impl.h */
 
 __MACHINEI(__MINGW_EXTENSION unsigned __int64 __ll_lshift(unsigned __int64,int))
 __MACHINEI(__MINGW_EXTENSION __int64 __ll_rshift(__int64,int))
diff --git a/mingw-w64-headers/crt/stdlib.h b/mingw-w64-headers/crt/stdlib.h
index e38d481..18a569d 100644
--- a/mingw-w64-headers/crt/stdlib.h
+++ b/mingw-w64-headers/crt/stdlib.h
@@ -526,19 +526,20 @@ float __cdecl __MINGW_NOTHROW strtof(const char * __restrict__ _Str,char ** __re
   _CRTIMP int __cdecl _atodbl_l(_CRT_DOUBLE *_Result,char *_Str,_locale_t _Locale);
   _CRTIMP int __cdecl _atoldbl_l(_LDOUBLE *_Result,char *_Str,_locale_t _Locale);
   _CRTIMP int __cdecl _atoflt_l(_CRT_FLOAT *_Result,char *_Str,_locale_t _Locale);
-#pragma push_macro (_lrotr)
-#pragma push_macro (_lrotl)
-#undef _lrotr
-#undef _lrotl
-#ifdef __x86_64__
-  __MINGW_EXTENSION unsigned long long __cdecl _lrotl(unsigned long long _Val,int _Shift);
-  __MINGW_EXTENSION unsigned long long __cdecl _lrotr(unsigned long long _Val,int _Shift);
-#else
-  unsigned long __cdecl _lrotl(unsigned long _Val,int _Shift);
-  unsigned long __cdecl _lrotr(unsigned long _Val,int _Shift);
-#endif
-#pragma pop_macro (_lrotl)
-#pragma pop_macro (_lrotr)
+
+  /* If x86intrin.h has already been included, we already have these definitions */
+#ifndef _X86INTRIN_H_INCLUDED
+/* When using 4 byte longs (x86 or x64+native Windows) */
+#ifndef __LP64__
+  /* use the 32bit rotates in MSVCRT.dll */
+  unsigned long __cdecl _lrotl(unsigned long,int);
+  unsigned long __cdecl _lrotr(unsigned long,int);
+#else /* __LP64__ */
+/* Under systems that use 8 byte longs (like 64bit cygwin), we need 8 byte rotates */
+#define _lrotl(a,b) _rotl64((a), (b))
+#define _lrotr(a,b) _rotr64((a), (b))
+#endif /* __LP64__ */
+#endif /* _X86INTRIN_H_INCLUDED */
 
   _CRTIMP void __cdecl _makepath(char *_Path,const char *_Drive,const char *_Dir,const char *_Filename,const char *_Ext);
   _onexit_t __cdecl _onexit(_onexit_t _Func);
diff --git a/mingw-w64-headers/include/psdk_inc/intrin-impl.h b/mingw-w64-headers/include/psdk_inc/intrin-impl.h
index 8ccff53..8b186f6 100644
--- a/mingw-w64-headers/include/psdk_inc/intrin-impl.h
+++ b/mingw-w64-headers/include/psdk_inc/intrin-impl.h
@@ -498,6 +498,30 @@ supports ReadWriteBarrier, map all 3 to do the same. */
 extern C {
 #endif
 
+/* Before 4.9.2, ia32intrin.h had broken versions of these. */
+#undef _lrotl
+#undef _lrotr
+
+#if __INTRINSIC_PROLOG(_lrotl)
+unsigned long _lrotl(unsigned long __X, int __C);
+__INTRINSICS_USEINLINE
+unsigned long _lrotl(unsigned long __X, int __C)
+{
+  return (__X  __C) | (__X  ((sizeof(long) * 8) - __C));
+} 
+#define __INTRINSIC_DEFINED__lrotl
+#endif /* __INTRINSIC_PROLOG */
+
+#if __INTRINSIC_PROLOG(_lrotr)
+unsigned long _lrotr(unsigned long __X, int __C);
+__INTRINSICS_USEINLINE
+unsigned long _lrotr(unsigned long __X, int __C)
+{
+  return (__X  __C) | (__X  ((sizeof(long) * 8) - __C));
+} 
+#define __INTRINSIC_DEFINED__lrotr
+#endif /* __INTRINSIC_PROLOG */
+
 #if defined(__x86_64__) || defined(_AMD64_)
 
 #if __INTRINSIC_PROLOG(__faststorefence)
--
Want fast and easy access to all the code

Re: [Mingw-w64-public] _lrotl and _lrotr

2014-07-26 Thread dw

Well, since no one else has responded, what would you say to this 
(attached)?


If you like, I can write up a detailed description about why I believe 
this is the way to go, but hopefully the comments and code speak for 
themselves.  This should give the correct definitions for 32bit, LP64 
and LLP64.


If this is approved, someone else will have to commit it.  git is not my 
thing.


dw

On 7/20/2014 2:18 AM, Ozkan Sezer wrote:

Regarding gcc PR target/61662:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61662
http://gcc.gnu.org/viewcvs/gcc?view=revisionsortby=daterevision=212826

In our intrin.h (and stdlib.h), we are overriding the definitions
from ia32intrin.h possibly the original definition from gcc used
to be wrong with relation to _LLP64?  Even if that were the case,
what we have is wrong because _lrotl and _lrotr accept and return
unsigned long for both win32 _and_ win64, and for windows that is
strictly 32 bits.  We need to fix this.

--
O.S.

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



diff --git a/mingw-w64-headers/crt/intrin.h b/mingw-w64-headers/crt/intrin.h
index db4d7cd..8a08e9d 100644
--- a/mingw-w64-headers/crt/intrin.h
+++ b/mingw-w64-headers/crt/intrin.h
@@ -430,19 +430,19 @@ extern C {
 __MACHINEIA64(__MINGW_EXTENSION __int64 __load128_acq(void *,__int64 *))
 __MACHINEZ(void __cdecl longjmp(jmp_buf,int))
 
-#pragma push_macro (_lrotl)
-#undef _lrotl
-#pragma push_macro (_lrotr)
-#undef _lrotr
-#ifdef __x86_64__
-__MACHINE(__MINGW_EXTENSION unsigned long long __cdecl _lrotl(unsigned long long,int))
-__MACHINE(__MINGW_EXTENSION unsigned long long __cdecl _lrotr(unsigned long long,int))
-#else
-__MACHINE(unsigned __LONG32 __cdecl _lrotl(unsigned __LONG32,int))
-__MACHINE(unsigned __LONG32 __cdecl _lrotr(unsigned __LONG32,int))
-#endif
-#pragma pop_macro (_lrotl)
-#pragma pop_macro (_lrotr)
+/* If x86intrin.h has already been included, we already have these definitions */
+#ifndef _X86INTRIN_H_INCLUDED
+/* When using 4 byte longs (x86 or x64+native Windows) */
+#ifndef __LP64__
+  /* use the 32bit rotates in MSVCRT.dll */
+__MACHINE(unsigned long __cdecl _lrotl(unsigned long,int))
+__MACHINE(unsigned long __cdecl _lrotr(unsigned long,int))
+#else /* __LP64__ */
+/* Under systems that use 8 byte longs (like 64bit cygwin), we need 8 byte rotates */
+#define _lrotl(a,b) _rotl64((a), (b))
+#define _lrotr(a,b) _rotr64((a), (b))
+#endif /* __LP64__ */
+#endif /* _X86INTRIN_H_INCLUDED */
 
 __MACHINEI(__MINGW_EXTENSION unsigned __int64 __ll_lshift(unsigned __int64,int))
 __MACHINEI(__MINGW_EXTENSION __int64 __ll_rshift(__int64,int))
diff --git a/mingw-w64-headers/crt/stdlib.h b/mingw-w64-headers/crt/stdlib.h
index e38d481..18a569d 100644
--- a/mingw-w64-headers/crt/stdlib.h
+++ b/mingw-w64-headers/crt/stdlib.h
@@ -526,19 +526,20 @@ float __cdecl __MINGW_NOTHROW strtof(const char * __restrict__ _Str,char ** __re
   _CRTIMP int __cdecl _atodbl_l(_CRT_DOUBLE *_Result,char *_Str,_locale_t _Locale);
   _CRTIMP int __cdecl _atoldbl_l(_LDOUBLE *_Result,char *_Str,_locale_t _Locale);
   _CRTIMP int __cdecl _atoflt_l(_CRT_FLOAT *_Result,char *_Str,_locale_t _Locale);
-#pragma push_macro (_lrotr)
-#pragma push_macro (_lrotl)
-#undef _lrotr
-#undef _lrotl
-#ifdef __x86_64__
-  __MINGW_EXTENSION unsigned long long __cdecl _lrotl(unsigned long long _Val,int _Shift);
-  __MINGW_EXTENSION unsigned long long __cdecl _lrotr(unsigned long long _Val,int _Shift);
-#else
-  unsigned long __cdecl _lrotl(unsigned long _Val,int _Shift);
-  unsigned long __cdecl _lrotr(unsigned long _Val,int _Shift);
-#endif
-#pragma pop_macro (_lrotl)
-#pragma pop_macro (_lrotr)
+
+  /* If x86intrin.h has already been included, we already have these definitions */
+#ifndef _X86INTRIN_H_INCLUDED
+/* When using 4 byte longs (x86 or x64+native Windows) */
+#ifndef __LP64__
+  /* use the 32bit rotates in MSVCRT.dll */
+  unsigned long __cdecl _lrotl(unsigned long,int);
+  unsigned long __cdecl _lrotr(unsigned long,int);
+#else /* __LP64__ */
+/* Under systems that use 8 byte longs (like 64bit cygwin), we need 8 byte rotates */
+#define _lrotl(a,b) _rotl64((a), (b))
+#define _lrotr(a,b) _rotr64((a), (b))
+#endif /* __LP64__ */
+#endif /* _X86INTRIN_H_INCLUDED */
 
   _CRTIMP void __cdecl _makepath(char *_Path,const char *_Drive,const char *_Dir,const char *_Filename,const char *_Ext);
   _onexit_t __cdecl _onexit(_onexit_t _Func

Re: [Mingw-w64-public] _lrotl and _lrotr

2014-07-26 Thread dw


On 7/26/2014 9:29 AM, JonY wrote:
 On 7/26/2014 22:39, Ozkan Sezer wrote:
 On 7/26/14, dw limegreenso...@yahoo.com wrote:
 Well, since no one else has responded, what would you say to this
 (attached)?

 If you like, I can write up a detailed description about why I believe
 this is the way to go, but hopefully the comments and code speak for
 themselves.  This should give the correct definitions for 32bit, LP64
 and LLP64.

 If this is approved, someone else will have to commit it.  git is not my
 thing.
 Kai and/or Jon should be approving or rejecting this.

 I'm not familiar enough with these calls to comment on them, but if
 Cygwin uses it, keep in mind that Cygwin is LP64, not LLP64 like Windows is.

That's the crazy thing about all this: It truly isn't that complicated 
to understand.  Here is the actual code needed for _lrotl:

unsigned long _lrotl(unsigned long __X, int __C)
{
   return (__X  __C) | (__X  ((sizeof(long) * 8) - __C));
}

And you know what you have to change to get this to support 32bit? Or 
LP64?  Or LLP64?  NOTHING!  That's the whole dang thing there in 1 line 
of code.

But instead of using this simple, easy to understand, platform neutral 
and readily inlined code, we've got macros, #undefs, weird pragmas, 
#ifs, imports, etc.  The only part of this that's hard to understand is 
why everyone has made this so freaking complicated.

deep breath

Ok then, the challenge here is take what we've got and try to make the 
best of things. So this is what my patch does:

1) If x86intrin.h has been included, it's got a nice inline version of 
this function.  Now that the gcc team has fixed it, this is the best choice.
2) If we are dealing with 32bit longs (either x86 or LLP64), just add 
the prototype and let things get resolved from msvcrt.dll.  Not as nice 
as x86intrin's inline, but it works (and is what the existing code does).
3) If we are dealing with 64bit longs (ie 64bit cygwin), we macro _lrotl 
to _lrotl64, which will get resolved from msvcrt.dll.  Again, not 
ideal.  But unlike the existing definition in stdlib.h (which always 
maps to msvcrt.dll's 32bit _lrotl), it gives the right answer.

And while I think it would be a good idea to add this function to 
intrin-impl.h so that this intrinsic function would be, well, 
intrinsic (instead of imported), that seems like a discussion for 
another day.

dw

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Potential memory leaks in exception handling?

2014-01-16 Thread dw


 AFAIK mingw-w64 uses callbacks to reclaim TLS memory. In the first case, upon 
 destruction of the static object there were 5 blocks of memory unfreed; and 
 in the second case there were 6. If we say there was no memory leak in case 
 1, then there must be in case 2, IMO.

I've tried this myself, and I think I'm seeing what you are seeing. It 
looks to me like the problem comes from ___w64_mingwthr_add_key_dtor in 
tlsthrd.c.  In this routine, calloc is called to create a 
__mingwthr_key_t.  However, I don't believe that memory ever gets freed.

In theory it could get freed in ___w64_mingwthr_remove_key_dtor (at 
least there is a free for it there), but apparently that routine never 
gets called.

Maybe it was supposed to be freed in __mingwthr_run_key_dtors when it 
gets called?

dw



--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Winpthreads library issue with dwarf toolchain

2013-12-05 Thread dw


A few thoughts:

1) Shouldn't global_lock be __LONG32?
2) Would it make sense for the exchange on global_lock to be done as a 
single operation (ie InterlockedCompareExchange)?


dw

On 12/5/2013 10:45 AM, Fanael Linithien wrote:

I came up with a patch that fixes the issue for me.

The patch replaces the global critical section with a spinlock.
Critical sections require explicit initialization before use, which in
this case is not possible: register_frame_ctor (from libgcc), which
runs BEFORE enter_global_cs, tries to lock a mutex, which requires a
spinlock, which needs to be initialized in static_spin_init, which
tries to enter the global critical section, which is not initialized.
The result is a segfault somewhere in ntdll.

register_frame_ctor has constructor priority of 0, so setting the
priority of global_spin_ctor wouldn't cut it.


I'm not sure what is the official way to send patches, so I'm posting it here.


--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Mingwbuilds-users] GlobalMemoryStatusEx still failing

2013-11-17 Thread dw

Are you setting the dwLength member to the size of the structure?

dw

On 11/17/2013 1:18 AM, niXman wrote:
 Jim Michaels 2013-11-17 11:27:
 it's returning failure.
 I have even filled the MEMORYSTATUSEX struct with 0's using memset().
 nothing about that function seems to work.
 Hi,

 Please repost to mingw-w64-public@lists.sourceforge.net, because
 MinGW-builds joined MinGW-W64.




--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Linking issue: _lock_file

2013-11-14 Thread dw


It sounds like you are missing libmsvcr100.a

dw

On 11/13/2013 9:34 AM, André Guerreiro wrote:

Hello all,
sorry if this is a really basic question, I'm a MingW newbie.

I'm trying to build this code with Mingw-w64 4.6.3

#include stdio.h

int main()
{
FILE *fp = fopen(SOME_FILE, r);
_lock_file(fp);
return 0;

}

Using the following command:
/usr/bin/i686-w64-mingw32-gcc -o hello.exe hello.c

it throws the following error:
/tmp/cc9120Ls.o:hello.c:(.text+0x30): undefined reference to 
`__imp___lock_file'

collect2: ld returned 1 exit status

I may be missing some linker flag but no idea which one...

Thanks in advance



--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] semaphore wrappers

2013-11-14 Thread dw


 My mistake, winpthreads itself is BSD, so is it OK to license it as 
 BSD for mingw-w64?

If we are going to look at adopting this code, there are few things in 
it that should be reviewed first.  I saw a few when it was first posted, 
but dropped them when I saw there were licensing issues. I'll look again 
if we are serious about using it.

dw

--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] semaphore wrappers

2013-11-09 Thread dw


  handle = CreateSemaphore(NULL, (LONG) value, (LONG) 1024, name);


Why 1024?  Is this the same as SEM_VALUE_MAX?


if (handle == NULL){
LPTSTR buffer;
errno = EINVAL;
return (_sem_t *)SEM_FAILED;
}


What's the buffer for?

static int _sem_timedwait(_sem_t *sem, const struct timespec 
*abs_timeout){

long milliseconds = abs_timeout-tv_sec * 1000;
milliseconds += (abs_timeout-tv_nsec/100);
tubo_sem_timeout(sem, milliseconds);
}


This doesn't appear to match the man page 
http://man7.org/linux/man-pages/man3/sem_wait.3.html I read: If the 
timeout has already expired by the time of the call implies that an 
absolute time is being specified, not a duration.  While I think your 
definition is more useful, this may result in unexpected behavior for 
others.


FWIW,
dw

--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] _lrotr - take 2

2013-10-03 Thread dw

Sorry for the delayed response on this topic, things got busy.  To pick 
this back up, this is where we stand now:

- There's a bug in gcc's x86intrin.h.  They assume that under x64, longs 
are always 8 bytes.  For native Windows (ie not cygwin), that's not 
correct, and leads to incorrect results for the intrinsics _lrotr and 
_lrotl.  It's possible to do a work-around using undef + define.
- In addition to the bug in x86intrin, there are incorrect prototypes 
for _lrotr and _lrotl in intrin.h, stdlib.h and winnt.h.

I see 3 reasonable courses of action:

1) We could fix our prototypes plus add the work-around everywhere we 
include x86intrin.h.  This is what my previous patch did. However, as 
Kai (correctly) points out, this puts the same code in a multiple 
places.  That's both inefficient, and harder to maintain.

2) We could fix our prototypes plus put the work-around in a wrapper 
file (ie x86intrin-fix.h).  Then instead of including x86intrin.h, we'd 
include x86intrin-fix.h in our headers (winnt.h  intrin.h).  This fix 
(as well as any future fixes for x86intrin) could be done in one place.  
Also, when gcc fixes this problem in their code, we can put an #ifdef to 
see if the fix is still needed in a single place.

3) We could fix our prototypes, then open a ticket against gcc to fix 
their bug in x86intrin.h.

Neither #1 or #2 fix the problem if users include x86intrin.h directly.  
Also, this problem has been there a long time, and I haven't seen anyone 
(besides me) screaming for a fix.  If we needed an immediate fix, I 
could see going with #2, but the cleanest (and my current preference) is 
#3.

I'm prepared to write #2 or #3 (or #4 if someone has a better idea), but 
before I spend the time, I'd like to know which would get approved.

dw

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Conflicts with intrin.h

2013-09-19 Thread dw



c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/include/intrin.h:235:5: 
error: declaration of C function 'long int 
_InterlockedDecrement(volatile long int*)' conflicts with


4. winnt.h includes intrin.h where all the Interlockedsomething 
funcs are declared
6. in winbase.h around line 805 the Interlockedsomething funcs are 
declared again


The error message doesn't seem to be complaining because they are 
declared again.  Having 2 prototypes for the same function is not 
necessarily a problem.  As long as they are the same.  This message 
seems to be saying that the definitions are different.


Since you say the definitions are in intrin and winbase (instead of 
intrin-impl.h), you are not using a real recent build of mingw-w64. Can 
you post the two conflicting lines?  Perhaps I'll be able to offer a clue.


At a guess, there's some type of issue with long vs long32.  Is 
sizeof(long) 32 or 64?


It might also be worth looking at the -E output.  Perhaps you are 
grabbing intrin.h and winbase.h from different mingw-w64 builds?


dw
--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___
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] intrsinsic _lrotl

2013-09-14 Thread dw




I asked somebody with an installed VS and indeed
winnt.h header includes intrin.h header by their SDK.  So your fix is
no fix at all.  It just removed a compatibility we had in the past,
and now doesn't exist anymore.


intrin.h is not included in the Windows 7 sdk version (either v7.0 or 
v7.1) of winnt.h.  It was added in the Windows 8 sdk, but *only* for 
_M_ARM.



I would like to know where you got this information that intrin.h
isn't included, as it is plain wrong.


I get this information from my own installed versions of the Windows sdk.


I mean incomplete, due important intrin-prototypes aren't done for our
winnt.h header now.


What ones?  Are you referring to the ones in the comment I added?

   //* We need implementations for _mm_lfence, _mm_mfence, _mm_sfence,
   _mm_pause, _mm_prefetch *//
   /# include x86intrin.h/

The purpose of this comment is *not* to document routines that are 
missing, it documents the reason the following line is included. 
x86intrin.h is where these routines are implemented.


Since x86intrin.h includes a number of additional routines that are not 
available from MS's version of this file, a comment explaining why 
mingw64 includes it seemed appropriate.  However, if the text isn't 
clear, I can re-word it.


dw
--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=64545871iu=/4140/ostg.clktrk___
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] intrinsics

2013-09-10 Thread dw


 I agree on fixing wrong behavior of intrinsic-functions (and their
 implementation files), but such changes please sent in separate
 patches, so that I can review them stand-alone.

 dw, can you please do that?

I'll try to parse these out into separate patches.  There's some overlap 
in the files they affect, so I can't send them all at once.

dw


--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [Patch] intrinsics __movsb

2013-09-10 Thread dw

__movsb, __movsd, __movsq, __movsw: Move these intrinsics from 
library-only to intrin-impl.


dw
Index: mingw-w64-crt/intrincs/__movsb.c
===
--- mingw-w64-crt/intrincs/__movsb.c	(revision 6265)
+++ mingw-w64-crt/intrincs/__movsb.c	(working copy)
@@ -1,12 +1,10 @@
-#include intrin.h
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
 
-void __movsb(unsigned char *Destination, unsigned char const *Source, size_t Count)
-{
-  __asm__ __volatile__
-  (
-rep; movsb :
-[Destination] =D (Destination), [Source] =S (Source), [Count] =c (Count) :
-[Destination] (Destination), [Source] (Source), [Count] (Count)
-  );
-}
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL___movsb /* Causes code generation in intrin-impl.h */
 
+#include intrin.h
Index: mingw-w64-crt/intrincs/__movsd.c
===
--- mingw-w64-crt/intrincs/__movsd.c	(revision 6265)
+++ mingw-w64-crt/intrincs/__movsd.c	(working copy)
@@ -1,12 +1,10 @@
-#include intrin.h
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
 
-void __movsd(unsigned __LONG32 *Dest, unsigned __LONG32 const *Source, size_t Count)
-{
-  __asm__ __volatile__
-  (
-rep; movsd :
-[Dest] =D (Dest), [Source] =S (Source), [Count] =c (Count) :
-[Dest] (Dest), [Source] (Source), [Count] (Count)
-  );
-}
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL___movsd /* Causes code generation in intrin-impl.h */
 
+#include intrin.h
Index: mingw-w64-crt/intrincs/__movsq.c
===
--- mingw-w64-crt/intrincs/__movsq.c	(revision 6265)
+++ mingw-w64-crt/intrincs/__movsq.c	(working copy)
@@ -1,12 +1,10 @@
-#include intrin.h
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
 
-void __movsq(unsigned long long *Dest, unsigned long long const *Source, size_t Count)
-{
-  __asm__ __volatile__
-  (
-rep; movsq :
-[Dest] =D (Dest), [Source] =S (Source), [Count] =c (Count) :
-[Dest] (Dest), [Source] (Source), [Count] (Count)
-  );
-}
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL___movsq /* Causes code generation in intrin-impl.h */
 
+#include intrin.h
Index: mingw-w64-crt/intrincs/__movsw.c
===
--- mingw-w64-crt/intrincs/__movsw.c	(revision 6265)
+++ mingw-w64-crt/intrincs/__movsw.c	(working copy)
@@ -1,12 +1,10 @@
-#include intrin.h
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
 
-void __movsw(unsigned short *Dest, unsigned short const *Source, size_t Count)
-{
-  __asm__ __volatile__
-  (
-rep; movsw :
-[Dest] =D (Dest), [Source] =S (Source), [Count] =c (Count) :
-[Dest] (Dest), [Source] (Source), [Count] (Count)
-  );
-}
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL___movsw /* Causes code generation in intrin-impl.h */
 
+#include intrin.h
Index: mingw-w64-headers/crt/intrin.h
===
--- mingw-w64-headers/crt/intrin.h	(revision 6265)
+++ mingw-w64-headers/crt/intrin.h	(working copy)
@@ -20,13 +20,13 @@
  is included by intrin.h, as well as various platform sdk headers.
- Including intrin.h will create definitions/implementations for all available MSVC intrinsics.
- Including various platforms sdk headers will only include the intrinsics defined in that
- header.  As of this writing, only winnt.h uses this approach.
+ header.  As of this writing, only winnt.h and winbase.h use this approach.
- If an application defines its own prototypes for intrinsics (ie without including any
  platform header or intrin.h), the symbols will be resolved from the library.  Since this
  will likely result in the code being invoked via 'call', performance may be degraded.
 
If you wish to implement intrinsic functions that are defined in intrin.h but are not
-   yet implemented in mingw, see the comments at the top of intrin-impl.h.
+   yet implemented in mingw-w64, see the comments at the top of intrin-impl.h.
 */
 
 #ifndef __INTRIN_H_
@@ -1020,10 +1020,10 @@
 #ifndef __GNUC__
 __MACHINEI(__MINGW_EXTENSION unsigned __int64 __rdtsc(void))
 #endif
-__MACHINEI(void __movsb(unsigned char *,unsigned char

Re: [Mingw-w64-public] [Patch] intrinsics

2013-09-06 Thread dw


It's a really delayed reply, dw asked me to join the conversation.


Hey Jacek, thanks for you thoughts on this.  However, it doesn't seem to 
have brought us to a conclusion.  I've been trying to avoid nagging 
(something I am prone to do), especially since I've seen how busy Kai 
has been with his own work.  But it has now been nearly a month, v3 is 
upon us, and we've had no movement here.


When I first sent this patch, I was in a hurry since I thought v3 was 
just a day or two away.  As a result, I included several things in this 
single patch that should probably have been done as separate patches.  
And some of those things are bug fixes where the functions will actually 
return wrong answers.  Looking back at the original mail, here's what 
all this patch includes:


=
1) __movsb, __movsd, __movsq, __movsw: Moved to intrin-impl.
2) __rdtsc: Change to use builtin, moved to intrin-impl, resolved 
conflict with ia32intrin.

3) _umul128  _mul128: Moved to intrin-impl.
4) __shiftright128  __shiftleft128: Re-written as asm, moved to 
intrin-impl.h.
5) _lrotr, _lrotl: Fix bug caused by ia32intrin.h when longs are 4 bytes 
long.
6) RtlSecureZeroMemory - According to msdn, this is not an intrinsic and 
should only be defined in winnt.h. *File deleted from intrincs.*
7) UnsignedMultiplyExtract128  MultiplyExtract128:  According to msdn, 
these are not intrinsics.  Also, MultiplyExtract128 doesn't work right. 
*Files deleted from intrincs* and code fixed in winnt.h.
8) _InterlockedAdd  _InterlockedAdd64: According to msdn, these 
intrinsics are only available for itanium.  I'm not sure the inline asm 
we have will run properly there, and there are no #if's around it to 
limit it to that platform.  Note that winnt.h has inlines for x86/x64 
for these. *Files deleted from intrincs*.

=

1-4 These 9 functions were ONLY available in the .a file.  This patch 
includes them as inline intrinsics, a performance win.
5  7 fix actual bugs that result in the functions returning incorrect 
answers under certain conditions.


I don't believe there is any controversy regarding these points. Even if 
we can't come to an agreement on the rest, I believe these should be 
included in v3.  I'm prepared to produce a patch for just these upon 
request and we can continue to debate the rest.


As we have discussed before, the problem here seems to be the deletions 
from 6, 7  8.  I've tried to understand the requirement here, and I'm 
sure Kai is as frustrated with trying to explain it to me as I am about 
trying to get it explained.


For example, kai says:


The need to add it to libmingwex is that this function isn't present
on all supported Windoof OSes, so we need to handle that.


This is confusing since these functions aren't support by the Windows 
OS.  They aren't exported from any DLL that I'm aware of. The only place 
they exist in MS world is as inlines in winnt.h, which is the same thing 
I'm trying to do.


Other than this, Kai seems to be saying that there is a requirement that 
we be able to support the ability to have all these functions not be 
inline.  However, I'm not clear on why these specific functions have 
this requirement.  Not only is this inconsistent with MS's definition, 
there are a number of other functions in the platform headers that are 
marked as FORCEINLINE, so why are these functions different?  Deleting 
these files and using FORCEINLINE still seems to me to be the most 
logical course here.


However, if that's not acceptable, perhaps there is an alternative. If 
the requirement I'm violating here is simply that these specific 
functions must be able to support not being inlined, then I believe 
simply changing them from FORCEINLINE to inline would satisfy this 
requirement.  It seems like having them in the library is still 
redundant.  Would this change make the deletions acceptable?


Thirdly, if the requirement is really that these functions must exist in 
the .a file, then just let me know.  While I don't understand why (and 
I'd like to), I'm prepared to do it anyway.  I would still need to fix 
the library version of MultiplyExtract128, but if this is what I need to 
do, just say so.


I'm obviously not going to check anything in that isn't approved. But 
there are bug fixes and performance improvements here that I think are 
worth including in v3.  Let me know how I should proceed.


dw
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk___
Mingw

Re: [Mingw-w64-public] _CRTIMP

2013-08-26 Thread dw


 we are capable to handle dll-imports without the proper
 decoration of the symbol.

I understand why you want to have the stubs.  This made more sense to me 
once I saw that __builtin_memset ends up using them to call __imp_memset.

 If a symbol is marked as dllimport, it means it becomes part of the
 DECL itself.  So we get conflicts with people simply doing prototypes
 without.  By this reason - and some issues about builtin-optimization
 for such symbols - we decided to remove by those symbols the CRTIMP
 decoration.

Argh!  Yes, I see what you mean.  Even if you aren't using posix, if you 
have your own definition for any of these functions, warning messages 
can appear.  Unless the _CRTIMP def comes after the non-imp.

I'm trying to decide what is the proper balance here:

Side A (Change to use _CRTIMP or _POSIXPREFIX): People who use headers 
that conflict with ours AND who use our headers first will get easily 
suppressed warning messages.
Side B (Leave as is): We have runtime performance issues with any 
posix-ish functions.

Given that my current project is so performance sensitive, I'm heavily 
biased towards B.  But maybe this one should just sit for a while.  
Perhaps a better approach will occur to me.

 And I kindly ask not to touch the default behavior here as it might
 cause breakages at pretty unexpected places.

I didn't even start trying to change stdio.h until I heard back from 
you.  This seemed so odd that I had to ask.

If we did add some type of #define here, it would also be a good place 
to document all this.  I'm a big believer in capturing this kind of 
knowledge, but you've got to have a place where people will find it.

dw

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Interlocked API for Mingw64 4.8.1

2013-08-20 Thread dw

It turns out his problem was with boost (ie the problem we discussed 
here https://sourceforge.net/p/mingw-w64/mailman/message/31196562/).


Erik, what ever happened with that patch you proposed?  If someone pops 
up here with this problem again, can I tell them to just get the latest 
boost?  Apply your patch?  Define BOOST_USE_WINDOWS_H?


dw

On 8/20/2013 7:46 AM, Ruben Van Boxem wrote:
2013/8/20 Alex Hultman alexhult...@gmail.com 
mailto:alexhult...@gmail.com


Hey!

I'm trying to figure out what libs to link with to get the
Interlocked*-API working. Google points me in the direction of
wkernel32 but I cannot find that lib in the newer sources and it
doesn't exist in my Fedora 19 installation. kernel32, mingwex
doesn't define the API. What libs am I supposed to link with to
get this working?


It should be in kernel32.dll, which is linked automatically by GCC.

What is your link commandline?

Ruben


Thanks.


--
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance
Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
mailto:Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




--
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Mingw-w64-developer] Patch for winbase.h header

2013-08-20 Thread dw




With recent patch I get compiler-error for c++ in
psdk_inc/intrin-impl.h:914 due different use of types.  Again psdk vs
bare-C types (LONGLONG vs long long).


Looking at the prototypes and implementations for 
InterlockedCompareExchange64 (which I believe is what is at your line 
#914), all I see are __int64 and LONGLONG.  Because of these lines, 
I assume the types are the same:


ntdef.h:__MINGW_EXTENSION typedef __int64 LONGLONG, *PLONGLONG;
winnt.h:  __MINGW_EXTENSION typedef __int64 LONGLONG;

The only exception I see is the newly added ARM definition in winbase.h 
at ~line 965.  This definition uses LONG64, which is not consistent with 
any of the other definitions of InterlockedCompareExchange64, and is not 
consistent with MSDN 
http://msdn.microsoft.com/en-us/library/windows/apps/ms683562%28v=vs.85%29.aspx.


If you are not compiling for ARM, I'll need more details so I can 
reproduce the problem here.



This signature stuff has to stop.



dw
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk___
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] intrinsics

2013-08-09 Thread dw



 IMHO it has some advantages to have some of
 those functions used by static-library instead of calling into a DLL.

What DLL?  None of these 5 functions are in any DLL that I can see.

   The need to add it to libmingwex is that this function isn't present
 on all supported Windoof OSes, so we need to handle that.

Since these functions are *always* inline under MS (and in my patch), 
how can they not work on other OSes?They are either forceinline 
(winnt.h x64 only) or only available as intrinsics (Itanium-only).  
What am I missing here?


 Does the inline assembler
 code we have in the intrinsc directory even work on Itanium?
 No, IA64 isn't supported in our assembler.  We lack IA64 hardware for
 testing ...

Me too.  The fact that MS has dropped support for Itanium in W8 and 
VS2012 makes me even less motivated to support it.

 - These deletes bring mingw-w64 in line with MS.
 That isn't necessarily the thing we want.  I admit that in point of
 incompatiblity, we should think pretty hard about it, if we want to do
 that, but by default we have the goal of having a working environment
 for gcc (and other FOSS) compilers.

It seems to me that best performance and most compatible with MS are 
the same thing in this case.  I'm not clear what benefit we get for not 
doing exactly what MS does here.  Allowing people to force these 
functions to NOT be inline allows them to?

I used to think forcing them inline meant you couldn't take the address 
of the routine, but that doesn't appear to be true?

dw

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [Patch] intrinsics

2013-08-06 Thread dw

I think this is about it for intrinsics work for v3.  This patch is 
(mostly) for the files in intrinsc\*.c that weren't changed by any 
previous work.  It's possible that not everything in this patch will get 
approved, but I figure it's easier to ask forgiveness than permission.


__movsb, __movsd, __movsq, __movsw: Moved to intrin-impl.
__rdtsc: Change to use builtin, moved to intrin-impl, resolved conflict 
with ia32intrin.

_umul128  _mul128: Moved to intrin-impl.
__shiftright128  __shiftleft128: Re-written as asm, moved to intrin-impl.h.

_lrotr, _lrotl: Fix bug caused by ia32intrin.h when longs are 4 bytes long.

RtlSecureZeroMemory - According to msdn, this is not an intrinsic and 
should only be defined in winnt.h. *File deleted from intrincs.*


UnsignedMultiplyExtract128  MultiplyExtract128:  According to msdn, 
these are not intrinsics.  Also, MultiplyExtract128 doesn't work right. 
*Files deleted from intrincs* and code fixed in winnt.h.


_InterlockedAdd  _InterlockedAdd64: According to msdn, these intrinsics 
are only available for itanium.  I'm not sure the inline asm we have 
will run properly there, and there are no #if's around it to limit it to 
that platform.  Note that winnt.h has inlines for x86/x64 for these. 
*Files deleted from intrincs*.


dw
Index: mingw-w64-crt/intrincs/__movsb.c
===
--- mingw-w64-crt/intrincs/__movsb.c	(revision 6023)
+++ mingw-w64-crt/intrincs/__movsb.c	(working copy)
@@ -1,12 +1,10 @@
-#include intrin.h
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
 
-void __movsb(unsigned char *Destination, unsigned char const *Source, size_t Count)
-{
-  __asm__ __volatile__
-  (
-rep; movsb :
-[Destination] =D (Destination), [Source] =S (Source), [Count] =c (Count) :
-[Destination] (Destination), [Source] (Source), [Count] (Count)
-  );
-}
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL___movsb /* Causes code generation in intrin-impl.h */
 
+#include intrin.h
Index: mingw-w64-crt/intrincs/__movsd.c
===
--- mingw-w64-crt/intrincs/__movsd.c	(revision 6023)
+++ mingw-w64-crt/intrincs/__movsd.c	(working copy)
@@ -1,12 +1,10 @@
-#include intrin.h
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
 
-void __movsd(unsigned __LONG32 *Dest, unsigned __LONG32 const *Source, size_t Count)
-{
-  __asm__ __volatile__
-  (
-rep; movsd :
-[Dest] =D (Dest), [Source] =S (Source), [Count] =c (Count) :
-[Dest] (Dest), [Source] (Source), [Count] (Count)
-  );
-}
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL___movsd /* Causes code generation in intrin-impl.h */
 
+#include intrin.h
Index: mingw-w64-crt/intrincs/__movsq.c
===
--- mingw-w64-crt/intrincs/__movsq.c	(revision 6023)
+++ mingw-w64-crt/intrincs/__movsq.c	(working copy)
@@ -1,12 +1,10 @@
-#include intrin.h
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
 
-void __movsq(unsigned long long *Dest, unsigned long long const *Source, size_t Count)
-{
-  __asm__ __volatile__
-  (
-rep; movsq :
-[Dest] =D (Dest), [Source] =S (Source), [Count] =c (Count) :
-[Dest] (Dest), [Source] (Source), [Count] (Count)
-  );
-}
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL___movsq /* Causes code generation in intrin-impl.h */
 
+#include intrin.h
Index: mingw-w64-crt/intrincs/__movsw.c
===
--- mingw-w64-crt/intrincs/__movsw.c	(revision 6023)
+++ mingw-w64-crt/intrincs/__movsw.c	(working copy)
@@ -1,12 +1,10 @@
-#include intrin.h
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
 
-void __movsw(unsigned short *Dest, unsigned short const *Source, size_t Count)
-{
-  __asm__ __volatile__
-  (
-rep; movsw :
-[Dest] =D (Dest), [Source] =S (Source), [Count] =c (Count) :
-[Dest] (Dest), [Source] (Source), [Count] (Count)
-  );
-}
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL___movsw /* Causes code generation in intrin-impl.h */
 
+#include intrin.h
Index: mingw-w64-crt/intrincs/__shiftleft128.c
===
--- mingw-w64-crt/intrincs/__shiftleft128.c	(revision 6023

Re: [Mingw-w64-public] _lrotr and LP64

2013-08-04 Thread dw


 As for LLP64 long isn't 64-bit wide, we need to override it.

Except that we don't override it.  As written, every 64bit compile turns 
_lrotr into a 64bit operation, regardless of the actual size of a long.  
And calling _lrotr with a 32bit value and having it do a 64bit rotate 
does not yield the correct answer.

Despite my earlier statements, I now believe that the problem is in 
ia32intrin.h.  Instead of using __x86_64__ to determine whether to use 
the 64bit rotate, it should be using __LP64__, __SIZEOF_LONG__, or some 
such.

 please note that changing of these headers
 in gcc was already tried by me in the past and was rejected.

I assume your patch was something like this 
(http://pastebin.com/0KHDDXie)? Determining the length of a long using 
standard defines seems pretty basic.  What was the objection?

 So we need to work-a-round that.
 please tell how to resolve difference between gcc's and MS
 intrinsic-defintion.

If they absolutely refuse to make any change here, then we could replace 
our code with something like this:

#if __SIZEOF_LONG__ == 8

#pragma push_macro (_lrotr)
#undef _lrotr
 __MACHINE(__MINGW_EXTENSION unsigned long long __cdecl 
_lrotr(unsigned long long,int))
#pragma pop_macro (_lrotr)

#else

#undef _lrotr
 __MACHINE(unsigned __LONG32 __cdecl _lrotr(unsigned __LONG32,int))
#define _lrotr(a,b)__rord((a), (b))

#endif

This will use the existing logic when longs are 8 bytes long (ie 
cygwin), and re-map the call to the correct function if it is 4 bytes 
(native windows).  This should work correctly for x86, x64, and cygwin.

 So I have strong doubts about the intend of your patch.

Sorry about that.  I missed the fact that all this was being done in 
ia32intrin.h.  Since a scan of the entire mingw-w64 tree didn't find any 
of these functions, I just assumed it was using msvcr*.dll for 
everything.  Hopefully I'm making more sense this time.

dw

--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
___
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] Move inline asm from conio.h to intrin-impl.h

2013-08-04 Thread dw


 In general this patch looks fair.  But there seems to be a bug here
 about readcr(1|2|...) function and none-64-bit mode.  The signature is
 different for that and this seems not to be reflected in that patch.

It's there, it just isn't as obvious as how it was done in 
intrincs\readcr*.c.

Look at intrin-impl.h.  There are several #if blocks there

- defined(__x86_64__)
- defined(__x86_64__) || (defined(_X86_)
- defined(_X86_)

The readcr* functions appear in both the __x86_64__ and _X86_ blocks 
using different signatures.

dw

--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
___
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] _bittest, _bittestandset, etc

2013-08-03 Thread dw

Jacek, while I have checked in this patch so that I could continue work, 
I would still be interested in any comments you might have on this.

dw

On 8/2/2013 12:12 AM, Kai Tietz wrote:
 Jacek, do you have any objections about that patch?


--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [Patch] _bittest, _bittestandset, etc

2013-08-02 Thread dw


1) Move these functions from winnt.h to intrin-impl.h:

_bittest, _bittest64
_bittestandset, _bittestandreset, _bittestandcomplement
_bittestandset64, _bittestandreset64, _bittestandcomplement64

2) Update inline asm code:

*a) Remove memory clobber*.
*b) Remove volatile keyword.*
c) Several changes to inputs, outputs, constraints and clobbers.
d) Use macros  symbolic names.
e) Support both att and intel asm formats.

dw
Index: mingw-w64-crt/intrincs/bittest.c
===
--- mingw-w64-crt/intrincs/bittest.c	(revision 5980)
+++ mingw-w64-crt/intrincs/bittest.c	(working copy)
@@ -1,11 +1,4 @@
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL__bittest // Causes code generation in intrin-impl.h
+
 #include intrin.h
-
-unsigned char _bittest(__LONG32 const *Base, __LONG32 Offset)
-{
-  int old = 0;
-  __asm__ __volatile__(btl %2,%1\n\tsbbl %0,%0 
-   :=r (old),=m ((*(volatile __LONG32 *) Base))
-   :Ir (Offset) : memory);
-  return (old != 0);
-}
-
Index: mingw-w64-crt/intrincs/bittest64.c
===
--- mingw-w64-crt/intrincs/bittest64.c	(revision 5980)
+++ mingw-w64-crt/intrincs/bittest64.c	(working copy)
@@ -1,11 +1,4 @@
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL__bittest64 // Causes code generation in intrin-impl.h
+
 #include intrin.h
-
-unsigned char _bittest64(__int64 const *Base, __int64 Offset)
-{
-  int old = 0;
-  __asm__ __volatile__(btq %2,%1\n\tsbbl %0,%0 
-:=r (old),=m ((*(volatile long long *) Base))
-:Ir (Offset) : memory);
-  return (old != 0);
-}
-
Index: mingw-w64-crt/intrincs/bittestc.c
===
--- mingw-w64-crt/intrincs/bittestc.c	(revision 5980)
+++ mingw-w64-crt/intrincs/bittestc.c	(working copy)
@@ -1,11 +1,4 @@
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL__bittestandcomplement // Causes code generation in intrin-impl.h
+
 #include intrin.h
-
-unsigned char _bittestandcomplement(__LONG32 *Base, __LONG32 Offset)
-{
-  int old = 0;
-  __asm__ __volatile__(btcl %2,%1\n\tsbbl %0,%0 
-:=r (old),=m ((*(volatile __LONG32 *) Base))
-:Ir (Offset) : memory);
-  return (old != 0);
-}
-
Index: mingw-w64-crt/intrincs/bittestc64.c
===
--- mingw-w64-crt/intrincs/bittestc64.c	(revision 5980)
+++ mingw-w64-crt/intrincs/bittestc64.c	(working copy)
@@ -1,11 +1,4 @@
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL__bittestandcomplement64 // Causes code generation in intrin-impl.h
+
 #include intrin.h
-
-unsigned char _bittestandcomplement64(__int64 *Base, __int64 Offset)
-{
-  int old = 0;
-  __asm__ __volatile__(btcq %2,%1\n\tsbbl %0,%0 
-:=r (old),=m ((*(volatile long long *) Base))
-:Ir (Offset) : memory);
-  return (old != 0);
-}
-
Index: mingw-w64-crt/intrincs/bittestr.c
===
--- mingw-w64-crt/intrincs/bittestr.c	(revision 5980)
+++ mingw-w64-crt/intrincs/bittestr.c	(working copy)
@@ -1,11 +1,4 @@
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL__bittestandreset // Causes code generation in intrin-impl.h
+
 #include intrin.h
-
-unsigned char _bittestandreset(__LONG32 *Base, __LONG32 Offset)
-{
-  int old = 0;
-  __asm__ __volatile__(btrl %2,%1\n\tsbbl %0,%0 
-:=r (old),=m ((*(volatile __LONG32 *) Base))
-:Ir (Offset) : memory);
-  return (old != 0);
-}
-
Index: mingw-w64-crt/intrincs/bittestr64.c
===
--- mingw-w64-crt/intrincs/bittestr64.c	(revision 5980)
+++ mingw-w64-crt/intrincs/bittestr64.c	(working copy)
@@ -1,11 +1,4 @@
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL__bittestandreset64 // Causes code generation in intrin-impl.h
+
 #include intrin.h
-
-unsigned char _bittestandreset64(__int64 *Base, __int64 Offset)
-{
-  int old = 0;
-  __asm__ __volatile__(btrq %2,%1\n\tsbbl %0,%0 
-:=r (old),=m ((*(volatile long long *) Base))
-:Ir (Offset) : memory);
-  return (old != 0);
-}
-
Index: mingw-w64-crt/intrincs/bittests.c
===
--- mingw-w64-crt/intrincs/bittests.c	(revision 5980)
+++ mingw-w64-crt/intrincs/bittests.c	(working copy)
@@ -1,11 +1,4 @@
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL__bittestandset // Causes code generation in intrin-impl.h
+
 #include intrin.h
-
-unsigned char _bittestandset(__LONG32 *Base, __LONG32 Offset)
-{
-  int old = 0;
-  __asm__ __volatile__(btsl %2,%1\n\tsbbl %0,%0 
-:=r (old),=m ((*(volatile __LONG32 *) Base))
-:Ir (Offset) : memory);
-  return (old != 0);
-}
-
Index: mingw-w64-crt/intrincs/bittests64.c
===
--- mingw-w64-crt/intrincs/bittests64.c	(revision 5980)
+++ mingw-w64-crt/intrincs/bittests64.c	(working copy)
@@ -1,11

Re: [Mingw-w64-public] [RFC] Single filename per line in Makefiles

2013-08-02 Thread dw


 Comments, flames, or questions?

I like this idea too.

dw

--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] _lrotr and LP64

2013-08-02 Thread dw


I have some (non-asm) questions about _lrotr (long rotate right).

1. Looking at intrin.h, it uses a #ifdef __x86_64__ to change the
   parameters between LONG32 and LONG64.  But that doesn't seem right. 
   Shouldn't it be looking at __LP64__? Since this is mapped to

   msvcr*.dll in the .def files, will this even work correctly?
2. If we play this game with the #ifdef, that leaves no methods for 32
   bit rotations under LP64.  There will be 8, 16, and 2 different
   functions for 64bit (_lrotr and _rotr64). Are we sure that's what we
   want?
3. Also in intrin.h, it uses #pragma push_macro (_lrotr) and #undef
   _lrotr.  As I understand it, these both only apply to macros, and
   _lrotr is not a macro. I think this should be deleted.

I realize that the l in _lrotr is supposed to stand for long.  
However, I believe it should still perform a 32bit rotation, even under 
LP64.  That would give us:


unsigned char _rotr8 (unsigned char _val, int _Shift);
unsigned short_rotr16(unsigned short_val, int _Shift);
unsigned __LONG32 _lrotr (unsigned __LONG32_val, int _Shift);
unsigned __int64  _rotr64(unsigned __int64  _val, int _Shift);

Note that mingw-w64-headers\crt\stdlib.h and 
mingw-w64-headers\include\winnt.h do the same thing.


dw
--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___
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] Fix warning error error for membarrier.c

2013-07-24 Thread dw


Done as 5980.

dw

On 7/23/2013 4:33 PM, dw wrote:



The patch looks good to me.


This patch requires re-building mingw-w64-crt/Makefile.in.  Can 
someone with the right autoconf do this checkin please?  The 
description should be something like:


Remove non-intrinsic function from intrinsic library.  Function is 
available in winnt.h.


Thanks,
dw


--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [Patch] Update winnt.h to be in line with MS

2013-07-24 Thread dw


Minor tweaks to bring defs in line with MS.

dw
Index: winnt.h
===
--- winnt.h	(revision 5973)
+++ winnt.h	(working copy)
@@ -1620,7 +1620,7 @@
 #else
 #define YieldProcessor __buildpause()
 VOID MemoryBarrier(VOID);
-__CRT_INLINE VOID MemoryBarrier(VOID)
+FORCEINLINE VOID MemoryBarrier(VOID)
 __buildmemorybarrier()
 #endif
 
@@ -6258,9 +6258,9 @@
 struct _TEB *NtCurrentTeb(VOID);
 PVOID GetCurrentFiber(VOID);
 PVOID GetFiberData(VOID);
-__CRT_INLINE struct _TEB *NtCurrentTeb(VOID) { return (struct _TEB *)__readgsqword(FIELD_OFFSET(NT_TIB,Self)); }
-__CRT_INLINE PVOID GetCurrentFiber(VOID) { return(PVOID)__readgsqword(FIELD_OFFSET(NT_TIB,FiberData)); }
-__CRT_INLINE PVOID GetFiberData(VOID) {
+FORCEINLINE struct _TEB *NtCurrentTeb(VOID) { return (struct _TEB *)__readgsqword(FIELD_OFFSET(NT_TIB,Self)); }
+FORCEINLINE PVOID GetCurrentFiber(VOID) { return(PVOID)__readgsqword(FIELD_OFFSET(NT_TIB,FiberData)); }
+FORCEINLINE PVOID GetFiberData(VOID) {
   return *(PVOID *)GetCurrentFiber();
 }
 #endif /* __x86_64 */
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [Patch] Fix warning error error for membarrier.c

2013-07-23 Thread dw


There is a compile warning coming from intrincs/membarrier.c:

/../../mingw-w64/mingw-w64-crt/intrincs/membarrier.c:4:6: warning: no 
previous prototype for 'MemoryBarrier' [-Wmissing-prototypes]/


There are two ways to fix it.

1) The easy, non-controversial way is to just add the prototype to the 
file.  And maybe to add the x64 version of code for slightly faster 
performance.


2) Of course I'm going to recommend the other fix which is to delete 
this file.  MemoryBarrier is NOT an intrinsic (ie it is not implemented 
as a builtin by the MSVC compiler).  According to MSDN 
http://msdn.microsoft.com/en-us/library/ms684208%28v=VS.85%29.aspx 
It's just an macro that's defined in winnt.h.  Which we already do.


The attached patch does the delete.  I can create the other patch 
instead if that seems like a better approach.


dw


Index: intrincs/membarrier.c
===
--- intrincs/membarrier.c	(revision 5979)
+++ intrincs/membarrier.c	(working copy)
@@ -1,10 +0,0 @@
-#include intrin.h
-
-/* for x86 only */
-void MemoryBarrier (void)
-{
-__LONG32 Barrier = 0;
-__asm__ __volatile__(xchgl %%eax,%0 
-  :=r (Barrier));
-}
-
Index: Makefile.am
===
--- Makefile.am	(revision 5979)
+++ Makefile.am	(working copy)
@@ -287,7 +287,7 @@
 
 # these only go into the 32 bit version:
 src_intrincs32=\
-  intrincs/membarrier.c   intrincs/readfsbyte.c   intrincs/readfsword.c   intrincs/readfsdword.c  \
+  intrincs/readfsbyte.c   intrincs/readfsword.c   intrincs/readfsdword.c  \
   intrincs/writefsbyte.c  intrincs/writefsword.c  intrincs/writefsdword.c
 
 if LIB32
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___
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] Fix warning error error for membarrier.c

2013-07-23 Thread dw




The patch looks good to me.


This patch requires re-building mingw-w64-crt/Makefile.in.  Can someone 
with the right autoconf do this checkin please?  The description should 
be something like:


Remove non-intrinsic function from intrinsic library.  Function is 
available in winnt.h.


Thanks,
dw
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Interlocked* patches follow-up

 I committed the patch with additional __MINGW_INTRIN_INLINE check so we
 can move on (to another problem on x64).

I committed the additional updates I had sent privately to Erik.

As for the __MINGW_INTRIN_INLINE thing, I guess I still don't quite 
understand the value.  If it isn't defined, is it likely 
__MINGW_GNUC_PREREQ will be?  Seems like we're just changing where the 
compiler error occurs.

 I hope Kai is okay with it and will review it when he's back.

Kai said that in his absence, you were able to approve checkins.

dw

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] InterlockedIncrement boost (yes, again) -What's the right answer here?


 I vote for this. Boost can always be fixed, and it contains lots of 
 ugly hacks around various platform obscurities. I think MSVC 
 intrinsics combined with GCC are a valid obscurity.
 Granted, if Boost is to change, you might as well give them the best 
 performance while we're at it :)

It's (apparently) a pretty trivial change and one that people are 
already recommending.  Doesn't seem that significant an issue (to me).

 Why not explain it to the Boost mailing list? I'm rather sure they'd 
 be inclined to accomodate us, if there's no fundamental problems with 
 the changes.

While I could write the email, I'm not sure they'd listen to me. It's 
not like they know who I am.  Also, I've been told that my posts are 
sometimes perceived as confrontational.  And that's not a good thing for 
this kind of effort.

dw

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] InterlockedIncrement boost (yes, again) -What's the right answer here?


 With this specific define set the boost package can indeed be compiled 
 without issues (for both the x86 and x64 targets).

Yay!

 However, there's a catch! The boost build system doesn't embed this
 specific define in its installed headers. It expects that all
 boost-using projects (like qpid-cpp) also have this BOOST_USE_WINDOWS_H
 define set otherwise it will also cause build failures there.

I don't know squat about boost.  But it seems like building boost with 
one set of options, then building downstream projects that use boost 
with a different set of options is a bad idea.  If defining 
BOOST_USE_WINDOWS_H is what's needed to work with our v3, this doesn't 
seem to me like an unreasonable burden.  Especially when it also gains 
them performance improvements.

dw

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] InterlockedIncrement boost (yes, again) -What's the right answer here?


 Still, the question if we want those in our crt is a separated issue.
 That's a question of being backward compatible, which is important IMO.
 Too bad those were introduced in the first place...

To me, this is the key question.  I agree that breaking backward 
compatibility is a bad thing.  And worse, we don't have any idea how 
many projects would be affected.  And really, the fix is pretty trivial 
(like I say, probably just an alias).

On the other hand, if someone were to post a message to some project 
saying I'm using your header files to access someone else's lib files 
and it doesn't always work right, who would you say is at fault?  The 
header people?  The lib people?  Or the crazy person who is trying to 
mix the two?

I'm still prepared to add these definitions back to the library file if 
people feel strongly.  I just want to point out that if I do, there will 
be no way to access these symbols using our headers.  You must be using 
boost (or some similar project) to reference them. And that just feels odd.

In summary, I've got Ruben who (I think) is saying to leave them out and 
work with boost (and others) to deal with the consequences.  And Jacek 
who (I think) is saying we should put them back to maintain backward 
compatibility.  If this were just a technical question, I'd vote to 
leave them out.  But really it's more of a political question.  And 
that's something I'm really bad at.

So, who decides?  If it's me, I'm probably going to wimp out and add the 
defs back to avoid the conflict.

dw

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] InterlockedIncrement boost (yes, again) -What's the right answer here?

 Attached is the patch I came up with to fix the build issue.

You are checking for defined(__MINGW64_VERSION_MAJOR).  Would it make 
sense to do (__MINGW64_VERSION_MAJOR = 3)?

dw

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [Patch] Updates for winbase.h

This patch has nothing to do with boost, and makes no changes to inline 
asm.  Just some simple header changes.


This patch:

- Allows winbase.h to use inline intrinsics whether winnt.h is also 
included or not.

- Brings x86 versions of InterlockedAnd64 et al into alignment with MS.
- Adds the #ifdef for __MINGW_INTRIN_INLINE that jacek wanted for 
intrin-impl.h.


dw
Index: mingw-w64-headers/include/psdk_inc/intrin-impl.h
===
--- mingw-w64-headers/include/psdk_inc/intrin-impl.h	(revision 5971)
+++ mingw-w64-headers/include/psdk_inc/intrin-impl.h	(working copy)
@@ -56,6 +56,11 @@
included multiple times.  This is because this file might be included multiple
times to define various subsets of the functions it contains. */
 
+/* However we do check for __MINGW_INTRIN_INLINE.  In theory this means we
+   can work with other compilers.  */
+
+#ifdef __MINGW_INTRIN_INLINE
+
 #include psdk_inc/intrin-mac.h
 
 /* The Barrier functions can never be in the library.  Since gcc only
@@ -168,6 +173,30 @@
 
 #endif /* __INTRINSIC_GROUP_WINNT */
 
+#ifdef __INTRINSIC_GROUP_WINBASE
+#undef __INTRINSIC_GROUP_WINBASE /* Remove this for efficiency if intrin-impl.h is included again */
+
+/* Note that this gets undefined at the end of this file */
+#define __INTRINSIC_ONLYSPECIAL
+
+#define __INTRINSIC_SPECIAL__InterlockedIncrement
+#define __INTRINSIC_SPECIAL__InterlockedDecrement
+#define __INTRINSIC_SPECIAL__InterlockedExchange
+#define __INTRINSIC_SPECIAL__InterlockedExchangeAdd
+#define __INTRINSIC_SPECIAL__InterlockedCompareExchange
+#define __INTRINSIC_SPECIAL__InterlockedCompareExchangePointer
+#define __INTRINSIC_SPECIAL__InterlockedExchangePointer
+#define __INTRINSIC_SPECIAL__InterlockedAnd64
+#define __INTRINSIC_SPECIAL__InterlockedOr64
+#define __INTRINSIC_SPECIAL__InterlockedXor64
+#define __INTRINSIC_SPECIAL__InterlockedIncrement64
+#define __INTRINSIC_SPECIAL__InterlockedDecrement64
+#define __INTRINSIC_SPECIAL__InterlockedExchange64
+#define __INTRINSIC_SPECIAL__InterlockedExchangeAdd64
+#define __INTRINSIC_SPECIAL__InterlockedCompareExchange64
+
+#endif /* __INTRINSIC_GROUP_WINBASE */
+
 /* To add an additional group, put the #ifdef and definitions here. */
 
 #endif /* __INTRINSIC_ONLYSPECIAL */
@@ -633,3 +662,5 @@
 #undef __INTRINSIC_PROLOG
 #undef __INTRINSIC_EPILOG
 #undef __INTRINSICS_USEINLINE
+
+#endif /* __MINGW_INTRIN_INLINE */
Index: mingw-w64-headers/include/winbase.h
===
--- mingw-w64-headers/include/winbase.h	(revision 5968)
+++ mingw-w64-headers/include/winbase.h	(working copy)
@@ -11,6 +11,9 @@
 #include apisetcconv.h
 #include winapifamily.h
 
+#define __INTRINSIC_GROUP_WINBASE /* only define the intrinsics in this file */
+#include psdk_inc/intrin-impl.h
+
 #ifdef __cplusplus
 extern C {
 #endif
@@ -977,21 +980,21 @@
 #define InterlockedCompareExchangeAcquire64 InterlockedCompareExchange64
 #define InterlockedCompareExchangeRelease64 InterlockedCompareExchange64
 
-  LONG  __cdecl _InterlockedIncrement(LONG volatile *Addend);
-  LONG  __cdecl _InterlockedDecrement(LONG volatile *Addend);
-  LONG  __cdecl _InterlockedExchange(LONG volatile *Target,LONG Value);
-  LONG  __cdecl _InterlockedExchangeAdd(LONG volatile *Addend,LONG Value);
-  LONG  __cdecl _InterlockedCompareExchange(LONG volatile *Destination,LONG ExChange,LONG Comperand);
-  PVOID  __cdecl _InterlockedCompareExchangePointer(PVOID volatile *Destination,PVOID Exchange,PVOID Comperand);
-  PVOID  __cdecl _InterlockedExchangePointer(PVOID volatile *Target,PVOID Value);
-  LONG64  __cdecl _InterlockedAnd64(LONG64 volatile *Destination,LONG64 Value);
-  LONG64  __cdecl _InterlockedOr64(LONG64 volatile *Destination,LONG64 Value);
-  LONG64  __cdecl _InterlockedXor64(LONG64 volatile *Destination,LONG64 Value);
-  LONG64  __cdecl _InterlockedIncrement64(LONG64 volatile *Addend);
-  LONG64  __cdecl _InterlockedDecrement64(LONG64 volatile *Addend);
-  LONG64  __cdecl _InterlockedExchange64(LONG64 volatile *Target,LONG64 Value);
-  LONG64  __cdecl _InterlockedExchangeAdd64(LONG64 volatile *Addend,LONG64 Value);
-  LONG64  __cdecl _InterlockedCompareExchange64(LONG64 volatile *Destination,LONG64 ExChange,LONG64 Comperand);
+  /* LONG  __cdecl _InterlockedIncrement(LONG volatile *Addend); moved to psdk_inc/intrin-impl.h */
+  /* LONG  __cdecl _InterlockedDecrement(LONG volatile *Addend); moved to psdk_inc/intrin-impl.h */
+  /* LONG  __cdecl _InterlockedExchange(LONG volatile *Target,LONG Value); moved to psdk_inc/intrin-impl.h */
+  /* LONG  __cdecl _InterlockedExchangeAdd(LONG volatile *Addend,LONG Value); moved to psdk_inc/intrin-impl.h */
+  /* LONG  __cdecl _InterlockedCompareExchange(LONG volatile *Destination,LONG ExChange,LONG Comperand); moved to psdk_inc/intrin-impl.h */
+  /* PVOID  __cdecl _InterlockedCompareExchangePointer(PVOID volatile *Destination,PVOID Exchange,PVOID Comperand); moved

[Mingw-w64-public] InterlockedIncrement boost (yes, again) -What's the right answer here?

2013-07-20 Thread dw

So, Erik was kind enough to try re-running some of his builds with the 
latest patches to winbase.h.  With a bit of tweaking to the patch, x86 
now builds.  While I haven't checked it in yet, these DLLIMPORT things 
are fixed.


Unfortunately, x64 does not build correctly.  If you want to see the raw 
details:


Error log: http://fpaste.org/26679/42789171/raw/
-E output from one of the failing files: 
http://vanpienbroek.nl/SaslFactory.obj
The important source file is 
http://svn.boost.org/svn/boost/trunk/boost/detail/interlocked.hpp. It is 
currently using the definitions from line 143.


To save you the time, the problem is that for x64, they are NOT 
including winbase.h (which MSDN 
http://msdn.microsoft.com/en-us/library/ms683614%28v=VS.85%29.aspx 
says is where the def exists).  They are (as before) using their own 
def.  Since they are not using our headers, the intrinsics are not 
available, and the mapping from the PSDK function to the intrinsic 
(which is what MS does for x64) isn't done.


This used to work before my patch because intrincs/ilockinc.c used to 
(incorrectly, in my opinion) have definitions for both the intrinsic 
(_InterlockedIncrement) and the PSDK (InterlockedIncrement).  Now it 
only has _InterlockedIncrement. FYI, while MSDN says that this function 
is in kernel32.lib, that is only true for x86.


So, that's what's happening.  Now, what do we do about it?  A few 
alternatives that occur to me (in no particular order).


Boost could:
1) Use winbase.h (via windows.h) like the MSDN docs say they should.  In 
fact, I wonder if defining BOOST_USE_WINDOWS_H would work.
2) In the #if defined(__MINGW64__) block just above, they could add 
these underscore defines along with #include intrin.h.
3) They could probably just add the defines for the underscores to the 
__MINGW64__ block.  Unlike 1  2, this would NOT get them the inlines, 
but would resolve from the library like it did before.


Or, we could:
4) Add InterlockedIncrement back to ilockinc.c (likewise for the other 
half dozen or so functions here), probably using alias.


An argument could be made that we have broken backward compatibility and 
it's our responsibility to fix it.  On the other hand, one could say 
they are using our library incorrectly (by not including any of our 
headers), and the fact that it worked at all was a fluke and 
inconsistent with the MSDN docs.


Making things work like they did before (#4) causes the fewest problems 
for boost.  1  2 are cleaner fixes that will help boost produce better 
code, and keep our own code cleaner, but might irritate the boost folks 
(and possibly others).


I'm (reluctantly) prepared to add the defs back to the library if that 
seems like the right thing to do.  But I could use some guidance about 
what the right thing to do is.


dw
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Interlocked* patches follow-up

2013-07-18 Thread dw



this issue seems t be related to a bug fixed for gcc' trunk and for 
the 4.8 branch.

Could  you test more recent version to see if issue remains?



Umm.  Hmm.  Ok, well, the compiler now does (silently) pick one of the 
two defined implementations and uses it consistently.  I'd be interested 
to know exactly what the rule is here for what it picks.


In the meantime, there's the question of what we do now.  Jacek's patch 
still gives errors under certain circumstances.  How about something 
like this (attached)?  Note that WINBASEAPI is just dllimport.


This gets us back to always_inline if we can use inlines, and uses 
dllimport as a fallback.


dw
Index: mingw-w64-headers/include/winbase.h
===
--- mingw-w64-headers/include/winbase.h (revision 5955)
+++ mingw-w64-headers/include/winbase.h (working copy)
@@ -995,6 +995,14 @@
 
 #else /* not ia64, nor x64.  */
 
+  /* While MS resolves these from kernel32.dll, we are mapping them to 
intrinsics. If we can. */
+
+ /* GCC in version = 4.8.1 can't inline functions that have dllimport 
attribute. This may cause an error in
+  * combination with always_inline. Even if we don't explicitly use dllimport, 
some users have their own 
+  * declarations.  If the compiler supports it, we'll use the always_inline 
(for best performance), otherwise
+  * we'll use the DLLIMPORT (for max compatibility). */
+#if !defined(__GNUC__) || __MINGW_GNUC_PREREQ(4, 9) || (__MINGW_GNUC_PREREQ(4, 
8)  __GNUC_PATCHLEVEL__ = 2)
+
   LONG WINAPI InterlockedIncrement(LONG volatile *lpAddend);
   LONG WINAPI InterlockedDecrement(LONG volatile *lpAddend);
   LONG WINAPI InterlockedExchange(LONG volatile *Target,LONG Value);
@@ -1002,9 +1010,6 @@
   LONG WINAPI InterlockedCompareExchange(LONG volatile *Destination,LONG 
Exchange,LONG Comperand);
   LONGLONG WINAPI InterlockedCompareExchange64(LONGLONG volatile 
*Destination,LONGLONG Exchange,LONGLONG Comperand);
 
-
-  /* While MS resolves these from kernel32.dll, we are mapping them to 
intrinsics. */
-#ifdef __MINGW_INTRIN_INLINE
   __MINGW_INTRIN_INLINE LONG WINAPI InterlockedIncrement(LONG volatile 
*lpAddend) {
   return _InterlockedIncrement(lpAddend);
   }
@@ -1023,8 +1028,18 @@
   __MINGW_INTRIN_INLINE LONGLONG WINAPI InterlockedCompareExchange64(LONGLONG 
volatile *Destination, LONGLONG Exchange, LONGLONG Comperand) {
   return _InterlockedCompareExchange64(Destination, Exchange, Comperand);
   }
-#endif /* __MINGW_INTRIN_INLINE */
 
+#else
+
+  WINBASEAPI LONG WINAPI InterlockedIncrement(LONG volatile *lpAddend);
+  WINBASEAPI LONG WINAPI InterlockedDecrement(LONG volatile *lpAddend);
+  WINBASEAPI LONG WINAPI InterlockedExchange(LONG volatile *Target,LONG Value);
+  WINBASEAPI LONG WINAPI InterlockedExchangeAdd(LONG volatile *Addend,LONG 
Value);
+  WINBASEAPI LONG WINAPI InterlockedCompareExchange(LONG volatile 
*Destination,LONG Exchange,LONG Comperand);
+  WINBASEAPI LONGLONG WINAPI InterlockedCompareExchange64(LONGLONG volatile 
*Destination,LONGLONG Exchange,LONGLONG Comperand);
+
+#endif
+
 #define InterlockedExchangePointer(Target,Value) 
(PVOID)InterlockedExchange((PLONG)(Target),(LONG)(Value))
 
 /* While MS resolves these 3 from kernel32.dll, we are mapping them
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Interlocked* patches follow-up

2013-07-18 Thread dw



I can confirm that with GCC 4.9. In cause of our headers, it always 
chooses inline version, which is good.


That is the best possible outcome.  For this particular situation. But 
it's possible that's not always the case.


What with normal implementations, inline implementations, dllimport 
implementations, weak attribute, etc, I'm not sure I know which one the 
compiler may pick for any given symbol.  I'm hoping there's some sort of 
precedence list.


Why don't you add WINBASEAPI to GCC version independent declaration 


You mean something more like this (attached)?


add version guard only to the part that currently checks
__CRT__NO_INLINE to avoid duplication?


I'm not sure we are looking at the same code.  Since I'm using 
__MINGW_INTRIN_INLINE (which is what is currently checked in), I don't 
have a check for __CRT__NO_INLINE.  In fact, I removed the check for 
__MINGW_INTRIN_INLINE.  If that's important, then intrin-impl.h needs to 
be updated as well.



I'd hope for better fallback on older (well, all currently released) GCC
versions, but I'm out of ideas now.


Between the gcc bug and people copying prototypes locally, there was 
only so much we could do.


dw
Index: mingw-w64-headers/include/winbase.h
===
--- mingw-w64-headers/include/winbase.h (revision 5962)
+++ mingw-w64-headers/include/winbase.h (working copy)
@@ -995,16 +995,20 @@
 
 #else /* not ia64, nor x64.  */
 
-  LONG WINAPI InterlockedIncrement(LONG volatile *lpAddend);
-  LONG WINAPI InterlockedDecrement(LONG volatile *lpAddend);
-  LONG WINAPI InterlockedExchange(LONG volatile *Target,LONG Value);
-  LONG WINAPI InterlockedExchangeAdd(LONG volatile *Addend,LONG Value);
-  LONG WINAPI InterlockedCompareExchange(LONG volatile *Destination,LONG 
Exchange,LONG Comperand);
-  LONGLONG WINAPI InterlockedCompareExchange64(LONGLONG volatile 
*Destination,LONGLONG Exchange,LONGLONG Comperand);
+  /* While MS resolves these from kernel32.dll, we are mapping them to 
intrinsics. If we can. */
+  WINBASEAPI LONG WINAPI InterlockedIncrement(LONG volatile *lpAddend);
+  WINBASEAPI LONG WINAPI InterlockedDecrement(LONG volatile *lpAddend);
+  WINBASEAPI LONG WINAPI InterlockedExchange(LONG volatile *Target,LONG Value);
+  WINBASEAPI LONG WINAPI InterlockedExchangeAdd(LONG volatile *Addend,LONG 
Value);
+  WINBASEAPI LONG WINAPI InterlockedCompareExchange(LONG volatile 
*Destination,LONG Exchange,LONG Comperand);
+  WINBASEAPI LONGLONG WINAPI InterlockedCompareExchange64(LONGLONG volatile 
*Destination,LONGLONG Exchange,LONGLONG Comperand);
 
+ /* GCC in version = 4.8.1 can't inline functions that have dllimport 
attribute. This may cause an error in
+  * combination with always_inline. Even if we don't explicitly use dllimport, 
some users have their own 
+  * declarations.  If the compiler supports it, we'll use the always_inline 
(for best performance), otherwise
+  * we'll use the DLLIMPORT (for max compatibility). */
+#if !defined(__GNUC__) || __MINGW_GNUC_PREREQ(4, 9) || (__MINGW_GNUC_PREREQ(4, 
8)  __GNUC_PATCHLEVEL__ = 2)
 
-  /* While MS resolves these from kernel32.dll, we are mapping them to 
intrinsics. */
-#ifdef __MINGW_INTRIN_INLINE
   __MINGW_INTRIN_INLINE LONG WINAPI InterlockedIncrement(LONG volatile 
*lpAddend) {
   return _InterlockedIncrement(lpAddend);
   }
@@ -1023,8 +1027,9 @@
   __MINGW_INTRIN_INLINE LONGLONG WINAPI InterlockedCompareExchange64(LONGLONG 
volatile *Destination, LONGLONG Exchange, LONGLONG Comperand) {
   return _InterlockedCompareExchange64(Destination, Exchange, Comperand);
   }
-#endif /* __MINGW_INTRIN_INLINE */
 
+#endif
+
 #define InterlockedExchangePointer(Target,Value) 
(PVOID)InterlockedExchange((PLONG)(Target),(LONG)(Value))
 
 /* While MS resolves these 3 from kernel32.dll, we are mapping them
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Interlocked* patches follow-up

2013-07-18 Thread dw


 you are changing Interlocked*() calls to system DLL
 functions into inline functions

This is true.  If you are using x86, non-underscore versions (ie 
InterlockedExchange vs _InterlockedExchange) of these 6 functions.

 I hope this is disabled by default / __MINGW_INTRIN_INLINE is undefined
 by default.

Why?  What problems do you envision?

 To me this looks like trading future proof solution for speed.

Since MS has omitted these functions from the x64 version of 
kernel32.dll and replaced them with inline versions, I'm not clear what 
future problems you are expecting.

dw


--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Interlocked* patches follow-up

2013-07-17 Thread dw


Kai, can you offer some compiler insight here?


Something is getting tangled here, but I'm not quite sure what.


I can't reproduce it here. It looks like a GCC bug, but I'm not 
familiar with those constprop symbols. Maybe Kai will have some idea.


I've had someone else try, and they see the same error.  Here's the code 
I'm using http://privatepaste.com/a27ce89f72. Compile for x86 with -Os 
-fwhole-program.  Remove the -fwhole-program and it works.


Even when this works, the inline code for InterlockedExchange is 
included in the exe AND there is a dependency on kernel32.dll.  This 
fact makes me really uncomfortable.  We're actually defining 2 
implementations for the same function.  And the compiler isn't just 
picking one, it's somehow trying to use both.


I worry that even if we discover a work-around for this specific issue, 
it seems like we're trying to trick the compiler into doing something it 
normally forbids.  That seldom ends well.


I'd like to see this work.  But I'm starting to lean back towards just 
using the imports for x86.


dw
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___
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] _bittest, _bittestandset, etc

2013-07-17 Thread dw


Ping.

These have nothing to do with the boost/Interlocked* issues.

dw

On 7/15/2013 2:37 PM, dw wrote:

1) Move these functions to intrin-impl.h:

_bittest, _bittest64
_bittestandset, _bittestandreset, _bittestandcomplement
_bittestandset64, _bittestandreset64, _bittestandcomplement64

2) Update inline asm code:

*a) Remove memory clobber*.
*b) Remove volatile keyword.*
c) Several changes to inputs, outputs, and constraints.
d) add cc clobber.
e) Use symbolic names.
f) Support both att and intel asm formats.

dw 


--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Interlocked* patches follow-up

2013-07-16 Thread dw




Please review the new patch


Well, we got your good news and your bad news.

On the plus side, this patch fixes the problem I was seeing with -Os.  
On the downside, my release build script also uses -fwhole-program.  
This is giving me a link error:


/undefined reference to `_imp__InterlockedExchange@8.constprop.0'/

I'm using 4.8.1.  The minimal set of compile switches to see this 
problems seems to be: -Os -fwhole-program


Examining the object files with a hex editor, I see that -O1 (which 
works) has symbols for both _InterlockedExchange@8 and 
__imp__InterlockedExchange@8.  -Os has 
_InterlockedExchange@8.constprop.0 and 
__imp__InterlockedExchange@8.constprop.0.


Something is getting tangled here, but I'm not quite sure what.

dw
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Interlocked* patches follow-up


 Let's get rid of empty files.

Ok by me.

Since my automake isn't up to creating .in files, I was going to wait 
until I was sure I wasn't going to have any more before asking someone 
to help.  I'm aware of at least one more file that needs to have this 
done (intrincs\membarrier.c is not an intrinsic, it is a macro defined 
in winnt.h).

 Inline functions are better way for forwarding calls, esp. in this case.

Ok by me, but shouldn't you do all 6?

dw

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [Patch] _bittest, _bittestandset, etc


1) Move these functions to intrin-impl.h:

_bittest, _bittest64
_bittestandset, _bittestandreset, _bittestandcomplement
_bittestandset64, _bittestandreset64, _bittestandcomplement64

2) Update inline asm code:

*a) Remove memory clobber*.
*b) Remove volatile keyword.*
c) Several changes to inputs, outputs, and constraints.
d) add cc clobber.
e) Use symbolic names.
f) Support both att and intel asm formats.

dw
Index: mingw-w64-crt/intrincs/bittest.c
===
--- mingw-w64-crt/intrincs/bittest.c(revision 5952)
+++ mingw-w64-crt/intrincs/bittest.c(working copy)
@@ -1,11 +1,4 @@
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL__bittest // Causes code generation in intrin-impl.h
+
 #include intrin.h
-
-unsigned char _bittest(__LONG32 const *Base, __LONG32 Offset)
-{
-  int old = 0;
-  __asm__ __volatile__(btl %2,%1\n\tsbbl %0,%0 
-   :=r (old),=m ((*(volatile __LONG32 *) Base))
-   :Ir (Offset) : memory);
-  return (old != 0);
-}
-
Index: mingw-w64-crt/intrincs/bittest64.c
===
--- mingw-w64-crt/intrincs/bittest64.c  (revision 5952)
+++ mingw-w64-crt/intrincs/bittest64.c  (working copy)
@@ -1,11 +1,4 @@
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL__bittest64 // Causes code generation in 
intrin-impl.h
+
 #include intrin.h
-
-unsigned char _bittest64(__int64 const *Base, __int64 Offset)
-{
-  int old = 0;
-  __asm__ __volatile__(btq %2,%1\n\tsbbl %0,%0 
-:=r (old),=m ((*(volatile long long *) Base))
-:Ir (Offset) : memory);
-  return (old != 0);
-}
-
Index: mingw-w64-crt/intrincs/bittestc.c
===
--- mingw-w64-crt/intrincs/bittestc.c   (revision 5952)
+++ mingw-w64-crt/intrincs/bittestc.c   (working copy)
@@ -1,11 +1,4 @@
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL__bittestandcomplement // Causes code generation in 
intrin-impl.h
+
 #include intrin.h
-
-unsigned char _bittestandcomplement(__LONG32 *Base, __LONG32 Offset)
-{
-  int old = 0;
-  __asm__ __volatile__(btcl %2,%1\n\tsbbl %0,%0 
-:=r (old),=m ((*(volatile __LONG32 *) Base))
-:Ir (Offset) : memory);
-  return (old != 0);
-}
-
Index: mingw-w64-crt/intrincs/bittestc64.c
===
--- mingw-w64-crt/intrincs/bittestc64.c (revision 5952)
+++ mingw-w64-crt/intrincs/bittestc64.c (working copy)
@@ -1,11 +1,4 @@
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL__bittestandcomplement64 // Causes code generation 
in intrin-impl.h
+
 #include intrin.h
-
-unsigned char _bittestandcomplement64(__int64 *Base, __int64 Offset)
-{
-  int old = 0;
-  __asm__ __volatile__(btcq %2,%1\n\tsbbl %0,%0 
-:=r (old),=m ((*(volatile long long *) Base))
-:Ir (Offset) : memory);
-  return (old != 0);
-}
-
Index: mingw-w64-crt/intrincs/bittestr.c
===
--- mingw-w64-crt/intrincs/bittestr.c   (revision 5952)
+++ mingw-w64-crt/intrincs/bittestr.c   (working copy)
@@ -1,11 +1,4 @@
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL__bittestandreset // Causes code generation in 
intrin-impl.h
+
 #include intrin.h
-
-unsigned char _bittestandreset(__LONG32 *Base, __LONG32 Offset)
-{
-  int old = 0;
-  __asm__ __volatile__(btrl %2,%1\n\tsbbl %0,%0 
-:=r (old),=m ((*(volatile __LONG32 *) Base))
-:Ir (Offset) : memory);
-  return (old != 0);
-}
-
Index: mingw-w64-crt/intrincs/bittestr64.c
===
--- mingw-w64-crt/intrincs/bittestr64.c (revision 5952)
+++ mingw-w64-crt/intrincs/bittestr64.c (working copy)
@@ -1,11 +1,4 @@
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL__bittestandreset64 // Causes code generation in 
intrin-impl.h
+
 #include intrin.h
-
-unsigned char _bittestandreset64(__int64 *Base, __int64 Offset)
-{
-  int old = 0;
-  __asm__ __volatile__(btrq %2,%1\n\tsbbl %0,%0 
-:=r (old),=m ((*(volatile long long *) Base))
-:Ir (Offset) : memory);
-  return (old != 0);
-}
-
Index: mingw-w64-crt/intrincs/bittests.c
===
--- mingw-w64-crt/intrincs/bittests.c   (revision 5952)
+++ mingw-w64-crt/intrincs/bittests.c   (working copy)
@@ -1,11 +1,4 @@
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL__bittestandset // Causes code generation in 
intrin-impl.h
+
 #include intrin.h
-
-unsigned char _bittestandset(__LONG32 *Base, __LONG32 Offset)
-{
-  int old = 0;
-  __asm__ __volatile__(btsl %2,%1\n\tsbbl %0,%0 
-:=r (old),=m ((*(volatile __LONG32 *) Base))
-:Ir (Offset) : memory);
-  return (old != 0);
-}
-
Index: mingw-w64-crt/intrincs/bittests64.c
===
--- mingw-w64-crt/intrincs/bittests64.c (revision 5952)
+++ mingw-w64-crt/intrincs/bittests64.c (working

Re: [Mingw-w64-public] Interlocked* patches follow-up



 Inline functions are better way for forwarding calls, esp. in this case.

 Ok by me, but shouldn't you do all 6?

Turns out your prediction of trouble came true faster than expected.

Looking at the mass build report, there are a number of errors that all 
map to these stdcall functions.  As near as I can make out, what 
happened was this:

Boost duplicated the lines declaring the prototypes for these functions 
(see http://svn.boost.org/svn/boost/trunk/boost/detail/interlocked.hpp). 
They declared these functions as DLLIMPORT.

Normally not a problem, but when I did #define InterlockedExchange 
_InterlockedExchange in winbase, suddenly their code started looking 
for an import named _imp___InterlockedExchange@8 (note the triple 
underscore) instead of _imp__InterlockedExchange@8 (double underscore).

Jacek's proposed patch (if he does all 6 stdcall functions) should 
resolve this problem.

dw

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Interlocked* patches follow-up