Re: [Mingw-w64-public] Building mingw-w64 and include paths

[David Wohlferd]

Let's try this again.  This time the proposed patch is attached which 
may help.  For 'ease of review,' this patch does not include the 
'generated' makefile.in files.


The problem I am trying to fix is that when building mingw-w64, the 
compiler will often use headers from the Tools Directories instead of 
the mingw-w64 source directory.  This is due to the fact that while some 
mingw-w64 SourceDir paths are passed to the compiler, several are not.  
This causes 3 problems:


1) In order for me to make and test changes to intrin.h (for example), I 
have to remember to copy it to ToolsDir after every change.


2) Users who want to build mingw-w64 have to *know* that they need to 
copy certain files (from a variety of locations) to their ToolsDir 
before trying to build mingw-w64.  While the build may succeed without 
this, the results will be uncertain.


3) Header files that are in ToolsDir are usually treated as 'System 
Headers' (https://gcc.gnu.org/onlinedocs/cpp/System-Headers.html). Among 
other things, this means that warnings in these files tend to get 
suppressed rather than found and fixed.


While there are multiple ways to fix this, I have chosen to add the 
necessary paths to Makefile.am.  I also needed to duplicate 2 files 
(_mingw_directx.h _mingw_ddk.h) into appropriately named directories so 
that _mingw.h's #include "sdks/_mingw_directx.h" would work (Is there a 
better way to resolve this?  I can't just generate them into the sdks 
directory, since 'distribution' needs them where they are.).


Kai has suggested that we modify the configure script to copy all the 
header files to a single directory (a la 'make install') and use that 
single directory instead of the 9 above.  My scripting skills are not 
sufficient to do this.  If this is how we want to proceed, someone else 
will need to write it.


dw
diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 886fcf0..67ac481 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -11,6 +11,9 @@
 
 #AUTOMAKE_OPTIONS = color-tests
 
+extra_include2=-I$(top_srcdir)/../mingw-w64-headers/include -I$(top_srcdir)/../mingw-w64-headers/crt -I../mingw-w64-headers/crt
+extra_includeDX=-I$(top_srcdir)/../mingw-w64-headers/direct-x/include
+
 if WITHSYSROOT
   sysincludes=-I@TARGET_SYSTEM_ROOT@/include
   withsys=--with-sysroot=@TARGET_SYSTEM_ROOT@
@@ -19,7 +22,7 @@ else
   withsys=
 endif
 
-AM_CPPFLAGS=-D_CRTBLD $(sysincludes)
+AM_CPPFLAGS=-D_CRTBLD $(extra_include2) $(sysincludes)
 AM_CFLAGS=-pipe -std=gnu99 -D_WIN32_WINNT=0x0f00 @ADD_C_CXX_WARNING_FLAGS@ @ADD_C_ONLY_WARNING_FLAGS@
 AM_CXXFLAGS=@ADD_C_CXX_WARNING_FLAGS@ @ADD_CXX_ONLY_WARNING_FLAGS@
 CPPFLAGSARM32=-mfpu=vfp
@@ -422,7 +425,7 @@ else
 crt32_DATA =
 endif
 
-COMPILE32=$(COMPILE) $(CPPFLAGS32) $(extra_include) -D_SYSCRT=1 -DCRTDLL=1
+COMPILE32=$(COMPILE) $(CPPFLAGS32) $(extra_include) $(extra_include2) -D_SYSCRT=1 -DCRTDLL=1
 lib32/crt1.o: crt/crtexe.c
 	$(COMPILE32) -c $< -o $@ -D__CRTDLL__ -U__MSVCRT__
 lib32/crt2.o: crt/crtexe.c
@@ -463,111 +466,111 @@ if !W32API
 lib32_LIBRARIES += lib32/libmsvcrt.a
 lib32_libmsvcrt_a_SOURCES = $(src_msvcrt32) lib32/msvcrt.def.in
 lib32_libmsvcrt_a_AR = $(DTDEF32) lib32/msvcrt.def && $(AR) $(ARFLAGS)
-lib32_libmsvcrt_a_CPPFLAGS=$(CPPFLAGS32) -D__LIBMSVCRT__ $(extra_include) $(sysincludes)
+lib32_libmsvcrt_a_CPPFLAGS=$(CPPFLAGS32) -D__LIBMSVCRT__ $(extra_include) $(extra_include2) $(sysincludes)
 EXTRA_lib32_libmsvcrt_a_DEPENDENCIES=lib32/msvcrt.def
 endif
 
 lib32_LIBRARIES += lib32/libshell32.a
 lib32_libshell32_a_SOURCES = $(src_libshell32)
 lib32_libshell32_a_AR = $(DTLIB32) && $(AR) $(ARFLAGS)
-lib32_libshell32_a_CPPFLAGS=$(CPPFLAGS32) $(sysincludes)
+lib32_libshell32_a_CPPFLAGS=$(CPPFLAGS32) $(extra_include2) $(sysincludes)
 
 lib32_LIBRARIES += lib32/libdinput.a
 lib32_libdinput_a_SOURCES = $(src_libdinput)
 lib32_libdinput_a_AR = $(DTLIB32) && $(AR) $(ARFLAGS)
-lib32_libdinput_a_CPPFLAGS=$(CPPFLAGS32) $(sysincludes)
+lib32_libdinput_a_CPPFLAGS=$(CPPFLAGS32) $(extra_include2) $(sysincludes)
 
 lib32_LIBRARIES += lib32/libdinput8.a
 lib32_libdinput8_a_SOURCES = $(src_libdinput8)
 lib32_libdinput8_a_AR = $(DTLIB32) && $(AR) $(ARFLAGS)
-lib32_libdinput8_a_CPPFLAGS=$(CPPFLAGS32) $(sysincludes)
+lib32_libdinput8_a_CPPFLAGS=$(CPPFLAGS32) $(extra_include2) $(sysincludes)
 
 lib32_LIBRARIES += lib32/libdmoguids.a
 lib32_libdmoguids_a_SOURCES = $(src_libdmoguids)
-lib32_libdmoguids_a_CPPFLAGS=$(CPPFLAGS32) $(sysincludes)
+lib32_libdmoguids_a_CPPFLAGS=$(CPPFLAGS32) $(extra_include2) $(sysincludes)
 
 lib32_LIBRARIES += lib32/libdxerr8.a
 lib32_libdxerr8_a_SOURCES = $(src_libdxerr8)
-lib32_libdxerr8_a_CPPFLAGS=$(CPPFLAGS32) $(sysincludes)
+lib32_libdxerr8_a_CPPFLAGS=$(CPPFLAGS32) $(extra_include2) $(sysincludes)
 
 lib32_LIBRARIES += lib32/libdxerr9.a
 lib32_libdxerr9_a_SOURCES = $(src_libdxerr9)
-lib32_libdxerr9_a_CPPFLAGS=$(CPPFLAGS32) $(sysincludes)
+lib32_libdxerr9_a_CPPFLAGS=$(CPPFLAGS32) $(extra_include2) 

Re: [Mingw-w64-public] [PATCH] Change check for _WIN64 to check for __x86_64__ in assembler

[Corinna Vinschen]

Hi Kai,

On Aug 22 17:34, Kai Tietz wrote:
> Hi Corinna,
> 
> 2016-08-22 17:23 GMT+02:00 Corinna Vinschen :
> > Lots of assembler files in the math subdir check for _WIN64 when they
> > actually mean to check for the x86_64 target CPU, rather than the target
> > OS.  This patch fixes it.  This helps Cygwin in the first place because
> > __x86_64__ is defined in both toolchains, while _WIN64 is only defined
> > on Mingw-w64 for x86_64.
> >
> >
> > Is that ok to apply?
> 
> Patch is ok. Please apply.

Done, thanks!

> PS: Does this mean you use these math functions on cywin?

Not all of them but, yes, Cygwin does.  The problem was that newlib only
provided float and double, but no long double, so Cygwin is using the
long double functions from Mingw-w64 and a few others for simplicity.

Btw., we had to apply two Cygwin-specific patches to the math functions.
I don't know if that's something we should share, but please have a
look.  I'm curious if that's stuff which should go upstream one way or
the other:

https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=929be80
https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=71df3bf


Thanks,
Corinna

--
___
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] Align thread entry point stack

[Kai Tietz]

Hello Aleksey,

2016-08-22 13:52 GMT+02:00 Aleksey Vasenev :
> __attribute__((aligned)) don't work for stack variables in threads created
> with _beginthreadex without alignment.
>
> Signed-off-by: Aleksey Vasenev 
> ---
> send it again
> github: https://github.com/Ratio2/mingw-w64/tree/align
> fix crash: ffmpeg -f lavfi -i testsrc -vcodec libvpx -threads 2 -f null -
> problem discuss: https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=2236
>
> _beginthreadex does not align the stack on 16-byte boundary as expected
> by gcc.
>
> On x86 targets, the force_align_arg_pointer attribute may be applied to
> individual function definitions, generating an alternate prologue and
> epilogue that realigns the run-time stack if necessary. This supports
> mixing legacy codes that run with a 4-byte aligned stack with modern
> codes that keep a 16-byte stack for SSE compatibility.
> https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html
>
>  mingw-w64-libraries/winpthreads/src/thread.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/mingw-w64-libraries/winpthreads/src/thread.c 
> b/mingw-w64-libraries/winpthreads/src/thread.c
> index 565ea48..c771daf 100644
> --- a/mingw-w64-libraries/winpthreads/src/thread.c
> +++ b/mingw-w64-libraries/winpthreads/src/thread.c
> @@ -1454,6 +1454,9 @@ pthread_setcanceltype (int type, int *oldtype)
>return 0;
>  }
>
> +#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 2)
> +__attribute__((force_align_arg_pointer))
> +#endif
>  int
>  pthread_create_wrapper (void *args)
>  {
> --
> 2.9.1

I guess you have tested your suggested patch?  Over all it looks
reasonable to me.

Regards,
Kai

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

Re: [Mingw-w64-public] GDB release canditate 7.11.90 build failure for mingw-w64

[Kai Tietz]

2016-08-22 17:40 GMT+02:00 Pierre Free Pascal :
>
>
>> -Message d'origine-
>> De : Kai Tietz [mailto:ktiet...@googlemail.com]
>> Envoyé : lundi 22 août 2016 16:57
>> À : mingw-w64-public@lists.sourceforge.net
>> Objet : Re: [Mingw-w64-public] GDB release canditate 7.11.90 build
>> failure for mingw-w64
>>
>> Hello Pierre,
>
>   Hello Kai,
>
>> 2016-08-22 16:27 GMT+02:00 Pierre Free Pascal :
>> > make[1] : on quitte le répertoire «
>> > /usr/local/src/gdb-releases/build-gdb-7.11.90/gdb »
>> >
>> > make: *** [Makefile:9169: all-gdb] Error 2
>>
>> I am just interested where you got this dlfnc.h header from.  In our
>> headers we don't provide it.
>
>   I thought that i twas just installed by cygwin setup...
> But it appears I was wrong:
> $ cygcheck -f /usr/i686-w64-mingw32/sys-root/mingw/include/dlfcn.h
> returns nothing, meaning this file is not installed by cygwin setup.
>
> $ ls -aldtr include/dlfcn.h
> -rwxrwx---+ 1 Pierre None 1476  7 août   2013 include/dlfcn.h
>
> Which reveals that I probably installed manually a long while ago...
>
> First lines are:
> /*
>  * dlfcn-win32
>  * Copyright (c) 2007 Ramiro Polla
>  *
>  * This library is free software; you can redistribute it and/or
>
> I honestly don't remember when and why I installed this...
>
> Sorry for the noise!

I just asked Ramiro for it.  He told me that maintainership of this
project has changed to Timothy Gu.

>
>> And yes, it is a bug to provide a C API without such guards, if the
>> header should be useful in C++ too.
>
>   Do you know this dlfcn-win32 package?
> In fact it is on github...
> and the current header does have the missing guards!
> https://github.com/dlfcn-win32/dlfcn-win32/blob/master/dlfcn.h
>
> It was added in January 2014!
>
> https://github.com/dlfcn-win32/dlfcn-win32/commit/53c31d96e15eaf310dd2f82ff0fc0e1e9b6cb0bf#diff-46a1393ac45c16a13d328c53675207c9
>
> Updating to newest header is enough to fix my issue.

Yes, Timothy fixed it for C++.  https://github.com/dlfcn-win32/dlfcn-win32

> Thanks for the reply,
> and sorry again for the noise!
>
> Pierre

Kai

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

[Mingw-w64-public] [PATCH] Align thread entry point stack

[Aleksey Vasenev]

__attribute__((aligned)) don't work for stack variables in threads created
with _beginthreadex without alignment.

Signed-off-by: Aleksey Vasenev 
---
send it again
github: https://github.com/Ratio2/mingw-w64/tree/align
fix crash: ffmpeg -f lavfi -i testsrc -vcodec libvpx -threads 2 -f null -
problem discuss: https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=2236

_beginthreadex does not align the stack on 16-byte boundary as expected
by gcc.

On x86 targets, the force_align_arg_pointer attribute may be applied to
individual function definitions, generating an alternate prologue and
epilogue that realigns the run-time stack if necessary. This supports
mixing legacy codes that run with a 4-byte aligned stack with modern
codes that keep a 16-byte stack for SSE compatibility.
https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html

 mingw-w64-libraries/winpthreads/src/thread.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mingw-w64-libraries/winpthreads/src/thread.c 
b/mingw-w64-libraries/winpthreads/src/thread.c
index 565ea48..c771daf 100644
--- a/mingw-w64-libraries/winpthreads/src/thread.c
+++ b/mingw-w64-libraries/winpthreads/src/thread.c
@@ -1454,6 +1454,9 @@ pthread_setcanceltype (int type, int *oldtype)
   return 0;
 }
 
+#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 2)
+__attribute__((force_align_arg_pointer))
+#endif
 int
 pthread_create_wrapper (void *args)
 {
-- 
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] Change check for _WIN64 to check for __x86_64__ in assembler

[Kai Tietz]

Hi Corinna,

2016-08-22 17:23 GMT+02:00 Corinna Vinschen :
> Hi folks,
>
>
> Lots of assembler files in the math subdir check for _WIN64 when they
> actually mean to check for the x86_64 target CPU, rather than the target
> OS.  This patch fixes it.  This helps Cygwin in the first place because
> __x86_64__ is defined in both toolchains, while _WIN64 is only defined
> on Mingw-w64 for x86_64.
>
>
> Is that ok to apply?
>
>
> Thanks,
> Corinna

Patch is ok. Please apply.

Thanks,
Kai

PS: Does this mean you use these math functions on cywin?

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

[Mingw-w64-public] [PATCH] Change check for _WIN64 to check for __x86_64__ in assembler

[Corinna Vinschen]

Hi folks,


Lots of assembler files in the math subdir check for _WIN64 when they
actually mean to check for the x86_64 target CPU, rather than the target
OS.  This patch fixes it.  This helps Cygwin in the first place because
__x86_64__ is defined in both toolchains, while _WIN64 is only defined
on Mingw-w64 for x86_64.


Is that ok to apply?


Thanks,
Corinna
From 40f03bb9ebc8c43235871329466b1b8a5794a27b Mon Sep 17 00:00:00 2001
From: Corinna Vinschen 
Date: Mon, 22 Aug 2016 14:30:39 +0200
Subject: [PATCH] Change check for _WIN64 to check for __x86_64__ in assembler
 files

Lots of assembler files in the math subdir check for _WIN64 when they
actually mean to check for the x86_64 target CPU, rather than the target
OS.  This patch fixes it.  This helps Cygwin in the first place because
__x86_64__ is defined in both toolchains, while _WIN64 is only defined
on Mingw-w64 for x86_64.

Signed-off-by: Corinna Vinschen 
---
 mingw-w64-crt/math/_chgsignl.S | 2 +-
 mingw-w64-crt/math/ceil.S  | 2 +-
 mingw-w64-crt/math/ceilf.S | 2 +-
 mingw-w64-crt/math/ceill.S | 2 +-
 mingw-w64-crt/math/cephes_mconf.h  | 2 +-
 mingw-w64-crt/math/copysignl.S | 2 +-
 mingw-w64-crt/math/cosl_internal.S | 4 ++--
 mingw-w64-crt/math/exp.def.h   | 2 +-
 mingw-w64-crt/math/exp2.S  | 4 ++--
 mingw-w64-crt/math/exp2f.S | 4 ++--
 mingw-w64-crt/math/exp2l.S | 4 ++--
 mingw-w64-crt/math/floor.S | 2 +-
 mingw-w64-crt/math/floorf.S| 2 +-
 mingw-w64-crt/math/floorl.S| 2 +-
 mingw-w64-crt/math/fma.S   | 2 +-
 mingw-w64-crt/math/fmaf.S  | 2 +-
 mingw-w64-crt/math/frexpl.S| 4 ++--
 mingw-w64-crt/math/ilogb.S | 4 ++--
 mingw-w64-crt/math/ilogbf.S| 4 ++--
 mingw-w64-crt/math/ilogbl.S| 4 ++--
 mingw-w64-crt/math/internal_logl.S | 4 ++--
 mingw-w64-crt/math/log10l.S| 6 +++---
 mingw-w64-crt/math/log1p.S | 4 ++--
 mingw-w64-crt/math/log1pf.S| 4 ++--
 mingw-w64-crt/math/log1pl.S| 4 ++--
 mingw-w64-crt/math/log2.S  | 4 ++--
 mingw-w64-crt/math/log2f.S | 4 ++--
 mingw-w64-crt/math/log2l.S | 4 ++--
 mingw-w64-crt/math/nearbyint.S | 2 +-
 mingw-w64-crt/math/nearbyintf.S| 2 +-
 mingw-w64-crt/math/nearbyintl.S| 2 +-
 mingw-w64-crt/math/pow.def.h   | 2 +-
 mingw-w64-crt/math/remainder.S | 4 ++--
 mingw-w64-crt/math/remainderf.S| 4 ++--
 mingw-w64-crt/math/remainderl.S| 4 ++--
 mingw-w64-crt/math/remquo.S| 4 ++--
 mingw-w64-crt/math/remquof.S   | 4 ++--
 mingw-w64-crt/math/remquol.S   | 4 ++--
 mingw-w64-crt/math/scalbn.S| 4 ++--
 mingw-w64-crt/math/scalbnf.S   | 4 ++--
 mingw-w64-crt/math/scalbnl.S   | 4 ++--
 mingw-w64-crt/math/sinl_internal.S | 4 ++--
 mingw-w64-crt/math/tanl.S  | 4 ++--
 mingw-w64-crt/math/trunc.S | 2 +-
 mingw-w64-crt/math/truncf.S| 2 +-
 45 files changed, 73 insertions(+), 73 deletions(-)

diff --git a/mingw-w64-crt/math/_chgsignl.S b/mingw-w64-crt/math/_chgsignl.S
index 65c4cee..3876465 100644
--- a/mingw-w64-crt/math/_chgsignl.S
+++ b/mingw-w64-crt/math/_chgsignl.S
@@ -20,7 +20,7 @@
 
.file   "_chgignl.S"
.text
-#ifdef _WIN64
+#ifdef __x86_64__
.align 8
 #else
.align 4
diff --git a/mingw-w64-crt/math/ceil.S b/mingw-w64-crt/math/ceil.S
index 2ce21dd..636df1e 100644
--- a/mingw-w64-crt/math/ceil.S
+++ b/mingw-w64-crt/math/ceil.S
@@ -10,7 +10,7 @@
.align 4
.globl __MINGW_USYMBOL(ceil)
.def__MINGW_USYMBOL(ceil);  .scl2;  .type   32; .endef
-#ifdef _WIN64
+#ifdef __x86_64__
.seh_proc   __MINGW_USYMBOL(ceil)
 #endif
 
diff --git a/mingw-w64-crt/math/ceilf.S b/mingw-w64-crt/math/ceilf.S
index c1202e0..605c7bf 100644
--- a/mingw-w64-crt/math/ceilf.S
+++ b/mingw-w64-crt/math/ceilf.S
@@ -10,7 +10,7 @@
.align 4
.globl __MINGW_USYMBOL(ceilf)
.def__MINGW_USYMBOL(ceilf); .scl2;  .type   32; .endef
-#ifdef _WIN64
+#ifdef __x86_64__
.seh_proc   __MINGW_USYMBOL(ceilf)
 #endif
 
diff --git a/mingw-w64-crt/math/ceill.S b/mingw-w64-crt/math/ceill.S
index 9804004..61d6199 100644
--- a/mingw-w64-crt/math/ceill.S
+++ b/mingw-w64-crt/math/ceill.S
@@ -7,7 +7,7 @@
 
.file   "ceill.S"
.text
-#ifdef _WIN64
+#ifdef __x86_64__
.align 8
 #else
.align 4
diff --git a/mingw-w64-crt/math/cephes_mconf.h 
b/mingw-w64-crt/math/cephes_mconf.h
index 25ab33e..832fae0 100644
--- a/mingw-w64-crt/math/cephes_mconf.h
+++ b/mingw-w64-crt/math/cephes_mconf.h
@@ -11,7 +11,7 @@
 #define VOLATILE
 #define mtherr(fname, code)
 #define XPD 0,
-#ifdef _WIN64
+#ifdef __x86_64__
 #define XPD_SHORT 0, 0,
 #define XPD_LONG 0,
 #else
diff --git a/mingw-w64-crt/math/copysignl.S b/mingw-w64-crt/math/copysignl.S
index 0becf53..1ee4a45 100644
--- a/mingw-w64-crt/math/copysignl.S
+++ b/mingw-w64-crt/math/copysignl.S
@@ -12,7 

[Mingw-w64-public] GDB release canditate 7.11.90 build failure for mingw-w64

[Pierre Free Pascal]

Hi,

 

  this is my first email to this list.

I would have directly put that in the ‘Tickets/Bugs’ of sourceforge,

but I didn’t find where I should send a request to get my account accepted
for bug reports.

 

  I am using GNU debugger GDB quite heavily,

partly because I am the pascal language maintainer and

because I use GDB to develop Free Pascal compiler.

 

  I use a cygwin installation to cross-compile GDB for mingw-w64

in order to get a GNU GDB executable that depends only on Windows system
DLLs.

 

  GDB recently decided to change from gcc to g++ as a compiler,

and this generates a compilation failure currently, see bottom of the email.

 

  I reported the issue to gdb mailing list:

https://sourceware.org/ml/gdb/2016-08/msg4.html

 

  There is also a mingw-w64 part to this issue as

the problem is due to the fact that the include file dlfnc.h

does not contain the usual C++ wrapper.

 

  This leads to the fact the g++ mangles dl functions,

and the linker is thus not able to find the mangled names.

 

  I still got no reply to the gdb email, and I don’t know if this is really

an error in the configure part of GDB sources, but 

it would probably be good to also insert the usual wrappers

in include/dlfnc.h.

 

  I was not able to find this file in git repository, and saw that it is
apparently a generated

file, thus I have absolutely no idea how to fix the issue, as I don’t know
where the file is generated.

 

  Should  this issue be added to the bugs?

How do I get write permissions there?

 

Does anyone know how dlfcn.h header is generated?

 

Thanks in advance,

 

Pierre Muller

 

i686-w64-mingw32-g++ -gdwarf-2 -O0   -static-libstdc++ -static-libgcc
-Wl,--stack,12582912   \

-o gdb.exe gdb.o i386-tdep.o i386-cygwin-tdep.o i387-tdep.o
windows-tdep.o ser-base.o ser-tcp.o ser-mingw.o x86-nat.o x86-dregs.o
windows-nat.o i386-windows-nat.o remote.o dcache.o tracepoint.o ax-general.o
ax-gdb.o remote-fileio.o remote-notif.o ctf.o tracefile.o tracefile-tfile.o
cli-dump.o cli-decode.o cli-script.o cli-cmds.o cli-setshow.o cli-logging.o
cli-interp.o cli-utils.o mi-out.o mi-console.o mi-cmds.o mi-cmd-catch.o
mi-cmd-env.o mi-cmd-var.o mi-cmd-break.o mi-cmd-stack.o mi-cmd-file.o
mi-cmd-disas.o mi-symbol-cmds.o mi-cmd-target.o mi-cmd-info.o mi-interp.o
mi-main.o mi-parse.o mi-getopt.o tui-command.o tui-data.o tui-disasm.o
tui-file.o tui-hooks.o tui-interp.o tui-io.o tui-layout.o tui-out.o
tui-regs.o tui-source.o tui-stack.o tui-win.o tui-windata.o tui-wingeneral.o
tui-winsource.o tui.o python.o guile.o elfread.o stap-probe.o dtrace-probe.o
mingw-hdep.o mingw-strerror.o c-exp.o cp-name-parser.o ada-exp.o jv-exp.o
d-exp.o f-exp.o go-exp.o m2-exp.o p-exp.o rust-exp.o version.o annotate.o
addrmap.o auto-load.o auxv.o agent.o bfd-target.o blockframe.o breakpoint.o
break-catch-sig.o break-catch-throw.o break-catch-syscall.o findvar.o
regcache.o cleanups.o charset.o continuations.o corelow.o disasm.o
dummy-frame.o dfp.o source.o value.o eval.o valops.o valarith.o valprint.o
printcmd.o block.o symtab.o psymtab.o symfile.o symfile-debug.o symmisc.o
linespec.o dictionary.o namespace.o location.o infcall.o infcmd.o infrun.o
expprint.o environ.o stack.o tid-parse.o thread.o thread-fsm.o exceptions.o
extension.o filesystem.o filestuff.o inf-child.o interps.o minidebug.o
main.o macrotab.o macrocmd.o macroexp.o macroscope.o mi-common.o
event-loop.o event-top.o inf-loop.o completer.o gdbarch.o arch-utils.o
gdbtypes.o gdb_bfd.o gdb_obstack.o osabi.o copying.o memattr.o mem-break.o
target.o target-dcache.o parse.o language.o build-id.o buildsym.o findcmd.o
std-regs.o signals.o exec.o reverse.o bcache.o objfiles.o observer.o
minsyms.o maint.o demangle.o dbxread.o coffread.o coff-pe-read.o
dwarf2read.o mipsread.o stabsread.o corefile.o dwarf2expr.o dwarf2loc.o
dwarf2-frame.o dwarf2-frame-tailcall.o ada-lang.o c-lang.o d-lang.o f-lang.o
objc-lang.o ada-tasks.o ada-varobj.o c-varobj.o ui-out.o cli-out.o varobj.o
vec.o go-lang.o go-valprint.o go-typeprint.o jv-lang.o jv-valprint.o
jv-typeprint.o jv-varobj.o m2-lang.o opencl-lang.o p-lang.o p-typeprint.o
p-valprint.o selftest.o sentinel-frame.o complaints.o typeprint.o
ada-typeprint.o c-typeprint.o f-typeprint.o m2-typeprint.o ada-valprint.o
c-valprint.o cp-valprint.o d-valprint.o f-valprint.o m2-valprint.o
ser-event.o serial.o mdebugread.o top.o utils.o ui-file.o user-regs.o
frame.o frame-unwind.o doublest.o frame-base.o inline-frame.o gnu-v2-abi.o
gnu-v3-abi.o cp-abi.o cp-support.o cp-namespace.o d-namespace.o reggroups.o
rust-lang.o trad-frame.o tramp-frame.o solib.o solib-target.o
prologue-value.o memory-map.o memrange.o xml-support.o xml-syscall.o
xml-utils.o target-descriptions.o target-memory.o xml-tdesc.o xml-builtin.o
inferior.o osdata.o gdb_usleep.o record.o record-full.o gcore.o gdb_vecs.o
jit.o progspace.o skip.o probe.o common-utils.o buffer.o ptid.o gdb-dlfcn.o
common-agent.o format.o registry.o btrace.o record-btrace.o waitstatus.o

Re: [Mingw-w64-public] [PATCH] math: Preserve NAN/INF in rint(f) on ARM

[Kai Tietz]

Ok.  Please apply. Important is here that we don't normalize NaN/Inf.
I did so for pow, and well, it caused some troubles.

Thanks,
Kai

2016-08-22 15:41 GMT+02:00 Martin Storsjö :
> rintl doesn't need changes since it calls rint().
> ---
>  mingw-w64-crt/math/rint.c  | 2 ++
>  mingw-w64-crt/math/rintf.c | 2 ++
>  2 files changed, 4 insertions(+)
>
> diff --git a/mingw-w64-crt/math/rint.c b/mingw-w64-crt/math/rint.c
> index 01f9644..6d0b632 100644
> --- a/mingw-w64-crt/math/rint.c
> +++ b/mingw-w64-crt/math/rint.c
> @@ -23,6 +23,8 @@ double rint (double x) {
>  #if defined(_AMD64_) || defined(__x86_64__) || defined(_X86_) || 
> defined(__i386__)
>__asm__ __volatile__ ("frndint;" : "=t" (retval) : "0" (x));
>  #elif defined(__arm__) || defined(_ARM_)
> +if (isnan(x) || isinf(x))
> +return x;
>  retval = __rint_internal(x);
>  #endif
>return retval;
> diff --git a/mingw-w64-crt/math/rintf.c b/mingw-w64-crt/math/rintf.c
> index 09c641b..37d4a92 100644
> --- a/mingw-w64-crt/math/rintf.c
> +++ b/mingw-w64-crt/math/rintf.c
> @@ -23,6 +23,8 @@ float rintf (float x) {
>  #if defined(_AMD64_) || defined(__x86_64__) || defined(_X86_) || 
> defined(__i386__)
>__asm__ __volatile__ ("frndint;": "=t" (retval) : "0" (x));
>  #elif defined(__arm__) || defined(_ARM_)
> +if (isnan(x) || isinf(x))
> +return x;
>  retval = __rintf_internal(x);
>  #endif
>return retval;
> --
> 2.7.4
>
>
> --
> ___
> 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] math: Fix rounding in ceilf and floorf on ARM

[Martin Storsjö]

If the 'r' flag is omitted from vcvt, the rounding mode specified
in the fpscr is ignored.
---
 mingw-w64-crt/math/ceilf.S  | 2 +-
 mingw-w64-crt/math/floorf.S | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/mingw-w64-crt/math/ceilf.S b/mingw-w64-crt/math/ceilf.S
index def516e..bb77ed6 100644
--- a/mingw-w64-crt/math/ceilf.S
+++ b/mingw-w64-crt/math/ceilf.S
@@ -97,7 +97,7 @@ __MINGW_USYMBOL(ceilf):
bic r0, r1, #0x00c0
orr r0, r0, #0x0040 /* Round towards Plus Infinity */
vmsrfpscr, r0
-   vcvt.s32.f32s0, s0
+   vcvtr.s32.f32   s0, s0
vcvt.f32.s32s0, s0
vmsrfpscr, r1
 2:
diff --git a/mingw-w64-crt/math/floorf.S b/mingw-w64-crt/math/floorf.S
index 94efa2a..fb9b705 100644
--- a/mingw-w64-crt/math/floorf.S
+++ b/mingw-w64-crt/math/floorf.S
@@ -37,7 +37,7 @@ __MINGW_USYMBOL(floorf):
bic r0, r1, #0x00c0
orr r0, r0, #0x0080 /* Round towards Minus Infinity */
vmsrfpscr, r0
-   vcvt.s32.f32s0, s0
+   vcvtr.s32.f32   s0, s0
vcvt.f32.s32s0, s0
vmsrfpscr, r1
 2:
-- 
2.7.4


--
___
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] math: Fix rounding in ceilf and floorf on ARM

[Kai Tietz]

Thanks, please go ahead and apply.

Regards,
Kai

2016-08-22 15:42 GMT+02:00 Martin Storsjö :
> If the 'r' flag is omitted from vcvt, the rounding mode specified
> in the fpscr is ignored.
> ---
>  mingw-w64-crt/math/ceilf.S  | 2 +-
>  mingw-w64-crt/math/floorf.S | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mingw-w64-crt/math/ceilf.S b/mingw-w64-crt/math/ceilf.S
> index def516e..bb77ed6 100644
> --- a/mingw-w64-crt/math/ceilf.S
> +++ b/mingw-w64-crt/math/ceilf.S
> @@ -97,7 +97,7 @@ __MINGW_USYMBOL(ceilf):
> bic r0, r1, #0x00c0
> orr r0, r0, #0x0040 /* Round towards Plus Infinity */
> vmsrfpscr, r0
> -   vcvt.s32.f32s0, s0
> +   vcvtr.s32.f32   s0, s0
> vcvt.f32.s32s0, s0
> vmsrfpscr, r1
>  2:
> diff --git a/mingw-w64-crt/math/floorf.S b/mingw-w64-crt/math/floorf.S
> index 94efa2a..fb9b705 100644
> --- a/mingw-w64-crt/math/floorf.S
> +++ b/mingw-w64-crt/math/floorf.S
> @@ -37,7 +37,7 @@ __MINGW_USYMBOL(floorf):
> bic r0, r1, #0x00c0
> orr r0, r0, #0x0080 /* Round towards Minus Infinity */
> vmsrfpscr, r0
> -   vcvt.s32.f32s0, s0
> +   vcvtr.s32.f32   s0, s0
> vcvt.f32.s32s0, s0
> vmsrfpscr, r1
>  2:
> --
> 2.7.4
>
>
> --
> ___
> 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] math: Fix rounding in llrintl on ARM

[Kai Tietz]

Patch is ok.  Please go ahead.

Thanks,
Kai

2016-08-22 15:40 GMT+02:00 Martin Storsjö :
> ---
> This is the same fix as in e9e42ce3113b which is already pushed;
> I didn't notice that this function has a separate copy of the
> implementation (contrary to e.g. rintl where the ARM block
> just calls rint).
> ---
>  mingw-w64-crt/math/llrintl.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/mingw-w64-crt/math/llrintl.c b/mingw-w64-crt/math/llrintl.c
> index 59ace2d..ac06ab2 100644
> --- a/mingw-w64-crt/math/llrintl.c
> +++ b/mingw-w64-crt/math/llrintl.c
> @@ -4,6 +4,7 @@
>   * No warranty is given; refer to the file DISCLAIMER.PD within this package.
>   */
>  #include 
> +#include 
>
>  long long llrintl (long double x)
>  {
> @@ -11,7 +12,15 @@ long long llrintl (long double x)
>  #if defined(_AMD64_) || defined(__x86_64__) || defined(_X86_) || 
> defined(__i386__)
>__asm__ __volatile__ ("fistpll %0"  : "=m" (retval) : "t" (x) : "st");
>  #else
> -  retval = (long long)x;
> +  int mode = fegetround();
> +  if (mode == FE_DOWNWARD)
> +retval = (long long)floor(x);
> +  else if (mode == FE_UPWARD)
> +retval = (long long)ceil(x);
> +  else if (mode == FE_TOWARDZERO)
> +retval = x >= 0 ? (long long)floor(x) : (long long)ceil(x);
> +  else
> +retval = x >= 0 ? (long long)floor(x + 0.5) : (long long)ceil(x - 0.5);
>  #endif
>return retval;
>  }
> --
> 2.7.4
>
>
> --
> ___
> 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] math: Preserve NAN/INF in rint(f) on ARM

[Martin Storsjö]

rintl doesn't need changes since it calls rint().
---
 mingw-w64-crt/math/rint.c  | 2 ++
 mingw-w64-crt/math/rintf.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/mingw-w64-crt/math/rint.c b/mingw-w64-crt/math/rint.c
index 01f9644..6d0b632 100644
--- a/mingw-w64-crt/math/rint.c
+++ b/mingw-w64-crt/math/rint.c
@@ -23,6 +23,8 @@ double rint (double x) {
 #if defined(_AMD64_) || defined(__x86_64__) || defined(_X86_) || 
defined(__i386__)
   __asm__ __volatile__ ("frndint;" : "=t" (retval) : "0" (x));
 #elif defined(__arm__) || defined(_ARM_)
+if (isnan(x) || isinf(x))
+return x;
 retval = __rint_internal(x);
 #endif
   return retval;
diff --git a/mingw-w64-crt/math/rintf.c b/mingw-w64-crt/math/rintf.c
index 09c641b..37d4a92 100644
--- a/mingw-w64-crt/math/rintf.c
+++ b/mingw-w64-crt/math/rintf.c
@@ -23,6 +23,8 @@ float rintf (float x) {
 #if defined(_AMD64_) || defined(__x86_64__) || defined(_X86_) || 
defined(__i386__)
   __asm__ __volatile__ ("frndint;": "=t" (retval) : "0" (x));
 #elif defined(__arm__) || defined(_ARM_)
+if (isnan(x) || isinf(x))
+return x;
 retval = __rintf_internal(x);
 #endif
   return retval;
-- 
2.7.4


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

[Mingw-w64-public] [PATCH] math: Fix rounding in llrintl on ARM

[Martin Storsjö]

---
This is the same fix as in e9e42ce3113b which is already pushed;
I didn't notice that this function has a separate copy of the
implementation (contrary to e.g. rintl where the ARM block
just calls rint).
---
 mingw-w64-crt/math/llrintl.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/mingw-w64-crt/math/llrintl.c b/mingw-w64-crt/math/llrintl.c
index 59ace2d..ac06ab2 100644
--- a/mingw-w64-crt/math/llrintl.c
+++ b/mingw-w64-crt/math/llrintl.c
@@ -4,6 +4,7 @@
  * No warranty is given; refer to the file DISCLAIMER.PD within this package.
  */
 #include 
+#include 
 
 long long llrintl (long double x) 
 {
@@ -11,7 +12,15 @@ long long llrintl (long double x)
 #if defined(_AMD64_) || defined(__x86_64__) || defined(_X86_) || 
defined(__i386__)
   __asm__ __volatile__ ("fistpll %0"  : "=m" (retval) : "t" (x) : "st");
 #else
-  retval = (long long)x;
+  int mode = fegetround();
+  if (mode == FE_DOWNWARD)
+retval = (long long)floor(x);
+  else if (mode == FE_UPWARD)
+retval = (long long)ceil(x);
+  else if (mode == FE_TOWARDZERO)
+retval = x >= 0 ? (long long)floor(x) : (long long)ceil(x);
+  else
+retval = x >= 0 ? (long long)floor(x + 0.5) : (long long)ceil(x - 0.5);
 #endif
   return retval;
 }
-- 
2.7.4


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

Re: [Mingw-w64-public] _CRTIMP

[Kai Tietz]

Hmm, as all of those are functions, and we get those warnings during
crt build. So we could simply take care that within crt build (and it
helper libraries) those prototypes using a _CRTIMP variant without
dllimport.

This should work in all scenarios well, as linker will resolve such functions.

Regards,
Kai

2016-08-22 11:04 GMT+02:00 David Wohlferd :
> On 8/18/2016 11:27 PM, David Wohlferd wrote:
>> My next patch is very small, but it affects a bunch of code.  Ponder
>> it a bit before approving.  The goal is to fix all the warnings like
>> this:
>>
>>  warning: '_unlock_file' redeclared without dllimport attribute:
>> previous dllimport ignored [-Wattributes]
>>
>> This occurs because our headers use:
>>
>>   _CRTIMP void __cdecl _unlock_file(FILE *_File);
>>
>> and _CRTIMP is always defined like this:
>>
>> #ifndef _CRTIMP
>> #define _CRTIMP __declspec(dllimport)
>> #endif
>>
>> If we were *only* providing a mapping to the function in a DLL, this
>> would be fine.  But we actually create an implementation of this
>> function (mingw-w64-crt/stdio/mingw_lock.c).  And the implementation
>> uses the same header.  Since it makes no sense to have an
>> implementation tagged as dllimport, I assert that when building
>> mingw-w64, _CRTIMP should always be defined as blank (attached).
>
> Below is the list of functions that have the problem.  Note most are in
> secapi.
>
> .../mingw-w64-crt/misc/invalid_parameter_handler.c:21:36: warning:
> '_get_invalid_parameter_handler' redeclared without dllimport attribute:
> previous dllimport ignored [-Wattributes]
> .../mingw-w64-crt/misc/invalid_parameter_handler.c:22:36: warning:
> '_set_invalid_parameter_handler' redeclared without dllimport attribute:
> previous dllimport ignored [-Wattributes]
> .../mingw-w64-crt/misc/purecall.c:10:27: warning:
> '_set_purecall_handler' redeclared without dllimport attribute: previous
> dllimport ignored [-Wattributes]
> .../mingw-w64-crt/secapi/_controlfp_s.c:14:17: warning: '_controlfp_s'
> redeclared without dllimport attribute: previous dllimport ignored
> [-Wattributes]
> .../mingw-w64-crt/secapi/_ctime32_s.c:7:17: warning: '_localtime32_s'
> redeclared without dllimport attribute after being referenced with dll
> linkage
> .../mingw-w64-crt/secapi/_ctime32_s.c:8:17: warning: 'asctime_s'
> redeclared without dllimport attribute: previous dllimport ignored
> [-Wattributes]
> .../mingw-w64-crt/secapi/_ctime32_s.c:9:17: warning: '_ctime32_s'
> redeclared without dllimport attribute after being referenced with dll
> linkage
> .../mingw-w64-crt/secapi/_ctime64_s.c:7:17: warning: '_localtime64_s'
> redeclared without dllimport attribute: previous dllimport ignored
> [-Wattributes]
> .../mingw-w64-crt/secapi/_ctime64_s.c:8:17: warning: 'asctime_s'
> redeclared without dllimport attribute: previous dllimport ignored
> [-Wattributes]
> .../mingw-w64-crt/secapi/_gmtime32_s.c:8:17: warning: '_gmtime32_s'
> redeclared without dllimport attribute after being referenced with dll
> linkage
> .../mingw-w64-crt/secapi/_gmtime64_s.c:8:17: warning: '_gmtime64_s'
> redeclared without dllimport attribute: previous dllimport ignored
> [-Wattributes]
> .../mingw-w64-crt/secapi/_localtime32_s.c:8:17: warning:
> '_localtime32_s' redeclared without dllimport attribute after being
> referenced with dll linkage
> .../mingw-w64-crt/secapi/_localtime64_s.c:8:17: warning:
> '_localtime64_s' redeclared without dllimport attribute: previous
> dllimport ignored [-Wattributes]
> .../mingw-w64-crt/secapi/_sopen_s.c:6:17: warning: '_sopen_s' redeclared
> without dllimport attribute: previous dllimport ignored [-Wattributes]
> .../mingw-w64-crt/secapi/_wasctime_s.c:7:17: warning: '_wasctime_s'
> redeclared without dllimport attribute: previous dllimport ignored
> [-Wattributes]
> .../mingw-w64-crt/secapi/_wctime32_s.c:7:17: warning: '_localtime32_s'
> redeclared without dllimport attribute after being referenced with dll
> linkage
> .../mingw-w64-crt/secapi/_wctime32_s.c:8:17: warning: '_wasctime_s'
> redeclared without dllimport attribute: previous dllimport ignored
> [-Wattributes]
> .../mingw-w64-crt/secapi/_wctime32_s.c:9:17: warning: '_wctime32_s'
> redeclared without dllimport attribute after being referenced with dll
> linkage
> .../mingw-w64-crt/secapi/_wctime64_s.c:7:17: warning: '_localtime64_s'
> redeclared without dllimport attribute: previous dllimport ignored
> [-Wattributes]
> .../mingw-w64-crt/secapi/_wctime64_s.c:8:17: warning: '_wasctime_s'
> redeclared without dllimport attribute: previous dllimport ignored
> [-Wattributes]
> .../mingw-w64-crt/secapi/_wctime64_s.c:9:17: warning: '_wctime64_s'
> redeclared without dllimport attribute: previous dllimport ignored
> [-Wattributes]
> .../mingw-w64-crt/secapi/asctime_s.c:7:17: warning: 'asctime_s'
> redeclared without dllimport attribute: previous dllimport ignored
> [-Wattributes]
> .../mingw-w64-crt/secapi/memcpy_s.c:6:17: warning: 'memcpy_s' redeclared
> without dllimport 

Re: [Mingw-w64-public] _CRTIMP

[David Wohlferd]

On 8/18/2016 11:27 PM, David Wohlferd wrote:
> My next patch is very small, but it affects a bunch of code.  Ponder 
> it a bit before approving.  The goal is to fix all the warnings like 
> this:
>
>  warning: '_unlock_file' redeclared without dllimport attribute: 
> previous dllimport ignored [-Wattributes]
>
> This occurs because our headers use:
>
>   _CRTIMP void __cdecl _unlock_file(FILE *_File);
>
> and _CRTIMP is always defined like this:
>
> #ifndef _CRTIMP
> #define _CRTIMP __declspec(dllimport)
> #endif
>
> If we were *only* providing a mapping to the function in a DLL, this 
> would be fine.  But we actually create an implementation of this 
> function (mingw-w64-crt/stdio/mingw_lock.c).  And the implementation 
> uses the same header.  Since it makes no sense to have an 
> implementation tagged as dllimport, I assert that when building 
> mingw-w64, _CRTIMP should always be defined as blank (attached).

Below is the list of functions that have the problem.  Note most are in 
secapi.

.../mingw-w64-crt/misc/invalid_parameter_handler.c:21:36: warning: 
'_get_invalid_parameter_handler' redeclared without dllimport attribute: 
previous dllimport ignored [-Wattributes]
.../mingw-w64-crt/misc/invalid_parameter_handler.c:22:36: warning: 
'_set_invalid_parameter_handler' redeclared without dllimport attribute: 
previous dllimport ignored [-Wattributes]
.../mingw-w64-crt/misc/purecall.c:10:27: warning: 
'_set_purecall_handler' redeclared without dllimport attribute: previous 
dllimport ignored [-Wattributes]
.../mingw-w64-crt/secapi/_controlfp_s.c:14:17: warning: '_controlfp_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/secapi/_ctime32_s.c:7:17: warning: '_localtime32_s' 
redeclared without dllimport attribute after being referenced with dll 
linkage
.../mingw-w64-crt/secapi/_ctime32_s.c:8:17: warning: 'asctime_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/secapi/_ctime32_s.c:9:17: warning: '_ctime32_s' 
redeclared without dllimport attribute after being referenced with dll 
linkage
.../mingw-w64-crt/secapi/_ctime64_s.c:7:17: warning: '_localtime64_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/secapi/_ctime64_s.c:8:17: warning: 'asctime_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/secapi/_gmtime32_s.c:8:17: warning: '_gmtime32_s' 
redeclared without dllimport attribute after being referenced with dll 
linkage
.../mingw-w64-crt/secapi/_gmtime64_s.c:8:17: warning: '_gmtime64_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/secapi/_localtime32_s.c:8:17: warning: 
'_localtime32_s' redeclared without dllimport attribute after being 
referenced with dll linkage
.../mingw-w64-crt/secapi/_localtime64_s.c:8:17: warning: 
'_localtime64_s' redeclared without dllimport attribute: previous 
dllimport ignored [-Wattributes]
.../mingw-w64-crt/secapi/_sopen_s.c:6:17: warning: '_sopen_s' redeclared 
without dllimport attribute: previous dllimport ignored [-Wattributes]
.../mingw-w64-crt/secapi/_wasctime_s.c:7:17: warning: '_wasctime_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/secapi/_wctime32_s.c:7:17: warning: '_localtime32_s' 
redeclared without dllimport attribute after being referenced with dll 
linkage
.../mingw-w64-crt/secapi/_wctime32_s.c:8:17: warning: '_wasctime_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/secapi/_wctime32_s.c:9:17: warning: '_wctime32_s' 
redeclared without dllimport attribute after being referenced with dll 
linkage
.../mingw-w64-crt/secapi/_wctime64_s.c:7:17: warning: '_localtime64_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/secapi/_wctime64_s.c:8:17: warning: '_wasctime_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/secapi/_wctime64_s.c:9:17: warning: '_wctime64_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/secapi/asctime_s.c:7:17: warning: 'asctime_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/secapi/memcpy_s.c:6:17: warning: 'memcpy_s' redeclared 
without dllimport attribute: previous dllimport ignored [-Wattributes]
.../mingw-w64-crt/secapi/memmove_s.c:6:17: warning: 'memmove_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/secapi/strerror_s.c:7:17: warning: 'strerror_s' 
redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]
.../mingw-w64-crt/stdio/mingw_lock.c:35:14: warning: '_lock_file' 
redeclared without dllimport attribute: previous dllimport ignored 

Re: [Mingw-w64-public] undefined references to __GSHandlerCheck and __security_check_cookie

[Kai Tietz]

2016-08-22 8:58 GMT+02:00 Mario Emmenlauer :
>
> Dear All,
>
> I'm trying to link against MySQL, but it fails with undefined references
> to __GSHandlerCheck and __security_check_cookie. I searched and this has
> been asked before (several years back), but back then there was no solution
> found. AFAIK these two where not available in MinGW's runtime, and in the
> end the user was switching compilers. Is there a MinGW-based solution
> possible now? I'd very much prefer that. I found people recommending to
> link against a "bufferoverflowu.lib" and some 'gshandler.obj'. Do you know
> if I can take those from Visual Studio and link against them in MinGW?
> Would that work? Or other ideas?
>
> Thanks for any help,
>
> Mario Emmenlauer

We don't support those.  You can link against MS libraries/objects for
these symbols.  Or you could work on a patch, which provides support
for those.

Regards,
Kai

--
___
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] variadic functions can't be stdcall

[Kai Tietz]

2016-08-22 9:11 GMT+02:00 Martin Storsjö :
> On Sun, 21 Aug 2016, David Wohlferd wrote:
>
>> As my expert on patch etiquette, I have a question for you.  When
>> posting a patch, does one traditionally include all the files that will
>> be in the push?  Or do you skip the 'generated' files to make the review
>> easier?
>
> I guess it depends on the project, and the kind of the generated files.
>
> For things like automake/autoconf, where regeneration can produce huge
> unreadable diffs (while for things like idl -> h, including it is nice),
> I'd just omit such things from review, and regenerate it when pushing
> (whether it goes into the same or into a different commit is also project
> specific - I think the norm here is to keep it in the same commit).
>
> // Martin

It isn't required to attach auto-generated stuff to patch.  But of
course it belongs to the patch, and has to be applied, when patch is
approved.  I agree that omit auto-generated parts makes review easier.

IIRC gcc doesn't rejects stdcall on variadic.  In general it is a bit
piggy, but IIRC gcc supports that. Of course are just the "fixed"
arguments automatically popped on return.

Regards,
Kai

--
___
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 missing voids

[Kai Tietz]

2016-08-22 8:43 GMT+02:00 David Wohlferd :
> On 8/21/2016 11:17 PM, Martin Storsjö wrote:
>> On Sun, 21 Aug 2016, David Wohlferd wrote:
>>
>>> To my surprise, these two statements have (slightly) different meanings:
>>>
>>>   STDAPI MFUnregisterPlatformFromMMCSS ();
>>>   STDAPI MFUnregisterPlatformFromMMCSS (void);
>>>
>>> And clang complains about it (warning: function with no prototype cannot use
>>> the stdcall calling convention).
>> Yes - the former means any number of parameters.
>
> I don't think I've ever seen this used this way.  I'm ok with that.
>
>>> I have added 'void' every place clang complained (attached).
>> The patch seems fine to me, assuming these functions really take no
>> parameters.
>
> I'd be tempted to just say "stop doing that" if someone was doing this
> intentionally, but I did check.
>
> dw

Patch is fine.  Please go ahead, and apply.

Thanks,
Kai

--
___
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] variadic functions can't be stdcall

[Martin Storsjö]

On Sun, 21 Aug 2016, David Wohlferd wrote:

> As my expert on patch etiquette, I have a question for you.  When
> posting a patch, does one traditionally include all the files that will
> be in the push?  Or do you skip the 'generated' files to make the review
> easier?

I guess it depends on the project, and the kind of the generated files.

For things like automake/autoconf, where regeneration can produce huge 
unreadable diffs (while for things like idl -> h, including it is nice), 
I'd just omit such things from review, and regenerate it when pushing 
(whether it goes into the same or into a different commit is also project 
specific - I think the norm here is to keep it in the same commit).

// Martin

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

[Mingw-w64-public] undefined references to __GSHandlerCheck and __security_check_cookie

[Mario Emmenlauer]

Dear All,

I'm trying to link against MySQL, but it fails with undefined references
to __GSHandlerCheck and __security_check_cookie. I searched and this has
been asked before (several years back), but back then there was no solution
found. AFAIK these two where not available in MinGW's runtime, and in the
end the user was switching compilers. Is there a MinGW-based solution
possible now? I'd very much prefer that. I found people recommending to
link against a "bufferoverflowu.lib" and some 'gshandler.obj'. Do you know
if I can take those from Visual Studio and link against them in MinGW?
Would that work? Or other ideas?

Thanks for any help,

Mario Emmenlauer

--
___
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] variadic functions can't be stdcall

[David Wohlferd]

On 8/21/2016 11:19 PM, Martin Storsjö wrote:
> On Sun, 21 Aug 2016, David Wohlferd wrote:
>
>> By definition, functions with variable numbers of parameters cannot be
>> stdcall.  Clang complains (warning: stdcall calling convention ignored on
>> variadic function).
>>
>> Attached.
> Seems ok to me. I assume GCC did the same, ignored the attribute since it
> couldn't apply? Or were these functions just inlined in all cases where
> anybody ever used them, so it never mattered?

It has to be (silently) ignoring them.

As my expert on patch etiquette, I have a question for you.  When 
posting a patch, does one traditionally include all the files that will 
be in the push?  Or do you skip the 'generated' files to make the review 
easier?

dw

--
___
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 push/pop macro problem

[David Wohlferd]

On 8/21/2016 11:27 PM, Martin Storsjö wrote:
> On Sun, 21 Aug 2016, David Wohlferd wrote:
>
>> Under certain circumstances, the #pragma pop_macro("__has_builtin") at the
>> bottom of intrin-impl.h can be called without ever having hit the #pragma
>> push_macro("__has_builtin") at the top.  Clang warns about this, so I have
>> moved the push appropriately.
>>
>> Patch attached.
> The patch seems ok, although the nesting in that header isn't quite
> obvious.

True.  I thought about trying to move the 'pop' up, but quickly surrendered.

dw

--
___
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 missing voids

[David Wohlferd]

On 8/21/2016 11:17 PM, Martin Storsjö wrote:
> On Sun, 21 Aug 2016, David Wohlferd wrote:
>
>> To my surprise, these two statements have (slightly) different meanings:
>>
>>   STDAPI MFUnregisterPlatformFromMMCSS ();
>>   STDAPI MFUnregisterPlatformFromMMCSS (void);
>>
>> And clang complains about it (warning: function with no prototype cannot use
>> the stdcall calling convention).
> Yes - the former means any number of parameters.

I don't think I've ever seen this used this way.  I'm ok with that.

>> I have added 'void' every place clang complained (attached).
> The patch seems fine to me, assuming these functions really take no
> parameters.

I'd be tempted to just say "stop doing that" if someone was doing this 
intentionally, but I did check.

dw

--
___
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 push/pop macro problem

[Martin Storsjö]

On Sun, 21 Aug 2016, David Wohlferd wrote:

> Under certain circumstances, the #pragma pop_macro("__has_builtin") at the 
> bottom of intrin-impl.h can be called without ever having hit the #pragma 
> push_macro("__has_builtin") at the top.  Clang warns about this, so I have 
> moved the push appropriately.
>
> Patch attached.

The patch seems ok, although the nesting in that header isn't quite 
obvious.

// Martin

--
___
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 missing voids

[Martin Storsjö]

On Sun, 21 Aug 2016, David Wohlferd wrote:

> To my surprise, these two statements have (slightly) different meanings:
>
>  STDAPI MFUnregisterPlatformFromMMCSS ();
>  STDAPI MFUnregisterPlatformFromMMCSS (void);
>
> And clang complains about it (warning: function with no prototype cannot use 
> the stdcall calling convention).

Yes - the former means any number of parameters.

> I have added 'void' every place clang complained (attached).

The patch seems fine to me, assuming these functions really take no 
parameters.

// Martin

--
___
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 sinhl()

[Martin Storsjö]

On Sun, 21 Aug 2016, David Wohlferd wrote:

> In this function:
>
>long double sinhl(long double x)
>
> there is a call to fabs:
>
>  (fabs (x) > (MAXLOGL + LOGE2L)))
>
> However, fabs doesn't take a (long double), it only takes a (double).  Clang 
> complains about the truncation (warning: absolute value function 'fabs' given 
> an argument of type 'long double' but has parameter of type 'double' which 
> may cause truncation of value).
>
> Patch attached.

Ok with me.

// Martin

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