Re: [Mingw-w64-public] Fix mkstemp implementation

On Wed, Mar 2, 2016 at 2:10 AM, İsmailDönmez wrote: > > Dongsheng Song writes: > > > On Tue, Mar 1, 2016 at 8:42 PM, Ismail Donmez pik7zc4d...@public.gmane.org> wrote:Hi, > > mingw-w64's current mkstemp implementation wrongly uses _O_TEMPORARY > which > >

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

I can confirm, that gcc5.3.0 also fails with this commit, see https://github.com/mingwpy/mingwpy/issues/7. carl 2016-03-01 21:31 GMT+01:00 Martell Malone : > You have my go ahead to apply. > > There is a header setting for when building gcc or rather libgcc to > specify

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

Óscar Fuentes writes: > Daniel Franzini > writes: > >> I got it. The problem is that identical code is resulting different in two >> different threads and not the fact that the code seems theoretically wrong. > > It is worse: spawning a thread affects

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

Daniel Franzini writes: > I got it. The problem is that identical code is resulting different in two > different threads and not the fact that the code seems theoretically wrong. It is worse: spawning a thread affects the results of FP operations on the main thread.

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

You have my go ahead to apply. There is a header setting for when building gcc or rather libgcc to specify that ctors and dtors are provided by the c runtime. This is usually enabled for some embedded targets. Alternatively I could only enable that when we build the crt with clang and not gcc.

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

I got it. The problem is that identical code is resulting different in two different threads and not the fact that the code seems theoretically wrong. Thanks for that. On Tue, Mar 1, 2016 at 1:18 PM, Ruben Van Boxem wrote: > 2016-03-01 16:58 GMT+01:00 Daniel Franzini

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

Hi, I think we should revert commit [ca451a] Handle __CTOR_LIST__ internally within mingw-w64 It is not ready yet and makes serious problems for GCC. Mateusz diff --git a/mingw-w64-crt/crt/gccmain.c b/mingw-w64-crt/crt/gccmain.c index ba50691..fc0e350 100644 ---

Re: [Mingw-w64-public] [PATCH] Fix data types pid_t and _pid_t for 64 bit Windows

I'm imagining something like this in a header file: pid_t __mingw_posix_getpid(); #ifdef __USE_MINGW_POSIX_PID #define getpid __mingw_posix_getpid #endif So the mingw-w64 binary (the crt?) would always provide __mingw_posix_getpid, but the user program can either use it or not depending on how

Re: [Mingw-w64-public] [PATCH] Fix data types pid_t and _pid_t for 64 bit Windows

On 03/01/2016 11:54 AM, Stefan Weil wrote: > Am 01.03.2016 um 17:31 schrieb Adrien Nader: >> Hi, >> >> I poked Kaï on IRC about that; here's the log (very slightly reformatted): >> >>> Well, I admit that I know that pid_t is on standard sdk just a 32-bit value. >>> Nevertheless there is a lot of

Re: [Mingw-w64-public] [PATCH] Fix data types pid_t and _pid_t for 64 bit Windows

On Tue, Mar 01, 2016, David Grayson wrote: > Could we add a preprocessor configuration option like > __USE_MINGW_POSIX_PID which makes getpid() actually return a pid_t > (signed 64-bit integer)? (It can be wrapped in a function named > __mingw_getpid or something.) So POSIXY projects could opt

Re: [Mingw-w64-public] [PATCH] Fix data types pid_t and _pid_t for 64 bit Windows

Could we add a preprocessor configuration option like __USE_MINGW_POSIX_PID which makes getpid() actually return a pid_t (signed 64-bit integer)? (It can be wrapped in a function named __mingw_getpid or something.) So POSIXY projects could opt in to the new behavior in their build configuration,

Re: [Mingw-w64-public] [PATCH] Fix data types pid_t and _pid_t for 64 bit Windows

On 03/01/2016 11:54 AM, Stefan Weil wrote: > Kai is absolutely right regarding the signedness. I suggest replacing > "int" by "unsigned" or "unsigned int" in my patch as DWORD and > unsigned int have the same size for Windows. Feel free to do so > before committing it (otherwise I'd have to

Re: [Mingw-w64-public] [PATCH] Fix data types pid_t and _pid_t for 64 bit Windows

Am 01.03.2016 um 17:31 schrieb Adrien Nader: > Hi, > > I poked Kaï on IRC about that; here's the log (very slightly reformatted): > >> Well, I admit that I know that pid_t is on standard sdk just a 32-bit value. >> Nevertheless there is a lot of software in FOSS, which assumes that pid_t has >>

Re: [Mingw-w64-public] Fix mkstemp implementation

Hi, Dongsheng Song writes: > > > On Tue, Mar 1, 2016 at 8:42 PM, Ismail Donmez wrote:Hi, > mingw-w64's current mkstemp implementation wrongly uses _O_TEMPORARY which > doesn't make sense. Here is a patch from openSUSE we apply to fix it: > From: Jan Engelhardt

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

You're probably running into the fact that Intel processors have floating point registers with 80 bits, and when optimization is turned on, operations are done in registers and not truncated as they are when the values are stored to memory. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Re: [Mingw-w64-public] [PATCH] Fix data types pid_t and _pid_t for 64 bit Windows

Hi, I poked Kaï on IRC about that; here's the log (very slightly reformatted): > Well, I admit that I know that pid_t is on standard sdk just a 32-bit value. > Nevertheless there is a lot of software in FOSS, which assumes that pid_t has > actually the width of a pointer, and so we decided to

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

2016-03-01 16:58 GMT+01:00 Daniel Franzini : > I think that comparing floating point numbers this way is wrong (well, at > least in C it is) because you can't never know how is the precision of this > comparison. It might be the case that in C++ the == operator is

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

Thank you for your answer, but I do not mind. What upsets me is that the method getResult behaves differently, if it runs in another thread! This shouldn’t be the case! Never, never, never ever! Or am I wrong? Von: Daniel Franzini [mailto:daniel.franz...@gmail.com] Gesendet: Dienstag, 1. März

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

I think that comparing floating point numbers this way is wrong (well, at least in C it is) because you can't never know how is the precision of this comparison. It might be the case that in C++ the == operator is overloaded and it performs correctly using some pre-defined precision constant. I'm

Re: [Mingw-w64-public] Fix mkstemp implementation

2016-03-01 15:25 GMT+01:00 Dongsheng Song : > > On Tue, Mar 1, 2016 at 8:42 PM, Ismail Donmez wrote: > >> Hi, >> >> mingw-w64's current mkstemp implementation wrongly uses _O_TEMPORARY which >> doesn't make sense. Here is a patch from openSUSE we apply

Re: [Mingw-w64-public] Fix mkstemp implementation

On Tue, Mar 1, 2016 at 8:42 PM, Ismail Donmez wrote: > Hi, > > mingw-w64's current mkstemp implementation wrongly uses _O_TEMPORARY which > doesn't make sense. Here is a patch from openSUSE we apply to fix it: > > From: Jan Engelhardt > Date: 2015-03-31

[Mingw-w64-public] Fix mkstemp implementation

Hi, mingw-w64's current mkstemp implementation wrongly uses _O_TEMPORARY which doesn't make sense. Here is a patch from openSUSE we apply to fix it: From: Jan Engelhardt Date: 2015-03-31 18:57:45.887248277 +0200 References: https://sourceforge.net/p/mingw-w64/bugs/471/ When

Re: [Mingw-w64-public] time.h : undefined reference to '_mkgmtime32'

oh, I'm sorry about formatting. It looked fine in my draft. I also observed that the installer is available for download only for the latest version. Is it available for previous versions ate other location? -Sandeep. On Tuesday, March 1, 2016 12:54 PM, Sandeep Thakkar

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

Hello, I have found a behaviour of MinGW-W64 5.3.0 that disturbs me very much: the results of floating-point operations may differ, if they are run on different threads. This does not happen with Visual Studio 2015 and not with g++ 4.9.2 on my Debian Linux. Please consider the following