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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

; 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 tha

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

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,

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

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

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

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 &q

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

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

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

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

Re: [Mingw-w64-public] Test

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

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

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

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

> 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

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

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 ta

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

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,

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

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

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

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, >&g

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

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.

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

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

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

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

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

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

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

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

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

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 &l

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

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);

[Mingw-w64-public] [Patch] Fix warning

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

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

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: >>&g

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

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

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

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 defa

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

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

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

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

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

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

Re: [Mingw-w64-public] [PATCH] Revert \"Avoid declaring something extern AND initializing it

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

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

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

Re: [Mingw-w64-public] [PATCH] Revert "Avoid declaring something extern AND initializing it

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

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

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

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

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

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

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

Re: [Mingw-w64-public] DirectWrite additions

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

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

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

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

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

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

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

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

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

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

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

Re: [Mingw-w64-public] _CRTIMP

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

Re: [Mingw-w64-public] [PATCH] variadic functions can't be stdcall

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

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

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(&

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

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); &

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

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

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

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'

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

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

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

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

[Mingw-w64-public] _CRTIMP

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:

[Mingw-w64-public] As obvious?

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

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

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

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

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

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

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

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

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

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

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*

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

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

[Mingw-w64-public] Patch w/o thunderbird

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

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

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