date:20160319

Re: [Mingw-w64-public] [PATCH 2/2] wrl/client.h: Fixed a typo.

2016-03-19 Thread Kai Tietz

Hi Jacek,

patch is ok.

Thanks,
Kai


2016-03-16 17:13 GMT+01:00 Jacek Caban :
> Signed-off-by: Jacek Caban 
> ---
>  mingw-w64-headers/include/wrl/client.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
>
>
> --
> 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=278785231=/4140
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

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

[Mingw-w64-public] LTO alignment warning

2016-03-19 Thread Hannes Domani

Hello


Consider this source (which is partly from SETJMP_FLOAT128):

#include 

typedef __attribute__ ((__aligned__ (16))) struct _TEST_FLOAT128 {
__extension__ unsigned long long Part[2];
} TEST_FLOAT128;

int main( void )
{
   TEST_FLOAT128 tf;
   printf( "alignof(tf) = %d\n",(int)__alignof__(tf) );

   printf( "alignof(struct _TEST_FLOAT128) = %d\n",(int)__alignof__(struct 
_TEST_FLOAT128) );
   printf( "alignof(TEST_FLOAT128) = %d\n",(int)__alignof__(TEST_FLOAT128) );

   return 0;
}


Compiled like this:
g++ -O3 -flto -oalign align.cpp -Wall -Wextra -g


I get the following warning:
align.cpp:4:51: warning: type 'struct _TEST_FLOAT128' violates one definition 
rule [-Wodr]
typedef __attribute__ ((__aligned__ (16))) struct _TEST_FLOAT128 {
align.cpp:6:3: note: a type with different alignment is defined in another 
translation unit
} TEST_FLOAT128;


And this output when run:
alignof(tf) = 16
alignof(struct _TEST_FLOAT128) = 8
alignof(TEST_FLOAT128) = 16



Now if I move the __aligned__ attribute after the struct like this:
typedef struct __attribute__ ((__aligned__ (16))) _TEST_FLOAT128 {
__extension__ unsigned long long Part[2];
} TEST_FLOAT128;



The warning is gone, and the alignment is the same everywhere:

alignof(tf) = 16
alignof(struct _TEST_FLOAT128) = 16
alignof(TEST_FLOAT128) = 16


Is the warning correct, even thou the names are slightly different 
(with/without underscore)?
Should the attribute be moved in SETJMP_FLOAT128?


Regards
Domani Hannes

--
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=278785231=/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] complex: Add clog10*.

2016-03-19 Thread sisyphus1


-Original Message- 
From: JonY 
Sent: Sunday, March 20, 2016 10:52 AM 
To: mingw-w64-public@lists.sourceforge.net 
Subject: Re: [Mingw-w64-public] [PATCH] complex: Add clog10*. 

On 3/17/2016 22:36, Nakai Yuta wrote:
>> Hi All,
>> 
>> This patch implements clog10/clog10f/clog10l in libmingwex.
>> Please review:)
>> 

Sorry - I missed the original post.

No clog10q ? (For completeness.)

Cheers,
Rob



--
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=278785231=/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] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

2016-03-19 Thread Benjamin Bihler

Thank you for the suggestion.

I have tried the following code snippets when the program starts up to set the 
floating-point precision:

---
unsigned int fpu_cw;
 _controlfp_s(_cw, _PC_24, _MCW_PC);
---

---
unsigned int fpu_cw;
 _controlfp_s(_cw, _PC_53, _MCW_PC);
---

---
unsigned int fpu_cw;
 _controlfp_s(_cw, _PC_64, _MCW_PC);
---

This does not help. Still the asynchronous thread gives different results. 
Should I use different commands? Which ones?

Actually limiting the fp precision on the main thread would be a solution for 
me, though it feels like a dirty workaround.

-Ursprüngliche Nachricht-
Von: K. Frank [mailto:kfrank2...@gmail.com] 
Gesendet: Dienstag, 15. März 2016 22:09
An: mingw64
Betreff: Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic 
When Excecuted Asynchronously

Hi Benjamin!

I have no idea how to patch mingw-w64 to do you you really want, but perhaps I 
have a suggestion for a work-around, below.

On Tue, Mar 15, 2016 at 11:15 AM, Benjamin Bihler 
 wrote:
> I have taken commit d82c6defa723b6e7986091ce0fb74da544b9e0f6 ("Reset thread 
> floating point settings on new thread") from the master branch of the mingw64 
> repository, compiled it and replaced the respective files in the "include" 
> and "lib" folder of the "x86_64-mingw32" folder of my mingww64 5.3.0 
> installation with the newly compiled files.
>
> Then I have compiled my sample file with this modified mingw64 installation. 
> It had no effect, the two threads give different results. I have checked that 
> the executable depends only on the DLLs Kernel32.dll and Msvcrt.dll.
>
> When I add
>
> _fpreset()
>
> as the first command of the method that is run asynchronously, both threads 
> give the same result. But this has already been the case with the unmodified 
> mingw64 compiler (without overwriting the link binaries with those from the 
> new revision), I have checked that.
>
> My sample is a C++ sample, since I am using the gnu++11 features.
>
> It would be painful for me, if I had to add _fpreset() to all methods that I 
> want to run asynchronously, especially since they may be part of other 
> libraries.
>
> Did I patch my mingw64 installation in a wrong way? Otherwise it seems as if 
> the commit mentioned above does not solve my problem.
>
> Does anyone have another idea? Thanks!

Disclaimer: I don't know anything about the patch or the _fpreset() call.  
Also, I am speaking from memory, so I may have some of the details backwards.

Is it essential that you get the better, 80-bit long-double behavior, or can 
you live with 64-bit long doubles as long as all threads behave the same way?

As I understand it, the main thread starts with the 80-bit setting, but 
somebody (mingw?, microsoft?) sets 64-bit behavior on start-up of subsequent 
threads.

Perhaps you could -- just once, in your main thread -- set the 64-bit behavior 
when your program starts up.  Then (hopefully) all new threads that 
automatically get 64-bit behavior will match your main thread.

You would still have to call some sort of "_fpset(...)" once in your main 
thread, but you would no longer have to add _fpreset to all of your 
asynchronous methods.

(You might have to do some reverse engineering or ask on this list to find out 
exactly what floating-point mode you need to set for your main thread in order 
that it match that of the child treads.)

Sorry if this is all nonsense, but maybe it could help.

Good luck.

K. Frank

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

--
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=278785231=/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] Order of -ladvapi32 versus -lkernel32

2016-03-19 Thread Ruben Van Boxem

2016-03-18 17:22 GMT+01:00 Vitaly Kruglikov :

>
>
>
> >
> >
> >
> >--
> >
> >Message: 3
> >Date: Fri, 18 Mar 2016 04:37:25 +0100
> >From: Vincent Torri 
> >Subject: Re: [Mingw-w64-public] Order of -ladvapi32 versus -lkernel32
> >To: "mingw-w64-public@lists.sourceforge.net"
> >   
> >Message-ID:
> >    dqw5kx-ocdr06jme...@mail.gmail.com>
> >Content-Type: text/plain; charset=UTF-8
> >
> >hello
> >
> >On Fri, Mar 18, 2016 at 2:48 AM, Vitaly Kruglikov
> > wrote:
> >>
> >> Carl of mingwpy suggested that I re-post this question here (originally
> >>posted on https://groups.google.com/forum/#!topic/mingwpy/kHhGl3mBNfo)
> >>
> >>
> >> My project's CMAKE_CXX_STANDARD_LIBRARIES originally contained by
> >>default: "-lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32
> >>-loleaut32 -luuid -lcomdlg32 -ladvapi32" (without the quotes).
> >>
> >> I used mingwpy (based on mingw-w64) running on Windows Server 2008
> >>32-bit to build my python extension DLL. The apr (apache portable
> >>runtime) library that's linked as a static library into my extension DLL
> >>makes a call to "CreateProcessAsUserW". When testing, I would get this
> >>error: "The procedure entry point CreateProcessAsUserW could not be
> >>located in the dynamic link library KERNEL32.dll". I found this error
> >>surprising, because CreateProcessAsUserW is in advapi32, and
> >>"-ladvapi32" was listed at the end of CMAKE_CXX_STANDARD_LIBRARIES, so
> >>it should have been picked up by mingwpy's linker/loader. I was able to
> >>fix this failure by moving
> >> "-ladvapi32" to the beginning so that it was in front of "-lkernel32"
> >>like so: "-ladvapi32 -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32
> >>-lole32 -loleaut32 -luuid -lcomdlg32".
> >>
> >> However, I don't understand why it was necessary to place -ladvapi32 in
> >>front of -lkernel32 to make the CreateProcessAsUserW problem go away.
> >>Does someone know why this would be necessary? Is there a better way to
> >>avoid this problem?
> >
> >advapi32.dll depends on kernel32.dll (you can see that with dependency
> >walker for example), and the order of the -l flags is important : from
> >right to left : the "less dependent" to the "more dependant". So pass
> >to the linker "-ladvapi32 -lkernel32" because advapi32.dll depends on
> >kernel32.dll
> >
> >Vincent Torri
>
> Many thanks Vincent. I guess that the haphazard order that CMake used to
> add libraries to CMAKE_CXX_STANDARD_LIBRARIES should not be relied upon,
> and should be set explicitly instead!
>

No, you should report this to CMake so that they can fix it!
https://public.kitware.com/Bug/my_view_page.php

Point them to this discussion to prove your point :)

Ruben
--
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=278785231=/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] complex: Add clog10*.

2016-03-19 Thread JonY

On 3/17/2016 22:36, Nakai Yuta wrote:
> Hi All,
> 
> This patch implements clog10/clog10f/clog10l in libmingwex.
> Please review:)
> 

Hi,

Style wise, I have no problems with it, but please expand the commit
message a bit.

Otherwise, OK from me.




0xD4EBC740.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
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=278785231=/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] Differentiate on MinGW-w64 and TDM-gcc

2016-03-19 Thread LRN

On 17.03.2016 17:49, Gisle Vanem wrote:
>
> So how can I differentiate on your MinGW-w64 and TDM-gcc from 
> http://tdm-gcc.tdragon.net 
>

Why would you do that? What are you hoping to achieve by telling the
difference between TDM mingw-w64-based toolchain and non-TDM
mingw-w64-based toolchain?

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org



signature.asc
Description: OpenPGP digital signature
--
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=278785231=/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] Differentiate on MinGW-w64 and TDM-gcc

2016-03-19 Thread Gisle Vanem

Ruben Van Boxem wrote:

> There is, as far as I know, no special define you can check to differentiate 
> TDM's GCC from vanilla GCC. If I remember
> correctly, there's no extra defines added into the compiler in the patches 
> applied in a TDM build.

Thanks for clearing that up.

-- 
--gv

--
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=278785231=/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] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

2016-03-19 Thread Benjamin Bihler

Hi Kai,

I am a complete novice when it comes to patching Mingw. I have done the 
following:


-  Cloned git://git.code.sf.net/p/mingw-w64/mingw-w64

-  mkdir build

-  cd build

-  ../mingw-w64-crt/configure --prefix=/d/OpenCascade/mingw-w64-install 
--host=x86_64-w64-mingw32

-  make all

-  make install

-  copied the files from /d/OpenCascade/mingw-w64-install/include and 
/d/OpenCascade/mingw-w64-install/lib to the respective folders in the 
x86_64-w64-mingw32 folder of my Mingw-w64 installation

Is this “building a replaced complete runtime”? If not, how can I do that?

Thank you very much!
Benjamin

Von: Kai Tietz [mailto:ktiet...@googlemail.com]
Gesendet: Dienstag, 15. März 2016 22:24
An: mingw-w64-public@lists.sourceforge.net
Betreff: Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic 
When Excecuted Asynchronously


Hi Benjamin,

I would assume that there might be something wrong with your update of crt.  
What doesn't get clear to me by your description is what you build and what you 
replaced actually.
The code in question is part of the crt build .a files. have you just replace 
object code (as it sounds) or have you build an replaced complete runtime?

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

[Mingw-w64-public] [PATCH] complex: Add clog10*.

2016-03-19 Thread Nakai Yuta

Hi All,

This patch implements clog10/clog10f/clog10l in libmingwex.
Please review:)
From b4eb652558fe341a25c12935ee7b9939d1520f3f Mon Sep 17 00:00:00 2001
From: Yuta Nakai 
Date: Sun, 7 Feb 2016 17:10:12 +0900
Subject: [PATCH] complex: Add clog10*.

---
 mingw-w64-crt/Makefile.am| 27 ++--
 mingw-w64-crt/complex/clog10.c   | 48 +
 mingw-w64-crt/complex/clog10.def.h   | 71 
 mingw-w64-crt/complex/clog10f.c  | 48 +
 mingw-w64-crt/complex/clog10l.c  | 48 +
 mingw-w64-crt/complex/complex_internal.h |  4 +-
 mingw-w64-headers/crt/complex.h  | 13 +-
 7 files changed, 243 insertions(+), 16 deletions(-)
 create mode 100644 mingw-w64-crt/complex/clog10.c
 create mode 100644 mingw-w64-crt/complex/clog10.def.h
 create mode 100644 mingw-w64-crt/complex/clog10f.c
 create mode 100644 mingw-w64-crt/complex/clog10l.c

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 038dea5..2815196 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -221,19 +221,20 @@ src_msvcrt32=\
 src_libmingwex=\
   crt/dllentry.ccrt/dllmain.c \
   \
-  complex/_cabs.c  complex/cabs.c complex/cabsf.ccomplex/cabsl.c   
complex/cacos.ccomplex/cacosf.c   complex/cacosl.c \
-  complex/carg.c complex/cargf.ccomplex/cargl.c   complex/casin.c
complex/casinf.c   complex/casinl.c \
-  complex/catan.ccomplex/catanf.c   complex/catanl.c  complex/ccos.c 
complex/ccosf.ccomplex/ccosl.c  \
-  complex/cexp.c complex/cexpf.ccomplex/cexpl.c   complex/cimag.c
complex/cimagf.c   complex/cimagl.c \
-  complex/clog.c complex/clogf.ccomplex/clogl.c   complex/conj.c 
complex/conjf.ccomplex/conjl.c  \
-  complex/cpow.c complex/cpowf.ccomplex/cpowl.c   complex/cproj.c
complex/cprojf.c   complex/cprojl.c \
-  complex/creal.ccomplex/crealf.c   complex/creall.c  complex/csin.c 
complex/csinf.ccomplex/csinl.c  \
-  complex/csqrt.ccomplex/csqrtf.c   complex/csqrtl.c  complex/ctan.c 
complex/ctanf.ccomplex/ctanl.c  \
-  complex/cabs.def.hcomplex/cacos.def.h  complex/cacosh.def.h  
complex/carg.def.h  complex/casin.def.h \
-  complex/casinh.def.h  complex/catan.def.h  complex/catanh.def.h  
complex/ccos.def.h  complex/ccosh.def.h \
-  complex/cexp.def.hcomplex/cimag.def.h  complex/clog.def.h
complex/complex_internal.h  complex/conj.def.h  \
-  complex/cpow.def.hcomplex/cproj.def.h  complex/creal.def.h   
complex/csin.def.h  complex/csinh.def.h \
-  complex/csqrt.def.h   complex/ctan.def.h   complex/ctanh.def.h   \
+  complex/_cabs.ccomplex/cabs.c   complex/cabsf.c   complex/cabsl.c   
complex/cacos.c   complex/cacosf.c   \
+  complex/cacosl.c   complex/carg.c   complex/cargf.c   complex/cargl.c   
complex/casin.c   complex/casinf.c   \
+  complex/casinl.c   complex/catan.c  complex/catanf.c  complex/catanl.c  
complex/ccos.ccomplex/ccosf.c\
+  complex/ccosl.ccomplex/cexp.c   complex/cexpf.c   complex/cexpl.c   
complex/cimag.c   complex/cimagf.c   \
+  complex/cimagl.c   complex/clog.c   complex/clogf.c   complex/clogl.c   
complex/clog10.c  complex/clog10f.c  \
+  complex/clog10l.c  complex/conj.c   complex/conjf.c   complex/conjl.c   
complex/cpow.ccomplex/cpowf.c\
+  complex/cpowl.ccomplex/cproj.c  complex/cprojf.c  complex/cprojl.c  
complex/creal.c   complex/crealf.c   \
+  complex/creall.c   complex/csin.c   complex/csinf.c   complex/csinl.c   
complex/csqrt.c   complex/csqrtf.c   \
+  complex/csqrtl.c   complex/ctan.c   complex/ctanf.c   complex/ctanl.c   \
+  complex/cabs.def.hcomplex/cacos.def.h  complex/cacosh.def.h  
complex/carg.def.hcomplex/casin.def.h \
+  complex/casinh.def.h  complex/catan.def.h  complex/catanh.def.h  
complex/ccos.def.hcomplex/ccosh.def.h \
+  complex/cexp.def.hcomplex/cimag.def.h  complex/clog.def.h
complex/clog10.def.h  complex/complex_internal.h  \
+  complex/conj.def.hcomplex/cpow.def.h   complex/cproj.def.h   
complex/creal.def.h   complex/csin.def.h  \
+  complex/csinh.def.h   complex/csqrt.def.h  complex/ctan.def.h
complex/ctanh.def.h   \
   \
   gdtoa/gd_arith.h  gdtoa/gd_qnan.h  gdtoa/gdtoa.h  gdtoa/gdtoaimp.h \
   gdtoa/arithchk.c  gdtoa/dmisc.cgdtoa/dtoa.c   gdtoa/g_dfmt.c   
gdtoa/gdtoa.c  gdtoa/gethex.c \
diff --git a/mingw-w64-crt/complex/clog10.c b/mingw-w64-crt/complex/clog10.c
new file mode 100644
index 000..f8545cd
--- /dev/null
+++ b/mingw-w64-crt/complex/clog10.c
@@ -0,0 +1,48 @@
+/*
+ This Software is provided under the Zope Public License (ZPL) Version 2.1.
+
+ Copyright (c) 2009, 2010 by the mingw-w64 project
+
+ See the AUTHORS file for the list of contributors to the mingw-w64 project.
+
+ This license has been certified as open source. It has also been designated
+ as

[Mingw-w64-public] Does GCC 4.9.0 supports -Wl,--gc-sections?

2016-03-19 Thread YIRAN LI

Hi guys,

I'm compiling on MingW-W64 and had a problem in using -Wl,--gc-setions.

I'm compiling 2 files into a shared library: a.c which contains a1, a2 and
b.c which contains b1 b2.

I used --fdata-sections -ffunction-setions to put each function into a
separate text section and by dumpbin I could see that's successful.

But when I link them to be a shared library, from the map file I can see
that b1 and b2 are also included into text section of the dll.

Below is the command I used

gcc -c -fdata-sections -ffucntion-sections a.c
gcc -c -fdata-sections -ffucntion-sections b.c
gcc -shared -Wl,--gc-sections -Wl,--version-script v.ver -Wl,-Map=out.map
 -Wl,--strip-all -o dll.dll a.o b.o

v.ver is the script to control export function list, its content is:
libsimple {
  global: a1;
a2;
  local: *;
};


dumpbin shows that each function is put into individual section.

COFF SYMBOL TABLE
000  DEBUG  notype   Filename | .file
a.c
002  SECT5  notype ()External | _a1
tag index  size  lines  next function 
004  SECT6  notype ()External | _a2
005  SECT7  notype ()External | _a3
006  SECT8  notype ()External | _a4
007  SECT1  notype   Static   | .text
Section length0, #relocs0, #linenums0, checksum0
009  SECT2  notype   Static   | .data
Section length0, #relocs0, #linenums0, checksum0
00B  SECT3  notype   Static   | .bss
Section length0, #relocs0, #linenums0, checksum0
00D  SECT4  notype   Static   | .rdata
Section length   7C, #relocs0, #linenums0, checksum0
00F  SECT5  notype   Static   | .text$a1
Section length   D9, #relocsA, #linenums0, checksum0
011  SECT6  notype   Static   | .text$a2
Section length   DC, #relocsA, #linenums0, checksum0
013  SECT7  notype   Static   | .text$a3
Section length   DC, #relocsA, #linenums0, checksum0
015  SECT8  notype   Static   | .text$a4
Section length   DC, #relocsA, #linenums0, checksum0
017  SECT9  notype   Static   | .rdata$zzz
Section length   3E, #relocs0, #linenums0, checksum0
019  UNDEF  notype ()External | _printf

String Table Size = 0x1A bytes

  Summary

   0 .bss
   0 .data
  7C .rdata
  40 .rdata$zzz
   0 .text
  DC .text$a1
  DC .text$a2
  DC .text$a3
  DC .text$a4

But out.map shows

 *(SORT(.text$*))
 .text$a1   0x623c2470   0xdc a.o
0x623c2470a1
 .text$a2   0x623c254c   0xdc a.o
0x623c254ca2
 .text$a3   0x623c2628   0xdc a.o
0x623c2628a3
 .text$a4   0x623c2704   0xdc a.o
0x623c2704a4
 .text$b1   0x623c27e0   0xdc b.o
0x623c27e0b1
 .text$b2   0x623c28bc   0xdc b.o
0x623c28bcb2
 .text$b3   0x623c2998   0xdc b.o
0x623c2998b3
 .text$b4   0x623c2a74   0xdc b.o
0x623c2a74b4


The gcc version I'm using is: gcc version 4.9.0 (i686-win32-sjlj-rev1,
Built by MinGW-W64 project)

Thanks for your help.
--
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=278785231=/4140___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] winnt.h: Use __sync_synchronize for MemoryBarrier implementation.

2016-03-19 Thread Jacek Caban

My main motivation for this patch was to ensure that the function is
always inline (not a define) in i386 case like in PSDK. Firefox (in code
imported from Chromium) depends on it by using ::MemoryBarrier() syntax,
which failed if SSE was enabled. While looking at this, I think that
__sync_synchronize is more appropriate. Non-GCC variant depends on side
effect of InterlockedOr instead of hardcoding assembly.


---
 mingw-w64-headers/include/psdk_inc/intrin-impl.h |  8 
 mingw-w64-headers/include/winnt.h| 11 +--
 2 files changed, 9 insertions(+), 10 deletions(-)


diff --git a/mingw-w64-headers/include/psdk_inc/intrin-impl.h b/mingw-w64-headers/include/psdk_inc/intrin-impl.h
index 97804fb..7b8fae0 100644
--- a/mingw-w64-headers/include/psdk_inc/intrin-impl.h
+++ b/mingw-w64-headers/include/psdk_inc/intrin-impl.h
@@ -163,14 +163,6 @@ Parameters: (IntNum)
 IntNum: Interrupt number in hex */
 #define __buildint(a) __asm__ __volatile__("int {$}" #a :)
 
-/* This macro is used by MemoryBarrier when compiling x86 w/o SSE2. 
-Note that on i386, xchg performs an implicit lock. */
-#define __buildmemorybarrier() \
-{ \
-unsigned char Barrier; \
-__asm__ __volatile__("xchg{b %%| }al, %0" :"=m" (Barrier) : /* no inputs */ : "eax", "memory"); \
-}
-
 /* This macro is used by __readfsbyte, __readfsword, __readfsdword
  __readgsbyte, __readgsword, __readgsdword, __readgsqword
 
diff --git a/mingw-w64-headers/include/winnt.h b/mingw-w64-headers/include/winnt.h
index 84eb36a..cbe34a8 100644
--- a/mingw-w64-headers/include/winnt.h
+++ b/mingw-w64-headers/include/winnt.h
@@ -1977,13 +1977,20 @@ extern "C" {
 
 #ifdef __SSE2__
 #define YieldProcessor _mm_pause
-#define MemoryBarrier _mm_mfence
 #else
 #define YieldProcessor __buildpause
+#endif
+
 VOID MemoryBarrier(VOID);
 FORCEINLINE VOID MemoryBarrier(VOID)
-__buildmemorybarrier()
+{
+#ifdef __GNUC__
+__sync_synchronize();
+#else
+LONG b;
+InterlockedOr(,0);
 #endif
+}
 
 #define PreFetchCacheLine(l,a)
 #define ReadForWriteAccess(p) (*(p))

--
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=278785231=/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] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

2016-03-19 Thread Benjamin Bihler

There is no difference in the results. I have even raised the precision of the 
number output, but my call to _controlfp_s seems not to influence the output at 
all... what does that mean? That _controlfp_s cannot be a part of the solution?

-Ursprüngliche Nachricht-
Von: K. Frank [mailto:kfrank2...@gmail.com] 
Gesendet: Donnerstag, 17. März 2016 14:40
An: mingw64
Betreff: Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic 
When Excecuted Asynchronously

Hi Benjamin!

On Thu, Mar 17, 2016 at 4:07 AM, Benjamin Bihler 
 wrote:
> Thank you for the suggestion.
>
> I have tried the following code snippets when the program starts up to set 
> the floating-point precision:
>
> ---
> unsigned int fpu_cw;
>  _controlfp_s(_cw, _PC_24, _MCW_PC);
> ---
> ...
> This does not help. Still the asynchronous thread gives different results. 
> Should I use different commands? Which ones?

I don't know anything about the details of _controlfp_s, etc., but I do have a 
debugging question.

Did any of your versions of calling _controlfp_s have any effect in that they 
changed the results produced by the main thread (even if those changed results 
did not match the results of the asynchronous thread)?

Or did your main thread still give the same results as without the _controlfp_s 
call?

Obviously, until you can change the behavior of the main thread, you can't 
change it to match the asynchronous threads.

In any event, hopefully someone on this list could tell you what call to 
_controlfp_s you need to match the floating-point environment that is getting 
set up for the asynchronous thread.  (I certainly can't.)

> Actually limiting the fp precision on the main thread would be a solution for 
> me, though it feels like a dirty workaround.

Yeah, you shouldn't have to use the less-favorable precision.  But that's the 
nature of work-arounds ...

Logically, I do think the idea should work.  Sorry i can't give you any detail 
on how to make it work.

(Of course, the better approach is to figure out how to make the child threads 
behave -- i.e., use the extended precision, and otherwise use a floating-point 
environment consistent with that of the main thread.)

Good luck.

K. Frank

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

--
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=278785231=/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] Order of -ladvapi32 versus -lkernel32

2016-03-19 Thread Vincent Torri

hello

On Fri, Mar 18, 2016 at 2:48 AM, Vitaly Kruglikov
 wrote:
>
> Carl of mingwpy suggested that I re-post this question here (originally 
> posted on https://groups.google.com/forum/#!topic/mingwpy/kHhGl3mBNfo)
>
>
> My project's CMAKE_CXX_STANDARD_LIBRARIES originally contained by default: 
> "-lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid 
> -lcomdlg32 -ladvapi32" (without the quotes).
>
> I used mingwpy (based on mingw-w64) running on Windows Server 2008 32-bit to 
> build my python extension DLL. The apr (apache portable runtime) library 
> that's linked as a static library into my extension DLL makes a call to 
> "CreateProcessAsUserW". When testing, I would get this error: "The procedure 
> entry point CreateProcessAsUserW could not be located in the dynamic link 
> library KERNEL32.dll". I found this error surprising, because 
> CreateProcessAsUserW is in advapi32, and "-ladvapi32" was listed at the end 
> of CMAKE_CXX_STANDARD_LIBRARIES, so it should have been picked up by 
> mingwpy's linker/loader. I was able to fix this failure by moving
> "-ladvapi32" to the beginning so that it was in front of "-lkernel32" like 
> so: "-ladvapi32 -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 
> -loleaut32 -luuid -lcomdlg32".
>
> However, I don't understand why it was necessary to place -ladvapi32 in front 
> of -lkernel32 to make the CreateProcessAsUserW problem go away. Does someone 
> know why this would be necessary? Is there a better way to avoid this problem?

advapi32.dll depends on kernel32.dll (you can see that with dependency
walker for example), and the order of the -l flags is important : from
right to left : the "less dependent" to the "more dependant". So pass
to the linker "-ladvapi32 -lkernel32" because advapi32.dll depends on
kernel32.dll

Vincent Torri

--
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=278785231=/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] Differentiate on MinGW-w64 and TDM-gcc

2016-03-19 Thread Gisle Vanem

I wrote: 

> In a 32-bit program if mine (while printing the version info) 
> I have stuff like: 
> 
>  extern const char *os_name (const char *vendor); 
> 
>  #if defined(__MINGW64_VERSION_MAJOR) 
>#define VENDOR os_name ("MinGW-w64") /* a new-school MinGW */ 
>  #elif defined(__MINGW32__) 
>#define VENDOR os_name ("MinGW")   /* old-school mingw.org */ 
>  #else 

(should be '#elif defined(_MSC_VER)'). 

>#define VENDOR os_name ("MSVC")   /* Some MS Visual version */ 
>  #else 
>#define VENDOR os_name ("??") 
>  #endif 
> 
>  printf ("... %s\n", VENDOR); 
> 
> - 
> 
> So how can I differentiate on your MinGW-w64 and TDM-gcc from 
> http://tdm-gcc.tdragon.net 
> 
> AFAICS, both of them defines '__MINGW64_VERSION_MAJOR'. What other 
> 'define' can I use? 
> 
> PS. for TDM-gcc this is defined in: 
>   f:/MingW32/TDM-gcc/x86_64-w64-mingw32/include/_mingw_mac.h 

*ping*. 

Are there really nobody here who can answer on this? 

PS. I'm sending via the Yahoo web-mailer (yuk!) since smtp.mail.yahoo.com 
  seems to have some issues at the moment.

-- 
--gv 

--
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=278785231=/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] Does GCC 4.9.0 supports -Wl,--gc-sections?

2016-03-19 Thread Stephen Kitt

Hi,

On Thu, 17 Mar 2016 11:50:17 +1100, YIRAN LI  wrote:
> I'm compiling on MingW-W64 and had a problem in using -Wl,--gc-setions.
> 
[...]
> 
> The gcc version I'm using is: gcc version 4.9.0 (i686-win32-sjlj-rev1,
> Built by MinGW-W64 project)

--gc-sections is handled by ld, so support for it depends on the version of
binutils you have; what does

ld -v

produce? Support for --gc-sections on COFF and PE binaries requires binutils
2.26 (although there are still some issues to be worked out).

Regards,

Stephen

--
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=278785231=/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] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

2016-03-19 Thread K. Frank

Hi Benjamin!

On Thu, Mar 17, 2016 at 4:07 AM, Benjamin Bihler
 wrote:
> Thank you for the suggestion.
>
> I have tried the following code snippets when the program starts up to set 
> the floating-point precision:
>
> ---
> unsigned int fpu_cw;
>  _controlfp_s(_cw, _PC_24, _MCW_PC);
> ---
> ...
> This does not help. Still the asynchronous thread gives different results. 
> Should I use different commands? Which ones?

I don't know anything about the details of _controlfp_s, etc., but I do
have a debugging question.

Did any of your versions of calling _controlfp_s have any effect in that
they changed the results produced by the main thread (even if those
changed results did not match the results of the asynchronous thread)?

Or did your main thread still give the same results as without the _controlfp_s
call?

Obviously, until you can change the behavior of the main thread, you can't
change it to match the asynchronous threads.

In any event, hopefully someone on this list could tell you what call to
_controlfp_s you need to match the floating-point environment that is
getting set up for the asynchronous thread.  (I certainly can't.)

> Actually limiting the fp precision on the main thread would be a solution for 
> me, though it feels like a dirty workaround.

Yeah, you shouldn't have to use the less-favorable precision.  But that's
the nature of work-arounds ...

Logically, I do think the idea should work.  Sorry i can't give you any
detail on how to make it work.

(Of course, the better approach is to figure out how to make the child
threads behave -- i.e., use the extended precision, and otherwise use
a floating-point environment consistent with that of the main thread.)

Good luck.

K. Frank

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

[Mingw-w64-public] Order of -ladvapi32 versus -lkernel32

2016-03-19 Thread Vitaly Kruglikov

Carl of mingwpy suggested that I re-post this question here (originally posted 
on https://groups.google.com/forum/#!topic/mingwpy/kHhGl3mBNfo)


My project's CMAKE_CXX_STANDARD_LIBRARIES originally contained by default: 
"-lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid 
-lcomdlg32 -ladvapi32" (without the quotes).

I used mingwpy (based on mingw-w64) running on Windows Server 2008 32-bit to 
build my python extension DLL. The apr (apache portable runtime) library that's 
linked as a static library into my extension DLL makes a call to 
"CreateProcessAsUserW". When testing, I would get this error: "The procedure 
entry point CreateProcessAsUserW could not be located in the dynamic link 
library KERNEL32.dll". I found this error surprising, because 
CreateProcessAsUserW is in advapi32, and "-ladvapi32" was listed at the end of 
CMAKE_CXX_STANDARD_LIBRARIES, so it should have been picked up by mingwpy's 
linker/loader. I was able to fix this failure by moving
"-ladvapi32" to the beginning so that it was in front of "-lkernel32" like so: 
"-ladvapi32 -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 
-luuid -lcomdlg32".

However, I don't understand why it was necessary to place -ladvapi32 in front 
of -lkernel32 to make the CreateProcessAsUserW problem go away. Does someone 
know why this would be necessary? Is there a better way to avoid this problem?

Many thanks,
Vitaly



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

[Mingw-w64-public] [PATCH 1/2] intrin-impl.h: Guard readfsdword implementation by has_builtin.

2016-03-19 Thread Jacek Caban

Signed-off-by: Jacek Caban 
---
 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 b99334b..97804fb 100644
--- a/mingw-w64-headers/include/psdk_inc/intrin-impl.h
+++ b/mingw-w64-headers/include/psdk_inc/intrin-impl.h
@@ -1448,9 +1448,11 @@ __buildreadseg(__readfsword, unsigned short, "fs", "w")
 
 #if __INTRINSIC_PROLOG(__readfsdword)
 unsigned __LONG32 __readfsdword(unsigned __LONG32 Offset);
+#if !__has_builtin(__readfsdword)
 __INTRINSICS_USEINLINE
 __buildreadseg(__readfsdword, unsigned __LONG32, "fs", "l")
 #define __INTRINSIC_DEFINED___readfsdword
+#endif
 #endif /* __INTRINSIC_PROLOG */
 
 #if __INTRINSIC_PROLOG(__writefsbyte)

--
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=278785231=/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] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

2016-03-19 Thread Carl Kleffner

Just link your example with CRT_Fp8.o:

g++ -O2 -std=gnu++11 main.cpp
\mingw64\x86_64-w64-mingw32\lib\CRT_fp8.o

With that it is ensured that the intermediate precision of the FPU is
double precision even for the main thread. In the C99 standard this is
FLT_EVAL_METHOD=1

The problem with mingw-w64 is that it defaults to FLT_EVAL_METHOD=2
(intermediate precision is long double), but new threads never starts with
FLT_EVAL_METHOD=2  per default on Windows. Hence the difference between
main thread and new thread.

C.

2016-03-17 15:45 GMT+01:00 Benjamin Bihler 
:

> There is no difference in the results. I have even raised the precision of
> the number output, but my call to _controlfp_s seems not to influence the
> output at all... what does that mean? That _controlfp_s cannot be a part of
> the solution?
>
> -Ursprüngliche Nachricht-
> Von: K. Frank [mailto:kfrank2...@gmail.com]
> Gesendet: Donnerstag, 17. März 2016 14:40
> An: mingw64
> Betreff: Re: [Mingw-w64-public] Floating-Point Operations Not
> Deterministic When Excecuted Asynchronously
>
> Hi Benjamin!
>
> On Thu, Mar 17, 2016 at 4:07 AM, Benjamin Bihler <
> benjamin.bih...@compositence.de> wrote:
> > Thank you for the suggestion.
> >
> > I have tried the following code snippets when the program starts up to
> set the floating-point precision:
> >
> > ---
> > unsigned int fpu_cw;
> >  _controlfp_s(_cw, _PC_24, _MCW_PC);
> > ---
> > ...
> > This does not help. Still the asynchronous thread gives different
> results. Should I use different commands? Which ones?
>
> I don't know anything about the details of _controlfp_s, etc., but I do
> have a debugging question.
>
> Did any of your versions of calling _controlfp_s have any effect in that
> they changed the results produced by the main thread (even if those changed
> results did not match the results of the asynchronous thread)?
>
> Or did your main thread still give the same results as without the
> _controlfp_s call?
>
> Obviously, until you can change the behavior of the main thread, you can't
> change it to match the asynchronous threads.
>
> In any event, hopefully someone on this list could tell you what call to
> _controlfp_s you need to match the floating-point environment that is
> getting set up for the asynchronous thread.  (I certainly can't.)
>
> > Actually limiting the fp precision on the main thread would be a
> solution for me, though it feels like a dirty workaround.
>
> Yeah, you shouldn't have to use the less-favorable precision.  But that's
> the nature of work-arounds ...
>
> Logically, I do think the idea should work.  Sorry i can't give you any
> detail on how to make it work.
>
> (Of course, the better approach is to figure out how to make the child
> threads behave -- i.e., use the extended precision, and otherwise use a
> floating-point environment consistent with that of the main thread.)
>
>
> Good luck.
>
>
> K. Frank
>
>
> --
> 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=278785231=/4140
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
>
>
> --
> 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=278785231=/4140
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
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=278785231=/4140___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH 2/2] wrl/client.h: Fixed a typo.

2016-03-19 Thread Jacek Caban

Signed-off-by: Jacek Caban 
---
 mingw-w64-headers/include/wrl/client.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


diff --git a/mingw-w64-headers/include/wrl/client.h b/mingw-w64-headers/include/wrl/client.h
index 5e3e0c3..83b4cb3 100644
--- a/mingw-w64-headers/include/wrl/client.h
+++ b/mingw-w64-headers/include/wrl/client.h
@@ -79,7 +79,7 @@ namespace Microsoft {
 ComPtr() throw() : ptr_(nullptr) {}
 ComPtr(decltype(nullptr)) throw() : ptr_(nullptr) {}
 
-template ComPtr(U *other) throw() : ptr_(other.ptr_) {
+template ComPtr(U *other) throw() : ptr_(other) {
 InternalAddRef();
 }
 

--
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=278785231=/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] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

2016-03-19 Thread Benjamin Bihler

Thank you for that hint! Now really the two threads behave equally! ☺

How to continue? Is it a disadvantage to default to FLT_EVAL_METHOD=1 with 
mingw-w64? Will the fix be part of the next mingw-w64 release? Then with the 
new compiler distribution, my thread will behave the same without linking to 
extra fp-related objects?
Thanks for answers and support!

Von: Carl Kleffner [mailto:cmkleff...@gmail.com]
Gesendet: Donnerstag, 17. März 2016 16:09
An: mingw-w64-public@lists.sourceforge.net
Betreff: Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic 
When Excecuted Asynchronously

Just link your example with CRT_Fp8.o:

g++ -O2 -std=gnu++11 main.cpp \mingw64\x86_64-w64-mingw32\lib\CRT_fp8.o
With that it is ensured that the intermediate precision of the FPU is double 
precision even for the main thread. In the C99 standard this is 
FLT_EVAL_METHOD=1
The problem with mingw-w64 is that it defaults to FLT_EVAL_METHOD=2 
(intermediate precision is long double), but new threads never starts with 
FLT_EVAL_METHOD=2  per default on Windows. Hence the difference between main 
thread and new thread.
C.

2016-03-17 15:45 GMT+01:00 Benjamin Bihler 
>:
There is no difference in the results. I have even raised the precision of the 
number output, but my call to _controlfp_s seems not to influence the output at 
all... what does that mean? That _controlfp_s cannot be a part of the solution?

-Ursprüngliche Nachricht-
Von: K. Frank [mailto:kfrank2...@gmail.com]
Gesendet: Donnerstag, 17. März 2016 14:40
An: mingw64
Betreff: Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic 
When Excecuted Asynchronously
Hi Benjamin!

On Thu, Mar 17, 2016 at 4:07 AM, Benjamin Bihler 
> wrote:
> Thank you for the suggestion.
>
> I have tried the following code snippets when the program starts up to set 
> the floating-point precision:
>
> ---
> unsigned int fpu_cw;
>  _controlfp_s(_cw, _PC_24, _MCW_PC);
> ---
> ...
> This does not help. Still the asynchronous thread gives different results. 
> Should I use different commands? Which ones?

I don't know anything about the details of _controlfp_s, etc., but I do have a 
debugging question.

Did any of your versions of calling _controlfp_s have any effect in that they 
changed the results produced by the main thread (even if those changed results 
did not match the results of the asynchronous thread)?

Or did your main thread still give the same results as without the _controlfp_s 
call?

Obviously, until you can change the behavior of the main thread, you can't 
change it to match the asynchronous threads.

In any event, hopefully someone on this list could tell you what call to 
_controlfp_s you need to match the floating-point environment that is getting 
set up for the asynchronous thread.  (I certainly can't.)

> Actually limiting the fp precision on the main thread would be a solution for 
> me, though it feels like a dirty workaround.

Yeah, you shouldn't have to use the less-favorable precision.  But that's the 
nature of work-arounds ...

Logically, I do think the idea should work.  Sorry i can't give you any detail 
on how to make it work.

(Of course, the better approach is to figure out how to make the child threads 
behave -- i.e., use the extended precision, and otherwise use a floating-point 
environment consistent with that of the main thread.)

Good luck.

K. Frank

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

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

--
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=278785231=/4140___
Mingw-w64-public mailing list

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

2016-03-19 Thread Benjamin Bihler

I have tried it, it does not change anything.

-Ursprüngliche Nachricht-
Von: JonY [mailto:jo...@users.sourceforge.net] 
Gesendet: Mittwoch, 16. März 2016 12:57
An: mingw-w64-public@lists.sourceforge.net
Betreff: Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic 
When Excecuted Asynchronously

On 3/15/2016 23:15, Benjamin Bihler wrote:
> I have taken commit d82c6defa723b6e7986091ce0fb74da544b9e0f6 ("Reset 
> thread floating point settings on new thread") from the master branch 
> of the mingw64 repository, compiled it and replaced the respective 
> files in the "include" and "lib" folder of the "x86_64-mingw32"
> folder of my mingww64 5.3.0 installation with the newly compiled 
> files.
> 
> Then I have compiled my sample file with this modified mingw64 
> installation. It had no effect, the two threads give different 
> results. I have checked that the executable depends only on the DLLs 
> Kernel32.dll and Msvcrt.dll.
> 
> When I add
> 
> _fpreset()
> 
> as the first command of the method that is run asynchronously, both 
> threads give the same result. But this has already been the case with 
> the unmodified mingw64 compiler (without overwriting the link binaries 
> with those from the new revision), I have checked that.
> 
> My sample is a C++ sample, since I am using the gnu++11 features.
> 
> It would be painful for me, if I had to add _fpreset() to all methods 
> that I want to run asynchronously, especially since they may be part 
> of other libraries.
> 
> Did I patch my mingw64 installation in a wrong way? Otherwise it seems 
> as if the commit mentioned above does not solve my problem.
> 
> Does anyone have another idea? Thanks!


Hi,

Can you try with the latest code? I have just moved the _fpreset call, 
hopefully it gets called correctly this time.
--
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=278785231=/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 2/2] wrl/client.h: Fixed a typo.

[Mingw-w64-public] LTO alignment warning

Re: [Mingw-w64-public] [PATCH] complex: Add clog10*.

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

Re: [Mingw-w64-public] Order of -ladvapi32 versus -lkernel32

Re: [Mingw-w64-public] [PATCH] complex: Add clog10*.

Re: [Mingw-w64-public] Differentiate on MinGW-w64 and TDM-gcc

Re: [Mingw-w64-public] Differentiate on MinGW-w64 and TDM-gcc

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[Mingw-w64-public] [PATCH] complex: Add clog10*.

[Mingw-w64-public] Does GCC 4.9.0 supports -Wl,--gc-sections?

[Mingw-w64-public] [PATCH] winnt.h: Use __sync_synchronize for MemoryBarrier implementation.

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

Re: [Mingw-w64-public] Order of -ladvapi32 versus -lkernel32

Re: [Mingw-w64-public] Differentiate on MinGW-w64 and TDM-gcc

Re: [Mingw-w64-public] Does GCC 4.9.0 supports -Wl,--gc-sections?

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[Mingw-w64-public] Order of -ladvapi32 versus -lkernel32

[Mingw-w64-public] [PATCH 1/2] intrin-impl.h: Guard readfsdword implementation by has_builtin.

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[Mingw-w64-public] [PATCH 2/2] wrl/client.h: Fixed a typo.

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

23 matches

Site Navigation

Mail list logo

Footer information