Re: [Mingw-w64-public] [PATCH] comment out '__in' and '__out' from driverspecs.h for compatibility with libstdc++

On 2017/5/17 23:04, David Grayson wrote: > Now that I think about it again, given that driverspecs.h does not > define __in or __out, I am actually in favor of Mateusz's patch now, > because it will make mingw-w64 closer to the official Windows headers. ... no, because you no longer have `__in` or

[Mingw-w64-public] [PATCH] Fix compiler errors on MinGW-w64 due to identifier collision with macros.

The attached patch was generated by running the following command in GCC source tree cloned from git://gcc.gnu.org/git/gcc.git : --- $ git checkout gcc-7-branch $ nano libstdc++-v3/doc/xml/manual/appendix_contributing.xml # Append the fol

Re: [Mingw-w64-public] [Patch] normalize strftime and strftime_l

On 2017/5/22 2:05, Martell Malone wrote: > Context: libc++ uses strftime_l now > > Please Review The DEF files are generated from DLLs. I don't have Win10 at hand so I have asked jon_y on IRC to update them. -- Best regards, LH_Mouse ---

Re: [Mingw-w64-public] [Patch] normalize strftime and strftime_l

On 2017/5/22 18:43, JonY wrote: > On 05/22/2017 07:57 AM, Liu Hao wrote: >> On 2017/5/22 2:05, Martell Malone wrote: >>> Context: libc++ uses strftime_l now >>> >>> Please Review >> The DEF files are generated from DLLs. I don't have Win10 at hand

Re: [Mingw-w64-public] [PATCH] Add flag for symlink creation by unprivileged users

On 2017/5/27 21:35, JonY wrote: On 05/27/2017 11:14 AM, Samuel Leslie wrote: The MSDN documentation doesn't appear to have been updated yet: https://msdn.microsoft.com/en-us/library/windows/desktop/aa363866(v=vs.85).aspx But you can find the details on the official developer blog: https://blogs

Re: [Mingw-w64-public] [PATCH] Add flag for symlink creation by unprivileged users

On 2017/5/28 11:50, Samuel Leslie wrote: Oh dear. Take two! *crosses fingers* Thanks for the patch, I pushed it to master. -- Best regards, LH_Mouse -- Check out the vibrant tech community on one of the world's most

Re: [Mingw-w64-public] C++ cout executable size

On 2017/6/2 20:21, bob by wrote: 2017-06-02 16:05 GMT+04:00 JonY : On 06/02/2017 11:47 AM, bob by wrote: Wonder why including bloats my exe file so much (extra 900 KiB, with statically linked libraries), even if nothing from there is used. Why cout requires so much code. It includes st

Re: [Mingw-w64-public] C++ cout executable size

On 2017/6/3 0:18, bob by wrote: Can't find the code of std::ios_base::Init It should be somewhere in here, but I can't find it: https://gcc.gnu.org/onlinedocs/gcc-6.3.0/libstdc++/api/a00801.html Why do you want to find its source? It is merely the answer to your previous question: `#include

Re: [Mingw-w64-public] Default _WIN32_WINNT version too low?

On 2017/6/12 23:17, Martell Malone wrote: In that case, I think the best course of immediate action is to bump to Windows 7 as Kai suggested. If someone has the time to implement a configure option for changing this default like Ruben suggest that would be a great. Here is a patch for the former.

Re: [Mingw-w64-public] [PATCH] remove cast to int from mantissa for __mingw_printf

/ 8 = 1` hence the result is correct. But it still does not agree with `printf` from MSVCRT. -- Best regards, LH_Mouse From ff27b6d4d605b8296f814855f183e790b65183d3 Mon Sep 17 00:00:00 2001 From: Liu Hao Date: Thu, 15 Jun 2017 11:43:15 +0800 Subject: [PATCH] mingw-w64-crt/stdio/mingw_pformat.c:

Re: [Mingw-w64-public] mingw-w64-tools - configure.ac and Makefile.am for autoconf

On 2017/6/15 14:00, J. Peter Mugaas wrote: I hope this works. Please send attachments in plain text formats. If your client has trouble doing that, you can usually force it by adding a `.txt` extension. Don't forget to carry a copy of the patch inline. -- Best regards, LH_Mouse ---

Re: [Mingw-w64-public] Does clang sanitizers supposed to work on mingw64?

On 2017/6/20 2:16, Lev Serebryakov wrote: Hello Mingw-w64-public, I have installed: mingw-w64-x86_64-clang 4.0.0-1 mingw-w64-x86_64-clang-analyzer 4.0.0-1 mingw-w64-x86_64-clang-tools-extra 4.0.0-1 mingw-w64-x86_64-compiler-rt 4.0.0-1 And I could not link project which is compiled with UB

Re: [Mingw-w64-public] [PATCH] strsafe.h: Added missing _STRSAFE_EXTERN_C in cases when inlining is disables.

On 2017/6/20 1:40, Jacek Caban wrote: Please review. Signed-off-by: Jacek Caban --- mingw-w64-headers/include/strsafe.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) We might have to test this patch with different `-std=` options with different optimization levels because of di

Re: [Mingw-w64-public] how to printf() 64-bit integer in 64-bit compiler in strict ISO mode with all warnings enabled?

On 2017/6/22 6:30, Lev Serebryakov wrote: Hello Lev, Wednesday, June 21, 2017, 11:41:45 PM, you wrote: So, I need to printf() uint64_t in my project, which is built in strict ISO C11 mode and with all warnings enabled. If I try to use "%llu" I get warning that "unknown conversion type c

Re: [Mingw-w64-public] how to printf() 64-bit integer in 64-bit compiler in strict ISO mode with all warnings enabled?

On 2017/6/25 21:11, Lev Serebryakov wrote: Hello Kai, Friday, June 23, 2017, 5:55:39 PM, you wrote: I've checked and both _POSIX_C_SOURCE=1 and __USE_MINGW_ANSI_STDIO=1 don't affect this define. It should, at least the latter one should show effect. Of course you need to define it before i

Re: [Mingw-w64-public] how to printf() 64-bit integer in 64-bit compiler in strict ISO mode with all warnings enabled?

On 2017/6/26 19:04, Lev Serebryakov wrote: On 25.06.2017 20:39, Liu Hao wrote: I've checked and both _POSIX_C_SOURCE=1 and __USE_MINGW_ANSI_STDIO=1 don't affect this define. It should, at least the latter one should show effect. Of course you need to define it before including

Re: [Mingw-w64-public] how to printf() 64-bit integer in 64-bit compiler in strict ISO mode with all warnings enabled?

Patch attached. -- Best regards, ltpmouse From 35656690a3eb69ac5694de27081e9213df2eec79 Mon Sep 17 00:00:00 2001 From: Liu Hao Date: Tue, 27 Jun 2017 23:57:39 +0800 Subject: [PATCH] mingw-w64-headers/crt/_mingw_print_pop.h: Do not check for _INC_STDIO or _WSTDIO_DEFINED any more, as there

Re: [Mingw-w64-public] [PATCH] amended function prototype of function 'glob' in glob.h

On 2017/7/3 19:04, Jannick wrote: Attached a tiny patch to glob.h which remedies a function prototype definition error thrown upon compilation. On one of cygwin's user lists I was deferred to this one here. I bumped into that issue when compiling with cygwin's i686-pc-mingw32. I am hoping t

Re: [Mingw-w64-public] [PATCH] VirtualProtect problem in pseudo-reloc.c

On 2017/7/9 14:06, Arthur D. Edelstein wrote: Hi, I am proposing a patch here to deal with a problem found in a cross-compiled Tor Browser and Tor Expert Bundle. Using VMMap on Windows, we observed Execute/Read/Write (XRW) and Execute/Copy-on-Write pages (X/COW) in some DLLs and the Tor executabl

Re: [Mingw-w64-public] [PATCH] VirtualProtect problem in pseudo-reloc.c

On 2017/7/10 22:34, Kai Tietz via Mingw-w64-public wrote: Hi, yes, the patch looks fine to me. Your changes looking fine to me. Nevertheless we should just put this code change just in master, as we need to let people test new code. Please go ahead and commit to master. Thanks, Kai Done. --

Re: [Mingw-w64-public] FW: Section sizes too big in object files (possible bug?)

On 2017/8/2 19:42, Madalinski Piotr wrote: Hi all, I'm having trouble with getting correct section sizes under MinGW. The example below demonstrates the issue: (... abridgement ...) Adding align(1) attribute to the data definition is a workaround, that fixes the problem, but due to external f

Re: [Mingw-w64-public] [Project News|New Builds]

On 2017/8/15 3:22, Adrien Nader wrote: On Mon, Aug 14, 2017, niXman wrote: Norbert Pfeiler 2017-08-14 18:19: What do you want the contents to be? (regarding it currently shows 2 versions) I usually update Msys2 and Arch where only 1 version applies. will be better if you explain how I can upd

Re: [Mingw-w64-public] [Project News|New Builds]

On 2017/8/15 15:16, Adrien Nader wrote: On Tue, Aug 15, 2017, niXman wrote: Liu Hao 2017-08-15 05:59: When I click the Register button the page reloads and nothing happens thereafter. +1 Have you checked your emails, including the spam folder? Yes. There are no such mails. -- Best

Re: [Mingw-w64-public] [Project News|New Builds]

has been devised but not deployed yet. This should happen soon but in the meantime I have created and configured an account for you and Liu Hao by hand. I will send the credentials by mail in a minute. Gotcha. Thanks for your work! :> -- Best regards, LH_Mo

Re: [Mingw-w64-public] [PATCH] headers: Add casts in ua_wcs*chr in stralign.h

On 2017/8/25 19:09, Mateusz Mikuła wrote: There was discussion if this should be done via cast or union, both versions were attached at some point of [1] discussion. [1] https://sourceforge.net/p/mingw-w64/mailman/message/35923114/ C-style casts shall suffice. I don't see why we have to introdu

Re: [Mingw-w64-public] [PATCH 3/3] headers: Remove accidental double semicolons

On 2017/9/6 13:14, Martin Storsjö wrote: Signed-off-by: Martin Storsjö --- mingw-w64-headers/crt/stdio.h | 2 +- mingw-w64-headers/ddk/include/ddk/wdm.h | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) These three patches look good to me. -- Best regards, LH_Mouse

Re: [Mingw-w64-public] Problems with using printf format specs with GCC 7

On 2017/9/13 0:15, Eli Zaretskii wrote: You'd need to disassemble (or at least check with nm) the object/function to find out if it's calling __mingw_printf or regular printf, seems like emacs is using %lld and %I64 in different places. %lld is used for intmax_t values, %I64d is used for 64-bit

Re: [Mingw-w64-public] [PATCH] winpthreads/src/dll_math.c: Implement `__divmoddi4()' for GCC 7.

On 2017/9/27 20:21, Christer Solskogen wrote: On 08-May-17 12:32, Kai Tietz wrote: ok, please apply. Was this ever applied? It seem still to happen with latest 5.x branch. Jon would you please cherry-pick it to v5.x? Thanks. -- Best regards, LH_Mouse -

Re: [Mingw-w64-public] [PATCH] winpthreads/src/dll_math.c: Implement `__divmoddi4()' for GCC 7.

On 2017/9/27 20:32, Liu Hao wrote: On 2017/9/27 20:21, Christer Solskogen wrote: On 08-May-17 12:32, Kai Tietz wrote: ok, please apply. Was this ever applied? It seem still to happen with latest 5.x branch. Jon would you please cherry-pick it to v5.x? Thanks. Eventually, SF is back

Re: [Mingw-w64-public] no WIN32 predefined macro with -std=c++{98, 11, 14}, only with gnu++{98, 11, 14}

On 2017/10/12 15:10, Frédéric wrote: Hi, I am using mingw w64 5.0.2 on a linux machine with gcc/g++ 7.2.0. I noticed that the macro WIN32 is: - defined if -std=gnu++{98,11,14,17} - not defined if -std=c++{98,11,14,17} why such difference? A library I try to cross-compile tests for WIN32 and fa

Re: [Mingw-w64-public] no WIN32 predefined macro with -std=c++{98, 11, 14}, only with gnu++{98, 11, 14}

On 2017/10/12 17:14, Frédéric wrote: However, why does w64 treat differently -std=gnu++XX than -std=c++XX? This does not look consistent to me as WIN32 is not concerned by the standard. It is GCC that does that, not MinGW-w64. The standard does not treat `WIN32` particularly, but the rule is s

Re: [Mingw-w64-public] _ftelli64 bug

On 2017/10/19 18:22, Mateusz Mikuła wrote: You can try linking to different version of runtime library [0] like MSVC does by default. [0] https://stackoverflow.com/questions/3402252/how-to-link-against-msvcr90-dll-with-mingw-gcc MSVCR90 have been in the DLL hell for a decade so linking against

Re: [Mingw-w64-public] GCC 7.2 build bugs on Windows 8.1 and Windows 10

On 2017/10/24 23:55, Jonathan Wakely wrote: On 23 October 2017 at 15:55, David Gressett wrote: gcc needs some substantial patching to to build on Windows. The details depend on whether you are building a 64-bit or a 32-bit gcc. There are two projects on Sourceforge which deal with gcc on Windo

Re: [Mingw-w64-public] GCC 7.2 build bugs on Windows 8.1 and Windows 10

On 2017/10/25 18:35, Jonathan Wakely wrote: Is this because -std=c99 sets __STRICT_ANSI__? > The C++ runtime is not built with -std=c99, of course. > No. It will not compile despite the `-std=` option, because `_aligned_{malloc,free}` are conditionally `#ifdef`'d out by the following code

Re: [Mingw-w64-public] New bug fix from v5.x release soon

fore this release. -- Best regards, LH_Mouse From 6988618931548eea602319488e60d32557d704c2 Mon Sep 17 00:00:00 2001 From: Liu Hao Date: Thu, 26 Oct 2017 20:48:45 +0800 Subject: [PATCH] mingw-w64-crt/math/modf{,f,l}.c: Fix segment faults in modf(), modff() and modfl(). Reference: https://sourcef

Re: [Mingw-w64-public] New bug fix from v5.x release soon

On 2017/10/27 8:52, David Grayson wrote: The mingw-w64 project has some documentation about how to build a mingw-w64 GCC compiler: https://sourceforge.net/p/mingw-w64/wiki2/Cross%20Win32%20and%20Win64%20compiler/ https://github.com/mirror/mingw-w64/tree/master/mingw-w64-doc/howto-build No you d

Re: [Mingw-w64-public] New bug fix from v5.x release soon

With this patch the crash in question shall not happen on i686 and x86_64 any more. Pushed to master. -- Best regards, LH_Mouse -- Check out the vibrant tech community on one of the world's most engaging tech sites, S

Re: [Mingw-w64-public] Any chance that C++ locales work with g++?

On 2017/11/4 13:47, Frédéric wrote: Hi, I saw that std::locale(local_name) does not work with mingw (throws an exception). Even std::locale("") does not work. What is the reason for that? Any chance that it works some day? Maybe it's a problem with the C++ standard library, not mingw w64? Se

Re: [Mingw-w64-public] New bug fix from v5.x release soon

On 2017/11/4 15:24, Adrien Nader wrote: Good morning, I was looking at the changelog for OCaml 4.06 and noticed the following entry: - MPR#7638: in the Windows Mingw64 port, multithreaded programs compiled to bytecode could crash when raising an exception from C code. This looks like a Mingw6

Re: [Mingw-w64-public] [PATCH 3/3] headers: Fix the ucrtbase version of asprintf

On 2017/11/7 6:19, Martin Storsjö wrote: Signed-off-by: Martin Storsjö --- mingw-w64-headers/crt/stdio.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h index 7365994..cea5559 100644 --- a/mingw-w64-head

Re: [Mingw-w64-public] [PATCH 3/3] headers: Fix the ucrtbase version of asprintf

On 2017/11/7 13:19, Martin Storsjö wrote: Not really, it mostly comes from whichever wording was used in the place it was copypasted from. Since these identifiers aren't visible outside of the inline function, I don't see how it would matter. If you feel strongly about it, there's a huge number

Re: [Mingw-w64-public] [PATCHv2 3/3] headers: Fix the ucrtbase version of asprintf and vasprinf

On 2017/11/7 14:23, Martin Storsjö wrote: __attribute__ ((format (__MINGW_PRINTF_FORMAT, 2, 0))) I think this should be `__attribute__((__format__ ... ))`, as in `_snprintf`. I just took a look at other functions in , and yes, there are a number of such issues, with a few more (such as th

Re: [Mingw-w64-public] Importing other IDLs from wine

On 2017/11/7 21:55, Jacek Caban wrote: On 07.11.2017 14:42, Shinchiro Shinchiro wrote: At the moment, only directx idl is imported from wine. I want to suggest you to import other IDLs from wine/include too if it doesn't break anything. That's not really true, there are some other IDLs. I occa

Re: [Mingw-w64-public] Calling wprintf from a C++ program

On 2017/11/9 12:13, David Lee wrote: Hello. I have an issue that isn't necessarily related to mingw-w64. Could be gcc/g++, libstdc++ or even my mistake. Let me have a starting point here. (... abridged ...) > [Question] Did I do something wrong or is the issue not related to mingw-w64? (it looks

Re: [Mingw-w64-public] Calling wprintf from a C++ program

On 2017/11/9 15:46, David Lee wrote: Thanks for the reply. You are welcome. :> (1) Your observation seems to apply to the whole *wprintf() family (fwprintf(), swprintf(), etc), not just wprintf(). It seems so. I am not clear how libstdc++ is making use if these functions. If they didn't ev

Re: [Mingw-w64-public] swscanf() crashes if __USE_MINGW_ANSI_STDIO is defined

On 2017/11/11 12:41, David Lee wrote: Hello, Tried to compile and run the following C code on Windows (with gcc/mingw-w64), and it crashed at the swscanf() call: #define __USE_MINGW_ANSI_STDIO 1 #include int main(void) { wchar_t buf[] = L"1 2 3"; wchar_t field[10]; swsc

Re: [Mingw-w64-public] swscanf() crashes if __USE_MINGW_ANSI_STDIO is defined

On 2017/11/11 21:47, Hannes Domani via Mingw-w64-public wrote: Am Samstag, 11. November 2017, 10:15:00 MEZ hat Liu Hao Folgendes geschrieben: Debugging in assembly exposes indirection through a null pointer in `mingw-w64-crt/stdio/mingw_wvfscanf.c` around or after line 906

Re: [Mingw-w64-public] swscanf() crashes if __USE_MINGW_ANSI_STDIO is defined

On 2017/11/13 11:11, David Lee wrote: Built and tested a cross compiler (i686-w64-mingw32-gcc 6.4.0) on debian stretch with master mingw-w64. Same crash. Yeah I just updated MSYS2's repos and observed the crash... can't imagine why it didn't crash a few days ago. The patch for mingw_vfscanf.c

Re: [Mingw-w64-public] swscanf() crashes if __USE_MINGW_ANSI_STDIO is defined

On 2017/11/14 9:58, Liu Hao wrote: > On 2017/11/13 11:11, David Lee wrote: >> Built and tested a cross compiler (i686-w64-mingw32-gcc 6.4.0) on >> debian stretch with master mingw-w64. Same crash. >> > Yeah I just updated MSYS2's repos and observed the crash... can

[Mingw-w64-public] [PATCH] stdio/mingw_wvfscanf.c: Fix segmentation fault when a char or, string format (without malloc option) is used, like, 72d60c1a06490ec5937e6c620956b167bf0bf329.

roblem in the original post no longer happens on i686 and x86_64. -- Best regards, LH_Mouse From c470391c15e8006c43bc8d3924d1ad44de94ed87 Mon Sep 17 00:00:00 2001 From: Liu Hao Date: Tue, 14 Nov 2017 10:16:24 +0800 Subject: [PATCH] stdio/mingw_wvfscanf.c: Fix segmentation fault when a char or

Re: [Mingw-w64-public] [PATCH] stdio/mingw_wvfscanf.c: Fix segmentation fault when a char or, string format (without malloc option) is used, like, 72d60c1a06490ec5937e6c620956b167bf0bf329.

On 2017/11/15 9:54, Liu Hao wrote: > This patches addresses the issue in > <https://sourceforge.net/p/mingw-w64/mailman/message/36111483/>. > > The C99 standard treats %s, %c, %ls and %lc identically in *scanf and w*scanf, > hence this patch is mer

Re: [Mingw-w64-public] [PATCH] stdio/mingw_wvfscanf.c: Fix segmentation fault when a char or, string format (without malloc option) is used, like, 72d60c1a06490ec5937e6c620956b167bf0bf329.

On 2017/11/17 11:36, Liu Hao wrote: > On 2017/11/15 9:54, Liu Hao wrote: >> This patches addresses the issue in >> <https://sourceforge.net/p/mingw-w64/mailman/message/36111483/>. >> >> The C99 standard treats %s, %c, %ls and %lc identically in *scanf and &

Re: [Mingw-w64-public] Crash with Windows 7

On 2017/11/27 21:55, Jeremy Nicoll wrote: > On Mon, 27 Nov 2017, at 13:03, Ruben Van Boxem wrote: >> It would really helpful there were a backtrace of the crash, so we could >> pinpoint where the problem might lie. > > How does one capture one on Windows? > Compile all your source with `-ggdb` or

[Mingw-w64-public] Definition of `wint_t` violates the standard

Dear all, Today I noticed that `wint_t` is a typedef of `unsigned short`. This is however non-conforming, as the C99 standard says it shall not be changed by default argument promotions. This can be noticed from the following program: ``` E:\Desktop>expand -t4 test.c #include #include int mai

Re: [Mingw-w64-public] [PATCH] crt: Add an ldexpl function for arm and arm64

On 2017/12/17 15:25, Martin Storsjö wrote: > Since long double just is normal double on arm and arm64, just > call the normal ldexp function. > > Signed-off-by: Martin Storsjö > --- > mingw-w64-crt/Makefile.am | 3 ++- > mingw-w64-crt/math/arm/ldexpl.c | 16 > mingw-w

Re: [Mingw-w64-public] [PATCH] crt: Add an ldexpl function for arm and arm64

On 2017/12/18 3:42, Martin Storsjö wrote: > Indeed - I'm amazed that this even compiled... > > // Martin C does not forbid /implicit conversion/ from a pointer to an integer... You probably need to enable `-Werror`. -- Best regards, LH_Mouse ---

Re: [Mingw-w64-public] [PATCHv2] crt: Add an ldexpl function for arm and arm64

On 2017/12/18 3:43, Martin Storsjö wrote: > Since long double just is normal double on arm and arm64, just > call the normal ldexp function. > > Signed-off-by: Martin Storsjö > --- > Fixed the parameters in the C wrappers. > --- > mingw-w64-crt/Makefile.am | 3 ++- > mingw-w64-crt/math/

Re: [Mingw-w64-public] [PATCH] crt: Add linker aliases for utime/_utime/_futime/_wutime for ucrtbase

On 2017/12/19 20:13, Martin Storsjö wrote: > This matches what MSVC does. > > Signed-off-by: Martin Storsjö > --- > mingw-w64-crt/def-include/msvcrt-common.def.in | 2 ++ > mingw-w64-crt/lib-common/ucrtbase.def.in | 4 > 2 files changed, 6 insertions(+) > On my 64-bit Win7 only MSVC

Re: [Mingw-w64-public] [PATCH] intrin-impl.h: Added missing volatile to _interlockedbittestandset and _interlockedbittestandset64 declarations.

On 2018/1/11 6:21, Jacek Caban wrote: > Signed-off-by: Jacek Caban > --- > mingw-w64-headers/include/psdk_inc/intrin-impl.h | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > Hmmm shouldn't the x64 version __buildbittesti(_interlockedbittestandset64, __int64, "lo

Re: [Mingw-w64-public] [PATCH] intrin-impl.h: Added missing volatile to _interlockedbittestandset and _interlockedbittestandset64 declarations.

On 2018/1/12 4:28, Jacek Caban wrote: > > Fixes compilation with clang. > > Signed-off-by: Jacek Caban > --- > mingw-w64-headers/include/psdk_inc/intrin-impl.h | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > If the last parameter to the `__buildbittesti()` macro is

Re: [Mingw-w64-public] [PATCH 2/5] corecrt_startup.h: Added _onexit_table_t and related functions declarations.

On 2018/1/12 4:30, Jacek Caban wrote: > Signed-off-by: Jacek Caban > --- > mingw-w64-headers/crt/corecrt_startup.h | 12 > 1 file changed, 12 insertions(+) > > > > The C standard requires that 'the implementation shall support the registration of at least 32 functions' (see WG14

Re: [Mingw-w64-public] [PATCH 3/5] libmsvcr*.a: Added compatibility implementation of onexit table functions.

On 2018/1/12 4:31, Jacek Caban wrote: > Signed-off-by: Jacek Caban > --- > mingw-w64-crt/Makefile.am | 1 + > mingw-w64-crt/misc/onexit_table.c | 74 > +++ > 2 files changed, 75 insertions(+) > create mode 100644 mingw-w64-crt/misc/onexit_table.c > >

Re: [Mingw-w64-public] [PATCH 2/5] corecrt_startup.h: Added _onexit_table_t and related functions declarations.

On 2018/1/12 15:15, Martin Storsjö wrote: > On Fri, 12 Jan 2018, Liu Hao wrote: > This struct as declared here, has to be the same form as the struct that > ucrtbase.dll uses in this set of functions. Therefore, the extra local > array of 32 elements can't be in this struct

Re: [Mingw-w64-public] Nonexistent "/home/Jeroen" in default cygwin gcc search paths

On 2018/1/12 21:47, Philip Vetter wrote: > Hello, I did an install of cygwin on Windows 10, keeping all defaults. I > tried to compile some sample code from National Instruments which had an > include and a library. Since running make did not find the header > file, I tried to place copies of NIDA

[Mingw-w64-public] [PATCH] winpthreads: Fix prototype of `pthread_attr_{getstackaddr, getschedpolicy}`.

The attached patch adds `const` qualifiers that were missing. -- Best regards, LH_Mouse From 5be179b4611c2174c73ee5947d4d10e031069381 Mon Sep 17 00:00:00 2001 From: Liu Hao Date: Sat, 13 Jan 2018 20:14:42 +0800 Subject: [PATCH] winpthreads: Fix prototype of `pthread_attr_{getstackaddr

Re: [Mingw-w64-public] linux gcc vs mingw-w64 performance ?

On 2018/1/18 9:27, lemonsqueeze wrote: > Ah, found the big one: > Was testing single threaded but code uses __thread thread-local storage > which slows things down a lot on mingw. > > Tried a few alternatives: > - Microsoft TlsGetValue() / TlsSetValue() > - pthread_getspecific() / pthread_setspeci

Re: [Mingw-w64-public] [PATCH] winpthreads: Fix prototype of `pthread_attr_{getstackaddr, getschedpolicy}`.

On 2018/1/27 0:06, Kai Tietz via Mingw-w64-public wrote: > Hey, > > patch is ok. Please go ahead and apply. > > Thanks, > Kai I pushed it to master quite a few days ago. :| -- Best regards, LH_Mouse -- Check out the

[Mingw-w64-public] [PATCH 2/2] include/usbspec.h: Update to newest.

The definitions of `struct _USB_DEVICE_CAPABILITY_BILLBOARD_DESCRIPTOR` and `typedef struct _USB_SUPERSPEEDPLUS_ISOCH_ENDPOINT_COMPANION_DESCRIPTOR` got moved upwards to match their original order in from Win10 SDK 10.0.16299. -- Best regards, LH_Mouse --

[Mingw-w64-public] [PATCH 1/2] include/usbioctl.h: Add required headers for `__C89_NAMELESS` and Windows data types.

This caused trouble when was included after . Reference: https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/usbioctl/ne-usbioctl-_usb_connection_status Signed-off-by: Liu Hao -- Best regards, LH_Mouse From 15bc66f90d5c510c8f85e6da77078670b11ab8d0 Mon Sep 17 00:00:00 2001

Re: [Mingw-w64-public] [PATCH 2/2] include/usbspec.h: Update to newest.

On 2018/1/29 18:37, Liu Hao wrote: > The definitions of `struct _USB_DEVICE_CAPABILITY_BILLBOARD_DESCRIPTOR` > and `typedef struct > _USB_SUPERSPEEDPLUS_ISOCH_ENDPOINT_COMPANION_DESCRIPTOR` got moved > upwards to match their original order in from Win10 SDK > 10.0.16299. >

Re: [Mingw-w64-public] [PATCH 1/2] include/usbioctl.h: Add required headers for `__C89_NAMELESS` and Windows data types.

On 2018/1/29 19:00, Kai Tietz via Mingw-w64-public wrote: > Hey, > > why you include _mingw_mac.h before including minwindef.h ? This seems > to be superflous. The header mingwindef.h includes already _mingw.h, > which includes for sure _mingw_mac.h too. Hmm I added <_mingw_mac.h> for `__C89_NAM

Re: [Mingw-w64-public] Missing header SearchAPI.h in Thunderbird cross-compile using mingw-w64

在 2018/3/2 2:23, Sukhbir Singh 写道: > Hi, > > I am trying to build Thunderbird for Windows on Linux using mingw-w64. (For > the specifics, I am building comm-esr52 THUNDERBIRD_52_6_0_RELEASE tag.) There > seems to be a missing header in mingw-w64, SearchAPI.h > > mail/components/search/nsMailWinS

Re: [Mingw-w64-public] [PATCH] headers: Cast chars to unsigned char before attempting to use as index in arrays

在 2018/3/5 4:43, Martin Storsjö 写道: > This fixes warnings when building libc++, like these: > > libcxx/include/locale:1198:18: warning: array subscript is of type 'char' > [-Wchar-subscripts] > if (!isxdigit_l(*__ns, _LIBCPP_GET_C_LOCALE)) > ^~

Re: [Mingw-w64-public] Deadlock in winpthreads' pthread_cond_signal()

在 2018/3/10 18:14, Sitsofe Wheeler 写道: > Hi, > > It's possible to trigger a deadlock in winpthreads' > pthread_cond_signal() when using the pthread_cond_signal() call > outside of a pthread_mutex_lock()/pthread_mutex_unlock() region. This > problem happens under Windows 2012 R2 with winpthreads-5.

Re: [Mingw-w64-public] GCC Fallthrough warnings.

在 03/10/2018 06:17 PM, jpmug...@suddenlink.net 写道: > I hope this works: Please send a patch generated using `git format-patch`. Don't for get to sign off it with `git commit -s`. -- Best regards, LH_Mouse -- Check out

Re: [Mingw-w64-public] Deadlock in winpthreads' pthread_cond_signal()

在 2018/3/10 20:46, Sitsofe Wheeler 写道: > On 10 March 2018 at 12:38, Liu Hao wrote: >> 在 2018/3/10 20:06, Sitsofe Wheeler 写道: >>> Reattaching example program with .txt extension and just in case you >>> can also download it from http://sucs.org/~sits/test/signalhang.c

Re: [Mingw-w64-public] Oatcg for mingw-w64-crt - Fix fallthrough warnings

在 03/12/2018 11:23 PM, jpmug...@suddenlink.net 写道: > Anyway, the fix adds a macro that I barrowed from Graphite2 and further > modified. > Graphite2 is LGPL's, so copying code from there is not an option. > > > I hope gets through. > > > > Interestingly enough, part of the issue with tool

[Mingw-w64-public] [PATCH] include/winnt.h: involve when attempting to use SSE2

This fixes <https://sourceforge.net/p/mingw-w64/bugs/712/>. Signed-off-by: Liu Hao -- Best regards, LH_Mouse >From d48ee23fb9c6e756f00372850733d96f37e2ff1f Mon Sep 17 00:00:00 2001 From: Liu Hao Date: Fri, 16 Mar 2018 15:59:38 +0800 Subject: [PATCH] include/winnt.h: involve when a

Re: [Mingw-w64-public] [PATCH] headers: Complete the winnt.h structs/defines for ARM64

在 03/19/2018 03:12 AM, Martin Storsjö 写道: > Sync the latest version from wine. > > Signed-off-by: Martin Storsjö > --- > mingw-w64-headers/include/winnt.h | 119 > ++ > 1 file changed, 108 insertions(+), 11 deletions(-) > > This patch looks good to me. B

Re: [Mingw-w64-public] [PATCH] crt: Share odbc32.def between lib64 and libarm32

在 03/20/2018 03:51 PM, Martin Storsjö 写道: > On Wed, 28 Feb 2018, Martin Storsjö wrote: > >> Also provide it for libarm64. >> >> Signed-off-by: Martin Storsjö >> --- >> mingw-w64-crt/lib-common/odbc32.def | 192 >> >> mingw-w64-crt/lib64/odbc32.def  | 190 >>

Re: [Mingw-w64-public] GDB and Microsoft Windows thread pool

在 03/21/2018 12:18 PM, Ruslan Garipov 写道: > As it was suggested on the project's IRC channel, I am opening a preliminary > discussion of my issue in this mailing list. > > I encountered an internal GDB error while was debugging C++ code using > Microsoft > Windows thread pool API[1]. When several

Re: [Mingw-w64-public] [PATCH] headers: Stop using the register storage class for local variables in inline functions

在 2018/3/24 4:58, Martin Storsjö 写道: > The register storage class is deprecated in C++11 and removed in > C++17, and doesn't serve any purpose in these particular instances > in C either. > > Signed-off-by: Martin Storsjö > --- > mingw-w64-headers/crt/stdio.h | 30 +++---

Re: [Mingw-w64-public] [PATCH 0/4] Add Windows 8/8.1 high DPI scaling APIs

在 2018/3/27 20:42, James Ross-Gowan 写道: > This adds shellscaling.h and some related winuser.h APIs from Windows > 8/8.1. > > It covers some of the APIs from the High DPI section on MSDN[1], though > the new mixed-mode scaling APIs from Windows 10 1607 are missing. I have > a patch in the works for

Re: [Mingw-w64-public] [PATCH 3/4] shellscalingapi.h: Add new header file

在 2018/3/27 20:42, James Ross-Gowan 写道: > +#if NTDDI_VERSION >= NTDDI_WIN8 > +STDAPI_(DEVICE_SCALE_FACTOR) GetScaleFactorForDevice(DISPLAY_DEVICE_TYPE > deviceType); > +STDAPI RegisterScaleChangeNotifications(DISPLAY_DEVICE_TYPE displayDevice, > HWND hwndNotify, UINT uMsgNotify, > + DWORD *pdwCo

Re: [Mingw-w64-public] Backport d516b31 to 5.x branch

在 2018/3/29 1:53, Scott Talbert 写道: > Hi, > > Can commit d516b31 please be backported to the 5.x branch? > > Thanks, > Scott > Cherry-picked as 'd713e2226a3ff134d1367e5638f0242640f5a049' on v5.x and pushed. -- Best regards, LH_Mouse -

Re: [Mingw-w64-public] [PATCH 3/4] shellscalingapi.h: Add new header file

在 2018/3/29 19:58, James Ross-Gowan 写道: > Will fix. Is there a line length limit for these header files? Without > the break, this line is over 120 chars. > No. The problem is that, if there are any warnings or errors related to a function, GCC only prints the first line of the declaration in its

Re: [Mingw-w64-public] [PATCH 0/4] Add Windows 8/8.1 high DPI scaling APIs

在 2018/3/29 20:28, James Ross-Gowan 写道: > I can resend these patches as attachments, but will this be a > requirement for future patches? The contribute page[1] says both > git-send-email and git-format-patch forms are allowed and I find it more > convenient to use send-email. I've noticed other pe

Re: [Mingw-w64-public] [PATCH] winreg.h: Add missing WINAPI_PARTITION_DESKTOP guard

在 2018/4/10 21:44, Hugo Beauzée-Luyssen 写道: > > +#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) > + Please clarify the rationale of this patch. Win8 SDK does not have this guard while the Win10 SDK uses a different guard `WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_APP | WINAPI_PARTITION_D

Re: [Mingw-w64-public] Shell is stripping curly braces

在 2018/4/17 7:08, Robert Dailey 写道: > I have been trying to chase down a [bug I found][1] over on the Git > for Windows project. The short version of the issue is that specifying > a parameter like "@{-1}" with a git alias gets converted to "@-1". > Visit link #1 for more detail on that. > > I had

Re: [Mingw-w64-public] MinGW64 AVX Code Generation on Windows 64 Bit

在 2018/4/8 21:39, Royi Avital via Mingw-w64-public 写道: > Hello, > Currently MinGW64 cant generate proper code with AVX / AVX2 on Windows 64 Bit > due to alignment issues. > > Is there a plan to fix this significant issue in the near term? > This is a GCC issue:

Re: [Mingw-w64-public] Hello mingw-64. Can I contribute my std::random_device implementation as mingw-64's implementation?

在 2018/4/29 19:24, sotrdg sotrdg 写道: > Same as mcf-mingw > > https://github.com/euloanty/mingw-std-random_device/blob/master > > This is not the correct place for submitting a bug report/feature request/whatsoever for libstdc++. GCC's configure checks only define the macro `_GLIBCXX_USE_RANDO

[Mingw-w64-public] [PATCH] gendef: Silence warnings about casting function pointers on, GCC 8.

From ea84b4501db5b7f5eb642751c1418ff23afeb11f Mon Sep 17 00:00:00 2001 From: Liu Hao Date: Wed, 2 May 2018 10:48:01 +0800 Subject: [PATCH] gendef: Silence warnings about casting function pointers on GCC 8. GCC 8 warns about casting between incompatible pointer to functions. This can be worked

Re: [Mingw-w64-public] [BUG (suspicious)] gdb crashes when info registers

在 2018/5/3 9:03, 章成凯 写道: Sorry for that. I upload the attachment to google drive and post the link in the bug report: https://sourceforge.net/p/mingw-w64/bugs/731/ I can reproduce this problem on x64 but ATM I have no idea what causes it. This crash is not reproducible on x86. 2018-05-01 1

Re: [Mingw-w64-public] [BUG (suspicious)] gdb crashes when info registers

在 2018/5/3 18:23, Hannes Domani via Mingw-w64-public 写道: 在 2018/5/3 9:03, 章成凯 写道: Sorry for that. I upload the attachment to google drive and post the link in the bug report: https://sourceforge.net/p/mingw-w64/bugs/731/ I'm pretty sure that it's this bug I reported a while ago: https://source

Re: [Mingw-w64-public] [PATCH] gendef: Silence warnings about casting function pointers on, GCC 8.

在 2018年05月02日 10:53, Liu Hao 写道: > From ea84b4501db5b7f5eb642751c1418ff23afeb11f Mon Sep 17 00:00:00 2001 > From: Liu Hao > Date: Wed, 2 May 2018 10:48:01 +0800 > Subject: [PATCH] gendef: Silence warnings about casting function pointers on > GCC 8. > > GCC 8 warns

Re: [Mingw-w64-public] [PATCH] gendef: Silence warnings about casting function pointers on, GCC 8.

在 2018/5/4 20:14, Martin Storsjö 写道: Ok with me. Annoying if GCC now has made this warning even harder to get around... Pushed. This is not an old issue, since C never allows such casts, albeit it is required by POSIX. The warning can still be observed on an older version of GCC with `-pe

Re: [Mingw-w64-public] [PATCH] gendef: Silence warnings about casting function pointers on, GCC 8.

在 2018/5/4 21:06, Liu Hao 写道: 在 2018/5/4 20:14, Martin Storsjö 写道: Ok with me. Annoying if GCC now has made this warning even harder to get around... Pushed. This is not an old issue, since C never allows such casts, albeit it is required by POSIX. The warning can still be observed on an

[Mingw-w64-public] [PATCH] crt/stdio/mingw_pformat.c: Make the %e specifier compliant to C99.

-by: Liu Hao --- mingw-w64-crt/stdio/mingw_pformat.c | 59 ++--- 1 file changed, 3 insertions(+), 56 deletions(-) diff --git a/mingw-w64-crt/stdio/mingw_pformat.c b/mingw-w64-crt/stdio/mingw_pformat.c index 350c6638..7e249321 100644 --- a/mingw-w64-crt/stdio

Re: [Mingw-w64-public] [PATCH] crt/stdio/mingw_pformat.c: Make the %e specifier compliant to C99.

在 2018/5/6 17:44, JonY via Mingw-w64-public 写道: On 05/06/2018 09:14 AM, Liu Hao wrote: Remove the hacks to mimic old MS behavior and hardcode the minimum number of digits of the exponent to 2, as required by C99 and POSIX. If the __USE_MINGW_ANSI_STDIO macro is not defined, the user will be

Re: [Mingw-w64-public] [PATCH] d2d1.h: Work around GCC not being compatible with MSVC in aggregate retuns handling.

在 2018/5/14 23:41, Jacek Caban 写道: Based on patch by Tom Ritter. Tom explained it here: https://sourceforge.net/p/mingw-w64/mailman/message/36238073/ I added WIDL_EXPLICIT_AGGREGATE_RETURNS preprocessor guards so that it's not used then not needed. Signed-off-by: Jacek Caban --- mingw-w64-h

<    3   4   5   6   7   8   9   10   11   12   >