Re: [Mingw-w64-public] std::filesystem::copy_options::overwrite_existing & similar still do not work.

Ryan Starrett writes: > The initial bug reports for these problems were started in 2018! > > https://sourceforge.net/p/mingw-w64/bugs/699/ > https://sourceforge.net/p/mingw-w64/bugs/852/ (2020) > > It's been nearly five years. Can we expect a fix to this issue soon? You'll better report it

Re: [Mingw-w64-public] clock_nanosleep patch

Glenn Burkhardt writes: Reading the registry on every call to clock_nanosleep is wasteful. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Reliability of our C++ atomics implementation

LIU Hao writes: > 在 2021-10-30 03:34, Óscar Fuentes 写道: >> I was about to start using in my projects but then bumped into >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037 >> I can reproduce the problem with gcc 11.2 from MSYS2 and, needless >> to >> say

Re: [Mingw-w64-public] Reliability of our C++ atomics implementation

LIU Hao writes: > 在 2021-10-30 03:34, Óscar Fuentes 写道: >> I was about to start using in my projects but then bumped into >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037 >> I can reproduce the problem with gcc 11.2 from MSYS2 and, needless >> to >> say

[Mingw-w64-public] Reliability of our C++ atomics implementation

I was about to start using in my projects but then bumped into https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037 I can reproduce the problem with gcc 11.2 from MSYS2 and, needless to say, pictures as "completely broken". Is the Mingw-w64 community aware of issues like this? Is there any

[Mingw-w64-public] About -mthreads

The gcc documentation for -mthreads says: -mthreads Support thread-safe exception handling on MinGW. Programs that rely on thread-safe exception handling must compile and link all code with the -mthreads option. When compiling, -mthreads defines

Re: [Mingw-w64-public] [PATCH] lib32 msvcrt add mkgmtime exports - XP support?

Adrien Nader writes: > Oh, just one thing: it probably makes more sense to simply state the > support becomes unoffcial for v6. It might work just as much as it might > not and the way to keep the support would be to speak up, provide some > input on the matter and tests. In

Re: [Mingw-w64-public] Problems with finding DLLs

phillip.l...@russet.org.uk (Phillip Lord) writes: > I am having a problem running an application which requires an external > DLL. The strange thing is that it occurs only when build for i686 and > not x86_64 > > I am trying to build the Emacs pretests using mingw-w64 and msys2. On > windows,

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

Óscar Fuentes <o...@wanadoo.es> writes: > Daniel Franzini > <daniel.franz...@gmail.com> writes: > >> I got it. The problem is that identical code is resulting different in two >> different threads and not the fact that the code seems theoretically wrong. > >

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

Daniel Franzini writes: > I got it. The problem is that identical code is resulting different in two > different threads and not the fact that the code seems theoretically wrong. It is worse: spawning a thread affects the results of FP operations on the main thread.

Re: [Mingw-w64-public] Error cross building LLVM for MinGW

Richard Pennington <r...@pennware.com> writes: > On 02/17/2016 04:21 PM, Óscar Fuentes wrote: >> Showing the cmake invocation you used for configuring the build would >> help. If you use a Toolchain-*.cmake file for describing the >> cross-tools to cmake, please show

Re: [Mingw-w64-public] Error cross building LLVM for MinGW

Richard Pennington writes: > I recently switched over to using cmake to build my clang/LLVM based > ELLCC cross development project (http://ellcc.org). I also recently > updated to LLVM svn version 258915 from 258477. > > I use ELLCC to cross compile all the tools for various

Re: [Mingw-w64-public] does linker correctly set the creation date of a PE file ?

Vincent Torri writes: > Can someone confirm that ? If yes, is it possible to fix this ? For obtaining reproducible binaries I had to pass --no-insert-timestamp to the linker. That was last December, using the MSYS2's MinGW-w64 toolchain (32 bits).

Re: [Mingw-w64-public] does linker correctly set the creation date of a PE file ?

Vincent Torri writes: > my point is that the timestamp is incorrect (it is set to 0, which is wrong) Yes, that was clear from your first message. binutils can be cofigured with --enable-deterministic-archives. Maybe your binutils was configured that way? Please note

Re: [Mingw-w64-public] does linker correctly set the creation date of a PE file ?

Vincent Torri writes: >>> Can someone confirm that ? If yes, is it possible to fix this ? >> >> For obtaining reproducible binaries I had to pass --no-insert-timestamp >> to the linker. That was last December, using the MSYS2's MinGW-w64 >> toolchain (32 bits). > > i've

Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'

Edward Diener eldlistmaili...@tropicsoft.com writes: The code is far from being a minimal example, so I didn't look at it all, but I see that the class ex_exception is not exported (EX_VISIBLE expands to ... __visibility__(default)... and you set -fvisibility=hidden in your compile command).

Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'

Edward Diener eldlistmaili...@tropicsoft.com writes: I'm not sure this is a GCC bug. Does the linker error also occur when using static libraries, and when you dllexport the whole class as opposed to the functions you're explicitly defining? I have tried neither. I believe this error is

Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'

Edward Diener eldlistmaili...@tropicsoft.com writes: Another thing is to get some hints from a .map-file. Add -Wl,--print-map,--sort-common,--cref file.map at the of the link-cmd. I could not find any documentation regarding the linker options you specify in the gcc documentation. Are

Re: [Mingw-w64-public] Include and lib search paths for mingw-64

Edward Diener eldlistmaili...@tropicsoft.com writes: Apparently those programmers are not so inconvenienced as you are by having to use methods like the .bat mentioned above. And I can assure you that some of those programmers have quite a few gcc installs on their machines, that they use on

Re: [Mingw-w64-public] Include and lib search paths for mingw-64

JonY jo...@users.sourceforge.net writes: This. This is the reason why it was never changed, because it was never seen as a problem, its just something you did. I setup PATH depending on which compiler version I want to use, all sharing the same mingw-w64 install, courtesy of hardcoded paths.

Re: [Mingw-w64-public] Include and lib search paths for mingw-64

Yaron Keren yaron.ke...@gmail.com writes: Why in the world should I have to put anything in my PATH if these releases are self-enclosed ? I am executing gcc from the exact same directory where the libwinpthread-1.dll exists. I misunderstood you, thought you refer to running compiled apps not

Re: [Mingw-w64-public] Include and lib search paths for mingw-64

Edward Diener eldlistmaili...@tropicsoft.com writes: At the end, adapting your PATH setting works the best. Just a simple .bat file solves the problem for those of us that need to constantly experiment with multiple installs: @rem mingw-w64-492.bat @PATH=path-to-the-bin-directory;%PATH%

Re: [Mingw-w64-public] std::thread and memory leaks

LRN lrn1...@gmail.com writes: Here's a patch to fix this. It does solve the problem for the simple testcase, but i have no idea how it would behave in the wild, i didn't test it on anything else. One might notice that it is set to crash when certain things happen. I'm not sure whether these

Re: [Mingw-w64-public] MinGW LGPL licensed, header-only std::thread implementation

Alex avasi...@gmx.net writes: Hi Martell, I have changed the license as per your request. You can checkout the latest version of the lib with the copyright note. In case you intend to update the contributors list, my data is: Alexander Vassilev, Mega Limited av at mega dot co dot nz If

Re: [Mingw-w64-public] [PATCH 1/2] stdlib.h: Add mkstemp implementation.

Dongsheng Song dongsheng.s...@gmail.com writes: On Thu, Jan 22, 2015 at 1:03 AM, Alexey Pavlov alex...@gmail.com wrote: Current mkstemp implementation call _sopen_s that is not present in WinXP msvcrt.dll. So this break supporting WinXP. I have no WinXP now, but '_sopen_s' in the

Re: [Mingw-w64-public] Out of memory for cc1plus

Edward Diener eldlistmaili...@tropicsoft.com writes: I am seeing an out of memory message of: cc1plus.exe: out of memory allocating 65536 bytes when compiling code using mingw-64 from gcc-4.8.1, gcc-4.8.2, gcc-4.8.3, gcc-4.9.0, and gcc-4.9.1. Nor is this just a mingw-64 problem as I am

Re: [Mingw-w64-public] MinGW LGPL licensed, header-only std::thread implementation

Ruben Van Boxem vanboxem.ru...@gmail.com writes: I'd like to draw your attention to a std::thread implementation written without pthreads. It seems quite lightweight, and almost too small to be fully compliant. If it is at all useful or even completely/nearly bug-free, perhaps it would be

Re: [Mingw-w64-public] quadmath bugs

sisyph...@optusnet.com.au writes: In quadmath.h there's a long list of math library function prototypes, beginning with acosq() ... through to ynq(). On 6/10/2013 I reported (to this list) a problem with expq crashing - and I still haven't struck a mingw-w64 compiler where this has been

Re: [Mingw-w64-public] CMake Toolcahin for linux/clang 3.6

Barnaby Jones si...@xn--schrdingerskatze-pwb.de writes: Error message --- cmake -DCMAKE_TOOLCHAIN_FILE=~/Dokumente/toolchain-ubuntu-mingw64.cmake ../ -- The C compiler identification is Clang 3.6.0 -- The CXX compiler identification is Clang 3.6.0 -- Check for working C compiler:

Re: [Mingw-w64-public] CMake Toolcahin for linux/clang 3.6

Barnaby Jones si...@xn--schrdingerskatze-pwb.de writes: The problems are self-evident: and CMakeError.log -- Determining if the C compiler works failed with the following output: Change Dir: /home/barnaby/Dokumente/sourceProjects/gnustep/libobjc2/build/CMakeFiles/CMakeTmp Run Build

Re: [Mingw-w64-public] CMake Toolcahin for linux/clang 3.6

Ruben Van Boxem vanboxem.ru...@gmail.com writes: As stated, the problem is not related to MinGW-w64, it is about how you configure the CMake/Clang combo for cross-compiling. I beg to differ, and it is quite related to using MinGW-w64. It's just not about GCC. Currently, Clang as-is cannot

Re: [Mingw-w64-public] CMake Toolcahin for linux/clang 3.6

Adrien Nader adr...@notk.org writes: As a project, mingw-w64 wishes to have clang and llvm supported. There have been recent reports of troubles with it however but we'd prefer it to work. Nice. Preferences are a good starting point for achieving things ;-) On the other side, the llvm

Re: [Mingw-w64-public] Windows service built with g++ fails to start, but works when built with gcc

mingw-w64_pub...@baker-research.com writes: [snip] Looking over the documentation of the command-line parameters for gcc and g++ didn't shed any light on this. While trying to resolve this, I have been able to build a service with g++ that did run, but failed when I modified the service to

Re: [Mingw-w64-public] Debugging with GDB

Alexander Shukaev haroo...@gmail.com writes: When the application crashes it shows the following: Fault Module Name: StackHash_e7de Fault Module Version: 0.0.0.0 Fault Module Timestamp: Exception Offset: PCH_E1_FROM_ntdll+0x0009B13A Exception Code: c005

Re: [Mingw-w64-public] Debugging with GDB

Kai Tietz ktiet...@googlemail.com writes: for sure there are some issues in gdb about debugging pe and pe+ coff executables in some scenarios. For pe+ ones the backtrace shown by gdb is much more reliable then for the 32-bit case, as pe+ makes use of the function-tables, which helps on

[Mingw-w64-public] _W64 defined for 32 bits target?

Some developers have been trapped by assuming that _W64 indicates a Windows 64 bits target. But it is defined for 32 bits too: #include math.h #ifdef _W64 int w64 = 0; #endif #ifdef _WIN64 int win64 = 0; #endif The prepocessed output ends with int w64 = 0; This is with $ gcc -v Using

Re: [Mingw-w64-public] Debug application built with mingw64

Edward Diener eldlistmaili...@tropicsoft.com writes: How do I debug a command line application built with Mingw64 on Windows ? Is there a gdb debugger that works natively under Windows or do I need something else ? Yes, native gdb is available in 32 bits and 64 bits variants. I got mine

Re: [Mingw-w64-public] Debug application built with mingw64

niXman i.nix...@autistici.org writes: Yes, native gdb is available in 32 bits and 64 bits variants. I got mine from the MSYS2 project, as well as the compilers and libraries. Why do you propose third-party GDB, when MinGW-W64 distributions provides GDB for 32/64 bits? Maybe I'm not

Re: [Mingw-w64-public] Debug application built with mingw64

niXman i.nix...@autistici.org writes: Óscar Fuentes 2014-08-29 05:33: Maybe I'm not accustomed yet to MinGW-W64 having an official binary distribution. When posting in the MinGW-W64 ML you don't known about official MinGW-W64 binary distribution? Is this a strange joke? ;) No, seriously

Re: [Mingw-w64-public] Big perfomance difference 32/64 bits

Raffaello D. Di Napoli fasti...@gmail.com writes: 2014-08-25 11:25 GMT-04:00 Óscar Fuentes o...@wanadoo.es: On a CPU-intensive application, the 64 bit exe runs 40% slower than its 32 bit counterpart. It's a C++ app with a workload typical of a compiler. Are there known slow spots on the 64

Re: [Mingw-w64-public] Big perfomance difference 32/64 bits

Kai Tietz ktiet...@googlemail.com writes: Are there known slow spots on the 64 bit runtimes? Well, there might be some. I can't actual confirm this finding in general. The load you see is often application-specific. I know about a lot of application, which are actual about 30% faster on

Re: [Mingw-w64-public] exceptions weirdness

JonY jo...@users.sourceforge.net writes: Could the compiler enforce If you link to static libgcc, you should also link libstdc++ statically or at least warn about it? It would save users such mysterious bugs resulting from having two copies of ligcc around. Unfortunately, no, binutils

[Mingw-w64-public] Big perfomance difference 32/64 bits

On a CPU-intensive application, the 64 bit exe runs 40% slower than its 32 bit counterpart. It's a C++ app with a workload typical of a compiler. Are there known slow spots on the 64 bit runtimes? I'm using latest gcc/runtime as shipped by MSYS2. Tried to profile the executables but gprof

Re: [Mingw-w64-public] MinGW-w64 + MSYS: g++ can't include files with unix style prefix?

Richard Shaw hobbes1...@gmail.com writes: I'm working on documenting how to build a project natively in windows, which first means figuring out the quirks myself and I ran into an issue with g++ not being able to find headers with unix style paths /usr/local/include. [snip] If I change the

Re: [Mingw-w64-public] MinGW-w64 + MSYS: g++ can't include files with unix style prefix?

Richard Shaw hobbes1...@gmail.com writes: I'm using MSYS makefiles, otherwise you don't get very far... Tell CMake to use ninja (available as a MSYS2 package.) [snip] -- Infragistics Professional Build stunning

Re: [Mingw-w64-public] 4.9.1. fails to compile project while 4.8.1 succeeds

klo uo klo...@gmail.com writes: [snip] Now that you mention MSYS2, quick Google shows it related to Cygwin, but it seems you use it with MinGW? It looks interesting, can you confirm if you use MSYS2 exclusively with MinGW? MSYS2 is a Cygwin fork, but it comes with a package system that

Re: [Mingw-w64-public] fork is an inbuilt function?

lh_mouselh_mo...@126.com writes: EDIT: since C99, reaching the } that terminates the main function returns a value of 0. 'The returned value is undefined' is not true. If the return value is used(in the case of main(), the host environment cares about it), I already said that undefined

Re: [Mingw-w64-public] 4.9.1. fails to compile project while 4.8.1 succeeds

klo uo klo...@gmail.com writes: I upgraded from 4.8.1 to 4.9.1 (x86_64-4.9.1-release-win32-seh-rt_v3-rev0) and noticed that the package I used to build successfully, now fails. The package is latest hunspell-1.3.3 and it fails with libtool error (failing to match some quote on line 7000 or

Re: [Mingw-w64-public] fork is an inbuilt function?

Ray Donnelly mingw.andr...@gmail.com writes: Hi Ruben, Please take this in the friendly/jokey manner it is intended. This isn't the first time you corrected me on the return value from main when I'm making a test-case to demonstrate a compiler issue; I honestly couldn't care less and my

Re: [Mingw-w64-public] fork is an inbuilt function?

Suresh Govindachar sgovindac...@yahoo.com writes: This isn't the first time you corrected me on the return value from main when I'm making a test-case to demonstrate a compiler issue; I honestly couldn't care less and my goal is to use the minimum amount of characters

Re: [Mingw-w64-public] possible use seh for 32 bit migw-w63 GCC-4.9.1 :

Ruben Van Boxem vanboxem.ru...@gmail.com writes: [snip] Anyways, it's a real clusterf*ck and MS should be ashamed of themselves for letting it come to this. Microsoft? -- Want fast and easy access to all the code in

Re: [Mingw-w64-public] ICE with 4.9 on simple code (regression)

lh_mouselh_mo...@126.com writes: Tip: when preparing a test case it is recommended to remove dependency on library headers since gcc and gcc libraries(here, libstdc++) are developed by different teams, and otherwise people might not be able to tell who went wrong. An ICE is always a compiler

Re: [Mingw-w64-public] problem with compiler not concatenating strings

Jim Michaels jmich...@yahoo.com writes: printf(abc% I64u def, 12);    ^ inttypes-strings.cpp:5:19: error: expected ')' before 'PRSIu64' printf(abc% PRSIu64 def, 12);    ^ inttypes-strings.cpp:5:36: warning: spurious trailing '%' in

Re: [Mingw-w64-public] Getting started building examples that use std::thread

Suresh Govindachar sgovindac...@yahoo.com writes: Upgraded to 4.9.0 (x86_64-posix-seh-rev1, Built by MinGW-W64 project). Tried the above command and the one below -- both give the same pop-up error message from cc1plus.exe about not finding libwinpthread-1.dll: [snip] Perhaps I

Re: [Mingw-w64-public] -console gone, some opt switches seem to force wWinMain

Jim Michaels jmich...@yahoo.com writes: hi folks, one of the things that is causing the problem is -municode. Try replacing `main' with `wmain'. -- Is your legacy SCM system holding you back? Join Perforce May 7 to

Re: [Mingw-w64-public] mingw-w64 may move to git in the future

Adrien Nader adr...@notk.org writes: I quite dislike github and its UI in particular. Uses flash on every page (no idea what for) and lots of javascript which makes my laptop heat and get noisy when displaying something as small as a 3-lines diff. I see no flash at all on Github (it is

Re: [Mingw-w64-public] Why is MSYS2 Git so slow?

Óscar Fuentes o...@wanadoo.es writes: I was hoping to replace my MSYSGit install with MSYS2 + Git, but the later is 4x slower than the former. Same Git version (1.8.4), same command (git status, for example.) Why this difference? Maybe this patch is worth considering for MSYS2: https

Re: [Mingw-w64-public] clang on Windows

Hello Kai, Kai Tietz ktiet...@googlemail.com writes: Sounds interesting. But honestly, llvm (Clang) is for Windows right now pretty unusable. Major basic features of compiler are missing. LLVM is one thing and Clang another. LLVM works fine on Windows. Lacks some features compared to *nix,

Re: [Mingw-w64-public] clang on Windows

Baruch Burstein bmburst...@gmail.com writes: And if I compile it with MinGW then it uses MinGW's toolchain, no? Correct. Does Clang not have it's own toolchain (specifically linker)? They are creating one ( http://lld.llvm.org ) but it is not production-ready yet. llvm-link is for

Re: [Mingw-w64-public] clang on Windows

Ivan Garramona heavenandhell...@gmail.com writes: I think Clang svn uses its integrated assembler. IIRC Clang uses the integrated assembler since a few releases ago. But it still needs GCC for linking though. On Windows, Clang needs MinGW or VS for linking and for the runtime libraries and

Re: [Mingw-w64-public] clang on Windows

Alexpux alex...@gmail.com writes: My 50 cents to this topic. There are some interesting discussion about porting clang to self-hosting on windows http://clang-developers.42468.n3.nabble.com/Porting-libcxxabi-Unwind-to-Windows-MingW-32-bit-td4035390.html AFAIK Clang could use (actually uses?)

Re: [Mingw-w64-public] clang on Windows

Ivan Garramona heavenandhell...@gmail.com writes: Clang+MinGW-w64 is working pretty well for me. For me the inability of creating C++ DLLs (exporting classes and template instantiations) is a show stopper. I had problems with some Boost libraries (boost::thread, IIRC) but that could be fixable.

Re: [Mingw-w64-public] Win-Builds

niXman i.nix...@autistici.org writes: wynfi...@gmail.com 2013-12-12 18:28: ... Win-Builds ... What is this? It was announced yesterday on this list by Adrien Nader. -- Rapidly troubleshoot problems before they

Re: [Mingw-w64-public] How do I file a bug report ?

sisyph...@optusnet.com.au writes: I've read the faq and visited http://sourceforge.net/p/mingw-w64/bugs/. I've even searched the wiki. But I haven't been able to work out how to file a bug report. You need a SF account. Log in with it and you will see a Create ticket on the left side of the

Re: [Mingw-w64-public] What's this Unix environment from Microsoft?

Suresh Govindachar sgovindac...@yahoo.com writes: Has anyone tried the above? Any comments? You might find this article relevant: http://brianreiter.org/2010/08/24/the-sad-history-of-the-microsoft-posix-subsystem/

[Mingw-w64-public] chrono broken (was: Coverage of C++11 library features)

Ruben Van Boxem vanboxem.ru...@gmail.com writes: The libstdc++ online documentation keeps a list here: http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html This should correspond fairly well to what is available on any platform. Of course, there may be deviations (e.g. thread, and

Re: [Mingw-w64-public] chrono broken

Hello Ruben, Ruben Van Boxem vanboxem.ru...@gmail.com writes: This is comparable to the output I get from VS2013. So I would say this is a quality of implementation issue (wrt the resolution of the clock used). I doubt though that this is nonconformant. I didn't look up the exact chrono

[Mingw-w64-public] Why is MSYS2 Git so slow?

I was hoping to replace my MSYSGit install with MSYS2 + Git, but the later is 4x slower than the former. Same Git version (1.8.4), same command (git status, for example.) Why this difference? -- Shape the Mobile

Re: [Mingw-w64-public] Why is MSYS2 Git so slow?

Alexey Pavlov alex...@gmail.com writes: As I know, MSYSGit is hybrid of MSYS shell + MinGW Git. Git there is native Windows application while MSYS2 has posix Git that is slower to work throw posix layer then native application. I was under the impression that the git executable on MSYSGit

[Mingw-w64-public] Coverage of C++11 library features

Is there a list of C++11 standard library features missing on MinGW-W64? -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software

[Mingw-w64-public] MSYS2: wrong disk space used reported by `du'

$ du -sh /lib/git-core 13M /lib/git-core Windows Explorer says that d:/msys32/lib/git-core uses 169 MB. Obviously `du' is wrong because that directory contains lots of executables, using 1.5 MB each. -- November

Re: [Mingw-w64-public] MSYS2: wrong disk space used reported by `du'

Corinna Vinschen vinsc...@redhat.com writes: On Nov 12 13:59, Óscar Fuentes wrote: $ du -sh /lib/git-core 13M /lib/git-core Windows Explorer says that d:/msys32/lib/git-core uses 169 MB. Obviously `du' is wrong because that directory contains lots of executables, using 1.5 MB each

Re: [Mingw-w64-public] MSYS2

Hello Alexey, Alexey Pavlov alex...@gmail.com writes: Yesterday snapshots contain errors that may cause errors during uncompress. Today I upload new snapshots that fix this issue: Just checked the 32-bit package and the issues I reported seem fixed. The banner that informs the user about the

Re: [Mingw-w64-public] MSYS2

John E. / TDM tdra...@tdragon.net writes: With MSYS 1.0, the make job server exposes a race condition in the underlying MSYS DLL code that leads to child make processes freezing up in many cases when trying to run parallel make jobs with the -j command. I've never been able to complete a

Re: [Mingw-w64-public] MSYS2

Alexey Pavlov alex...@gmail.com writes: New MSYS2 snapshots: 32-bit: x32-msys2-20131021.tar.xzhttp://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-20131021.tar.xz/download 64-bit:

Re: [Mingw-w64-public] MinGW64\bin... 32/64 bits compier?

Incongruous incongru...@outlook.com writes: Woe, woe, woe, hold on. Now you really got me confused. According to the book, with Mingw-w64 I can compile in 32 and 64 bits, so which g++ should I use if I want to compile in 32bits..? The same, but with the -m32 switch.

Re: [Mingw-w64-public] tRyIng 2 maKe sence of things

Adrien Nader adr...@notk.org writes: In regards to C++ Exception Models, Avoid Dwarf2, but use SEH when available or SJLJ otherwise. Take into consideration that: a.. SJLJ is slower but compatible with everything (*what is everything in this case?). b.. SEH is the fastest, but it is

Re: [Mingw-w64-public] tRyIng 2 maKe sence of things

Kai Tietz ktiet...@googlemail.com writes: zero cost here means that ordinary (non-exceptional) paths of execution runs at the same speed than a executable with no exceptions enabled. When an exception is thrown, things change: then SEH can be faster than Dwarf2. But on most C++ programs the

Re: [Mingw-w64-public] mingw-w64 v3 release calling for testers

JonY jo...@users.sourceforge.net writes: We will be releasing v3 from trunk soon. Testers, please check with the latest trunk version if any of the changes break your applications! This critical pessimization affecting C++ is still unresolved: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56892

Re: [Mingw-w64-public] The API supported by g++11_64bit

Incongruous incongru...@outlook.com writes: OKay? Code Snip #include memory //share_ptr std::shared_ptrabc::someClass apx; //--Does not work Error g++-c -g -I/c/abc -I/c/abc/gui/msg/ -MMD -MP -MF build/Debug/MinGW64-Windows/_ext/348948719/MyClass.o.d -o

[Mingw-w64-public] Future of exception handling for 32 bit

Since the 64 bit compiler uses SEH and the Borland patent expires next year, I'll like to know how plausible it is to expect SEH on the 32 bit compiler for the gcc 4.9 timeframe. That is, how difficult the implementation is and how much interest it attracts from the developers. This question was

Re: [Mingw-w64-public] dllexport/inline pessimization (hack included)

Hello Kai. Kai Tietz ktiet...@googlemail.com writes: [snip] Thanks for looking into this and for improving my knowledge of GCC. I must admit that I found GCC sources quite arcane. It reminds me of Emacs sources. No wonder, both were started by the same person :-) I tried your patch with one of

[Mingw-w64-public] dllexport/inline pessimization (hack included)

This issue was raised on the sf forum: http://sourceforge.net/p/mingw-w64/discussion/723797/thread/cd8a855f but I very much prefer to use the mailing list. The problem: marking a class as dllexport prevents the inlining of its class methods. I guess the same applies to inline functions. This