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

2014-11-10 Thread David Wohlferd 

Can someone who knows more about clang than I do help me out here?

snow_xmas posted a problem report to the SF forum regarding using clang with 
mingw-W64.  After a brief investigation, it became clear that the problem was 
that clang doesn't support one of the features of inline asm that gcc does.  
The hope was that the llvm people would choose to fix this, however it doesn't 
appear that's going to happen any time soon.

The checkins that introduced this problem were done over a year ago and since 
then, it has not been possible to build mingw-w64 with clang.  Because kai 
wants to continue to support clang, I have updated the code.

However, I am no clang expert, so I don't feel like I have tested this 
sufficiently.  And unfortunately, snow_xmas is no longer responding.


The code is at http://www.LimeGreenSocks.com/intrin-impl.h (full file, not a 
patch). I realize that not everyone is an inline-asm expert, but in this case 
you really don't need to be.  Building mingw-w64 with clang would be a good 
test, but I also have some test code for the various functions in intrin-impl.h 
if you want it.

Without a clang expert to verify, I'm not going to be comfortable checking this 
in.

dw

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/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 w/o thunderbird

2016-08-08 Thread David Wohlferd 
Sorry for the spam, but if this list is how patches are expected to be
sent, I've got to get this working.  I'm using gmail's web interface
instead of TB this time.  I'm also only sending 1 patch.  Fingers crossed...

ext2.patch - Fix macro pasting error and duplicate symbol names.

dw
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Clean build of mingw-w64 (ie no more warning)

2016-08-16 Thread David Wohlferd 
On 8/16/2016 7:30 AM, Martin Storsjö wrote:
> Btw,
>
> All of your mails end up sorted in the spam box by gmail (at least for
> me), citing this reason: "It has a from address in yahoo.com but has
> failed yahoo.com's required tests for authentication."
>
> As long as I remember to check the spam box, it's fine though :-)

  It's always something.  Does this address work any better?

Jacek?  Ktietz?  Where do we stand on my defines3.patch and 
dxgi2.patch?  Approved to push?

I'm rested and ready to start on the next set of patches, but I don't 
want to get too far ahead of myself.

dw



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

[Mingw-w64-public] Building mingw-w64 and include paths

2016-08-16 Thread David Wohlferd 
One of my upcoming patches is going to be a bit controversial (or maybe 
I'm just missing something).  In either case, I'm going to go ahead and 
start the discussion early.

First a bit of vocabulary.  I'm not including this because I think 
people here don't know these terms.  It's because *I* am probably using 
them wrong.  But by defining how I am using them, hopefully you will at 
least understand what I am trying to convey.

  * SourceDir - The directory that contains the git repository of all
the mingw-w64 source files
  * BuildDir - The directory into which you will be building the output
of the files in the SourceDir.
  * OutputDir - The directory into which the useful output files
(libraries, headers, etc) will be installed when running "make
install".  Its location can be specified by using --prefix on the
configure command.
  * BinutilsDir - A loose term that encompasses the system build
utilities (gcc, clang, etc) and their support files (includes, libs,
etc).

With that in mind, here's my question: When I am building mingw-w64, 
which of these directories should the compiler be searching for include 
files, and in which order?

In my view, the correct answer (in order) is SourceDir, BuildDir, and 
BinutilsDir.  OutputDir should not be searched at all.

However, that does not appear to be what is happening.  The correct 
SourceDirs and BuildDirs frequently aren't searched at all, and 
OutputDir is.  As a result, the Mingw-w64 headers you are modifying 
while working on the project aren't used during the build (IOW you end 
up using old copies) unless you explicitly copy them around before 
running make.  While this is a hassle for people maintaining mingw-w64, 
it's got to be worse for users who "grab the latest" and don't 
understand what's required to build it.

This just seems wrong.  I believe that when building mingw-w64, the 
default should be to use the mingw-64 headers first (since that's where 
the newest files will be), then BuildDir (think: generated _mingw.h), 
then BinutilsDir (for things like ia32intrin.h, etc).  OutputDir should 
not be used at all, since it is (at best) a copy of a previous (ie 
out-of-date) build.

I have a patch for makefile.am that makes things "better" (ie adding the 
appropriate -I where needed), but I assume there's more to this issue 
than I currently understand.  Since it will probably take several emails 
for even the best teachers to fix my misunderstanding here, I'm starting 
the discussion before sending the patch.

Be gentle...

dw

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

Re: [Mingw-w64-public] Implement fused multiply-add (FMA) funcitons for x86 families properly

2017-01-22 Thread David Wohlferd 
Hmm.

It seems a bit backwards to have the function that takes a 'long double' 
calling the function that takes a 'double.'  Yes, they are both the same 
size on ARM, but I think I would have gone the other way.  Plus I kinda 
like having all the implementations in one file (fmal.c).

Other than that, this looks ok to me.  Building for ARM with clang seems 
to work (although I have no way to run it).

dw

On 1/20/2017 1:57 AM, lhmouse wrote:
> The mail has been being rejected for spamming for a few hours.
> Hope it wouldn't be this time.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] intrin-impl.h: Added __popcnt16, __popcnt, and __popcnt64.

2017-02-09 Thread David Wohlferd 
On 2/9/2017 3:28 AM, Jacek Caban wrote:
> __has_builtin looks like a nice way to fix it.

Too bad gcc doesn't see the value in __has_builtin: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970

dw

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Implement fused multiply-add (FMA) funcitons for x86 families properly

2017-01-18 Thread David Wohlferd 
On 1/18/2017 5:14 AM, lhmouse wrote:
> Patch is attached.

I see that you have replaced the x86 parts for fma and fmaf with C 
code.  That seems like a good thing.  Is there some reason you can't do 
that with the ARM versions too?

Reducing the amount of platform-specific code also seems like a good thing.

> This patch removes assembly files that implement FMA on ARM and merges
> them into the corresponding C files with the same name using inline assembly.

Umm.  Hmm.

There are a number of reasons not to use inline asm (for example 
https://gcc.gnu.org/wiki/DontUseInlineAsm ).  Are you sure this is a 
good idea?

> I don't have any knowledge about ARM assembly. Those functions for ARM
> were created using my x86 assembly knowledge and the actual instructions
> are copy-n-paste'd from old .S files. I don't have an ARM compiler to test
> those functions. Please fix them should they be broken.

Yup, that's one of the downsides to using inline asm.

I'm no ARM expert, but I'm not sure about this ARM code for fmal:

+long double fmal(long double x, long double y, long double z){
+  __asm__ (
+"fmacd %2, %0, %1 \n"
+"fcpyd %0, %2 \n"
+: "+"(z)
+: "w"(x), "w"(y)
+  );

Doesn't fmacd modify %2?  That would be (y), which is listed as an input 
parameter (and therefore is read-only).  What's more, I thought fmacd 
was calculating "Fd + Fn * Fm" where the parameters were "fmacd Fd, Fn, 
Fm".  Such being the case, I would have expected "fmacd %0, %1 %2"?  I 
don't have a way to run this either, but this looks wrong.

Under the nit-picky heading:

+double fma(double x, double y, double z){
+  __asm__ (
+"fmacd %0, %1, %2 \n"
+: "+"(z)
+: "w"(x), "w"(y)
+  );

The \n is redundant.  And doesn't the + make the & redundant as well?

+float fmaf(float x, float y, float z){
+  __asm__ (
+"fmacs %0, %1, %2 \n"
+: "+"(z)
+: "t"(x), "t"(y)

The \n is redundant.  And doesn't the + make the & redundant as well?

Lastly I gotta ask: Can we use __builtin_fmal?  Or is mingw-w64 the one 
providing the implementations for these?

dw

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Implement fused multiply-add (FMA) funcitons for x86 families properly

2017-01-19 Thread David Wohlferd 
So you have decided that __builtins can't be used then?  That's too bad.

I know almost nothing about the guts of floating point, so I'm prepared 
to defer to your judgement, but here's what I think:

Let me propose an alternative for fma.c:



/**
  * 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.
  */
double fma(double x, double y, double z);

long double fmal(long double x, long double y, long double z);

double fma(double x, double y, double z){
   return (double)fmal(x, y, z);
}



In other words, remove all the platform specific code.  This (greatly) 
simplifies this file.  You were already using fmal for x86.  And it 
doesn't lose anything for ARM, since both fma() and fmal() use the exact 
same inline asm.  Why have the exact same (hard to maintain) code in 2 
places?

As for fmaf, what about:



/**
  * 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.
  */
float fmaf(float x, float y, float z);

#if defined(_ARM_) || defined(__arm__)

float fmaf(float x, float y, float z){
   __asm__ (
 "fmacs %0, %1, %2 \n"
 : "+t"(z)
 : "t"(x), "t"(y)
   );
   return z;
}

#else

long double fmal(long double x, long double y, long double z);

float fmaf(float x, float y, float z){
   return (float)fmal(x, y, z);
}

#endif



The case here is less compelling, but I assert that if fmal is 
supported, it can always be used to calculate fmaf.  If there is a 
shorter/more efficient method (such as there is with ARM), it can be 
added here.

As for fmal, I have a question about your code.  Not the implementation, 
but the design.  Looking at https://en.wikipedia.org/wiki/Long_double, 
it says "Microsoft Windows with Visual C++ also sets the processor in 
double-precision mode by default."  Since (it appears?) you aren't 
following _controlfp_s, won't this give use a different answer than fmal 
from msvcr120.dll?

More nits:

s/whecher/whether
s/#x86_Extended_Precision_Format/#x86_extended_precision_format

dw


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Clean build of mingw-w64 (ie no more warning)

2016-08-18 Thread David Wohlferd 

It's late, so just 3 quick new ones tonight:


Ok, kai signed off on these too.

So, next are the IDL files.  I (mistakenly) tried to regenerate my 
changes by just running widl against the appropriate idl file. 
Apparently the correct way is to use --with-widl on the configure line.


So I did that.  And it turned up a couple of (new) problems:

1) When building windows.foundation.idl, I get:

/mingw64/bin/widl -DBOOL=WINBOOL 
-I/c/cygwin64/src/Mingw-w64d/mingw-w64-headers/include 
-I/c/cygwin64/src/Mingw-w64d/mingw-w64-headers/direct-x/include -Icrt 
-I/c/cygwin64/src/Mingw-w64d/mingw-w64-headers/crt -h -o 
/c/cygwin64/src/Mingw-w64d/mingw-w64-headers/include/windows.foundation.h 
/c/cygwin64/src/Mingw-w64d/mingw-w64-headers/include/windows.foundation.idl
C:/cygwin64/src/Mingw-w64d/mingw-w64-headers/include/windows.foundation.idl:14: 
error: syntax error, unexpected aIDENTIFIER, expecting $end


I don't see anything particularly interesting about line 14, but 
removing the "#pragma winrt ns_prefix" allowed the build to continue.


2) The build is overwriting prsht.h with the output from prsht.idl. 
However the new prsht.h is very different.  Either prsht.idl needs a lot 
of additions, or the build needs to stop building prsht.h from the idl.


I have not attempted to fix either of these issues, since there is 
probably some history here.


What I have attempted to fix, are these (attached):

mftransform.patch - EXTERN_C is either defined as 'extern' or 'extern 
"C"'. However, this isn't really an extern (implying that the actual 
definition is elsewhere), since the code also initializes the variable. 
And we don't need 'extern "C"' since this entire section is already 
wrapped with one (part of idl generation). Using both 'extern' and 
initializing generates a warning (warning: 
'MFT_ENUM_TRANSCODE_ONLY_ATTRIBUTE' initialized and declared 'extern').


strmif.patch - There are explicit #warning statements in strmif.idl (and 
thus strmif.h) that are not conditional (ie you always get them).  I'm 
guessing this is because the code around it was manually generated 
instead of letting widl generate it from an interface definition.  I 
have removed the manual code from strmif.idl and added the interface 
definition to axextend.idl (where it seems to belong).  Reviewing this 
patch is easier if you remember that strmif.h is a generated file.


dw
diff --git a/mingw-w64-headers/include/mftransform.h b/mingw-w64-headers/include/mftransform.h
index 1663d74..4738b4a 100644
--- a/mingw-w64-headers/include/mftransform.h
+++ b/mingw-w64-headers/include/mftransform.h
@@ -701,6 +701,11 @@ void __RPC_STUB IMFTransform_ProcessMessage_Stub(
 
 #endif  /* __IMFTransform_INTERFACE_DEFINED__ */
 
+#ifdef __GNUC__
+#undef EXTERN_C
+#define EXTERN_C
+#endif
+
 EXTERN_C const DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_CLSID = {{0xc57a84c0,0x1a80,0x40a3,{0x97,0xb5,0x92,0x72,0xa4,0x3,0xc8,0xae}}, 0x01};
 EXTERN_C const DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_CATEGORY = {{0xc57a84c0,0x1a80,0x40a3,{0x97,0xb5,0x92,0x72,0xa4,0x3,0xc8,0xae}}, 0x02 };
 EXTERN_C const DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_EXATTRIBUTE_SUPPORTED = {{0x456fe843,0x3c87,0x40c0,{0x94,0x9d,0x14,0x9,0xc9,0x7d,0xab,0x2c}}, 0x01};
diff --git a/mingw-w64-headers/include/mftransform.idl b/mingw-w64-headers/include/mftransform.idl
index 9b91736..11d5988 100644
--- a/mingw-w64-headers/include/mftransform.idl
+++ b/mingw-w64-headers/include/mftransform.idl
@@ -143,6 +143,14 @@ interface IMFTransform : IUnknown
   [out] DWORD *pdwStatus);
 }
 
+/* In gcc, declaring something 'extern' and then initializing it
+   generates a warning.  */
+cpp_quote("#ifdef __GNUC__")
+cpp_quote("#undef EXTERN_C")
+cpp_quote("#define EXTERN_C")
+cpp_quote("#endif")
+cpp_quote("")
+
 cpp_quote("EXTERN_C const DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_CLSID = {{0xc57a84c0,0x1a80,0x40a3,{0x97,0xb5,0x92,0x72,0xa4,0x3,0xc8,0xae}}, 0x01};")
 cpp_quote("EXTERN_C const DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_CATEGORY = {{0xc57a84c0,0x1a80,0x40a3,{0x97,0xb5,0x92,0x72,0xa4,0x3,0xc8,0xae}}, 0x02 };")
 cpp_quote("EXTERN_C const DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_EXATTRIBUTE_SUPPORTED = {{0x456fe843,0x3c87,0x40c0,{0x94,0x9d,0x14,0x9,0xc9,0x7d,0xab,0x2c}}, 0x01};")
diff --git a/mingw-w64-headers/include/axextend.idl b/mingw-w64-headers/include/axextend.idl
index 754ca22..79e8369 100644
--- a/mingw-w64-headers/include/axextend.idl
+++ b/mingw-w64-headers/include/axextend.idl
@@ -1292,3 +1292,49 @@ interface IAMVfwCaptureDialogs : IUnknown
 [in] long data1,
 [in] long data2);
 };
+
+cpp_quote("#if (_WIN32_WINNT >= 0x0601)")
+[
+local,
+object,
+uuid(cf7b26fc-9a00-485b-8147-3e789d5e8f67),
+pointer_default(unique)
+]
+interface IAMAsyncReaderTimestampScaling : IUnknown
+{
+HRESULT GetTimestampMode(
+[out] BOOL *pfRaw);
+HRESULT SetTimestampMode(
+[in] BOOL fRaw);
+};
+
+[
+local,
+object,
+

[Mingw-w64-public] [PATCH] for sinhl()

2016-08-21 Thread David Wohlferd 

In this function:

long double sinhl(long double x)

there is a call to fabs:

  (fabs (x) > (MAXLOGL + LOGE2L)))

However, fabs doesn't take a (long double), it only takes a (double).  
Clang complains about the truncation (warning: absolute value function 
'fabs' given an argument of type 'long double' but has parameter of type 
'double' which may cause truncation of value).


Patch attached.

dw

diff --git a/mingw-w64-crt/math/sinhl.c b/mingw-w64-crt/math/sinhl.c
index f6ecef0..4db0e51 100644
--- a/mingw-w64-crt/math/sinhl.c
+++ b/mingw-w64-crt/math/sinhl.c
@@ -67,7 +67,7 @@ long double sinhl(long double x)
   if (x_class == FP_ZERO)
 return x;
   if (x_class == FP_INFINITE ||
-  (fabs (x) > (MAXLOGL + LOGE2L)))
+  (fabsl (x) > (MAXLOGL + LOGE2L)))
   {
 errno = ERANGE;
 #ifdef INFINITIES
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] for missing voids

2016-08-21 Thread David Wohlferd 

To my surprise, these two statements have (slightly) different meanings:

  STDAPI MFUnregisterPlatformFromMMCSS ();
  STDAPI MFUnregisterPlatformFromMMCSS (void);

And clang complains about it (warning: function with no prototype cannot 
use the stdcall calling convention).


I have added 'void' every place clang complained (attached).

dw

diff --git a/mingw-w64-headers/include/commctrl.h b/mingw-w64-headers/include/commctrl.h
index 23adb9e..70d00b4 100644
--- a/mingw-w64-headers/include/commctrl.h
+++ b/mingw-w64-headers/include/commctrl.h
@@ -436,7 +436,7 @@ extern "C" {
 #define ILCF_SWAP 0x1
   WINCOMMCTRLAPI WINBOOL WINAPI ImageList_Copy(HIMAGELIST himlDst,int iDst,HIMAGELIST himlSrc,int iSrc,UINT uFlags);
   WINCOMMCTRLAPI WINBOOL WINAPI ImageList_BeginDrag(HIMAGELIST himlTrack,int iTrack,int dxHotspot,int dyHotspot);
-  WINCOMMCTRLAPI void WINAPI ImageList_EndDrag();
+  WINCOMMCTRLAPI void WINAPI ImageList_EndDrag(void);
   WINCOMMCTRLAPI WINBOOL WINAPI ImageList_DragEnter(HWND hwndLock,int x,int y);
   WINCOMMCTRLAPI WINBOOL WINAPI ImageList_DragLeave(HWND hwndLock);
   WINCOMMCTRLAPI WINBOOL WINAPI ImageList_DragMove(int x,int y);
diff --git a/mingw-w64-headers/include/mfapi.h b/mingw-w64-headers/include/mfapi.h
index 94404ce..fa41c97 100644
--- a/mingw-w64-headers/include/mfapi.h
+++ b/mingw-w64-headers/include/mfapi.h
@@ -71,9 +71,9 @@ extern "C" {
 #endif
 );
 
-  STDAPI MFShutdown ();
-  STDAPI MFLockPlatform ();
-  STDAPI MFUnlockPlatform ();
+  STDAPI MFShutdown (void);
+  STDAPI MFLockPlatform (void);
+  STDAPI MFUnlockPlatform (void);
   STDAPI MFPutWorkItem2 (DWORD dwQueue, LONG Priority, IMFAsyncCallback *pCallback, IUnknown *pState);
   STDAPI MFPutWorkItemEx2 (DWORD dwQueue, LONG Priority, IMFAsyncResult *pResult);
   STDAPI MFPutWaitingWorkItem (HANDLE hEvent, LONG Priority, IMFAsyncResult *pResult, MFWORKITEM_KEY *pKey);
@@ -124,7 +124,7 @@ extern "C" {
   STDAPI MFGetWorkQueueMMCSSClass (DWORD dwWorkQueueId, LPWSTR pwszClass, DWORD *pcchClass);
   STDAPI MFGetWorkQueueMMCSSTaskId (DWORD dwWorkQueueId, LPDWORD pdwTaskId);
   STDAPI MFRegisterPlatformWithMMCSS (PCWSTR wszClass, DWORD *pdwTaskId, LONG lPriority);
-  STDAPI MFUnregisterPlatformFromMMCSS ();
+  STDAPI MFUnregisterPlatformFromMMCSS (void);
   STDAPI MFGetWorkQueueMMCSSPriority (DWORD dwWorkQueueId, LONG *lPriority);
   STDAPI MFCreateFile (MF_FILE_ACCESSMODE AccessMode, MF_FILE_OPENMODE OpenMode, MF_FILE_FLAGS fFlags, LPCWSTR pwszFileURL, IMFByteStream **ppIByteStream);
   STDAPI MFCreateTempFile (MF_FILE_ACCESSMODE AccessMode, MF_FILE_OPENMODE OpenMode, MF_FILE_FLAGS fFlags, IMFByteStream **ppIByteStream);
@@ -148,7 +148,7 @@ extern "C" {
 
 #if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_APP)
   STDAPI MFLockDXGIDeviceManager (UINT *pResetToken, IMFDXGIDeviceManager **ppManager);
-  STDAPI MFUnlockDXGIDeviceManager ();
+  STDAPI MFUnlockDXGIDeviceManager (void);
   STDAPI MFCreateDXGISurfaceBuffer (REFIID riid, IUnknown *punkSurface, UINT uSubresourceIndex, WINBOOL fBottomUpWhenLinear, IMFMediaBuffer **ppBuffer);
   STDAPI MFCreateVideoSampleAllocatorEx (REFIID riid, void **ppSampleAllocator);
   STDAPI MFCreateDXGIDeviceManager (UINT *resetToken, IMFDXGIDeviceManager **ppDeviceManager);
diff --git a/mingw-w64-headers/include/rpcdce.h b/mingw-w64-headers/include/rpcdce.h
index 289a780..5c0af03 100644
--- a/mingw-w64-headers/include/rpcdce.h
+++ b/mingw-w64-headers/include/rpcdce.h
@@ -235,7 +235,7 @@ extern "C" {
   RPCRTAPI RPC_STATUS RPC_ENTRY RpcServerUseProtseqIfExA(RPC_CSTR Protseq,unsigned int MaxCalls,RPC_IF_HANDLE IfSpec,void *SecurityDescriptor,PRPC_POLICY Policy);
   RPCRTAPI RPC_STATUS RPC_ENTRY RpcServerUseProtseqIfW(RPC_WSTR Protseq,unsigned int MaxCalls,RPC_IF_HANDLE IfSpec,void *SecurityDescriptor);
   RPCRTAPI RPC_STATUS RPC_ENTRY RpcServerUseProtseqIfExW(RPC_WSTR Protseq,unsigned int MaxCalls,RPC_IF_HANDLE IfSpec,void *SecurityDescriptor,PRPC_POLICY Policy);
-  RPCRTAPI void RPC_ENTRY RpcServerYield ();
+  RPCRTAPI void RPC_ENTRY RpcServerYield (void);
   RPCRTAPI RPC_STATUS RPC_ENTRY RpcMgmtStatsVectorFree(RPC_STATS_VECTOR **StatsVector);
   RPCRTAPI RPC_STATUS RPC_ENTRY RpcMgmtInqStats(RPC_BINDING_HANDLE Binding,RPC_STATS_VECTOR **Statistics);
   RPCRTAPI RPC_STATUS RPC_ENTRY RpcMgmtIsServerListening(RPC_BINDING_HANDLE Binding);
@@ -454,7 +454,7 @@ extern "C" {
 
   RPCRTAPI RPC_STATUS RPC_ENTRY RpcImpersonateClient(RPC_BINDING_HANDLE BindingHandle);
   RPCRTAPI RPC_STATUS RPC_ENTRY RpcRevertToSelfEx(RPC_BINDING_HANDLE BindingHandle);
-  RPCRTAPI RPC_STATUS RPC_ENTRY RpcRevertToSelf();
+  RPCRTAPI RPC_STATUS RPC_ENTRY RpcRevertToSelf(void);
   RPCRTAPI RPC_STATUS RPC_ENTRY RpcBindingInqAuthClientA(RPC_BINDING_HANDLE ClientBinding,RPC_AUTHZ_HANDLE *Privs,RPC_CSTR *ServerPrincName,unsigned __LONG32 *AuthnLevel,unsigned __LONG32 *AuthnSvc,unsigned __LONG32 *AuthzSvc);
   RPCRTAPI RPC_STATUS RPC_ENTRY RpcBindingInqAuthClientW(RPC_BINDING_HANDLE ClientBinding,RPC_AUTHZ_HANDLE *Privs,RPC_WSTR

[Mingw-w64-public] [PATCH] for push/pop macro problem

2016-08-21 Thread David Wohlferd 
Under certain circumstances, the #pragma pop_macro("__has_builtin") at 
the bottom of intrin-impl.h can be called without ever having hit the 
#pragma push_macro("__has_builtin") at the top.  Clang warns about this, 
so I have moved the push appropriately.


Patch attached.

dw

diff --git a/mingw-w64-headers/include/psdk_inc/intrin-impl.h b/mingw-w64-headers/include/psdk_inc/intrin-impl.h
index 7da3238..f8dc78f 100644
--- a/mingw-w64-headers/include/psdk_inc/intrin-impl.h
+++ b/mingw-w64-headers/include/psdk_inc/intrin-impl.h
@@ -61,6 +61,12 @@ __INTRINSICS_USEINLINE
 
 #ifdef __MINGW_INTRIN_INLINE
 
+/* Clang has support for MSVC builtins, GCC doesn't */
+#pragma push_macro("__has_builtin")
+#ifndef __has_builtin
+  #define __has_builtin(x) 0
+#endif
+
 /* These macros are used by the routines below.  While this file may be included 
multiple times, these macros only need to be defined once. */
 #ifndef _INTRIN_MAC_
@@ -80,12 +86,6 @@ __INTRINSICS_USEINLINE
 #define __FLAGCLOBBER2
 #endif
 
-/* Clang has support for MSVC builtins, GCC doesn't */
-#pragma push_macro("__has_builtin")
-#ifndef __has_builtin
-  #define __has_builtin(x) 0
-#endif
-
 /* This macro is used by __stosb, __stosw, __stosd, __stosq */
 
 /* Parameters: (FunctionName, DataType, Operator)
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] error: operator '==' has no left operand, #if (defined(_FILE_OFFSET_BITS) && (_FILE_OFFSET_BITS == 64))

2016-08-21 Thread David Wohlferd 
To get this error, I have to have a line like:

#define _FILE_OFFSET_BITS

_FILE_OFFSET_BITS should either be undefined, or be set to 32 or 64 (see 
https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html). 
'Blank' is not a valid setting.

I'm not sure where this is happening in your build, but that's what you 
need to look for.

dw

On 8/21/2016 6:15 PM, kl222 wrote:
> When I compile tiff, the following error occurred:
>
> [ 4%] Building C object libtiff/CMakeFiles/tiff.dir/tif_close.c.obj
> In file included from D:/msys32/mingw32/i686-w64-mingw32/include/io.h:169:0,
>from D:/msys32/mingw32/i686-w64-mingw32/include/fcntl.h:8,
>from
> D:/source/rabbitim/ThirdLibrary/src/tiff/libtiff/tiffiop.h:36,
>from
> D:/source/rabbitim/ThirdLibrary/src/tiff/libtiff/tif_aux.c:32:
> D:/msys32/mingw32/i686-w64-mingw32/include/_mingw_off_t.h:23:55: error:
> operator '==' has no left operand
>#if (defined(_FILE_OFFSET_BITS) && (_FILE_OFFSET_BITS == 64))
>  ^~
> In file included from
> D:/msys32/mingw32/i686-w64-mingw32/include/fcntl.h:8:0,
>from
> D:/source/rabbitim/ThirdLibrary/src/tiff/libtiff/tiffiop.h:36,
>from
> D:/source/rabbitim/ThirdLibrary/src/tiff/libtiff/tif_aux.c:32:
>
> My gcc:
>
> $ gcc -v
> Using built-in specs.
> COLLECT_GCC=D:\msys32\mingw32\bin\gcc.exe
> COLLECT_LTO_WRAPPER=D:/msys32/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.0/lto-wrapper.exe
> Target: i686-w64-mingw32
> Configured with: ../gcc-6.1.0/configure --prefix=/mingw32
> --with-local-prefix=/mingw32/local --build=i686-w64-mingw32
> --host=i686-w64-mingw32 --target=i686-w64-mingw32
> --with-native-system-header-dir=/mingw32/i686-w64-mingw32/include
> --libexecdir=/mingw32/lib --enable-bootstrap --with-arch=i686
> --with-tune=generic
> --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared
> --enable-static --enable-libatomic --enable-threads=posix
> --enable-graphite --enable-fully-dynamic-string
> --enable-libstdcxx-time=yes --disable-libstdcxx-pch
> --disable-libstdcxx-debug --disable-isl-version-check --enable-lto
> --enable-libgomp --disable-multilib --enable-checking=release
> --disable-rpath --disable-win32-registry --disable-nls --disable-werror
> --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw32
> --with-mpfr=/mingw32 --with-mpc=/mingw32 --with-isl=/mingw32
> --with-pkgversion='Rev1, Built by MSYS2 project'
> --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as
> --with-gnu-ld --disable-sjlj-exceptions --with-dwarf2
> Thread model: posix
> gcc version 6.1.0 (Rev1, Built by MSYS2 project)
>
>
> This is mingw of BUG?
>
> --
> ___
> 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] [PATCH] for missing voids

2016-08-22 Thread David Wohlferd 
On 8/21/2016 11:17 PM, Martin Storsjö wrote:
> On Sun, 21 Aug 2016, David Wohlferd wrote:
>
>> To my surprise, these two statements have (slightly) different meanings:
>>
>>   STDAPI MFUnregisterPlatformFromMMCSS ();
>>   STDAPI MFUnregisterPlatformFromMMCSS (void);
>>
>> And clang complains about it (warning: function with no prototype cannot use
>> the stdcall calling convention).
> Yes - the former means any number of parameters.

I don't think I've ever seen this used this way.  I'm ok with that.

>> I have added 'void' every place clang complained (attached).
> The patch seems fine to me, assuming these functions really take no
> parameters.

I'd be tempted to just say "stop doing that" if someone was doing this 
intentionally, but I did check.

dw

--
___
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] for push/pop macro problem

2016-08-22 Thread David Wohlferd 
On 8/21/2016 11:27 PM, Martin Storsjö wrote:
> On Sun, 21 Aug 2016, David Wohlferd wrote:
>
>> Under certain circumstances, the #pragma pop_macro("__has_builtin") at the
>> bottom of intrin-impl.h can be called without ever having hit the #pragma
>> push_macro("__has_builtin") at the top.  Clang warns about this, so I have
>> moved the push appropriately.
>>
>> Patch attached.
> The patch seems ok, although the nesting in that header isn't quite
> obvious.

True.  I thought about trying to move the 'pop' up, but quickly surrendered.

dw

--
___
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] variadic functions can't be stdcall

2016-08-22 Thread David Wohlferd 
On 8/21/2016 11:19 PM, Martin Storsjö wrote:
> On Sun, 21 Aug 2016, David Wohlferd wrote:
>
>> By definition, functions with variable numbers of parameters cannot be
>> stdcall.  Clang complains (warning: stdcall calling convention ignored on
>> variadic function).
>>
>> Attached.
> Seems ok to me. I assume GCC did the same, ignored the attribute since it
> couldn't apply? Or were these functions just inlined in all cases where
> anybody ever used them, so it never mattered?

It has to be (silently) ignoring them.

As my expert on patch etiquette, I have a question for you.  When 
posting a patch, does one traditionally include all the files that will 
be in the push?  Or do you skip the 'generated' files to make the review 
easier?

dw

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

[Mingw-w64-public] _CRTIMP

2016-08-19 Thread David Wohlferd 
My next patch is very small, but it affects a bunch of code.  Ponder it 
a bit before approving.  The goal is to fix all the warnings like this:


 warning: '_unlock_file' redeclared without dllimport attribute: 
previous dllimport ignored [-Wattributes]


This occurs because our headers use:

  _CRTIMP void __cdecl _unlock_file(FILE *_File);

and _CRTIMP is always defined like this:

#ifndef _CRTIMP
#define _CRTIMP __declspec(dllimport)
#endif

If we were *only* providing a mapping to the function in a DLL, this 
would be fine.  But we actually create an implementation of this 
function (mingw-w64-crt/stdio/mingw_lock.c).  And the implementation 
uses the same header.  Since it makes no sense to have an implementation 
tagged as dllimport, I assert that when building mingw-w64, _CRTIMP 
should always be defined as blank (attached).


dw
diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 886fcf0..e52f961 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -20,7 +20,7 @@ else
 endif
 
 AM_CPPFLAGS=-D_CRTBLD $(sysincludes)
-AM_CFLAGS=-pipe -std=gnu99 -D_WIN32_WINNT=0x0f00 @ADD_C_CXX_WARNING_FLAGS@ @ADD_C_ONLY_WARNING_FLAGS@
+AM_CFLAGS=-pipe -std=gnu99 -D_WIN32_WINNT=0x0f00 @ADD_C_CXX_WARNING_FLAGS@ @ADD_C_ONLY_WARNING_FLAGS@ -D_CRTIMP=
 AM_CXXFLAGS=@ADD_C_CXX_WARNING_FLAGS@ @ADD_CXX_ONLY_WARNING_FLAGS@
 CPPFLAGSARM32=-mfpu=vfp
 CPPFLAGS32=-m32
diff --git a/mingw-w64-crt/Makefile.in b/mingw-w64-crt/Makefile.in
index 58c05c2..746d246 100644
--- a/mingw-w64-crt/Makefile.in
+++ b/mingw-w64-crt/Makefile.in
@@ -5092,7 +5092,7 @@ top_srcdir = @top_srcdir@
 @WITHSYSROOT_FALSE@withsys = 
 @WITHSYSROOT_TRUE@withsys = --with-sysroot=@TARGET_SYSTEM_ROOT@
 AM_CPPFLAGS = -D_CRTBLD $(sysincludes)
-AM_CFLAGS = -pipe -std=gnu99 -D_WIN32_WINNT=0x0f00 @ADD_C_CXX_WARNING_FLAGS@ @ADD_C_ONLY_WARNING_FLAGS@
+AM_CFLAGS = -pipe -std=gnu99 -D_WIN32_WINNT=0x0f00 @ADD_C_CXX_WARNING_FLAGS@ @ADD_C_ONLY_WARNING_FLAGS@ -D_CRTIMP=
 AM_CXXFLAGS = @ADD_C_CXX_WARNING_FLAGS@ @ADD_CXX_ONLY_WARNING_FLAGS@
 CPPFLAGSARM32 = -mfpu=vfp
 CPPFLAGS32 = -m32
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] As obvious?

2016-08-18 Thread David Wohlferd 
Most people could probably check this patch in "as obvious."  But I 
don't really speak script, so someone better check.


BTW, don't bother trying to build --enable-warnings=4 (or higher).  Even 
with this patch, it's not going to build (not even close).


dw
diff --git a/mingw-w64-crt/configure b/mingw-w64-crt/configure
index 77d0766..af2f7ca 100755
--- a/mingw-w64-crt/configure
+++ b/mingw-w64-crt/configure
@@ -6129,13 +6129,14 @@ case $warning_level in #(
   4) :
 
 ADD_C_CXX_WARNING_FLAGS="-Wall -Wextra -Wformat -Wstrict-aliasing=2 -Wsystem-headers -Wshadow -Wmissing-declarations -Wpacked -Winline -Werror -pedantic"
-ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration -Wmissing-noreturn -Wmissing-prototypes"
-  5 ;; #(
-  *) :
+ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration -Wmissing-noreturn -Wmissing-prototypes" ;; #(
+  5) :
 
 ADD_C_CXX_WARNING_FLAGS="-Wall -Wextra -Wformat -Wstrict-aliasing=2 -Wsystem-headers -Wshadow -Wmissing-declarations -Wpacked -Wredundant-decls -Winline -Werror -Wfatal-errors -pedantic -pedantic-errors"
 ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration -Wmissing-noreturn -Wmissing-prototypes"
-;;
+;; #(
+  *) :
+ ;;
 esac
 
 
diff --git a/mingw-w64-crt/configure.ac b/mingw-w64-crt/configure.ac
index b088953..884a7ae 100644
--- a/mingw-w64-crt/configure.ac
+++ b/mingw-w64-crt/configure.ac
@@ -314,7 +314,7 @@ AS_CASE([$warning_level],
 ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration -Wmissing-noreturn -Wmissing-prototypes"],
   [4],[
 ADD_C_CXX_WARNING_FLAGS="-Wall -Wextra -Wformat -Wstrict-aliasing=2 -Wsystem-headers -Wshadow -Wmissing-declarations -Wpacked -Winline -Werror -pedantic" 
-ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration -Wmissing-noreturn -Wmissing-prototypes"]
+ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration -Wmissing-noreturn -Wmissing-prototypes"],
   [5],[
 ADD_C_CXX_WARNING_FLAGS="-Wall -Wextra -Wformat -Wstrict-aliasing=2 -Wsystem-headers -Wshadow -Wmissing-declarations -Wpacked -Wredundant-decls -Winline -Werror -Wfatal-errors -pedantic -pedantic-errors" 
 ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration -Wmissing-noreturn -Wmissing-prototypes"]
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] _CRTIMP

2016-08-22 Thread David Wohlferd 
On 8/18/2016 11:27 PM, David Wohlferd wrote:
> My next patch is very small, but it affects a bunch of code.  Ponder 
> it a bit before approving.  The goal is to fix all the warnings like 
> this:
>
>  warning: '_unlock_file' redeclared without dllimport attribute: 
> previous dllimport ignored [-Wattributes]
>
> This occurs because our headers use:
>
>   _CRTIMP void __cdecl _unlock_file(FILE *_File);
>
> and _CRTIMP is always defined like this:
>
> #ifndef _CRTIMP
> #define _CRTIMP __declspec(dllimport)
> #endif
>
> If we were *only* providing a mapping to the function in a DLL, this 
> would be fine.  But we actually create an implementation of this 
> function (mingw-w64-crt/stdio/mingw_lock.c).  And the implementation 
> uses the same header.  Since it makes no sense to have an 
> implementation tagged as dllimport, I assert that when building 
> mingw-w64, _CRTIMP should always be defined as blank (attached).

Below is the list of functions that have the problem.  Note most are in 
secapi.

.../mingw-w64-crt/misc/invalid_parameter_handler.c:21:36: warning: 
'_get_invalid_parameter_handler' redeclared without dllimport attribute: 
previous dllimport ignored [-Wattributes]
.../mingw-w64-crt/misc/invalid_parameter_handler.c:22:36: warning: 
'_set_invalid_parameter_handler' redeclared without dllimport attribute: 
previous dllimport ignored [-Wattributes]
.../mingw-w64-crt/misc/purecall.c:10:27: warning: 
'_set_purecall_handler' redeclared without dllimport attribute: previous 
dllimport ignored [-Wattributes]
.../mingw-w64-crt/secapi/_controlfp_s.c:14:17: warning: '_controlfp_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/secapi/_ctime32_s.c:7:17: warning: '_localtime32_s' 
redeclared without dllimport attribute after being referenced with dll 
linkage
.../mingw-w64-crt/secapi/_ctime32_s.c:8:17: warning: 'asctime_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/secapi/_ctime32_s.c:9:17: warning: '_ctime32_s' 
redeclared without dllimport attribute after being referenced with dll 
linkage
.../mingw-w64-crt/secapi/_ctime64_s.c:7:17: warning: '_localtime64_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/secapi/_ctime64_s.c:8:17: warning: 'asctime_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/secapi/_gmtime32_s.c:8:17: warning: '_gmtime32_s' 
redeclared without dllimport attribute after being referenced with dll 
linkage
.../mingw-w64-crt/secapi/_gmtime64_s.c:8:17: warning: '_gmtime64_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/secapi/_localtime32_s.c:8:17: warning: 
'_localtime32_s' redeclared without dllimport attribute after being 
referenced with dll linkage
.../mingw-w64-crt/secapi/_localtime64_s.c:8:17: warning: 
'_localtime64_s' redeclared without dllimport attribute: previous 
dllimport ignored [-Wattributes]
.../mingw-w64-crt/secapi/_sopen_s.c:6:17: warning: '_sopen_s' redeclared 
without dllimport attribute: previous dllimport ignored [-Wattributes]
.../mingw-w64-crt/secapi/_wasctime_s.c:7:17: warning: '_wasctime_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/secapi/_wctime32_s.c:7:17: warning: '_localtime32_s' 
redeclared without dllimport attribute after being referenced with dll 
linkage
.../mingw-w64-crt/secapi/_wctime32_s.c:8:17: warning: '_wasctime_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/secapi/_wctime32_s.c:9:17: warning: '_wctime32_s' 
redeclared without dllimport attribute after being referenced with dll 
linkage
.../mingw-w64-crt/secapi/_wctime64_s.c:7:17: warning: '_localtime64_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/secapi/_wctime64_s.c:8:17: warning: '_wasctime_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/secapi/_wctime64_s.c:9:17: warning: '_wctime64_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/secapi/asctime_s.c:7:17: warning: 'asctime_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/secapi/memcpy_s.c:6:17: warning: 'memcpy_s' redeclared 
without dllimport attribute: previous dllimport ignored [-Wattributes]
.../mingw-w64-crt/secapi/memmove_s.c:6:17: warning: 'memmove_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/secapi/strerror_s.c:7:17: warning: 'strerror_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/stdio/mingw_lock.c:35:14: warning: '_lock_file

Re: [Mingw-w64-public] Building mingw-w64 and include paths

2016-08-22 Thread David Wohlferd 
Let's try this again.  This time the proposed patch is attached which 
may help.  For 'ease of review,' this patch does not include the 
'generated' makefile.in files.


The problem I am trying to fix is that when building mingw-w64, the 
compiler will often use headers from the Tools Directories instead of 
the mingw-w64 source directory.  This is due to the fact that while some 
mingw-w64 SourceDir paths are passed to the compiler, several are not.  
This causes 3 problems:


1) In order for me to make and test changes to intrin.h (for example), I 
have to remember to copy it to ToolsDir after every change.


2) Users who want to build mingw-w64 have to *know* that they need to 
copy certain files (from a variety of locations) to their ToolsDir 
before trying to build mingw-w64.  While the build may succeed without 
this, the results will be uncertain.


3) Header files that are in ToolsDir are usually treated as 'System 
Headers' (https://gcc.gnu.org/onlinedocs/cpp/System-Headers.html). Among 
other things, this means that warnings in these files tend to get 
suppressed rather than found and fixed.


While there are multiple ways to fix this, I have chosen to add the 
necessary paths to Makefile.am.  I also needed to duplicate 2 files 
(_mingw_directx.h _mingw_ddk.h) into appropriately named directories so 
that _mingw.h's #include "sdks/_mingw_directx.h" would work (Is there a 
better way to resolve this?  I can't just generate them into the sdks 
directory, since 'distribution' needs them where they are.).


Kai has suggested that we modify the configure script to copy all the 
header files to a single directory (a la 'make install') and use that 
single directory instead of the 9 above.  My scripting skills are not 
sufficient to do this.  If this is how we want to proceed, someone else 
will need to write it.


dw
diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 886fcf0..67ac481 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -11,6 +11,9 @@
 
 #AUTOMAKE_OPTIONS = color-tests
 
+extra_include2=-I$(top_srcdir)/../mingw-w64-headers/include -I$(top_srcdir)/../mingw-w64-headers/crt -I../mingw-w64-headers/crt
+extra_includeDX=-I$(top_srcdir)/../mingw-w64-headers/direct-x/include
+
 if WITHSYSROOT
   sysincludes=-I@TARGET_SYSTEM_ROOT@/include
   withsys=--with-sysroot=@TARGET_SYSTEM_ROOT@
@@ -19,7 +22,7 @@ else
   withsys=
 endif
 
-AM_CPPFLAGS=-D_CRTBLD $(sysincludes)
+AM_CPPFLAGS=-D_CRTBLD $(extra_include2) $(sysincludes)
 AM_CFLAGS=-pipe -std=gnu99 -D_WIN32_WINNT=0x0f00 @ADD_C_CXX_WARNING_FLAGS@ @ADD_C_ONLY_WARNING_FLAGS@
 AM_CXXFLAGS=@ADD_C_CXX_WARNING_FLAGS@ @ADD_CXX_ONLY_WARNING_FLAGS@
 CPPFLAGSARM32=-mfpu=vfp
@@ -422,7 +425,7 @@ else
 crt32_DATA =
 endif
 
-COMPILE32=$(COMPILE) $(CPPFLAGS32) $(extra_include) -D_SYSCRT=1 -DCRTDLL=1
+COMPILE32=$(COMPILE) $(CPPFLAGS32) $(extra_include) $(extra_include2) -D_SYSCRT=1 -DCRTDLL=1
 lib32/crt1.o: crt/crtexe.c
 	$(COMPILE32) -c $< -o $@ -D__CRTDLL__ -U__MSVCRT__
 lib32/crt2.o: crt/crtexe.c
@@ -463,111 +466,111 @@ if !W32API
 lib32_LIBRARIES += lib32/libmsvcrt.a
 lib32_libmsvcrt_a_SOURCES = $(src_msvcrt32) lib32/msvcrt.def.in
 lib32_libmsvcrt_a_AR = $(DTDEF32) lib32/msvcrt.def && $(AR) $(ARFLAGS)
-lib32_libmsvcrt_a_CPPFLAGS=$(CPPFLAGS32) -D__LIBMSVCRT__ $(extra_include) $(sysincludes)
+lib32_libmsvcrt_a_CPPFLAGS=$(CPPFLAGS32) -D__LIBMSVCRT__ $(extra_include) $(extra_include2) $(sysincludes)
 EXTRA_lib32_libmsvcrt_a_DEPENDENCIES=lib32/msvcrt.def
 endif
 
 lib32_LIBRARIES += lib32/libshell32.a
 lib32_libshell32_a_SOURCES = $(src_libshell32)
 lib32_libshell32_a_AR = $(DTLIB32) && $(AR) $(ARFLAGS)
-lib32_libshell32_a_CPPFLAGS=$(CPPFLAGS32) $(sysincludes)
+lib32_libshell32_a_CPPFLAGS=$(CPPFLAGS32) $(extra_include2) $(sysincludes)
 
 lib32_LIBRARIES += lib32/libdinput.a
 lib32_libdinput_a_SOURCES = $(src_libdinput)
 lib32_libdinput_a_AR = $(DTLIB32) && $(AR) $(ARFLAGS)
-lib32_libdinput_a_CPPFLAGS=$(CPPFLAGS32) $(sysincludes)
+lib32_libdinput_a_CPPFLAGS=$(CPPFLAGS32) $(extra_include2) $(sysincludes)
 
 lib32_LIBRARIES += lib32/libdinput8.a
 lib32_libdinput8_a_SOURCES = $(src_libdinput8)
 lib32_libdinput8_a_AR = $(DTLIB32) && $(AR) $(ARFLAGS)
-lib32_libdinput8_a_CPPFLAGS=$(CPPFLAGS32) $(sysincludes)
+lib32_libdinput8_a_CPPFLAGS=$(CPPFLAGS32) $(extra_include2) $(sysincludes)
 
 lib32_LIBRARIES += lib32/libdmoguids.a
 lib32_libdmoguids_a_SOURCES = $(src_libdmoguids)
-lib32_libdmoguids_a_CPPFLAGS=$(CPPFLAGS32) $(sysincludes)
+lib32_libdmoguids_a_CPPFLAGS=$(CPPFLAGS32) $(extra_include2) $(sysincludes)
 
 lib32_LIBRARIES += lib32/libdxerr8.a
 lib32_libdxerr8_a_SOURCES = $(src_libdxerr8)
-lib32_libdxerr8_a_CPPFLAGS=$(CPPFLAGS32) $(sysincludes)
+lib32_libdxerr8_a_CPPFLAGS=$(CPPFLAGS32) $(extra_include2) $(sysincludes)
 
 lib32_LIBRARIES += lib32/libdxerr9.a
 lib32_libdxerr9_a_SOURCES = $(src_libdxerr9)
-lib32_libdxerr9_a_CPPFLAGS=$(CPPFLAGS32) $(sysincludes)
+lib32_libdxerr9_a_CPPFLAGS=$(CPPFLAGS32) $(extra_include2)

[Mingw-w64-public] [PATCH] Fix prototype for _difftime32 & _difftime64

2016-08-24 Thread David Wohlferd 

Use correct prototype for _difftime32 & _difftime64.

Note that time.h already uses the correct prototype.

Question: Could the intent here have been to treat the (normally) signed 
__time32_t as unsigned in an attempt to squeeze more life out of it (the 
'2038' problem)?  If so, 'tricking' the compiler by having mismatched 
headers seems the wrong way to achieve this. Not to mention that this 
approach has other problems 
(https://en.wikipedia.org/wiki/Year_2038_problem#Solutions).


dw

diff --git a/mingw-w64-crt/misc/difftime32.c b/mingw-w64-crt/misc/difftime32.c
index 9eb3ecf..b893944 100644
--- a/mingw-w64-crt/misc/difftime32.c
+++ b/mingw-w64-crt/misc/difftime32.c
@@ -1,8 +1,8 @@
-double _difftime32(unsigned int _Time1,unsigned int _Time2);
+#include 
 
-double _difftime32(unsigned int _Time1,unsigned int _Time2)
+double __cdecl _difftime32(__time32_t _Time1,__time32_t _Time2)
 {
-  unsigned int r = _Time1 - _Time2;
+  __time32_t r = _Time1 - _Time2;
   if (r > _Time1)
 return -((double) (_Time2 - _Time1));
   return (double) r;
diff --git a/mingw-w64-crt/misc/difftime64.c b/mingw-w64-crt/misc/difftime64.c
index d50006b..54f9a12 100644
--- a/mingw-w64-crt/misc/difftime64.c
+++ b/mingw-w64-crt/misc/difftime64.c
@@ -1,8 +1,8 @@
-double _difftime64(unsigned long long _Time1,unsigned long long _Time2);
+#include 
 
-double _difftime64(unsigned long long _Time1,unsigned long long _Time2)
+double __cdecl _difftime64(__time64_t _Time1,__time64_t _Time2)
 {
-  unsigned long long r = _Time1 - _Time2;
+  __time64_t r = _Time1 - _Time2;
   if (r > _Time1)
 return -((double) (_Time2 - _Time1));
   return (double) r;
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] redeclared without dllimport warnings

2016-08-25 Thread David Wohlferd 
The thing that started the _SECIMP work was a whole bunch of "redeclared 
without dllimport attribute: previous dllimport ignored" warnings.  
While the _SECIMP work (coming soon) will fix most of them, there are a 
few others that still give this warning.


This patch fixes the places that DON'T use _SECIMP.

dw

diff --git a/mingw-w64-crt/misc/invalid_parameter_handler.c b/mingw-w64-crt/misc/invalid_parameter_handler.c
index edcdede..972b859 100644
--- a/mingw-w64-crt/misc/invalid_parameter_handler.c
+++ b/mingw-w64-crt/misc/invalid_parameter_handler.c
@@ -1,3 +1,4 @@
+#define _CRTIMP
 #include 
 
 typedef void (__cdecl *_invalid_parameter_handler)(const wchar_t *,const wchar_t *,const wchar_t *,unsigned int,uintptr_t);
diff --git a/mingw-w64-crt/misc/purecall.c b/mingw-w64-crt/misc/purecall.c
index 39be174..8c29e67 100644
--- a/mingw-w64-crt/misc/purecall.c
+++ b/mingw-w64-crt/misc/purecall.c
@@ -4,6 +4,7 @@
  * No warranty is given; refer to the file DISCLAIMER.PD within this package.
  */
 
+#define _CRTIMP
 #include 
 #include 
 
diff --git a/mingw-w64-crt/stdio/mingw_lock.c b/mingw-w64-crt/stdio/mingw_lock.c
index e62fe03..fe31780 100644
--- a/mingw-w64-crt/stdio/mingw_lock.c
+++ b/mingw-w64-crt/stdio/mingw_lock.c
@@ -1,3 +1,4 @@
+#define _CRTIMP
 #include 
 #include 
 #include "internal.h"
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] wchar.h missing functions

2016-08-25 Thread David Wohlferd 

In mingw-w64-headers/crt/time.h there is some code that does:

 #ifndef _WTIME_DEFINED
 #define _WTIME_DEFINED

After that, it defines a number of functions.

mingw-w64-headers/crt/wchar.h has this same #if block, using that exact 
same define, but it defines fewer functions.  So if you include time.h 
first, you get all the functions.  But if you include wchar.h first, you 
never get the prototypes for the extra functions, even if you later 
include time.h.


This patch makes sure you get the same list of functions no matter which 
file you include first.


dw

diff --git a/mingw-w64-headers/crt/wchar.h b/mingw-w64-headers/crt/wchar.h
index 88cb24c..9265d0b 100644
--- a/mingw-w64-headers/crt/wchar.h
+++ b/mingw-w64-headers/crt/wchar.h
@@ -913,12 +913,17 @@ int vsnwprintf (wchar_t *__stream, size_t __n, const wchar_t *__format, __builti
 #define _WTIME_DEFINED
 
   _CRTIMP wchar_t *__cdecl _wasctime(const struct tm *_Tm);
+  _CRTIMP errno_t __cdecl _wasctime_s (wchar_t *_Buf,size_t _SizeInWords,const struct tm *_Tm);
   wchar_t *__cdecl _wctime32(const __time32_t *_Time) __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
+  _CRTIMP errno_t __cdecl _wctime32_s (wchar_t *_Buf,size_t _SizeInWords,const __time32_t *_Time);
   size_t __cdecl wcsftime(wchar_t * __restrict__ _Buf,size_t _SizeInWords,const wchar_t * __restrict__ _Format,const struct tm * __restrict__ _Tm);
   _CRTIMP size_t __cdecl _wcsftime_l(wchar_t * __restrict__ _Buf,size_t _SizeInWords,const wchar_t * __restrict__ _Format,const struct tm * __restrict__ _Tm,_locale_t _Locale);
   _CRTIMP wchar_t *__cdecl _wstrdate(wchar_t *_Buffer) __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
+  _CRTIMP errno_t __cdecl _wstrdate_s (wchar_t *_Buf,size_t _SizeInWords);
   _CRTIMP wchar_t *__cdecl _wstrtime(wchar_t *_Buffer) __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
+  _CRTIMP errno_t __cdecl _wstrtime_s (wchar_t *_Buf,size_t _SizeInWords);
   _CRTIMP wchar_t *__cdecl _wctime64(const __time64_t *_Time) __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
+  _CRTIMP errno_t __cdecl _wctime64_s (wchar_t *_Buf,size_t _SizeInWords,const __time64_t *_Time);
 
 #if !defined (RC_INVOKED) && !defined (_INC_WTIME_INL)
 #define _INC_WTIME_INL
@@ -931,6 +936,19 @@ int vsnwprintf (wchar_t *__stream, size_t __n, const wchar_t *__format, __builti
 #endif
 #endif /* __CRT__NO_INLINE */
 #endif
+
+#if !defined (RC_INVOKED) && !defined (_INC_WTIME_S_INL)
+#define _INC_WTIME_S_INL
+  errno_t __cdecl _wctime_s(wchar_t *, size_t, const time_t *);
+#ifndef __CRT__NO_INLINE
+#ifndef _USE_32BIT_TIME_T
+  __CRT_INLINE errno_t __cdecl _wctime_s (wchar_t *_Buffer,size_t _SizeInWords,const time_t *_Time) { return _wctime64_s (_Buffer,_SizeInWords,_Time); }
+#else
+  __CRT_INLINE errno_t __cdecl _wctime_s (wchar_t *_Buffer,size_t _SizeInWords,const time_t *_Time) { return _wctime32_s (_Buffer,_SizeInWords,_Time); }
+#endif /* _USE_32BIT_TIME_T */
+#endif  /* __CRT__NO_INLINE */
+#endif /* !defined (RC_INVOKED) && !defined (_INC_WTIME_S_INL) */
+
 #endif
 
   typedef int mbstate_t;
--
___
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 1/4] winstorecompat: Add a GetStartupInfo stub

2016-09-08 Thread David Wohlferd 
On 9/8/2016 10:36 AM, Hugo Beauzée-Luyssen wrote:
> This only happens when building with -lwindowsapp (see another patch of
> mine). When building with the default -lkernel32, all is good, since
> kernel32.lib contains GetStartupInfo.
> windowsapp.lib, on the other hand, doesn't; which makes sense since the
> symbol is forbidden.
> Since the issue only happens when building test program within
> configure, it seemed ok to add a stub for it.

I'm not opposed to the idea of a stub for GetStartupInfo.  I assume your 
plan is to add it to libwindowsapp.a?  I'm guessing the idea is we want 
to avoid having to customize the startup code and that sounds like a 
good idea.

I'm also thinking some comments to explain what is going on for future 
maintainers might be a good idea.  Cuz this is gonna look a bit odd (ie 
why are we calling a function that doesn't do anything?).

If the expectation is that the code never gets called, it may even make 
sense to have the stub call abort() (or its winstore-appropriate 
equivalent) instead of the memset.  Configure doesn't actually run any 
of the programs it builds, does it?

dw

--
___
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 1/4] winstorecompat: Add a GetStartupInfo stub

2016-09-08 Thread David Wohlferd 
On 9/7/2016 2:19 PM, Hugo Beauzée-Luyssen wrote:
>> Is this to deal with the fact that __tmainCRTStartup uses it?
> Exactly. In the end, the function won't be used since __tmainCRTStartup
> won't be used for a windows store app, but we still need the configure
> scripts to be able to compile executables.

I haven't experimented with winstore.  What configure parameters are you 
using?

dw

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

2016-09-25 Thread David Wohlferd 

Fixes this warning which occurs when wchar_t is used:

.../mingw-w64-crt/misc/dirent.c:121:3: warning: 'memset' used with 
length equal to number of elements without multiplication by element 
size [-Wmemset-elt-size]

   memset (nd->dd_dir.d_name, 0, 260 /*FILENAME_MAX*/);

Push?

dw

diff --git a/mingw-w64-crt/misc/dirent.c b/mingw-w64-crt/misc/dirent.c
index f1ee0a2..4897cf4 100644
--- a/mingw-w64-crt/misc/dirent.c
+++ b/mingw-w64-crt/misc/dirent.c
@@ -118,7 +118,7 @@ _topendir (const _TCHAR *szPath)
   nd->dd_dir.d_ino = 0;
   nd->dd_dir.d_reclen = 0;
   nd->dd_dir.d_namlen = 0;
-  memset (nd->dd_dir.d_name, 0, 260 /*FILENAME_MAX*/);
+  memset (nd->dd_dir.d_name, 0, 260 * sizeof(nd->dd_dir.d_name[0])  /*FILENAME_MAX*/);
 
   return nd;
 }
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Duplicate symbols in libuuid.a

2016-09-29 Thread David Wohlferd 
Just those few?  How about the rest of extras-uuid.c?  The only ones 
that don't look like dupes are:

DEFINE_GUID(IID_IEnumSTATURL,0x3c374a42,0xbae4,0x11cf,0xbf,0x7d,0,0xaa,0,0x69,0x46,0xee);
DEFINE_GUID(IID_IHttpNegotiate,0x79eac9d2,0xbaf9,0x11ce,0x8c,0x82,0,0xaa,0,0x4b,0xa9,0xb);
DEFINE_GUID(IID_IUrlHistoryStg,0x3c374a41,0xbae4,0x11cf,0xbf,0x7d,0,0xaa,0,0x69,0x46,0xee);
DEFINE_GUID(IID_IWinInetHttpInfo,0x79eac9d8,0xbafa,0x11ce,0x8c,0x82,0,0xaa,0,0x4b,0xa9,0xb);
DEFINE_GUID(IID_IWinInetInfo,0x79eac9d6,0xbafa,0x11ce,0x8c,0x82,0,0xaa,0,0x4b,0xa9,0xb);

dw


On 9/29/2016 8:39 AM, LaurentP wrote:
>
> In latest git (tested with MSYS2) The following UUIDs are defined both
> in uuid.c and extra-uuid.c leading to links failures with duplicate
> symbols when using libuuid.a :
>
> // file:, local: Asychronous Pluggable Protocol Handler CLSID
> DEFINE_GUID(CLSID_FileProtocol,0x79eac9e7,0xbaf9,0x11ce,0x8c,0x82,0,0xaa,0,0x4b,0xa9,0xb);
> // ftp: Asychronous Pluggable Protocol Handler CLSID
> DEFINE_GUID(CLSID_FtpProtocol,0x79eac9e3,0xbaf9,0x11ce,0x8c,0x82,0,0xaa,0,0x4b,0xa9,0xb);
> // gopher: Asychronous Pluggable Protocol Handler CLSID
> DEFINE_GUID(CLSID_GopherProtocol,0x79eac9e4,0xbaf9,0x11ce,0x8c,0x82,0,0xaa,0,0x4b,0xa9,0xb);
> // http: Asychronous Pluggable Protocol Handler CLSID
> DEFINE_GUID(CLSID_HttpProtocol,0x79eac9e2,0xbaf9,0x11ce,0x8c,0x82,0,0xaa,0,0x4b,0xa9,0xb);
> // https: Asychronous Pluggable Protocol Handler CLSID
> DEFINE_GUID(CLSID_HttpSProtocol,0x79eac9e5,0xbaf9,0x11ce,0x8c,0x82,0,0xaa,0,0x4b,0xa9,0xb);
> // mk: Asychronous Pluggable Protocol Handler CLSID
> DEFINE_GUID(CLSID_MkProtocol,0x79eac9e6,0xbaf9,0x11ce,0x8c,0x82,0,0xaa,0,0x4b,0xa9,0xb);
> // URLMoniker ProxyStub Factory CLSID
> DEFINE_GUID(CLSID_PSUrlMonProxy,0x79eac9f1,0xbaf9,0x11ce,0x8c,0x82,0,0xaa,0,0x4b,0xa9,0xb);
> // URL Moniker CLSID
> DEFINE_GUID(CLSID_StdURLMoniker,0x79eac9e0,0xbaf9,0x11ce,0x8c,0x82,0,0xaa,0,0x4b,0xa9,0xb);
>
> I've filed a ticket for that one
>
> Reagrds
>


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

Re: [Mingw-w64-public] Duplicate symbols in libuuid.a

2016-09-30 Thread David Wohlferd 

Uh oh.

While I haven't tested it, my gut says it's something like this (attached).

dw

On 9/30/2016 1:35 AM, Mateusz wrote:

Duplicates weren't issue for a long time. Look here
https://github.com/Alexpux/MINGW-packages/issues/1712#issuecomment-247562691
As Laurent noticed this issue started somewhere after rev 4680 (b028d1)
dated 2016-07-08 and 4721 (1006bb) dated 2016-08-22.
None of *uuid.c source files changed this year so it's even more strange.
crt-git package and it's sources can be found here
http://repo.msys2.org/mingw/

2016-09-30 6:58 GMT+02:00 David Wohlferd <d...@limegreensocks.com>:


Just those few?  How about the rest of extras-uuid.c?  The only ones
that don't look like dupes are:

DEFINE_GUID(IID_IEnumSTATURL,0x3c374a42,0xbae4,0x11cf,0xbf,
0x7d,0,0xaa,0,0x69,0x46,0xee);
DEFINE_GUID(IID_IHttpNegotiate,0x79eac9d2,0xbaf9,0x11ce,0x8c,0x82,0,
0xaa,0,0x4b,0xa9,0xb);
DEFINE_GUID(IID_IUrlHistoryStg,0x3c374a41,0xbae4,0x11cf,0xbf,0x7d,0,
0xaa,0,0x69,0x46,0xee);
DEFINE_GUID(IID_IWinInetHttpInfo,0x79eac9d8,0xbafa,0x11ce,0x8c,0x82,0,
0xaa,0,0x4b,0xa9,0xb);
DEFINE_GUID(IID_IWinInetInfo,0x79eac9d6,0xbafa,0x11ce,0x8c,
0x82,0,0xaa,0,0x4b,0xa9,0xb);

dw


On 9/29/2016 8:39 AM, LaurentP wrote:

In latest git (tested with MSYS2) The following UUIDs are defined both
in uuid.c and extra-uuid.c leading to links failures with duplicate
symbols when using libuuid.a :

// file:, local: Asychronous Pluggable Protocol Handler CLSID
DEFINE_GUID(CLSID_FileProtocol,0x79eac9e7,0xbaf9,0x11ce,0x8c,0x82,0,

0xaa,0,0x4b,0xa9,0xb);

// ftp: Asychronous Pluggable Protocol Handler CLSID
DEFINE_GUID(CLSID_FtpProtocol,0x79eac9e3,0xbaf9,0x11ce,0x8c,

0x82,0,0xaa,0,0x4b,0xa9,0xb);

// gopher: Asychronous Pluggable Protocol Handler CLSID
DEFINE_GUID(CLSID_GopherProtocol,0x79eac9e4,0xbaf9,0x11ce,0x8c,0x82,0,

0xaa,0,0x4b,0xa9,0xb);

// http: Asychronous Pluggable Protocol Handler CLSID
DEFINE_GUID(CLSID_HttpProtocol,0x79eac9e2,0xbaf9,0x11ce,0x8c,0x82,0,

0xaa,0,0x4b,0xa9,0xb);

// https: Asychronous Pluggable Protocol Handler CLSID
DEFINE_GUID(CLSID_HttpSProtocol,0x79eac9e5,0xbaf9,0x11ce,0x8c,0x82,0,

0xaa,0,0x4b,0xa9,0xb);

// mk: Asychronous Pluggable Protocol Handler CLSID
DEFINE_GUID(CLSID_MkProtocol,0x79eac9e6,0xbaf9,0x11ce,0x8c,

0x82,0,0xaa,0,0x4b,0xa9,0xb);

// URLMoniker ProxyStub Factory CLSID
DEFINE_GUID(CLSID_PSUrlMonProxy,0x79eac9f1,0xbaf9,0x11ce,0x8c,0x82,0,

0xaa,0,0x4b,0xa9,0xb);

// URL Moniker CLSID
DEFINE_GUID(CLSID_StdURLMoniker,0x79eac9e0,0xbaf9,0x11ce,0x8c,0x82,0,

0xaa,0,0x4b,0xa9,0xb);

I've filed a ticket for that one

Reagrds




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



diff --git a/mingw-w64-headers/include/mftransform.h b/mingw-w64-headers/include/mftransform.h
index 954c861..b7b7619 100644
--- a/mingw-w64-headers/include/mftransform.h
+++ b/mingw-w64-headers/include/mftransform.h
@@ -701,6 +701,7 @@ void __RPC_STUB IMFTransform_ProcessMessage_Stub(
 
 #endif  /* __IMFTransform_INTERFACE_DEFINED__ */
 
+#pragma push_macro("EXTERN_C")
 #if defined(__GNUC__) && !defined(__cplusplus)
 #undef EXTERN_C
 #define EXTERN_C
@@ -730,6 +731,8 @@ EXTERN_C const DECLSPEC_SELECTANY GUID MFT_HW_TIMESTAMP_WITH_QPC_Attribute = {0x
 EXTERN_C const DECLSPEC_SELECTANY GUID MFT_FIELDOFUSE_UNLOCK_Attribute = {0x8ec2e9fd,0x9148,0x410d,{0x83,0x1e,0x70,0x24,0x39,0x46,0x1a,0x8e}};
 EXTERN_C const DECLSPEC_SELECTANY GUID MFT_CODEC_MERIT_Attribute = {0x88a7cb15,0x7b07,0x4a34,{0x91,0x28,0xe6,0x4c,0x67,0x3,0xc4,0xd3}};
 EXTERN_C const DECLSPEC_SELECTANY GUID MFT_ENUM_TRANSCODE_ONLY_ATTRIBUTE = {0x111ea8cd,0xb62a,0x4bdb,{0x89,0xf6,0x67,0xff,0xcd,0xc2,0x45,0x8b}};
+#pragma pop_macro("EXTERN_C")
+
 #if (WINVER >= 0x0601)
 HRESULT WINAPI MFCreateTransformActivate(IMFActivate **ppActivate);
 #endif /*(WINVER >= 0x0601)*/
--
___
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] Revert "Avoid declaring something extern AND initializing it

2016-09-17 Thread David Wohlferd 
It took me a bit to figure out the difference between my test code 
(which requires the patch) and yours (which can't have it). It was subtle.


Try this patch (attached).

dw

On 9/16/2016 1:39 AM, Mateusz wrote:

Hello,
Since this commit I'm not able to compile Qt5 with GCC 6.1.0 and 6.2.0
errors:

In file included from
D:/msys64/mingw64/x86_64-w64-mingw32/include/mfidl.h:73:0,
  from example.cc:1:
D:/msys64/mingw64/x86_64-w64-mingw32/include/mftransform.h:709:47: error:
'selectany' attribute applies only to initialized variables with external
linkage
  EXTERN_C const DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_CLSID =
{{0xc57a84c0,0x1a80,0x40a3,{0x97,0xb5,0x92,0x72,0xa4,0x3,0xc8,0xae}}, 0x01};
^~~~



diff --git a/mingw-w64-headers/include/mftransform.h b/mingw-w64-headers/include/mftransform.h
index 4738b4a..954c861 100644
--- a/mingw-w64-headers/include/mftransform.h
+++ b/mingw-w64-headers/include/mftransform.h
@@ -701,7 +701,7 @@ void __RPC_STUB IMFTransform_ProcessMessage_Stub(
 
 #endif  /* __IMFTransform_INTERFACE_DEFINED__ */
 
-#ifdef __GNUC__
+#if defined(__GNUC__) && !defined(__cplusplus)
 #undef EXTERN_C
 #define EXTERN_C
 #endif
diff --git a/mingw-w64-headers/include/mftransform.idl b/mingw-w64-headers/include/mftransform.idl
index 11d5988..bea0182 100644
--- a/mingw-w64-headers/include/mftransform.idl
+++ b/mingw-w64-headers/include/mftransform.idl
@@ -145,7 +145,7 @@ interface IMFTransform : IUnknown
 
 /* In gcc, declaring something 'extern' and then initializing it
generates a warning.  */
-cpp_quote("#ifdef __GNUC__")
+cpp_quote("#if defined(__GNUC__) && !defined(__cplusplus)")
 cpp_quote("#undef EXTERN_C")
 cpp_quote("#define EXTERN_C")
 cpp_quote("#endif")
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] errno.h or winerror.h ?

2016-09-17 Thread David Wohlferd 
I believe the values from errno.h are intended to provide POSIX 
compatibility for the (now defunct) Windows posix subsystem.  I'd 
wouldn't expect any API from XP or later to return these values.

OTOH, I don't know how the errcclass from gcc's error_constants.h is 
actually used.  Maybe somebody is emulating posix on Windows?

dw


On 9/17/2016 1:34 PM, niXman wrote:
> Hi,
>
> I want to restore the order in 'error_constants.h'[1] file, because
> there are so many constants commented out in this file.
> But I have a difficulty: for example, with macro 'EAFNOSUPPORT'. This
> macro is defined in 'errno.h'[2] file and in 'winerror.h'(but with 'WSA'
> prefix)[3] file.
>
> I have two questions:
> 1. What macro should I use?
> 2. Why these two macros has different values?
>
>
> Thanks!
>
>
>
> [1]
> https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/config/os/mingw32-w64/error_constants.h?view=markup
> [2]
> https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/crt/errno.h#l81
> [3]
> https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/winerror.h#l1652
>

--
___
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] Revert \"Avoid declaring something extern AND initializing it

2016-09-18 Thread David Wohlferd 
I assume someone still needs to approve this before I push?

dw

On 9/18/2016 6:10 AM, Mateusz wrote:
> Hello,
> While I'm not able to reply to the mailing list directly (forgot to 
> subscribe). Please discard my patch and commit your new patch.
> Thank you for your help!
> Best regards,
> Mateusz


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

Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

2016-09-20 Thread David Wohlferd 

On 8/12/2016 5:34 AM, NightStrike wrote:

On Thu, Aug 11, 2016 at 2:05 AM, dw  wrote:

I have been told that "autoreconf -fiv" regenerates all the files using
the current version.  But after seeing the dozen files it changed and
realizing I didn't actually know what any of them were, I chickened out.

If there's something I can do to help, let me know.

Yes, that's all that is required (other than testing).  I used to use
"make distcheck" to test things, but I don't know if that still works.
You can certainly try doing that before and after in each sub project.
The thing with make distcheck is that it verifies that every
distributable file is accounted for in the build system, which isn't
always the case.  If you feel like trying that, and you get errors,
let me know.


So, I have finally gotten back to this.

To recap:  My goal is to make sure all the generated files are in sync 
with each other (for example Makefile.in should be generated by the same 
version of autoconf/automake as aclocal.m4).


As nightstrike suggested, I have tried doing "make distcheck" before 
changing anything to find any existing problems.  This produced a BUNCH 
of failures.  They all come from EXTRA_DIST in mingw-w64-crt/Makefile.am 
and fall into 2 categories:


1) The paths for the math/DFP stuff are totally messed up. Directory 
names include a version number (2.3) which our tree has removed, some 
directory names have changed (s/cmd/examples) and some have been 
re-orged (mpdecimal-2.3/fnt.c -> mpdecimal/libmpdec/fnt.c).  I think I 
have fixed all these.
2) There are currently 69 files listed that don't appear in our tree (I 
don't see them being generated either).  I have moved all of the missing 
files from EXTRA_DIST to FILES_DONT_EXIST in the attached patch to keep 
distcheck from complaining.  Also note the 27 files I've added to 
SKIPPED_FILES that *are* in our tree, but *aren't* currently listed in 
EXTRA_DIST.


Arguably both SKIPPED_FILES and FILES_DONT_EXIST should be removed from 
this file before being pushed.  They serve no purpose other than as 
documentation of something I don't understand.  Unless someone tells me 
a better use for them (like moving all of SKIPPED_FILES into 
EXTRA_DIST?).  I could really use some guidance here.


Other than this, the regen seems to be working fine.  But I want to fix 
this DFP stuff first.  Help?


dw
diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 886fcf0..2dc1678 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -1512,188 +1512,222 @@ EXTRA_DIST += revstamp.h \
   profile/COPYING \
   profile/CYGWIN_LICENSE
 
-EXTRA_DIST += math/DFP/mpdecimal-2.3/.hg_archival.txt \
-math/DFP/mpdecimal-2.3/basearith.c \
-math/DFP/mpdecimal-2.3/basearith.h \
-math/DFP/mpdecimal-2.3/bench.c \
-math/DFP/mpdecimal-2.3/bits.h \
-math/DFP/mpdecimal-2.3/cdecimal2.c \
-math/DFP/mpdecimal-2.3/cdecimal3.c \
-math/DFP/mpdecimal-2.3/CHANGELOG.txt \
-math/DFP/mpdecimal-2.3/cmd/compare.c \
-math/DFP/mpdecimal-2.3/cmd/div.c \
-math/DFP/mpdecimal-2.3/cmd/divmod.c \
-math/DFP/mpdecimal-2.3/cmd/multiply.c \
-math/DFP/mpdecimal-2.3/cmd/pow.c \
-math/DFP/mpdecimal-2.3/cmd/powmod.c \
-math/DFP/mpdecimal-2.3/cmd/README.txt \
-math/DFP/mpdecimal-2.3/cmd/shift.c \
-math/DFP/mpdecimal-2.3/cmd/sqrt.c \
-math/DFP/mpdecimal-2.3/config.h.in \
-math/DFP/mpdecimal-2.3/configure \
-math/DFP/mpdecimal-2.3/configure.in \
-math/DFP/mpdecimal-2.3/constants.c \
-math/DFP/mpdecimal-2.3/constants.h \
-math/DFP/mpdecimal-2.3/context.c \
-math/DFP/mpdecimal-2.3/convolute.c \
-math/DFP/mpdecimal-2.3/convolute.h \
-math/DFP/mpdecimal-2.3/crt.c \
-math/DFP/mpdecimal-2.3/crt.h \
-math/DFP/mpdecimal-2.3/difradix2.c \
-math/DFP/mpdecimal-2.3/difradix2.h \
-math/DFP/mpdecimal-2.3/doc/cdecimal/index.html \
-math/DFP/mpdecimal-2.3/doc/index.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/arithmetic.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/assign-convert.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/attributes.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/context.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/decimals.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/functions.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/index.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/memory.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/various.html \
-math/DFP/mpdecimal-2.3/doc/LICENSE.txt \
-math/DFP/mpdecimal-2.3/doc/objects.inv \
-math/DFP/mpdecimal-2.3/doc/search.html \
-math/DFP/mpdecimal-2.3/doc/searchindex.js \
-math/DFP/mpdecimal-2.3/doc/_static/basic.css \
-math/DFP/mpdecimal-2.3/doc/_static/default.css \
-math/DFP/mpdecimal-2.3/doc/_static/doctools.js \
-math/DFP/mpdecimal-2.3/doc/_static/file.png \
-math/DFP/mpdecimal-2.3/doc/_static/jquery.js \
-math/DFP/mpdecimal-2.3/doc/_static/minus.png \
-math/DFP/mpdecimal-2.3/doc/_static/mpdecimal-doc.css \
-math/DFP/mpdecimal-2.3/doc/_static/plus.png \
-math/DFP/mpdecimal-2.3/doc/_static/pygments.css \

Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

2016-09-22 Thread David Wohlferd 
On 9/22/2016 5:53 AM, JonY wrote:
> On 9/22/2016 20:23, JonY wrote:
>> just remove the mpdecimal directory, the dfp/*.c stuff should
>> still work, likewise for the pformat.c changes. I'm doing just that
>> since yesterday, running build tests. SF ate my GPG signed mail.
>>
>> Use format-patch -D to ommit the contents of the deleted files.
> Patch attached.

Looks good to me.

dw

--
___
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 1/4] winstorecompat: Add a GetStartupInfo stub

2016-09-22 Thread David Wohlferd 
On 9/22/2016 9:35 AM, Hugo Beauzée-Luyssen wrote:
> On 09/08/2016 08:23 PM, David Wohlferd wrote:
>> On 9/8/2016 10:36 AM, Hugo Beauzée-Luyssen wrote:
>>> This only happens when building with -lwindowsapp (see another patch of
>>> mine). When building with the default -lkernel32, all is good, since
>>> kernel32.lib contains GetStartupInfo.
>>> windowsapp.lib, on the other hand, doesn't; which makes sense since the
>>> symbol is forbidden.
>>> Since the issue only happens when building test program within
>>> configure, it seemed ok to add a stub for it.
>>
>> I'm not opposed to the idea of a stub for GetStartupInfo.  I assume your
>> plan is to add it to libwindowsapp.a?  I'm guessing the idea is we want
>> to avoid having to customize the startup code and that sounds like a
>> good idea.
>>
>> I'm also thinking some comments to explain what is going on for future
>> maintainers might be a good idea.  Cuz this is gonna look a bit odd (ie
>> why are we calling a function that doesn't do anything?).
>>
>> If the expectation is that the code never gets called, it may even make
>> sense to have the stub call abort() (or its winstore-appropriate
>> equivalent) instead of the memset.  Configure doesn't actually run any
>> of the programs it builds, does it?
>>
>> dw
>>
>> --
>>  
>>
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
> Hm, it seems my patch didn't make it to the mailing list...
> Hopefully this one will go through!

Actually, it looks like your first one went thru 
(https://sourceforge.net/p/mingw-w64/mailman/message/35385460/).

IAC, this looks much better to me, but I don't have "approve" authority.

dw

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

Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

2016-09-21 Thread David Wohlferd 

On 9/20/2016 3:39 PM, David Wohlferd wrote:

On 9/20/2016 3:01 AM, JonY wrote:

On 9/20/2016 14:29, David Wohlferd wrote:

1) The paths for the math/DFP stuff are totally messed up.
Directory names include a version number (2.3) which our tree has
removed, some directory names have changed (s/cmd/examples) and
some have been re-orged (mpdecimal-2.3/fnt.c ->
mpdecimal/libmpdec/fnt.c).  I think I have fixed all these.

The libmpdec directory (and Makefile.am entries) stuff can be removed,
I was too ambitious to support DFP, but never really had the time to
go deep.


Ahh.

So, I have removed the DFP stuff from EXTRA_DIST (attached). That's an 
easier patch and solves my distcheck problems.  That's enough for me 
to proceed.


But it sounds like you are talking about more?

If it will help, I'm willing to take a crack at removing whatever you 
say should go.  But I'm reluctant to remove things I don't understand 
without clearer instructions.  For example, are we getting rid of all 
the ENABLE_DFP experimental stuff?  Deleting all of 
mingw-w64-crt/math/DFP from the tree?  Or just 
mingw-w64-crt/math/DFP/mpdecimal?


Creating patches that delete files makes for REALLY big patches. Instead 
of me emailing the 8MB file, just pretend that the attached file also 
deletes the entire mingw-w64-crt/math/DFP/mpdecimal directory, in 
addition to removing all references to it from mingw-w64-crt/Makefile.am.


Note that it does NOT remove mingw-w64-crt/math/DFP.

So, we have:

- DFP2.patch (previous email) which just changes EXTRA_DIST to remove 
the DFP/mpdecimal stuff.
- DFP3.patch (current email) which removes the entire 
mingw-w64-crt/math/DFP/mpdecimal directory and all references to it.


I suppose the next step would be to remove the entire 
--enable-experimental=dfp.  Is that what you were proposing?  Looks like 
a much bigger change (__dfp_expansion macro? stdio\mingw_pformat.c?).


JonY, please either approve one of these patches or provide more guidance.

dw
diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 886fcf0..cc54f5b 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -71,35 +71,6 @@ _libm_dummy.c:
 
 src_libm=_libm_dummy.c
 
-lib32/DFP_src_%.dfp.obj: math/DFP/mpdecimal/libmpdec/%.c
-	$(COMPILE) $(CPPFLAGS32) -Wno-unknown-pragmas -std=gnu99 -DCONFIG_32 -DASM -DPPRO -DHAVE_GCC_ASM_FOR_X87=1 -DHAVE_INTTYPES_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRINGS_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DPACKAGE_BUGREPORT='"mpdecimal-b...@bytereef.org"' -DPACKAGE_NAME='"mpdecimal"' -DPACKAGE_STRING='"mpdecimal 2.4.0"' -DPACKAGE_TARNAME='"mpdecimal"' -DPACKAGE_URL='"http://www.bytereef.org/mpdecimal/index.html;' -DPACKAGE_VERSION='"2.4.0"' -DSIZEOF_SIZE_T=4 -DSIZEOF___UINT128_T=0 -DSTDC_HEADERS=1 -O2 -Dmpdecimal_header=\"mpdecimal-i686.h\" -c $< -o $@
-
-lib64/DFP_src_%.dfp.obj: math/DFP/mpdecimal/libmpdec/%.c
-	$(COMPILE) $(CPPFLAGS64) -Wno-unknown-pragmas -std=gnu99 -DCONFIG_64 -DASM -DHAVE_GCC_ASM_FOR_X64=1 -DHAVE_GCC_ASM_FOR_X87=1 -DHAVE_INTTYPES_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRINGS_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UINT128_T=1 -DHAVE_UNISTD_H=1 -DPACKAGE_BUGREPORT='"mpdecimal-b...@bytereef.org"' -DPACKAGE_NAME='"mpdecimal"' -DPACKAGE_STRING='"mpdecimal 2.4.0"' -DPACKAGE_TARNAME='"mpdecimal"' -DPACKAGE_URL='"http://www.bytereef.org/mpdecimal/index.html;' -DPACKAGE_VERSION='"2.4.0"' -DSIZEOF_SIZE_T=8 -DSIZEOF___UINT128_T=16 -DSTDC_HEADERS=1 -O2 -Dmpdecimal_header=\"mpdecimal-x86_64.h\" -c $< -o $@
-
-if ENABLE_DFP
-obj_dfpsrc32 = \
-lib32/DFP_src_basearith.dfp.obj lib32/DFP_src_context.dfp.obj lib32/DFP_src_constants.dfp.obj lib32/DFP_src_convolute.dfp.obj lib32/DFP_src_crt.dfp.obj \
-lib32/DFP_src_mpdecimal.dfp.obj lib32/DFP_src_mpsignal.dfp.obj lib32/DFP_src_difradix2.dfp.obj lib32/DFP_src_fnt.dfp.obj lib32/DFP_src_fourstep.dfp.obj \
-lib32/DFP_src_io.dfp.obj lib32/DFP_src_memory.dfp.obj lib32/DFP_src_numbertheory.dfp.obj lib32/DFP_src_sixstep.dfp.obj lib32/DFP_src_transpose.dfp.obj
-
-obj_dfpsrc64 = \
-lib64/DFP_src_basearith.dfp.obj lib64/DFP_src_context.dfp.obj lib64/DFP_src_constants.dfp.obj lib64/DFP_src_convolute.dfp.obj lib64/DFP_src_crt.dfp.obj \
-lib64/DFP_src_mpdecimal.dfp.obj lib64/DFP_src_mpsignal.dfp.obj lib64/DFP_src_difradix2.dfp.obj lib64/DFP_src_fnt.dfp.obj lib64/DFP_src_fourstep.dfp.obj \
-lib64/DFP_src_io.dfp.obj lib64/DFP_src_memory.dfp.obj lib64/DFP_src_numbertheory.dfp.obj lib64/DFP_src_sixstep.dfp.obj lib64/DFP_src_transpose.dfp.obj
-
-src_dfp_math = \
-math/DFP/__fpclassifyd32.c math/DFP/__fpclassifyd64.c math/DFP/__fpclassifyd128.c \
-math/DFP/__isnand32.c math/DFP/__isnand64.c math/DFP/__isnand128.c \
-math/DFP/__signbitd32.c math/DFP/__signbitd64.c math/DFP/__s

Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

2016-09-20 Thread David Wohlferd 

On 9/20/2016 3:01 AM, JonY wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 9/20/2016 14:29, David Wohlferd wrote:

1) The paths for the math/DFP stuff are totally messed up.
Directory names include a version number (2.3) which our tree has
removed, some directory names have changed (s/cmd/examples) and
some have been re-orged (mpdecimal-2.3/fnt.c ->
mpdecimal/libmpdec/fnt.c).  I think I have fixed all these.

The libmpdec directory (and Makefile.am entries) stuff can be removed,
I was too ambitious to support DFP, but never really had the time to
go deep.


Ahh.

So, I have removed the DFP stuff from EXTRA_DIST (attached).  That's an 
easier patch and solves my distcheck problems.  That's enough for me to 
proceed.


But it sounds like you are talking about more?

If it will help, I'm willing to take a crack at removing whatever you 
say should go.  But I'm reluctant to remove things I don't understand 
without clearer instructions.  For example, are we getting rid of all 
the ENABLE_DFP experimental stuff?  Deleting all of 
mingw-w64-crt/math/DFP from the tree?  Or just 
mingw-w64-crt/math/DFP/mpdecimal?


dw
diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 886fcf0..6241f76 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -1512,189 +1512,6 @@ EXTRA_DIST += revstamp.h \
   profile/COPYING \
   profile/CYGWIN_LICENSE
 
-EXTRA_DIST += math/DFP/mpdecimal-2.3/.hg_archival.txt \
-math/DFP/mpdecimal-2.3/basearith.c \
-math/DFP/mpdecimal-2.3/basearith.h \
-math/DFP/mpdecimal-2.3/bench.c \
-math/DFP/mpdecimal-2.3/bits.h \
-math/DFP/mpdecimal-2.3/cdecimal2.c \
-math/DFP/mpdecimal-2.3/cdecimal3.c \
-math/DFP/mpdecimal-2.3/CHANGELOG.txt \
-math/DFP/mpdecimal-2.3/cmd/compare.c \
-math/DFP/mpdecimal-2.3/cmd/div.c \
-math/DFP/mpdecimal-2.3/cmd/divmod.c \
-math/DFP/mpdecimal-2.3/cmd/multiply.c \
-math/DFP/mpdecimal-2.3/cmd/pow.c \
-math/DFP/mpdecimal-2.3/cmd/powmod.c \
-math/DFP/mpdecimal-2.3/cmd/README.txt \
-math/DFP/mpdecimal-2.3/cmd/shift.c \
-math/DFP/mpdecimal-2.3/cmd/sqrt.c \
-math/DFP/mpdecimal-2.3/config.h.in \
-math/DFP/mpdecimal-2.3/configure \
-math/DFP/mpdecimal-2.3/configure.in \
-math/DFP/mpdecimal-2.3/constants.c \
-math/DFP/mpdecimal-2.3/constants.h \
-math/DFP/mpdecimal-2.3/context.c \
-math/DFP/mpdecimal-2.3/convolute.c \
-math/DFP/mpdecimal-2.3/convolute.h \
-math/DFP/mpdecimal-2.3/crt.c \
-math/DFP/mpdecimal-2.3/crt.h \
-math/DFP/mpdecimal-2.3/difradix2.c \
-math/DFP/mpdecimal-2.3/difradix2.h \
-math/DFP/mpdecimal-2.3/doc/cdecimal/index.html \
-math/DFP/mpdecimal-2.3/doc/index.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/arithmetic.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/assign-convert.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/attributes.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/context.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/decimals.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/functions.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/index.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/memory.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/various.html \
-math/DFP/mpdecimal-2.3/doc/LICENSE.txt \
-math/DFP/mpdecimal-2.3/doc/objects.inv \
-math/DFP/mpdecimal-2.3/doc/search.html \
-math/DFP/mpdecimal-2.3/doc/searchindex.js \
-math/DFP/mpdecimal-2.3/doc/_static/basic.css \
-math/DFP/mpdecimal-2.3/doc/_static/default.css \
-math/DFP/mpdecimal-2.3/doc/_static/doctools.js \
-math/DFP/mpdecimal-2.3/doc/_static/file.png \
-math/DFP/mpdecimal-2.3/doc/_static/jquery.js \
-math/DFP/mpdecimal-2.3/doc/_static/minus.png \
-math/DFP/mpdecimal-2.3/doc/_static/mpdecimal-doc.css \
-math/DFP/mpdecimal-2.3/doc/_static/plus.png \
-math/DFP/mpdecimal-2.3/doc/_static/pygments.css \
-math/DFP/mpdecimal-2.3/doc/_static/searchtools.js \
-math/DFP/mpdecimal-2.3/doc/_static/sidebar.js \
-math/DFP/mpdecimal-2.3/doc/_static/underscore.js \
-math/DFP/mpdecimal-2.3/docstrings.h \
-math/DFP/mpdecimal-2.3/fnt.c \
-math/DFP/mpdecimal-2.3/fnt.h \
-math/DFP/mpdecimal-2.3/fourstep.c \
-math/DFP/mpdecimal-2.3/fourstep.h \
-math/DFP/mpdecimal-2.3/io.c \
-math/DFP/mpdecimal-2.3/io.h \
-math/DFP/mpdecimal-2.3/LIBINSTALL.txt \
-math/DFP/mpdecimal-2.3/LICENSE.txt \
-math/DFP/mpdecimal-2.3/literature/mpdecimal.lisp \
-math/DFP/mpdecimal-2.3/literature/README.txt \
-math/DFP/mpdecimal-2.3/literature/umodarith.lisp \
-math/DFP/mpdecimal-2.3/Makefile.in \
-math/DFP/mpdecimal-2.3/Makefile.vc \
-math/DFP/mpdecimal-2.3/memory.c \
-math/DFP/mpdecimal-2.3/memory.h \
-math/DFP/mpdecimal-2.3/mpdecimal-i686.h \
-math/DFP/mpdecimal-2.3/mpdecimal-x86_64.h \
-math/DFP/mpdecimal-2.3/mpdecimal.c \
-math/DFP/mpdecimal-2.3/mpdecimal.h.in \
-math/DFP/mpdecimal-2.3/mpdecimal32vc.h \
-math/DFP/mpdecimal-2.3/mpdecimal64vc.h \
-math/DFP/mpdecimal-2.3/mpsignal.c \
-math/DFP/mpdecimal-2.3/mptest.h \
-math/DFP/mpdecimal-2.3/mptypes.h \
-math/DFP/mpdecimal-2.3/numbertheory.c \
-math/DFP/mpdecimal-2.3/numbertheory.h \
-math/DFP/mpdecimal-2.3/PKG-INFO \
-math/DFP/mpdecimal-2.3/PYINSTALL.txt \
-math/

Re: [Mingw-w64-public] [PATCH 1/4] winstorecompat: Add a GetStartupInfo stub

2016-09-07 Thread David Wohlferd 
I'm confused.  Is GetStartupInfo even a winstore function?  Is this to 
deal with the fact that __tmainCRTStartup uses it?

dw

On 9/7/2016 1:31 AM, Hugo Beauzée-Luyssen wrote:
> On 09/07/2016 10:25 AM, Jacek Caban wrote:
>> Hi Hugo,
>>
>> On 06.09.2016 16:11, Hugo Beauzée-Luyssen wrote:
>>> +#define GetStartupInfo __GetStartupInfo
>>> +#include 
>>> +#undef GetStartupInfo
>>> +
>>> +VOID WINAPI GetStartupInfo( LPSTARTUPINFO lpStartupInfo )
>>> +{
>>> +(void)lpStartupInfo;
>>> +}
>>
>> Callers of this function expect passed STARTUPINFO to be filled with
>> something sane. You can't just leave it untouched, it would most likely
>> fail in runtime.
>>
>>
>> Thanks,
>>
>> Jacek
>>
>>
>> --
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
> Hi,
>
> Fair point, would 0'ing it be ok in your opinion?
>
> Regards,
>
>
> --
> ___
> 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] Building mingw-w64 and include paths

2016-08-17 Thread David Wohlferd 
Huh.  Well, that went a lot better than I thought it would...

On 8/17/2016 1:11 AM, Kai Tietz wrote:
> Hello dw,
>
> 2016-08-17 4:22 GMT+02:00 David Wohlferd <d...@limegreensocks.com>:
>> One of my upcoming patches is going to be a bit controversial (or maybe
>> I'm just missing something).  In either case, I'm going to go ahead and
>> start the discussion early.
>>
>> First a bit of vocabulary.  I'm not including this because I think
>> people here don't know these terms.  It's because *I* am probably using
>> them wrong.  But by defining how I am using them, hopefully you will at
>> least understand what I am trying to convey.
>>
>>* SourceDir - The directory that contains the git repository of all
>>  the mingw-w64 source files
>>* BuildDir - The directory into which you will be building the output
>>  of the files in the SourceDir.
>>* OutputDir - The directory into which the useful output files
>>  (libraries, headers, etc) will be installed when running "make
>>  install".  Its location can be specified by using --prefix on the
>>  configure command.
>>* BinutilsDir - A loose term that encompasses the system build
>>  utilities (gcc, clang, etc) and their support files (includes, libs,
>>  etc).
> Thanks for pointing out your nomenclature.  These names are always a
> well of misunderstanding.
>
> (I use in common instead of binutilsDir the name ToolsDir ... and for
> OutputDir the name InstallDir)

I was just making terms up.  ToolsDir and InstallDir are better. But 
hey, at least you understood what I was trying to say.

>> With that in mind, here's my question: When I am building mingw-w64,
>> which of these directories should the compiler be searching for include
>> files, and in which order?
>>
>> In my view, the correct answer (in order) is SourceDir, BuildDir, and
>> BinutilsDir.  OutputDir should not be searched at all.
> Why it shouldn't search in OutputDir?  where do you install headers & co too?

I guess I was thinking in terms of a single project.  If you only output 
mingw-w64 to (say) /home/david/mingstuff, having the next build of 
mingw-w64 look in /home/david/mingstuff seems totally pointless.  The 
only files in that directory would be old ones from the previous build.  
Almost by definition, these aren't the includes you want.

But if (as I think you are suggesting) people output headers from *all* 
their projects to a common directory, then it could make sense.  
Assuming the SourceDir directories come earlier in the search path than 
OutputDir.  We'd still want to avoid accidentally using 'old' mingw-w64 
files when building the next.

Or were you referring to your idea (discussed below) of outputting all 
the headers from the build first?

> Anyway, as we have one generated headers (_mingw.h, sdks, ...), it is
> mandatory to (atleast) configure/build headers before trying to build
> crt.
> The include paths in SourceDir are in "mingw-w64-headers/crt/", and
> "mingw-w64-headers/include".

What I'm currently using:

extra_include=-I$(top_srcdir)/include
extra_include2=-I$(top_srcdir)/../mingw-w64-headers/include 
-I$(top_srcdir)/../mingw-w64-headers/crt -I../mingw-w64-headers/crt
extra_includeDX=-I$(top_srcdir)/../mingw-w64-headers/direct-x/include

> Additional the build directory of the
> headers for the generated headers.
> In fact it is easier to install headers before, and just point to the
> include directory in OutputDir (/include for gcc)

While that could work, my understanding of configure is insufficient to 
allow me to do this.  While I have already added the -I statements to my 
Makefile.am, someone else would have to do what (I think) you are 
describing here.

>> However, that does not appear to be what is happening.  The correct
>> SourceDirs and BuildDirs frequently aren't searched at all, and
>> OutputDir is.  As a result, the Mingw-w64 headers you are modifying
>> while working on the project aren't used during the build (IOW you end
>> up using old copies) unless you explicitly copy them around before
>> running make.  While this is a hassle for people maintaining mingw-w64,
>> it's got to be worse for users who "grab the latest" and don't
>> understand what's required to build it.
> See comment above.
>
>> This just seems wrong.  I believe that when building mingw-w64, the
>> default should be to use the mingw-64 headers first (since that's where
>> the newest files will be), then BuildDir (think: generated _mingw.h),
>> then BinutilsDir (for things like ia32intrin.h, etc).  OutputDir should
>> not be used at all, since it is (at best) a copy of a previous (ie
>> out-of

Re: [Mingw-w64-public] Clean build of mingw-w64 (ie no more warning)

2016-08-18 Thread David Wohlferd 


I assume I still need to wait for someone else to approve this before 
I push? 


Kai signed off on these via IRC.

It's late, so just 3 quick new ones tonight:

e_pow.patch - Signed/unsigned compare

mingw_pformat.patch - Don't use feature (__attribute__((gcc_struct))) 
that isn't supported on clang when compiling on clang.


mfapi.patch - FCC ('AI44') et al cause 'multichar' compiler warnings. 
Ignore them.


We're getting close to done.  Some IDL changes, some configure/makefile 
changes and that's it.


dw
diff --git a/mingw-w64-crt/math/softmath/e_pow.c b/mingw-w64-crt/math/softmath/e_pow.c
index 4e56eeb..da697db 100644
--- a/mingw-w64-crt/math/softmath/e_pow.c
+++ b/mingw-w64-crt/math/softmath/e_pow.c
@@ -45,7 +45,7 @@ double bsd__ieee754_pow(double x, double y)
 k = (iy>>20)-0x3ff;	/* exponent */
 if(k>20) {
 j = ly>>(52-k);
-if((j<<(52-k))==ly) yisint = 2-(j&1);
+if((u_int32_t)(j<<(52-k))==ly) yisint = 2-(j&1);
 } else if(ly==0) {
 j = iy>>(20-k);
 if((j<<(20-k))==iy) yisint = 2-(j&1);
diff --git a/mingw-w64-crt/stdio/mingw_pformat.c b/mingw-w64-crt/stdio/mingw_pformat.c
index 0438112..445320c 100644
--- a/mingw-w64-crt/stdio/mingw_pformat.c
+++ b/mingw-w64-crt/stdio/mingw_pformat.c
@@ -77,13 +77,13 @@
 
 /* FIXME: The following belongs in values.h, but current MinGW
  * has nothing useful there!  OTOH, values.h is not a standard
- * header, and it's use may be considered obsolete; perhaps it
+ * header, and its use may be considered obsolete; perhaps it
  * is better to just keep these definitions here.
  */
 
 #include 
 /* workaround gcc bug */
-#ifdef __GNUC__
+#if defined(__GNUC__) && !defined(__clang__)
 #define ATTRIB_GCC_STRUCT __attribute__((gcc_struct))
 #else
 #define ATTRIB_GCC_STRUCT
diff --git a/mingw-w64-headers/include/mfapi.h b/mingw-w64-headers/include/mfapi.h
index 67dc684..94404ce 100644
--- a/mingw-w64-headers/include/mfapi.h
+++ b/mingw-w64-headers/include/mfapi.h
@@ -329,6 +329,12 @@ extern "C" {
   DEFINE_MEDIATYPE_GUID (MFVideoFormat_RGB555, D3DFMT_X1R5G5B5);
   DEFINE_MEDIATYPE_GUID (MFVideoFormat_RGB565, D3DFMT_R5G6B5);
   DEFINE_MEDIATYPE_GUID (MFVideoFormat_RGB8, D3DFMT_P8);
+
+#ifdef __GNUC__
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wmultichar"
+#endif
+
   DEFINE_MEDIATYPE_GUID (MFVideoFormat_AI44, FCC ('AI44'));
   DEFINE_MEDIATYPE_GUID (MFVideoFormat_AYUV, FCC ('AYUV'));
   DEFINE_MEDIATYPE_GUID (MFVideoFormat_YUY2, FCC ('YUY2'));
@@ -384,6 +390,10 @@ extern "C" {
   DEFINE_MEDIATYPE_GUID (MFVideoFormat_H263, FCC ('H263'));
 #endif
 
+#ifdef __GNUC__
+#pragma GCC diagnostic pop
+#endif
+
 #ifdef LOCAL_D3DFMT_DEFINES
 #undef D3DFMT_R8G8B8
 #undef D3DFMT_A8R8G8B8
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Clean build of mingw-w64 (ie no more warning)

2016-08-18 Thread David Wohlferd 
On 8/18/2016 4:23 AM, Martell Malone wrote:
> I would also like to point you to my selectany patch.
> You asked why that wasn't supported on clang on irc.
> https://github.com/martell/mingw-w64-clang/blob/master/patches/clang/0003-mingw-w64-enable-support-for-__declspec-selectany.patch
> This should be better then using -fms-{extensions,compat}

Excellent.  Thank you for this.

dw

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

Re: [Mingw-w64-public] DirectWrite additions

2016-08-25 Thread David Wohlferd 
So what happened here?  The winerror.h that got checked in still has the 
duplicate defines?


Is there some reason I can't remove the dupes (attached)?

dw


On 8/24/2016 9:46 AM, Jacek Caban wrote:

Hi Ruben,

I'm sorry I didn't look at this earlier.

I committed winerror.h (it seems that you included the same defines in
two different places in those patches, so please retest with committed
version) and wincodec.idl parts.

However, dwrite_2.h needs some more work. We try to provide dwrite APIs
for plain C, which makes things a bit more painful than that. You need
to add THIS (for functions with no arguments) or THIS_ macros in the
beginning of declaration of each functions. Also to preserve proper vtbl
layout, declaration of parent interface needs to be copied inside
__cplusplus guard. See other declarations for an example. Also we try to
avoid using things like _In_, _Out_ macros in our headers.

Thanks,
Jacek

On 24.08.2016 18:25, Ruben Van Boxem wrote:

I would like to reiterate my request to include the following the changes
in MinGW-w64. I have no commit rights, and Kai half-OKed them, so input
from someone in the team that can commit them directly would be greatly
appreciated!

I'll attach both patches (which are required to build Skia with MinGW-w64)
to this email for convenience. Note there were duplicate GUID's in the
previous patch, those were removed here.

Please OK and apply so I can stop keeing my custom builds of MinGW-w64
around, thanks :)

Cheers!

Ruben

2016-08-09 19:44 GMT+02:00 Ruben Van Boxem :


Hi Kai (and Jacek),

Thanks for taking a look.

Note there are two patches: one I linked to in the body of my email, the
other was attached. Both would need to be applied by someone (I don't have
commit rights).

Cheers,

Ruben

2016-08-09 10:58 GMT+02:00 Kai Tietz :


Hi Ruben,

patch looks fine to me.  As long as there are no objections (Jacek  do
you?), go ahead and apply.

Thanks,
Kai

2016-08-08 20:57 GMT+02:00 Ruben Van Boxem :

Hi guys,

it would be nice to keep up to date with new APIs that gain real world

use,

like this little patch:
https://github.com/Alexpux/mingw-w64/pull/1/commits/6c0efe37

b32510f72020e38726c7a84690a926fd

Which is now needed for Qt 5.7 (and skia).

I would also like to point out attached patch that adds various GUIDs
missing I ran into when compiling skia.

Cheers,

Ruben



--

What NetFlow Analyzer can do for you? Monitors network bandwidth and

traffic

patterns at an interface-level. Reveals which users, apps, and

protocols are

consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



--
What NetFlow Analyzer can do for you? Monitors network bandwidth and
traffic
patterns at an interface-level. Reveals which users, apps, and protocols
are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
___
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


--
___
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/include/winerror.h b/mingw-w64-headers/include/winerror.h
index 55ebd50..aee0618 100644
--- a/mingw-w64-headers/include/winerror.h
+++ b/mingw-w64-headers/include/winerror.h
@@ -3467,20 +3467,6 @@ __CRT_INLINE HRESULT HRESULT_FROM_WIN32(__LONG32 x) { return x <= 0 ? (HRESULT)x
 #define DXGI_ERROR_NAME_ALREADY_EXISTS  _HRESULT_TYPEDEF_(0x887A002C)
 #define DXGI_ERROR_SDK_COMPONENT_MISSING_HRESULT_TYPEDEF_(0x887A002D)
 
-#define DWRITE_E_FILEFORMAT   _HRESULT_TYPEDEF_(0x88985000)
-#define DWRITE_E_UNEXPECTED   _HRESULT_TYPEDEF_(0x88985001)
-#define DWRITE_E_NOFONT   _HRESULT_TYPEDEF_(0x88985002)
-#define DWRITE_E_FILENOTFOUND _HRESULT_TYPEDEF_(0x88985003)
-#define DWRITE_E_FILEACCESS

[Mingw-w64-public] [PATCH] _SECIMP patches

2016-08-25 Thread David Wohlferd 
There is an entire collection of routines in mingw-w64-crt\secapi.  
These functions replicate the functionality of a number of secure 
versions of functions (_vcprintf_s, _wstrtime_s, etc).  The idea was to 
support these functions on platforms which didn't have the necessary DLLs.


The purpose of the attached patches is to allow you to switch between 
using the internal versions, or the DLL versions.  The patches select 
the DLL versions by default.  In the (unlikely) event that you want the 
'internal' versions, build your project with '-D_SECIMP='.


And incidentally it cleans up a number of "redeclared without dllimport 
attribute: previous dllimport ignored" warnings.


secimp1.patch - A number of the secapi\*.c files (actually all of them) 
duplicate the function prototypes of the functions they implement (and 
sometimes some of the functions they use as well) instead of simply 
including the appropriate header.  This patch removes the duplicate 
definitions, and ensures that the correct headers are included.


secimp2.patch - Per Kai, these data imports are *always* resolved from 
DLLs.  Having them 'follow' _CRTIMP is incorrect.


secimp3.patch - Replace all the _CRTIMP with _SECIMP on the secure 
functions to allow them to be controlled independently of the rest of 
the library functions.  Note that while building mingw-w64 itself (aka 
defined(__LIBMSVCRT__)), _SECIMP must always be defined as blank to 
allow the internal versions to build without warnings.


dw

diff --git a/mingw-w64-crt/secapi/_access_s.c b/mingw-w64-crt/secapi/_access_s.c
index e5fea3b..9be582e 100644
--- a/mingw-w64-crt/secapi/_access_s.c
+++ b/mingw-w64-crt/secapi/_access_s.c
@@ -2,9 +2,8 @@
 #include 
 #include 
 #include 
+#include 
 
-int __cdecl _access (const char *, int);
-errno_t __cdecl _access_s (const char *, int);
 static errno_t __cdecl _int_access_s (const char *, int);
 static errno_t __cdecl _stub (const char *, int);
 
diff --git a/mingw-w64-crt/secapi/_cgets_s.c b/mingw-w64-crt/secapi/_cgets_s.c
index a5023de..e70efe7 100644
--- a/mingw-w64-crt/secapi/_cgets_s.c
+++ b/mingw-w64-crt/secapi/_cgets_s.c
@@ -1,10 +1,10 @@
+#define MINGW_HAS_SECURE_API 1
 #include 
 #include 
 #include 
 #include 
+#include 
 
-char * __cdecl _cgets (char *);
-errno_t __cdecl _cgets_s (char *, size_t, size_t *);
 static errno_t __cdecl _int_cgets_s (char *, size_t, size_t *);
 static errno_t __cdecl _stub (char *, size_t, size_t *);
 
diff --git a/mingw-w64-crt/secapi/_cgetws_s.c b/mingw-w64-crt/secapi/_cgetws_s.c
index 9380ec3..dff4187 100644
--- a/mingw-w64-crt/secapi/_cgetws_s.c
+++ b/mingw-w64-crt/secapi/_cgetws_s.c
@@ -1,10 +1,10 @@
+#define MINGW_HAS_SECURE_API 1
 #include 
 #include 
 #include 
 #include 
+#include 
 
-wchar_t * __cdecl _cgetws (wchar_t *);
-errno_t __cdecl _cgetws_s (wchar_t *, size_t, size_t *);
 static errno_t __cdecl _int_cgetws_s (wchar_t *, size_t, size_t *);
 static errno_t __cdecl _stub (wchar_t *, size_t, size_t *);
 
diff --git a/mingw-w64-crt/secapi/_chsize_s.c b/mingw-w64-crt/secapi/_chsize_s.c
index 3993199..cd8d066 100644
--- a/mingw-w64-crt/secapi/_chsize_s.c
+++ b/mingw-w64-crt/secapi/_chsize_s.c
@@ -2,9 +2,8 @@
 #include 
 #include 
 #include 
+#include 
 
-int __cdecl _chsize (int, long);
-errno_t __cdecl _chsize_s (int, long long);
 static errno_t __cdecl _int_chsize_s (int, long long);
 static errno_t __cdecl _stub (int, long long);
 
diff --git a/mingw-w64-crt/secapi/_cprintf_s.c b/mingw-w64-crt/secapi/_cprintf_s.c
index 8101bc1..36ea582 100644
--- a/mingw-w64-crt/secapi/_cprintf_s.c
+++ b/mingw-w64-crt/secapi/_cprintf_s.c
@@ -1,10 +1,9 @@
+#define MINGW_HAS_SECURE_API 1
 #include 
 #include 
 #include 
 #include 
-
-int __cdecl _cprintf_s (const char *,...);
-int __cdecl _vcprintf_s (const char *,va_list);
+#include 
 
 int __cdecl (*__MINGW_IMP_SYMBOL(_cprintf_s))(const char *,...) = 
  _cprintf_s;
diff --git a/mingw-w64-crt/secapi/_cprintf_s_l.c b/mingw-w64-crt/secapi/_cprintf_s_l.c
index 97fd4fb..316ca86 100644
--- a/mingw-w64-crt/secapi/_cprintf_s_l.c
+++ b/mingw-w64-crt/secapi/_cprintf_s_l.c
@@ -1,10 +1,9 @@
+#define MINGW_HAS_SECURE_API 1
 #include 
 #include 
 #include 
 #include 
-
-int __cdecl _cprintf_s_l (const char *, _locale_t, ...);
-int __cdecl _vcprintf_s_l(const char *,_locale_t,va_list);
+#include 
 
 int __cdecl (*__MINGW_IMP_SYMBOL(_cprintf_s_l))(const char *, _locale_t, ...) = 
  _cprintf_s_l;
diff --git a/mingw-w64-crt/secapi/_ctime32_s.c b/mingw-w64-crt/secapi/_ctime32_s.c
index 9c54914..c59ccfc 100644
--- a/mingw-w64-crt/secapi/_ctime32_s.c
+++ b/mingw-w64-crt/secapi/_ctime32_s.c
@@ -4,9 +4,6 @@
 #include 
 #include 
 
-errno_t __cdecl _localtime32_s (struct tm *, const __time32_t *);
-errno_t __cdecl asctime_s (char *, size_t, const struct tm *);
-errno_t __cdecl _ctime32_s (char *, size_t, const __time32_t *);
 static errno_t __cdecl _int_ctime32_s (char *, size_t, const __time32_t *);
 static errno_t __cdecl _stub (char *, size_t, const __time32_t *);

Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

2016-10-03 Thread David Wohlferd 

On 10/2/2016 6:38 PM, JonY wrote:

On 10/3/2016 06:37, David Wohlferd wrote:

So, my testing didn't turn up any problems.  The patch is pretty
big (1,389,398), so I have compressed it and uploaded it to
http://www.LimeGreenSocks.com/gen2.7z (where it is only 82,083).

Just a reminder: Despite the size, this is 100% regenerated code,
mostly in the build-aux directories.

Comments (especially about whether we need the beta config.guess)
welcome.  What needs to happen to get this approved to Push?



I'm sorry, I'm a bit thick.  Can you clarify?


Since it is all regenerated code, I'm OK with it.


Is this the same as "approved to push?"


config.guess is
nice, but not essential, no one has complained about unsupported
platforms, yet.


Does this mean you want to use the most-recently-released version? Or 
the beta version (which is even more recent)?  The patch I posted uses 
the released version.  But it could be that "no one has complained" 
because the beta is what is currently checked in.


While an argument can be made for either, my recommendation is to go 
with the 'released,' and only use the beta if there is a specific 
requirement.  But since "going backward" like this might break something 
(maybe someone did complain at some point?), I felt the need to ask.


My tests were with the 'released' version, but I'm prepared to re-test 
if the beta is preferred.  As the "approver," I assume you decide?


I believe that if I update config.guess, I'm supposed to update 
config.sub too (not knowing the answer to this is another reason to 
stick with the 'released' version).  I have attached a patch for 
config.guess + config.sub to show what has changed.  Note that this is 
going backwards (turning the 'beta' into the 'most recently released').


dw
diff --git a/mingw-w64-tools/widl/build-aux/config.guess b/mingw-w64-tools/widl/build-aux/config.guess
index 0967f2a..b450eb4 100755
--- a/mingw-w64-tools/widl/build-aux/config.guess
+++ b/mingw-w64-tools/widl/build-aux/config.guess
@@ -1,8 +1,8 @@
 #! /bin/sh
 # Attempt to guess a canonical system name.
-#   Copyright 1992-2016 Free Software Foundation, Inc.
+#   Copyright 1992-2014 Free Software Foundation, Inc.
 
-timestamp='2016-04-02'
+timestamp='2014-11-04'
 
 # This file is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License as published by
@@ -27,7 +27,7 @@ timestamp='2016-04-02'
 # Originally written by Per Bothner; maintained since 2000 by Ben Elliston.
 #
 # You can get the latest version of this script from:
-# http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess
+# http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
 #
 # Please send patches to <config-patc...@gnu.org>.
 
@@ -50,7 +50,7 @@ version="\
 GNU config.guess ($timestamp)
 
 Originally written by Per Bothner.
-Copyright 1992-2016 Free Software Foundation, Inc.
+Copyright 1992-2014 Free Software Foundation, Inc.
 
 This is free software; see the source for copying conditions.  There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
@@ -168,27 +168,20 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in
 	# Note: NetBSD doesn't particularly care about the vendor
 	# portion of the name.  We always set it to "unknown".
 	sysctl="sysctl -n hw.machine_arch"
-	UNAME_MACHINE_ARCH=`(uname -p 2>/dev/null || \
-	/sbin/$sysctl 2>/dev/null || \
-	/usr/sbin/$sysctl 2>/dev/null || \
-	echo unknown)`
+	UNAME_MACHINE_ARCH=`(/sbin/$sysctl 2>/dev/null || \
+	/usr/sbin/$sysctl 2>/dev/null || echo unknown)`
 	case "${UNAME_MACHINE_ARCH}" in
 	armeb) machine=armeb-unknown ;;
 	arm*) machine=arm-unknown ;;
 	sh3el) machine=shl-unknown ;;
 	sh3eb) machine=sh-unknown ;;
 	sh5el) machine=sh5le-unknown ;;
-	earmv*)
-		arch=`echo ${UNAME_MACHINE_ARCH} | sed -e 's,^e\(armv[0-9]\).*$,\1,'`
-		endian=`echo ${UNAME_MACHINE_ARCH} | sed -ne 's,^.*\(eb\)$,\1,p'`
-		machine=${arch}${endian}-unknown
-		;;
 	*) machine=${UNAME_MACHINE_ARCH}-unknown ;;
 	esac
 	# The Operating System including object format, if it has switched
 	# to ELF recently, or will in the future.
 	case "${UNAME_MACHINE_ARCH}" in
-	arm*|earm*|i386|m68k|ns32k|sh3*|sparc|vax)
+	arm*|i386|m68k|ns32k|sh3*|sparc|vax)
 		eval $set_cc_for_build
 		if echo __ELF__ | $CC_FOR_BUILD -E - 2>/dev/null \
 			| grep -q __ELF__
@@ -204,13 +197,6 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in
 		os=netbsd
 		;;
 	esac
-	# Determine ABI tags.
-	case "${UNAME_MACHINE_ARCH}" in
-	earm*)
-		expr='s/^earmv[0-9]/-eabi/;s/eb$//'
-		abi=`echo ${UNAME_MACHINE_ARCH} | sed -e "$expr"`
-		;;
-	esac
 	# The OS release
 	# Debian GNU/NetBSD machines have a differe

Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

2016-10-02 Thread David Wohlferd 
On 10/1/2016 4:37 PM, David Wohlferd wrote:
> On 9/24/2016 7:23 PM, David Wohlferd wrote:
>> On 9/24/2016 4:55 AM, NightStrike wrote:
>>> On Sep 23, 2016 8:08 PM, "David Wohlferd" <d...@limegreensocks.com> 
>>> wrote:
>>>> Ok. With that change in place, I have run
>>>>autoreconf -fiv
>>>>
>>>> in the root directory of mingw-w64.  That regenerated a bunch of 
>>>> files.
>>>>
>>>> To test this, I have run configure, make and make install for each of
>>>> x86, x64 and arm.  These all seem to build correctly.
>>>>
>>>> Nightstrike: Running "make distcheck" now runs a bit further than
>>>> before.  However:
>>>>
>>>> - For x86, all the initial checks complete, but when it tries doing 
>>>> its
>>>> own VPATH build, it fails because of include path issues (it tries to
>>>> build mingw-w64-crt in isolation from mingw-w64-headers). But since 
>>>> the
>>>> normal build succeeds, I don't believe this is a problem.
>>>> - For x64, it fails because pseh is "missing."  Obviously it is 
>>>> missing
>>>> because it's not supported on x64.  I'm not sure why distcheck doesn't
>>>> skip it.
>>>> - For arm, it fails because libmangle is missing.  Not sure how to get
>>>> it to skip this either.
>>> Use AM_DISTCHECK_CONFIGURE_FLAGS to set configure options 
>>> specifically used
>>> for the distcheck target. For instance, maybe --disable-pseh (if 
>>> that's a
>>> thing, I don't know)
>> Actually, "disabled" is the default.  If you want it to build, you must
>> explicitly enable it (--with-libraries=pseh or --with-libraries=all).
>> It's not immediately clear to me why distcheck thinks it should check
>> parts that are disabled.
>>
>> Is this important enough to track down?  Or can this patch be approved
>> without it?
>
> I was getting ready to nudge this thread to get it approved for push, 
> when I noticed something.  While running "autoreconf -fiv" does walk 
> down subdirectories, it doesn't walk ALL our subdirectories.
>
> So I tried again.
>
> This time I explicitly deleted all the build-aux directories, as well 
> as all makefile.in, configure. and aclocal.m4 to force autoreconf to 
> really regenerate them.  After running "autoreconf -fiv", I looked to 
> see which directories didn't get these files re-generated.  I then 
> changed to those directories and run "autoreconf -fiv" from there.  
> THAT got everything.
>
> Looking at the new patch, I noticed something else.  In some cases, 
> the config.guess that is being generated is OLDER than the one that is 
> checked in.  After analysis, it appears that someone (sezero?) has 
> checked in a beta version of this file in a few places.  Was this done 
> on purpose to resolve a problem?  It seems like we should either stay 
> with "released" versions, or use the same version everywhere.  Opinions?
>
> I have started re-testing, but if someone wants to shed some light on 
> this config.guess thing, I can make any needed changes before posting 
> this (increasingly large) patch.

So, my testing didn't turn up any problems.  The patch is pretty big 
(1,389,398), so I have compressed it and uploaded it to 
http://www.LimeGreenSocks.com/gen2.7z (where it is only 82,083).

Just a reminder: Despite the size, this is 100% regenerated code, mostly 
in the build-aux directories.

Comments (especially about whether we need the beta config.guess) 
welcome.  What needs to happen to get this approved to Push?

dw

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

2016-09-24 Thread David Wohlferd 
On 9/24/2016 4:55 AM, NightStrike wrote:
> On Sep 23, 2016 8:08 PM, "David Wohlferd" <d...@limegreensocks.com> wrote:
>> On 9/23/2016 5:08 AM, JonY wrote:
>>> On 9/23/2016 09:50, David Wohlferd wrote:
>>>> On 9/22/2016 5:53 AM, JonY wrote:
>>>>> On 9/22/2016 20:23, JonY wrote:
>>>>>> just remove the mpdecimal directory, the dfp/*.c stuff should
>>>>>> still work, likewise for the pformat.c changes. I'm doing just
>>>>>> that since yesterday, running build tests. SF ate my GPG signed
>>>>>> mail.
>>>>>>
>>>>>> Use format-patch -D to ommit the contents of the deleted
>>>>>> files.
>>>>> Patch attached.
>>>> Looks good to me.
>>> Done.
>> Ok.  With that change in place, I have run
>>
>>   autoreconf -fiv
>>
>> in the root directory of mingw-w64.  That regenerated a bunch of files.
>>
>> To test this, I have run configure, make and make install for each of
>> x86, x64 and arm.  These all seem to build correctly.
>>
>> Nightstrike: Running "make distcheck" now runs a bit further than
>> before.  However:
>>
>> - For x86, all the initial checks complete, but when it tries doing its
>> own VPATH build, it fails because of include path issues (it tries to
>> build mingw-w64-crt in isolation from mingw-w64-headers). But since the
>> normal build succeeds, I don't believe this is a problem.
>> - For x64, it fails because pseh is "missing."  Obviously it is missing
>> because it's not supported on x64.  I'm not sure why distcheck doesn't
>> skip it.
>> - For arm, it fails because libmangle is missing.  Not sure how to get
>> it to skip this either.
> Use AM_DISTCHECK_CONFIGURE_FLAGS to set configure options specifically used
> for the distcheck target. For instance, maybe --disable-pseh  (if that's a
> thing, I don't know)

Actually, "disabled" is the default.  If you want it to build, you must 
explicitly enable it (--with-libraries=pseh or --with-libraries=all).  
It's not immediately clear to me why distcheck thinks it should check 
parts that are disabled.

Is this important enough to track down?  Or can this patch be approved 
without it?

dw

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

Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

2016-10-01 Thread David Wohlferd 
On 9/24/2016 7:23 PM, David Wohlferd wrote:
> On 9/24/2016 4:55 AM, NightStrike wrote:
>> On Sep 23, 2016 8:08 PM, "David Wohlferd" <d...@limegreensocks.com> wrote:
>>> Ok. With that change in place, I have run
>>>autoreconf -fiv
>>>
>>> in the root directory of mingw-w64.  That regenerated a bunch of files.
>>>
>>> To test this, I have run configure, make and make install for each of
>>> x86, x64 and arm.  These all seem to build correctly.
>>>
>>> Nightstrike: Running "make distcheck" now runs a bit further than
>>> before.  However:
>>>
>>> - For x86, all the initial checks complete, but when it tries doing its
>>> own VPATH build, it fails because of include path issues (it tries to
>>> build mingw-w64-crt in isolation from mingw-w64-headers). But since the
>>> normal build succeeds, I don't believe this is a problem.
>>> - For x64, it fails because pseh is "missing."  Obviously it is missing
>>> because it's not supported on x64.  I'm not sure why distcheck doesn't
>>> skip it.
>>> - For arm, it fails because libmangle is missing.  Not sure how to get
>>> it to skip this either.
>> Use AM_DISTCHECK_CONFIGURE_FLAGS to set configure options specifically used
>> for the distcheck target. For instance, maybe --disable-pseh  (if that's a
>> thing, I don't know)
> Actually, "disabled" is the default.  If you want it to build, you must
> explicitly enable it (--with-libraries=pseh or --with-libraries=all).
> It's not immediately clear to me why distcheck thinks it should check
> parts that are disabled.
>
> Is this important enough to track down?  Or can this patch be approved
> without it?

I was getting ready to nudge this thread to get it approved for push, 
when I noticed something.  While running "autoreconf -fiv" does walk 
down subdirectories, it doesn't walk ALL our subdirectories.

So I tried again.

This time I explicitly deleted all the build-aux directories, as well as 
all makefile.in, configure. and aclocal.m4 to force autoreconf to really 
regenerate them.  After running "autoreconf -fiv", I looked to see which 
directories didn't get these files re-generated.  I then changed to 
those directories and run "autoreconf -fiv" from there.  THAT got 
everything.

Looking at the new patch, I noticed something else.  In some cases, the 
config.guess that is being generated is OLDER than the one that is 
checked in.  After analysis, it appears that someone (sezero?) has 
checked in a beta version of this file in a few places.  Was this done 
on purpose to resolve a problem?  It seems like we should either stay 
with "released" versions, or use the same version everywhere.  Opinions?

I have started re-testing, but if someone wants to shed some light on 
this config.guess thing, I can make any needed changes before posting 
this (increasingly large) patch.

dw

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Release criteria for mingw-w64 v5?

2016-10-19 Thread David Wohlferd 

> RC has been out forever without much feedback.

Ahh.  I did not know this.

Looking back thru the archive, I see the announcements came during a 
time (Feb 25 & Mar 25) when I was not following the list.  I didn't tune 
back in until July.

Of course this does raise another obvious question (see next email)...

> The regenerated auto* changes were not included, but I did include
> some recent code fixes.

That's probably a good thing.  Glad you are on top of all this.

dw

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Release criteria for mingw-w64 v6?

2016-10-19 Thread David Wohlferd 
Is there an official list of release criteria for mingw-w64 v6? Or a 
targeted release date?  I'm not seeing anything on the web site.

I have some changes I'd like to propose that only belong at the start of 
a new cycle.  But I'd like to see how they fit with the current plans.

dw


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Patch] Make build environment consistent

2016-10-17 Thread David Wohlferd 
On 10/17/2016 2:34 AM, JonY wrote:
> On 10/17/2016 10:17, David Wohlferd wrote:
>> Is that the same as "approved for push?"  Or am I still waiting to
>> hear from someone?  I'm told you are the 'makefile' approver.
>>
> Yes, you can go ahead and push.

Thank you.  Pushed.

dw

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Release criteria for mingw-w64 v5?

2016-10-18 Thread David Wohlferd 
Is there an official list of release criteria for mingw-w64 v5? Or a 
targeted release date?  I'm not seeing anything on the web site.

I have my own list of things I'm working on (~6 items) that I'd like to 
see included, assuming there is still time.  I also have a few more that 
I'd like to do, but that belong at the beginning of a release cycle.  
When does v6 begin?

dw

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Release criteria for mingw-w64 v5?

2016-10-18 Thread David Wohlferd 
On 10/18/2016 3:28 PM, JonY wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 10/19/2016 04:18, Jean-Baptiste Kempf wrote:
>> On 18 Oct, David Wohlferd wrote :
>>> Is there an official list of release criteria for mingw-w64 v5?
>>> Or a targeted release date?  I'm not seeing anything on the web
>>> site.
>> It would be nice to have a release, indeed.
>>
>> Btw, there is still the MACRO bug about IN6_IS_ADDR_MULTICAST, in
>> violation of the POSIX spec, and I'd love to get that fixed before
>> we do the 5.0 release.
>>
> It's just been released, but I have not yet announce it, I guess that
> can go into 5.0.1.

Wow.  That was... abrupt.  I didn't even know it was being considered.

Was the cutoff before or after that big checkin I just did to upgrade 
the make files?  From one point of view, I'm hoping it was included.  On 
the other hand, I would never have pushed this had I known we were just 
days away from a release.

dw

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Test

2016-11-11 Thread David Wohlferd 
Apparently there is a filter on the SF mail list.  Nightstrike had to 
specifically add something for my patches to get thru (see 
https://sourceforge.net/p/mingw-w64/mailman/message/35277894/).

dw


On 11/11/2016 2:30 AM, JonY wrote:
> On 11/11/2016 18:17, LRN wrote:
>> On 11.11.2016 13:09, JonY wrote:
>>> PGP/MIME signed message.
>>>
>> PGP/MIME signed messages rock.
>>
>>
> Looks like they show up empty in the list archives.


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

2016-10-10 Thread David Wohlferd 
On 10/8/2016 3:09 AM, Adrien Nader wrote:

> Yet, it would also be useful to know which compilers are used or we 
> are bound to repeatedly break them. Please, report in this thread if 
> you use something else than GCC or Clang.

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

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

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

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

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

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

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

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

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

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

dw

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [Patch] Make build environment consistent

2016-10-15 Thread David Wohlferd 
I have a patch to bring all the mingw-w64 build files up to the latest 
version (1.15).  Due to size, it is at 
http://www.LimeGreenSocks.com/gen2.7z and is unchanged since I posted it 
back on Oct 2.  This patch is 100% regenerated files from running 
"autoreconf -fiv" in all the directories.  While the patch has been 
debated, no one has approved it yet.

As has been discussed (see 
https://sourceforge.net/p/mingw-w64/mailman/message/35418338/), there is 
some question about whether we should be using beta versions of the 
config.guess files downloaded from the current automake build tree.

sezero has been checking in these beta versions, but no one seems to 
know why (and he hasn't responded to explain).  To be clear, the files 
currently checked in to mingw-w64 are NEWER than the most recently 
released version of automake.  A review of the differences doesn't 
reveal any obvious benefit.

I'm asking that my current patch (which does NOT use the beta files) be 
approved.  If there is a reason to use the beta files, let's do that as 
a separate checkin, along with an explanation as to WHY we are doing it.

Ok to push?

dw


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Patch] Make build environment consistent

2016-10-16 Thread David Wohlferd 
On 10/15/2016 5:04 PM, JonY wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 10/16/2016 07:21, David Wohlferd wrote:
>> I'm asking that my current patch (which does NOT use the beta
>> files) be approved.  If there is a reason to use the beta files,
>> let's do that as a separate checkin, along with an explanation as
>> to WHY we are doing it.
>>
> We can put the newer version back if someone complains.

Agreed.

> I have no strong preferences either way.

Is that the same as "approved for push?"  Or am I still waiting to hear 
from someone?  I'm told you are the 'makefile' approver.

dw

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Will be fesetenv fixed?

2016-12-19 Thread David Wohlferd 
FWIW, I agree that this code does not look right.

The purpose of fesetenv(const fenv_t * envp) is to change the settings 
of the floating point environment as specified by the parameter.  
However, instead of using the values from the parameter, the current 
code *overwrites* the passed in settings with the current settings, then 
sets using the result.  Kinda defeats the purpose.

I hesitate to offer a fix, since I'm not sure what kai was trying to fix 
with 
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/e98d8084dde3e3aba43736ee78dd7b35541df00b/

The description for his checkin ("Add a fix for working fesetenv in 
libquadmath-library") is a little vague.  Something relating to the sse 
flags perhaps?

Kai, I don't suppose you remember any more details from this (> 3 year 
old) checkin?  It was a Monday, does that help?

dw

On 12/12/2016 2:26 AM, Zidane Sama wrote:
> Fesetenv does not change fpu rounding mode. This bug already described
> in https://sourceforge.net/p/mingw-w64/bugs/541/


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Will be fesetenv fixed?

2016-12-20 Thread David Wohlferd 
Ahh, the wonders of google.  I believe I have found the problem kai's 
change was originally intended to fix: 
http://mingw-w64-public.narkive.com/jr5jMaJ2/quadmath-h-s-expq-crashes-at-runtime 



And, I believe I have found what the actual problem was.  I don't think 
what kai did was the right fix.  Let me explain why.


There is a big old structure full of obscure x87 floating point settings 
defined as fenv_t in fenv.h (make sure you don't look at the ARM 
definition by mistake).  The format of this structure is defined by the 
fldenv assembler instruction (so blame Intel).


Now, someone decided to be tricky and used some of the 'unused' data 
members of this struct to store, not just the x87 FPU settings, but also 
the SSE settings.  It does this by overwriting the __unused0 and 
__unused1 members of the struct.


So, when you call fegetenv(fenv_t * envp), what you actually get back is 
a mixture of settings for both x87 and SSE.  This isn't (normally) a 
problem, since when you call fesetenv (const fenv_t * envp), it extracts 
the SSE values back out of the struct, puts back the normal 'default' 
values for __unused0 and __unused1, then calls fldenv to set the x87 
values, followed by ldmxcsr for the SSE values.


However, quadmath doesn't use fegetenv to retrieve the current 
settings.  It uses feholdexcept.  Unfortunately, feholdexcept doesn't 
set __unused0 and __unused1 using the SSE flags the way fegetenv does.  
As a result, when quadmath eventually calls fesetenv () to put 
things back, the values in __unused0 and __unused1 are not valid SSE 
flag settings.  This is why quadmath was crashing.


Instead of fixing feholdexcept to use the same format that the rest of 
the fenv_t functions use, kai changed fesetenv as described below.


I think the correct fix is something like the attached.  This undoes 
kai's change, and fixes feholdexcept instead.  I've taken a brief look, 
and I don't see any other functions that are like this.


Comments?  Zidane, can you try this?

dw

On 12/19/2016 7:03 PM, David Wohlferd wrote:

FWIW, I agree that this code does not look right.

The purpose of fesetenv(const fenv_t * envp) is to change the settings
of the floating point environment as specified by the parameter.
However, instead of using the values from the parameter, the current
code *overwrites* the passed in settings with the current settings, then
sets using the result.  Kinda defeats the purpose.

I hesitate to offer a fix, since I'm not sure what kai was trying to fix
with
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/e98d8084dde3e3aba43736ee78dd7b35541df00b/

The description for his checkin ("Add a fix for working fesetenv in
libquadmath-library") is a little vague.  Something relating to the sse
flags perhaps?

Kai, I don't suppose you remember any more details from this (> 3 year
old) checkin?  It was a Monday, does that help?

dw

On 12/12/2016 2:26 AM, Zidane Sama wrote:

Fesetenv does not change fpu rounding mode. This bug already described
in https://sourceforge.net/p/mingw-w64/bugs/541/
diff --git a/mingw-w64-crt/misc/feholdexcept.c b/mingw-w64-crt/misc/feholdexcept.c
index a2b7834..b44c336 100644
--- a/mingw-w64-crt/misc/feholdexcept.c
+++ b/mingw-w64-crt/misc/feholdexcept.c
@@ -13,6 +13,7 @@
 
 int feholdexcept (fenv_t * envp)
 {
+  int ret = 0;
 #if defined(_ARM_) || defined(__arm__)
   fenv_t _env;
   __asm__ volatile ("fmrx %0, FPSCR" : "=r" (_env));
@@ -20,10 +21,10 @@ int feholdexcept (fenv_t * envp)
   _env.__cw &= ~(FE_ALL_EXCEPT);
   __asm__ volatile ("fmxr FPSCR, %0" : : "r" (_env));
 #else
-  __asm__ __volatile__ ("fnstenv %0;" : "=m" (* envp)); /* save current into envp */
+  ret = fegetenv(envp);
  /* fnstenv sets control word to non-stop for all exceptions, so all we
 need to do is clear the exception flags.  */
   __asm__ __volatile__ ("fnclex");
 #endif /* defined(_ARM_) || defined(__arm__) */
-  return 0;
+  return ret;
 }
diff --git a/mingw-w64-crt/misc/fesetenv.c b/mingw-w64-crt/misc/fesetenv.c
index d16dd65..015f71e 100644
--- a/mingw-w64-crt/misc/fesetenv.c
+++ b/mingw-w64-crt/misc/fesetenv.c
@@ -58,16 +58,14 @@ int fesetenv (const fenv_t * envp)
 {
   fenv_t env = *envp;
   int _mxcsr;
-  __asm__ ("fnstenv %0\n"
-   "stmxcsr %1" : "=m" (*), "=m" (*&_mxcsr));
-  /*_mxcsr = ((int)envp->__unused0 << 16) | (int)envp->__unused1; *//* mxcsr low and high */
+  _mxcsr = ((int)envp->__unused0 << 16) | (int)envp->__unused1; /* mxcsr low and high */
   env.__unused0 = 0x;
   env.__unused1 = 0x;
   __asm__ volatile ("fldenv %0" : : "m" (env)
 			: "st", "st(1)", "st(2)", "st(3)", "st(4)",
 			"st(5)", "st(6)", "st(7)");
   if (__mingw_has_sse ())
-__asm__ v

Re: [Mingw-w64-public] Cannot build ming64 for windows

2016-12-24 Thread David Wohlferd 
On 12/24/2016 8:36 AM, Michele Bucca wrote:
> ../../../gcc-6.2.0/libgcc/libgcc2.c:557:1: warning: control reaches
> end of non-void function [-Wreturn-type]

What does your gcc configure line look like?  Have you tried adding 
--enable-werror=no?

dw

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Will be fesetenv fixed?

2016-12-25 Thread David Wohlferd 



OK, clear to apply to master, thanks for testing!


When I went to push, I had a problem with git that took me a while to 
sort out.  While I was doing that, I realized that this patch wasn't 
quite right (so I never push-ed it).  This x87 stuff is just weird.


According to 7.6.4.2 in c99, feholdexcept is supposed to do 3 things:

1) Save the current floating-point environment in the object pointed to 
by envp.

2) Clear the exception flags.
3) Install a non-stop (continue on exceptions) mode, for all exceptions.

The currently checked-in code (ie kai's last fix) does 2 & 3, and *part* 
of 1.  My previous (not pushed) patch does 1 & 2, but not 3.


So, I had to re-run this thru the fortran tests (still no changes in 
results), and now I'm re-running it past you.  Updated patch is attached.


It also occurs to me that this is the 3rd bug we had in these 3 
functions, and NONE of them have shown up in these fortran tests. AAR, 
I've created some test code for them (in c), but I'm not quite sure what 
to do with it.


dw
diff --git a/mingw-w64-crt/misc/feholdexcept.c b/mingw-w64-crt/misc/feholdexcept.c
index a2b7834..a2d351f 100644
--- a/mingw-w64-crt/misc/feholdexcept.c
+++ b/mingw-w64-crt/misc/feholdexcept.c
@@ -11,8 +11,13 @@
flags, and then installs a non-stop (continue on exceptions) mode,
if available, for all exceptions.  */
 
+#if !(defined(_ARM_) || defined(__arm__))
+int __mingw_has_sse (void);
+#endif
+
 int feholdexcept (fenv_t * envp)
 {
+  int ret = 0;
 #if defined(_ARM_) || defined(__arm__)
   fenv_t _env;
   __asm__ volatile ("fmrx %0, FPSCR" : "=r" (_env));
@@ -20,10 +25,23 @@ int feholdexcept (fenv_t * envp)
   _env.__cw &= ~(FE_ALL_EXCEPT);
   __asm__ volatile ("fmxr FPSCR, %0" : : "r" (_env));
 #else
-  __asm__ __volatile__ ("fnstenv %0;" : "=m" (* envp)); /* save current into envp */
- /* fnstenv sets control word to non-stop for all exceptions, so all we
-need to do is clear the exception flags.  */
-  __asm__ __volatile__ ("fnclex");
+   /* 1) fnstenv "saves the current floating-point environment in the object
+ pointed to by envp." (part 1)
+  3) fnstenv also "installs a non-stop (continue on exceptions) mode,
+ for all exceptions."  */
+  __asm__ __volatile__ ("fnstenv %0": "=m" (*envp)); /* Should clobber fpsr */
+
+   /* 2) "Clears the exception flags." */
+  __asm__ __volatile__ ("fnclex" :);
+  if (__mingw_has_sse ())
+{
+  int _mxcsr;
+ /* 1) Saves the current floating-point environment in the object
+   pointed to by envp (part 2) - add the SSE flags */
+  __asm__ __volatile__ ("stmxcsr %0" : "=m" (_mxcsr));
+  envp->__unused0 = (((unsigned int) _mxcsr) >> 16);
+  envp->__unused1 = (((unsigned int) _mxcsr) & 0x);
+}
 #endif /* defined(_ARM_) || defined(__arm__) */
-  return 0;
+  return ret;
 }
diff --git a/mingw-w64-crt/misc/fesetenv.c b/mingw-w64-crt/misc/fesetenv.c
index d16dd65..015f71e 100644
--- a/mingw-w64-crt/misc/fesetenv.c
+++ b/mingw-w64-crt/misc/fesetenv.c
@@ -58,16 +58,14 @@ int fesetenv (const fenv_t * envp)
 {
   fenv_t env = *envp;
   int _mxcsr;
-  __asm__ ("fnstenv %0\n"
-   "stmxcsr %1" : "=m" (*), "=m" (*&_mxcsr));
-  /*_mxcsr = ((int)envp->__unused0 << 16) | (int)envp->__unused1; *//* mxcsr low and high */
+  _mxcsr = ((int)envp->__unused0 << 16) | (int)envp->__unused1; /* mxcsr low and high */
   env.__unused0 = 0x;
   env.__unused1 = 0x;
   __asm__ volatile ("fldenv %0" : : "m" (env)
 			: "st", "st(1)", "st(2)", "st(3)", "st(4)",
 			"st(5)", "st(6)", "st(7)");
   if (__mingw_has_sse ())
-__asm__ volatile ("ldmxcsr %0" : : "m" (*&_mxcsr));
+__asm__ volatile ("ldmxcsr %0" : : "m" (_mxcsr));
 }
 
 #endif /* defined(_ARM_) || defined(__arm__) */
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Will be fesetenv fixed?

2016-12-25 Thread David Wohlferd 
Attached is an alternate fix.  This does everything the previous patch 
does, plus a bit more.


On the plus side it doesn't try to cram the SSE settings into the x87 
settings.  This not only makes things cleaner to code from the library 
side, it makes things easier for users who actually want to try to 
modify settings.  Reading/editing the (otherwise unused) __mxcsr field 
is going to be *way* easier than trying to parse things in and out of 
those 2 "__unused" fields.


The downside of course is that if someone is *already* parsing things 
out of those 2 "__unused" fields, their code would break.


While I like this "cleaner" approach, playing it safe means leaving this 
alone.


Clean?  Or safe?

dw

On 12/25/2016 9:49 PM, David Wohlferd wrote:



OK, clear to apply to master, thanks for testing!


When I went to push, I had a problem with git that took me a while to 
sort out.  While I was doing that, I realized that this patch wasn't 
quite right (so I never push-ed it).  This x87 stuff is just weird.


According to 7.6.4.2 in c99, feholdexcept is supposed to do 3 things:

1) Save the current floating-point environment in the object pointed 
to by envp.

2) Clear the exception flags.
3) Install a non-stop (continue on exceptions) mode, for all exceptions.

The currently checked-in code (ie kai's last fix) does 2 & 3, and 
*part* of 1.  My previous (not pushed) patch does 1 & 2, but not 3.


So, I had to re-run this thru the fortran tests (still no changes in 
results), and now I'm re-running it past you.  Updated patch is attached.


It also occurs to me that this is the 3rd bug we had in these 3 
functions, and NONE of them have shown up in these fortran tests. AAR, 
I've created some test code for them (in c), but I'm not quite sure 
what to do with it.


dw


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel


___
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-crt/misc/fegetenv.c b/mingw-w64-crt/misc/fegetenv.c
index 96f57e4..4e19e18 100644
--- a/mingw-w64-crt/misc/fegetenv.c
+++ b/mingw-w64-crt/misc/fegetenv.c
@@ -23,12 +23,7 @@ int fegetenv (fenv_t * envp)
 need to reload our env to restore the original mask.  */
   __asm__ __volatile__ ("fldenv %0" : : "m" (*envp));
   if (__mingw_has_sse ())
-{
-  int _mxcsr;
-  __asm__ __volatile__ ("stmxcsr %0" : "=m" (_mxcsr));
-  envp->__unused0 = (((unsigned int) _mxcsr) >> 16);
-  envp->__unused1 = (((unsigned int) _mxcsr) & 0x);
-}
+__asm__ __volatile__ ("stmxcsr %0" : "=m" (envp->__mxcsr));
 #endif /* defined(_ARM_) || defined(__arm__) */
   return 0;
 }
diff --git a/mingw-w64-crt/misc/feholdexcept.c b/mingw-w64-crt/misc/feholdexcept.c
index a2b7834..f189135 100644
--- a/mingw-w64-crt/misc/feholdexcept.c
+++ b/mingw-w64-crt/misc/feholdexcept.c
@@ -11,8 +11,13 @@
flags, and then installs a non-stop (continue on exceptions) mode,
if available, for all exceptions.  */
 
+#if !(defined(_ARM_) || defined(__arm__))
+int __mingw_has_sse (void);
+#endif
+
 int feholdexcept (fenv_t * envp)
 {
+  int ret = 0;
 #if defined(_ARM_) || defined(__arm__)
   fenv_t _env;
   __asm__ volatile ("fmrx %0, FPSCR" : "=r" (_env));
@@ -20,10 +25,18 @@ int feholdexcept (fenv_t * envp)
   _env.__cw &= ~(FE_ALL_EXCEPT);
   __asm__ volatile ("fmxr FPSCR, %0" : : "r" (_env));
 #else
-  __asm__ __volatile__ ("fnstenv %0;" : "=m" (* envp)); /* save current into envp */
- /* fnstenv sets control word to non-stop for all exceptions, so all we
-need to do is clear the exception flags.  */
-  __asm__ __volatile__ ("fnclex");
+   /* 1) fnstenv "saves the current floating-point environment in the object
+ pointed to by envp." (part 1)
+  3) fnstenv also "installs a non-stop (continue on exceptions) mode,
+ for all exceptions."  */
+  __asm__ __volatile__ ("fnstenv %0": "=m" (*envp)); /* Should clobber fpsr */
+
+   /* 2) "Clears the exception flags." */
+  __asm__ __volatile__ ("fnclex" :);
+  if (__mingw_has_sse ())
+/* 1) Saves the current floating-point environment in the object
+  pointed to by envp (part 2) - add the SSE flags */
+__asm__ __volatile__ ("stmxcsr %0" : "=m" (envp->__mxcsr));
 #endif /* defined(_ARM_) || defined(__arm__) */
-  return 0;
+  return ret;
 }
diff --git a/mingw-w64-crt/misc/fesetenv.c b/

Re: [Mingw-w64-public] Will be fesetenv fixed?

2016-12-22 Thread David Wohlferd 
On 12/21/2016 4:27 AM, JonY wrote:
> On 12/21/2016 07:29 AM, David Wohlferd wrote:
>> Comments?  Zidane, can you try this?
> David, can you also test against the gfortran testsuites?

Since mingw-w64 doesn't have any gfortran testsuites, I assume you want 
me to run gcc's.  Running "make -k check-fortran"before applying my fix 
shows a BUNCH of failures. Since I know squat about fortran, I'm not 
sure if this is because my environment is set up wrong, or if there are 
normally this many errors.  My gcc source is also somewhat old.

> Kai asks to make sure there are no new failures introduced by this change.

I suppose the most significant metric is how many failures are added (or 
removed) by applying my patch.  It turns out, the number of failures is 
unchanged:

 === gfortran Summary ===

# of expected passes42031
# of unexpected failures788
# of expected failures  80
# of unsupported tests  180

Logfile available upon request.

> Thanks for looking into it.

What's next?

dw
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
___
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] Use LPCVOID instead of 'const LPVOID' for VerQueryValue

2017-03-20 Thread David Wohlferd 

> I don't think application/octet-stream is something we would want to
> enable.  Doesn't that sound like something that would be abused?

I suppose application/octet-stream might be useful if we commonly worked 
with binary files for patches.  But I agree with you, don't do it.

A google search turned up a few other hits:

  * text/x-diff
  * application/x-patch

These aren't a problem for me, but while we're thinking about it.

dw

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] Use LPCVOID instead of 'const LPVOID' for VerQueryValue

2017-03-21 Thread David Wohlferd 

> We have text/x-patch, not application/x-patch.  I don't understand the
> difference.  Do you?

The problem with mime types is that anyone can use any string they want 
and it means whatever they want it to mean.  Of course to be "generally 
useful" the meaning must be "generally agreed upon."

It looks like you have already hit most of the "generally agreed upon" 
mime types for patches.  While there are a few places that use 
application/x-patch, it doesn't appear to be common.

Too bad SF doesn't log the mime types it has eaten.  There can't be that 
many that people are actually trying to send to this list.

dw

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] intrincs: check for __rdtsc

2017-04-15 Thread David Wohlferd 
On 4/14/2017 7:14 AM, Martell Malone wrote:
> Updated clang no longer defines __IA32INTRIN_H so lets do this properly.

It appears that the only use for  in that file is the 
prototype for __rdtsc.  While it's not "good form" to have the prototype 
in multiple places...

> I assume intrin-impl.h is only ever included by intrin.h?

Fraid not.

mingw-w64-headers\include\winbase.h:#include 
mingw-w64-headers\include\winnt.h:#include 

> If not I will have to find a way to deal with __has_builtin in both files


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public