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 function
io.c" file and it is working.
Could you/Kai show example 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/fp
function, so I changed
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
"fte
There are wrong folders:
in "Toolchains targetting Win32/" there are "sjlj" & "seh" instead of
"sjlj" & "dwarf"
Please take a look:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.3/threads-posix/
For 64-bit there are also wrong
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 );
**
dxva2.c:265:14: error: implicit declaration of function
'ID3D11VideoContext_DecoderEndFrame' [-Werror=implicit-functi
on-declaration]
hr =
ID3D11VideoContext_DecoderEndFrame(D3D11VA_CONTEXT(ctx)->video_context,
D3D11VA_CONTEXT(ctx)->decoder);
^
cc1.exe:
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 libavfor
).
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 ca
__builtin_va_end( __local_argv );
return __retval;
}
which eats L1 cache for code that on my CPU is only 32 KiB. It makes EXE
file bigger and slower.
W dniu 2015-12-28 o 08:36, Baruch Burstein pisze:
On Thu, Dec 3, 2015 at 12:35 AM, Mateusz <mailto:mateu...@poczta.onet.pl>> wrote:
_T.
t.cpp 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 r
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
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, Ma
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:
https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/dongshe
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
*make[
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-
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 __USE_MINGW_ANSI_S
I've made sample patch + speed up for wide output to file for 'ls'
conversion specifications (only one call to __ms_fwprintf function).
Now works extended sample:
#define __USE_MINGW_ANSI_STDIO 1
#include
#include
#include
int main( void )
{
char *nonTerminated = malloc (1);
wchar_t *n
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
b/m
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 aa198bd.
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
--- a/mingw-w64-headers/include/mem
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
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 del
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
---
mingw-w64-headers/include/setupapi.h | 1 +
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' attribute
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;
^
D:\projekty\msys2\clang\msys64\mingw32\i686-
Fixed patch so it don't remove newline at the end of file.
2016-09-28 11:54 GMT+02:00 Mateusz :
> 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
&& __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 :
> Fixed patch so it don't re
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 yea
.
>
> 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/issues/1712#issue
Can some commit it?
śr., 28 wrz 2016, 16:29 użytkownik JonY
napisał:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 9/28/2016 18:02, Mateusz wrote:
> > Looks attachment didn't work. Here is the patch:
> >
> >> From e98ec7a116256108831f03
east16_t char16_t;
> typedef uint_least32_t char32_t;
> #endif
> Regardless it is in master now.
>
>
> On Mon, Oct 17, 2016 at 4:24 AM, Mateusz wrote:
>
> > Can some commit it?
> >
> > śr., 28 wrz 2016, 16:29 użytkownik JonY
> > napis
e of type 'const wchar_t *'
> if(WSTR_ALIGNED(String)) return wcsrchr((PCWSTR)String,Character);
> ^
>
I don't know if it is mingw-w64 or Clang bug so I'm asking here for some
help with it.
Here are our patches:
https://github.com/
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: M
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
-I/home/ma/m/target/x86_64-w64-mingw32
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 = __popcnt
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
unsigned __int64 ulr = __popcnt64(ul[i]);
^~
_popcnt64
D:\msys64\mingw64\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 20:1
_popcnt64
D:\msys64\mingw64\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 :
> I think ms-extensions was made default option for mingw and msvc clang an
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
+
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
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
f:\msy
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" but
W dniu 2017-05-03 o 23:14, Mateusz pisze:
> We could consider define DECLSPEC_SELECTANY to __attribute__((weak)) for old
> GCC.
>
> Patch for this attached.
Sorry for this patch -- it's not wo
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
>> some
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 2f
,
> Kai
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 :
>> We really should do something with '__in' and '__out' from driverspecs.h.
>>
>> Please revie
fair. But
> to enforce dependency to it in general feels wrong.
>
> Cheers,
> Kai
If user wants driverspecs.h and include it, the problem still exists. There
should be no macros '__in' and '__out' for GCC.
We could add in
ea 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
ase] | %[Base],%[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
-
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
Date: Mon, 22 Jan 2018 20:58:48 +0100
Subject: [PATCH] intrin-impl.h: do not
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
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
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
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
>>>>
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).
C
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.
>>>
>>>
W dniu 31.08.2018 o 14:38, Martin Storsjö pisze:
>> On Aug 31, 2018, at 14:05, Mateusz wrote:
>>
>> 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 Stors
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]
ing
> it to the right value 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 simp
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
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'
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.
>>
>&g
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
W dniu 01.11.2018 o 15:33, Liu Hao pisze:
> 在 2018/11/1 9:52, Mateusz 写道:
>> 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) &&
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 realize
ving directory '/home/ma/m/build/bc_m64_head'
Makefile: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
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) &
ders/crt/ctype.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
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.
>>
&g
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.
R
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_t s
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
hat I described (you 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
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
>>
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
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 coul
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
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.
>>>
>>>
>>>
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.
>>>
>>>
>>>
It is 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
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/fse
ouble 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 m
cpp/c-runtime-library/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:
ingw-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
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
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:
> 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
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
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 b
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
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.
>>
>>
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,
PT;
GetSaveFileNameW(&Ofn);
return 0;
}
Mateusz@Mateusz-i7 /f/b/ma-gcc/c
$ gcc -Wall -o t.exe t.c
f:/msys/m32-741/bin/../lib/gcc/i686-w64-mingw32/7.4.1/../../../../i686-w64-mingw32/bin/ld.exe:
C:\Users\Mateusz\AppData\Local\Temp\cc290RXt.o:t.c:(.text+0x46): undefined
reference to `_imp__GetSaveF
sted?) 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-experimenta
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.
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
EFINE_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
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
9387: 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
>
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 <
>
1 - 100 of 161 matches
Mail list logo