Re: [Mingw-w64-public] Proposition for locking printf

of performance drop with this patch? W dniu 2015-08-02 o 01:43, JonY pisze: On 8/2/2015 06:27, Mateusz wrote: We have 4 functions from printf family that output to FILE stream: printf, vprintf, fprintf, vfprintf We have also puts/fputs functions that output to FILE stream and are always directly from

[Mingw-w64-public] Proposition for locking printf

We have 4 functions from printf family that output to FILE stream: printf, vprintf, fprintf, vfprintf We have also puts/fputs functions that output to FILE stream and are always directly from msvcrt.dll. puts/fputs functions are atomic with Microsoft lock. If we want mingw-w64 printf

Re: [Mingw-w64-public] Proposition for locking printf

to _ftime64. W dniu 2015-08-02 o 10:04, JonY pisze: On 8/2/2015 09:15, Mateusz wrote: I'm not diff expert, but I tried git diff -- maybe now is better. Due to problem with new file I copy context of mingw_lock.c to smallest ftello.c -- surprisingly make install works and with new libmingwex.a I

Re: [Mingw-w64-public] winpthreads

Hi, Consider such code: * { pthread_spinlock_t* lock_pointer; pthread_spinlock_t lock_value; lock_pointer = (pthread_spinlock_t*)calloc( 1, sizeof(pthread_spinlock_t) ); pthread_spin_init( lock_pointer, 0 ); lock_value = *lock_pointer; /* == -1 */ free( lock_pointer );

Re: [Mingw-w64-public] Proposition for locking printf

, D3D11VA_CONTEXT(ctx)-decoder); ^ cc1.exe: some warnings being treated as errors make: *** [libavcodec/dxva2.o] Error 1 W dniu 2015-08-28 o 13:04, JonY pisze: On 8/3/2015 07:51, Mateusz wrote: Now _lock_file/_unlock_file are in stdio/mingw_lock.c (new) file. printf_full.diff works out

[Mingw-w64-public] Patch for ffmpeg

I've prepared small patch for _mingw_stat64.h and mkstemp.c files. First problem is that in _mingw_stat64.h header file #define section for _USE_32BIT_TIME_T case is switched from #define new_name msvcrt_function to #define msvcrt_function new_name which is nonsense. ffmpeg in file

Re: [Mingw-w64-public] Patch for ffmpeg

.a). Included new version of the patch which works witch msvcrt.dll and msvcr120.dll. W dniu 2015-12-02 o 20:32, Mateusz pisze: I've prepared small patch for _mingw_stat64.h and mkstemp.c files. First problem is that in _mingw_stat64.h header file #define section for _USE_32BIT_TIME_T case

Re: [Mingw-w64-public] Patch for ffmpeg

p works with GCC 64-bit (msvcrt.dll), GCC 32-bit (msvcrt.dll). It doesn't work with GCC 64-bit with msvcr120.dll: $ g++ -Wall -o t-gcc64-msvcr120.exe t.cpp C:\Users\Mateusz\AppData\Local\Temp\ccmui7l3.o:t.cpp:(.text+0x17): undefined reference to `__imp__ftime' collect2.exe: error: ld returned 1 exit

Re: [Mingw-w64-public] Patch for ffmpeg

:36, Baruch Burstein pisze: On Thu, Dec 3, 2015 at 12:35 AM, Mateusz <mateu...@poczta.onet.pl <mailto:mateu...@poczta.onet.pl>> wrote: Sorry for previous patch -- I often link to msvcr120.dll instead of msvcrt.dll. I didn't know that was possible. How do you do that and why w

[Mingw-w64-public] Revert [ca451a] Handle __CTOR_LIST__ internally within mingw-w64

Hi, I think we should revert commit [ca451a] Handle __CTOR_LIST__ internally within mingw-w64 It is not ready yet and makes serious problems for GCC. Mateusz diff --git a/mingw-w64-crt/crt/gccmain.c b/mingw-w64-crt/crt/gccmain.c index ba50691..fc0e350 100644 --- a/mingw-w64-crt/crt

Re: [Mingw-w64-public] problem in 5.3.1 with fstream, use of ifstream, ofstream cause compile error

It's related to commit [ca451a] Handle __CTOR_LIST__ internally within mingw-w64. Now this commit is reverted and everything is working. Please update yours compilers to versions 20160318:

Re: [Mingw-w64-public] Revert [ca451a] Handle __CTOR_LIST__ internally within mingw-w64

I don't have access rights to apply. If you have ready patch that enables __MINGW_CTOR_LIST__ only when building with clang it will be the best solution before release of ver. 5. If not, please revert this commit -- you have the access rights. Mateusz W dniu 2016-03-01 o 21:31, Martell

Re: [Mingw-w64-public] Problem with [2c5fe3]

JonY already fix this problem with [0bb471]. Thanks! W dniu 2016-04-23 o 17:58, Jean-Baptiste Kempf pisze: > Hello Mateusz, > > On 22 Apr, Mateusz wrote : >> Hi, >> >> Commit [2c5fe3] breaks build of cross compiler on Ubuntu (GCC 4.9.3): >> >> x86_64-w64-

[Mingw-w64-public] Problem with [2c5fe3]

Hi, Commit [2c5fe3] breaks build of cross compiler on Ubuntu (GCC 4.9.3): x86_64-w64-mingw32-dlltool --as-flags=--64 -m i386:x86-64 -k --as=x86_64-w64-mingw32-as --output-lib lib64/libcrtdll.a --input-def /home/ma/m/source/mingw-w64-v5/mingw-w64-crt/lib64/crtdll.def --dllname crtdll.dll

Re: [Mingw-w64-public] [PATCH 2/7] crt: Add e_pow.c to the source list

Sorry for false alarm. The problem is with [553c86] commit and deleted VirtualFree declaration. W dniu 2016-05-21 o 08:33, JonY pisze: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 5/21/2016 11:40, Mateusz wrote: >> Are you sure that this patch works without r

[Mingw-w64-public] Restore deleted VirtualFree declaration

Restore deleted VirtualFree declaration Without VirtualFree declaration I can't compile mingw-w64/gcc toolchain on Ubuntu. Please review. diff --git a/mingw-w64-headers/include/memoryapi.h b/mingw-w64-headers/include/memoryapi.h index 46e18c4..19aeae4 100755 ---

Re: [Mingw-w64-public] [PATCH] headers: Fix VirtualFree declaration scope

I've compiled GCC with this patch and everything is OK. Thanks! W dniu 2016-05-24 o 11:24, Hugo Beauzée-Luyssen pisze: > It is available on desktop apps since XP, and on store apps since > Windows 10 > --- > mingw-w64-headers/include/memoryapi.h | 5 - > 1 file changed, 4 insertions(+), 1

Re: [Mingw-w64-public] [PATCH 2/7] crt: Add e_pow.c to the source list

Are you sure that this patch works without regenerate makefile? W dniu 2016-05-18 o 17:06, Hugo Beauzée-Luyssen pisze: > --- > mingw-w64-crt/Makefile.am | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am > index

[Mingw-w64-public] Problem with _O_U8TEXT mode and msvcrt.dll on Win7

Hi, I have problem with "Hello World" example with _O_U8TEXT mode. Sample code: _setmode(_fileno(stderr), _O_U8TEXT); fputws(L"Hello ", stderr); fwprintf(stderr, L"%ls\n", L"World"); If I compile this code with __USE_MINGW_ANSI_STDIO, it prints nothing, if without

[Mingw-w64-public] Fix mingw wprintf family function for _O_U8TEXT mode

Fix mingw wprintf family function for _O_U8TEXT mode This patch uses __ms_fwprintf function for '%ls', '%lc', '%s', '%c' and literal strings in mingw wprintf family function. It works with _O_U8TEXT mode and is much faster. Please review. diff --git a/mingw-w64-crt/lib32/msvcr100.def.in

[Mingw-w64-public] After last update I can't compile cross-compiler

Hi! After last update by Jonathan Yong [5c7bc5] I can't compile cross-compiler (on Ubuntu). The error message (for 64-bit cross-compiler): /home/ma/m/cross/bin/x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I/home/ma/m/source/mingw-w64-v5/mingw-w64-crt -m64

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

MSYS2 native Clang test-popcnt.cpp: $ clang++ popcnt.cc -std=c++14 popcnt.cc:9:26: error: use of undeclared identifier '__popcnt16' unsigned short usr = __popcnt16(us[i]); ^ popcnt.cc:17:24: error: use of undeclared identifier '__popcnt' unsigned int uir =

Re: [Mingw-w64-public] After last update I can't compile cross-compiler

Hi Jacek, Now it is OK. Thanks! Mateusz W dniu 2017-02-08 o 18:53, Jacek Caban pisze: > Hi Mateusz, > > Thanks for the notice. I just pushed a fix, please retest. > > Jacek > > On 08.02.2017 18:06, Mateusz wrote: >> Hi! >> >> After last update by Jonat

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

com>: > Mateusz, thanks for looking in to this. > > Here are the relevant lines from the clang source code that indicate > that it supports those builtins: > > https://github.com/llvm-mirror/clang/blob/3e45634a7f951c2306e4b368f9fb8c > 8d80c48273/include/clang/Basic/Builtins.def#L76

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

\bin\..\lib\clang\3.9.1\include\popcntintrin.h:90:1: note: '_popcnt64' declared here _popcnt64(long long __A) ^ 3 errors generated. 2017-02-08 22:22 GMT+01:00 Mateusz <mati...@gmail.com>: > I think ms-extensions was made default option for mingw and msvc clang and > codegen

[Mingw-w64-public] [PATCH] stdio.h: Ignore extern "C++" for Clang

Hello, I don't know why it was required but it breaks some cases of using GCC together with Clang as reported here: https://github.com/Alexpux/MINGW-packages/issues/1678 In case attachment didn't work: >From f59cbc266025bc070e05a0d7ad44853b1771c21a Mon Sep 17 00:00:00 2001 From: Mateusz Mik

[Mingw-w64-public] sqrt.patch from bug #567

Hi! There are lots of complaint about sqrt -- see bug #567. Martin Whitaker prepared a patch which I converted to git form for easy apply. Please review. diff --git a/mingw-w64-crt/math/sqrt.def.h b/mingw-w64-crt/math/sqrt.def.h index 602409a..b6f5460 100644 --- a/mingw-w64-crt/math/sqrt.def.h

Re: [Mingw-w64-public] sqrt.patch from bug #567

And version 2 proposed by Kai Tietz. W dniu 2017-02-17 o 10:10, Mateusz pisze: > Hi! > > There are lots of complaint about sqrt -- see bug #567. Martin Whitaker > prepared a patch which I converted to git form for easy apply. > > Please review. diff --git a/mingw-w64-crt

[Mingw-w64-public] [PATCH] setupapi.h: add missing devpropdef.h include

Fix for bug #550 https://sourceforge.net/p/mingw-w64/bugs/550/ >From 6325df027a92d7f5041da022d0a9420c1af531c2 Mon Sep 17 00:00:00 2001 From: mati865 Date: Thu, 25 Aug 2016 11:00:50 +0200 Subject: [PATCH] setupapi.h: add missing devpropdef.h include ---

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

Duplicates weren't issue for a long time. Look here https://github.com/Alexpux/MINGW-packages/issues/1712#issuecomment-247562691 As Laurent noticed this issue started somewhere after rev 4680 (b028d1) dated 2016-07-08 and 4721 (1006bb) dated 2016-08-22. None of *uuid.c source files changed this

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

Hello, Since this commit I'm not able to compile Qt5 with GCC 6.1.0 and 6.2.0 errors: In file included from D:/msys64/mingw64/x86_64-w64-mingw32/include/mfidl.h:73:0, from example.cc:1: D:/msys64/mingw64/x86_64-w64-mingw32/include/mftransform.h:709:47: error: 'selectany'

[Mingw-w64-public] [PATCH] fix uchar.h for Clang

Fixes this error when compiling with clang: "D:\projekty\msys2\clang\msys64\mingw32\i686-w64-mingw32\include\uchar.h:34:24: e rror: cannot combine with previous 'type-name' declaration specifier typedef uint_least16_t char16_t; ^

Re: [Mingw-w64-public] [PATCH] fix uchar.h for Clang

Fixed patch so it don't remove newline at the end of file. 2016-09-28 11:54 GMT+02:00 Mateusz <mati...@gmail.com>: > Fixes this error when compiling with clang: > "D:\projekty\msys2\clang\msys64\mingw32\i686-w64-mingw32\include\uchar.h:34:24: > e rror: cannot combine with

Re: [Mingw-w64-public] [PATCH] fix uchar.h for Clang

lt; 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 4)) +(!defined(__clang__) && (__GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 4))) typedef uint_least16_t char16_t; typedef uint_least32_t char32_t; #endif -- 2.9.1 2016-09-28 11:59 GMT+02:00 Mateusz <mati...@gmail

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

ocks.com>: > Uh oh. > > While I haven't tested it, my gut says it's something like this (attached). > > dw > > > On 9/30/2016 1:35 AM, Mateusz wrote: > >> Duplicates weren't issue for a long time. Look here >> https://github.com/Alexpux/MINGW-packages/i

Re: [Mingw-w64-public] [PATCH] fix uchar.h for Clang

Can some commit it? śr., 28 wrz 2016, 16:29 użytkownik JonY <jo...@users.sourceforge.net> napisał: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 9/28/2016 18:02, Mateusz wrote: > > Looks attachment didn't work. Here is

Re: [Mingw-w64-public] [PATCH] guiddef.h: Use __declspec(selectany) on GUID declarations.

W dniu 2017-05-02 o 13:08, Liu Hao pisze: > On 2017/5/2 18:38, Kai Tietz wrote: >> I think, it is worth a try. In general it looks sensible. > As you wish. For GCC 7.1 and 6.3 the patch is OK. For GCC 5.4 is not -- error compiling ffmpeg: CC libavdevice/dshow.o In file included from

Re: [Mingw-w64-public] [PATCH] guiddef.h: Use __declspec(selectany) on GUID declarations.

We could consider define DECLSPEC_SELECTANY to __attribute__((weak)) for old GCC. Patch for this attached. W dniu 2017-05-03 o 17:19, David Grayson pisze: > By the way, it's really not clear to me what specific solution you are > proposing when you say "ensure each GUID is defined only once"

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

W dniu 2017-05-15 o 08:51, Liu Hao pisze: > On 2017/5/11 23:11, Kai Tietz wrote: >> I would prefer this too, but I don't believe that we can convince >> libstdc++ maintainers to modify their code for this. Sadly the MS' >> platform sdk defines a lot of stuff, which collides some times with >>

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

t about '__in' and '__out' that we recommend '_In_' and '_Out_' in source code instead of '__in' and '__out'. Mateusz > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites,

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

We really should do something with '__in' and '__out' from driverspecs.h. Please review. mingw-w64-headers/include/driverspecs.h | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/mingw-w64-headers/include/driverspecs.h b/mingw-w64-headers/include/driverspecs.h index

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

We could roll back commit [b7f44b]. Now there are new commits and this should be fixed. Mateusz > > > 2017-05-17 12:34 GMT+02:00 Mateusz <mateu...@poczta.onet.pl>: >> We really should do something

[Mingw-w64-public] Problem with GCC 8 and _xgetbv

ter idea how to fix this, it will be appreciated. Mateusz -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-

Re: [Mingw-w64-public] mingw-w64 v5 and gcc 8 fails

W dniu 05.05.2018 o 11:57, JonY via Mingw-w64-public pisze: > On 05/04/2018 02:49 PM, Mateusz wrote: >> The patch is only in master (v6) branch >> https://sourceforge.net/p/mingw-w64/mingw-w64/ci/3ce3e27f044935f19e93e80c43ca695262d484e1/ >> >> JonY could you backpor

Re: [Mingw-w64-public] mingw-w64 v5 and gcc 8 fails

W dniu 06.05.2018 o 04:17, JonY via Mingw-w64-public pisze: > On 05/05/2018 11:46 AM, Mateusz wrote: >> W dniu 05.05.2018 o 11:57, JonY via Mingw-w64-public pisze: >>> On 05/04/2018 02:49 PM, Mateusz wrote: >>>> The patch is only in master (v6) branch >>>>

Re: [Mingw-w64-public] mingw-w64 v5 and gcc 8 fails

The patch is only in master (v6) branch https://sourceforge.net/p/mingw-w64/mingw-w64/ci/3ce3e27f044935f19e93e80c43ca695262d484e1/ JonY could you backport this patch to v5.x branch? Mateusz W dniu 04.05.2018 o 16:32, JonY via Mingw-w64-public pisze: > On 05/04/2018 12:35 PM, Christer Solsko

[Mingw-w64-public] About [PATCH] intrin-impl.h: Use volatile argument for __buildbittesti-based functions.

%[Offset]}" __FLAGSET, "J") in the last line in the second param '__int64 volatile' could/should be without volatile (which is always added by __buildbittesti macro). Apart from that the patch is OK for me. Mateusz --

Re: [Mingw-w64-public] [PATCH] intrin-impl.h: do not define _xgetbv for GCC 8

W dniu 30.01.2018 o 10:51, Jacek Caban pisze: > Hi Mateusz, > > > On 1/22/18 9:18 PM, Mateusz wrote: >> GCC 8 from r248028 has defined function _xgetbv and we should >> avoid double definition of this function. >> >> Please review. >> > > The patc

Re: [Mingw-w64-public] [PATCH] crt: Check whether the linker provides __CTOR_LIST__, don't check for __clang__

W dniu 31.08.2018 o 12:17, Martin Storsjö pisze: > On Aug 31, 2018, at 12:51, Mateusz wrote: >> >> W dniu 30.08.2018 o 09:53, Martin Storsjö pisze: >>>> On Aug 29, 2018, at 18:44, Martell Malone wrote: >>>> >>>> LGTM. >>> >>>

Re: [Mingw-w64-public] [PATCH] crt: Check whether the linker provides __CTOR_LIST__, don't check for __clang__

W dniu 30.08.2018 o 09:53, Martin Storsjö pisze: >> On Aug 29, 2018, at 18:44, Martell Malone wrote: >> >> LGTM. > > Pushed this version. > > // Martin It's not working for me (when I build gcc on ubuntu). Could

[Mingw-w64-public] [PATCH] intrin-impl.h: do not define _xgetbv for GCC 8

GCC 8 from r248028 has defined function _xgetbv and we should avoid double definition of this function. Please review. Mateusz From 5aa15ee4a5f04cdc797deb685d23dc67275af357 Mon Sep 17 00:00:00 2001 From: Mateusz <mateu...@poczta.onet.pl> Date: Mon, 22 Jan 2018 20:58:48 +0100 Subject:

Re: [Mingw-w64-public] inttypes Format Specifiers

W dniu 27.10.2018 o 13:46, Vincent Torri pisze: > On Fri, Oct 26, 2018 at 11:58 PM Mateusz wrote: >> >> W dniu 26.10.2018 o 22:35, Tom Ritter pisze: >>> This is not really a MinGW problem, but MinGW does diverge from other >>> compilers and it caused Firefox to c

Re: [Mingw-w64-public] inttypes Format Specifiers

e in the first place, we don't need to redefine it later. Now if it is defined __USE_MINGW_ANSI_STDIO and stdio.h is NOT included, it is I64x, with your patch it is changed to llx (that not works with msvcrt.dll without miracles from stdio.h). Maybe it is simpler to leave *_pop.h and *_push.h l

[Mingw-w64-public] [PATCH] Always define __USE_MINGW_ANSI_STDIO as 0 or 1 in _mingw.h

Regards, Mateusz From fdd383cbb0e636c609c19f78f1c0655d94f0c4e5 Mon Sep 17 00:00:00 2001 From: Mateusz Date: Thu, 1 Nov 2018 01:07:37 +0100 Subject: [PATCH] Always define __USE_MINGW_ANSI_STDIO as 0 or 1 in _mingw.h We check state of __USE_MINGW_ANSI_STDIO in many places. This patch checks all corn

Re: [Mingw-w64-public] inttypes Format Specifiers

W dniu 30.10.2018 o 13:59, Jacek Caban pisze: > On 10/28/2018 10:28 PM, Mateusz wrote: >> W dniu 28.10.2018 o 16:07, Jacek Caban pisze: >>> >>> On 28/10/2018 09:39, Liu Hao wrote: >>>> 在 2018/10/27 19:52, Jacek Caban 写道: >>>>> I don't se

Re: [Mingw-w64-public] inttypes Format Specifiers

W dniu 30.10.2018 o 17:04, Liu Hao pisze: > 在 2018/10/30 23:48, Mateusz 写道: >> Liu Hao example is the explanation. >> printf("value = %" PRIx64 "\n", value); >> should print 64-bit int 'value' regardless stdio.h is included or not. >> >> > &

Re: [Mingw-w64-public] inttypes Format Specifiers

W dniu 26.10.2018 o 22:35, Tom Ritter pisze: > This is not really a MinGW problem, but MinGW does diverge from other > compilers and it caused Firefox to crash. > > MinGW defines a lot of I64[foo] format specifiers in inttypes.h. > clang and clang-cl don't use I64[foo] they use ll[foo]. (I64[foo]

Re: [Mingw-w64-public] [PATCH] Always define __USE_MINGW_ANSI_STDIO as 0 or 1 in _mingw.h

W dniu 04.11.2018 o 10:30, Liu Hao pisze: > 在 2018/11/3 4:28, Mateusz 写道: >> I've attached new version of this patch that works with current tip. >> >> I've added patch 0002 that sets printf format attribute according to new >> logic in inttypes.h. >> >> Reg

Re: [Mingw-w64-public] [PATCH] inttypes.h: Take into account __USE_MINGW_ANSI_STDIO and msvcrt version instead of depending on _mingw_print_p*.h headers.

file:542: recipe for target 'all' failed make: *** [all] Error 2 Should I do something special to test this patch? Regards, Mateusz ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] Always define __USE_MINGW_ANSI_STDIO as 0 or 1 in _mingw.h

W dniu 01.11.2018 o 14:16, JonY pisze: > On 11/01/2018 01:52 AM, Mateusz wrote: >> During discussion about inttypes I realized that we check (in header files) >> if >> __USE_MINGW_ANSI_STDIO is active in non consistent way: >> #if defined(__USE_MINGW_ANSI_STDIO) &

Re: [Mingw-w64-public] [PATCH] Always define __USE_MINGW_ANSI_STDIO as 0 or 1 in _mingw.h

W dniu 01.11.2018 o 16:06, Earnie via Mingw-w64-public pisze: > On 11/1/2018 10:53 AM, Earnie wrote: >> >> >> On 11/1/2018 10:33 AM, Liu Hao wrote: >>> 在 2018/11/1 9:52, Mateusz 写道: >>>> During discussion about inttypes I rea

Re: [Mingw-w64-public] [PATCH] timeb.h: declare _ftime32 function, define _ftime according to _USE_32BIT_TIME_T

W dniu 05.11.2018 o 16:53, Earnie via Mingw-w64-public pisze: > On 11/4/2018 2:02 PM, Mateusz wrote: > >> (but in _mingw.h we always define _USE_32BIT_TIME_T for 32-bit) > > This is a wrong implementation. 32-bit Windows supports 64-bit time_t. > 32-bit time_

Re: [Mingw-w64-public] [PATCH] timeb.h: declare _ftime32 function, define _ftime according to _USE_32BIT_TIME_T

W dniu 06.11.2018 o 04:58, Earnie via Mingw-w64-public pisze: > On 11/5/2018 11:49 AM, Mateusz wrote: > >> functions. In my patch we use _ftime32 and _ftime64 functions and we define >> _ftime to _ftime32 or _ftime64. It should work on WinXP because _ftime32 is >> alia

[Mingw-w64-public] [PATCH] timeb.h: declare _ftime32 function, define _ftime according to _USE_32BIT_TIME_T

are only _ftime and _ftime64 functions. In header files we could declare *32 functions and define _ftime and _ftime_s according to _USE_32BIT_TIME_T. I've attached patch that do this. Sample program should be compiled with -DMINGW_HAS_SECURE_API option. Please review. Regard

Re: [Mingw-w64-public] [PATCH] headers: Update the threadlocinfo struct for ucrt

type.h > @@ -209,8 +209,13 @@ _CRTIMP int __cdecl ___mb_cur_max_func(void); > #endif > > #define __chvalidchk(a,b) (__PCTYPE_FUNC[(unsigned char)(a)] & (b)) > +#ifdef __MSVCRT_VERSION__ >= 0x1400 And here also. Regards, Mateusz ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] Add _ftime aliases for all msvcr versions

w64/ci/38496499910a580ddc449a7d09f3bc0302767f31/ Regards, Mateusz ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] Add _ftime aliases for all msvcr versions

W dniu 02.01.2019 o 20:27, Johannes Pfau pisze: > Am 02.01.19 um 18:02 schrieb Mateusz: >> W dniu 02.01.2019 o 14:10, Johannes Pfau pisze: >>> BTW: How do you handle branches for the patches? The attached patch >>> is against the v6.x branch. >> I didn't read this,

Re: [Mingw-w64-public] [PATCH] GCC: Introduce xaccess function in libiberty

return 0; > case X_OK: > // On Windows all files are presumed to be executable. > // They can be opened in a command prompt without any arguments. > return 0; > default: > errno = EINVAL; > return -1; > } > ``` ucrtbase.dll is affected t

Re: [Mingw-w64-public] [PATCH] GCC: Introduce xaccess function in libiberty

W dniu 05.01.2019 o 20:59, Johannes Pfau pisze: > Am 05.01.19 um 18:56 schrieb Mateusz: >> ucrtbase.dll is affected too (msvcr100 works OK), so maybe it is better to >> add your access() function to msvcr110/120 and ucrtbase (as a replacement) >> instead of patchi

Re: [Mingw-w64-public] [PATCH] GCC: Introduce xaccess function in libiberty

W dniu 06.01.2019 o 16:17, Liu Hao pisze: > 在 2019/1/6 9:19, Mateusz 写道: >> W dniu 05.01.2019 o 20:59, Johannes Pfau pisze: >> Maybe it would make sense to add this in crt/io.h? There's already a >> __USE_MINGW_ACCESS guarded __mingw_access wrapper function which could be &g

[Mingw-w64-public] MSVC returns aggregate types of up to 8 bytes via EAX register

fun4(void) {     Double v;     v.x = 3.13;     return v; } Mateusz@Mateusz-i7 /c/temp $ g++ -c -Wall -O2 -o t.o t.cpp Mateusz@Mateusz-i7 /c/temp $ objdump -dr t.o t.o: file format pe-x86-64 Disassembly of section .text: <_Z4fun1v>:    0:   f3 0f 10 05 00 00 00    movss 

[Mingw-w64-public] Problems with fseeko64, libstdc++ and ucrt builds

need to execute automake in mingw-w64-crt folder before build). Now I can build and execute x265 (ucrt build). I am not sure if it is the best way -- to make two libmingwex* and only one libstdc++. So my question is -- we should go in this direction or not? Regards, Mateusz diff --git a/mingw

Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro

possible, in order to succeed. Now I'm testing new patch for mingw-w64 so I rebuild GCC 7.3.1 with new patch and binutils from current git -- you can try if ld.exe from this binaries works for you. www.msystem.waw.pl/x265/mingw-gcc731-20181123.7z Regards, Mateusz _

Re: [Mingw-w64-public] Problems with fseeko64, libstdc++ and ucrt builds

W dniu 22.11.2018 o 09:51, Mateusz pisze: > W dniu 21.11.2018 o 23:39, Martin Storsjö pisze: >> On Wed, 21 Nov 2018, Mateusz wrote: >> >>> Problem is in libstdc++.a which uses fseeko64 from libmingwex. >>> >>> My proposition is: >>> we

Re: [Mingw-w64-public] [PATCH] msvcr80: Provide _set_invalid_parameter_handler compat implementation in libmsvcr80.a.

much better but not perfect. Regards, Mateusz ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] msvcr80: Provide _set_invalid_parameter_handler compat implementation in libmsvcr80.a.

W dniu 27.11.2018 o 20:28, Mateusz pisze: > W dniu 27.11.2018 o 17:57, Jacek Caban pisze: >> Signed-off-by: Jacek Caban >> --- >>  mingw-w64-crt/Makefile.am | 8 ++-- >>  1 file changed, 6 insertions(+), 2 deletions(-) > > Thanks! I've added stdio/

Re: [Mingw-w64-public] Problems with fseeko64, libstdc++ and ucrt builds

W dniu 21.11.2018 o 23:39, Martin Storsjö pisze: > On Wed, 21 Nov 2018, Mateusz wrote: > >> Problem is in libstdc++.a which uses fseeko64 from libmingwex. >> >> My proposition is: >> we could build two libmingwex -- libmingwex for msvcrt and libmingwex10 for >>

Re: [Mingw-w64-public] Problems with fseeko64, libstdc++ and ucrt builds

W dniu 26.11.2018 o 23:30, Jacek Caban pisze: > On 11/26/18 10:31 PM, Martin Storsjö wrote: >> On Mon, 26 Nov 2018, Jacek Caban wrote: >> >>> Hi Mateusz, >>> >>> >>> The patch looks mostly good to me. >>> >>> >>>

Re: [Mingw-w64-public] Problems with fseeko64, libstdc++ and ucrt builds

W dniu 26.11.2018 o 23:30, Jacek Caban pisze: > On 11/26/18 10:31 PM, Martin Storsjö wrote: >> On Mon, 26 Nov 2018, Jacek Caban wrote: >> >>> Hi Mateusz, >>> >>> >>> The patch looks mostly good to me. >>> >>> >>>

Re: [Mingw-w64-public] Problems with fseeko64, libstdc++ and ucrt builds

W dniu 26.11.2018 o 12:36, Jacek Caban pisze: > Hi Mateusz, > > > The patch looks mostly good to me. > > > On 23/11/2018 22:37, Mateusz wrote: >> --- a/mingw-w64-headers/crt/stdio.h >> +++ b/mingw-w64-headers/crt/stdio.h >> @@ -609,31 +609,20 @@ int vsnpr

Re: [Mingw-w64-public] Linking fails for GetSaveFileName when cross compiling with MinGW

ple with native mingw-w64 GCC: $ cat t.c #include WCHAR szFile[512]; OPENFILENAMEW Ofn; int main() { Ofn.lStructSize = sizeof(OPENFILENAMEW); Ofn.lpstrFile= szFile; Ofn.nMaxFile = sizeof(szFile)/ sizeof(*szFile); Ofn.Flags = OFN_SHOWHELP | OFN_OVERWRITEPROMPT; GetSaveFileNameW(); retu

[Mingw-w64-public] [PATCH] Add __mingw_access() that works the same for all msvcr*/ucrt libs

Old versions of MSVCRT _access() just ignored X_OK, while the version shipped with Vista, returns an error code. _access() from msvcr110/120 returns an error code for nul file. Signed-off-by: Mateusz Brzostek --- mingw-w64-crt/Makefile.am | 2 +- mingw-w64-crt/misc/mingw-access.c | 53

Re: [Mingw-w64-public] [PATCH] Add __mingw_access() that works the same for all msvcr*/ucrt libs

W dniu 08.01.2019 o 00:49, JonY pisze: > On 1/7/19 5:50 PM, Mateusz wrote: >> Old versions of MSVCRT _access() just ignored X_OK, while the >> version shipped with Vista, returns an error code. >> _access() from msvcr110/120 returns an error code for nul file. >> >>

Re: [Mingw-w64-public] [PATCH] Add __mingw_access() that works the same for all msvcr*/ucrt libs

W dniu 08.01.2019 o 04:33, Liu Hao pisze: > 在 2019/1/8 8:32, Mateusz 写道: >> W dniu 08.01.2019 o 00:49, JonY pisze: >>> On 1/7/19 5:50 PM, Mateusz wrote: >>>> Old versions of MSVCRT _access() just ignored X_OK, while the >>>> version shipped with Vista,

Re: [Mingw-w64-public] [PATCH] Add _ftime aliases for all msvcr versions

W dniu 03.01.2019 o 17:05, Jacek Caban pisze: > On 1/3/19 4:47 PM, Jacek Caban wrote: >> Hi Mateusz, >> >> On 1/2/19 5:45 PM, Mateusz wrote: >>> W dniu 02.01.2019 o 16:32, JonY via Mingw-w64-public pisze: >>>> On 1/2/19 1:10 PM, Johannes Pfau wrote:

Re: [Mingw-w64-public] [PATCH] Add _ftime aliases for all msvcr versions

y/reference/ftime-ftime32-ftime64?view=vs-2017 there is an example program. I've tested this example in 64-bit GCC msvcrt/msvcr120/ucrtbase + 32-bit GCC msvcrt/msvcr120/ucrtbase -- all works. Could you specify example that not works? Regards, Mateusz Test results: $ m64- 82 Mateusz@Mateu

Re: [Mingw-w64-public] --enable-experimental breaks as

W dniu 27.01.2019 o 18:40, Christer Solskogen pisze: > On 26.01.2019 01:01, Mateusz wrote: > >> For me it looks OK. > > Which version of binutils? It's fixed in master branch. $ gcc -v && ld -v Using built-in specs. COLLECT_GCC=f:\msys\m64-83\bin\gcc.exe COLLECT_LTO_

Re: [Mingw-w64-public] [PATCH 2/2] corecrt_wstdlib.h: Add new file and move some relevant declaration to it.

t; __DEFINE_CPP_OVERLOAD_SECURE_FUNC_SPLITPATH(errno_t,_wsplitpath_s,wchar_t,_Dest) > - > -#endif > -#endif Now it is deleted one too much '#endif' and then Martin deleted '#ifndef _POSIX_' in [55cc16]. Is this change intentional (delete '#ifndef _POSIX_'/'#endif')? Regards, Mateusz ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 2/2] corecrt_wstdlib.h: Add new file and move some relevant declaration to it.

W dniu 02.03.2019 o 20:12, Martin Storsjö pisze: > On Sat, 2 Mar 2019, Mateusz wrote: > >> W dniu 28.02.2019 o 18:31, Jacek Caban pisze: >>> diff --git a/mingw-w64-headers/crt/sec_api/wchar_s.h >>> b/mingw-w64-headers/crt/sec_api/wchar_s.h >>> index ef53aa

Re: [Mingw-w64-public] --enable-experimental breaks as

) with mingw-w64-crt configured with "--enable-experimental" I get > this (on Windows). Could you post your mingw-w64-crt configure options to reproduce the problem (did you use --enable-experimental all or --enable-experimental pri

Re: [Mingw-w64-public] --enable-experimental breaks as

W dniu 25.01.2019 o 10:48, Christer Solskogen pisze: > On 25.01.2019 10:43, Mateusz wrote: >> W dniu 21.01.2019 o 21:20, Christer Solskogen pisze: >>> I've successfully built a multilib compiler on linux targeting both >>> x86_64-w64-mingw32 and i686-w64-mingw32. Usi

Re: [Mingw-w64-public] [PATCH] crt/websocket: move websocket to lib-common

W dniu 24.12.2019 o 17:05, Liu Hao pisze: > 在 2019/12/24 23:29, Mateusz 写道: >> Hi, >> >> After this patch I can't build cross compiler under Ubuntu: >> * >> rm -f lib64/libmincore.a >> cd lib64/ && x86_64-w64-mingw32-ar -M < >>

Re: [Mingw-w64-public] [PATCH] crt/websocket: move websocket to lib-common

387: recipe for target 'lib64/libmincore.a' failed make[1]: *** [lib64/libmincore.a] Error 9 * Regards, Mateusz W dniu 07.12.2019 o 15:56, Biswapriyo Nath pisze: > ... > > > > ___ > Mingw-w64-public mailing list > Mingw-w64-publ

Re: [Mingw-w64-public] getc skips "0D" in binary file

setmode(fileno(stdin), O_BINARY); Regards Mateusz W dniu 30.11.2021 o 11:11, David Webb pisze: Sorry if this is old hat - an archives search showed there may have been some discussion of getc and 0D but the query returned 9770 messages and I gave up after the first few hundred. A C linux

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

Hello Jacek, With this patch clang builds example code from first message with and without `-fms-extensions`. I can provide prebuild clang-svn pacakge for msys2. Thanks, Mateusz 2017-02-16 15:06 GMT+01:00 Jacek Caban <ja...@codeweavers.com>: > Hi Mateusz, > > Could you please t

Re: [Mingw-w64-public] Fwd: mungw-w64-v5.0.1

> ./configure --build alias - -host -alias --target -alias It is wrong, because there is no arch named 'alias'. Look at https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-crt-git/PKGBUILD#L57 , "${MINGW_CHOST}" is expanded as 'x86_64-w64-mingw32'. 2017-02-25 8:50 GMT+01:00 Adrien

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

quired patching clang and llvm and working around misc problems I don't quite remember in details. I haven't tried but I doubt it will be smooth. 2017-02-17 12:55 GMT+01:00 Jacek Caban <ja...@codeweavers.com>: > Hi Mateusz, > > On 17.02.2017 00:06, Mateusz Mikuła w

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

It explains why my patches created with `git format-patch` couldn't make it. Their mime type is `text/x-diff`. -- Original Message -- Subject: Re: [Mingw-w64-public] [PATCH] Use LPCVOID instead of 'const LPVOID' for VerQueryValue Date: Mon, 20 Mar 2017 00:13:44 -0500 To:

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

From: Liu Hao > On 2017/3/20 22:34, Mateusz Mikuła wrote: >> It explains why my patches created with `git format-patch` couldn't >> make it. >> >> Their mime type is `text/x-diff`. > Isn't it our mail clients that guess MIME types of attachments? The diff >

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

To: Mingw-w64-public From: Nightstrike > On Mon, Mar 20, 2017 at 9:34 AM, Mateusz Mikuła <mati...@gmail.com> wrote: >> It explains why my patches created with `git format-patch` couldn't >> make it. >> >> Their mime type is `text/x-diff`. > I added text

  1   2   >