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

[Mateusz]

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 can compile test-stdio.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/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 functions (__USE_MINGW_ANSI_STDIO) to be atomic against
puts/fputs functions, we must copy lock from Microsoft sources.

Microsoft use _lock_file/_unlock_file lock to stdio functions, so patch
for mingw-w64
printf, vprintf, fprintf, vfprintf
functions are obvious -- _lock_file - __pformat - _unlock_file

There is one problem: _lock_file/_unlock_file are exported from
msvcr*.dll starting from version msvcr90.dll. There are no such
functions in msvcrt.dll  msvcr80.dll.

My proposition: we can add obvious patch to mingw-w64 printf functions
family and copy _lock_file/_unlock_file from MS sources and add only to
libmsvcrt.a  libmsvcr80.a.

I attached diff file that is not complete -- there is to do add
mingw_lock.c source to libmsvcrt.a  libmsvcr80.a.


Please resend patch in unified diff form.

I spoke with Kai earlier, he wants __pformat behavior unchanged for
performance reasons, preferring programs to handle their own locking,
you may be able to convince him otherwise.




--


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


diff --git a/mingw-w64-crt/stdio/ftello.c b/mingw-w64-crt/stdio/ftello.c
index 1a63987..31a0b5a 100644
--- a/mingw-w64-crt/stdio/ftello.c
+++ b/mingw-w64-crt/stdio/ftello.c
@@ -3,3 +3,95 @@
 _off_t ftello(FILE * stream){
   return (_off_t) ftello64(stream);
 }
+
+
+
+#include stdio.h
+#include synchapi.h
+#include internal.h
+
+
+_CRTIMP void __cdecl _lock(int locknum);
+_CRTIMP void __cdecl _unlock(int locknum);
+#define _STREAM_LOCKS   16
+#define _IOLOCKED   0x8000
+
+
+/***
+* _lock_file - Lock a FILE
+*
+*Purpose:
+*   Assert the lock for a stdio-level file
+*
+*Entry:
+*   pf = __piob[] entry (pointer to a FILE or _FILEX)
+*
+*Exit:
+*
+*Exceptions:
+*
+***/
+
+void __cdecl _lock_file( FILE *pf )
+{
+/*
+ * The way the FILE (pointed to by pf) is locked depends on whether
+ * it is part of _iob[] or not
+ */
+if ( (pf = (__iob_func()[0]))  (pf = 
(__iob_func()[_IOB_ENTRIES-1])) )
+{
+/*
+ * FILE lies in _iob[] so the lock lies in _locktable[].
+ */
+_lock( _STREAM_LOCKS + (int)(pf - (__iob_func()[0])) );
+/* We set _IOLOCKED to indicate we locked the stream */
+pf-_flag |= _IOLOCKED;
+}
+else
+/*
+ * Not part of _iob[]. Therefore, *pf is a _FILEX and the
+ * lock field of the struct is an initialized critical
+ * section.
+ */
+EnterCriticalSection( (((_FILEX *)pf)-lock) );
+}
+
+
+/***
+* _unlock_file - Unlock a FILE
+*
+*Purpose:
+*   Release the lock for a stdio-level file
+*
+*Entry:
+*   pf = __piob[] entry (pointer to a FILE or _FILEX)
+*
+*Exit:
+*
+*Exceptions:
+*
+***/
+
+void __cdecl _unlock_file( FILE *pf )
+{
+/*
+ * The way the FILE (pointed to by pf) is unlocked depends on whether
+ * it is part of _iob[] or not
+ */
+if ( (pf = (__iob_func()[0]))  (pf = 
(__iob_func()[_IOB_ENTRIES-1])) )
+{
+/*
+ * FILE lies in _iob[] so the lock lies in _locktable[].
+ * We reset _IOLOCKED to indicate we unlock the stream.
+ */
+ pf-_flag = ~_IOLOCKED;
+_unlock( _STREAM_LOCKS + (int)(pf - (__iob_func()[0])) );
+}
+else
+/*
+ * Not part of _iob[]. Therefore, *pf is a _FILEX and the
+ * lock field of the struct is an initialized critical
+ * section.
+ */
+LeaveCriticalSection( (((_FILEX *)pf)-lock) );
+}
diff --git a/mingw-w64-crt/stdio/mingw_fprintf.c 
b/mingw-w64-crt/stdio/mingw_fprintf.c
index 011a634..438941f 100644
--- a/mingw-w64-crt/stdio/mingw_fprintf.c
+++ b/mingw-w64-crt/stdio/mingw_fprintf.c
@@ -50,7 +50,9 @@ int __cdecl __fprintf(FILE *stream, const APICHAR *fmt, ...)
 {
   register int retval;
   va_list argv

[Mingw-w64-public] Proposition for locking printf

[Mateusz]

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 functions (__USE_MINGW_ANSI_STDIO) to be atomic against 
puts/fputs functions, we must copy lock from Microsoft sources.


Microsoft use _lock_file/_unlock_file lock to stdio functions, so patch 
for mingw-w64

printf, vprintf, fprintf, vfprintf
functions are obvious -- _lock_file - __pformat - _unlock_file

There is one problem: _lock_file/_unlock_file are exported from 
msvcr*.dll starting from version msvcr90.dll. There are no such 
functions in msvcrt.dll  msvcr80.dll.


My proposition: we can add obvious patch to mingw-w64 printf functions 
family and copy _lock_file/_unlock_file from MS sources and add only to 
libmsvcrt.a  libmsvcr80.a.


I attached diff file that is not complete -- there is to do add 
mingw_lock.c source to libmsvcrt.a  libmsvcr80.a.


Simplified version of this patch is used without problems in x265 
community -- in message 
http://forum.doom9.org/showthread.php?p=1731962#post1731962
diff -r -c -N a/stdio/mingw_fprintf.c b/stdio/mingw_fprintf.c
*** a/stdio/mingw_fprintf.c Sat Aug  1 18:19:05 2015
--- b/stdio/mingw_fprintf.c Sat Aug  1 20:23:28 2015
***
*** 50,56 
--- 50,58 
  {
register int retval;
va_list argv; va_start( argv, fmt );
+   _lock_file( stream );
retval = __pformat( PFORMAT_TO_FILE | PFORMAT_NOLIMIT, stream, 0, fmt, argv 
);
+   _unlock_file( stream );
va_end( argv );
return retval;
  }
diff -r -c -N a/stdio/mingw_lock.c b/stdio/mingw_lock.c
*** a/stdio/mingw_lock.cThu Jan  1 00:00:00 1970
--- b/stdio/mingw_lock.cSat Aug  1 21:38:55 2015
***
*** 0 
--- 1,89 
+ #include stdio.h
+ #include synchapi.h
+ #include internal.h
+ 
+ 
+ _CRTIMP void __cdecl _lock(int locknum);
+ _CRTIMP void __cdecl _unlock(int locknum);
+ #define _STREAM_LOCKS   16
+ #define _IOLOCKED   0x8000
+ 
+ 
+ /***
+ * _lock_file - Lock a FILE
+ *
+ *Purpose:
+ *   Assert the lock for a stdio-level file
+ *
+ *Entry:
+ *   pf = __piob[] entry (pointer to a FILE or _FILEX)
+ *
+ *Exit:
+ *
+ *Exceptions:
+ *
+ 
***/
+ 
+ void __cdecl _lock_file( FILE *pf )
+ {
+ /*
+  * The way the FILE (pointed to by pf) is locked depends on whether
+  * it is part of _iob[] or not
+  */
+ if ( (pf = (__iob_func()[0]))  (pf = 
(__iob_func()[_IOB_ENTRIES-1])) )
+ {
+ /*
+  * FILE lies in _iob[] so the lock lies in _locktable[].
+  */
+ _lock( _STREAM_LOCKS + (int)(pf - (__iob_func()[0])) );
+ /* We set _IOLOCKED to indicate we locked the stream */
+ pf-_flag |= _IOLOCKED;
+ }
+ else
+ /*
+  * Not part of _iob[]. Therefore, *pf is a _FILEX and the
+  * lock field of the struct is an initialized critical
+  * section.
+  */
+ EnterCriticalSection( (((_FILEX *)pf)-lock) );
+ }
+ 
+ 
+ /***
+ * _unlock_file - Unlock a FILE
+ *
+ *Purpose:
+ *   Release the lock for a stdio-level file
+ *
+ *Entry:
+ *   pf = __piob[] entry (pointer to a FILE or _FILEX)
+ *
+ *Exit:
+ *
+ *Exceptions:
+ *
+ 
***/
+ 
+ void __cdecl _unlock_file( FILE *pf )
+ {
+ /*
+  * The way the FILE (pointed to by pf) is unlocked depends on whether
+  * it is part of _iob[] or not
+  */
+ if ( (pf = (__iob_func()[0]))  (pf = 
(__iob_func()[_IOB_ENTRIES-1])) )
+ {
+ /*
+  * FILE lies in _iob[] so the lock lies in _locktable[].
+  * We reset _IOLOCKED to indicate we unlock the stream.
+  */
+  pf-_flag = ~_IOLOCKED;
+ _unlock( _STREAM_LOCKS + (int)(pf - (__iob_func()[0])) );
+ }
+ else
+ /*
+  * Not part of _iob[]. Therefore, *pf is a _FILEX and the
+  * lock field of the struct is an initialized critical
+  * section.
+  */
+ LeaveCriticalSection( (((_FILEX *)pf)-lock) );
+ }
diff -r -c -N a/stdio/mingw_printf.c b/stdio/mingw_printf.c
*** a/stdio/mingw_printf.c  Sat Aug  1 18:19:05 2015
--- b/stdio/mingw_printf.c  Sat Aug  1 20:21:05 2015
***
*** 50,56 
--- 50,58 
  {
register int retval;
va_list argv; va_start( argv, fmt );
+   _lock_file( stdout );
retval = __pformat( PFORMAT_TO_FILE | PFORMAT_NOLIMIT, stdout, 0, fmt, argv 
);
+   _unlock_file( stdout );
va_end( argv );
return retval;
  }
diff -r -c -N a/stdio/mingw_vfprintf.c b/stdio/mingw_vfprintf.c
*** 

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

[Mateusz]

Now _lock_file/_unlock_file are in stdio/mingw_lock.c (new) file.

printf_full.diff works out of the box but I edited makefile.am  
makefile.in by hands which is wrong. I tested this patch with 64 and 
32-bit GCC 5.2 with link to msvcrt.dll/msvcr100.dll/msvcr120.dll -- all 
is working.


printf.diff is only with *.c files and needs (proper) modification to 
makefile.am/makefile.in -- stdio/mingw_lock.c should go to libmsvcrt.a 
and to libmsvcr80.a


I attached new version of test-stdio.c because when I test with 32-bit 
GCC and link to msvcr120.dll there is no ftime 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
ftello.c -- surprisingly make install works and with new
libmingwex.a I can compile test-stdio.c file and it is working.

Could you/Kai show example of performance drop with this patch?


Personally, I think the patch is nearly OK, but the lock/unlock
functions should go into its own files, not something hard to correct.

Kai, anything?



--


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


diff --git a/mingw-w64-crt/stdio/mingw_fprintf.c 
b/mingw-w64-crt/stdio/mingw_fprintf.c
index 011a634..438941f 100644
--- a/mingw-w64-crt/stdio/mingw_fprintf.c
+++ b/mingw-w64-crt/stdio/mingw_fprintf.c
@@ -50,7 +50,9 @@ int __cdecl __fprintf(FILE *stream, const APICHAR *fmt, ...)
 {
   register int retval;
   va_list argv; va_start( argv, fmt );
+  _lock_file( stream );
   retval = __pformat( PFORMAT_TO_FILE | PFORMAT_NOLIMIT, stream, 0, fmt, argv 
);
+  _unlock_file( stream );
   va_end( argv );
   return retval;
 }
diff --git a/mingw-w64-crt/stdio/mingw_lock.c b/mingw-w64-crt/stdio/mingw_lock.c
new file mode 100644
index 000..e62fe03
--- /dev/null
+++ b/mingw-w64-crt/stdio/mingw_lock.c
@@ -0,0 +1,97 @@
+#include stdio.h
+#include synchapi.h
+#include internal.h
+
+/***
+ * Copy of MS functions _lock_file, _unlock_file which are missing from
+ * msvcrt.dll and msvcr80.dll. They are needed to atomic/lock stdio
+ * functions (printf, fprintf, vprintf, vfprintf). We need exactly the same
+ * lock that MS uses in msvcrt.dll because we can mix mingw-w64 code with
+ * original MS functions (puts, fputs for example).
+***/ 
+
+
+_CRTIMP void __cdecl _lock(int locknum);
+_CRTIMP void __cdecl _unlock(int locknum);
+#define _STREAM_LOCKS   16
+#define _IOLOCKED   0x8000
+
+
+/***
+* _lock_file - Lock a FILE
+*
+*Purpose:
+*   Assert the lock for a stdio-level file
+*
+*Entry:
+*   pf = __piob[] entry (pointer to a FILE or _FILEX)
+*
+*Exit:
+*
+*Exceptions:
+*
+***/
+
+void __cdecl _lock_file( FILE *pf )
+{
+/*
+ * The way the FILE (pointed to by pf) is locked depends on whether
+ * it is part of _iob[] or not
+ */
+if ( (pf = (__iob_func()[0]))  (pf = (__iob_func()[_IOB_ENTRIES-1])) 
)
+{
+/*
+ * FILE lies in _iob[] so the lock lies in _locktable[].
+ */
+_lock( _STREAM_LOCKS + (int)(pf - (__iob_func()[0])) );
+/* We set _IOLOCKED to indicate we locked the stream */
+pf-_flag |= _IOLOCKED;
+}
+else
+/*
+ * Not part of _iob[]. Therefore, *pf is a _FILEX and the
+ * lock field of the struct is an initialized critical
+ * section.
+ */
+EnterCriticalSection( (((_FILEX *)pf)-lock) );
+}
+
+
+/***
+* _unlock_file - Unlock a FILE
+*
+*Purpose:
+*   Release the lock for a stdio-level file
+*
+*Entry:
+*   pf = __piob[] entry (pointer to a FILE or _FILEX)
+*
+*Exit:
+*
+*Exceptions:
+*
+***/
+
+void __cdecl _unlock_file( FILE *pf )
+{
+/*
+ * The way the FILE (pointed to by pf) is unlocked depends on whether
+ * it is part of _iob[] or not
+ */
+if ( (pf = (__iob_func()[0]))  (pf = (__iob_func()[_IOB_ENTRIES-1])) 
)
+{
+/*
+ * FILE lies in _iob[] so the lock lies in _locktable[].
+ * We reset _IOLOCKED to indicate we unlock the stream.
+ */
+pf-_flag = ~_IOLOCKED;
+_unlock( _STREAM_LOCKS + (int)(pf - (__iob_func()[0])) );
+}
+else
+/*
+ * Not part of _iob[]. Therefore, *pf is a _FILEX and the
+ * lock field of the struct is an initialized critical
+ * section.
+ */
+LeaveCriticalSection( (((_FILEX *)pf)-lock) );
+}
diff --git a/mingw-w64-crt/stdio/mingw_printf.c 
b/mingw-w64-crt/stdio/mingw_printf.c
index 5d23b02..fbd2e7d 100644
--- a/mingw-w64-crt/stdio/mingw_printf.c
+++ b/mingw-w64-crt/stdio

Re: [Mingw-w64-public] winpthreads

[Mateusz]

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 );
*

And my riddle is: where is the spinlock?

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

Thanks for the patch.

Unfortunately I can't do full test because I can't compile ffmpeg-2.7.2 
-- mingw-w64 trunk from 2015-08-10 works with ffmpeg-2.7.2, from 
2015-08-28 doesn't work. There are changes in include file d3d11.h 
which could make the difference.


Error from ffmepeg-2.7.2 make:
CC  libavcodec/dxva2.o
In file included from libavcodec/dxva2_internal.h:34:0,
 from libavcodec/dxva2.c:31:
libavcodec/d3d11va.h:66:5: error: unknown type name 'ID3D11VideoContext'
 ID3D11VideoContext *video_context;
 ^
In file included from libavcodec/dxva2.c:31:0:
libavcodec/dxva2.c: In function 'ff_dxva2_get_surface_index':
libavcodec/dxva2_internal.h:65:117: warning: pointer type mismatch in 
conditional expression
 #define DXVA_CONTEXT_SURFACE(avctx, ctx, i) (avctx-pix_fmt == 
AV_PIX_FMT_D3D11VA_VLD ? ctx-d3d11va.surface[i] : ctx-dxva

2.surface[i])
^
libavcodec/dxva2.c:46:13: note: in expansion of macro 'DXVA_CONTEXT_SURFACE'
 if (DXVA_CONTEXT_SURFACE(avctx, ctx, i) == surface)
 ^
libavcodec/dxva2.c: In function 'ff_dxva2_commit_buffer':
libavcodec/dxva2.c:66:14: error: implicit declaration of function 
'ID3D11VideoContext_GetDecoderBuffer' [-Werror=implicit-functi

on-declaration]
 hr = 
ID3D11VideoContext_GetDecoderBuffer(D3D11VA_CONTEXT(ctx)-video_context,

  ^
libavcodec/dxva2.c:86:13: error: unknown type name 
'D3D11_VIDEO_DECODER_BUFFER_DESC'

 D3D11_VIDEO_DECODER_BUFFER_DESC *dsc11 = dsc;
 ^
libavcodec/dxva2.c:88:18: error: request for member 'BufferType' in 
something not a structure or union

 dsc11-BufferType   = type;
  ^
libavcodec/dxva2.c:89:18: error: request for member 'DataSize' in 
something not a structure or union

 dsc11-DataSize = size;
  ^
libavcodec/dxva2.c:90:18: error: request for member 'NumMBsInBuffer' in 
something not a structure or union

 dsc11-NumMBsInBuffer   = mb_count;
  ^
libavcodec/dxva2.c:111:14: error: implicit declaration of function 
'ID3D11VideoContext_ReleaseDecoderBuffer' [-Werror=implicit-f

unction-declaration]
 hr = 
ID3D11VideoContext_ReleaseDecoderBuffer(D3D11VA_CONTEXT(ctx)-video_context, 
D3D11VA_CONTEXT(ctx)-decoder, type);


  ^
libavcodec/dxva2.c: In function 'ff_dxva2_common_end_frame':
libavcodec/dxva2.c:136:5: error: unknown type name 
'D3D11_VIDEO_DECODER_BUFFER_DESC'

 D3D11_VIDEO_DECODER_BUFFER_DESC buffer11[4];
 ^
libavcodec/dxva2.c:149:18: error: implicit declaration of function 
'ID3D11VideoContext_DecoderBeginFrame' [-Werror=implicit-func

tion-declaration]
 hr = 
ID3D11VideoContext_DecoderBeginFrame(D3D11VA_CONTEXT(ctx)-video_context, D3D11VA_CONTEXT(ctx)-decoder,

  ^
libavcodec/dxva2.c:171:16: error: 
'D3D11_VIDEO_DECODER_BUFFER_PICTURE_PARAMETERS' undeclared (first use in 
this function)

 type = D3D11_VIDEO_DECODER_BUFFER_PICTURE_PARAMETERS;
^
libavcodec/dxva2.c:171:16: note: each undeclared identifier is reported 
only once for each function it appears in
libavcodec/dxva2.c:194:20: error: 
'D3D11_VIDEO_DECODER_BUFFER_INVERSE_QUANTIZATION_MATRIX' undeclared 
(first use in this functio

n)
 type = D3D11_VIDEO_DECODER_BUFFER_INVERSE_QUANTIZATION_MATRIX;
^
libavcodec/dxva2.c:243:14: error: implicit declaration of function 
'ID3D11VideoContext_SubmitDecoderBuffers' [-Werror=implicit-f

unction-declaration]
 hr = 
ID3D11VideoContext_SubmitDecoderBuffers(D3D11VA_CONTEXT(ctx)-video_context,

  ^
libavcodec/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: 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 of the box but I edited makefile.am 
makefile.in by hands which is wrong. I tested this patch with 64 and
32-bit GCC 5.2 with link to msvcrt.dll/msvcr100.dll/msvcr120.dll -- all
is working.

printf.diff is only with *.c files and needs (proper) modification to
makefile.am/makefile.in -- stdio/mingw_lock.c should go to libmsvcrt.a
and to libmsvcr80.a

I attached new version of test-stdio.c because when I test with 32-bit
GCC and link to msvcr120.dll there is no ftime function, so I changed
to _ftime64.


Done, patch applied to master.




--


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Patch for ffmpeg

[Mateusz]

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 libavformat/os_support.h undefines 
stat & fstat in blind for _WIN32.


Second problem is described in ticket #471
http://sourceforge.net/p/mingw-w64/bugs/471/
so I've removed _O_TEMPORARY flag.
diff --git a/mingw-w64-crt/misc/mkstemp.c b/mingw-w64-crt/misc/mkstemp.c
index d3c4aad..c78b7c5 100644
--- a/mingw-w64-crt/misc/mkstemp.c
+++ b/mingw-w64-crt/misc/mkstemp.c
@@ -48,7 +48,7 @@ int __cdecl mkstemp (char *template_name)
 template_name[j] = letters[rand () % 62];
 }
 fd = _sopen(template_name,
-_O_RDWR | _O_CREAT | _O_EXCL | _O_TEMPORARY | _O_BINARY,
+_O_RDWR | _O_CREAT | _O_EXCL | _O_BINARY,
 _SH_DENYRW, _S_IREAD | _S_IWRITE);
 if (fd != -1) return fd;
 if (fd == -1 && errno != EEXIST) return -1;
diff --git a/mingw-w64-headers/crt/_mingw_stat64.h 
b/mingw-w64-headers/crt/_mingw_stat64.h
index 17e754c..8ce0975 100644
--- a/mingw-w64-headers/crt/_mingw_stat64.h
+++ b/mingw-w64-headers/crt/_mingw_stat64.h
@@ -1,12 +1,12 @@
 #ifndef _STAT_DEFINED
 
 #ifdef _USE_32BIT_TIME_T
-#define _fstat32 _fstat
-#define _stat32 _stat
-#define _wstat32 _wstat
-#define _fstat32i64 _fstati64
-#define _stat32i64 _stati64
-#define _wstat32i64 _wstati64
+#define _fstat _fstat32
+#define _fstati64 _fstat32i64
+#define _stat _stat32
+#define _stati64 _stat32i64
+#define _wstat _wstat32
+#define _wstati64 _wstat32i64
 #else
 #define _fstat _fstat64i32
 #define _fstati64 _fstat64
--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911=/4140___
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 for ffmpeg

[Mateusz]

Sorry for previous patch -- I often link to msvcr120.dll instead of 
msvcrt.dll.


For normal linking to msvcrt.dll the patch should be bigger -- we should 
add _fstat32i64, _stat32i64, _wstat32i64, _ftime32 aliases to 32-bit 
version of libmsvcrt.a (these functions are present in libmsvcr120.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 is switched from

#define  new_name  msvcrt_function
to
#define  msvcrt_function  new_name
which is nonsense. ffmpeg in file libavformat/os_support.h undefines 
stat & fstat in blind for _WIN32.


Second problem is described in ticket #471
http://sourceforge.net/p/mingw-w64/bugs/471/
so I've removed _O_TEMPORARY flag.


--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911=/4140


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


diff --git a/mingw-w64-crt/lib32/msvcrt.def.in 
b/mingw-w64-crt/lib32/msvcrt.def.in
index 71bdf56..94378a4 100644
--- a/mingw-w64-crt/lib32/msvcrt.def.in
+++ b/mingw-w64-crt/lib32/msvcrt.def.in
@@ -196,7 +196,9 @@ _fsopen
 _fstat
 _fstat32 == _fstat
 _fstati64
+_fstat32i64 == _fstati64
 _ftime
+_ftime32 == _ftime
 _ftol
 _fullpath
 _futime
@@ -403,6 +405,7 @@ _stat
 _stat64
 _stati64
 _stat32 == _stat
+_stat32i64 == _stati64
 _statusfp
 _strcmpi
 _strdate
@@ -517,6 +520,7 @@ _wsplitpath
 _wstat
 _wstati64
 _wstat32 == _wstat
+_wstat32i64 == _wstati64
 _wstrdate
 _wstrtime
 _wsystem
diff --git a/mingw-w64-crt/misc/mkstemp.c b/mingw-w64-crt/misc/mkstemp.c
index d3c4aad..c78b7c5 100644
--- a/mingw-w64-crt/misc/mkstemp.c
+++ b/mingw-w64-crt/misc/mkstemp.c
@@ -48,7 +48,7 @@ int __cdecl mkstemp (char *template_name)
 template_name[j] = letters[rand () % 62];
 }
 fd = _sopen(template_name,
-_O_RDWR | _O_CREAT | _O_EXCL | _O_TEMPORARY | _O_BINARY,
+_O_RDWR | _O_CREAT | _O_EXCL | _O_BINARY,
 _SH_DENYRW, _S_IREAD | _S_IWRITE);
 if (fd != -1) return fd;
 if (fd == -1 && errno != EEXIST) return -1;
diff --git a/mingw-w64-headers/crt/_mingw_stat64.h 
b/mingw-w64-headers/crt/_mingw_stat64.h
index 17e754c..8ce0975 100644
--- a/mingw-w64-headers/crt/_mingw_stat64.h
+++ b/mingw-w64-headers/crt/_mingw_stat64.h
@@ -1,12 +1,12 @@
 #ifndef _STAT_DEFINED
 
 #ifdef _USE_32BIT_TIME_T
-#define _fstat32 _fstat
-#define _stat32 _stat
-#define _wstat32 _wstat
-#define _fstat32i64 _fstati64
-#define _stat32i64 _stati64
-#define _wstat32i64 _wstati64
+#define _fstat _fstat32
+#define _fstati64 _fstat32i64
+#define _stat _stat32
+#define _stati64 _stat32i64
+#define _wstat _wstat32
+#define _wstati64 _wstat32i64
 #else
 #define _fstat _fstat64i32
 #define _fstati64 _fstat64
diff --git a/mingw-w64-headers/crt/sys/timeb.h 
b/mingw-w64-headers/crt/sys/timeb.h
index c92c8e0..d60ac45 100644
--- a/mingw-w64-headers/crt/sys/timeb.h
+++ b/mingw-w64-headers/crt/sys/timeb.h
@@ -77,12 +77,13 @@ extern "C" {
 
   _CRTIMP void __cdecl _ftime64(struct __timeb64 *_Time);
 
-#ifdef _WIN64
+#ifndef _USE_32BIT_TIME_T
 #define _timeb __timeb64
-  _CRTIMP void __cdecl _ftime(struct __timeb64 *);
+#define _ftime _ftime64
 #else
 #define _timeb __timeb32
-  _CRTIMP void __cdecl _ftime(struct __timeb32 *);
+  _CRTIMP void __cdecl _ftime32(struct __timeb32 *);
+#define _ftime _ftime32
 #endif
 
 #ifndef _TIMESPEC_DEFINED
--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911=/4140___
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 for ffmpeg

[Mateusz]

> I don`t see that this patch is valid.  I would request here more
> details about reasoning. I would be curious to learn that we have
> useless code in repro for years
>
> Kai

Current code works with msvcrt.dll in Win32 + _USE_32BIT_TIME_T (which 
is defined by default in Win32).


It doesn't work with msvcr120.dll (or msvcr110.dll) in Win32 + 
_USE_32BIT_TIME_T, doesn't work with msvcrt.dll in Win32 + 64BIT_TIME_T 
(which you can achieve by define __MINGW_USE_VC2005_COMPAT). It is also 
not 100% compliant with current Microsoft documentation.


I think we can choose one from three possibilities:
1) to do nothing (Win32 should die soon),
2) to change header files according M$ documentation and move function 
aliases from header file to 32-bit libmsvcrt.a (like in patch), it 
allows to work with msvcr120.dll in Win32 (but still msvcrt.dll in Win32 
+ 64BIT_TIME_T will be not working),
3) to change header files and 32-bit libmsvcrt.a to 100% compliant with 
M$ documentation.


At bottom of the page
https://msdn.microsoft.com/en-us/library/w4ddyt9h.aspx
I found information, that M$ made change in time functions in MSVC 2005. 
It was 10 years ago, now VS 2015 is free for open source projects. We 
could consider make mingw-w64 100% compliant with M$ documentation.


I attached example code t.cpp (based on page 
https://msdn.microsoft.com/en-us/library/95e68951.aspx) that works with 
VS 2015 64-bit & 32-bit & 32-bit + _USE_32BIT_TIME_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 returned 1 exit status

It doesn't work with GCC 32-bit with msvcr120.dll (the same link error).

It can't compile with GCC 32-bit + -D__MINGW_USE_VC2005_COMPAT:
$ g++ -Wall -D__MINGW_USE_VC2005_COMPAT -o tg.exe t.cpp
t.cpp: In function 'int main()':
t.cpp:32:55: error: cannot convert '__time32_t* {aka long int*}' to 
'const time_t* {aka const long long int*}' for argument '3'

to 'errno_t ctime_s(char*, size_t, const time_t*)'
 err = ctime_s( timeline, 26, & ( timebuffer.time ) );
^

I attached also t0.cpp which works with all variants of VS 2015 and 
doesn't work with any variant of GCC.


My question is: should I try to make patch for 100% compliance with M$ 
documentation that works with all variants of GCC?
// crt_ftime64_s.c
// This program uses _ftime64_s to obtain the current
// time and then stores this time in timebuffer.

#include 
#include 
#include 

int main( void )
{
   struct _timeb timebuffer;
   char timeline[26];
   errno_t err;
   time_t time1;
   unsigned short millitm1;
   short timezone1;
   short dstflag1;

   _ftime(  );

time1 = timebuffer.time;
millitm1 = timebuffer.millitm;
timezone1 = timebuffer.timezone;
dstflag1 = timebuffer.dstflag;

   printf( "Seconds since midnight, January 1, 1970 (UTC): %ld\n", (unsigned 
long)time1);
   printf( "Milliseconds: %d\n", millitm1);
   printf( "Minutes between UTC and local time: %d\n", timezone1);
   printf( "Daylight savings time flag (1 means Daylight time is in "
   "effect): %d\n", dstflag1); 

   err = ctime_s( timeline, 26, & ( timebuffer.time ) );
   if (err)
   {
   printf("Invalid argument to ctime_s. ");
   }
   printf( "The time is %.19s.%hu %s", timeline, timebuffer.millitm,
   [20] );
}

// crt_ftime64_s.c
// This program uses _ftime64_s to obtain the current
// time and then stores this time in timebuffer.

#include 
#include 
#include 

int main( void )
{
   struct _timeb timebuffer;
   char timeline[26];
   errno_t err;
   time_t time1;
   unsigned short millitm1;
   short timezone1;
   short dstflag1;

   _ftime_s(  );

time1 = timebuffer.time;
millitm1 = timebuffer.millitm;
timezone1 = timebuffer.timezone;
dstflag1 = timebuffer.dstflag;

   printf( "Seconds since midnight, January 1, 1970 (UTC): %ld\n", (unsigned 
long)time1);
   printf( "Milliseconds: %d\n", millitm1);
   printf( "Minutes between UTC and local time: %d\n", timezone1);
   printf( "Daylight savings time flag (1 means Daylight time is in "
   "effect): %d\n", dstflag1); 

   err = ctime_s( timeline, 26, & ( timebuffer.time ) );
   if (err)
   {
   printf("Invalid argument to ctime_s. ");
   }
   printf( "The time is %.19s.%hu %s", timeline, timebuffer.millitm,
   [20] );
}

--
___
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 for ffmpeg

[Mateusz]

I execute command
gcc -dumpspecs >/local/specs.org

and then edit /local/specs.org file. I find 'msvcrt' word and delete all 
text except '*libgcc:' section (which contains 'msvcrt' word). In my GCC 
it looks like this:


*libgcc:
%{mthreads:-lmingwthrd} -lmingw32 -lgcc -lmoldname -lmingwex 
-lmsvcrt


It could be longer line if you compile GCC without '--disable-shared' 
option.
Then I copy file specs.org to specs.new and edit specs.new file to 
change '-lmsvcrt' to '-lmsvcr120'. It looks like this:


*libgcc:
%{mthreads:-lmingwthrd} -lmingw32 -lgcc -lmoldname -lmingwex 
-lmsvcr120


Then I copy both files specs.org and specs.new to 
\lib\gcc\x86_64-w64-mingw32\5.3.0\ folder in GCC directory. If I want to 
link to msvcr120.dll I copy 'specs.new' file to 'specs' file (without 
any extension). If I want link to old msvcrt.dll I copy 'cpecs.old' file 
to 'specs' file (I've made batch files to change this).


This is example for x86-64 version of GCC 5.3 compiled with actual trunk 
version of mingw-w64 (which has 'libmsvcr120.a' file).


Why?
Many open source project uses 'll' (long long) size specification in 
printf and scanf family functions. This not work in msvcrt.dll but works 
perfect in msvcr120.dll. So I turn off '__USE_MINGW_ANSI_STDIO' in 
'_mingw.h' header file and link to new msvcr120.dll. The printf family 
functions from Microsoft DLLs are threads safe (actual trunk version of 
mingw printf functions are threads safe too, but release 4.0.4 version 
is not threads safe).


Second problem is C++ project x265. If you don't turn off 
'__USE_MINGW_ANSI_STDIO' in '_mingw.h' header file each 'fprintf' 
function is replaced by

int fprintf (FILE *__stream, const char *__format, ...)
{
  register int __retval;
  __builtin_va_list __local_argv; __builtin_va_start( __local_argv, 
__format );

  __retval = __mingw_vfprintf( __stream, __format, __local_argv );
  __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 <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 would you? 
What is the advantage?



--
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı


--


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

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/gccmain.c
+++ b/mingw-w64-crt/crt/gccmain.c
@@ -9,15 +9,8 @@
 #include 
 
 typedef void (*func_ptr) (void);
-#define STATIC static
-
-STATIC func_ptr __MINGW_CTOR_LIST__[1]
-  __attribute__ ((__used__, section(".ctors"), aligned(sizeof(func_ptr
-  = { (func_ptr) (-1) };
-
-STATIC func_ptr __MINGW_DTOR_LIST__[1]
-  __attribute__((section(".dtors"), aligned(sizeof(func_ptr
-  = { (func_ptr) (-1) };
+extern func_ptr __CTOR_LIST__[];
+extern func_ptr __DTOR_LIST__[];
 
 void __do_global_dtors (void);
 void __do_global_ctors (void);
@@ -26,7 +19,7 @@ void __main (void);
 void
 __do_global_dtors (void)
 {
-  static func_ptr *p = __MINGW_DTOR_LIST__ + 1;
+  static func_ptr *p = __DTOR_LIST__ + 1;
 
   while (*p)
 {
@@ -38,17 +31,17 @@ __do_global_dtors (void)
 void
 __do_global_ctors (void)
 {
-  unsigned long nptrs = (unsigned long) (ptrdiff_t) __MINGW_CTOR_LIST__[0];
+  unsigned long nptrs = (unsigned long) (ptrdiff_t) __CTOR_LIST__[0];
   unsigned long i;
 
   if (nptrs == (unsigned long) -1)
 {
-  for (nptrs = 0; __MINGW_CTOR_LIST__[nptrs + 1] != 0; nptrs++);
+  for (nptrs = 0; __CTOR_LIST__[nptrs + 1] != 0; nptrs++);
 }
 
   for (i = nptrs; i >= 1; i--)
 {
-  __MINGW_CTOR_LIST__[i] ();
+  __CTOR_LIST__[i] ();
 }
 
   atexit (__do_global_dtors);
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

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/dongsheng-daily/5.x/gcc-5-win64_5.3.1-20160318.7z/download

https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/dongsheng-daily/6.x/gcc-6-win64_6.0.0-20160318.7z/download

W dniu 2016-03-26 o 17:07, Jim Michaels pisze:
problem in 5.3.1 with , , , use of 
std::ifstream, std::ofstream cause compile errors.

and as 6.0 and its errors go, I have no completely working compiler. help.

C:\jim\KBIB_KJ1>g++ -v -s -o KBIB_KJ1to5toBible_txt.exe -O4 -std=c++11 
-lstdlib

-W -Wall KBIB_KJ1to5toBible_txt.cpp
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=c:/gcc-5-win32/bin/../libexec/gcc/i686-w64-mingw32/5.3.1/lto
-wrapper.exe
Target: i686-w64-mingw32
Configured with: 
/home/cauchy/vcs/svn/gcc/branches/gcc-5-branch/configure --pref
ix=/home/cauchy/native/gcc-5-win32 
--with-sysroot=/home/cauchy/native/gcc-5-win3
2 --build=x86_64-unknown-linux-gnu --host=i686-w64-mingw32 
--target=i686-w64-min
gw32 --disable-multilib --disable-nls --disable-win32-registry 
--disable-gcov-to
ol --enable-checking=release --enable-languages=c,c++,fortran 
--enable-fully-dyn

amic-string --with-arch=core2 --with-tune=generic
Thread model: win32
gcc version 5.3.1 20160301 (GCC)
COLLECT_GCC_OPTIONS='-v' '-s' '-o' 'KBIB_KJ1to5toBible_txt.exe' '-O4' 
'-std=c++1

1' '-Wextra' '-Wall' '-shared-libgcc' '-mtune=generic' '-march=core2'
 c:/gcc-5-win32/bin/../libexec/gcc/i686-w64-mingw32/5.3.1/cc1plus.exe 
-quiet -v
-iprefix c:\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.3.1/ 
-isysroot c:\gcc-
5-win32\bin\../../gcc-5-win32 -U_REENTRANT KBIB_KJ1to5toBible_txt.cpp 
-quiet -du
mpbase KBIB_KJ1to5toBible_txt.cpp -mtune=generic -march=core2 -auxbase 
KBIB_KJ1t
o5toBible_txt -O4 -Wextra -Wall -std=c++11 -version -o 
C:\Users\Kristina\AppData

\Local\Temp\cc0XLJ6n.s
GNU C++11 (GCC) version 5.3.1 20160301 (i686-w64-mingw32)
compiled by GNU C version 5.3.1 20160301, GMP version 6.1.0, 
MPFR versio

n 3.1.3-p5, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory 
"c:/gcc-5-win32/lib/gcc/../../lib/gcc/i686-w64-ming

w32/5.3.1/../../../../include/c++/5.3.1"
ignoring duplicate directory 
"c:/gcc-5-win32/lib/gcc/../../lib/gcc/i686-w64-ming

w32/5.3.1/../../../../include/c++/5.3.1/i686-w64-mingw32"
ignoring duplicate directory 
"c:/gcc-5-win32/lib/gcc/../../lib/gcc/i686-w64-ming

w32/5.3.1/../../../../include/c++/5.3.1/backward"
ignoring duplicate directory 
"c:/gcc-5-win32/lib/gcc/../../lib/gcc/i686-w64-ming

w32/5.3.1/include"
ignoring nonexistent directory 
"c:\gcc-5-win32\bin\../../gcc-5-win32/home/cauchy

/native/gcc-5-win32/lib/gcc/i686-w64-mingw32/5.3.1/../../../../include"
ignoring duplicate directory 
"c:/gcc-5-win32/lib/gcc/../../lib/gcc/i686-w64-ming

w32/5.3.1/include-fixed"
ignoring duplicate directory 
"c:/gcc-5-win32/lib/gcc/../../lib/gcc/i686-w64-ming

w32/5.3.1/../../../../i686-w64-mingw32/include"
ignoring nonexistent directory 
"c:\gcc-5-win32\bin\../../gcc-5-win32/mingw/inclu

de"
#include "..." search starts here:
#include <...> search starts here:
 c:\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.3.1/../../../../include/c++/5.
3.1
 c:\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.3.1/../../../../include/c++/5.
3.1/i686-w64-mingw32
 c:\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.3.1/../../../../include/c++/5.
3.1/backward
 c:\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.3.1/include
 c:\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.3.1/include-fixed
 c:\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.3.1/../../../../i686-w64-mingw
32/include
End of search list.
GNU C++11 (GCC) version 5.3.1 20160301 (i686-w64-mingw32)
compiled by GNU C version 5.3.1 20160301, GMP version 6.1.0, 
MPFR versio

n 3.1.3-p5, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 0601085ae72d1dd599a3fd803d942dc0
KBIB_KJ1to5toBible_txt.cpp:15:20: fatal error: ifstream: No such file 
or directo

ry
compilation terminated.
-
Jim Michaels j...@renewalcomputerservices.com
http://www.RenewalComputerServices.com
http://www.JesusnJim.com (computer repair info, programming)


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

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 Malone pisze:

You have my go ahead to apply.

There is a header setting for when building gcc or rather libgcc to 
specify that ctors and dtors are provided by the c runtime.

This is usually enabled for some embedded targets.

Alternatively I could only enable that when we build the crt with 
clang and not gcc.
This would then mean that we can't use compiler-rt with mingw-w64 crt 
built with gcc and that we can't use libgcc with a clang built 
mingw-w64 crt.

I can probably live with that.

The correct fix would be to upstream a patch into libgcc to assume it 
is external from now on.

Might be hard to get that merged because of legacy support though.

I will provide a follow up patch to enable this only when building 
with clang


On Tue, Mar 1, 2016 at 12:25 PM, Mateusz <mateu...@poczta.onet.pl 
<mailto:mateu...@poczta.onet.pl>> wrote:


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



--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
<mailto:Mingw-w64-public@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

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-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[1]: *** No rule to make target
>> '/home/ma/m/source/mingw-w64-v5/mingw-w64-crt/winrt/libruntimeobject.a',
>> needed by 'all-am'.  Stop.*
>> rm lib64/msvcr120.def lib64/msvcr90.def lib64/msvcr90d.def
>> lib64/msvcr100.def lib64/msvcr110.def lib64/msvcr120d.def
> I believe you need to regenerate the Makefile.in.
> I'll ping Hugo about it :)
>
>
>
> With my kindest regards,
>


--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

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[1]: *** No rule to make target 
'/home/ma/m/source/mingw-w64-v5/mingw-w64-crt/winrt/libruntimeobject.a', 
needed by 'all-am'.  Stop.*
rm lib64/msvcr120.def lib64/msvcr90.def lib64/msvcr90d.def 
lib64/msvcr100.def lib64/msvcr110.def lib64/msvcr120d.def

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
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/7] crt: Add e_pow.c to the source list

[Mateusz]

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 regenerate makefile?
>>
> 
> Whoever pulls it in is supposed to regenerate those themselves.
> 
> 
> -BEGIN PGP SIGNATURE-
> 
> iF4EAREIAAYFAldAAToACgkQk721PNTrx0D5vQD+I8ytK2eAxxb21mFI4Whd7gGI
> l1VyIP1K8AlHM7k5MPEA/jf51Igd9SFlLnKvAC8cXuQLrV3QVMCxpc8RbSUORZEc
> =03hn
> -END PGP SIGNATURE-
> 
> 
> 
> --
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> 
> 
> 
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> 


--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Restore deleted VirtualFree declaration

[Mateusz]

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/memoryapi.h
+++ b/mingw-w64-headers/include/memoryapi.h
@@ -68,6 +68,7 @@ extern "C" {
 #define FILE_CACHE_MIN_HARD_DISABLE 0x0008
 
   WINBASEAPI LPVOID WINAPI VirtualAlloc (LPVOID lpAddress, SIZE_T dwSize, 
DWORD flAllocationType, DWORD flProtect);
+  WINBASEAPI WINBOOL WINAPI VirtualFree (LPVOID lpAddress, SIZE_T dwSize, 
DWORD dwFreeType);
   WINBASEAPI LPVOID WINAPI VirtualAllocEx (HANDLE hProcess, LPVOID lpAddress, 
SIZE_T dwSize, DWORD flAllocationType, DWORD flProtect);
   WINBASEAPI WINBOOL WINAPI VirtualFreeEx (HANDLE hProcess, LPVOID lpAddress, 
SIZE_T dwSize, DWORD dwFreeType);
   WINBASEAPI WINBOOL WINAPI VirtualProtectEx (HANDLE hProcess, LPVOID 
lpAddress, SIZE_T dwSize, DWORD flNewProtect, PDWORD lpflOldProtect);
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
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] headers: Fix VirtualFree declaration scope

[Mateusz]

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 deletion(-)
> 
> diff --git a/mingw-w64-headers/include/memoryapi.h 
> b/mingw-w64-headers/include/memoryapi.h
> index 46e18c4..0a2fbd7 100755
> --- a/mingw-w64-headers/include/memoryapi.h
> +++ b/mingw-w64-headers/include/memoryapi.h
> @@ -37,6 +37,10 @@ extern "C" {
>  #endif
>  #endif
>  
> +#if (WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_APP) && _WIN32_WINNT >= 
> 0x0A00) || WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
> +WINBASEAPI WINBOOL WINAPI VirtualFree (LPVOID lpAddress, SIZE_T dwSize, 
> DWORD dwFreeType);
> +#endif
> +
>  #if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_APP)
>  #define FILE_MAP_WRITE SECTION_MAP_WRITE
>  #define FILE_MAP_READ SECTION_MAP_READ
> @@ -51,7 +55,6 @@ extern "C" {
>WINBASEAPI PVOID WINAPI MapViewOfFileFromApp (HANDLE hFileMappingObject, 
> ULONG DesiredAccess, ULONG64 FileOffset, SIZE_T NumberOfBytesToMap);
>  #if _WIN32_WINNT >= 0x0A00
>WINBASEAPI PVOID WINAPI VirtualAllocFromApp(PVOID BaseAddress, SIZE_T 
> Size, ULONG AllocationType, ULONG  Protection);
> -  WINBASEAPI WINBOOL WINAPI VirtualFree (LPVOID lpAddress, SIZE_T dwSize, 
> DWORD dwFreeType);
>  #endif
>  #endif
>  
> 



--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
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/7] crt: Add e_pow.c to the source list

[Mateusz]

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..52d1dc7 100644
> --- a/mingw-w64-crt/Makefile.am
> +++ b/mingw-w64-crt/Makefile.am
> @@ -348,7 +348,7 @@ src_libmingwex32=\
>  
>  # these only go into the ARM32 version:
>  src_libmingwexarm32=\
> -  math/softmath/e_fmod.cmath/softmath/e_fmodf.c   math/softmath/e_powf.c 
>\
> +  math/softmath/e_fmod.cmath/softmath/e_fmodf.c   math/softmath/e_powf.c 
>math/softmath/e_pow.c \
>math/softmath/acosf.c math/softmath/acosh.c math/softmath/acosl.c  
>math/softmath/acoshf.cmath/softmath/acoshl.c\
>math/softmath/asinf.c math/softmath/asinh.c math/softmath/asinl.c  
>math/softmath/asinhf.cmath/softmath/asinhl.c\
>math/softmath/atan2f.cmath/softmath/atan2l.cmath/softmath/atanf.c  
>math/softmath/atanh.c math/softmath/atanl.c \
> 



--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

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_STDIO, it prints only "World" (on Windows 7).


If I link to msvcr110.dll instead of msvcrt.dll, it prints "Hello World" 
in both cases.


If I apply attached hello.patch to mingw-w64 (to patch only libmsvcrt.a) 
it prints "Hello World" in both cases.


It seems that 'fputwc' and 'fputws' from msvcrt.dll doesn't work with 
_O_U8TEXT mode (for console streams), but 'fwprintf' works OK.


Does anyone have a better idea of the patch of this error?

#define __USE_MINGW_ANSI_STDIO 1

#include 
#include 
#include 

int main()
{
_setmode(_fileno(stderr), _O_U8TEXT);
fputws(L"Hello ", stderr);
fwprintf(stderr, L"%ls\n", L"World");
}
diff --git a/mingw-w64-crt/lib32/msvcrt.def.in 
b/mingw-w64-crt/lib32/msvcrt.def.in
index 71bdf56..24c21cd 100644
--- a/mingw-w64-crt/lib32/msvcrt.def.in
+++ b/mingw-w64-crt/lib32/msvcrt.def.in
@@ -572,8 +572,8 @@ fopen
 fprintf
 fputc
 fputs
-fputwc
-fputws
+;fputwc
+;fputws
 fread
 free
 freopen
@@ -585,6 +585,7 @@ fseek
 fsetpos
 ftell
 fwprintf
+__ms_fwprintf == fwprintf
 fwrite
 fwscanf
 getc
diff --git a/mingw-w64-crt/lib64/msvcrt.def.in 
b/mingw-w64-crt/lib64/msvcrt.def.in
index 946c200..e229c86 100644
--- a/mingw-w64-crt/lib64/msvcrt.def.in
+++ b/mingw-w64-crt/lib64/msvcrt.def.in
@@ -1070,8 +1070,8 @@ fprintf
 fprintf_s
 fputc
 fputs
-fputwc
-fputws
+;fputwc
+;fputws
 fread
 free
 freopen
@@ -1084,6 +1084,7 @@ fseek
 fsetpos
 ftell
 fwprintf
+__ms_fwprintf == fwprintf
 fwprintf_s
 fwrite
 fwscanf
diff --git a/mingw-w64-crt/stdio/mingw_lock.c b/mingw-w64-crt/stdio/mingw_lock.c
index e62fe03..ff15d30 100644
--- a/mingw-w64-crt/stdio/mingw_lock.c
+++ b/mingw-w64-crt/stdio/mingw_lock.c
@@ -95,3 +95,18 @@ void __cdecl _unlock_file( FILE *pf )
  */
 LeaveCriticalSection( &(((_FILEX *)pf)->lock) );
 }
+
+
+int __cdecl __ms_fwprintf(FILE *, const wchar_t *, ...);
+
+wint_t __cdecl fputwc(wchar_t _Ch, FILE *_File)
+{
+if (__ms_fwprintf(_File, L"%c", _Ch) > 0)
+return _Ch;
+return WEOF;
+}
+
+int __cdecl fputws(const wchar_t *_Str, FILE *_File)
+{
+return __ms_fwprintf(_File, L"%s", _Str);
+}
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

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/mingw-w64-crt/lib32/msvcr100.def.in
index a1d7447..d103a2b 100644
--- a/mingw-w64-crt/lib32/msvcr100.def.in
+++ b/mingw-w64-crt/lib32/msvcr100.def.in
@@ -1724,6 +1724,7 @@ fseek
 fsetpos
 ftell
 fwprintf
+__ms_fwprintf == fwprintf
 fwprintf_s
 fwrite
 fwscanf
diff --git a/mingw-w64-crt/lib32/msvcr110.def.in 
b/mingw-w64-crt/lib32/msvcr110.def.in
index f9f0294..7296955 100644
--- a/mingw-w64-crt/lib32/msvcr110.def.in
+++ b/mingw-w64-crt/lib32/msvcr110.def.in
@@ -1857,6 +1857,7 @@ fseek
 fsetpos
 ftell
 fwprintf
+__ms_fwprintf == fwprintf
 fwprintf_s
 fwrite
 fwscanf
diff --git a/mingw-w64-crt/lib32/msvcr120.def.in 
b/mingw-w64-crt/lib32/msvcr120.def.in
index c3158eb..57122cb 100644
--- a/mingw-w64-crt/lib32/msvcr120.def.in
+++ b/mingw-w64-crt/lib32/msvcr120.def.in
@@ -2018,6 +2018,7 @@ fseek
 fsetpos
 ftell
 fwprintf
+__ms_fwprintf == fwprintf
 fwprintf_s
 fwrite
 fwscanf
diff --git a/mingw-w64-crt/lib32/msvcr120_app.def.in 
b/mingw-w64-crt/lib32/msvcr120_app.def.in
index 579edb3..b29eaf9 100644
--- a/mingw-w64-crt/lib32/msvcr120_app.def.in
+++ b/mingw-w64-crt/lib32/msvcr120_app.def.in
@@ -1374,6 +1374,7 @@ fseek
 fsetpos
 ftell
 fwprintf
+__ms_fwprintf == fwprintf
 fwprintf_s
 fwrite
 fwscanf
diff --git a/mingw-w64-crt/lib32/msvcr120d.def.in 
b/mingw-w64-crt/lib32/msvcr120d.def.in
index f676867..194a0d2 100644
--- a/mingw-w64-crt/lib32/msvcr120d.def.in
+++ b/mingw-w64-crt/lib32/msvcr120d.def.in
@@ -2085,6 +2085,7 @@ fseek
 fsetpos
 ftell
 fwprintf
+__ms_fwprintf == fwprintf
 fwprintf_s
 fwrite
 fwscanf
diff --git a/mingw-w64-crt/lib32/msvcr80.def.in 
b/mingw-w64-crt/lib32/msvcr80.def.in
index f3408b9..79cd7dd 100644
--- a/mingw-w64-crt/lib32/msvcr80.def.in
+++ b/mingw-w64-crt/lib32/msvcr80.def.in
@@ -587,6 +587,7 @@ fseek
 fsetpos
 ftell
 fwprintf
+__ms_fwprintf == fwprintf
 fwrite
 fwscanf
 getc
diff --git a/mingw-w64-crt/lib32/msvcr90.def.in 
b/mingw-w64-crt/lib32/msvcr90.def.in
index 394d7f5..861ce56 100644
--- a/mingw-w64-crt/lib32/msvcr90.def.in
+++ b/mingw-w64-crt/lib32/msvcr90.def.in
@@ -1358,6 +1358,7 @@ fseek
 fsetpos
 ftell
 fwprintf
+__ms_fwprintf == fwprintf
 fwprintf_s
 fwrite
 fwscanf
diff --git a/mingw-w64-crt/lib32/msvcr90d.def.in 
b/mingw-w64-crt/lib32/msvcr90d.def.in
index 8846e13..419c65c 100644
--- a/mingw-w64-crt/lib32/msvcr90d.def.in
+++ b/mingw-w64-crt/lib32/msvcr90d.def.in
@@ -1430,6 +1430,7 @@ fseek
 fsetpos
 ftell
 fwprintf
+__ms_fwprintf == fwprintf
 fwprintf_s
 fwrite
 fwscanf
diff --git a/mingw-w64-crt/lib32/msvcrt.def.in 
b/mingw-w64-crt/lib32/msvcrt.def.in
index 71bdf56..6cc95a0 100644
--- a/mingw-w64-crt/lib32/msvcrt.def.in
+++ b/mingw-w64-crt/lib32/msvcrt.def.in
@@ -585,6 +585,7 @@ fseek
 fsetpos
 ftell
 fwprintf
+__ms_fwprintf == fwprintf
 fwrite
 fwscanf
 getc
diff --git a/mingw-w64-crt/lib64/msvcr100.def.in 
b/mingw-w64-crt/lib64/msvcr100.def.in
index a3ba8cd..b3be302 100644
--- a/mingw-w64-crt/lib64/msvcr100.def.in
+++ b/mingw-w64-crt/lib64/msvcr100.def.in
@@ -1679,6 +1679,7 @@ fseek
 fsetpos
 ftell
 fwprintf
+__ms_fwprintf == fwprintf
 fwprintf_s
 fwrite
 fwscanf
diff --git a/mingw-w64-crt/lib64/msvcr110.def.in 
b/mingw-w64-crt/lib64/msvcr110.def.in
index 6e8a487..5986892 100644
--- a/mingw-w64-crt/lib64/msvcr110.def.in
+++ b/mingw-w64-crt/lib64/msvcr110.def.in
@@ -1803,6 +1803,7 @@ fseek
 fsetpos
 ftell
 fwprintf
+__ms_fwprintf == fwprintf
 fwprintf_s
 fwrite
 fwscanf
diff --git a/mingw-w64-crt/lib64/msvcr120.def.in 
b/mingw-w64-crt/lib64/msvcr120.def.in
index 8784981..7afa0da 100644
--- a/mingw-w64-crt/lib64/msvcr120.def.in
+++ b/mingw-w64-crt/lib64/msvcr120.def.in
@@ -1967,6 +1967,7 @@ fseek
 fsetpos
 ftell
 fwprintf
+__ms_fwprintf == fwprintf
 fwprintf_s
 fwrite
 fwscanf
diff --git a/mingw-w64-crt/lib64/msvcr120_app.def.in 
b/mingw-w64-crt/lib64/msvcr120_app.def.in
index 8c60b42..53b2f7b 100644
--- a/mingw-w64-crt/lib64/msvcr120_app.def.in
+++ b/mingw-w64-crt/lib64/msvcr120_app.def.in
@@ -1326,6 +1326,7 @@ fseek
 fsetpos
 ftell
 fwprintf
+__ms_fwprintf == fwprintf
 fwprintf_s
 fwrite
 fwscanf
diff --git a/mingw-w64-crt/lib64/msvcr120d.def.in 
b/mingw-w64-crt/lib64/msvcr120d.def.in
index 2aab635..f5304d4 100644
--- a/mingw-w64-crt/lib64/msvcr120d.def.in
+++ b/mingw-w64-crt/lib64/msvcr120d.def.in
@@ -2032,6 +2032,7 @@ fseek
 fsetpos
 ftell
 fwprintf
+__ms_fwprintf == fwprintf
 fwprintf_s
 fwrite
 fwscanf
diff --git a/mingw-w64-crt/lib64/msvcr80.def.in 
b/mingw-w64-crt/lib64/msvcr80.def.in
index 18b8d2d..c84be87 100644
--- a/mingw-w64-crt/lib64/msvcr80.def.in
+++ b/mingw-w64-crt/lib64/msvcr80.def.in
@@ -713,6 +713,7 @@ fseek
 fsetpos
 ftell
 fwprintf
+__ms_fwprintf == fwprintf
 fwrite
 fwscanf
 getc
diff --git a/mingw-w64-crt/lib64/msvcr90.def.in 

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

[Mateusz]

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/include  -pipe -std=gnu99 
-D_WIN32_WINNT=0x0f00 -Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow 
-Wpacked -Winline -Wimplicit-function-declaration -Wmissing-noreturn 
-Wmissing-prototypes -pipe -O2 -MT libsrc/lib64_libtaskschd_a-taskschd.o -MD 
-MP -MF libsrc/.deps/lib64_libtaskschd_a-taskschd.Tpo -c -o 
libsrc/lib64_libtaskschd_a-taskschd.o `test -f 'libsrc/taskschd.c' || echo 
'/home/ma/m/source/mingw-w64-v5/mingw-w64-crt/'`libsrc/taskschd.c
mv -f libsrc/.deps/lib64_libtaskschd_a-taskschd.Tpo 
libsrc/.deps/lib64_libtaskschd_a-taskschd.Po
rm -f lib64/libtaskschd.a
/home/ma/m/cross/bin/x86_64-w64-mingw32-dlltool --as-flags=--64 -m i386:x86-64 
-k --as=/home/ma/m/cross/bin/x86_64-w64-mingw32-as --output-lib 
lib64/libtaskschd.a  --input-def 
/home/ma/m/source/mingw-w64-v5/mingw-w64-crt/`echo lib64/libtaskschd.a | 
/bin/sed 's|/lib|/|;s|\.a|.def|'` && /home/ma/m/cross/bin/x86_64-w64-mingw32-ar 
cru lib64/libtaskschd.a libsrc/lib64_libtaskschd_a-taskschd.o
/home/ma/m/cross/bin/x86_64-w64-mingw32-dlltool: Can't open def file: 
/home/ma/m/source/mingw-w64-v5/mingw-w64-crt/lib64/taskschd.def
Makefile:10879: recipe for target 'lib64/libtaskschd.a' failed
make[1]: *** [lib64/libtaskschd.a] Error 1


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
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] intrin-impl.h: Added __popcnt16, __popcnt, and __popcnt64.

[Mateusz]

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(ui[i]);
   ^
popcnt.cc:26:28: error: use of undeclared identifier '__popcnt64'; did you
mean '_popcnt64'?
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.

Probably its safe to enable it for Clang, I'll try tomorrow late.

2017-02-08 18:37 GMT+01:00 David Grayson :

> Hello.  This patch adds support for the Microsoft __popcnt16, __popcnt,
> and __popcnt64 intrinsics, which are documented here:
>
> https://msdn.microsoft.com/en-us/library/bb385231.aspx
>
> I was trying to compile ANGLE recently and one of the first errors I
> encountered was due to both GCC/mingw-w64 not supporting __popcnt.
>
> I attached the simple C++ program I used to test this patch.
>
> I am not totally sure, but it looks like Clang already supports the
> __popcnt intrinsics because I saw code for it in the clang repository.  So
> that is why this patch has "#if !defined(__clang__)" around it.
>
> I read the documentation for intrin.h and intrin-impl.h and I believe this
> patch follows all the rules.  It would be great if it could be merged in.
> Thanks!
>
> --David Grayson
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

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 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/include  -pipe -std=gnu99 
>> -D_WIN32_WINNT=0x0f00 -Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow 
>> -Wpacked -Winline -Wimplicit-function-declaration -Wmissing-noreturn 
>> -Wmissing-prototypes -pipe -O2 -MT libsrc/lib64_libtaskschd_a-taskschd.o -MD 
>> -MP -MF libsrc/.deps/lib64_libtaskschd_a-taskschd.Tpo -c -o 
>> libsrc/lib64_libtaskschd_a-taskschd.o `test -f 'libsrc/taskschd.c' || echo 
>> '/home/ma/m/source/mingw-w64-v5/mingw-w64-crt/'`libsrc/taskschd.c
>> mv -f libsrc/.deps/lib64_libtaskschd_a-taskschd.Tpo 
>> libsrc/.deps/lib64_libtaskschd_a-taskschd.Po
>> rm -f lib64/libtaskschd.a
>> /home/ma/m/cross/bin/x86_64-w64-mingw32-dlltool --as-flags=--64 -m 
>> i386:x86-64 -k --as=/home/ma/m/cross/bin/x86_64-w64-mingw32-as --output-lib 
>> lib64/libtaskschd.a  --input-def 
>> /home/ma/m/source/mingw-w64-v5/mingw-w64-crt/`echo lib64/libtaskschd.a | 
>> /bin/sed 's|/lib|/|;s|\.a|.def|'` && 
>> /home/ma/m/cross/bin/x86_64-w64-mingw32-ar cru lib64/libtaskschd.a 
>> libsrc/lib64_libtaskschd_a-taskschd.o
>> /home/ma/m/cross/bin/x86_64-w64-mingw32-dlltool: Can't open def file: 
>> /home/ma/m/source/mingw-w64-v5/mingw-w64-crt/lib64/taskschd.def
>> Makefile:10879: recipe for target 'lib64/libtaskschd.a' failed
>> make[1]: *** [lib64/libtaskschd.a] Error 1
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> 
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> 


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
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] intrin-impl.h: Added __popcnt16, __popcnt, and __popcnt64.

[Mateusz]

I think ms-extensions was made default option for mingw and msvc clang and
codegen is used only for creating msvc libs. Here is Clang output anyway:

$ clang++ popcnt.cc -std=c++14 -fms-extensions
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(ui[i]);
   ^
popcnt.cc:26:28: error: use of undeclared identifier '__popcnt64'; did you
mean '_popcnt64'?
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:10 GMT+01:00 David Grayson <davidegray...@gmail.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#L760-L762
> https://github.com/llvm-mirror/clang/blob/4cedfcc1ecf8387082183508604b7f
> 47c634f708/lib/CodeGen/CGBuiltin.cpp#L804-L821
>
> Can you try your clang test again with the "-fms-extensions" argument?
>
> (I tried to test clang myself earlier but I had various issues.  I
> could probably try again tonight if you don't want to.)
>
> --David
>
> On Wed, Feb 8, 2017 at 10:54 AM, Mateusz <mati...@gmail.com> wrote:
> > 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(ui[i]);
> >^
> > popcnt.cc:26:28: error: use of undeclared identifier '__popcnt64'; did
> you
> > mean '_popcnt64'?
> > 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.
> >
> > Probably its safe to enable it for Clang, I'll try tomorrow late.
> >
> > 2017-02-08 18:37 GMT+01:00 David Grayson <davidegray...@gmail.com>:
> >
> >> Hello.  This patch adds support for the Microsoft __popcnt16, __popcnt,
> >> and __popcnt64 intrinsics, which are documented here:
> >>
> >> https://msdn.microsoft.com/en-us/library/bb385231.aspx
> >>
> >> I was trying to compile ANGLE recently and one of the first errors I
> >> encountered was due to both GCC/mingw-w64 not supporting __popcnt.
> >>
> >> I attached the simple C++ program I used to test this patch.
> >>
> >> I am not totally sure, but it looks like Clang already supports the
> >> __popcnt intrinsics because I saw code for it in the clang repository.
> So
> >> that is why this patch has "#if !defined(__clang__)" around it.
> >>
> >> I read the documentation for intrin.h and intrin-impl.h and I believe
> this
> >> patch follows all the rules.  It would be great if it could be merged
> in.
> >> Thanks!
> >>
> >> --David Grayson
> >>
> >> 
> >> --
> >> Check out the vibrant tech community on one of the world's most
> >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> >> ___
> >> Mingw-w64-public mailing list
> >> Mingw-w64-public@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> >>
> >>
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > ___
> > Mingw-w64-public mailing list
> > Mingw-w64-public@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.or

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

[Mateusz]

Opps, gmail put output into quote. Improved version:
$ clang++ popcnt.cc -std=c++14 -fms-extensions
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(ui[i]);
   ^
popcnt.cc:26:28: error: use of undeclared identifier '__popcnt64'; did you
mean '_popcnt64'?
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 22:22 GMT+01:00 Mateusz <mati...@gmail.com>:

> I think ms-extensions was made default option for mingw and msvc clang and
> codegen is used only for creating msvc libs. Here is Clang output anyway:
>
> $ clang++ popcnt.cc -std=c++14 -fms-extensions
> 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(ui[i]);
>^
> popcnt.cc:26:28: error: use of undeclared identifier '__popcnt64'; did you
> mean '_popcnt64'?
> 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:10 GMT+01:00 David Grayson <davidegray...@gmail.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/3e45634a7f951c2306
>> e4b368f9fb8c8d80c48273/include/clang/Basic/Builtins.def#L760-L762
>> https://github.com/llvm-mirror/clang/blob/4cedfcc1ecf8387082
>> 183508604b7f47c634f708/lib/CodeGen/CGBuiltin.cpp#L804-L821
>>
>> Can you try your clang test again with the "-fms-extensions" argument?
>>
>> (I tried to test clang myself earlier but I had various issues.  I
>> could probably try again tonight if you don't want to.)
>>
>> --David
>>
>> On Wed, Feb 8, 2017 at 10:54 AM, Mateusz <mati...@gmail.com> wrote:
>> > 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(ui[i]);
>> >^
>> > popcnt.cc:26:28: error: use of undeclared identifier '__popcnt64'; did
>> you
>> > mean '_popcnt64'?
>> > 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.
>> >
>> > Probably its safe to enable it for Clang, I'll try tomorrow late.
>> >
>> > 2017-02-08 18:37 GMT+01:00 David Grayson <davidegray...@gmail.com>:
>> >
>> >> Hello.  This patch adds support for the Microsoft __popcnt16, __popcnt,
>> >> and __popcnt64 intrinsics, which are documented here:
>> >>
>> >> https://msdn.microsoft.com/en-us/library/bb385231.aspx
>> >>
>> >> I was trying to compile ANGLE recently and one of the first errors I
>> >> encountered was due to both GCC/mingw-w64 not supporting __popcnt.
>> >>
>> >> I attached the simple C++ program I used to test this patch.
>> >>
>> >> I am not totally sure, but it looks like Clang already supports the
>> >> __popcnt intrinsics because I saw code for it in the clang
>> repository.  So
>> >> that is why this patch has "#if !defined(__clang__)" around it.
>> >>
>> >> I read the documentation for intrin.h and intrin-impl.h and I believe
>> this
>> >> patch follows all the rules.  It would be great if it could be merged
>> in.
>> >> Thanks!
>> >>
>> 

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

[Mateusz]

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 Mikula <mati...@gmail.com>
Date: Mon, 30 Jan 2017 18:09:09 +0100
Subject: [PATCH] stdio.h: Ignore extern "C++" for Clang

---
 mingw-w64-headers/crt/stdio.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h
index c37ae15f..9c064246 100644
--- a/mingw-w64-headers/crt/stdio.h
+++ b/mingw-w64-headers/crt/stdio.h
@@ -218,7 +218,7 @@ int vasprintf(char **__ret, const char *__format,
__builtin_va_list __local_argv

 /* There seems to be a bug about builtins and static overrides of them
in g++.  So we need to do here some trickery.  */
-#ifdef __cplusplus
+#ifdef __cplusplus && !defined(__clang__)
 extern "C++" {
 #endif

@@ -367,7 +367,7 @@ int vsnprintf (char *__stream, size_t __n, const
char *__format, __builtin_va_li

 /* #endif */ /* __NO_ISOCEXT */

-#ifdef __cplusplus
+#ifdef __cplusplus && !defined(__clang__)
 }
 #endif

-- 
2.11.0


Regards,

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-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

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
+++ b/mingw-w64-crt/math/sqrt.def.h
@@ -66,14 +66,20 @@ __FLT_ABI (sqrt) (__FLT_TYPE x)
 {
   __FLT_TYPE res = __FLT_CST (0.0);
   int x_class = fpclassify (x);
-  if (x_class == FP_NAN || signbit (x))
+  if (x_class == FP_NAN)
 {
-  if (x_class == FP_ZERO)
-   return __FLT_CST (-0.0);
-
   __FLT_RPT_DOMAIN ("sqrt", x, 0.0, x);
   return x;
 }
+  else if (signbit (x))
+{
+  if (x_class == FP_ZERO)
+return __FLT_CST (-0.0);
+
+  res = -__FLT_NAN;
+  __FLT_RPT_DOMAIN ("sqrt", x, 0.0, res);
+  return res;
+}
   else if (x_class == FP_ZERO)
 return __FLT_CST (0.0);
   else if (x_class == FP_INFINITE)
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

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/math/sqrt.def.h b/mingw-w64-crt/math/sqrt.def.h
index 602409a..0cd401d 100644
--- a/mingw-w64-crt/math/sqrt.def.h
+++ b/mingw-w64-crt/math/sqrt.def.h
@@ -71,8 +71,15 @@ __FLT_ABI (sqrt) (__FLT_TYPE x)
   if (x_class == FP_ZERO)
return __FLT_CST (-0.0);
 
-  __FLT_RPT_DOMAIN ("sqrt", x, 0.0, x);
-  return x;
+  if (x_class == FP_NAN)
+{
+  __FLT_RPT_DOMAIN ("sqrt", x, 0.0, x);
+  return x;
+}
+
+  res = -__FLT_NAN;
+  __FLT_RPT_DOMAIN ("sqrt", x, 0.0, res);
+  return res;
 }
   else if (x_class == FP_ZERO)
 return __FLT_CST (0.0);
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

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 +
 1 file changed, 1 insertion(+)

diff --git a/mingw-w64-headers/include/setupapi.h
b/mingw-w64-headers/include/setupapi.h
index a0244a3..f029b80 100644
--- a/mingw-w64-headers/include/setupapi.h
+++ b/mingw-w64-headers/include/setupapi.h
@@ -7,6 +7,7 @@
 #define _INC_SETUPAPI

 #include <_mingw_unicode.h>
+#include 

 #ifndef _SETUPAPI_
 #define WINSETUPAPI DECLSPEC_IMPORT
-- 
2.9.1
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

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 year so it's even more strange.
crt-git package and it's sources can be found here
http://repo.msys2.org/mingw/

2016-09-30 6:58 GMT+02:00 David Wohlferd :

> Just those few?  How about the rest of extras-uuid.c?  The only ones
> that don't look like dupes are:
>
> DEFINE_GUID(IID_IEnumSTATURL,0x3c374a42,0xbae4,0x11cf,0xbf,
> 0x7d,0,0xaa,0,0x69,0x46,0xee);
> DEFINE_GUID(IID_IHttpNegotiate,0x79eac9d2,0xbaf9,0x11ce,0x8c,0x82,0,
> 0xaa,0,0x4b,0xa9,0xb);
> DEFINE_GUID(IID_IUrlHistoryStg,0x3c374a41,0xbae4,0x11cf,0xbf,0x7d,0,
> 0xaa,0,0x69,0x46,0xee);
> DEFINE_GUID(IID_IWinInetHttpInfo,0x79eac9d8,0xbafa,0x11ce,0x8c,0x82,0,
> 0xaa,0,0x4b,0xa9,0xb);
> DEFINE_GUID(IID_IWinInetInfo,0x79eac9d6,0xbafa,0x11ce,0x8c,
> 0x82,0,0xaa,0,0x4b,0xa9,0xb);
>
> dw
>
>
> On 9/29/2016 8:39 AM, LaurentP wrote:
> >
> > In latest git (tested with MSYS2) The following UUIDs are defined both
> > in uuid.c and extra-uuid.c leading to links failures with duplicate
> > symbols when using libuuid.a :
> >
> > // file:, local: Asychronous Pluggable Protocol Handler CLSID
> > DEFINE_GUID(CLSID_FileProtocol,0x79eac9e7,0xbaf9,0x11ce,0x8c,0x82,0,
> 0xaa,0,0x4b,0xa9,0xb);
> > // ftp: Asychronous Pluggable Protocol Handler CLSID
> > DEFINE_GUID(CLSID_FtpProtocol,0x79eac9e3,0xbaf9,0x11ce,0x8c,
> 0x82,0,0xaa,0,0x4b,0xa9,0xb);
> > // gopher: Asychronous Pluggable Protocol Handler CLSID
> > DEFINE_GUID(CLSID_GopherProtocol,0x79eac9e4,0xbaf9,0x11ce,0x8c,0x82,0,
> 0xaa,0,0x4b,0xa9,0xb);
> > // http: Asychronous Pluggable Protocol Handler CLSID
> > DEFINE_GUID(CLSID_HttpProtocol,0x79eac9e2,0xbaf9,0x11ce,0x8c,0x82,0,
> 0xaa,0,0x4b,0xa9,0xb);
> > // https: Asychronous Pluggable Protocol Handler CLSID
> > DEFINE_GUID(CLSID_HttpSProtocol,0x79eac9e5,0xbaf9,0x11ce,0x8c,0x82,0,
> 0xaa,0,0x4b,0xa9,0xb);
> > // mk: Asychronous Pluggable Protocol Handler CLSID
> > DEFINE_GUID(CLSID_MkProtocol,0x79eac9e6,0xbaf9,0x11ce,0x8c,
> 0x82,0,0xaa,0,0x4b,0xa9,0xb);
> > // URLMoniker ProxyStub Factory CLSID
> > DEFINE_GUID(CLSID_PSUrlMonProxy,0x79eac9f1,0xbaf9,0x11ce,0x8c,0x82,0,
> 0xaa,0,0x4b,0xa9,0xb);
> > // URL Moniker CLSID
> > DEFINE_GUID(CLSID_StdURLMoniker,0x79eac9e0,0xbaf9,0x11ce,0x8c,0x82,0,
> 0xaa,0,0x4b,0xa9,0xb);
> >
> > I've filed a ticket for that one
> >
> > Reagrds
> >
>
>
> 
> --
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

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 applies only to initialized variables with external
linkage
 EXTERN_C const DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_CLSID =
{{0xc57a84c0,0x1a80,0x40a3,{0x97,0xb5,0x92,0x72,0xa4,0x3,0xc8,0xae}}, 0x01};
   ^~~~
D:/msys64/mingw64/x86_64-w64-mingw32/include/mftransform.h:710:47: error:
'selectany' attribute applies only to initialized variables with external
linkage
 EXTERN_C const DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_CATEGORY =
{{0xc57a84c0,0x1a80,0x40a3,{0x97,0xb5,0x92,0x72,0xa4,0x3,0xc8,0xae}}, 0x02
};
   ^~~
D:/msys64/mingw64/x86_64-w64-mingw32/include/mftransform.h:711:47: error:
'selectany' attribute applies only to initialized variables with external
linkage
 EXTERN_C const DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_EXATTRIBUTE_SUPPORTED
= {{0x456fe843,0x3c87,0x40c0,{0x94,0x9d,0x14,0x9,0xc9,0x7d,0xab,0x2c}},
0x01};
   ^~~~
D:/msys64/mingw64/x86_64-w64-mingw32/include/mftransform.h:712:47: error:
'selectany' attribute applies only to initialized variables with external
linkage
 EXTERN_C const DECLSPEC_SELECTANY PROPERTYKEY
MFPKEY_MULTICHANNEL_CHANNEL_MASK  =
{{0x58bdaf8c,0x3224,0x4692,{0x86,0xd0,0x44,0xd6,0x5c,0x5b,0xf8,0x2b}},
0x01};

^~~~
D:/msys64/mingw64/x86_64-w64-mingw32/include/mftransform.h:713:40: error:
'selectany' attribute applies only to initialized variables with external
linkage
 EXTERN_C const DECLSPEC_SELECTANY GUID MF_SA_D3D_AWARE =
{0xeaa35c29,0x775e,0x488e,{0x9b,0x61,0xb3,0x28,0x3e,0x49,0x58,0x3b}};
^~~
D:/msys64/mingw64/x86_64-w64-mingw32/include/mftransform.h:714:40: error:
'selectany' attribute applies only to initialized variables with external
linkage
 EXTERN_C const DECLSPEC_SELECTANY GUID MF_SA_REQUIRED_SAMPLE_COUNT =
{0x18802c61,0x324b,0x4952,{0xab,0xd0,0x17,0x6f,0xf5,0xc6,0x96,0xff}};
^~~
D:/msys64/mingw64/x86_64-w64-mingw32/include/mftransform.h:715:40: error:
'selectany' attribute applies only to initialized variables with external
linkage
 EXTERN_C const DECLSPEC_SELECTANY GUID MF_TRANSFORM_ASYNC =
{0xf81a699a,0x649a,0x497d,{0x8c,0x73,0x29,0xf8,0xfe,0xd6,0xad,0x7a}};
^~
D:/msys64/mingw64/x86_64-w64-mingw32/include/mftransform.h:716:40: error:
'selectany' attribute applies only to initialized variables with external
linkage
 EXTERN_C const DECLSPEC_SELECTANY GUID MF_TRANSFORM_ASYNC_UNLOCK =
{0xe5666d6b,0x3422,0x4eb6,{0xa4,0x21,0xda,0x7d,0xb1,0xf8,0xe2,0x7}};
^
D:/msys64/mingw64/x86_64-w64-mingw32/include/mftransform.h:717:40: error:
'selectany' attribute applies only to initialized variables with external
linkage
 EXTERN_C const DECLSPEC_SELECTANY GUID MF_TRANSFORM_FLAGS_Attribute =
{0x9359bb7e,0x6275,0x46c4,{0xa0,0x25,0x1c,0x1,0xe4,0x5f,0x1a,0x86}};
^~~~
D:/msys64/mingw64/x86_64-w64-mingw32/include/mftransform.h:718:40: error:
'selectany' attribute applies only to initialized variables with external
linkage
 EXTERN_C const DECLSPEC_SELECTANY GUID MF_TRANSFORM_CATEGORY_Attribute =
{0xceabba49,0x506d,0x4757,{0xa6,0xff,0x66,0xc1,0x84,0x98,0x7e,0x4e}};
^~~
D:/msys64/mingw64/x86_64-w64-mingw32/include/mftransform.h:719:40: error:
'selectany' attribute applies only to initialized variables with external
linkage
 EXTERN_C const DECLSPEC_SELECTANY GUID MFT_TRANSFORM_CLSID_Attribute =
{0x6821c42b,0x65a4,0x4e82,{0x99,0xbc,0x9a,0x88,0x20,0x5e,0xcd,0xc}};
^
D:/msys64/mingw64/x86_64-w64-mingw32/include/mftransform.h:720:40: error:
'selectany' attribute applies only to initialized variables with external
linkage
 EXTERN_C const DECLSPEC_SELECTANY GUID MFT_INPUT_TYPES_Attributes =
{0x4276c9b1,0x759d,0x4bf3, {0x9c,0xd0,0xd,0x72,0x3d,0x13,0x8f,0x96}};
^~
D:/msys64/mingw64/x86_64-w64-mingw32/include/mftransform.h:721:40: error:
'selectany' attribute applies only to initialized variables with external
linkage
 EXTERN_C const DECLSPEC_SELECTANY GUID MFT_OUTPUT_TYPES_Attributes =
{0x8eae8cf3,0xa44f,0x4306,{0xba,0x5c,0xbf,0x5d,0xda,0x24,0x28,0x18}};
^~~
D:/msys64/mingw64/x86_64-w64-mingw32/include/mftransform.h:722:40: error:
'selectany' attribute 

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

[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 'type-name' declaration specifier
typedef uint_least16_t char16_t;
   ^
D:\projekty\msys2\clang\msys64\mingw32\i686-w64-mingw32\include\uchar.h:35:24:
e   rror: cannot combine with previous 'type-name' declaration specifier
typedef uint_least32_t char32_t;
   ^
2 errors generated.
"

>From e98ec7a116256108831f035eb0a7f0f2fdf049e9 Mon Sep 17 00:00:00 2001
From: mati865 
Date: Wed, 28 Sep 2016 11:45:40 +0200
Subject: [PATCH] fix uchar.h for Clang

Clang defines itself as GCC 4.2.1 and triggers check for GCC lower than
4.4.0.\
This patch adds additional !defined(__clang__) check
---
 mingw-w64-headers/crt/uchar.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/mingw-w64-headers/crt/uchar.h b/mingw-w64-headers/crt/uchar.h
index 475ad87..ab8a26d 100644
--- a/mingw-w64-headers/crt/uchar.h
+++ b/mingw-w64-headers/crt/uchar.h
@@ -30,7 +30,7 @@
 /* Remember that g++ >= 4.4 defines these types only in c++0x mode */
 #if !(defined(__cplusplus) && defined(__GXX_EXPERIMENTAL_CXX0X__)) ||\
 !defined(__GNUC__) ||\
-(__GNUC__ < 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
@@ -70,4 +70,3 @@ size_t c32rtomb (char *__restrict__ s,
 #endif

 #endif /* __UCHAR_H */
-
-- 
2.9.1
--
___
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] fix uchar.h for Clang

[Mateusz]

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 previous 'type-name' declaration specifier
> typedef uint_least16_t char16_t;
>^
> D:\projekty\msys2\clang\msys64\mingw32\i686-w64-mingw32\include\uchar.h:35:24:
> e   rror: cannot combine with previous 'type-name' declaration specifier
> typedef uint_least32_t char32_t;
>^
> 2 errors generated.
> "
>
> From e98ec7a116256108831f035eb0a7f0f2fdf049e9 Mon Sep 17 00:00:00 2001
> From: mati865 <mati...@gmail.com>
> Date: Wed, 28 Sep 2016 11:45:40 +0200
> Subject: [PATCH] fix uchar.h for Clang
>
> Clang defines itself as GCC 4.2.1 and triggers check for GCC lower than
> 4.4.0.\
> This patch adds additional !defined(__clang__) check
> ---
>  mingw-w64-headers/crt/uchar.h | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/mingw-w64-headers/crt/uchar.h b/mingw-w64-headers/crt/uchar.h
> index 475ad87..ab8a26d 100644
> --- a/mingw-w64-headers/crt/uchar.h
> +++ b/mingw-w64-headers/crt/uchar.h
> @@ -30,7 +30,7 @@
>  /* Remember that g++ >= 4.4 defines these types only in c++0x mode */
>  #if !(defined(__cplusplus) && defined(__GXX_EXPERIMENTAL_CXX0X__)) ||
> \
>  !defined(__GNUC__) ||\
> -(__GNUC__ < 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
> @@ -70,4 +70,3 @@ size_t c32rtomb (char *__restrict__ s,
>  #endif
>
>  #endif /* __UCHAR_H */
> -
> --
> 2.9.1
>
--
___
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] fix uchar.h for Clang

[Mateusz]

Looks attachment didn't work.
Here is the patch:

>From e98ec7a116256108831f035eb0a7f0f2fdf049e9 Mon Sep 17 00:00:00 2001
From: mati865 <mati...@gmail.com>
Date: Wed, 28 Sep 2016 11:45:40 +0200
Subject: [PATCH] fix uchar.h for Clang

Clang defines itself as GCC 4.2.1 and triggers check for GCC lower than
4.4.0.
This patch adds additional !defined(__clang__) check
---
 mingw-w64-headers/crt/uchar.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mingw-w64-headers/crt/uchar.h b/mingw-w64-headers/crt/uchar.h
index 475ad87..ab8a26d 100644
--- a/mingw-w64-headers/crt/uchar.h
+++ b/mingw-w64-headers/crt/uchar.h
@@ -30,7 +30,7 @@
 /* Remember that g++ >= 4.4 defines these types only in c++0x mode */
 #if !(defined(__cplusplus) && defined(__GXX_EXPERIMENTAL_CXX0X__)) ||\
 !defined(__GNUC__) ||\
-(__GNUC__ < 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.com>:

> 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 previous 'type-name' declaration specifier
>> typedef uint_least16_t char16_t;
>>^
>> D:\projekty\msys2\clang\msys64\mingw32\i686-w64-mingw32\include\uchar.h:35:24:
>> e   rror: cannot combine with previous 'type-name' declaration specifier
>> typedef uint_least32_t char32_t;
>>^
>> 2 errors generated.
>> "
>>
>> From e98ec7a116256108831f035eb0a7f0f2fdf049e9 Mon Sep 17 00:00:00 2001
>> From: mati865 <mati...@gmail.com>
>> Date: Wed, 28 Sep 2016 11:45:40 +0200
>> Subject: [PATCH] fix uchar.h for Clang
>>
>> Clang defines itself as GCC 4.2.1 and triggers check for GCC lower than
>> 4.4.0.\
>> This patch adds additional !defined(__clang__) check
>> ---
>>  mingw-w64-headers/crt/uchar.h | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/mingw-w64-headers/crt/uchar.h b/mingw-w64-headers/crt/uchar.
>> h
>> index 475ad87..ab8a26d 100644
>> --- a/mingw-w64-headers/crt/uchar.h
>> +++ b/mingw-w64-headers/crt/uchar.h
>> @@ -30,7 +30,7 @@
>>  /* Remember that g++ >= 4.4 defines these types only in c++0x mode */
>>  #if !(defined(__cplusplus) && defined(__GXX_EXPERIMENTAL_CXX0X__))
>> ||\
>>  !defined(__GNUC__) ||\
>> -(__GNUC__ < 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
>> @@ -70,4 +70,3 @@ size_t c32rtomb (char *__restrict__ s,
>>  #endif
>>
>>  #endif /* __UCHAR_H */
>> -
>> --
>> 2.9.1
>>
>
>
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

Laurent reported in MSYS2 bug tracker that this patch didn't help.

Also this is interesting:

>
>- crt 4680:
>
> $ nm /mingw64/x86_64-w64-mingw32/lib/libuuid.a | grep "MkProtocol\|\.o"
> ...
> lib64_libuuid_a-extras-uuid.o:
>  r .rdata$CLSID_MkProtocol
>  R CLSID_MkProtocol
> ...
> lib64_libuuid_a-uuid.o:
>  r .rdata$CLSID_MkProtocol
>  R CLSID_MkProtocol
> ...
>
>
>- crt 4734:
>
> $ nm /mingw64/x86_64-w64-mingw32/lib/libuuid.a | grep "MkProtocol\|\.o"
> ...
> lib64_libuuid_a-extras-uuid.o:
>  r .rdata$CLSID_MkProtocol
>  R CLSID_MkProtocol
> ...
> lib64_libuuid_a-uuid.o:
> 00b0 R CLSID_MkProtocol
> ...
>
>
2016-09-30 10:49 GMT+02:00 David Wohlferd <d...@limegreensocks.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/issues/1712#issuec
>> omment-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 year so it's even more strange.
>> crt-git package and it's sources can be found here
>> http://repo.msys2.org/mingw/
>>
>> 2016-09-30 6:58 GMT+02:00 David Wohlferd <d...@limegreensocks.com>:
>>
>> Just those few?  How about the rest of extras-uuid.c?  The only ones
>>> that don't look like dupes are:
>>>
>>> DEFINE_GUID(IID_IEnumSTATURL,0x3c374a42,0xbae4,0x11cf,0xbf,
>>> 0x7d,0,0xaa,0,0x69,0x46,0xee);
>>> DEFINE_GUID(IID_IHttpNegotiate,0x79eac9d2,0xbaf9,0x11ce,0x8c,0x82,0,
>>> 0xaa,0,0x4b,0xa9,0xb);
>>> DEFINE_GUID(IID_IUrlHistoryStg,0x3c374a41,0xbae4,0x11cf,0xbf,0x7d,0,
>>> 0xaa,0,0x69,0x46,0xee);
>>> DEFINE_GUID(IID_IWinInetHttpInfo,0x79eac9d8,0xbafa,0x11ce,0x8c,0x82,0,
>>> 0xaa,0,0x4b,0xa9,0xb);
>>> DEFINE_GUID(IID_IWinInetInfo,0x79eac9d6,0xbafa,0x11ce,0x8c,
>>> 0x82,0,0xaa,0,0x4b,0xa9,0xb);
>>>
>>> dw
>>>
>>>
>>> On 9/29/2016 8:39 AM, LaurentP wrote:
>>>
>>>> In latest git (tested with MSYS2) The following UUIDs are defined both
>>>> in uuid.c and extra-uuid.c leading to links failures with duplicate
>>>> symbols when using libuuid.a :
>>>>
>>>> // file:, local: Asychronous Pluggable Protocol Handler CLSID
>>>> DEFINE_GUID(CLSID_FileProtocol,0x79eac9e7,0xbaf9,0x11ce,0x8c,0x82,0,
>>>>
>>> 0xaa,0,0x4b,0xa9,0xb);
>>>
>>>> // ftp: Asychronous Pluggable Protocol Handler CLSID
>>>> DEFINE_GUID(CLSID_FtpProtocol,0x79eac9e3,0xbaf9,0x11ce,0x8c,
>>>>
>>> 0x82,0,0xaa,0,0x4b,0xa9,0xb);
>>>
>>>> // gopher: Asychronous Pluggable Protocol Handler CLSID
>>>> DEFINE_GUID(CLSID_GopherProtocol,0x79eac9e4,0xbaf9,0x11ce,0x8c,0x82,0,
>>>>
>>> 0xaa,0,0x4b,0xa9,0xb);
>>>
>>>> // http: Asychronous Pluggable Protocol Handler CLSID
>>>> DEFINE_GUID(CLSID_HttpProtocol,0x79eac9e2,0xbaf9,0x11ce,0x8c,0x82,0,
>>>>
>>> 0xaa,0,0x4b,0xa9,0xb);
>>>
>>>> // https: Asychronous Pluggable Protocol Handler CLSID
>>>> DEFINE_GUID(CLSID_HttpSProtocol,0x79eac9e5,0xbaf9,0x11ce,0x8c,0x82,0,
>>>>
>>> 0xaa,0,0x4b,0xa9,0xb);
>>>
>>>> // mk: Asychronous Pluggable Protocol Handler CLSID
>>>> DEFINE_GUID(CLSID_MkProtocol,0x79eac9e6,0xbaf9,0x11ce,0x8c,
>>>>
>>> 0x82,0,0xaa,0,0x4b,0xa9,0xb);
>>>
>>>> // URLMoniker ProxyStub Factory CLSID
>>>> DEFINE_GUID(CLSID_PSUrlMonProxy,0x79eac9f1,0xbaf9,0x11ce,0x8c,0x82,0,
>>>>
>>> 0xaa,0,0x4b,0xa9,0xb);
>>>
>>>> // URL Moniker CLSID
>>>> DEFINE_GUID(CLSID_StdURLMoniker,0x79eac9e0,0xbaf9,0x11ce,0x8c,0x82,0,
>>>>
>>> 0xaa,0,0x4b,0xa9,0xb);
>>>
>>>> I've filed a ticket for that one
>>>>
>>>> Reagrds
>>>>
>>>>
>>> 
>>> --
>>> ___
>>> Mingw-w64-public mailing list
>>> Mingw-w64-public@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>>
>>> 
>> --
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>>
>
> 
> --
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
--
___
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] fix uchar.h for Clang

[Mateusz]

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 the patch:
> >
> >> From e98ec7a116256108831f035eb0a7f0f2fdf049e9 Mon Sep 17 00:00:00
> >> 2001
> > From: mati865 <mati...@gmail.com> Date: Wed, 28 Sep 2016 11:45:40
> > +0200 Subject: [PATCH] fix uchar.h for Clang
> >
> > Clang defines itself as GCC 4.2.1 and triggers check for GCC lower
> > than 4.4.0. This patch adds additional !defined(__clang__) check
> > --- mingw-w64-headers/crt/uchar.h | 2 +- 1 file changed, 1
> > insertion(+), 1 deletion(-)
> >
> > diff --git a/mingw-w64-headers/crt/uchar.h
> > b/mingw-w64-headers/crt/uchar.h index 475ad87..ab8a26d 100644 ---
> > a/mingw-w64-headers/crt/uchar.h +++
> > b/mingw-w64-headers/crt/uchar.h @@ -30,7 +30,7 @@ /* Remember that
> > g++ >= 4.4 defines these types only in c++0x mode */ #if
> > !(defined(__cplusplus) && defined(__GXX_EXPERIMENTAL_CXX0X__)) ||
> > \ !defined(__GNUC__) ||\ -(__GNUC__ < 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
> >
>
> Patch looks OK.
>
>
> -BEGIN PGP SIGNATURE-
>
> iF4EAREIAAYFAlfr01kACgkQk721PNTrx0D/oAD7BQAqa+mfswOGE5VF+tqOBGhA
> fwdzqx9Ame+pT4PjC7sBAIUFQvSfIuffAkLVe6vUZVzzmae4JzzZ+CkyfUT/ZuTp
> =j/Ue
> -END PGP SIGNATURE-
>
> --
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
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] guiddef.h: Use __declspec(selectany) on GUID declarations.

[Mateusz]

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:\msys\m64-54\x86_64-w64-mingw32\include\combaseapi.h:156:0,
 from f:\msys\m64-54\x86_64-w64-mingw32\include\objbase.h:14,
 from f:\msys\m64-54\x86_64-w64-mingw32\include\ole2.h:17,
 from f:\msys\m64-54\x86_64-w64-mingw32\include\ocidl.h:12,
 from f:\msys\m64-54\x86_64-w64-mingw32\include\olectl.h:15,
 from f:\msys\m64-54\x86_64-w64-mingw32\include\dshow.h:28,
 from libavdevice/dshow_capture.h:33,
 from libavdevice/dshow.c:22:
libavdevice/dshow.c: In function 'dshow_add_device':
f:\msys\m64-54\x86_64-w64-mingw32\include\uuids.h:228:1: error: 
'FORMAT_VideoInfo':'selectany' attribute applies only to initial
ized objects
 
OUR_GUID_ENTRY(FORMAT_VideoInfo,0x05589f80,0xc356,0x11ce,0xbf,0x01,0x00,0xaa,0x00,0x55,0x59,0x5a)
 ^
f:\msys\m64-54\x86_64-w64-mingw32\include\uuids.h:229:1: error: 
'FORMAT_VideoInfo2':'selectany' attribute applies only to initia
lized objects
 
OUR_GUID_ENTRY(FORMAT_VideoInfo2,0xf72a76A0,0xeb0a,0x11d0,0xac,0xe4,0x00,0x00,0xc0,0xcc,0x16,0xba)
 ^
f:\msys\m64-54\x86_64-w64-mingw32\include\uuids.h:230:1: error: 
'FORMAT_WaveFormatEx':'selectany' attribute applies only to init
ialized objects
 
OUR_GUID_ENTRY(FORMAT_WaveFormatEx,0x05589f81,0xc356,0x11ce,0xbf,0x01,0x00,0xaa,0x00,0x55,0x59,0x5a)
 ^ 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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] guiddef.h: Use __declspec(selectany) on GUID declarations.

[Mateusz]

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 I'm
> imagining it will introduce new incompatibilities/quirks that people have
> to worry about when switching between Visual Studio and mingw-w64, because
> you would have to prevent any GUID definitions from being emitted by header
> files.
> 
> --David
> 
> On Wed, May 3, 2017 at 8:12 AM, David Grayson 
> wrote:
> 
>>> It sounds like guiddef.h should probably check the GCC major version.
 Based on the tests people have reported in this thread, I would guess
>>> that
 for GCC 6 and above the selectany attribute on the declaration is
>>> required,
 while on GCC 5 and below the selectany attribute on the declaration is
 forbidden. Or we could get fancy and add a test to the configure script
>>> to
 figure out which is the case.
>>> Both require citation from GCC documentation. But neither is an optimal
>>> solution IMHO. I suggest we ensure each GUID is defined only once then
>>> remove that attribute completely.
>>>
>>
>> When you say "optimal", what are you optimizing for?
>>
>> I'm trying to optimize for being able to port code from Visual Studio to
>> mingw-w64.  Microsoft has example code (UsbView) that has a header file
>> that includes the windows.h, followed by initguid.h, followed by
>> winioctl.h.  You can see the header file here:
>>
>> https://github.com/Microsoft/Windows-driver-samples/blob/
>> master/usb/usbview/uvcview.h
>>
>> The UsbView code uses that header file in several different translation
>> units, so you end up having a bunch of duplicate GUID definitions for all
>> the GUIDs defined in winioctl.h, like GUID_DEVINTERFACE_DISK.  To prevent
>> multiple definition errors, the Microsoft header files using the selectany
>> attribute.
>>
>> I don't know why Microsoft engineered such a complicated solution for
>> defining GUIDs, but they did, and I would think we should try to make our
>> header files compatible with it.  If it just takes a few preprocessor if
>> statements that check the GCC version, that seems OK.
>>
>> --David
>>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> 

diff --git a/mingw-w64-headers/include/guiddef.h 
b/mingw-w64-headers/include/guiddef.h
index 9ecea3e..aaa3316 100644
--- a/mingw-w64-headers/include/guiddef.h
+++ b/mingw-w64-headers/include/guiddef.h
@@ -36,8 +36,12 @@ __extension__ template const GUID 
&__mingw_uuidof();
 #endif
 
 #ifndef DECLSPEC_SELECTANY
+#if defined (__GNUC__) && __GNUC__ < 6
+#define DECLSPEC_SELECTANY __attribute__((weak))
+#else
 #define DECLSPEC_SELECTANY __declspec(selectany)
 #endif
+#endif
 
 #ifndef EXTERN_C
 #ifdef __cplusplus
@@ -58,8 +62,7 @@ __extension__ template const GUID 
&__mingw_uuidof();
 #define DEFINE_GUID(name,l,w1,w2,b1,b2,b3,b4,b5,b6,b7,b8) const GUID 
DECLSPEC_SELECTANY name = { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } }
 #endif
 #else
-/* __declspec(selectany) must be applied to initialized objects on GCC 5 hence 
must not be used here. */
-#define DEFINE_GUID(name,l,w1,w2,b1,b2,b3,b4,b5,b6,b7,b8) EXTERN_C const GUID 
name
+#define DEFINE_GUID(name,l,w1,w2,b1,b2,b3,b4,b5,b6,b7,b8) EXTERN_C const GUID 
DECLSPEC_SELECTANY name
 #endif
 
 #define DEFINE_OLEGUID(name, l, w1, w2) DEFINE_GUID (name, l, w1, w2, 0xc0, 0, 
0, 0, 0, 0, 0, 0x46)
diff --git a/mingw-w64-headers/include/ksguid.h 
b/mingw-w64-headers/include/ksguid.h
index eca0269..71462c2 100644
--- a/mingw-w64-headers/include/ksguid.h
+++ b/mingw-w64-headers/include/ksguid.h
@@ -7,8 +7,12 @@
 #include 
 
 #ifndef DECLSPEC_SELECTANY
+#if defined (__GNUC__) && __GNUC__ < 6
+#define DECLSPEC_SELECTANY __attribute__((weak))
+#else
 #define DECLSPEC_SELECTANY __declspec(selectany)
 #endif
+#endif
 
 #ifdef DEFINE_GUIDEX
 #undef DEFINE_GUIDEX
diff --git a/mingw-w64-headers/include/ntdef.h 
b/mingw-w64-headers/include/ntdef.h
index e3e29e7..02c9722 100644
--- a/mingw-w64-headers/include/ntdef.h
+++ b/mingw-w64-headers/include/ntdef.h
@@ -273,7 +273,11 @@
 
 #ifndef DECLSPEC_SELECTANY
 #if (_MSC_VER >= 1100) || defined(__GNUC__)
+#if defined (__GNUC__) && __GNUC__ < 6
+#define DECLSPEC_SELECTANY __attribute__((weak))
+#else
 #define DECLSPEC_SELECTANY __declspec(selectany)
+#endif
 #else
 #define DECLSPEC_SELECTANY
 #endif
diff --git a/mingw-w64-headers/include/objsel.h 
b/mingw-w64-headers/include/objsel.h
index 7e8ed1d..5f3a05b 100644
--- a/mingw-w64-headers/include/objsel.h

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

[Mateusz]

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 projects.  We made about this already a lot of bad experiences
>> ... especially in context of MIDL ... defining
>> IN/OUT/INOUT/OPTIONAL/etc is really no clever move ...
>> Nevertheless it might be worth a try to ask libstdc++ people for those
>> __in A good argument (and bad one too) might be that the double
>> underscore symbols are reserved to compilers/system headers.  And
>> well, C++ headers aren't really system headers, which is in general
>> just a POV ;)
> I suggest we comment out `__in` and `__out` from _driverspecs.h_. The 
> compatibility with GNU libstdc++ and LLVM libcxx is more essential than 
> that with Windows in my opinion.

+1

> 
> These macros are defined after including _windows.h_ from official 
> Windows SDK, as shown in this example:
> 
> 
> E:\Desktop>cat test.c
> #include 
> #include 
> 
> int main(){
> #if defined(__in)
>  puts("__in is defined.");
> #else
>  puts("__in is not defined.");
> #endif
> }
> 
> E:\Desktop>cl test.c /nologo /Fea.exe
> test.c
> 
> E:\Desktop>cat test.c
> #include 
> #include 
> 
> int main(){
> #if defined(__in)
>  puts("__in is defined.");
> #else
>  puts("__in is not defined.");
> #endif
> }
> 
> E:\Desktop>cl test.c /nologo /Fe:a.exe
> test.c
> 
> E:\Desktop>a.exe
> __in is defined.
> 
> E:\Desktop>gcc test.c
> 
> E:\Desktop>a.exe
> __in is not defined.
> 
> 
> 


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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] comment out '__in' and '__out' from driverspecs.h for compatibility with libstdc++

[Mateusz]

W dniu 2017-05-17 o 16:35, Kai Tietz pisze:
> 2017-05-17 16:25 GMT+02:00 David Grayson <davidegray...@gmail.com>:
>> On Wed, May 17, 2017 at 4:10 AM, Kai Tietz <ktiet...@googlemail.com> wrote:
>>> The best solution would be something like to include
>>> driverspecs.h in specstring.h only, if user intends to use ddk.
>>
>> Is that how the real DDK works?  When you don't have the DDK
>> installed, you can still include specstrings.h but it somehow does not
>> include driverspecs.h?
>>
>> --David Grayson
> 
> No idea, and nothing of much interest to us AFAICS.  For us, ddk is an
> optional component. It isn't mandatory to include it at all. It is
> controlled by an configure option to our header's build.
> 
> That means, to rely on driverspecs.h seems to be the wrong thing.
> Including it on purpose, if user wants it, sounds something 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 info to comment 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, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> 


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

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 2fa89a1..d8d2f1b 100644
--- a/mingw-w64-headers/include/driverspecs.h
+++ b/mingw-w64-headers/include/driverspecs.h
@@ -15,11 +15,15 @@
 /*
  * FIXME: These annotations are not driver-only and does not belong here
  */
-#define __in
+/* for compatibility with GNU libstdc++ we comment out
+ * #define __in
+ */
 #define __in_bcount(Size)
 #define __in_ecount(Size)
 
-#define __out
+/* for compatibility with GNU libstdc++ we comment out
+ * #define __out
+ */
 #define __out_bcount(Size)
 #define __out_bcount_part(Size, Length)
 #define __out_ecount(Size)
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
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] comment out '__in' and '__out' from driverspecs.h for compatibility with libstdc++

[Mateusz]

W dniu 2017-05-17 o 13:10, Kai Tietz pisze:
> Hello,
> 
> I dislike such a change.  As if somebody wants to driverspec.h, op
> will need these symbols defined.  Otherwise build will badly fail.
> So this brings us back to the reasoning of this ... adding to
> specstrings.h the include of driverspecs.h.  IMHO this shouldn't be
> done always.  The best solution would be something like to include
> driverspecs.h in specstring.h only, if user intends to use ddk.
> Otherwise we shouldn't include this header at all.
> 
> Any thoughts?
> 
> Regards,
> 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 <mateu...@poczta.onet.pl>:
>> We really should do something with '__in' and '__out' from driverspecs.h.
>>
>> Please review.
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> 


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

Hello,

>From revision 248028 in GCC 8 there is defined function _xgetbv:
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/i386/xsaveintrin.h?r1=248028=248027=248028

It conflicting with mingw-w64 definition from 
mingw-w64-headers/include/psdk_inc/intrin-impl.h

I made workaround for mingw-w64:
diff --git a/mingw-w64-headers/include/psdk_inc/intrin-impl.h 
b/mingw-w64-headers/include/psdk_inc/intrin-impl.h
index 340d6fb..f5fd84b 100644
--- a/mingw-w64-headers/include/psdk_inc/intrin-impl.h
+++ b/mingw-w64-headers/include/psdk_inc/intrin-impl.h
@@ -1631,6 +1631,7 @@ __buildmov(__movsd, unsigned __LONG32, "d")
 #define __INTRINSIC_DEFINED___movsd
 #endif /* __INTRINSIC_PROLOG */
 
+#if __GNUC__ < 8 /* GCC 8 already has _xgetbv defined */
 /* NOTE: This should be in immintrin.h */
 #if __INTRINSIC_PROLOG(_xgetbv)
 unsigned __int64 _xgetbv(unsigned int);
@@ -1654,6 +1655,7 @@ unsigned __int64 _xgetbv(unsigned int index)
 #endif
 #define __INTRINSIC_DEFINED__xgetbv
 #endif /* __INTRINSIC_PROLOG */
+#endif /* __GNUC__ < 8 */
 
 #endif /* defined(__x86_64__) || defined(_AMD64_) || defined(__i386__) || 
defined(_X86_) */

If someone has a better 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-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

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 backport this patch to v5.x branch?
>>
>> Mateusz
>>
> 
> It is already in.

From my end I can apply this patch to v5.x branch (I just checked):

ma@ma-VirtualBox:~$ git clone https://git.code.sf.net/p/mingw-w64/mingw-w64 
mingw-w64-v6
Cloning into 'mingw-w64-v6'...
remote: Counting objects: 55481, done.
remote: Compressing objects: 100% (16557/16557), done.
remote: Total 55481 (delta 41287), reused 52211 (delta 38558)
Receiving objects: 100% (55481/55481), 30.47 MiB | 622.00 KiB/s, done.
Resolving deltas: 100% (41287/41287), done.
ma@ma-VirtualBox:~$ git clone -b v5.x 
https://git.code.sf.net/p/mingw-w64/mingw-w64 mingw-w64-v5
Cloning into 'mingw-w64-v5'...
remote: Counting objects: 55481, done.
remote: Compressing objects: 100% (16557/16557), done.
remote: Total 55481 (delta 41285), reused 52212 (delta 38558)
Receiving objects: 100% (55481/55481), 30.55 MiB | 543.00 KiB/s, done.
Resolving deltas: 100% (41285/41285), done.
ma@ma-VirtualBox:~$ cd mingw-w64-v6
ma@ma-VirtualBox:~/mingw-w64-v6$ git format-patch -1 3ce3e2
0001-intrin-impl.h-do-not-define-_xgetbv-for-GCC-8.patch
ma@ma-VirtualBox:~/mingw-w64-v6$ cd ../mingw-w64-v5
ma@ma-VirtualBox:~/mingw-w64-v5$ patch -p1 <../mingw-w64-v6/0001*.patch
patching file mingw-w64-headers/include/psdk_inc/intrin-impl.h
Hunk #1 succeeded at 1405 (offset -370 lines).
Hunk #2 succeeded at 1427 with fuzz 1 (offset -372 lines).


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-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

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
>>>> https://sourceforge.net/p/mingw-w64/mingw-w64/ci/3ce3e27f044935f19e93e80c43ca695262d484e1/
>>>>
>>>> JonY could you backport this patch to v5.x branch?
>>>>
>>>> Mateusz
>>>>
>>>
>>> It is already in.
>>
>> From my end I can apply this patch to v5.x branch (I just checked):
>>
> 
> Checked, I thought I saw it, must have been on the wrong branch.
> Just pushed to the v5.x branch.

Thanks!


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

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 Solskogen wrote:
>> It fails with this:
>>
>> make[1]: Entering directory
>> '/tmp/obj/_build/mingw-w64.crt.cross.x86_64-w64-mingw32'
>> x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I.
>> -I/home/solskogen/mingw-w64-builder/trunk/lib/mingw-w64/mingw-w64-crt
>> -m64
>> -I/home/solskogen/mingw-w64-builder/trunk/lib/mingw-w64/mingw-w64-crt/include
>> -D_CRTBLD
>> -I/home/solskogen/obj/cross-mingw-w64/x86_64-w64-mingw32/include  -pipe
>> -std=gnu99 -D_WIN32_WINNT=0x0f00 -Wall -Wextra -Wformat
>> -Wstrict-aliasing -Wshadow -Wpacked -Winline
>> -Wimplicit-function-declaration -Wmissing-noreturn -Wmissing-prototypes
>> -g -O2 -MT intrincs/lib64_libkernel32_a-rdtsc.o -MD -MP -MF
>> intrincs/.deps/lib64_libkernel32_a-rdtsc.Tpo -c -o
>> intrincs/lib64_libkernel32_a-rdtsc.o `test -f 'intrincs/rdtsc.c' || echo
>> '/home/solskogen/mingw-w64-builder/trunk/lib/mingw-w64/mingw-w64-crt/'`intrincs/rdtsc.c
>>
>> In file included from
>> /tmp/obj/cross-mingw-w64/lib/gcc/x86_64-w64-mingw32/8.1.1/include/x86intrin.h:74,
>>
>>  from
>> /tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/intrin.h:73,
>>  from
>> /home/solskogen/mingw-w64-builder/trunk/lib/mingw-w64/mingw-w64-crt/intrincs/rdtsc.c:10:
>>
>> /tmp/obj/cross-mingw-w64/lib/gcc/x86_64-w64-mingw32/8.1.1/include/xsaveintrin.h:60:1:
>> error: conflicting types for '_xgetbv'
>>  _xgetbv (unsigned int __A)
>>  ^~~
>> In file included from
>> /tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/intrin.h:41,
>>  from
>> /home/solskogen/mingw-w64-builder/trunk/lib/mingw-w64/mingw-w64-crt/intrincs/rdtsc.c:10:
>>
>> /tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/psdk_inc/intrin-impl.h:1412:18:
>> note: previous definition of '_xgetbv' was here
>>  unsigned __int64 _xgetbv(unsigned int index)
>>   ^~~
>> Makefile:28152: recipe for target 'intrincs/lib64_libkernel32_a-rdtsc.o'
>> failed
>> make[1]: *** [intrincs/lib64_libkernel32_a-rdtsc.o] Error 1
>> make[1]: Leaving directory
>> '/tmp/obj/_build/mingw-w64.crt.cross.x86_64-w64-mingw32'
>> Makefile:7778: recipe for target 'all' failed
>> make: *** [all] Error 2
> 
> Can you retry with the v5.x branch on git? There are gcc 8 fixes in
> included after the last v5 release.
> 
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

Hello,

The patch "intrin-impl.h: Use volatile argument for __buildbittesti-based 
functions."
is not working well for me (I can't compile GCC with this patch).

The problem is with one extra 'volatile':

@@ -615,28 +614,28 @@ __buildstos(__stosq, unsigned __int64, "q|q")
 #endif /* __INTRINSIC_PROLOG */
 
 #if __INTRINSIC_PROLOG(_interlockedbittestandset64)
-__MINGW_EXTENSION unsigned char _interlockedbittestandset64(__int64 *a, 
__int64 b);
+__MINGW_EXTENSION unsigned char _interlockedbittestandset64(__int64 volatile 
*a, __int64 b);
 #if !__has_builtin(_interlockedbittestandset64)
 __INTRINSICS_USEINLINE
-__buildbittesti(_interlockedbittestandset64, __int64, "lock bts{q 
%[Offset],%[Base] | %[Base],%[Offset]}" __FLAGSET, "J", __int64)
+__buildbittesti(_interlockedbittestandset64, __int64 volatile, "lock bts{q 
%[Offset],%[Base] | %[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


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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] intrin-impl.h: do not define _xgetbv for GCC 8

[Mateusz]

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 patch looks good to me.
> 
> Thanks,
> Jacek

Thanks for review.

Could somebody with write access commit this patch?

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-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

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.
>>>
>>> Pushed this version.
>>>
>>> // Martin
>>
>> It's not working for me (when I build gcc on ubuntu).
>> Could we revert this patch?
> 
> Maybe, but first I'd like to know more about what doesn't work for you. What 
> step fails for you?
> 
> What does configure say about "Checking whether the linker provides 
> __CTOR_LIST__"? Do you use specifically binutils 2.30? Can you provide the 
> config.log from that run?
> 
> // Martin

binutils 2.31.1, config.log + config.h attached (from building gcc cross 
compiler on ubuntu)

Mateusz
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by mingw-w64-runtime configure 4.0b, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  $ /home/ma/m/source/mingw-w64-v6/mingw-w64-crt/configure 
--host=x86_64-w64-mingw32 --prefix=/home/ma/m/cross/x86_64-w64-mingw32 
--enable-lib64 --disable-lib32

## - ##
## Platform. ##
## - ##

hostname = ma-VirtualBox
uname -m = x86_64
uname -r = 4.15.0-33-generic
uname -s = Linux
uname -v = #36~16.04.1-Ubuntu SMP Wed Aug 15 17:21:05 UTC 2018

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = unknown
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /home/ma/m/cross/bin
PATH: /home/ma/bin
PATH: /home/ma/.local/bin
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /sbin
PATH: /bin
PATH: /usr/games
PATH: /usr/local/games
PATH: /snap/bin


## --- ##
## Core tests. ##
## --- ##

configure:2289: checking for a BSD-compatible install
configure:2357: result: /usr/bin/install -c
configure:2368: checking whether build environment is sane
configure:2423: result: yes
configure:2482: checking for x86_64-w64-mingw32-strip
configure:2498: found /home/ma/m/cross/bin/x86_64-w64-mingw32-strip
configure:2509: result: x86_64-w64-mingw32-strip
configure:2574: checking for a thread-safe mkdir -p
configure:2613: result: /bin/mkdir -p
configure:2620: checking for gawk
configure:2650: result: no
configure:2620: checking for mawk
configure:2636: found /usr/bin/mawk
configure:2647: result: mawk
configure:2658: checking whether make sets $(MAKE)
configure:2680: result: yes
configure:2709: checking whether make supports nested variables
configure:2726: result: yes
configure:2853: checking whether to enable maintainer-specific portions of 
Makefiles
configure:2862: result: no
configure:2880: checking build system type
configure:2894: result: x86_64-unknown-linux-gnu
configure:2914: checking host system type
configure:2927: result: x86_64-w64-mingw32
configure:2948: checking for sysroot
configure:2966: result: /home/ma/m/cross/x86_64-w64-mingw32
configure:2987: checking for a sed that does not truncate output
configure:3051: result: /bin/sed
configure:3060: checking for gawk
configure:3087: result: mawk
configure:3106: checking for x86_64-w64-mingw32-gcc
configure:3122: found /home/ma/m/cross/bin/x86_64-w64-mingw32-gcc
configure:3133: result: x86_64-w64-mingw32-gcc
configure:3402: checking for C compiler version
configure:3411: x86_64-w64-mingw32-gcc --version >&5
x86_64-w64-mingw32-gcc (GCC) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:3422: $? = 0
configure:3411: x86_64-w64-mingw32-gcc -v >&5
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/home/ma/m/cross/libexec/gcc/x86_64-w64-mingw32/8.2.0/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: /home/ma/m/source/gcc-8.2/configure 
--target=x86_64-w64-mingw32 --disable-nls --disable-multilib 
--with-gmp=/home/ma/m/build/for_cross --with-mpfr=/home/ma/m/build/for_cross 
--with-mpc=/home/ma/m/build/for_cross --with-isl=/home/ma/m/build/for_cross 
--enable-languages=c,c++,objc,obj-c++ --disable-libstdcxx-pch --disable-shared 
--enable-fully-dynamic-string --with-tune=core-avx2 --prefix=/home/ma/m/cross 
--with-sysroot=/home/ma/m/cross
Thread model: win32
gcc version 8.2.0 (GCC) 
configure:3422: $? = 0
configure:3411: x86_64-w64-mingw32-gcc -V >&5
x86_64-w64-mingw32-gcc: error: unrecognized command line option '-V'
x86_64-w64-mingw32-gcc: fatal error: no input files
compilation terminated.
configure:3422: $? = 1
configure:3411: x86_64-w64-mingw32-gcc -qversion >&5
x86_64-w

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

[Mateusz]

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 we revert this patch?

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-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[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 <mateu...@poczta.onet.pl>
Date: Mon, 22 Jan 2018 20:58:48 +0100
Subject: [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.

Signed-off-by: Mateusz Brzostek <mateu...@poczta.onet.pl>
---
 mingw-w64-headers/include/psdk_inc/intrin-impl.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mingw-w64-headers/include/psdk_inc/intrin-impl.h 
b/mingw-w64-headers/include/psdk_inc/intrin-impl.h
index ff9e6aff..88af804c 100644
--- a/mingw-w64-headers/include/psdk_inc/intrin-impl.h
+++ b/mingw-w64-headers/include/psdk_inc/intrin-impl.h
@@ -1775,6 +1775,7 @@ __buildmov(__movsd, unsigned __LONG32, "d")
 #define __INTRINSIC_DEFINED___movsd
 #endif /* __INTRINSIC_PROLOG */
 
+#if !defined(__GNUC__) || __GNUC__ < 8 /* GCC 8 has already defined _xgetbv */
 /* NOTE: This should be in immintrin.h */
 #if __INTRINSIC_PROLOG(_xgetbv)
 unsigned __int64 _xgetbv(unsigned int);
@@ -1798,6 +1799,7 @@ unsigned __int64 _xgetbv(unsigned int index)
 #endif
 #define __INTRINSIC_DEFINED__xgetbv
 #endif /* __INTRINSIC_PROLOG */
+#endif /* __GNUC__ < 8 */
 
 #endif /* defined(__x86_64__) || defined(_AMD64_) || defined(__i386__) || 
defined(_X86_) */
 
-- 
2.14.1

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

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 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] is
>>> valid according to Microsoft. MinGW mentions "MS runtime does not yet
>>> understand C9x standard "ll"" but at some point they started
>>> supporting ll[foo].  And as I mentioned, that's what clang[-cl] uses.
>>>
>>> Mozilla has our own implementation of printf that does the format
>>> specifier parsing. We don't support I64[foo]. So using it caused data
>>> corruption and general bad behavior. Switching to ll[foo] fixed it.
>>>
>>> I have a patch here:
>>> https://hg.mozilla.org/try/raw-file/eaae7782a1dd/build/build-clang/mingw-int.patch
>>
>> You can try to define
>> __USE_MINGW_ANSI_STDIO
>> instead of patching mingw-w64
> 
> i've mesure a significant performance loss when using printf
> functions with __USE_MINGW_ANSI_STDIO cmopared to the ones in
> msvcrt.dll
> 
> is it normal ?
> 
> Vincent Torri

Yes, it is normal.

We could try to speed up mingw_printf -- if you have some examples when the 
speed loss is significat please share (it was recently speed up for some cases 
in mingw_wprintf family -- wide char version).

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] inttypes Format Specifiers

[Mateusz]

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 see what makes __USE_MINGW_ANSI_STDIO a correct solution.
>>> Firefox builds use ucrt, which is sufficient for handling stdio (and
>>> official winapi+clang-cl builds use that anyway).
>>>
>> Oh I didn't know that had migrated to UCRT.
>>
>>> I took a look at this and I think we want a more radical solution. Right
>>> now we have _mingw_print_push.h/_mingw_print_pop.h hack that has no
>>> clean purpose to me. I did some git history checking and when it was
>>> introduced, it was important for __USE_MINGW_ANSI_STDIO because that was
>>> where printf/scanf functions were #defined. It was later removed and the
>>> only thing that's left there is a bunch of PRI* macros. Instead of
>>> defining and redefining them, we may just as well define them correctly
>>> in the first place.
>>>
>>> That's what the attached patch does. It also uses the same for ucrt and
>>> mingw stdio, leaving hackish values only for affected builds. This fixes
>>> Firefox issue and makes mingw stdio cleaner. It's not yet tested, I'm
>>> mostly sending it for comments now.
>>>
>> Yes those macros `scanf()` and `printf()` etc. were removed in
>> d4e56ae45d4f92598f7b393340efca93f3deff38 and now those functions are
>> implemented by conditional inline definitions. If no other inline
>> functions [1] in our headers rely on the old format specifiers, the
>> header <_mingw_print_push.h> is consequenctly unneeded thereafter.
>>
>> The circumstances of <_mingw_print_pop.h> are a bit more complex. It has
>> to restore `PRId64` etc. to the correct strings that correspond to what
>> `printf()` etc., after the inclusion of , will eventually
>> call. Thus at the moment <_mingw_print_pop.h> actually checks for
>> inclusion of  or  (there was an old thread about this
>> [2]), otherwise the following code may not produce the expected result:
>>
>> ```c
>> #define __USE_MINGW_ANSI_STDIO  1
>> #include 
>> #include 
>>
>> // `PRIx64` is defined as `I64x` here, which will co-operate with
>> // `printf()` from MSVCRT rather than the inline one in .
> 
> In my proposed patch, it will be properly defined to llx in inttypes.h (note 
> that the patch makes inttypes.h aware of __USE_MINGW_ANSI_STDIO). By defining 
> 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 simpler to leave *_pop.h and *_push.h like it is/was and change 
only condition from
#if defined(__USE_MINGW_ANSI_STDIO)
to
#if defined(__USE_MINGW_ANSI_STDIO) || __MSVCRT_VERSION__ >= 0x1400
for llx inttypes.

I've attached patch proposition (and I removed the case when 
__USE_MINGW_ANSI_STDIO defined as 0 is like not defined -- it's too 
complicated).

Regards,
Mateusz
From 956ce6c208de2bf8bc67772839543449e0f08f5e Mon Sep 17 00:00:00 2001
From: Mateusz 
Date: Sun, 28 Oct 2018 19:48:06 +0100
Subject: [PATCH] use ANSI inttypes for ucrt builds

Signed-off-by: Mateusz 
---
 mingw-w64-headers/crt/_mingw_print_pop.h  | 4 ++--
 mingw-w64-headers/crt/_mingw_print_push.h | 4 ++--
 mingw-w64-headers/crt/stdio.h | 8 
 mingw-w64-headers/crt/stdlib.h| 2 +-
 mingw-w64-headers/crt/wchar.h | 6 +++---
 5 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/mingw-w64-headers/crt/_mingw_print_pop.h 
b/mingw-w64-headers/crt/_mingw_print_pop.h
index 046b6203..e711cd28 100644
--- a/mingw-w64-headers/crt/_mingw_print_pop.h
+++ b/mingw-w64-headers/crt/_mingw_print_pop.h
@@ -5,7 +5,7 @@
  */
 
 /* Define __mingw_ macros.  */
-#if defined(__USE_MINGW_ANSI_STDIO) && (defined(_INC_STDIO) || 
defined(_WSTDIO_DEFINED)) && ((__USE_MINGW_ANSI_STDIO + 0) != 0)
+#if (defined(__USE_MINGW_ANSI_STDIO) && (defined(_INC_STDIO) || 
defined(_WSTDIO_DEFINED))) || __MSVCRT_VERSION__ >= 0x1400
 
 /* Redefine to GNU specific PRI... and SCN... macros.  */
 #if defined(_INTTYPES_H_) && defined(PRId64)
@@ -133,4 +133,4 @@
 #endif /* _WIN64 */
 #endif /* defined(_INTTYPES_H_) && defined(PRId64) */
 
-#endif /* defined(__USE_MINGW_ANSI_STDIO) && defined(_INC_STDIO) && 
__USE_MINGW_ANSI_STDIO != 0 */
+#endif /* (defined(__USE_MINGW_ANSI_STDIO) && defined(_INC_STDIO)) || 
__MSVCRT_VERSION__ >= 0x1400 */
diff --git a/mingw-w64-headers/crt/_mingw_print_push.h 
b/mingw-w64-headers/crt/_mingw_print_push.h
index e0da9d00..7431c0

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

[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) && ((__USE_MINGW_ANSI_STDIO + 0) != 0)
#elif defined(__USE_MINGW_ANSI_STDIO)
#if !defined (__USE_MINGW_ANSI_STDIO) || __USE_MINGW_ANSI_STDIO == 0

Attached patch simplified checking if __USE_MINGW_ANSI_STDIO is active -- it
always define __USE_MINGW_ANSI_STDIO to 0 or 1 in _mingw.h so now it should be
simple:
#if __USE_MINGW_ANSI_STDIO /* active */
#if __USE_MINGW_ANSI_STDIO == 0 /* not active */

Please review.

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 corner cases for __USE_MINGW_ANSI_STDIO
in one place in _mingw.h and then we have easy and consistent check
-- it is 0 or 1.

Signed-off-by: Mateusz Brzostek 
---
 mingw-w64-headers/crt/_mingw.h.in | 9 +
 mingw-w64-headers/crt/_mingw_print_pop.h  | 4 ++--
 mingw-w64-headers/crt/_mingw_print_push.h | 4 ++--
 mingw-w64-headers/crt/stdio.h | 8 
 mingw-w64-headers/crt/stdlib.h| 2 +-
 mingw-w64-headers/crt/wchar.h | 6 +++---
 6 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/mingw-w64-headers/crt/_mingw.h.in 
b/mingw-w64-headers/crt/_mingw.h.in
index bbbd07d0..c6b9d760 100644
--- a/mingw-w64-headers/crt/_mingw.h.in
+++ b/mingw-w64-headers/crt/_mingw.h.in
@@ -428,6 +428,15 @@ typedef int __int128 __attribute__ ((__mode__ (TI)));
 #  define __USE_MINGW_ANSI_STDIO   1
 #endif
 
+/* We are defining __USE_MINGW_ANSI_STDIO as 0 or 1 */
+#if !defined(__USE_MINGW_ANSI_STDIO)
+#define __USE_MINGW_ANSI_STDIO 0  /* was not defined so it should be 0 */
+#elif (__USE_MINGW_ANSI_STDIO + 0) != 0 || (1 - __USE_MINGW_ANSI_STDIO - 1) == 
2
+#define __USE_MINGW_ANSI_STDIO 1  /* was defined as nonzero or empty so it 
should be 1 */
+#else
+#define __USE_MINGW_ANSI_STDIO 0  /* was defined as (int)zero and 
non-empty so it should be 0 */
+#endif
+
 /* _dowildcard is an int that controls the globbing of the command line.
  * The MinGW32 (mingw.org) runtime calls it _CRT_glob, so we are adding
  * a compatibility definition here:  you can use either of _CRT_glob or
diff --git a/mingw-w64-headers/crt/_mingw_print_pop.h 
b/mingw-w64-headers/crt/_mingw_print_pop.h
index 046b6203..491749ea 100644
--- a/mingw-w64-headers/crt/_mingw_print_pop.h
+++ b/mingw-w64-headers/crt/_mingw_print_pop.h
@@ -5,7 +5,7 @@
  */
 
 /* Define __mingw_ macros.  */
-#if defined(__USE_MINGW_ANSI_STDIO) && (defined(_INC_STDIO) || 
defined(_WSTDIO_DEFINED)) && ((__USE_MINGW_ANSI_STDIO + 0) != 0)
+#if __USE_MINGW_ANSI_STDIO && (defined(_INC_STDIO) || defined(_WSTDIO_DEFINED))
 
 /* Redefine to GNU specific PRI... and SCN... macros.  */
 #if defined(_INTTYPES_H_) && defined(PRId64)
@@ -133,4 +133,4 @@
 #endif /* _WIN64 */
 #endif /* defined(_INTTYPES_H_) && defined(PRId64) */
 
-#endif /* defined(__USE_MINGW_ANSI_STDIO) && defined(_INC_STDIO) && 
__USE_MINGW_ANSI_STDIO != 0 */
+#endif /* __USE_MINGW_ANSI_STDIO && defined(_INC_STDIO) */
diff --git a/mingw-w64-headers/crt/_mingw_print_push.h 
b/mingw-w64-headers/crt/_mingw_print_push.h
index e0da9d00..eca11bf9 100644
--- a/mingw-w64-headers/crt/_mingw_print_push.h
+++ b/mingw-w64-headers/crt/_mingw_print_push.h
@@ -5,7 +5,7 @@
  */
 
 /* Undefine __mingw_ macros.  */
-#if defined(__USE_MINGW_ANSI_STDIO) && ((__USE_MINGW_ANSI_STDIO + 0) != 0)
+#if __USE_MINGW_ANSI_STDIO
 
 /* Redefine to MS specific PRI... and SCN... macros.  */
 #if defined(_INTTYPES_H_) && defined(PRId64)
@@ -133,4 +133,4 @@
 
 #endif /* defined(_INTTYPES_H_) && defined(PRId64) */
 
-#endif /* defined(__USE_MINGW_ANSI_STDIO) && __USE_MINGW_ANSI_STDIO != 0 */
+#endif /* __USE_MINGW_ANSI_STDIO */
diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h
index d981f701..a7f0ae8c 100644
--- a/mingw-w64-headers/crt/stdio.h
+++ b/mingw-w64-headers/crt/stdio.h
@@ -223,7 +223,7 @@ extern
 #if defined(__clang__)
 #define __MINGW_PRINTF_FORMAT printf
 #define __MINGW_SCANF_FORMAT  scanf
-#elif defined(__USE_MINGW_ANSI_STDIO)
+#elif __USE_MINGW_ANSI_STDIO
 #define __MINGW_PRINTF_FORMAT gnu_printf
 #define __MINGW_SCANF_FORMAT  gnu_scanf
 #else
@@ -737,7 +737,7 @@ int vsnprintf (char *__stream, size_t __n, const char 
*__format, __builtin_va_li
   _CRTIMP int __cdecl _vsnprintf(char * __restrict__ _Dest,size_t _Count,const 
char * __restrict__ _Format,va_list _Args) __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
 #endif
 
-#if !defined (__USE_MINGW_ANSI_STDIO) || __USE_MINGW_ANSI_STDIO == 0
+#if __USE_MINGW_ANSI_STDIO == 0
 
 #if __MSVCRT_VERSION__ >= 0x1400
 #ifdef __GNU

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

[Mateusz]

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 see what makes __USE_MINGW_ANSI_STDIO a correct solution.
>>>>> Firefox builds use ucrt, which is sufficient for handling stdio (and
>>>>> official winapi+clang-cl builds use that anyway).
>>>>>
>>>> Oh I didn't know that had migrated to UCRT.
>>>>
>>>>> I took a look at this and I think we want a more radical solution. Right
>>>>> now we have _mingw_print_push.h/_mingw_print_pop.h hack that has no
>>>>> clean purpose to me. I did some git history checking and when it was
>>>>> introduced, it was important for __USE_MINGW_ANSI_STDIO because that was
>>>>> where printf/scanf functions were #defined. It was later removed and the
>>>>> only thing that's left there is a bunch of PRI* macros. Instead of
>>>>> defining and redefining them, we may just as well define them correctly
>>>>> in the first place.
>>>>>
>>>>> That's what the attached patch does. It also uses the same for ucrt and
>>>>> mingw stdio, leaving hackish values only for affected builds. This fixes
>>>>> Firefox issue and makes mingw stdio cleaner. It's not yet tested, I'm
>>>>> mostly sending it for comments now.
>>>>>
>>>> Yes those macros `scanf()` and `printf()` etc. were removed in
>>>> d4e56ae45d4f92598f7b393340efca93f3deff38 and now those functions are
>>>> implemented by conditional inline definitions. If no other inline
>>>> functions [1] in our headers rely on the old format specifiers, the
>>>> header <_mingw_print_push.h> is consequenctly unneeded thereafter.
>>>>
>>>> The circumstances of <_mingw_print_pop.h> are a bit more complex. It has
>>>> to restore `PRId64` etc. to the correct strings that correspond to what
>>>> `printf()` etc., after the inclusion of , will eventually
>>>> call. Thus at the moment <_mingw_print_pop.h> actually checks for
>>>> inclusion of  or  (there was an old thread about this
>>>> [2]), otherwise the following code may not produce the expected result:
>>>>
>>>> ```c
>>>> #define __USE_MINGW_ANSI_STDIO  1
>>>> #include 
>>>> #include 
>>>>
>>>> // `PRIx64` is defined as `I64x` here, which will co-operate with
>>>> // `printf()` from MSVCRT rather than the inline one in .
>>> In my proposed patch, it will be properly defined to llx in inttypes.h 
>>> (note that the patch makes inttypes.h aware of __USE_MINGW_ANSI_STDIO). By 
>>> defining 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).
> 
> Yes, but what's wrong with that? Doesn't that make more sense? What's
> the sense of depending on strio.h presence? I think that not depending
> on it will give more consistent results. And I suspect that current
> behaviour is a side effect of a hack and not really intended feature and
> as such I don't see a reason to preserve it.

Liu Hao example is the explanation.
printf("value = %" PRIx64 "\n", value);
should print 64-bit int 'value' regardless stdio.h is included or not.


>> Maybe it is simpler to leave *_pop.h and *_push.h like it is/was and change 
>> only condition from
>> #if defined(__USE_MINGW_ANSI_STDIO)
>> to
>> #if defined(__USE_MINGW_ANSI_STDIO) || __MSVCRT_VERSION__ >= 0x1400
>> for llx inttypes.
>>
>> I've attached patch proposition (and I removed the case when 
>> __USE_MINGW_ANSI_STDIO defined as 0 is like not defined -- it's too 
>> complicated).
> 
> Why do you want to remove support for __USE_MINGW_ANSI_STDIO? I think
> it's good to have a way for users to explicitly specify that they don't
> want mingw stdio.
> 
> Jacek

Now I see it, thanks!

I was wrongly thinking that if __USE_MINGW_ANSI_STDIO is not defined it is 
ms_printf, if it is defined it is mingw_printf.

Now I see that if __USE_MINGW_ANSI_STDIO is not defined it is fuzzy logic 
(_GNU_SOURCE and so on), if it is defined as 0 it should be ms_printf, if it is 
defined != 0 it should be mingw_printf. I will prepare new 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] inttypes Format Specifiers

[Mateusz]

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.
>>
>>
> 
> Hmmm on my Windows 7 Professional [Version 6.1.7601 x64], the `printf()`
> function from MSVCRT actually recognizes `%llx` and `%lld`.
> 
> Is maintaining `%I64d` really necessary?

On my Win10, 7 and Vista also %lld works. Strange... Maybe somebody with WinXP 
will try?

But if in t.c first line is #include  we have
$ gcc -D__USE_MINGW_ANSI_STDIO= t.c -o t.exe
In file included from t.c:1:0:
f:\msys\m32-494\i686-w64-mingw32\include\stdio.h:234:27: error: #if with no 
expression
 #if __USE_MINGW_ANSI_STDIO
   ^
f:\msys\m32-494\i686-w64-mingw32\include\stdio.h:740:65: error: operator '||' 
has no right operand
 #if !defined (__USE_MINGW_ANSI_STDIO) || __USE_MINGW_ANSI_STDIO == 0
 ^
f:\msys\m32-494\i686-w64-mingw32\include\stdio.h:857:27: error: #if with no 
expression
 #if __USE_MINGW_ANSI_STDIO
   ^
f:\msys\m32-494\i686-w64-mingw32\include\stdio.h:1195:65: error: operator '||' 
has no right operand
 #if !defined (__USE_MINGW_ANSI_STDIO) || __USE_MINGW_ANSI_STDIO == 0
 ^



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

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] is
> valid according to Microsoft. MinGW mentions "MS runtime does not yet
> understand C9x standard "ll"" but at some point they started
> supporting ll[foo].  And as I mentioned, that's what clang[-cl] uses.
> 
> Mozilla has our own implementation of printf that does the format
> specifier parsing. We don't support I64[foo]. So using it caused data
> corruption and general bad behavior. Switching to ll[foo] fixed it.
> 
> I have a patch here:
> https://hg.mozilla.org/try/raw-file/eaae7782a1dd/build/build-clang/mingw-int.patch

You can try to define
__USE_MINGW_ANSI_STDIO
instead of patching mingw-w64



___
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

[Mateusz]

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.
>>
>> Regards,
>> Mateusz
>>
> 
> Mateusz do you have write to our Git repo? I will push this patch for
> you if it's not the case.

I don't have write access, so please push.

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] inttypes.h: Take into account __USE_MINGW_ANSI_STDIO and msvcrt version instead of depending on _mingw_print_p*.h headers.

[Mateusz]

W dniu 31.10.2018 o 20:12, Jacek Caban pisze:
> We had a discussion about it and I'd like to get it back to the patch. I
> tested it some more and I think it's ready. Please review the patch.
> 
> There was a concern that applications might define
> __USE_MINGW_ANSI_STDIO but instead of including stdio.h obtaining a
> declaration in another way, ending up calling msvcrt.dll with invalid
> arguments. While such case is questionable by itself, it matters only on
> XP in practice.
> 
> This patch cleans up the code and makes PRI*64 definitions more
> consistent. It also uses C99 values for ucrt builds.
> 
> ---
>  mingw-w64-headers/configure.ac|   2 +-
>  mingw-w64-headers/crt/_mingw_print_pop.h  | 136 --
>  mingw-w64-headers/crt/_mingw_print_push.h | 136 --
>  mingw-w64-headers/crt/inttypes.h  | 129 ++--
>  mingw-w64-headers/crt/stdio.h |   4 -
>  mingw-w64-headers/crt/wchar.h |   3 -
>  mingw-w64-headers/include/wspiapi.h   |   4 -
>  7 files changed, 65 insertions(+), 349 deletions(-)
>  delete mode 100644 mingw-w64-headers/crt/_mingw_print_pop.h
>  delete mode 100644 mingw-w64-headers/crt/_mingw_print_push.h

I have some problems with this patch. It doesn't apply cleanly on my system:
ma@ma-VirtualBox:~/m/source/mingw-w64-v7$ patch -p1 <../01.diff
(Stripping trailing CRs from patch; use --binary to disable.)
patching file mingw-w64-headers/configure.ac
(Stripping trailing CRs from patch; use --binary to disable.)
patching file mingw-w64-headers/crt/_mingw_print_pop.h
...

I can't compile cross compiler with this patch:
+ /home/ma/m/source/mingw-w64-v7/mingw-w64-headers/configure 
--host=x86_64-w64-mingw32 --prefix=/home/ma/m/cross/x86_64-w64-mingw32
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for x86_64-w64-mingw32-strip... no
checking for strip... strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-w64-mingw32
checking for a sed that does not truncate output... /bin/sed
checking whether to rebuild headers with widl... no
checking whether to build a w32api package for Cygwin... no
checking for c-runtime headers... yes
checking for optional sdk headers... ddk,directx
checking if installing idl files is enabled... no
checking whether to enable the secure API... no
checking default _WIN32_WINNT version... 0x502
checking default msvcrt... msvcrt (0x700)
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating crt/_mingw.h
config.status: creating config.h
+ make
make  all-am
make[1]: Entering directory '/home/ma/m/build/bc_m64_head'
make[1]: *** No rule to make target 'crt/_mingw_print_push.h', needed by 
'all-am'.  Stop.
make[1]: Leaving 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

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

[Mateusz]

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) && ((__USE_MINGW_ANSI_STDIO + 0) != 0)
>> #elif defined(__USE_MINGW_ANSI_STDIO)
>> #if !defined (__USE_MINGW_ANSI_STDIO) || __USE_MINGW_ANSI_STDIO == 0
>>
>> Attached patch simplified checking if __USE_MINGW_ANSI_STDIO is active -- it
>> always define __USE_MINGW_ANSI_STDIO to 0 or 1 in _mingw.h so now it should 
>> be
>> simple:
>> #if __USE_MINGW_ANSI_STDIO /* active */
>> #if __USE_MINGW_ANSI_STDIO == 0 /* not active */
>>
>> Please review.
>>
>> Regards,
>> Mateusz
>>
> 
> 
> Patch looks good to me.

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.

Regards,
Mateusz
From 7fc7776a0b8ee9489f226eca2bdaad15d22032f3 Mon Sep 17 00:00:00 2001
From: Mateusz 
Date: Fri, 2 Nov 2018 21:01:43 +0100
Subject: [PATCH 1/2] 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 corner cases for __USE_MINGW_ANSI_STDIO
in one place in _mingw.h and then we have easy and consistent check
-- it is 0 or 1.

Signed-off-by: Mateusz Brzostek 
---
 mingw-w64-headers/crt/_mingw.h.in | 9 +
 mingw-w64-headers/crt/inttypes.h  | 2 +-
 mingw-w64-headers/crt/stdio.h | 8 
 mingw-w64-headers/crt/stdlib.h| 2 +-
 mingw-w64-headers/crt/wchar.h | 6 +++---
 5 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/mingw-w64-headers/crt/_mingw.h.in 
b/mingw-w64-headers/crt/_mingw.h.in
index bbbd07d0..c6b9d760 100644
--- a/mingw-w64-headers/crt/_mingw.h.in
+++ b/mingw-w64-headers/crt/_mingw.h.in
@@ -428,6 +428,15 @@ typedef int __int128 __attribute__ ((__mode__ (TI)));
 #  define __USE_MINGW_ANSI_STDIO   1
 #endif
 
+/* We are defining __USE_MINGW_ANSI_STDIO as 0 or 1 */
+#if !defined(__USE_MINGW_ANSI_STDIO)
+#define __USE_MINGW_ANSI_STDIO 0  /* was not defined so it should be 0 */
+#elif (__USE_MINGW_ANSI_STDIO + 0) != 0 || (1 - __USE_MINGW_ANSI_STDIO - 1) == 
2
+#define __USE_MINGW_ANSI_STDIO 1  /* was defined as nonzero or empty so it 
should be 1 */
+#else
+#define __USE_MINGW_ANSI_STDIO 0  /* was defined as (int)zero and 
non-empty so it should be 0 */
+#endif
+
 /* _dowildcard is an int that controls the globbing of the command line.
  * The MinGW32 (mingw.org) runtime calls it _CRT_glob, so we are adding
  * a compatibility definition here:  you can use either of _CRT_glob or
diff --git a/mingw-w64-headers/crt/inttypes.h b/mingw-w64-headers/crt/inttypes.h
index 500df7de..23dcd42c 100644
--- a/mingw-w64-headers/crt/inttypes.h
+++ b/mingw-w64-headers/crt/inttypes.h
@@ -29,7 +29,7 @@ typedef struct {
  * The non-standard I64 length specifier causes warning in GCC,
  * but understood by MS runtime functions.
  */
-#if __MSVCRT_VERSION__ >= 0x1400 || (defined(__USE_MINGW_ANSI_STDIO) && 
((__USE_MINGW_ANSI_STDIO + 0) != 0))
+#if __MSVCRT_VERSION__ >= 0x1400 || __USE_MINGW_ANSI_STDIO
 #define PRId64 "lld"
 #define PRIi64 "lli"
 #define PRIo64 "llo"
diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h
index d0659238..e412b2d9 100644
--- a/mingw-w64-headers/crt/stdio.h
+++ b/mingw-w64-headers/crt/stdio.h
@@ -221,7 +221,7 @@ extern
 #if defined(__clang__)
 #define __MINGW_PRINTF_FORMAT printf
 #define __MINGW_SCANF_FORMAT  scanf
-#elif defined(__USE_MINGW_ANSI_STDIO)
+#elif __USE_MINGW_ANSI_STDIO
 #define __MINGW_PRINTF_FORMAT gnu_printf
 #define __MINGW_SCANF_FORMAT  gnu_scanf
 #else
@@ -735,7 +735,7 @@ int vsnprintf (char *__stream, size_t __n, const char 
*__format, __builtin_va_li
   _CRTIMP int __cdecl _vsnprintf(char * __restrict__ _Dest,size_t _Count,const 
char * __restrict__ _Format,va_list _Args) __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
 #endif
 
-#if !defined (__USE_MINGW_ANSI_STDIO) || __USE_MINGW_ANSI_STDIO == 0
+#if __USE_MINGW_ANSI_STDIO == 0
 
 #if __MSVCRT_VERSION__ >= 0x1400
 #ifdef __GNUC__
@@ -1140,7 +1140,7 @@ int vsnwprintf (wchar_t *__stream, size_t __n, const 
wchar_t *__format, __builti
   }
   int __cdecl _vsnwprintf(wchar_t * __restrict__ _Dest,size_t _Count,const 
wchar_t * __restrict__ _Format,va_list _Args) 
__MINGW_ATTRIB_DEPRECATED_SEC_WARN;
 
-#if !defined (__USE_MINGW_ANSI_STDIO) || __USE_MINGW_ANSI_STDIO == 0
+#if __USE_MINGW_ANSI_STDIO == 0
   __mingw_ovr
   int snwprintf (wchar_t * __restrict__ s, size_t n, const wchar_t * 
__restrict__ format, ...)
   {
@@ -1190,7 +1190,7 @@ int vsnwprintf (wchar_t *__stream, size_t __n, const 
wchar_t *__format, __builti
 
 #ifndef __NO_ISOCEXT  /* ext

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

[Mateusz]

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 realized that we check (in header 
>>>> files) if
>>>> __USE_MINGW_ANSI_STDIO is active in non consistent way:
>>>> #if defined(__USE_MINGW_ANSI_STDIO) && ((__USE_MINGW_ANSI_STDIO + 0) != 0)
>>>> #elif defined(__USE_MINGW_ANSI_STDIO)
>>>> #if !defined (__USE_MINGW_ANSI_STDIO) || __USE_MINGW_ANSI_STDIO == 0
>>>>
>>>> Attached patch simplified checking if __USE_MINGW_ANSI_STDIO is active -- 
>>>> it
>>>> always define __USE_MINGW_ANSI_STDIO to 0 or 1 in _mingw.h so now it 
>>>> should be
>>>> simple:
>>>> #if __USE_MINGW_ANSI_STDIO /* active */
>>>> #if __USE_MINGW_ANSI_STDIO == 0 /* not active */
>>>>
>>>> Please review.
>>>>
>>>
>>> Are there any existent projects where `__USE_MINGW_ANSI_STDIO` is
>>> defined as something other than `0` or `1`, if it is defined at all,
>>> including empty?
>>
>> If by `empty' you mean `#define FOO` as being empty the value is
>> actually 1. If __USE_MINGW_ANSI_STDIO is set to some unexpected value
>> then _mingw.h could handle it and set to the standard value of 1 or give
>> a #error (maybe best).
> 
> If __USE_MINGW_ANSI_STDIO is defined but not numeric adding 0 results in
> a value of 0. The patch to _mingw.h needs to check defined and set the
> value to 1.
> 
> 
> #define FOO foo
> #if (FOO + 0) == 0
> #warning FOO is 0
> #endif
> 
> 
> $ gcc -c foo.c
> foo.c:3:2: warning: #warning FOO is 0 [-Wcpp]
>  #warning FOO is 0

Yes, if you compile
gcc -D__USE_MINGW_ANSI_STDIO=foo ...
it will be set to 0.

It is technically complicated to handle 'foo' case different than 0.
If you know the trick, please share.

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] timeb.h: declare _ftime32 function, define _ftime according to _USE_32BIT_TIME_T

[Mateusz]

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 should only be used if _USE_32BIT_TIME_T is set.

Yes, I agree -- in the future we should not define _USE_32BIT_TIME_T. I didn't 
change this because the patch is only for _ftime functions. If the patch 
survives in real life we could make next step and check/fix all time functions 
that depend on _USE_32BIT_TIME_T and not define _USE_32BIT_TIME_T.

> _USE_32BIT_TIME_T functions might not be in the MSVCRT.DLL residing on
> the OS which includes Windows 7.  This
> https://sourceforge.net/p/mingw/bugs/1973/ might be helpful.

It is quite long thread. In msvcrt.dll from WinXPsp2 we have only
_ftime
_ftime64
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 
aliased as _ftime for 32-bit libmsvcrt.a.

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] timeb.h: declare _ftime32 function, define _ftime according to _USE_32BIT_TIME_T

[Mateusz]

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 
>> aliased as _ftime for 32-bit libmsvcrt.a.
>>
> 
> But what about 32bit Win10?  Does this idea still work there?

Yes, it works.

_ftime functions in msvcrt.dll:
WinXPsp2: _ftime, _ftime64
Vista/7/10: _ftime, _ftime32, _ftime32_s, _ftime64, _ftime64_s

_ftime functions in msvcr100.dll and newer:
_ftime32, _ftime32_s, _ftime64, _ftime64_s

In 32-bit msvcrt.dll _ftime it is the same as _ftime32.
In 64-bit msvcrt.dll _ftime it is the same as _ftime64.

After this patch in 64-bit libs we use _ftime32, _ftime32_s, _ftime64, 
_ftime64_s as base functions.
In 32-bit libs we use for msvcrt.dll -- _ftime, _ftime32_s, _ftime64, 
_ftime64_s as base functions, for newer dll (like msvcr120.dll) -- _ftime32, 
_ftime32_s, _ftime64, _ftime64_s as base functions. The trick is not in *.h 
files but int 32-bit libmsvcrt.a where we emulate _ftime32 as _ftime function 
(it works from WinXP up to 10).
Exactly in file mingw-w64-crt/lib-common/msvcrt.def.in
+F_I386(_ftime32 == _ftime)
+F_NON_I386(_ftime32)

Regards,
Mateusz



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

I have problems with functions:
_ftime32, _ftime64, _ftime, _ftime32_s, _ftime64_s, _ftime_s

There is no declaration for *32 functions.

In 64-bit libmsvcrt.a there is no _ftime32 function.

In 32-bit mode _ftime and _ftime_s are always *32 regardless of 
_USE_32BIT_TIME_T (but in _mingw.h we always define _USE_32BIT_TIME_T for 
32-bit)
#if defined (_WIN32) && !defined (_WIN64) && !defined 
(__MINGW_USE_VC2005_COMPAT)
#ifndef _USE_32BIT_TIME_T
#define _USE_32BIT_TIME_T

In 32/64-bit libmsvcr120.a there is no _ftime and _ftime_s function (which is 
currently declared) and this gives link error.

In 64-bit libucrt.a _ftime function is mapped to _ftime32: in 
mingw-w64-crt/lib-common/ucrtbase.def.in
_ftime == _ftime32

My proposition is:
We could add _ftime32 to 64-bit libmsvcrt.a and alias _ftime32 as _ftime in 
32-bit libmsvcrt.a -- in msvcrt.dll from WinXPsp2 there 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.

Regards,
Mateusz

From 2674d777144bfe3bd783aedf20c48fb95c183dcc Mon Sep 17 00:00:00 2001
From: Mateusz 
Date: Sun, 4 Nov 2018 17:39:10 +0100
Subject: [PATCH] timeb.h: declare _ftime32 function, define _ftime according
 to _USE_32BIT_TIME_T

Signed-off-by: Mateusz Brzostek 
---
 mingw-w64-crt/lib-common/msvcrt.def.in  | 3 ++-
 mingw-w64-headers/crt/sec_api/sys/timeb_s.h | 4 +++-
 mingw-w64-headers/crt/sys/timeb.h   | 9 +
 3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in 
b/mingw-w64-crt/lib-common/msvcrt.def.in
index 1a1db2b4..13115412 100644
--- a/mingw-w64-crt/lib-common/msvcrt.def.in
+++ b/mingw-w64-crt/lib-common/msvcrt.def.in
@@ -532,7 +532,8 @@ _fstat64
 _fstati64
 F64(_fstat64i32 == _fstat)
 _ftime
-F_ARM_ANY(_ftime32)
+F_I386(_ftime32 == _ftime)
+F_NON_I386(_ftime32)
 _ftime32_s
 _ftime64
 _ftime64_s
diff --git a/mingw-w64-headers/crt/sec_api/sys/timeb_s.h 
b/mingw-w64-headers/crt/sec_api/sys/timeb_s.h
index f635d32b..ed92946e 100644
--- a/mingw-w64-headers/crt/sec_api/sys/timeb_s.h
+++ b/mingw-w64-headers/crt/sec_api/sys/timeb_s.h
@@ -15,11 +15,13 @@ extern "C" {
 
 #if defined(MINGW_HAS_SECURE_API)
 
-  _CRTIMP errno_t __cdecl _ftime_s(struct __timeb32 *_Time);
+  _CRTIMP errno_t __cdecl _ftime32_s(struct __timeb32 *_Time);
   _CRTIMP errno_t __cdecl _ftime64_s(struct __timeb64 *_Time);
 
 #ifndef _USE_32BIT_TIME_T
 #define _ftime_s _ftime64_s
+#else
+#define _ftime_s _ftime32_s
 #endif
 #endif
 
diff --git a/mingw-w64-headers/crt/sys/timeb.h 
b/mingw-w64-headers/crt/sys/timeb.h
index c92c8e01..eb92cd02 100644
--- a/mingw-w64-headers/crt/sys/timeb.h
+++ b/mingw-w64-headers/crt/sys/timeb.h
@@ -76,13 +76,14 @@ extern "C" {
 #endif
 
   _CRTIMP void __cdecl _ftime64(struct __timeb64 *_Time);
+  _CRTIMP void __cdecl _ftime32(struct __timeb32 *);
 
-#ifdef _WIN64
+#ifndef _USE_32BIT_TIME_T
 #define _timeb __timeb64
-  _CRTIMP void __cdecl _ftime(struct __timeb64 *);
+#define _ftime _ftime64
 #else
 #define _timeb __timeb32
-  _CRTIMP void __cdecl _ftime(struct __timeb32 *);
+#define _ftime _ftime32
 #endif
 
 #ifndef _TIMESPEC_DEFINED
@@ -109,7 +110,7 @@ struct itimerspec {
   }
 #else
   __CRT_INLINE void __cdecl ftime(struct timeb *_Tmb) {
-_ftime((struct __timeb32 *)_Tmb);
+_ftime32((struct __timeb32 *)_Tmb);
   }
 #endif /* _USE_32BIT_TIME_T */
 #endif /* !__CRT__NO_INLINE */
-- 
2.19.1.windows.1

#include 
#include 

int main(void)
{  
struct __timeb64 timebuf64;
struct _timeb timebuf;
struct __timeb32 timebuf32;
int i;

_ftime64();
_ftime();
_ftime32();

for (i = 0; i < 2; i++)
{
printf("Seconds since midnight, January 1, 1970 (UTC): %d, %d(%d), 
%d\n", (int)timebuf64.time, (int)timebuf.time, (int)sizeof(timebuf.time), 
timebuf32.time);
printf("Milliseconds: %d, %d, %d\n", timebuf64.millitm, 
timebuf.millitm, timebuf32.millitm);
printf("Minutes between UTC and local time: %d, %d, %d\n", 
timebuf64.timezone, timebuf.timezone, timebuf32.timezone);
printf("Daylight savings time flag (1 means Daylight time is in 
effect): %d, %d, %d\n", timebuf64.dstflag, timebuf.dstflag, timebuf32.dstflag);
if (i == 0)
printf("\nThe same for *_s functions:\n");
_ftime64_s();
_ftime_s();
_ftime32_s();
}
}___
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] headers: Update the threadlocinfo struct for ucrt

[Mateusz]

W dniu 18.10.2018 o 19:51, Martin Storsjö pisze:
> Signed-off-by: Martin Storsjö 
> ---
> This fixes a testcase like this:
> 
> #include 
> #include 
> #include 
> 
> int main(int argc, char const *argv[])
> {
> _locale_t loc = _create_locale(LC_ALL, "C");
> int ret = _isdigit_l('3', loc);
> printf ("%d\n", ret);
> return 0;
> }
> ---
>  mingw-w64-headers/crt/crtdefs.h | 6 ++
>  mingw-w64-headers/crt/ctype.h   | 5 +
>  2 files changed, 11 insertions(+)
> 
> diff --git a/mingw-w64-headers/crt/crtdefs.h b/mingw-w64-headers/crt/crtdefs.h
> index 20ba574..84c0455 100644
> --- a/mingw-w64-headers/crt/crtdefs.h
> +++ b/mingw-w64-headers/crt/crtdefs.h
> @@ -442,6 +442,11 @@ typedef struct tagLC_ID {
>  #ifndef _THREADLOCALEINFO
>  #define _THREADLOCALEINFO
>  typedef struct threadlocaleinfostruct {
> +#ifdef __MSVCRT_VERSION__ >= 0x1400

This gives warning. Maybe we should use
#if __MSVCRT_VERSION__ >= 0x1400
instead?

> +  const unsigned short *_locale_pctype;
> +  int _locale_mb_cur_max;
> +  unsigned int _locale_lc_codepage;
> +#else
>int refcount;
>unsigned int lc_codepage;
>unsigned int lc_collate_cp;
> @@ -465,6 +470,7 @@ typedef struct threadlocaleinfostruct {
>const unsigned char *pclmap;
>const unsigned char *pcumap;
>struct __lc_time_data *lc_time_curr;
> +#endif
>  } threadlocinfo;
>  #endif /* _THREADLOCALEINFO */
>  
> diff --git a/mingw-w64-headers/crt/ctype.h b/mingw-w64-headers/crt/ctype.h
> index a85ad96..e6449b3 100644
> --- a/mingw-w64-headers/crt/ctype.h
> +++ b/mingw-w64-headers/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

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

[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, sorry for noise in previous mail.

The problem was solved in master branch by
https://sourceforge.net/p/mingw-w64/mingw-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

[Mateusz]

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, sorry for noise in previous mail.
>>
>> The problem was solved in master branch by
>> https://sourceforge.net/p/mingw-w64/mingw-w64/ci/38496499910a580ddc449a7d09f3bc0302767f31/
>>
>> Regards,
>> Mateusz
> 
> I guess I should have checked the master branch first, this is perfect. Any 
> idea whether this will be backported to v6.x?

I don't know, usually JonY make the backports and releases.

JonY maybe it is time to backport all new commits and make 6.1 release?
Now it is possible to compile ffmpeg for msvcrt/msvcr120/ucrtbase and it passes 
FATE tests for all variants 32/64-bit msvcrt/msvcr120/ucrtbase.
It is also possible to compile x265 for ucrtbase and run this x265 in Windows 
XP (after installing VC++ 2017 redist that brings ucrt to WinXP).

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] GCC: Introduce xaccess function in libiberty

[Mateusz]

W dniu 05.01.2019 o 15:32, Liu Hao pisze:
> 在 2019/1/5 21:14, Johannes Pfau 写道:
>> Liu Hao:
>>> There are a few resolution to this at different levels. The most ideal
>>> solution would be providing an `access()` function that behaves
>>> expectedly in gnulib or libiberty, so this recipe can be ported
>>> elsewhere. Modifying GCC source should be considered the least preferred
>>> and last option.
>>
>> OK, that's what I thought. I've attached a new patch for libiberty,
>> could you please have a quick look at it before I submit it to GCC?
>>
>> It currently only handles F_OK which is the only case which really
>> seems to matter for GCC. I do not know how to check if a file is effectively
>> readable/writeable/executable in the windows api. And it seems
>> reimplementing R_OK and all the other flags would mean effectively
>> rewriting the complete access function. What do you think?
>>
> 
> A complete version looks basically like this:
> 
> ```c
>   DWORD attr = GetFileAttributesA(pathname);
>   if (attr == INVALID_FILE_ATTRIBUTES)
> {
>   // Set `errno` accordingly.
>   switch (GetLastError())
> {
> case ERROR_FILE_NOT_FOUND:
> case ERROR_PATH_NOT_FOUND:
>   errno = ENOENT;
>   break;
> case ERROR_ACCESS_DENIED:
>   errno = EACCES;
>   break;
> default:
>   errno = EINVAL;
> }
>   return -1;
> }
>   switch (mode)
> {
> case F_OK:
> case R_OK:
>   // It is always existent and readable.
>   return 0;
> case W_OK:
>   // Directories are always writeable.
>   if (attr & FILE_ATTRIBUTE_DIRECTORY)
> return 0;
>   // Read-only files are not writeable.
>   if (attr & FILE_ATTRIBUTE_READONLY)
> {
>   errno = EACCES;
>   return -1;
> }
>   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 too (msvcr100 works OK), so maybe it is better to add 
your access() function to msvcr110/120 and ucrtbase (as a replacement) instead 
of patching GCC.

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] GCC: Introduce xaccess function in libiberty

[Mateusz]

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 patching GCC.
>>
>> Regards,
>> Mateusz
>>
>>
> 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 
> extended. And as far as I can see, GCC already sets the __USE_MINGW_ACCESS 
> define, so it likely wouldn't need any changes.
I've attached patch to mingw-w64 that replaces _access in msvcr110/120 and 
ucrtbase with Liu Hao version (for me it is too big for inline).

After patching mingw-w64 (and before building) please go to mingw-w64-crt 
folder and execute
aclocal
automake
to regenerate makefiles.

This patch changes only lib files -- it should work.

Regards,
Mateusz
From 71f1504a4181d38118b4d7924f6b6fee0b3d275e Mon Sep 17 00:00:00 2001
From: Mateusz Brzostek 
Date: Sun, 6 Jan 2019 00:54:25 +0100
Subject: [PATCH] Add _access function that works for nul file to msvcr110/120
 and ucrtbase libs

Original implementation
Liu Hao 

Signed-off-by: Mateusz Brzostek 
---
 mingw-w64-crt/Makefile.am|  23 ++--
 mingw-w64-crt/def-include/msvcr110-common.def.in | 144 +++
 mingw-w64-crt/lib-common/ucrtbase.def.in |   4 +-
 mingw-w64-crt/lib32/msvcr110.def.in  |   4 +-
 mingw-w64-crt/lib32/msvcr120.def.in  |   4 +-
 mingw-w64-crt/lib32/msvcr120_app.def.in  |   4 +-
 mingw-w64-crt/lib32/msvcr120d.def.in |   4 +-
 mingw-w64-crt/lib64/msvcr110.def.in  |   4 +-
 mingw-w64-crt/lib64/msvcr120.def.in  |   4 +-
 mingw-w64-crt/lib64/msvcr120_app.def.in  |   4 +-
 mingw-w64-crt/lib64/msvcr120d.def.in |   4 +-
 mingw-w64-crt/stdio/access.c |  65 ++
 12 files changed, 241 insertions(+), 27 deletions(-)
 create mode 100644 mingw-w64-crt/def-include/msvcr110-common.def.in
 create mode 100644 mingw-w64-crt/stdio/access.c

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index f8b0623..5c0b421 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -213,6 +213,10 @@ src_msvcrt=\
   stdio/fseeki64.c \
   stdio/mingw_lock.c
 
+src_msvcr110=\
+  $(src_msvcrt_common) \
+  stdio/access.c
+
 src_ucrtbase=\
   crt/ucrtbase_compat.c \
   stdio/ucrt_fprintf.c \
@@ -226,7 +230,8 @@ src_ucrtbase=\
   stdio/ucrt_vfprintf.c \
   stdio/ucrt_vprintf.c \
   stdio/ucrt_vsnprintf.c \
-  stdio/ucrt_vsprintf.c
+  stdio/ucrt_vsprintf.c \
+  stdio/access.c
 
 src_msvcrt32=\
   $(src_msvcrt) \
@@ -709,25 +714,25 @@ lib32_libmsvcr100_a_CPPFLAGS=$(CPPFLAGS32) 
-D__LIBMSVCRT__ $(extra_include) $(sy
 EXTRA_lib32_libmsvcr100_a_DEPENDENCIES=lib32/msvcr100.def
 
 lib32_LIBRARIES += lib32/libmsvcr110.a
-lib32_libmsvcr110_a_SOURCES = $(src_msvcrt_common) lib32/msvcr110.def.in
+lib32_libmsvcr110_a_SOURCES = $(src_msvcr110) lib32/msvcr110.def.in
 lib32_libmsvcr110_a_AR = $(DTDEF32) lib32/msvcr110.def && $(AR) $(ARFLAGS)
 lib32_libmsvcr110_a_CPPFLAGS=$(CPPFLAGS32) -D__LIBMSVCRT__ $(extra_include) 
$(sysincludes)
 EXTRA_lib32_libmsvcr110_a_DEPENDENCIES=lib32/msvcr110.def
 
 lib32_LIBRARIES += lib32/libmsvcr120.a
-lib32_libmsvcr120_a_SOURCES = $(src_msvcrt_common) lib32/msvcr120.def.in
+lib32_libmsvcr120_a_SOURCES = $(src_msvcr110) lib32/msvcr120.def.in
 lib32_libmsvcr120_a_AR = $(DTDEF32) lib32/msvcr120.def && $(AR) $(ARFLAGS)
 lib32_libmsvcr120_a_CPPFLAGS=$(CPPFLAGS32) -D__LIBMSVCRT__ $(extra_include) 
$(sysincludes)
 EXTRA_lib32_libmsvcr120_a_DEPENDENCIES=lib32/msvcr120.def
 
 lib32_LIBRARIES += lib32/libmsvcr120d.a
-lib32_libmsvcr120d_a_SOURCES = $(src_msvcrt_common) lib32/msvcr120d.def.in
+lib32_libmsvcr120d_a_SOURCES = $(src_msvcr110) lib32/msvcr120d.def.in
 lib32_libmsvcr120d_a_AR = $(DTDEF32) lib32/msvcr120d.def && $(AR) $(ARFLAGS)
 lib32_libmsvcr120d_a_CPPFLAGS=$(CPPFLAGS32) -D__LIBMSVCRT__ $(extra_include) 
$(sysincludes)
 EXTRA_lib32_libmsvcr120d_a_DEPENDENCIES=lib32/msvcr120d.def
 
 lib32_LIBRARIES += lib32/libmsvcr120_app.a
-lib32_libmsvcr120_app_a_SOURCES = $(src_msvcrt_common) 
lib32/msvcr120_app.def.in
+lib32_libmsvcr120_app_a_SOURCES = $(src_msvcr110) lib32/msvcr120_app.def.in
 lib32_libmsvcr120_app_a_AR = $(DTDEF32) lib32/msvcr120_app.def && $(AR) 
$(ARFLAGS)
 lib32_libmsvcr120_app_a_CPPFLAGS=$(CPPFLAGS32) -D__LIBMSVCRT__ 
$(extra_include) $(sysincludes)
 EXTRA_lib32_libmsvcr120_app_a_DEPENDENCIES=lib32/msvcr120_app.def
@@ -1046,25 +1051,25 @@ lib64_libmsvcr100_a_CPPFLAGS=$(CPPFLAGS64) 
-D__LIBMSVCRT__ $(extra_include) $(sy
 EXTRA_lib64_libmsvcr100_a_DEPENDENCIES=lib64/msvcr100.def
 
 lib64_LIBRARIES += lib64/libmsvcr110.a
-lib64_libmsvcr110_a_SOURCES = $(src_msvcrt_common) lib64/msvcr110.def.in
+lib64_li

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

[Mateusz]

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 
>> extended. And as far as I can see, GCC already sets the __USE_MINGW_ACCESS 
>> define, so it likely wouldn't need any changes.
>> I've attached patch to mingw-w64 that replaces _access in msvcr110/120 and 
>> ucrtbase with Liu Hao version (for me it is too big for inline).
>>
> 
> This looks bad to be, as it breaks code which expects the MSVC behavior.

We could add __mingw_access to msvcr110/120 + ucrtbase libs and change a little 
bit io.h for case if __USE_MINGW_ACCESS is defined (check for 
__MSVCRT_VERSION__).

Or we could add __mingw_access to libmingwex and use exact the same version for 
all msvcrt/msvcr*/ucrt if __USE_MINGW_ACCESS is defined.

Or we could add __mingw_access to libmingwex and use it only when 
__MSVCRT_VERSION__ >= 0x1100 && defined(__USE_MINGW_ACCESS) and leave as is now 
for __MSVCRT_VERSION__ < 0x1100.

>> After patching mingw-w64 (and before building) please go to mingw-w64-crt 
>> folder and execute
>> aclocal
>> automake
>> to regenerate makefiles.
>>
>> This patch changes only lib files -- it should work.
> 
> Oops sorry, the second argument to `access()` can be a bitwise OR'd
> mask, so `switch (mode)` is horribly wrong. An amended version is provided:

I've attached access from MSVC 2010 -- if we agree that mingw-w64 should be 
patched in some way we could choose detail for _access/__mingw_access.

> 
> ```
> int access(const char *pathname, int mode)
> {
>   DWORD attr;
>   if (mode & ~(F_OK | R_OK | W_OK | X_OK))
> {
>   /* Invalid mode specified.  */
>   errno = EINVAL;
>   return -1;
> }
>   attr = GetFileAttributesA(pathname);
>   if (attr == INVALID_FILE_ATTRIBUTES)
> {
>   /* Set `errno` accordingly.  */
>   switch (GetLastError())
> {
> case ERROR_FILE_NOT_FOUND:
> case ERROR_PATH_NOT_FOUND:
>   errno = ENOENT;
>   break;
> case ERROR_ACCESS_DENIED:
>   errno = EACCES;
>   break;
> default:
>   errno = EINVAL;
> }
>   return -1;
> }
>   if (mode & W_OK)
> {
>   /* Directories are always writeable.
>* Normal files are writeable if not read-only.  */
>   if (!(attr & FILE_ATTRIBUTE_DIRECTORY) &&
>   (attr & FILE_ATTRIBUTE_READONLY))
> {
>   errno = EACCES;
>   return -1;
> }
> }
>   /* On Windows all files are presumed to be readable and executable.
>* They can be opened in a command prompt without any arguments.  */
>   return 0;
> }
> ```
> 
> N.B. I will not approve this patch because I authored this function.
> Somebody else please test it and report any issues. Thanks in advance.

Noticed -- I've provided some code for general discussion how to solve the 
problem (and I copied your code).

Regards,
Mateusz
/***
*access.c - access function
*
*   Copyright (c) Microsoft Corporation. All rights reserved.
*
*Purpose:
*   This file has the _access() function which checks on file accessability.
*
***/

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

/***
*int _access(path, amode) - check whether file can be accessed under mode
*
*Purpose:
*   Checks to see if the specified file exists and can be accessed
*   in the given mode.
*
*Entry:
*   _TSCHAR *path - pathname
*   int amode - access mode
*   (0 = exist only, 2 = write, 4 = read, 6 = read/write)
*
*Exit:
*   returns 0 if file has given mode
*   returns -1 and sets errno if file does not have given mode or
*   does not exist
*
*Exceptions:
*
***/

int __cdecl _taccess (
const _TSCHAR *path,
int amode
)
{
errno_t e;
e = _taccess_s(path,amode);

return e ? -1 : 0 ;
}

/***
*errno_t _access_s(path, amode) - check whether file can be accessed under mode
*
*Purpose:
*   Checks to see if the specified file exists and can be accessed
*   in the given mode.
*
*Entry:
*   _TSCHAR *path - pathname
*   int amode - access mode
*   (0 = exist only, 2 = write, 4 = read, 6 = read/write)
*
*Exit:
*   returns 0 if file has given mode
*   returns errno_t for any other errors
*
*Exceptions:
*
**

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

[Mateusz]

Hello,

In gcc 9.0 r266355 there was change in ABI for mingw-w64 (64-bit) target -- 
"Return AX_REG instead of FIRST_SSE_REG for 4 or 8 byte modes". It is wrong -- 
now function return double in rax instead of xmm0 register. This patch shows 
how to change return register from xmm0 to eax/rax (which is cool).

There are 2 problems:
1) r266355 broke 64-bit gcc 9 for mingw-w64 target
2) gcc could/should return aggregate types of up to 8 bytes via EAX register 
(not st(0) or xmm0)

I've prepared patches to gcc (branches 7 and 8 + trunk 9) that checks if type 
is not aggregate of up to 8 bytes before it returns in st(0)/xmm0 -- now it 
should be like in C++ from MSVC. (svn patches -- please apply with -p0 option)

I think this is not new problem so if there are some hints/opinion -- please 
share.

My questions are:
are the patches OK?
are the changes really needed (return struct with float in eax)?

Now (with patches) it works like this:
$ cat t.cpp
float fun1(void)
{
    return 4.14f;
}

typedef struct {float x;} Float;

Float fun2(void)
{
    Float v;
    v.x = 4.14f;
    return v;
}

double fun3(void)
{
    return 3.13;
}

typedef struct {double x;} Double;

Double 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  0x0(%rip),%xmm0    # 8 <_Z4fun1v+0x8>
   7:   00
    4: R_X86_64_PC32    .rdata
   8:   c3  retq
   9:   0f 1f 80 00 00 00 00    nopl   0x0(%rax)

0010 <_Z4fun2v>:
  10:   8b 05 00 00 00 00   mov    0x0(%rip),%eax    # 16 <_Z4fun2v+0x6>
    12: R_X86_64_PC32   .rdata
  16:   c3  retq
  17:   66 0f 1f 84 00 00 00    nopw   0x0(%rax,%rax,1)
  1e:   00 00

0020 <_Z4fun3v>:
  20:   f2 0f 10 05 08 00 00    movsd  0x8(%rip),%xmm0    # 30 <_Z4fun4v>
  27:   00
    24: R_X86_64_PC32   .rdata
  28:   c3  retq
  29:   0f 1f 80 00 00 00 00    nopl   0x0(%rax)

0030 <_Z4fun4v>:
  30:   48 8b 05 08 00 00 00    mov    0x8(%rip),%rax    # 3f <_Z4fun4v+0xf>
    33: R_X86_64_PC32   .rdata
  37:   c3  retq
  38:   90  nop
  39:   90  nop
  3a:   90  nop
  3b:   90  nop
  3c:   90  nop
  3d:   90  nop
  3e:   90          nop
  3f:   90      nop

Mateusz@Mateusz-i7 /c/temp
$ m32- 900

Mateusz@Mateusz-i7 /c/temp
$ g++ -c -Wall -O2 -o t32.o t.cpp

Mateusz@Mateusz-i7 /c/temp
$ objdump -dr t32.o

t32.o: file format pe-i386


Disassembly of section .text:

 <__Z4fun1v>:
   0:   d9 05 00 00 00 00   flds   0x0
    2: dir32    .rdata
   6:   c3  ret
   7:   8d b4 26 00 00 00 00    lea    0x0(%esi,%eiz,1),%esi
   e:   66 90   xchg   %ax,%ax

0010 <__Z4fun2v>:
  10:   a1 00 00 00 00  mov    0x0,%eax
    11: dir32   .rdata
  15:   c3  ret
  16:   8d b4 26 00 00 00 00    lea    0x0(%esi,%eiz,1),%esi
  1d:   8d 76 00    lea    0x0(%esi),%esi

0020 <__Z4fun3v>:
  20:   dd 05 08 00 00 00   fldl   0x8
    22: dir32   .rdata
  26:   c3  ret
  27:   8d b4 26 00 00 00 00    lea    0x0(%esi,%eiz,1),%esi
  2e:   66 90   xchg   %ax,%ax

0030 <__Z4fun4v>:
  30:   b8 0a d7 a3 70  mov    $0x70a3d70a,%eax
  35:   ba 3d 0a 09 40  mov    $0x40090a3d,%edx
  3a:   c3  ret
  3b:   90  nop
  3c:   90  nop
  3d:   90  nop
  3e:   90  nop
  3f:   90  nop

Regards,
Mateusz

Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c  (revision 267306)
+++ gcc/config/i386/i386.c  (working copy)
@@ -10553,6 +10553,66 @@
 }
 
 static rtx
+function_value_ms_32 (machine_mode orig_mode, machine_mode mode,
+ const_tree fntype, const_tree fn, const_tree valtype)
+{
+  unsigned int regno;
+
+  /* 8-byte vector modes in %mm0. See ix86_return_in_memory for where
+ we normally prevent this case when mmx is not available.  However
+ some ABIs may require the result to be returned like DImode.  */
+  if (VECTOR_MODE_P (mode) && GET_MODE_SIZE (mode) == 8)
+regno = FIRST_MMX_REG;
+
+  /* 16-byte vector modes in %xmm0.  See ix86_return_in_memory for where
+ we prevent this case when sse is not available.  Howe

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

[Mateusz]

Hello,

When I try to build x265 with ucrtbase (instead of msvcrt) I get errors:
f:/msys/m64-82/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libucrt.a(dtwcs00041.o):(.text+0x0):
 multiple definition of `_fseeki64'; 
f:/msys/m64-82/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingwex.a(lib64_libmingwex_a-fseeko64.o):fseeko64.c:(.text+0x350):
 first defined here
f:/msys/m64-82/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
 
f:/msys/m64-82/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libucrt.a(dtwcs00045.o):(.text+0x0):
 multiple definition of `_ftelli64'; 
f:/msys/m64-82/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingwex.a(lib64_libmingwex_a-fseeko64.o):fseeko64.c:(.text+0x130):
 first defined here
f:/msys/m64-82/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
 
f:/msys/m64-82/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingwex.a(lib64_libmingwex_a-fseeko64.o):fseeko64.c:(.rdata$.refptr.__imp___pioinfo[.refptr.__imp___pioinfo]+0x0):
 undefined reference to `__imp___pioinfo'
collect2.exe: error: ld returned 1 exit status

Problem is in libstdc++.a which uses fseeko64 from libmingwex.

My proposition is:
we could build two libmingwex -- libmingwex for msvcrt and libmingwex10 for 
msvcr100 and above, leave fseeko64 in libmingwex* and remove _fseeki64 and 
_ftelli64 from libmingwex10.
For msvcrt spec file should be without changes
... -lmoldname -lmingwex -lmsvcrt
for ucrtbase (and similar for msvcr120/110/100)
... -lmoldname -lmingwex10 -lucrtbase

I've attached patch proposition that do what 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

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 079dc5a4..f6ffd922 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -658,6 +658,10 @@ lib32_LIBRARIES += lib32/libmingwex.a
 lib32_libmingwex_a_CPPFLAGS=$(CPPFLAGS32) $(extra_include) $(AM_CPPFLAGS)
 lib32_libmingwex_a_SOURCES = $(src_libmingwex) $(src_libmingwex32) 
$(src_dfp_math)
 
+lib32_LIBRARIES += lib32/libmingwex10.a
+lib32_libmingwex10_a_CPPFLAGS=$(CPPFLAGS32) -D__MINGW_LIBMINGWEX10 
$(extra_include) $(AM_CPPFLAGS)
+lib32_libmingwex10_a_SOURCES = $(src_libmingwex) $(src_libmingwex32) 
$(src_dfp_math)
+
 lib32_LIBRARIES += lib32/libmoldname.a
 lib32_libmoldname_a_CPPFLAGS=$(CPPFLAGS32) $(extra_include) $(AM_CPPFLAGS)
 lib32_libmoldname_a_SOURCES = $(src_libm)
@@ -992,6 +996,10 @@ lib64_LIBRARIES += lib64/libmingwex.a
 lib64_libmingwex_a_CPPFLAGS=$(CPPFLAGS64) $(extra_include) $(AM_CPPFLAGS)
 lib64_libmingwex_a_SOURCES = $(src_libmingwex) $(src_libmingwex64) 
$(src_dfp_math)
 
+lib64_LIBRARIES += lib64/libmingwex10.a
+lib64_libmingwex10_a_CPPFLAGS=$(CPPFLAGS64) -D__MINGW_LIBMINGWEX10 
$(extra_include) $(AM_CPPFLAGS)
+lib64_libmingwex10_a_SOURCES = $(src_libmingwex) $(src_libmingwex64) 
$(src_dfp_math)
+
 lib64_LIBRARIES += lib64/libmoldname.a
 lib64_libmoldname_a_CPPFLAGS=$(CPPFLAGS64) $(extra_include) $(AM_CPPFLAGS)
 lib64_libmoldname_a_SOURCES = $(src_libm)
diff --git a/mingw-w64-crt/stdio/fseeko64.c b/mingw-w64-crt/stdio/fseeko64.c
index 5905aa22..a36c89ce 100644
--- a/mingw-w64-crt/stdio/fseeko64.c
+++ b/mingw-w64-crt/stdio/fseeko64.c
@@ -3,12 +3,18 @@
  * This file is part of the mingw-w64 runtime package.
  * No warranty is given; refer to the file DISCLAIMER.PD within this package.
  */
+#ifdef __MINGW_LIBMINGWEX10
+#undef __MSVCRT_VERSION__
+#define __MSVCRT_VERSION__ 0x1000
+#endif
+
 #include 
 #include 
 #include 
 #include 
 #include 
 
+#if __MSVCRT_VERSION__ < 0x1000
 struct oserr_map {
   unsigned long oscode; /* OS values */
   int errnocode; /* System V codes */
@@ -103,6 +109,7 @@ int __cdecl _flush (FILE *str)
   stream->_cnt = 0ll;
   return rc;
 }
+#endif /* __MSVCRT_VERSION__ < 0x1000 */
 
 int fseeko64 (FILE* stream, _off64_t offset, int whence)
 {
@@ -130,6 +137,7 @@ int fseeko64 (FILE* stream, _off64_t offset, int whence)
   return fsetpos (stream, );
 }
 
+#if __MSVCRT_VERSION__ < 0x1000
 int __cdecl _fseeki64(FILE *str,__int64 offset,int whence)
 {
 FILE *stream;
@@ -256,3 +264,4 @@ void mingw_dosmaperr (unsigned long oserrno)
   else
 errno = EINVAL;
 }
+#endif /* __MSVCRT_VERSION__ < 0x1000 */
diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h
index c79d7054..0a167a26 100644
--- a/mingw-w64-headers/crt/stdio.h
+++ b/mingw-w64-headers/crt/stdio.h
@@ -609,31 +609,20 @@ int vsnprintf (char *__stream, size_t __n, const char 
*__format, __builtin_va_li
 
   /* Shouldn't be any fseeko32 

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

[Mateusz]

W dniu 23.11.2018 o 00:50, Edward Diener pisze:
> There is a bug which in binutils which causes clang targeting mingw-64/gcc on 
> Windows to create a bad windows executable. The bug is explained at 
> https://sourceware.org/bugzilla/show_bug.cgi?id=23872 and is fixed at
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=73af69e74974eaa155eec89867e3ccc77ab39f6d
> in the binutils-gdb git repository. I understand that part of the blame for 
> this problem resides with clang, and I have posted a bug report with clang 
> that is referencing the problem I found, which may be because of the bug.
> 
> Is it possible for me to replace the binutils executables in the latest 
> mingw-64 installation I have installed on Windows, which is for gcc-8.1, with 
> the fixed version ? If so how would I do that working on Windows ? I do have 
> MSYS2 installed but I do not know how to use it to rebuild the binutils for a 
> mingw-64 installation, if that is possible, so if anyone can offer me 
> guidance in doing so it would be appreciated. I am a knowledgeable C++ 
> programmer so I just need some sort of recipe for doing this, if it is 
> 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



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[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 could build two libmingwex -- libmingwex for msvcrt and libmingwex10 for 
>>> msvcr100 and above, leave fseeko64 in libmingwex* and remove _fseeki64 and 
>>> _ftelli64 from libmingwex10.
>>> For msvcrt spec file should be without changes
>>> ... -lmoldname -lmingwex -lmsvcrt
>>> for ucrtbase (and similar for msvcr120/110/100)
>>> ... -lmoldname -lmingwex10 -lucrtbase
>>
>> In general, so far, when using ucrt, we rely on a number of redirections in 
>> headers, so that an object file built for an older crt version won't 
>> necessarily work with the newer one. The exception to this, so far, has been 
>> the main CRT startup files and libmingw32/libmingwex. (We haven't checked 
>> all of libmingwex exhaustively, but only the parts that have been pulled in 
>> by code built in this setup.)
>>
>> In your case, the issue is that libstdc++.a contains a whole lot of object 
>> files built targeting another crt version.
>>
>> I would very much prefer not to have two separate versions of libmingwex. 
>> Instead it's often possible to tweak what libmingwex does, and tweak the 
>> headers and actual functions/stubs exported by libmsvcrt.a and libucrtbase.a 
>> so that the same single build of libmingwex.a works with both.
>>
>> If the __pioinfo function is the only issue with a libstdc++.a built against 
>> libmsvcrt.a but linked against libucrtbase.a, it might be worthwhile to try 
>> to work around it. To do that, the first step would be to look up what it is 
>> used for and what the replacing functionality is in ucrtbase. After that, 
>> one can e.g. change the headers to redirect the __piofunction to use the new 
>> ucrtbase mechansim in general, and add a wrapper in libmsvcr*.a that 
>> provides this interface. See e.g. src_msvcrt_common in 
>> mingw-w64-crt/Makefile.am for a few cases of doing this so far.
>>
>> A different strategy would be to move the helpers that differ depending on 
>> crt version from libmingwex.a into libmsvcr*.a and libucrtbase.a instead, to 
>> allow different versions/sets of them that actually match the CRT they are 
>> to be used with. In this case, move the parts that you wanted to 
>> differentiate in libmingwex into libmsvcr*.a and libucrtbase.a.
> 
> Thanks! I like the last approach -- we could remove _fseeki64 and _ftelli64 
> from libmingwex.a and move these functions to libmsvcrt.a and libmsvcr80.a 
> (there are already in libmsvcr90.a and newer).
> 
> I will make some tests and prepare new patch.

I've attached new patch -- mingw-w64-crt/Makefile.am is changed so you should 
use automake before testing.

Now libmingwex.a is smaller (without _fseeki64 and _ftelli64 functions which 
are moved to libmsvcrt.a). I can build and execute x265 linked to msvcrt.dll, 
msvcr120.dll and ucrtbase.dll.

In old file mingw-w64-crt/stdio/fseeko64.c was function mingw_dosmaperr that I 
don't know for what reason it was so I removed this function (there was only 
one string 'mingw_dosmaperr' in whole mingw-w64 folder).

Regards,
Mateusz
From 2c3234b7f75efce0c6fb0c872ebd79534948fbce Mon Sep 17 00:00:00 2001
From: Mateusz Brzostek 
Date: Fri, 23 Nov 2018 19:16:43 +0100
Subject: [PATCH] move _fseeki64 and _ftelli64 functions from libmingwex to
 libmsvcrt

Signed-off-by: Mateusz Brzostek 
---
 mingw-w64-crt/Makefile.am  |   1 +
 mingw-w64-crt/stdio/fseeki64.c | 171 +++
 mingw-w64-crt/stdio/fseeko64.c | 222 -
 mingw-w64-headers/crt/stdio.h  |  17 +---
 4 files changed, 175 insertions(+), 236 deletions(-)
 create mode 100644 mingw-w64-crt/stdio/fseeki64.c

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 079dc5a..f8b0623 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -210,6 +210,7 @@ src_msvcrt=\
   secapi/vsprintf_s.c \
   secapi/wmemcpy_s.c \
   secapi/wmemmove_s.c \
+  stdio/fseeki64.c \
   stdio/mingw_lock.c
 
 src_ucrtbase=\
diff --git a/mingw-w64-crt/stdio/fseeki64.c b/mingw-w64-crt/stdio/fseeki64.c
new file mode 100644
index 000..36d3274
--- /dev/null
+++ b/mingw-w64-crt/stdio/fseeki64.c
@@ -0,0 +1,171 @@
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define _IOYOURBUF  0x0100
+#define _IOSETVBUF  0x

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

[Mateusz]

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/fseeki64.c and stdio/mingw_lock.c and was able to 
build x265.

Bad news is that x265 is not working -- it displays message box:
Microsoft Visual C++ Runtime Library
Runtime Error!
Program: f:\speed\2.9+9\x265m08.exe
R6034
An application has made an attempt to load the C runtime
library incorrectly.
Please contact the application's support team for more
information.
[OK]

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

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

[Mateusz]

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/fseeki64.c and stdio/mingw_lock.c and was able to 
> build x265.
> 
> Bad news is that x265 is not working -- it displays message box:
> Microsoft Visual C++ Runtime Library
> Runtime Error!
> Program: f:\speed\2.9+9\x265m08.exe
> R6034
> An application has made an attempt to load the C runtime
> library incorrectly.
> Please contact the application's support team for more
> information.
> [OK]
> 
> It is much better but not perfect.

I have the same problem with exe linked to msvcr90.dll (on Windows 10 64-bit 
Home). I can run exe linked to msvcr100/110/120.dll, ucrtbase.dll and 
msvcrt.dll.

Is it needed something special to run exe linked to msvcr80/90.dll on 64-bit 
Win10?

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] Problems with fseeko64, libstdc++ and ucrt builds

[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 
>> msvcr100 and above, leave fseeko64 in libmingwex* and remove _fseeki64 and 
>> _ftelli64 from libmingwex10.
>> For msvcrt spec file should be without changes
>> ... -lmoldname -lmingwex -lmsvcrt
>> for ucrtbase (and similar for msvcr120/110/100)
>> ... -lmoldname -lmingwex10 -lucrtbase
> 
> In general, so far, when using ucrt, we rely on a number of redirections in 
> headers, so that an object file built for an older crt version won't 
> necessarily work with the newer one. The exception to this, so far, has been 
> the main CRT startup files and libmingw32/libmingwex. (We haven't checked all 
> of libmingwex exhaustively, but only the parts that have been pulled in by 
> code built in this setup.)
> 
> In your case, the issue is that libstdc++.a contains a whole lot of object 
> files built targeting another crt version.
> 
> I would very much prefer not to have two separate versions of libmingwex. 
> Instead it's often possible to tweak what libmingwex does, and tweak the 
> headers and actual functions/stubs exported by libmsvcrt.a and libucrtbase.a 
> so that the same single build of libmingwex.a works with both.
> 
> If the __pioinfo function is the only issue with a libstdc++.a built against 
> libmsvcrt.a but linked against libucrtbase.a, it might be worthwhile to try 
> to work around it. To do that, the first step would be to look up what it is 
> used for and what the replacing functionality is in ucrtbase. After that, one 
> can e.g. change the headers to redirect the __piofunction to use the new 
> ucrtbase mechansim in general, and add a wrapper in libmsvcr*.a that provides 
> this interface. See e.g. src_msvcrt_common in mingw-w64-crt/Makefile.am for a 
> few cases of doing this so far.
> 
> A different strategy would be to move the helpers that differ depending on 
> crt version from libmingwex.a into libmsvcr*.a and libucrtbase.a instead, to 
> allow different versions/sets of them that actually match the CRT they are to 
> be used with. In this case, move the parts that you wanted to differentiate 
> in libmingwex into libmsvcr*.a and libucrtbase.a.

Thanks! I like the last approach -- we could remove _fseeki64 and _ftelli64 
from libmingwex.a and move these functions to libmsvcrt.a and libmsvcr80.a 
(there are already in libmsvcr90.a and newer).

I will make some tests and prepare new 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] Problems with fseeko64, libstdc++ and ucrt builds

[Mateusz]

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.
>>>
>>>
>>> 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 vsnprintf (char *__stream, size_t __n, const 
>>>> char *__format, __builtin_va_li
>>>>   /* Shouldn't be any fseeko32 in glibc, 32bit to 64bit casting should 
>>>> be fine */
>>>>     /* int fseeko32(FILE* stream, _off_t offset, int whence);*/ /* 
>>>> fseeko32 redirects to fseeko64 */
>>>> -#if __MSVCRT_VERSION__ >= 0x1400
>>>> +#if __MSVCRT_VERSION__ >= 0x900
>>>>     // Mark these as _CRTIMP to avoid trying to link in the mingwex 
>>>> versions.
>>>>     _CRTIMP int __cdecl _fseeki64(FILE *_File,__int64 _Offset,int _Origin);
>>>>     _CRTIMP __int64 __cdecl _ftelli64(FILE *_File);
>>>> -  __mingw_static_ovr int fseeko(FILE *_File, _off_t _Offset, int _Origin) 
>>>> {
>>>> -    return fseek(_File, _Offset, _Origin);
>>>> -  }
>>>> -  __mingw_static_ovr int fseeko64(FILE *_File, _off64_t _Offset, int 
>>>> _Origin) {
>>>> -    return _fseeki64(_File, _Offset, _Origin);
>>>> -  }
>>>> -  __mingw_static_ovr _off_t ftello(FILE *_File) {
>>>> -    return ftell(_File);
>>>> -  }
>>>> -  __mingw_static_ovr _off64_t ftello64(FILE *_File) {
>>>> -    return _ftelli64(_File);
>>>> -  }
>>>>   #else
>>>>     __MINGW_EXTENSION int __cdecl _fseeki64(FILE *_File,__int64 
>>>> _Offset,int _Origin);
>>>>     __MINGW_EXTENSION __int64 __cdecl _ftelli64(FILE *_File);
>>>> +#endif
>>>
>>> I would suggest to get rid of #if here and simply always use _CRTIMP 
>>> without __MINGW_EXTENSION. This would require adding symbols with 
>>> __MINGW_IMP_SYMBOL to symbols in fseeki64.c.
>>
>> I'm not quite sure I know all the nuances about the difference between e.g. 
>> fseeko64 and _fseeki64 (looking at stdio/fseeko64.c, their implementation is 
>> rather different), but... On one hand I'd like to keep inline versions in 
>> the headers for ucrt, but on the other hand it is unnecessary if the 
>> libmingwex versions work as well. If others prefer unifying it I don't mind.
> 
> 
> Actually I didn't notice that aspect, I concentrated on getting moving part 
> right. Before changing that, it would at least deserve a reasoning. I'm not 
> sure about nuances as well, so I don't know what's the best solution. I'd 
> prefer to simply keep it out of this patch.
> 
> 
>>
>> In general the patch (the latest version) looks rather straightforward to 
>> me, and I'm fine with it if Jacek is. 
> 
> 
> With inline helpers kept for ucrt builds, I will be fine with the patch.

In all documentations about fseeko/fseek that I found it is clear stated that 
fseeko works exactly like fseek but it is better and preferable (because of 
_off_t instead of long). mingw implementation of fseeko64 looks too much 
simplified (it is possible that it was written before _fseeki64).

My question/proposition is:
we declare fseeko64 as
_CRTIMP int __cdecl fseeko64...

for libmsvcrt we add line to fseeki64.c
int __cdecl (*__MINGW_IMP_SYMBOL(fseeko64))(FILE *, _off64_t, int) = _fseeki64;

for libmsvcr90 and newer we add line to def.in file
fseeko64 == _fseeki64
and we delete 'DATA' from original _fseeki64 (libmsvcr90 and 100)

We could do similar for ftello64.

Is that way OK?

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] Problems with fseeko64, libstdc++ and ucrt builds

[Mateusz]

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.
>>>
>>>
>>> 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 vsnprintf (char *__stream, size_t __n, const 
>>>> char *__format, __builtin_va_li
>>>>   /* Shouldn't be any fseeko32 in glibc, 32bit to 64bit casting should 
>>>> be fine */
>>>>     /* int fseeko32(FILE* stream, _off_t offset, int whence);*/ /* 
>>>> fseeko32 redirects to fseeko64 */
>>>> -#if __MSVCRT_VERSION__ >= 0x1400
>>>> +#if __MSVCRT_VERSION__ >= 0x900
>>>>     // Mark these as _CRTIMP to avoid trying to link in the mingwex 
>>>> versions.
>>>>     _CRTIMP int __cdecl _fseeki64(FILE *_File,__int64 _Offset,int _Origin);
>>>>     _CRTIMP __int64 __cdecl _ftelli64(FILE *_File);
>>>> -  __mingw_static_ovr int fseeko(FILE *_File, _off_t _Offset, int _Origin) 
>>>> {
>>>> -    return fseek(_File, _Offset, _Origin);
>>>> -  }
>>>> -  __mingw_static_ovr int fseeko64(FILE *_File, _off64_t _Offset, int 
>>>> _Origin) {
>>>> -    return _fseeki64(_File, _Offset, _Origin);
>>>> -  }
>>>> -  __mingw_static_ovr _off_t ftello(FILE *_File) {
>>>> -    return ftell(_File);
>>>> -  }
>>>> -  __mingw_static_ovr _off64_t ftello64(FILE *_File) {
>>>> -    return _ftelli64(_File);
>>>> -  }
>>>>   #else
>>>>     __MINGW_EXTENSION int __cdecl _fseeki64(FILE *_File,__int64 
>>>> _Offset,int _Origin);
>>>>     __MINGW_EXTENSION __int64 __cdecl _ftelli64(FILE *_File);
>>>> +#endif
>>>
>>> I would suggest to get rid of #if here and simply always use _CRTIMP 
>>> without __MINGW_EXTENSION. This would require adding symbols with 
>>> __MINGW_IMP_SYMBOL to symbols in fseeki64.c.
>>
>> I'm not quite sure I know all the nuances about the difference between e.g. 
>> fseeko64 and _fseeki64 (looking at stdio/fseeko64.c, their implementation is 
>> rather different), but... On one hand I'd like to keep inline versions in 
>> the headers for ucrt, but on the other hand it is unnecessary if the 
>> libmingwex versions work as well. If others prefer unifying it I don't mind.
> 
> 
> Actually I didn't notice that aspect, I concentrated on getting moving part 
> right. Before changing that, it would at least deserve a reasoning. I'm not 
> sure about nuances as well, so I don't know what's the best solution. I'd 
> prefer to simply keep it out of this patch.
> 
> 
>>
>> In general the patch (the latest version) looks rather straightforward to 
>> me, and I'm fine with it if Jacek is. 
> 
> 
> With inline helpers kept for ucrt builds, I will be fine with the patch.
> 
> 
> Thanks,
> 
> Jacek

OK, I've attached minimal version -- inline helpers kept for ucrt, only 
_fseeki64 and _ftelli64 moved, I also removed 'DATA' guards for multiple 
definition in libmsvcr90 and 100.

Regards,
Mateusz
From f809876dfa33350d713b465cc033e85095fafddc Mon Sep 17 00:00:00 2001
From: Mateusz Brzostek 
Date: Tue, 27 Nov 2018 09:21:36 +0100
Subject: [PATCH] move _fseeki64 and _ftelli64 functions from libmingwex to
 libmsvcrt

_fseeki64 and _ftelli64 functions are already in libmsvcr90 and newer,
so we need to provide these functions only for libmsvcrt. In addition,
_ftelli64 function implementation is not compatible with ucrt.

Signed-off-by: Mateusz Brzostek 
---
 mingw-w64-crt/Makefile.am   |   1 +
 mingw-w64-crt/lib32/msvcr100.def.in |   4 +-
 mingw-w64-crt/lib32/msvcr90.def.in  |   4 +-
 mingw-w64-crt/lib64/msvcr100.def.in |   4 +-
 mingw-w64-crt/lib64/msvcr90.def.in  |   4 +-
 mingw-w64-crt/stdio/fseeki64.c  | 177 
 mingw-w64-crt/stdio/fseeko64.c  | 131 --
 mingw-w64-headers/crt/stdio.h   |   5 +-
 8 files changed, 187 insertions(+), 143 deletions(-)
 create mode 100644 mingw-w64-crt/stdio/fseeki64.c

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 079dc5a..f8b0623 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -210,6 +210,7 @@ src_msvcrt=\
   secapi/vsprintf_s.c \
   secapi/wmemcpy_s.c \
   secapi/wmemmove_s.c \
+  stdio/fseeki64.c \
   stdio/mingw_lock.c
 
 src_ucrtbase=\
diff --git a/mingw-w64-crt/lib32/msvcr100.def.in 
b/mingw-w64-crt/lib32/msvcr100.de

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

[Mateusz]

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 vsnprintf (char *__stream, size_t __n, const char 
>> *__format, __builtin_va_li
>>       /* Shouldn't be any fseeko32 in glibc, 32bit to 64bit casting should 
>> be fine */
>>     /* int fseeko32(FILE* stream, _off_t offset, int whence);*/ /* fseeko32 
>> redirects to fseeko64 */
>> -#if __MSVCRT_VERSION__ >= 0x1400
>> +#if __MSVCRT_VERSION__ >= 0x900
>>     // Mark these as _CRTIMP to avoid trying to link in the mingwex versions.
>>     _CRTIMP int __cdecl _fseeki64(FILE *_File,__int64 _Offset,int _Origin);
>>     _CRTIMP __int64 __cdecl _ftelli64(FILE *_File);
>> -  __mingw_static_ovr int fseeko(FILE *_File, _off_t _Offset, int _Origin) {
>> -    return fseek(_File, _Offset, _Origin);
>> -  }
>> -  __mingw_static_ovr int fseeko64(FILE *_File, _off64_t _Offset, int 
>> _Origin) {
>> -    return _fseeki64(_File, _Offset, _Origin);
>> -  }
>> -  __mingw_static_ovr _off_t ftello(FILE *_File) {
>> -    return ftell(_File);
>> -  }
>> -  __mingw_static_ovr _off64_t ftello64(FILE *_File) {
>> -    return _ftelli64(_File);
>> -  }
>>   #else
>>     __MINGW_EXTENSION int __cdecl _fseeki64(FILE *_File,__int64 _Offset,int 
>> _Origin);
>>     __MINGW_EXTENSION __int64 __cdecl _ftelli64(FILE *_File);
>> +#endif
> 
> I would suggest to get rid of #if here and simply always use _CRTIMP without 
> __MINGW_EXTENSION. This would require adding symbols with __MINGW_IMP_SYMBOL 
> to symbols in fseeki64.c.

Thanks for the suggestion -- new patch attached with __MINGW_IMP_SYMBOL.

I decided to not remove mingw_dosmaperr function -- it is safer and I found in 
some project the code:
#ifndef WIN_32
#define _dosmaperr mingw_dosmaperr

There is a problem with libmsvcr80 -- it is not working for me at all, error 
output from CMake:
  The C compiler

"F:/MSYS/m64-731/bin/gcc.exe"

  is not able to compile a simple test program.

  It fails with the following output:

Change Dir: F:/x265/ma/12-b/CMakeFiles/CMakeTmp

Run Build Command:"F:/MSYS/bin/make.exe" "cmTC_1e936/fast"
/usr/bin/make -f CMakeFiles/cmTC_1e936.dir/build.make 
CMakeFiles/cmTC_1e936.dir/build
make[1]: Entering directory `/f/x265/ma/12-b/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_1e936.dir/testCCompiler.c.obj
/F/MSYS/m64-731/bin/gcc.exe-o 
CMakeFiles/cmTC_1e936.dir/testCCompiler.c.obj   -c 
/F/x265/ma/12-b/CMakeFiles/CMakeTmp/testCCompiler.c
Linking C executable cmTC_1e936.exe
/F/cmake/bin/cmake.exe -E remove -f CMakeFiles/cmTC_1e936.dir/objects.a
/F/MSYS/m64-731/bin/ar.exe cr CMakeFiles/cmTC_1e936.dir/objects.a 
@CMakeFiles/cmTC_1e936.dir/objects1.rsp
/F/MSYS/m64-731/bin/gcc.exe  -Wl,--whole-archive 
CMakeFiles/cmTC_1e936.dir/objects.a -Wl,--no-whole-archive  -o cmTC_1e936.exe 
-Wl,--out-implib,libcmTC_1e936.dll.a 
-Wl,--major-image-version,0,--minor-image-version,0 
@CMakeFiles/cmTC_1e936.dir/linklibs.rsp

f:/msys/m64-731/bin/../lib/gcc/x86_64-w64-mingw32/7.3.1/../../../../x86_64-w64-mingw32/bin/ld.exe:
 
f:/msys/m64-731/bin/../lib/gcc/x86_64-w64-mingw32/7.3.1/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o:crtexe.c:(.text+0x270):
 undefined reference to `_set_invalid_parameter_handler'
collect2.exe: error: ld returned 1 exit status

I decide to not touch libmsvcr80 at all, because it is not working.

Regards,
Mateusz
From 7ffedc542531e01cc76242ff96c6b96593779a26 Mon Sep 17 00:00:00 2001
From: Mateusz Brzostek 
Date: Mon, 26 Nov 2018 20:17:22 +0100
Subject: [PATCH] move _fseeki64 and _ftelli64 functions from libmingwex to
 libmsvcrt

_fseeki64 and _ftelli64 functions are already in libmsvcr90 and newer,
so we need to provide these functions only for libmsvcrt. In addition,
_ftelli64 function implementation is not compatible with ucrt.

Signed-off-by: Mateusz Brzostek 
---
 mingw-w64-crt/Makefile.am  |   1 +
 mingw-w64-crt/stdio/fseeki64.c | 175 +
 mingw-w64-crt/stdio/fseeko64.c | 131 --
 mingw-w64-headers/crt/stdio.h  |  18 -
 4 files changed, 176 insertions(+), 149 deletions(-)
 create mode 100644 mingw-w64-crt/stdio/fseeki64.c

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 079dc5a..f8b0623 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -210,6 +210,7 @@ src_msvcrt=\
   secapi/vsprintf_s.c \
   secapi/wmemcpy_s.c \
   secapi/wmemmove_s.c \
+  stdio/fseeki64.c \
   stdio/mingw_lock.c
 
 src_ucrtbase=\
diff --git a/mingw-w64-crt/stdio/fseeki64.c b/mingw-w64-crt/st

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

[Mateusz]

W dniu 08.01.2019 o 18:29, Sailor Bob via Mingw-w64-public pisze:
> 
> I'm trying to compile a modified version of UniLogger on Ubuntu 18.04 using 
> mingw. I'm getting the following link error:
> 
> undefined reference to '_imp__GetSaveFileNameW@4'

I've tested GetSaveFileNameW sample 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();
  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__GetSaveFileNameW@4'
collect2.exe: error: ld returned 1 exit status

Mateusz@Mateusz-i7 /f/b/ma-gcc/c
$ gcc -Wall -o t.exe t.c -lcomdlg32

Now it is OK and t.exe works.

Regards,
Mateusz



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

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 +++
 mingw-w64-headers/crt/io.h|  4 +--
 3 files changed, 55 insertions(+), 4 deletions(-)
 create mode 100644 mingw-w64-crt/misc/mingw-access.c

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index f8b0623c..10f3b04c 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -330,7 +330,7 @@ src_libmingwex=\
   misc/wcstoimax.c   misc/wcstold.c misc/wcstoumax.c
misc/wctob.c misc/wctrans.c \
   misc/wctype.c  misc/wdirent.c misc/winbs_uint64.c 
misc/winbs_ulong.c   misc/winbs_ushort.c\
   misc/wmemchr.c misc/wmemcmp.c misc/wmemcpy.c  
misc/wmemmove.c  misc/wmempcpy.c\
-  misc/wmemset.c misc/ftw.c misc/ftw64.c  \
+  misc/wmemset.c misc/ftw.c misc/ftw64.c
misc/mingw-access.c  \
   \
   stdio/mingw_pformat.h\
   stdio/vfscanf2.S stdio/vfwscanf2.S stdio/vscanf2.S  
stdio/vsscanf2.S  stdio/vswscanf2.S \
diff --git a/mingw-w64-crt/misc/mingw-access.c 
b/mingw-w64-crt/misc/mingw-access.c
new file mode 100644
index ..98fe734d
--- /dev/null
+++ b/mingw-w64-crt/misc/mingw-access.c
@@ -0,0 +1,53 @@
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
+#include 
+#include 
+
+int __cdecl __mingw_access(const char *fname, int mode);
+
+int __cdecl __mingw_access(const char *fname, int mode)
+{
+  DWORD attr;
+
+  if (fname == NULL || (mode & ~(F_OK | X_OK | W_OK | R_OK)))
+  {
+errno = EINVAL;
+return -1;
+  }
+
+  attr = GetFileAttributesA(fname);
+  if (attr == INVALID_FILE_ATTRIBUTES)
+  {
+switch (GetLastError())
+{
+  case ERROR_FILE_NOT_FOUND:
+  case ERROR_PATH_NOT_FOUND:
+errno = ENOENT;
+break;
+  case ERROR_ACCESS_DENIED:
+errno = EACCES;
+break;
+  default:
+errno = EINVAL;
+}
+return -1;
+  }
+
+  if (attr & FILE_ATTRIBUTE_DIRECTORY)
+  {
+/* All directories have read & write access */
+return 0;
+  }
+
+  if ((attr & FILE_ATTRIBUTE_READONLY) && (mode & W_OK))
+  {
+/* no write permission on file */
+errno = EACCES;
+return -1;
+  }
+  else
+return 0;
+}
diff --git a/mingw-w64-headers/crt/io.h b/mingw-w64-headers/crt/io.h
index a7cc5fc4..4a5b08ba 100644
--- a/mingw-w64-headers/crt/io.h
+++ b/mingw-w64-headers/crt/io.h
@@ -365,9 +365,7 @@ unsigned int alarm(unsigned int seconds);
 /*  Old versions of MSVCRT access() just ignored X_OK, while the version
 shipped with Vista, returns an error code.  This will restore the
 old behaviour  */
-static inline int __mingw_access (const char *__fname, int __mode) {
-  return  _access (__fname, __mode & ~X_OK);
-}
+int __cdecl __mingw_access (const char *__fname, int __mode);
 
 #define access(__f,__m)  __mingw_access (__f, __m)
 #endif
-- 
2.20.1.windows.1



___
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 __mingw_access() that works the same for all msvcr*/ucrt libs

[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, returns an error code.
>> _access() from msvcr110/120 returns an error code for nul file.
>>
>> Signed-off-by: Mateusz Brzostek 
> 
> Patch looks OK.

Thanks for review.

There is one problem with this patch -- in 32-bit mode #include  
implies #include  only if it is set at least -msse2. In 32-bit MSVC 
2015 it is included even with options /arch:IA32 or /arch:SSE (/arch:SSE2 is 
default for 32-bit).

So it should be added
#include 
to the patch (or we could fix mingw-w64 to load errno.h unconditionally when we 
#include ).

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 __mingw_access() that works the same for all msvcr*/ucrt libs

[Mateusz]

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, returns an error code.
>>>> _access() from msvcr110/120 returns an error code for nul file.
>>>>
>>>> Signed-off-by: Mateusz Brzostek 
>>>
>>> Patch looks OK.
>>
>> Thanks for review.
>>
>> There is one problem with this patch -- in 32-bit mode #include  
>> implies #include  only if it is set at least -msse2. In 32-bit MSVC 
>> 2015 it is included even with options /arch:IA32 or /arch:SSE (/arch:SSE2 is 
>> default for 32-bit).
>>
>> So it should be added
>> #include 
>> to the patch (or we could fix mingw-w64 to load errno.h unconditionally when 
>> we #include ).
>>
>>
> 
> Pushed to master.
> 
> GCC source code (either of GCC itself or libiberty) still needs patching
> for use of newer MSVCR*.DLL with an old version of mingw-w64, however.
 
Thanks for pushing!

This patch changed mingw-w64-crt/Makefile.am -- can we regenerate makefiles in 
mingw-w64-crt/ ?

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

[Mateusz]

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:
>>>>> Hello all,
>>>>>
>>>>> I'm currently adding (some basic) MinGW support to the D code which
>>>>> was recently merged into GCC9. The D runtime library already has full
>>>>> windows support, developed by DMD and LLVM D compiler devs. However,
>>>>> this needs MSVC runtime versions >= 120. So I'm now trying to add
>>>>> proper support for targeting newer MSVC libs to the GCC/MinGW ecosystem. 
>>>>>
>>>>> It turns out libgomp uses _ftime, but this symbol is only exposed for
>>>>> msvcrt.dll and I get linker errors for any other MSVC version.
>>>>> Therefore this patch adds the _ftime aliases to all msvcr .def
>>>>> files. According to timeb.h, there should be a _ftime symbol which
>>>>> maps to _ftime64 on _WIN64 and _ftime32 for anything else.
>>>>>
>>>>> This is my first MinGW patch, so please feel free to point out if
>>>>> there's anything wrong with the patch.
>>>>> BTW: How do you handle branches for the patches? The attached patch
>>>>> is against the v6.x branch.
>>>>>
>>>>> Best regards,
>>>>> Johannes
>>>> Ideally, the patch should be against master, and then cherry-picked to
>>>> v6.x. If there are conflicts, please prepare the patch for both branches.
>>>>
>>>> I'll let LH, Jacek and the others comment on the patch.
>>> On page 
>>> https://docs.microsoft.com/en-us/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?
>>
>>
>> Note that in this example, a header file is used and it's redirected in 
>> header file itself by a macro (like we do). The patch affects importlib 
>> entries. To test them you could for example declare the function yourself.
>>
> 
> Oh, I missed part of the thread and thought that importlib patch is still 
> needed besides having the define. I already tested that patch's behaviour 
> matches msvc and pushed it. Do we want it anyway? It improves compatibility 
> and in practice the macro (doing the right thing) will be used anyway.
> 
> 
> Sorry for the mess.

Hi Jacek,

Microsoft removed _ftime function (it was in msvcrt.dll) and moved to 
_ftime32/64 functions and _ftime macro. In trunk we follow this path. It is not 
needed extra patch for _ftime function (moreover, in 32-bit it is only 50% 
accurate -- _ftime could be _ftime64 and without header and check of 
_USE_32BIT_TIME_T it is impossible to tell).

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

[Mateusz]

W dniu 02.01.2019 o 16:32, JonY via Mingw-w64-public pisze:
> On 1/2/19 1:10 PM, Johannes Pfau wrote:
>> Hello all,
>>
>> I'm currently adding (some basic) MinGW support to the D code which
>> was recently merged into GCC9. The D runtime library already has full
>> windows support, developed by DMD and LLVM D compiler devs. However,
>> this needs MSVC runtime versions >= 120. So I'm now trying to add
>> proper support for targeting newer MSVC libs to the GCC/MinGW ecosystem. 
>>
>> It turns out libgomp uses _ftime, but this symbol is only exposed for
>> msvcrt.dll and I get linker errors for any other MSVC version.
>> Therefore this patch adds the _ftime aliases to all msvcr .def
>> files. According to timeb.h, there should be a _ftime symbol which
>> maps to _ftime64 on _WIN64 and _ftime32 for anything else.
>>
>> This is my first MinGW patch, so please feel free to point out if
>> there's anything wrong with the patch.
>> BTW: How do you handle branches for the patches? The attached patch
>> is against the v6.x branch.
>>
>> Best regards,
>> Johannes
> 
> 
> Ideally, the patch should be against master, and then cherry-picked to
> v6.x. If there are conflicts, please prepare the patch for both branches.
> 
> I'll let LH, Jacek and the others comment on the patch.

On page 
https://docs.microsoft.com/en-us/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:

$ m64- 82

Mateusz@Mateusz-i7 /f/t/ft
$ gcc -Wall -o f64.exe f.c

Mateusz@Mateusz-i7 /f/t/ft
$ f64
Seconds since midnight, January 1, 1970 (UTC): 1546446966
Milliseconds: 416
Minutes between UTC and local time: -60
Daylight savings time flag (1 means Daylight time is in effect): 0
The time is Wed Jan 02 17:36:06.416 2019

Mateusz@Mateusz-i7 /f/t/ft
$ m64-12- 82

Mateusz@Mateusz-i7 /f/t/ft
$ gcc -Wall -o f64-12.exe f.c

Mateusz@Mateusz-i7 /f/t/ft
$ f64-12
Seconds since midnight, January 1, 1970 (UTC): 1546447001
Milliseconds: 583
Minutes between UTC and local time: -60
Daylight savings time flag (1 means Daylight time is in effect): 0
The time is Wed Jan 02 17:36:41.583 2019

Mateusz@Mateusz-i7 /f/t/ft
$ m64-14- 82

Mateusz@Mateusz-i7 /f/t/ft
$ gcc -Wall -o f64-14.exe f.c
f.c: In function 'main':
f.c:28:64: warning: format '%d' expects argument of type 'int', but argument 2 
has type 'time_t' {aka 'long long int'} [-Wformat=]
printf( "Seconds since midnight, January 1, 1970 (UTC): %I64d\n",
    ^
%I64lld
time1);
~

Mateusz@Mateusz-i7 /f/t/ft
$ f64-14
Seconds since midnight, January 1, 1970 (UTC): 1546447049
Milliseconds: 498
Minutes between UTC and local time: -60
Daylight savings time flag (1 means Daylight time is in effect): 0
The time is Wed Jan  2 17:37:29.498 2019

Mateusz@Mateusz-i7 /f/t/ft
$ m32- 82

Mateusz@Mateusz-i7 /f/t/ft
$ gcc -Wall -o f32.exe f.c
f.c: In function 'main':
f.c:28:64: warning: format '%I64d' expects argument of type 'long long int', 
but argument 2 has type 'time_t' {aka 'long int'} [-Wformat=]
printf( "Seconds since midnight, January 1, 1970 (UTC): %I64d\n",
^
%ld
time1);
~
f.c:28:64: warning: format '%I64d' expects argument of type 'long long int', 
but argument 2 has type 'time_t' {aka 'long int'} [-Wformat=]
printf( "Seconds since midnight, January 1, 1970 (UTC): %I64d\n",
^
%ld
time1);
~

Mateusz@Mateusz-i7 /f/t/ft
$ f32
Seconds since midnight, January 1, 1970 (UTC): 1546447100
Milliseconds: 970
Minutes between UTC and local time: -60
Daylight savings time flag (1 means Daylight time is in effect): 0
The time is Wed Jan 02 17:38:20.970 2019

Mateusz@Mateusz-i7 /f/t/ft
$ m32-12- 82

Mateusz@Mateusz-i7 /f/t/ft
$ gcc -Wall -o f32-12.exe f.c
f.c: In function 'main':
f.c:28:64: warning: format '%I64d' expects argument of type 'long long int', 
but argument 2 has type 'time_t' {aka 'long int'} [-Wformat=]
printf( "Seconds since midnight, January 1, 1970 (UTC): %I64d\n",
^
%ld
time1);
~
f.c:28:64: warning: format '%I64d' expects argument of type 'long long int', 
but argument 2 has type 'time_t' {aka 'long int'} [-Wformat=]
printf( "S

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

[Mateusz]

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_WRAPPER=f:/msys/m64-83/bin/../libexec/gcc/x86_64-w64-mingw32/8.2.1/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: /home/ma/m/source/gcc-8/configure --host=x86_64-w64-mingw32 
--target=x86_64-w64-mingw32 --disable-nls --enable-languages=c,c++,objc,obj-c++ 
--with-gmp=/home/ma/m/build/for_target --with-mpfr=/home/ma/m/build/for_target 
--with-mpc=/home/ma/m/build/for_target --with-isl=/home/ma/m/build/for_target 
--enable-twoprocess --disable-libstdcxx-pch --disable-win32-registry 
--disable-shared --enable-fully-dynamic-string --prefix=/home/ma/m/target 
--with-sysroot=/home/ma/m/target
Thread model: win32
gcc version 8.2.1 20190125 (GCC)
GNU ld (GNU Binutils) 2.32.51.20190125

It is fixed for binary zero in *.s file, but there is no binary zero in my *.s 
file.

> And was the native compiler cross compiled from Linux?

Yes, Ubuntu 16.04, build script close to 
https://sourceforge.net/projects/mingw-w64-dgn/
Cross compiler was build without '--enable-experimental --enable-wildcard'.
I've added '--enable-experimental --enable-wildcard' options only to 
rebuild_target.sh
it is close to 
https://sourceforge.net/p/mingw-w64-dgn/code/HEAD/tree/trunk/rebuild_target.sh

> Try with a simple hello world in C (or C++) (without the #define)

All OK, without binary 0.

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.

[Mateusz]

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 ef53aaf4..42cee7b9 100644
> --- a/mingw-w64-headers/crt/sec_api/wchar_s.h
> +++ b/mingw-w64-headers/crt/sec_api/wchar_s.h
> @@ -266,41 +266,7 @@ extern "C" {
>__DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_0(errno_t,_wtmpnam_s,wchar_t,_DstBuf)
>  #endif /* _WSTDIO_S_DEFINED */
>  
> -#ifndef _WSTDLIB_S_DEFINED
> -#define _WSTDLIB_S_DEFINED
> -  _CRTIMP errno_t __cdecl _itow_s (int _Val,wchar_t *_DstBuf,size_t 
> _SizeInWords,int _Radix);
> -  
> __DEFINE_CPP_OVERLOAD_SECURE_FUNC_1_1(errno_t,_itow_s,int,_Val,wchar_t,_DstBuf,int,_Radix)
> -
> -  _CRTIMP errno_t __cdecl _ltow_s (long _Val,wchar_t *_DstBuf,size_t 
> _SizeInWords,int _Radix);
> -  
> __DEFINE_CPP_OVERLOAD_SECURE_FUNC_1_1(errno_t,_ltow_s,long,_Val,wchar_t,_DstBuf,int,_Radix)
> -
> -  _CRTIMP errno_t __cdecl _ultow_s (unsigned long _Val,wchar_t 
> *_DstBuf,size_t _SizeInWords,int _Radix);
> -  __DEFINE_CPP_OVERLOAD_SECURE_FUNC_1_1(errno_t,_ultow_s,unsigned 
> long,_Val,wchar_t,_DstBuf,int,_Radix)
> -
> -  _CRTIMP errno_t __cdecl _wgetenv_s(size_t *_ReturnSize,wchar_t 
> *_DstBuf,size_t _DstSizeInWords,const wchar_t *_VarName);
> -  
> __DEFINE_CPP_OVERLOAD_SECURE_FUNC_1_1(errno_t,_wgetenv_s,size_t*,_ReturnSize,wchar_t,_DstBuf,const
>  wchar_t*,_VarName)
> -
> -  _CRTIMP errno_t __cdecl _wdupenv_s(wchar_t **_Buffer,size_t 
> *_BufferSizeInWords,const wchar_t *_VarName);
> -  _CRTIMP errno_t __cdecl _i64tow_s(__int64 _Val,wchar_t *_DstBuf,size_t 
> _SizeInWords,int _Radix);
> -  _CRTIMP errno_t __cdecl _ui64tow_s(unsigned __int64 _Val,wchar_t 
> *_DstBuf,size_t _SizeInWords,int _Radix);
> -#endif
> -
>  #ifndef _POSIX_
> -#ifndef _WSTDLIBP_S_DEFINED
> -#define _WSTDLIBP_S_DEFINED
> -  _CRTIMP errno_t __cdecl _wmakepath_s(wchar_t *_PathResult,size_t 
> _SizeInWords,const wchar_t *_Drive,const wchar_t *_Dir,const wchar_t 
> *_Filename,const wchar_t *_Ext);
> -  
> __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_4(errno_t,_wmakepath_s,wchar_t,_PathResult,const
>  wchar_t*,_Drive,const wchar_t*,_Dir,const wchar_t*,_Filename,const 
> wchar_t*,_Ext)
> -
> -  _CRTIMP errno_t __cdecl _wputenv_s(const wchar_t *_Name,const wchar_t 
> *_Value);
> -
> -  _CRTIMP errno_t __cdecl _wsearchenv_s(const wchar_t *_Filename,const 
> wchar_t *_EnvVar,wchar_t *_ResultPath,size_t _SizeInWords);
> -  __DEFINE_CPP_OVERLOAD_SECURE_FUNC_2_0(errno_t,_wsearchenv_s,const 
> wchar_t*,_Filename,const wchar_t*,_EnvVar,wchar_t,_ResultPath)
> -
> -  _CRTIMP errno_t __cdecl _wsplitpath_s(const wchar_t *_FullPath,wchar_t 
> *_Drive,size_t _DriveSizeInWords,wchar_t *_Dir,size_t _DirSizeInWords,wchar_t 
> *_Filename,size_t _FilenameSizeInWords,wchar_t *_Ext,size_t _ExtSizeInWords);
> -  
> __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.

[Mateusz]

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 ef53aaf4..42cee7b9 100644
>>> --- a/mingw-w64-headers/crt/sec_api/wchar_s.h
>>> +++ b/mingw-w64-headers/crt/sec_api/wchar_s.h
>>> @@ -266,41 +266,7 @@ extern "C" {
>>>    __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_0(errno_t,_wtmpnam_s,wchar_t,_DstBuf)
>>>  #endif /* _WSTDIO_S_DEFINED */
>>>
>>> -#ifndef _WSTDLIB_S_DEFINED
>>> -#define _WSTDLIB_S_DEFINED
>>> -  _CRTIMP errno_t __cdecl _itow_s (int _Val,wchar_t *_DstBuf,size_t 
>>> _SizeInWords,int _Radix);
>>> -  
>>> __DEFINE_CPP_OVERLOAD_SECURE_FUNC_1_1(errno_t,_itow_s,int,_Val,wchar_t,_DstBuf,int,_Radix)
>>> -
>>> -  _CRTIMP errno_t __cdecl _ltow_s (long _Val,wchar_t *_DstBuf,size_t 
>>> _SizeInWords,int _Radix);
>>> -  
>>> __DEFINE_CPP_OVERLOAD_SECURE_FUNC_1_1(errno_t,_ltow_s,long,_Val,wchar_t,_DstBuf,int,_Radix)
>>> -
>>> -  _CRTIMP errno_t __cdecl _ultow_s (unsigned long _Val,wchar_t 
>>> *_DstBuf,size_t _SizeInWords,int _Radix);
>>> -  __DEFINE_CPP_OVERLOAD_SECURE_FUNC_1_1(errno_t,_ultow_s,unsigned 
>>> long,_Val,wchar_t,_DstBuf,int,_Radix)
>>> -
>>> -  _CRTIMP errno_t __cdecl _wgetenv_s(size_t *_ReturnSize,wchar_t 
>>> *_DstBuf,size_t _DstSizeInWords,const wchar_t *_VarName);
>>> -  
>>> __DEFINE_CPP_OVERLOAD_SECURE_FUNC_1_1(errno_t,_wgetenv_s,size_t*,_ReturnSize,wchar_t,_DstBuf,const
>>>  wchar_t*,_VarName)
>>> -
>>> -  _CRTIMP errno_t __cdecl _wdupenv_s(wchar_t **_Buffer,size_t 
>>> *_BufferSizeInWords,const wchar_t *_VarName);
>>> -  _CRTIMP errno_t __cdecl _i64tow_s(__int64 _Val,wchar_t *_DstBuf,size_t 
>>> _SizeInWords,int _Radix);
>>> -  _CRTIMP errno_t __cdecl _ui64tow_s(unsigned __int64 _Val,wchar_t 
>>> *_DstBuf,size_t _SizeInWords,int _Radix);
>>> -#endif
>>> -
>>>  #ifndef _POSIX_
>>> -#ifndef _WSTDLIBP_S_DEFINED
>>> -#define _WSTDLIBP_S_DEFINED
>>> -  _CRTIMP errno_t __cdecl _wmakepath_s(wchar_t *_PathResult,size_t 
>>> _SizeInWords,const wchar_t *_Drive,const wchar_t *_Dir,const wchar_t 
>>> *_Filename,const wchar_t *_Ext);
>>> -  
>>> __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_4(errno_t,_wmakepath_s,wchar_t,_PathResult,const
>>>  wchar_t*,_Drive,const wchar_t*,_Dir,const wchar_t*,_Filename,const 
>>> wchar_t*,_Ext)
>>> -
>>> -  _CRTIMP errno_t __cdecl _wputenv_s(const wchar_t *_Name,const wchar_t 
>>> *_Value);
>>> -
>>> -  _CRTIMP errno_t __cdecl _wsearchenv_s(const wchar_t *_Filename,const 
>>> wchar_t *_EnvVar,wchar_t *_ResultPath,size_t _SizeInWords);
>>> -  __DEFINE_CPP_OVERLOAD_SECURE_FUNC_2_0(errno_t,_wsearchenv_s,const 
>>> wchar_t*,_Filename,const wchar_t*,_EnvVar,wchar_t,_ResultPath)
>>> -
>>> -  _CRTIMP errno_t __cdecl _wsplitpath_s(const wchar_t *_FullPath,wchar_t 
>>> *_Drive,size_t _DriveSizeInWords,wchar_t *_Dir,size_t 
>>> _DirSizeInWords,wchar_t *_Filename,size_t _FilenameSizeInWords,wchar_t 
>>> *_Ext,size_t _ExtSizeInWords);
>>> -  
>>> __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')?
> 
> Well, the intentional change removed all the content of the ifdef, so there's 
> little point in keeping an empty #ifndef _POSIX_/#endif.

Yes, now I see this. Thanks for clarification.

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] --enable-experimental breaks as

[Mateusz]

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. Using that compiler to compile a 
> native Windows compiler (what do you really call that? Crossed compiler? 
> Hosted?) 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 printf128)?

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] --enable-experimental breaks as

[Mateusz]

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. Using that compiler to compile a 
>>> native Windows compiler (what do you really call that? Crossed compiler? 
>>> Hosted?) 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 printf128)?
>>
> 
> "--enable-experimental --enable-wildcard"
> Which enables all of the experimental options, I guess.

OK, I've compiled native gcc (one 64-bit lib) with mingw-w64-crt options:
$M_SOURCE/mingw-w64-v$VER_MINGW64/mingw-w64-crt/configure \
  --host=$MINGW_TRIPLE \
  --prefix=$M_TARGET/$MINGW_TRIPLE $MINGW_LIB --enable-experimental 
--enable-wildcard

And with this native gcc (64-bit):
$ cat t.c
#define __USE_MINGW_ANSI_STDIO
#include 

int main()
{
  __int128 t = 0;
  t -= 1;
  printf("hello %I128u\n", t);
  return 0;
}
Mateusz@Mateusz-i7 /f/t/e
$ gcc -Wall -O2 -save-temps -o t.exe t.c
t.c: In function 'main':
t.c:8:10: warning: format '%u' expects argument of type 'unsigned int', but 
argument 2 has type '__int128' [-Wformat=]
   printf("hello %I128u\n", t);
  ^~~~  ~

Mateusz@Mateusz-i7 /f/t/e
$ t
hello 340282366920938463463374607431768211455

Mateusz@Mateusz-i7 /f/t/e
$ cat t.s
.file   "t.c"
.text
.section .rdata,"dr"
.LC0:
.ascii "hello %I128u\12\0"
.text
.p2align 4,,15
.defprintf.constprop.0; .scl3;  .type   32; .endef
.seh_proc   printf.constprop.0
printf.constprop.0:
pushq   %rbx
.seh_pushreg%rbx
subq$48, %rsp
.seh_stackalloc 48
.seh_endprologue
movl$1, %ecx
leaq72(%rsp), %rbx
movq%rdx, 72(%rsp)
movq%r8, 80(%rsp)
movq%r9, 88(%rsp)
movq%rbx, 40(%rsp)
call*__imp___acrt_iob_func(%rip)
movq%rbx, %r8
leaq.LC0(%rip), %rdx
movq%rax, %rcx
call__mingw_vfprintf
addq$48, %rsp
popq%rbx
ret
.seh_endproc
.def__main; .scl2;  .type   32; .endef
.section.text.startup,"x"
.p2align 4,,15
.globl  main
.defmain;   .scl2;  .type   32; .endef
.seh_proc   main
main:
subq$56, %rsp
.seh_stackalloc 56
.seh_endprologue
call__main
leaq32(%rsp), %rdx
leaq.LC0(%rip), %rcx
movq$-1, 32(%rsp)
movq$-1, 40(%rsp)
callprintf.constprop.0
xorl%eax, %eax
addq$56, %rsp
ret
    .seh_endproc
.ident  "GCC: (GNU) 8.2.1 20190125"
.def__mingw_vfprintf;   .scl2;  .type   32; .endef

For me it looks OK.

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] crt/websocket: move websocket to lib-common

[Mateusz]

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 < 
>> /home/ma/m/source/mingw-w64-v7/mingw-w64-crt/lib-common/mincore.mri
>> x86_64-w64-mingw32-ar: libwebsocket.a: No such file or directory
>> Makefile:69387: recipe for target 'lib64/libmincore.a' failed
>> make[1]: *** [lib64/libmincore.a] Error 9
>> *
>>
>>
> 
> Sorry for the inconvenience. Please test the attached patch. (You might
> need to invoke 'autoreconf' after applying it.)

Patch is working, thanks!

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] crt/websocket: move websocket to lib-common

[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 < 
/home/ma/m/source/mingw-w64-v7/mingw-w64-crt/lib-common/mincore.mri
x86_64-w64-mingw32-ar: libwebsocket.a: No such file or directory
Makefile:69387: 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-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> 




___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mateusz]

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 program I am converting needs to read a large number of binary files
containing a mixture of blocksizes, flags, int8, int16, int32 and text.  With
the normal gnu system the routines using getc to read the data are very
efficient.  However the mingw version of getc drops 'Carriage Return' (Hex:
0A) symbols and returns the next byte in the file.  As a result the following
block of data is read from the wrong position in the file.

Looking at stdio.h,  it looks as if mingw uses a getc routine instead of the
normal macro.  Is this correct - is it for example using a Microsoft getc
routine which drops '0D' from '0D''0A'?   More importantly, is there a way to
prevent the '0D' characters being dropped?

I could of course use the C read routine to read a buffer and generate my own
getc macro - but my coding is never optimal so if there is a better solution I
would prefer to use it.

Thanks,

David Webb.





___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



___
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] intrin-impl.h: Added __popcnt16, __popcnt, and __popcnt64.

[Mateusz Mikuła]

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 try the attached patch? It should existing failures on
> clang. It also changes our generic guard to take __has_builtin into
> account, so this should prevent problems in the future, if clang
> introduces more builtins, but I don't have clang setup to test it.
>
> Thanks,
> Jacek
>
> On 09.02.2017 01:35, Mateusz Mikuła wrote:
> > You are right David and now I remember the thing about ms-extensions.
> > Declspec was part of those extensions and enabling it by default caused
> > errors with specific code so declspec was changed to general attribute
> > instead.
> > Since I have clang git build (trying to upstream some patches used by
> > MSYS2), I tried it also:
> > https://paste.ubuntu.com/23957478/
> >
> > While for 3.9.x Clang `-fms-extensions` didn't hurt, master branch
> require
> > some corrections but it is another issue.
> >
> >
> > 2017-02-09 0:15 GMT+01:00 David Grayson <davidegray...@gmail.com>:
> >
> >> I can confirm that MSYS2's x86_64 clang++ compiler does not support
> >> __popcnt but does support __builtin_popcount.  I looked into it a
> >> little bit, and found out that the clang commit that adds the __popcnt
> >> builtins is very recent (September 2016).  I seems like it has not
> >> made it into a release yet.
> >>
> >> Here is the commit:
> >>
> >> https://github.com/llvm-mirror/clang/commit/
> 5eb95c4c284486351e3ed0fdad011a
> >> cf41540c8b
> >>
> >> The source code archive that Alexey used to build the MSYS2 clang++
> >> does not have the changes from that commit in it:
> >>
> >> http://repo.msys2.org/mingw/sources/mingw-w64-clang-3.9.1-3.src.tar.gz
> >>
> >> I don't intend to submit any more patches for this issue.  Jacek has
> >> already committed my patch to mingw-w64 (thanks!).  Once the new
> >> version of clang comes out and people start using it there should not
> >> be any problems.  If any clang users are itching to use __popcnt
> >> before the new version of clang comes out, they can easily remove the
> >> #if I put in intrin-impl.h.  They could also use __has_builtin in
> >> intrin-impl.h to detect whether clang has the builtin or not.
> >>
> >> Mateusz, the "CodeGen" folder in clang is not just used for MSVC libs,
> >> it has tons of general-purpose code for generating LLVM code from
> >> C/C++ code.
> >>
> >> --David Grayson
> >>
> >> On Wed, Feb 8, 2017 at 1:24 PM, Mateusz <mati...@gmail.com> wrote:
> >>> Opps, gmail put output into quote. Improved version:
> >>> $ clang++ popcnt.cc -std=c++14 -fms-extensions
> >>> 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(ui[i]);
> >>>^
> >>> popcnt.cc:26:28: error: use of undeclared identifier '__popcnt64'; did
> >> you
> >>> mean '_popcnt64'?
> >>> 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 22:22 GMT+01:00 Mateusz <mati...@gmail.com>:
> >>>
> >>>> I think ms-extensions was made default option for mingw and msvc clang
> >> and
> >>>> codegen is used only for creating msvc libs. Here is Clang output
> >> anyway:
> >>>> $ clang++ popcnt.cc -std=c++14 -fms-extensions
> >>>> 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(ui[i]);
> >>>>

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

[Mateusz Mikuła]

 > ./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 Nader :

> On Sat, Feb 25, 2017, JonY wrote:
> > On 02/25/2017 12:54 AM, Robert May wrote:
> > > --build alias - -host -alias --target -alias
> >
> > How did you even get that?
>
> --{build,host,target}-alias are valid configure options as far as I
> remmeber. However noone ever uses them. And here the copy-paste went
> completely wrong and inserted extra spaces at random places. That said,
> I don't know of any place that tells to use these options and no other
> one.
>
> --
> Adrien Nader
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
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] intrin-impl.h: Added __popcnt16, __popcnt, and __popcnt64.

[Mateusz Mikuła]

Hello Jacek,

> Thanks for testing. Sadly, I found that the patch wasn't correct. Could
you please try the attached one?

New patch is also fine.

> Thanks, but I'd be more interested in documentation how to get cross
compilation setup with clang + mingw-w64. I did one in the past, but it
required 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 wrote:
> > Hello Jacek,
> >
> > With this patch clang builds example code from first message with and
> > without `-fms-extensions`.
>
> Thanks for testing. Sadly, I found that the patch wasn't correct. Could
> you please try the attached one?
>
> > I can provide prebuild clang-svn pacakge for msys2.
>
> Thanks, but I'd be more interested in documentation how to get cross
> compilation setup with clang + mingw-w64. I did one in the past, but it
> required patching clang and llvm and working around misc problems I
> don't quite remember in details.
>
> Jacek
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
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] Use LPCVOID instead of 'const LPVOID' for VerQueryValue

[Mateusz Mikuła]

 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: Mingw-w64-public
From: Nightstrike
> Do you know what content type you attached as?  We have to explicitly
> allow each type.  The current list is:
>
> application/pgp-signature
> multipart/mixed
> multipart/alternative
> multipart/signed
> text/plain
> text/x-patch
>
> If the content type is left unspecified, then the attachment is
> deleted.  I can add anything you like.
>
> On Sun, Mar 19, 2017 at 10:30 PM, David Grayson  
> wrote:
>> NightStrike,
>>
>> The mailing list swallowed the patch in the message I sent on March 16th.
>> I can see in GMail that I did have a patch attached to my message, but no
>> attachment is visible in the archive here:
>>
>> https://sourceforge.net/p/mingw-w64/mailman/message/35729302/
>>
>> --David Grayson
>>
>> On Sun, Mar 19, 2017 at 7:03 PM, NightStrike  wrote:
>>
>>> On Mar 16, 2017 1:40 PM, "Liu Hao"  wrote:
>>>
>>> On 2017/3/17 0:51, David Grayson wrote:
 I was trying to compile Qt and I ran into an error because Qt is
 passing a const pointer to the first argument of VerQueryValue, which
 is not properly marked as const in the mingw-w64 header files.  This
 patch fixes that.
>>> Please send the patch both inline and as an attachment, since SF mailing
>>> lists swallow attachments frequently.
>>>
>>>
>>> It shouldn't. If it does, tell me and I'll address it. I believe I already
>>> fixed one issue you brought up a while ago. I haven't seen any since.
>>> 
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> Mingw-w64-public mailing list
>>> Mingw-w64-public@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
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] Use LPCVOID instead of 'const LPVOID' for VerQueryValue

[Mateusz Mikuła]

 I checked it with `file --mime-type something.patch` in MSYS2 shell;
something.patch was generated by git.



-- Original Message --
Subject: Re: [Mingw-w64-public] [PATCH] Use LPCVOID instead of 'const
LPVOID' for VerQueryValue
Date: Mon, 20 Mar 2017 23:15:21 +0800
To: Mingw-w64-public
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 
> file doesn't have any MIME type information stored with it.
>



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
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] Use LPCVOID instead of 'const LPVOID' for VerQueryValue

[Mateusz Mikuła]

 Sorry for the delay but I spent almost whole day in college.

Thank you for adding it, here comes small patch to test it.


-- Original Message --
Subject: Re: [Mingw-w64-public] [PATCH] Use LPCVOID instead of 'const
LPVOID' for VerQueryValue
Date: Mon, 20 Mar 2017 21:19:05 -0500
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/x-diff to the list.  Give it a shot.
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

From 180bffbe07c0c43e7f103debc8d8d777cb027096 Mon Sep 17 00:00:00 2001
From: Mateusz Mikula <mati...@gmail.com>
Date: Thu, 2 Feb 2017 12:21:45 +0100
Subject: [PATCH 3/9] fix libclang name for mingw

---
 tools/libclang/CMakeLists.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libclang/CMakeLists.txt b/tools/libclang/CMakeLists.txt
index 477e53dd15..dc2e3538fa 100644
--- a/tools/libclang/CMakeLists.txt
+++ b/tools/libclang/CMakeLists.txt
@@ -78,7 +78,7 @@ if((NOT LLVM_ENABLE_PIC OR LIBCLANG_BUILD_STATIC) AND (NOT 
MSVC))
   set(ENABLE_STATIC STATIC)
 endif()
 
-if(WIN32)
+if(MSVC)
   set(output_name "libclang")
 else()
   set(output_name "clang")
-- 
2.12.0



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public