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

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

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

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

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

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 ---

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-public] [PATCH 1/2] intrin-impl.h: Guard __readfsdword implementation by __has_builtin.

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 ---

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

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

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

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

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

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__) >

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

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

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

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

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

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

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

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

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?

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

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

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:) > Hi, Style wise, I have no problems with it, but please expand the commit message a bit. Otherwise, OK from me. 0xD4EBC740.asc Description:

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

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

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

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

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

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;

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

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

[Mingw-w64-public] LTO alignment warning

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) =

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

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

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

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

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

-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