Activity for niXman
-
niXman posted a comment on ticket #962
On 2023-02-03 17:25, Ryan Livingston wrote: hi, you are using a very old version of the toolchain. the new versions are located here: github.com/nixman/mingw-builds-binaries [bugs:#962] during GIMPLE pass: slsr ... internal compiler error: Segmentation fault Status: open Group: v1.0 (example) Created: Fri Feb 03, 2023 05:25 PM UTC by Ryan Livingston Last Updated: Fri Feb 03, 2023 05:25 PM UTC Owner: nobody Attachments: - spline_preproc.cpp (62.4 kB; text/plain) I'm seeing a segfault when compiling...
-
hi, the latest builds you can get here: https://github.com/niXman/mingw-builds-binaries/releases best! On 2022-02-05 21:41, blake danek wrote: Does anyone have tips to get around this issue? [bugs:#558] the file has been downloaded incorrectly! Status: closed-fixed Group: v1.0 (example) Created: Sat Aug 27, 2016 10:18 PM UTC by Jim Michaels Last Updated: Sat Feb 05, 2022 09:36 PM UTC Owner: niXman that's the message I get from the installer. instead of installing to default C:\Program Files\mingw-w64\i686-6.2.0-posix-dwarf-rt_v5-rev0,...
-
done
-
Crash during destruction of thread_local objects
-
Crash during destruction of thread_local objects
-
Broken 32 bit executables (GZDoom)
-
Rafael Kitover 2018-04-08 09:40: Or do I need to file a bug with them? Yes. -- Regards, niXman Work for Bitcoins Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows: https://sf.net/p/mingw-w64/
-
libstdc++ built with weakrefs causes problems mixing C and C++ code
-
Rafael Kitover 2018-04-08 06:25: Hi, See discussion here: https://github.com/Alexpux/MINGW-packages/issues/1580 Patch I use is: https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-gcc/0016-disable-weak-refs-in-libstdc%2B%2B.patch Thanks, but we already have this patch: https://github.com/niXman/mingw-builds/blob/master/patches/gcc/gcc-6.1-disable-weak-refs.patch -- Regards, niXman Work for Bitcoins Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows: https://sf.net...
-
philippe dunski 2018-04-07 17:50: In the future C++ header file, on line 195 for #if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1) and on line 655 for #ifndef _GLIBCXX_ASYNC_ABI_COMPAT. In this file, we have one accessible without any condition pre declaration of the template <>future class (in line 127) , but its complete definition is protected by those two conditions... in order to use 'std Thread support library'(http://en.cppreference.com/w/cpp/thread) you should to...
-
philippe dunski 2018-04-07 14:28: Hi, Hi niXman, You were right: all non sjlj packages compile the Qt framework fine, with both win32 and linux threads support. pthreads - posix threads, not linux threads ;) I have just a last problem for two of its modules, whose are using std::future : the complete definition of this class is protected by both #if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1) and #ifndef _GLIBCXX_ASYNC_ABI_COMPAT where can you see this #ifdefs? -- Regards,...
-
philippe dunski 2018-04-06 17:26: Ooppsss... Sorry. Here is it Attachments: - qrandom.cpp (51.0 kB; text/plain) Try to change this file like this: see attach -- Regards, niXman Work for Bitcoins Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows: https://sf.net/p/mingw-w64/
-
philippe dunski 2018-04-06 17:10: But, them tries to compile Qt with official packages ( at least i686-7.3.0-release-win32-sjlj-rt_v5-rev0.7z official package ) As far as I can remember, they use builds with DWARF exceptions, not sjlj. i.e.: i686-7.3.0-release-win32-dwarf-rt_v5-rev0.7z -- Regards, niXman Work for Bitcoins Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows: https://sf.net/p/mingw-w64/
-
philippe dunski 2018-04-06 17:10: Hi, at global\qrandom.cpp:121 Where can I see this file? -- Regards, niXman Work for Bitcoins Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows: https://sf.net/p/mingw-w64/
-
philippe dunski 2018-04-02 19:36: Hi, When trying to define MINGW_HAS_SECURE_API in the correct file to configure Qt, i got the error " _mingw_secapi.h : c:\mingw\x86_64-w64-mingw32\include_mingw_secapi.h:11:51: error: operator '==' has no left operand #if defined(cplusplus) && (MINGW_HAS_SECURE_API == 1) " Why not define it as '1'? -- Regards, niXman Work for Bitcoins Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows: https://sf.net/p/mingw-w64/
-
__MINGW64_VERSION_BUGFIX
-
__MINGW64_VERSION_BUGFIX
-
del
-
And, this bug also occurs when MinGW-W64-7.1/7.2 is used? Also, please provide the full link to the MinGW-W64-GCC build used.
-
As I can see this bug is occurs in the llvm-tblgen.exe proc. Can you please rebuild clang as release+debug_info and debug it?
-
https://github.com/niXman/mingw-builds/tree/master/mingw-builds-install
-
i have no free time for do it at the moment, sorry...
-
Why this bug issue is closed? because: https://sourceforge.net/p/mingw-w64/bugs/558/#99a5
-
initializer_list in 6.4.0 interprets lperen as start of list rather than lcurly
-
FindFirstFile, FindFirstFileEx, FindNext not working - lockout?
-
labels for goto causes errors in c++, what about flex and bison?
-
https://wandbox.org/permlink/Iaz2zgH4DMW5pKNh
-
std::string for no good reason throws length or null errors
-
std::ifstream>>n>>std::endl; doesn't work for >>endl anymore
-
initializer_list nonfunctional for vector.push_back() and structure within structure assigns
-
istream cannot handle std::endl anymore
-
Missing c++11 system error condition mapping
-
mingw-w64-install fails behind firewall
-
multiple local lobraries not allowed with g++ -c
-
+1
-
Include order affects selection of printf and __mingw_printf
-
iostream clog exponent sign not always correct
-
primes not an allowed variable id name.
-
https://sourceforge.net/p/mingw-w64/bugs/558/#99a5
-
Include order affects selection of printf and __mingw_printf
-
printf doesn't like %lf?
-
prime a reference and not a declaration?
-
gcc -o somefile.o somefile.c requires WinMain?
-
gcc version 7.1.0 (i686-win32-sjlj-rev1, Built by MinGW-W64 project) so the v5 runtime I guess? (is there a way to find out the runtime release version out of curiosity???) yes, v5.x branch patches are welcom ;)
-
gcc version 7.1.0 (i686-win32-sjlj-rev1, Built by MinGW-W64 project) so the v5 runtime I guess? (is there a way to find out the runtime release version out of curiosity???) yes, v5.x branch
-
strtold leaks heap memory
-
done: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/450309b97b2e839ea02887dfaf0f1d10fb5d40cc/
-
fix for bug 647
-
Merge branch 'master' of ssh://git.code.sf.net/p/mingw-w64/mingw-w64
-
Because we use malloc() without free(): https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-crt/misc/strtold.c#l90
-
Done: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/03474d2a2dcc43d9811f1d1e0e2eaf64c6c813b9/
-
Merge branch 'v5.x' of https://git.code.sf.net/p/mingw-w64/mingw-w64 into v5.x
-
fix for my "fix" for 051971
-
wcstof returns incorrect pointer when unable to perform the conversion
-
Sorry, my bad. Fixed: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/4e62ecef6a9b16438bb43b331e5c36844de94ef6/ Doug, thanks!
-
fix for my "fix" for 051971
-
<thread> library missing? namespace conflict?
-
compiler confused by decorations
-
regression: source code held old with stale cache
-
7.1.0 sjlj win32 compiler errors on operator<< for std::ostream
-
<regex> is very broken. gcc folks say theirs works
-
Good job, J. Bierema! But, please fill the bug report on the GCC's bugzilla: https://gcc.gnu.org/bugzilla/
-
Good job, J. Bierema! But, please fill the bug report on GCC's bugzilla: https://gcc.gnu.org/bugzilla/
-
Merge branch 'master' of ssh://git.code.sf.net/p/mingw-w64/mingw-w64
-
fix for previous commit
-
_wstat64i32 fails on path ending with slash, causing failure in the filesystem library
-
Done for master: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/32ec57d19d9678f0be7c4ecb2b251dba10d860e6/
-
_mingw_no_trailing_slash() for _stat64i32() and _wstat64i32()
-
_wstat64i32 fails on path ending with slash, causing failure in the filesystem library
-
Patch #34 What are you talking about?
-
https://sourceforge.net/p/mingw-w64/bugs/558/#99a5 https://sourceforge.net/projects/mingw-w64/files/?source=navbar
-
https://sourceforge.net/p/mingw-w64/bugs/558/#99a5
-
7.1.0
-
с++11 mismatch in standard library c++ streams implementation
-
Please test the gcc-7.1 builds. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145#c30
-
This is because SF uses mirrors, and each of the mirrors can behave differently. In addition to this, some mirrors today may behave in one way, and tomorrow - in another way. The only solution I see is to host the builds on a separate hosting.
-
What about 7.1 version? I have no solution yet...
-
cpp macros mis-preprocessed in 7.1.0
-
please report to GCC bugzilla. closed as invalid.
-
macros do not pass muster in cpp preprocessor
-
please report to GCC bugzilla. closed as invalid.
-
error generator has for loop generating same 10 errors for every template/class error
-
please repost to GCC bugzilla. closed as invalid.
-
std::thread not functioning in 7.1.0
-
#include <iostream> #include <thread> int main() { std::thread th([](){std::cout << "ping!" << std::endl;}); th.join(); } works as expected with any build using posix threads. closed as invalid.
-
LLD built with mingw-w64-based GCC deadlocks
-
I can catch a deadlock! I'll try to investigate this...
-
How many virtual cores is VM configured with? 1 =) Sorry, I'll retest now...
-
it deadlocks for me even if built with no optimization. The same result. Did you...
-
Compiled using: g++ -O2 partest.cpp -opartest -pthread Executed as: for i in seq...
-
Compiled using: g++ -O2 partest.cpp -opartest -pthread
-
Using gcc-6.3.0-x86_64 on MSYS2 your code always print 50075028, but not deadlocks....
-
Attached partest.cpp is completly self-contained. ?
-
Mingw-w64 installer Start Menu shortcuts misplaced
-
Can't install Mingw
-
Can't install Mingw
-
Cannot download repository.txt
-
Installer cannot download repository.txt
1 >