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,
+

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] Clean build of mingw-w64 (ie no more warning)

2016-08-18 Thread Martin Storsjö 
On Thu, 18 Aug 2016, David Wohlferd wrote:

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

No objections from me. For mingw_pformat.patch, one could argue that the 
typo fix could go separately, but for a small patch like this it's 
probably fine. Bonus points for mentioning the typofix in the commit 
message though.

// Martin

--
___
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 Martell Malone 
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}

On Thu, Aug 18, 2016 at 4:21 AM, Martell Malone 
wrote:

> mingw_pformat.patch - Don't use feature (__attribute__((gcc_struct))) that
>> isn't supported on clang when compiling on clang.
>
> I have the very same patch applied locally, can confirm this is a good
> change.
> The typo was a good catch.
>
> On Thu, Aug 18, 2016 at 3:33 AM, David Wohlferd 
> wrote:
>
>>
>> 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
>>
>> 
>> --
>>
>> ___
>> 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] 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-17 Thread Ruben Van Boxem 
2016-08-17 22:08 GMT+02:00 David Wohlferd :

> I'm reluctant to get too far ahead when creating patches.  My skills
> with git just aren't up to it.
>
>
I can strongly suggest Sourcetree. With it, you can go line by line through
source files and add only the bits and pieces you want to a commit. It's
possible from the commandline, but extremely painful. Note you'll need an
Atlassian account. But for the rest it's a free tool. I use it daily to
split up my work in bits and pieces.

Cheers,

Ruben


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

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

2016-08-16 Thread Martin Storsjö 

On Tue, 16 Aug 2016, David Wohlferd wrote:


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?


Just for the record - yes, this one made it through without ending up 
flagged as spam.


// Martin--
___
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 Jacek Caban 
On 8/17/16 12:30 AM, David Wohlferd wrote:

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

They are fine with me.

Thanks,
Jacek

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

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

2016-08-16 Thread The Canadian Bacon 
It's because yahoo isn't doing proper dkim signatures, Google up the ante
on proper e-mail authentication and security.

On Aug 16, 2016 10:32 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 :-)
>
> // Martin
>
> 
> --
> ___
> 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] Clean build of mingw-w64 (ie no more warning)

2016-08-16 Thread Jacek Caban 
On 16.08.2016 14:14, dw wrote:
>  cpp_quote("#define MAKE_DXGI_HRESULT(x)
> MAKE_HRESULT(1, _FACDXGI, x)")
> +cpp_quote("")
> +cpp_quote("/* These defines are (incorrectly) duplicated in winerror.h.  
> Avoid the")
> +cpp_quote("   redefine error.  */")
> +cpp_quote("#ifndef DXGI_ERROR_INVALID_CALL")
> +cpp_quote("")
>  cpp_quote("#define DXGI_ERROR_INVALID_CALL 
> MAKE_DXGI_HRESULT(1)")
>  cpp_quote("#define DXGI_ERROR_NOT_FOUND
> MAKE_DXGI_HRESULT(2)")
>  cpp_quote("#define DXGI_ERROR_MORE_DATA
> MAKE_DXGI_HRESULT(3)")
> @@ -45,6 +50,9 @@ cpp_quote("#define DXGI_ERROR_GRAPHICS_VIDPN_SOURCE_IN_USE  
>MAKE_DXGI_HRESULT
>  cpp_quote("#define DXGI_ERROR_DRIVER_INTERNAL_ERROR
> MAKE_DXGI_HRESULT(32)")
>  cpp_quote("#define DXGI_ERROR_NONEXCLUSIVE 
> MAKE_DXGI_HRESULT(33)")
>  cpp_quote("#define DXGI_ERROR_NOT_CURRENTLY_AVAILABLE  
> MAKE_DXGI_HRESULT(34)")
> +cpp_quote("")
> +cpp_quote("#endif /* DXGI_ERROR_INVALID_CALL */")
> +cpp_quote("")

Those should be removed from dxgi.idl.

Thanks,
Jacek

--
___
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 dw 
On 8/16/2016 4:34 AM, Martin Storsjö wrote:
> On Tue, 16 Aug 2016, dw wrote:
>
>> Attempting to follow Martin's suggestions, I'm attaching the next three (I
>> *think* this is the organization he requested).  Ok to push?
> uchar.patch and ntsecapi.patch are ok with me.

Hearing no objections, I will push these 2.

>> = defines.patch 
>> Fix minor variations in definitions that trigger compiler warnings.
>>
>> gs_support.c:
>>   - The minor variation causes a 'redefines' error.
>> cephes_emath.h:
>>   - The minor variations cause 'redefines' errors.
>> dxgi.h:
>>   - Cheap way to avoid 'redefine' errors.
>> aviriff.h, basetyps.h, combaseapi.h, gpedit.h:
>>   - Redefine errors.
>> mfapi.h:
>>   - Redefine errors.
>> mfidl.h:
>>   - Redefine errors.
>> ntdef.h:
>>   - Redefine errors.
>> winnt.h:
>>   - Redefine errors.
> Please elaborate a bit more in the commit message about why, not only what
> you do. I guess "The minor variation causes a 'redefines' error." captures
> it, but for the future reader, it's quite condensed and not at all
> obvious unless said future reader goes back to read the mailing list.
>
> Add something like "When the same define is redefined, it only emits a
> warning if the contents of the define differs (in literal spelling, not
> only value). Make their literal spelling consistent across headers to
> avoid warnings about redefinitions."

I'll see what I can do.

> Also, the changes to dxgi.h is IMO a different solution to the same
> problem, so then it IMO should go into a separate patch,

Turns out I had to do that anyway.

> but all the other
> changes here seem to be the same. That is, I prefer having patches split
> based on what solution is taken to fix the issue, not based on what issue
> it is. Then you can afford to be a bit more verbose about the chosen
> solution in the commit message, since it's only one solution per commit.
>
> The rest of that patch seems fine to me, as long as Jacek's concern is
> handled.

Updated patch sent.  Waiting to hear from Jacek.

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] Clean build of mingw-w64 (ie no more warning)

2016-08-16 Thread Martin Storsjö 
On Tue, 16 Aug 2016, dw wrote:

> On 8/16/2016 4:16 AM, Jacek Caban wrote:
>> On 16.08.2016 12:50, dw wrote:
>>> --- a/mingw-w64-headers/include/mfidl.h
>>> +++ b/mingw-w64-headers/include/mfidl.h
>> This file is auto generated. You should not touch it, please change .idl
>> file instead.
>
> Strictly speaking, I believe the (duplicate) MF_xx_BYTE_ALIGNMENT defines 
> should be removed from mfidl.idl.  But for our purposes today, I can achieve 
> the desired result by just changing mfapi.h (attached as defines3.patch). 
> Better?
>
> And since you mentioned it, I checked the other files and dxgi.h is also a 
> generated file.  I have broken it out to a separate patch (dxgi.patch).
>
> = dxgi.patch 
> Avoid 'redefine' warnings from duplicated (but microscopically different) 
> defines.
>
> = defines3.patch 
> Fix minor variations in definitions that trigger compiler warnings.
>
> gs_support.c:
>  - The minor variation causes a 'redefines' error.
> cephes_emath.h:
>  - The minor variations cause 'redefines' errors.
> aviriff.h, basetyps.h, combaseapi.h, gpedit.h:
>  - Redefine errors.
> mfapi.h:
>  - Redefine errors.
> ntdef.h:
>  - Redefine errors.
> winnt.h:
>  - Redefine errors.

Both patches ok with me, but please wait for someone else's opinion as 
well.

// Martin

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

On 8/16/2016 4:16 AM, Jacek Caban wrote:

On 16.08.2016 12:50, dw wrote:

--- a/mingw-w64-headers/include/mfidl.h
+++ b/mingw-w64-headers/include/mfidl.h

This file is auto generated. You should not touch it, please change .idl
file instead.


Strictly speaking, I believe the (duplicate) MF_xx_BYTE_ALIGNMENT 
defines should be removed from mfidl.idl.  But for our purposes today, I 
can achieve the desired result by just changing mfapi.h (attached as 
defines3.patch).  Better?


And since you mentioned it, I checked the other files and dxgi.h is also 
a generated file.  I have broken it out to a separate patch (dxgi.patch).


= dxgi.patch 
Avoid 'redefine' warnings from duplicated (but microscopically 
different) defines.


= defines3.patch 
Fix minor variations in definitions that trigger compiler warnings.

gs_support.c:
  - The minor variation causes a 'redefines' error.
cephes_emath.h:
  - The minor variations cause 'redefines' errors.
aviriff.h, basetyps.h, combaseapi.h, gpedit.h:
  - Redefine errors.
mfapi.h:
  - Redefine errors.
ntdef.h:
  - Redefine errors.
winnt.h:
  - Redefine errors.

dw
diff --git a/mingw-w64-crt/crt/gs_support.c b/mingw-w64-crt/crt/gs_support.c
index dbd95d5..f47b0fe 100644
--- a/mingw-w64-crt/crt/gs_support.c
+++ b/mingw-w64-crt/crt/gs_support.c
@@ -26,7 +26,7 @@
 
 typedef LONG NTSTATUS;	/* same as in ntdef.h / winternl.h */
 
-#define UNW_FLAG_NHANDLER 0x00
+#define UNW_FLAG_NHANDLER   0x0
 
 typedef union
 {
diff --git a/mingw-w64-crt/math/cephes_emath.h b/mingw-w64-crt/math/cephes_emath.h
index b92d710..58a8e13 100644
--- a/mingw-w64-crt/math/cephes_emath.h
+++ b/mingw-w64-crt/math/cephes_emath.h
@@ -190,7 +190,7 @@
 #define EXONE (0x3fff)
 
 
-#define  mtherr(x,y)
+#define mtherr(fname, code)
 
 
 extern long double strtold (const char * __restrict__ s, char ** __restrict__ se);
@@ -293,7 +293,7 @@ static __inline__ void __eshdn6(register short unsigned int *x);
  */
 #define XPD 0,
 /* #define XPD */
-#define NANS
+#define NANS 1
 
 /* NaN's require infinity support. */
 #ifdef NANS
diff --git a/mingw-w64-headers/include/aviriff.h b/mingw-w64-headers/include/aviriff.h
index 30e7de3..9f4e664 100755
--- a/mingw-w64-headers/include/aviriff.h
+++ b/mingw-w64-headers/include/aviriff.h
@@ -53,12 +53,12 @@ typedef struct _rifflist {
 #define streamtypeVIDEO FCC('vids')
 #endif
 
-#define AVIF_HASINDEX 0x10
-#define AVIF_MUSTUSEINDEX 0x20
-#define AVIF_ISINTERLEAVED 0x100
-#define AVIF_TRUSTCKTYPE 0x800
-#define AVIF_WASCAPTUREFILE 0x1
-#define AVIF_COPYRIGHTED 0x2
+#define AVIF_HASINDEX 0x0010
+#define AVIF_MUSTUSEINDEX 0x0020
+#define AVIF_ISINTERLEAVED 0x0100
+#define AVIF_TRUSTCKTYPE 0x0800
+#define AVIF_WASCAPTUREFILE 0x0001
+#define AVIF_COPYRIGHTED 0x0002
 
 #ifndef AVIIF_LIST
 #define AVIIF_LIST 0x1
@@ -67,8 +67,8 @@ typedef struct _rifflist {
 #define AVIIF_NO_TIME 0x100
 #define AVIIF_COMPRESSOR 0xfff
 
-#define AVISF_DISABLED 0x1
-#define AVISF_VIDEO_PALCHANGES 0x1
+#define AVISF_DISABLED 0x0001
+#define AVISF_VIDEO_PALCHANGES 0x0001
 
 #define TIMECODE_RATE_30DROP 0
 
diff --git a/mingw-w64-headers/include/basetyps.h b/mingw-w64-headers/include/basetyps.h
index 7c36eca..dbfdcea 100644
--- a/mingw-w64-headers/include/basetyps.h
+++ b/mingw-w64-headers/include/basetyps.h
@@ -78,9 +78,9 @@
 #endif
 
 #define IFACEMETHOD(method) /*override*/ STDMETHOD (method)
-#define IFACEMETHOD_(type, method) /*override*/ STDMETHOD_ (type, method)
+#define IFACEMETHOD_(type, method) /*override*/ STDMETHOD_(type, method)
 #define IFACEMETHODV(method) /*override*/ STDMETHODV (method)
-#define IFACEMETHODV_(type, method) /*override*/ STDMETHODV_ (type, method)
+#define IFACEMETHODV_(type, method) /*override*/ STDMETHODV_(type, method)
 
 #include 
 
diff --git a/mingw-w64-headers/include/combaseapi.h b/mingw-w64-headers/include/combaseapi.h
index 3536e25..ca6483f 100644
--- a/mingw-w64-headers/include/combaseapi.h
+++ b/mingw-w64-headers/include/combaseapi.h
@@ -63,7 +63,7 @@
 #define DECLARE_INTERFACE_IID_(iface, baseiface, iid) interface DECLSPEC_UUID (iid) DECLSPEC_NOVTABLE iface : public baseiface
 
 #define IFACEMETHOD(method) STDMETHOD (method)
-#define IFACEMETHOD_(type, method) STDMETHOD_(type, method)
+#define IFACEMETHOD_(type, method) /*override*/ STDMETHOD_(type, method)
 #define IFACEMETHODV(method) STDMETHODV (method)
 #define IFACEMETHODV_(type, method) STDMETHODV_(type, method)
 
@@ -92,9 +92,9 @@ extern "C++" {
 #define STDMETHODV_(type, method) type (STDMETHODVCALLTYPE *method)
 
 #define IFACEMETHOD(method) STDMETHOD (method)
-#define IFACEMETHOD_(type, method) STDMETHOD_ (type, method)
+#define IFACEMETHOD_(type, method) /*override*/ STDMETHOD_(type, method)
 #define IFACEMETHODV(method) STDMETHODV (method)
-#define IFACEMETHODV_(type, method) STDMETHODV_ (type, method)
+#define IFACEMETHODV_(type, method) /*override*/ STDMETHODV_(type, method)
 
 #ifndef BEGIN_INTERFACE
 #define

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

2016-08-16 Thread Martin Storsjö 
On Tue, 16 Aug 2016, dw wrote:

> Attempting to follow Martin's suggestions, I'm attaching the next three (I 
> *think* this is the organization he requested).  Ok to push?

uchar.patch and ntsecapi.patch are ok with me.

> = defines.patch 
> Fix minor variations in definitions that trigger compiler warnings.
>
> gs_support.c:
>  - The minor variation causes a 'redefines' error.
> cephes_emath.h:
>  - The minor variations cause 'redefines' errors.
> dxgi.h:
>  - Cheap way to avoid 'redefine' errors.
> aviriff.h, basetyps.h, combaseapi.h, gpedit.h:
>  - Redefine errors.
> mfapi.h:
>  - Redefine errors.
> mfidl.h:
>  - Redefine errors.
> ntdef.h:
>  - Redefine errors.
> winnt.h:
>  - Redefine errors.

Please elaborate a bit more in the commit message about why, not only what 
you do. I guess "The minor variation causes a 'redefines' error." captures 
it, but for the future reader, it's quite condensed and not at all 
obvious unless said future reader goes back to read the mailing list.

Add something like "When the same define is redefined, it only emits a 
warning if the contents of the define differs (in literal spelling, not 
only value). Make their literal spelling consistent across headers to 
avoid warnings about redefinitions."

Also, the changes to dxgi.h is IMO a different solution to the same 
problem, so then it IMO should go into a separate patch, but all the other 
changes here seem to be the same. That is, I prefer having patches split 
based on what solution is taken to fix the issue, not based on what issue 
it is. Then you can afford to be a bit more verbose about the chosen 
solution in the commit message, since it's only one solution per commit.

The rest of that patch seems fine to me, as long as Jacek's concern is 
handled.

// Martin

--
___
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 Jacek Caban 
On 16.08.2016 12:50, dw wrote:
>
> diff --git a/mingw-w64-headers/include/mfidl.h 
> b/mingw-w64-headers/include/mfidl.h
> index 76e8ae3..1658e58 100644
> --- a/mingw-w64-headers/include/mfidl.h
> +++ b/mingw-w64-headers/include/mfidl.h
> @@ -3399,12 +3399,12 @@ typedef struct _MFNetCredentialManagerGetParam {
>  #define MF_2_BYTE_ALIGNMENT 0x0001
>  #define MF_4_BYTE_ALIGNMENT 0x0003
>  #define MF_8_BYTE_ALIGNMENT 0x0007
> -#define MF_16_BYTE_ALIGNMENT0x000F
> -#define MF_32_BYTE_ALIGNMENT0x001F
> -#define MF_64_BYTE_ALIGNMENT0x003F
> -#define MF_128_BYTE_ALIGNMENT   0x007F
> -#define MF_256_BYTE_ALIGNMENT   0x00FF
> -#define MF_512_BYTE_ALIGNMENT   0x01FF
> +#define MF_16_BYTE_ALIGNMENT0x000f
> +#define MF_32_BYTE_ALIGNMENT0x001f
> +#define MF_64_BYTE_ALIGNMENT0x003f
> +#define MF_128_BYTE_ALIGNMENT   0x007f
> +#define MF_256_BYTE_ALIGNMENT   0x00ff
> +#define MF_512_BYTE_ALIGNMENT   0x01ff
>  
>  #define MEDIASINK_FIXED_STREAMS 0x0001
>  #define MEDIASINK_CANNOT_MATCH_CLOCK0x0002


This file is auto generated. You should not touch it, please change .idl
file instead.

Thanks,
Jacek
--
___
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 dw 

On 8/16/2016 12:41 AM, Kai Tietz wrote:

 From my POV patch is ok.


Ok, I pushed that one.

Attempting to follow Martin's suggestions, I'm attaching the next three 
(I *think* this is the organization he requested).  Ok to push?


BTW, since the list now supports it, I have switched from sending .txt 
files back to sending .patch files.  I find it easier to review 
attachments if the correct program auto-launches.  But if this causes 
problems, let me know.


= defines.patch 
Fix minor variations in definitions that trigger compiler warnings.

gs_support.c:
  - The minor variation causes a 'redefines' error.
cephes_emath.h:
  - The minor variations cause 'redefines' errors.
dxgi.h:
  - Cheap way to avoid 'redefine' errors.
aviriff.h, basetyps.h, combaseapi.h, gpedit.h:
  - Redefine errors.
mfapi.h:
  - Redefine errors.
mfidl.h:
  - Redefine errors.
ntdef.h:
  - Redefine errors.
winnt.h:
  - Redefine errors.
= uchar.patch 
Fix redefinitions warnings in uchar.h.

  - __STDC_UTF_16__ & __STDC_UTF_32__ are defined by the gcc compiler.
== ntsecapi.patch ===
Fix redefinitions warnings in ntsecapi.h.

  - These redefine values that are unconditionally defined earlier in 
the same file.


dw
diff --git a/mingw-w64-crt/crt/gs_support.c b/mingw-w64-crt/crt/gs_support.c
index dbd95d5..f47b0fe 100644
--- a/mingw-w64-crt/crt/gs_support.c
+++ b/mingw-w64-crt/crt/gs_support.c
@@ -26,7 +26,7 @@
 
 typedef LONG NTSTATUS;	/* same as in ntdef.h / winternl.h */
 
-#define UNW_FLAG_NHANDLER 0x00
+#define UNW_FLAG_NHANDLER   0x0
 
 typedef union
 {
diff --git a/mingw-w64-crt/math/cephes_emath.h b/mingw-w64-crt/math/cephes_emath.h
index b92d710..58a8e13 100644
--- a/mingw-w64-crt/math/cephes_emath.h
+++ b/mingw-w64-crt/math/cephes_emath.h
@@ -190,7 +190,7 @@
 #define EXONE (0x3fff)
 
 
-#define  mtherr(x,y)
+#define mtherr(fname, code)
 
 
 extern long double strtold (const char * __restrict__ s, char ** __restrict__ se);
@@ -293,7 +293,7 @@ static __inline__ void __eshdn6(register short unsigned int *x);
  */
 #define XPD 0,
 /* #define XPD */
-#define NANS
+#define NANS 1
 
 /* NaN's require infinity support. */
 #ifdef NANS
diff --git a/mingw-w64-headers/direct-x/include/dxgi.h b/mingw-w64-headers/direct-x/include/dxgi.h
index d116b89..d056fa3 100644
--- a/mingw-w64-headers/direct-x/include/dxgi.h
+++ b/mingw-w64-headers/direct-x/include/dxgi.h
@@ -108,6 +108,11 @@ extern "C" {
 #define DXGI_STATUS_MODE_CHANGEDMAKE_DXGI_STATUS(7)
 #define DXGI_STATUS_MODE_CHANGE_IN_PROGRESS MAKE_DXGI_STATUS(8)
 #define MAKE_DXGI_HRESULT(x)MAKE_HRESULT(1, _FACDXGI, x)
+
+/* These defines are (incorrectly) duplicated in winerror.h.  Avoid the
+   redefine error.  */
+#ifndef DXGI_ERROR_INVALID_CALL
+
 #define DXGI_ERROR_INVALID_CALL MAKE_DXGI_HRESULT(1)
 #define DXGI_ERROR_NOT_FOUNDMAKE_DXGI_HRESULT(2)
 #define DXGI_ERROR_MORE_DATAMAKE_DXGI_HRESULT(3)
@@ -121,6 +126,9 @@ extern "C" {
 #define DXGI_ERROR_DRIVER_INTERNAL_ERRORMAKE_DXGI_HRESULT(32)
 #define DXGI_ERROR_NONEXCLUSIVE MAKE_DXGI_HRESULT(33)
 #define DXGI_ERROR_NOT_CURRENTLY_AVAILABLE  MAKE_DXGI_HRESULT(34)
+
+#endif /* DXGI_ERROR_INVALID_CALL */
+
 #if 0
 typedef HANDLE HMONITOR;
 typedef struct _LUID {
diff --git a/mingw-w64-headers/include/aviriff.h b/mingw-w64-headers/include/aviriff.h
index 30e7de3..9f4e664 100755
--- a/mingw-w64-headers/include/aviriff.h
+++ b/mingw-w64-headers/include/aviriff.h
@@ -53,12 +53,12 @@ typedef struct _rifflist {
 #define streamtypeVIDEO FCC('vids')
 #endif
 
-#define AVIF_HASINDEX 0x10
-#define AVIF_MUSTUSEINDEX 0x20
-#define AVIF_ISINTERLEAVED 0x100
-#define AVIF_TRUSTCKTYPE 0x800
-#define AVIF_WASCAPTUREFILE 0x1
-#define AVIF_COPYRIGHTED 0x2
+#define AVIF_HASINDEX 0x0010
+#define AVIF_MUSTUSEINDEX 0x0020
+#define AVIF_ISINTERLEAVED 0x0100
+#define AVIF_TRUSTCKTYPE 0x0800
+#define AVIF_WASCAPTUREFILE 0x0001
+#define AVIF_COPYRIGHTED 0x0002
 
 #ifndef AVIIF_LIST
 #define AVIIF_LIST 0x1
@@ -67,8 +67,8 @@ typedef struct _rifflist {
 #define AVIIF_NO_TIME 0x100
 #define AVIIF_COMPRESSOR 0xfff
 
-#define AVISF_DISABLED 0x1
-#define AVISF_VIDEO_PALCHANGES 0x1
+#define AVISF_DISABLED 0x0001
+#define AVISF_VIDEO_PALCHANGES 0x0001
 
 #define TIMECODE_RATE_30DROP 0
 
diff --git a/mingw-w64-headers/include/basetyps.h b/mingw-w64-headers/include/basetyps.h
index 7c36eca..dbfdcea 100644
--- a/mingw-w64-headers/include/basetyps.h
+++ b/mingw-w64-headers/include/basetyps.h
@@ -78,9 +78,9 @@
 #endif
 
 #define IFACEMETHOD(method) /*override*/ STDMETHOD (method)
-#define IFACEMETHOD_(type, method) /*override*/ STDMETHOD_ (type, method)
+#define IFACEMETHOD_(type, method) /*override*/ STDMETHOD_(type, method)
 #define IFACEMETHODV(method) /*override*/ STDMETHODV (method)
-#define IFACEMETHODV_(type,

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

2016-08-16 Thread Kai Tietz 
Hi,

thanks for taking care about those warnings.  Interesting that the
redefinition is also triggered by whitespace changes, and leading
zeros ... but well, I guess it is related to partial parsing, and by
comparing for this diagnostic on not unified token stream.

From my POV patch is ok.  My personal preference is to get rid of
leading zeros, but well, I am fine.

Regards,
Kai


2016-08-16 8:45 GMT+02:00 Martin Storsjö :
> On Mon, 15 Aug 2016, dw wrote:
>
>> On 8/15/2016 4:54 AM, Martin Storsjö wrote:

 but 30 of these would be a huge hassle for the approvers as well.
>>>
>>> Not really, if they are well contained with an explanation matching it
>>> close by, it's trivial to review.
>>
>>
>> Historically my experiences haven't been good in this area.  But if you
>> are prepared to review them, I guess I can make them.
>>
 = Missing prototypes =
 clog10.c, clog10f.c, clog10l.c:
- The prototypes for the functions created in these files are
  protected by #ifdef _GNU_SOURCE.  Since we should always build
  the .c file, we need to add the define so we can find the
  prototype.
 gai_strerrorA.c:
- wcstombs() is in stdlib.
 abs64.c:
- llabs() is in stdlib.h.
 _vscprintf_p.c, _vscwprintf_p.c, _vswprintf_p.c:
- _vscprintf_p_l, _vscwprintf_p_l & _vswprintf_p_l prototypes are
  protected by #if.  Add the define so we can find them.
>>>
>>> Sure
>>
>>
>> Attached.  Ok to push?
>
>
> Remove the extra copyright disclaimer headers that you're adding. If you're
> keen on adding them, send a separate patch for that.
>
> No other objection from me, but please wait for at least somebody else to
> comment on it as well.
>
> // Martin
> --
>
> ___
> 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] Clean build of mingw-w64 (ie no more warning)

2016-08-16 Thread Martin Storsjö 

On Tue, 16 Aug 2016, dw wrote:


On 8/15/2016 11:45 PM, Martin Storsjö wrote:
Remove the extra copyright disclaimer headers that you're adding. If you're 
keen on adding them, send a separate patch for that.


I have removed the 'extra' text (attached).  Note that I am attaching 2 
files, but they are identical.  The goal is to see if text/x-patch files are 
being accepted by this list now.


I still think this level of 'purity' results in a great deal of unnecessary 
work on everyone's part.  But if this is what's required to get patches 
approved...


Anything less than this results in a commit history which is a huge pain 
to deal with afterwards.


Also keep in mind that it is absolutely trivial to do this with git, and 
you can post your full series (including attached commit messages, so that 
the commit message can be reviewed along with the diff) so that people can 
review all of them at once, instead of spoon-feeding one patch at a time 
which surely takes a lot of time and a huge number of roundtrips.


No other objection from me, but please wait for at least somebody else to 
comment on it as well.


Are you not authorized to approve patches?  Who should I be looking for email 
from then?  Or is there something about this particular patch that requires a 
closer look?


I'm just a very recent contributor, but I'm trying to get the suggested 
patches up to a level that I'm comfortable with, and that is common 
practice in other projects I've been involved with.


// Martin--
___
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 Martin Storsjö 

On Mon, 15 Aug 2016, dw wrote:


On 8/15/2016 4:54 AM, Martin Storsjö wrote:

but 30 of these would be a huge hassle for the approvers as well.

Not really, if they are well contained with an explanation matching it
close by, it's trivial to review.


Historically my experiences haven't been good in this area.  But if you are 
prepared to review them, I guess I can make them.



= Missing prototypes =
clog10.c, clog10f.c, clog10l.c:
   - The prototypes for the functions created in these files are
 protected by #ifdef _GNU_SOURCE.  Since we should always build
 the .c file, we need to add the define so we can find the
 prototype.
gai_strerrorA.c:
   - wcstombs() is in stdlib.
abs64.c:
   - llabs() is in stdlib.h.
_vscprintf_p.c, _vscwprintf_p.c, _vswprintf_p.c:
   - _vscprintf_p_l, _vscwprintf_p_l & _vswprintf_p_l prototypes are
 protected by #if.  Add the define so we can find them.

Sure


Attached.  Ok to push?


Remove the extra copyright disclaimer headers that you're adding. If 
you're keen on adding them, send a separate patch for that.


No other objection from me, but please wait for at least somebody else to 
comment on it as well.


// Martin--
___
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-15 Thread Martin Storsjö 
On Sun, 14 Aug 2016, dw wrote:

>>> - _vswprintf_p.c, _vscwprintf_p.c - these also add a comment that wasn't
>>> there before. Probably ok, but I guess it's preferrable to have such
>>> changes split out.
>>> - aviriff.h, I see no other changes than adding in leading zeros
>
> Yes, that's true.  However, there is another header that *doesn't* have 
> those zeros.  So while from a functional point of view it makes 
> absolutely no difference, the compiler warns about the "redefinition." 
> Even a difference in spacing triggers this warning.

Ah, right, that was the missing explanation - now it makes more sense.

> In my mind, the "issue" I was resolving was "cleaning up warnings." 
> Every line in this patch was designed with that goal (well, with the 
> exception of the copyright.  That's just habit). I didn't set out to 
> "fix redefine errors," then "fix unreferenced parameter errors," etc. 
> So in the end, I just have a bunch of files with fixes.

Yes, but from a reviewer perspective, or for someone digging through the 
history later, it's much easier to handle with one patch per issue group.

> but 30 of these would be a huge hassle for the approvers as well.

Not really, if they are well contained with an explanation matching it 
close by, it's trivial to review.

> = Missing prototypes =
> clog10.c, clog10f.c, clog10l.c:
>   - The prototypes for the functions created in these files are
> protected by #ifdef _GNU_SOURCE.  Since we should always build
> the .c file, we need to add the define so we can find the
> prototype.
> gai_strerrorA.c:
>   - wcstombs() is in stdlib.
> abs64.c:
>   - llabs() is in stdlib.h.
> _vscprintf_p.c, _vscwprintf_p.c, _vswprintf_p.c:
>   - _vscprintf_p_l, _vscwprintf_p_l & _vswprintf_p_l prototypes are
> protected by #if.  Add the define so we can find them.

Sure

> = #define mismatches =
> gs_support.c:
>   - The minor variation causes a 'redefines' error.
> cephes_emath.h:
>   - The minor variations cause 'redefines' errors.
> uchar.h:
>   - __STDC_UTF_16__ & __STDC_UTF_32__ are defined by the gcc
> compiler.

I'd say split this one separately.

> dxgi.h:
>   - Cheap way to avoid 'redefine' errors.
> aviriff.h, basetyps.h, combaseapi.h, gpedit.h:
>   - Redefine errors.
> mfapi.h:
>   - Redefine errors.
> mfidl.h:
>   - Redefine errors.
> ntdef.h:
>   - Redefine errors.
> ntsecapi.h:
>   - These redefine values that are unconditionally defined earlier
> in the same file.

This one probably should go separately as well.

This way, one patch is for all the "adjust definitions in separate headers 
to match, to avoid warnings about redefinition", and other patches for 
other solutions.

> winnt.h:
>   - Redefine errors.
>
> = Unreferenced variables =
> gs_support.c:
>   - ARM does not use StackCookie.  I'd like to use the already-
> defined __UNUSED_PARAM from _mingw.h, but it uses an attribute,
> so I'd have to put it on the function declaration, and then I'd
> have to #ifdef it by platform.  Yuck.
> ftw.c:
>   - Unused parameters.

Sure

> = Add Pragma Diagnostic =
> tdelete.c:
>   - Comparing NULL to function pointer generates warning.
> stdio.h:
>   - We are shadowing a number of functions provided by the compiler
>(snprintf, vsnprintf, etc).  Ignore warnings.
> mfapi.h:
>   - FCC ('AI44') et al cause 'multichar' compiler warnings. Ignore
> them.
>
> = Misc warnings =
> e_pow.c:
>   - Sign mismatch in comparison.
> mingw_pformat.c:
>   - ARM does not support __attribute__((gcc_struct))

It's still not ARM that doesn't support it, it's clang.

> mingw_vfscanf.c:
>   - Fix incorrect indention.
> mftransform.h:
>   - 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. Using both 'extern' and initializing generates
> a warning.

I'd rather split these misc ones up to individual patches as well.

// Martin

--
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-14 Thread dw 
On 8/14/2016 9:23 AM, NightStrike wrote:
> On Sun, Aug 14, 2016 at 9:02 AM, Martin Storsjö  wrote:
>> On Sat, 13 Aug 2016, dw wrote:
>>
>>> I still have some more fixes for ARM, but this patch is getting too 
>>> big.
>>> This is a logical point to break.
>> Yes, that's probably for the best.
>>
>> If/when committing (iirc someone had already ok'd it?),
> Who ok'd it?

Yeah, I'm pretty sure no one has yet.

>> I think it'd be
>> even better to split it further, to one commit per issue.
>> There also seems to be a few other changes in the patch not directly
>> related to getting rid of warnings:
>> - gs_support.c, only whitespace change in UNW_FLAG_NHANDLER, nothing 
>> else
>> changed on that line?

Actually, there are 2 changes on that line.  One is spacing, the other 
is changing "0x00" to "0x0".  However there are other changes in that 
patch that *are* just spacing (see basetyps.h).

>> - _vswprintf_p.c, _vscwprintf_p.c - these also add a comment that wasn't
>> there before. Probably ok, but I guess it's preferrable to have such
>> changes split out.
>> - aviriff.h, I see no other changes than adding in leading zeros

Yes, that's true.  However, there is another header that *doesn't* have 
those zeros.  So while from a functional point of view it makes 
absolutely no difference, the compiler warns about the "redefinition."  
Even a difference in spacing triggers this warning.

A lot of the changes here are just like this.  Trivial, nothing changes, 
that nonetheless trigger warnings.  That's the only reason I'm prepared 
to make a patch this big.

>> - basetyps.h, also only fixing whitespace?

Yup.

>> - mfidl.h, changing hex constants from upper case to lower?

Yeah.

>> - winnt.h, removing leading zeros in hex constants?

Uh huh.

>> So I think it'd be better to commit the fixes for each issue (not per
>> file, but per issue) separately, with an explanation on what 
>> warning/issue
>> it fixes, or why it stylistically is preferrable. (E.g. the list of 
>> files
>> and changes you have only mention "redefine errors" for winnt.h.)
> Yes, definitely split it up into smaller commits as described here.

In my mind, the "issue" I was resolving was "cleaning up warnings." 
Every line in this patch was designed with that goal (well, with the 
exception of the copyright.  That's just habit). I didn't set out to 
"fix redefine errors," then "fix unreferenced parameter errors," etc.  
So in the end, I just have a bunch of files with fixes.

While I can split this up into smaller patches if that's what it takes 
to get it approved, I'm not looking forward to it.  At ~one patch per 
file, that's ~30 patches.  If I compile each one before I check it in to 
make sure it can stand alone, that's what, 6 hours of compiling?  Ouch.  
I don't know if people like to build patches before they approve them, 
but 30 of these would be a huge hassle for the approvers as well.

But since Nightstrike and Martin want this broken up before they approve 
it, how about grouping them like this:

= Missing prototypes =
clog10.c, clog10f.c, clog10l.c:
   - The prototypes for the functions created in these files are
 protected by #ifdef _GNU_SOURCE.  Since we should always build
 the .c file, we need to add the define so we can find the
 prototype.
gai_strerrorA.c:
   - wcstombs() is in stdlib.
abs64.c:
   - llabs() is in stdlib.h.
_vscprintf_p.c, _vscwprintf_p.c, _vswprintf_p.c:
   - _vscprintf_p_l, _vscwprintf_p_l & _vswprintf_p_l prototypes are
 protected by #if.  Add the define so we can find them.

= #define mismatches =
gs_support.c:
   - The minor variation causes a 'redefines' error.
cephes_emath.h:
   - The minor variations cause 'redefines' errors.
uchar.h:
   - __STDC_UTF_16__ & __STDC_UTF_32__ are defined by the gcc
 compiler.
dxgi.h:
   - Cheap way to avoid 'redefine' errors.
aviriff.h, basetyps.h, combaseapi.h, gpedit.h:
   - Redefine errors.
mfapi.h:
   - Redefine errors.
mfidl.h:
   - Redefine errors.
ntdef.h:
   - Redefine errors.
ntsecapi.h:
   - These redefine values that are unconditionally defined earlier
 in the same file.
winnt.h:
   - Redefine errors.

= Unreferenced variables =
gs_support.c:
   - ARM does not use StackCookie.  I'd like to use the already-
 defined __UNUSED_PARAM from _mingw.h, but it uses an attribute,
 so I'd have to put it on the function declaration, and then I'd
 have to #ifdef it by platform.  Yuck.
ftw.c:
   - Unused parameters.

= Add Pragma Diagnostic =
tdelete.c:
   - Comparing NULL to function pointer generates warning.
stdio.h:
   - We are shadowing a number of functions provided by the compiler
(snprintf, vsnprintf, etc).  Ignore warnings.
mfapi.h:
   - FCC ('AI44') et al cause 'multichar' compiler warnings. Ignore
 them.

= Misc warnings =
e_pow.c:
   - Sign mismatch in comparison.

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

2016-08-14 Thread Martin Storsjö 

On Sun, 14 Aug 2016, NightStrike wrote:


On Sun, Aug 14, 2016 at 9:02 AM, Martin Storsjö  wrote:

On Sat, 13 Aug 2016, dw wrote:


I still have some more fixes for ARM, but this patch is getting too big.
This is a logical point to break.


Yes, that's probably for the best.

If/when committing (iirc someone had already ok'd it?),


Who ok'd it?


Ah, apparently I misremembered - nevermind then.

// Martin--
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-14 Thread NightStrike 
On Sun, Aug 14, 2016 at 9:02 AM, Martin Storsjö  wrote:
> On Sat, 13 Aug 2016, dw wrote:
>
>> I still have some more fixes for ARM, but this patch is getting too big.
>> This is a logical point to break.
>
> Yes, that's probably for the best.
>
> If/when committing (iirc someone had already ok'd it?),

Who ok'd it?

> I think it'd be
> even better to split it further, to one commit per issue.

> There also seems to be a few other changes in the patch not directly
> related to getting rid of warnings:
> - gs_support.c, only whitespace change in UNW_FLAG_NHANDLER, nothing else
>changed on that line?
> - _vswprintf_p.c, _vscwprintf_p.c - these also add a comment that wasn't
>there before. Probably ok, but I guess it's preferrable to have such
>changes split out.
> - aviriff.h, I see no other changes than adding in leading zeros
> - basetyps.h, also only fixing whitespace?
> - mfidl.h, changing hex constants from upper case to lower?
> - winnt.h, removing leading zeros in hex constants?
>
> So I think it'd be better to commit the fixes for each issue (not per
> file, but per issue) separately, with an explanation on what warning/issue
> it fixes, or why it stylistically is preferrable. (E.g. the list of files
> and changes you have only mention "redefine errors" for winnt.h.)

Yes, definitely split it up into smaller commits as described here.

--
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-14 Thread Martin Storsjö 
On Sat, 13 Aug 2016, dw wrote:

> I still have some more fixes for ARM, but this patch is getting too big. 
> This is a logical point to break.

Yes, that's probably for the best.

If/when committing (iirc someone had already ok'd it?), I think it'd be 
even better to split it further, to one commit per issue.

There also seems to be a few other changes in the patch not directly 
related to getting rid of warnings:
- gs_support.c, only whitespace change in UNW_FLAG_NHANDLER, nothing else
   changed on that line?
- _vswprintf_p.c, _vscwprintf_p.c - these also add a comment that wasn't
   there before. Probably ok, but I guess it's preferrable to have such
   changes split out.
- aviriff.h, I see no other changes than adding in leading zeros
- basetyps.h, also only fixing whitespace?
- mfidl.h, changing hex constants from upper case to lower?
- winnt.h, removing leading zeros in hex constants?

So I think it'd be better to commit the fixes for each issue (not per 
file, but per issue) separately, with an explanation on what warning/issue 
it fixes, or why it stylistically is preferrable. (E.g. the list of files 
and changes you have only mention "redefine errors" for winnt.h.)

// Martin

--
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-13 Thread dw 

On 8/8/2016 6:07 AM, Martin Storsjö wrote:

Q4: As of 3.8.0, clang (the only compiler I know that builds mingw-w64 for
ARM) doesn't support __declspec(selectany) or __attribute__((gcc_struct)) on
ARM.  Since (essentially) no one is using this yet, can we assume it will get
fixed before people will start using the library?  Or must we code around it?
Right now I'm doing a bit of both.

It's not about it being supported on ARM, but about clang not supporting
it at all, regardless of architecture.

I'd suggest doing

#if defined(__GNUC__) && !defined(__clang__)


I have made Martin's change (attached) as well as a couple others. Ok to 
push?


I still have some more fixes for ARM, but this patch is getting too 
big.  This is a logical point to break.  My commit text:


Clean up a variety of compile warnings:

clog10.c, clog10f.c, clog10l.c:
  - The prototypes for the functions created in these files are
protected by #ifdef _GNU_SOURCE.  Since we should always build
the .c file, we need to add the define so we can find the
prototype.

gs_support.c:
  - The minor variation causes a 'redefines' error.
  - ARM does not use StackCookie.  I'd like to use the already-
defined __UNUSED_PARAM from _mingw.h, but it uses an attribute,
so I'd have to put it on the function declaration, and then I'd
have to #ifdef it by platform.  Yuck.

gai_strerrorA.c:
  - wcstombs() is in stdlib.

abs64.c:
  - llabs() is in stdlib.h.

cephes_emath.h:
  - These minor variations cause 'redefines' errors.

e_pow.c:
  - Sign mismatch in comparison.

ftw.c:
  - Unused parameters.

tdelete.c:
  - Comparing NULL to function pointer generates warning.

_vscprintf_p.c, _vscwprintf_p.c, _vswprintf_p.c:
  - _vscprintf_p_l, _vscwprintf_p_l & _vswprintf_p_l prototypes are
protected by #if.  Add the define so we can find them.

mingw_pformat.c:
  - ARM does not support __attribute__((gcc_struct))

mingw_vfscanf.c:
  - Fix incorrect indention.

stdio.h:
  - We are shadowing a number of functions provided by the compiler
   (snprintf, vsnprintf, etc).  Ignore warnings.

uchar.h:
  - __STDC_UTF_16__ & __STDC_UTF_32__ are defined by the gcc
compiler.

dxgi.h:
  - Cheap way to avoid 'redefine' errors.

aviriff.h, basetyps.h, combaseapi.h, d2d1.h, gpedit.h:
  - Redefine errors.

mfapi.h:
  - Redefine errors.
  - FCC ('AI44') et al cause 'multichar' compiler warnings.  Ignore
them.

mfidl.h:
  - Redefine errors.

mftransform.h:
  - 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. Using both 'extern' and initializing generates
a warning.

ntdef.h:
  - Redefine errors.

ntsecapi.h:
  - These redefine values that are unconditionally defined earlier
in the same file.

winnt.h:
  - Redefine errors.

dw
diff --git a/mingw-w64-crt/complex/clog10.c b/mingw-w64-crt/complex/clog10.c
index f8545cd..8553e00 100644
--- a/mingw-w64-crt/complex/clog10.c
+++ b/mingw-w64-crt/complex/clog10.c
@@ -44,5 +44,6 @@
 
 /* double version of the functions.  */
 #define  _NEW_COMPLEX_DOUBLE 1
+#define _GNU_SOURCE
 #include "complex_internal.h"
 #include "clog10.def.h"
diff --git a/mingw-w64-crt/complex/clog10f.c b/mingw-w64-crt/complex/clog10f.c
index 36ac497..8ce97d3 100644
--- a/mingw-w64-crt/complex/clog10f.c
+++ b/mingw-w64-crt/complex/clog10f.c
@@ -44,5 +44,6 @@
 
 /* Float version of the functions.  */
 #define  _NEW_COMPLEX_FLOAT 1
+#define _GNU_SOURCE
 #include "complex_internal.h"
 #include "clog10.def.h"
diff --git a/mingw-w64-crt/complex/clog10l.c b/mingw-w64-crt/complex/clog10l.c
index 8baa2aa..11d85c7 100644
--- a/mingw-w64-crt/complex/clog10l.c
+++ b/mingw-w64-crt/complex/clog10l.c
@@ -44,5 +44,6 @@
 
 /* long double version of the functions.  */
 #define  _NEW_COMPLEX_LDOUBLE 1
+#define _GNU_SOURCE
 #include "complex_internal.h"
 #include "clog10.def.h"
diff --git a/mingw-w64-crt/crt/gs_support.c b/mingw-w64-crt/crt/gs_support.c
index dbd95d5..c5c1773 100644
--- a/mingw-w64-crt/crt/gs_support.c
+++ b/mingw-w64-crt/crt/gs_support.c
@@ -26,7 +26,7 @@
 
 typedef LONG NTSTATUS; /* same as in ntdef.h / winternl.h */
 
-#define UNW_FLAG_NHANDLER 0x00
+#define UNW_FLAG_NHANDLER   0x0
 
 typedef union
 {
@@ -99,6 +99,7 @@ __security_init_cookie (void)
 
 __declspec(noreturn) void __cdecl __report_gsfailure (ULONG_PTR);
 
+#define UNUSED_PARAM(x) { x = x; }
 __declspec(noreturn) void __cdecl
 __report_gsfailure (ULONG_PTR StackCookie)
 {
@@ -139,6 +140,7 @@ __report_gsfailure (ULONG_PTR StackCookie)
   GS_ContextRecord.Ecx = StackCookie;
 #elif defined(__arm__) || defined(_ARM_)
   GS_ExceptionRecord.ExceptionAddress = (PVOID) GS_ContextRecord.Pc;
+  UNUSED_PARAM(StackCookie);
 #endif /* _WIN64 */
   GS_ExceptionRecord.ExceptionCode = STATUS_STACK_BUFFER_OVERRUN;

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

2016-08-08 Thread Martin Storsjö 
On Mon, 8 Aug 2016, dw wrote:

> Q3: ARM is giving a bunch of warnings in the form: "dlltool.exe: Syntax error 
> in def file .../mingw-w64-crt/libarm32/powerwmiprovider.def:62."  I have 
> looked at the def file, but I don't understand what I am seeing. How do I 
> diagnose/repair this?

FWIW, I don't know about this, but as far as I know, you can't really use
dlltool to produce implibs for ARM (due to lacking binutils etc), you need
to build genlib (which is bundled in mingw-w64) and use --with-genlib
instead.

Since there are loads of other warnings (as you point out), and other 
bigger issues with the ARM port, I haven't paid attention to whether there 
are warnings int his part for me yet or not.

> Q4: As of 3.8.0, clang (the only compiler I know that builds mingw-w64 for 
> ARM) doesn't support __declspec(selectany) or __attribute__((gcc_struct)) on 
> ARM.  Since (essentially) no one is using this yet, can we assume it will get 
> fixed before people will start using the library?  Or must we code around it? 
> Right now I'm doing a bit of both.

It's not about it being supported on ARM, but about clang not supporting 
it at all, regardless of architecture.

I'd suggest doing

#if defined(__GNUC__) && !defined(__clang__)

instead of

#if defined(__GNUC__) && !defined(__arm__) && !defined(_ARM_)

Then one can later add specific compiler version checks if clang later
starts supporting it (although I doubt it's relevant since it says it's
about a gcc bug workaround).


// Martin

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