Re: [Mingw-w64-public] Problems when building NT kernel drivers with GCC / LD

On Mon, 28 Nov 2022, 08:08 Jan Beulich via Gcc, wrote: > On 26.11.2022 20:04, Pali Rohár wrote: > > On Monday 21 November 2022 08:24:36 Jan Beulich wrote: > >> But then, with you replying to > >> me specifically, perhaps you're wrongly assuming that I would be > >> planning to look into

Re: [Mingw-w64-public] std::regex freezes in Japanese locale

On Sun, 24 Jan 2021 at 08:15, Liu Hao wrote: > > 在 2021-01-24 02:05, Hannes Domani via Mingw-w64-public 写道: > > Am Samstag, 23. Januar 2021, 16:46:18 MEZ hat Jeroen Ooms > > Folgendes geschrieben: > > > >> A user of the R programming language has reported that std::regex > >> causes a hang for

Re: [Mingw-w64-public] Fwd: [patch] Reimplement GNU threads library on native Windows

On 02/07/19 12:15 +0200, Jacek Caban wrote: On 02/07/2019 12:12, Jacek Caban wrote: On 02/07/2019 11:57, Liu Hao wrote: 在 2019/7/2 下午5:19, Eric Botcazou 写道: It seems inappropriate to use handles as thread identifiers (as handles imply resource ownership and are not unique identifiers);

Re: [Mingw-w64-public] Fwd: [patch] Reimplement GNU threads library on native Windows

On 02/07/19 20:14 +0800, Liu Hao wrote: 在 2019/7/2 下午8:00, Jonathan Wakely 写道: The C++ standard says: "The library may reuse the value of a thread::id of a terminated thread that can no longer be joined." So that's not a reason to use a handle. According to MSDN [1] a thread I

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

On 25 October 2017 at 12:24, Liu Hao wrote: > 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 th

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

On 25 October 2017 at 02:50, Liu Hao wrote: > 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

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

On 16 May 2017 at 11:09, Jonathan Wakely <jwakely@gmail.com> wrote: > On 16 May 2017 at 11:01, Liu Hao wrote: >> On 2017/5/16 17:35, Jonathan Wakely wrote: >>> >>> On 11 May 2017 at 17:55, David Grayson wrote: >>>> >>>> Hello, gcc-he

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

On 16 May 2017 at 11:01, Liu Hao wrote: > On 2017/5/16 17:35, Jonathan Wakely wrote: >> >> On 11 May 2017 at 17:55, David Grayson wrote: >>> >>> Hello, gcc-help. >>> >>> There is an incompatibility between libstdc++ and the headers provided >

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

On 11 May 2017 at 17:55, David Grayson wrote: > Hello, gcc-help. > > There is an incompatibility between libstdc++ and the headers provided > by Microsoft and mingw-w64, because libstdc++ uses __in as a parameter > name in several places while the Microsoft headers define __in as a > preprocessor

Re: [Mingw-w64-public] Adding a new thread model to GCC

On 18 April 2016 at 10:57, Jonathan Wakely wrote: > On 18 April 2016 at 10:18, lh_mouse wrote: >>> I don't see why it has to be a struct, it just has to be suitable as >>> an argument to the relevant __gthread functions. >> >> The type __gthread_time_t is reference

Re: [Mingw-w64-public] Adding a new thread model to GCC

On 18 April 2016 at 08:39, lh_mouse wrote: > I have added a thread model and added its corresponding header files. But it > failed the linker. > > The file 'gcc/libgcc/config/i386/t-mingw-pthread' which contained two lines: > SHLIB_PTHREAD_CFLAG = -pthread > SHLIB_PTHREAD_LDFLAG =

Re: [Mingw-w64-public] Adding a new thread model to GCC

On 17 April 2016 at 17:56, lh_mouse wrote: > A glance over gthr.h reminds me __gthread_time_t. There seem few requirements > documented in gthr.h. > I discussed this with Adrien Nader on mingw-w64's mailing list a few days ago. > > Specifically, here are the two questions: > 0)

Re: [Mingw-w64-public] Adding a new thread model to GCC

On 13 April 2016 at 10:17, lh_mouse wrote: > Hi all, > > The 'win32' thread model of gcc has been there since long long ago, being > compatible with very old Windows versions, also having a number of drawbacks: > 0) its implementation is very inefficient, and > 1) its mutexes and condition

Re: [Mingw-w64-public] toUpper()

On 30 June 2015 at 23:58, p...@arbolone.ca wrote: I would like to write a function to capitalize letters, say... std::wstring toUpper(const std::wstring wstr){ for ( auto it = wstr.begin(); it != wstr.end(); ++it){ global_wapstr.append(std::towupper(it)); } } This doesn’t work,

Re: [Mingw-w64-public] GCCG with C++11

On 28 May 2015 at 18:22, Martin Sebor wrote: [*] The Feature Testing Recommendations For C++ proposal (N4440 being the latest I could find) tries to alleviate it by providing test macros for individual features. I know Clang implements parts of it but don't know what its status is in GCC.

Re: [Mingw-w64-public] I am in a in-path

On 28 May 2015 at 00:15, Hotmail (ArbolOne) wrote: I know, I know, this is not a C++ question, but, as I said, I am in a in-path, I don't know what to do in this case. I have no idea what an in-path is (impasse?) but you've sent another off-topic post that is not about GCC. For general

Re: [Mingw-w64-public] GCCG with C++11

On 28 May 2015 at 16:51, Martin Sebor wrote: The standard specifies that implementations conforming to C++ 11 must define the __cplusplus macro to 201103L, and recommends that non-conforming compilers (presumably those that aim to be C++11 conforming but whose support is incomplete) should use

Re: [Mingw-w64-public] GCCG with C++11

On 28 May 2015 at 16:24, Hotmail (ArbolOne) arbol...@hotmail.ca wrote: If I am not mistaken _MSC_VER = 1600 is the version that started implementing C++11. So, I test for that version of the compiler in my code, i.e. #ifdef _MSC_VER = 1600 #endif I would like to do the same for

Re: [Mingw-w64-public] Thoughts on supporting the C++11 thread library on Windows

On 10 May 2012 15:03, K. Frank wrote: Neither of these shows --enable-threads of any flavor (in gcc -v), but both show Thread model: win32 in the gcc -v output. Yep, if you don't explicitly configure with --enable-threads then the configure script picks a suitable default, which is win32 on

Re: [Mingw-w64-public] Thoughts on supporting the C++11 thread library on Windows

On 7 May 2012 18:35, K. Frank wrote: Hello Ruben and Gabriel! N.B. I'm not on the mingw lists, so please keep me CC'd if you want responses or any help from me in enhancing libstdc++ to work better on Windows. And my P.S.:  As I mentioned in my earlier post, I have been using Ruben's

Re: [Mingw-w64-public] Thoughts on supporting the C++11 thread library on Windows

, Jonathan Wakely jwakely@gmail.com wrote: For GCC 4.7 I enabled most of thread (without timed mutexes) on Mac OS X by making the _GLIBCXX_HAS_GTHREADS macro more fine-grained.  I think we could quite easily do the same again for the win32 thread model (defined in gthr-win32.h) so

Re: [Mingw-w64-public] Thoughts on supporting the C++11 thread library on Windows

On 9 May 2012 16:58, K. Frank wrote: Hello Jonathan! I've taken the liberty of cross-posting this to the mingw list (a separate project from mingw-w64), as they are the other big windows-focused downstream consumer of gcc. On Wed, May 9, 2012 at 9:29 AM, Jonathan Wakely jwakely

Re: [Mingw-w64-public] Thoughts on supporting the C++11 thread library on Windows

On 9 May 2012 17:28, Earnie Boyd wrote: On Wed, May 9, 2012 at 11:58 AM, K. Frank kfrank2...@gmail.com wrote: Again, I'm not all that big on backward compatibility, and, as noted above, I don't understand what  --enable-threads=win32 is for.  But my gut reaction is if that the gcc

Re: [Mingw-w64-public] Thoughts on supporting the C++11 thread library on Windows

On 9 May 2012 20:06, K. Frank wrote: However, as noted in my previous post, I have happily done some (limited) windows-api threading programming with Ruben's build (and also did the windows-api threading programming necessary to implement thread), If you use GCC built with

Re: [Mingw-w64-public] Windows/MinGW extension: opening std::fstream with a wstring/wchar_t*

On 27 June 2011 20:50, Ruben Van Boxem wrote: (If it is liked here, I see no reason not to also propose it to LLVM's libc++). Why? libc++ only supports Mac OS X, so adding Windows-only extensions seems pointless. How does the Rogue Wave / Apache stdcxx support whar_t filenames on Windows?

Re: [Mingw-w64-public] Windows/MinGW extension: opening std::fstream with a wstring/wchar_t*

On 26 June 2011 16:06, Ruben Van Boxem wrote: Hi, I have implemented a small patch that mirrors Microsoft's STL extension, where one can use wide strings as an argument to std::(w)fstream. This is very useful on Windows, where, without this extension, there is no way to open an fstream for a

Re: [Mingw-w64-public] Windows/MinGW extension: opening std::fstream with a wstring/wchar_t*

On 26 June 2011 16:26, Jonathan Wakely wrote: On 26 June 2011 16:06, Ruben Van Boxem wrote: No extra #includes are necessary, and for now I #ifdef'ed the extra code with #if _WIN32. Perhaps cleaner would be a configure check for OS or CRT used and a __GLIBCXX* macro to enable