date:20160301

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

2016-03-01 Thread Dongsheng Song

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
> > 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 closing the file handle obtained from mkstemp(), the file
> > ought _not_ to be deleted.
> >
> >
> > Why did you make such assertion ?
> >
> > I can not see such statement in POSIX, Linux, FreeBSD or OpenBSD:
> >
> > http://pubs.opengroup.org/onlinepubs/009695399/functions/mkstemp.html
> > http://man7.org/linux/man-pages/man3/mkstemp.3.html
> > https://www.freebsd.org/cgi/man.cgi?query=mkstemp
>
> I just tested the relevant Windows function _mkstemp_s
> (https://msdn.microsoft.com/en-us/library/t8ex5e91.aspx) and it does not
> remove the temp file on close.
>
> Also tested on Linux with glibc 2.22 and it doesn't remove the temporary
> file either.
>
> So mingw-w64's current behaviour is not compatible with any of them. IMHO
> patch should be applied.
>

OK, for compatible reason, I have no objections now.

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

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

2016-03-01 Thread Carl Kleffner

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 that ctors and dtors are provided by the c runtime.
> This is usually enabled for some embedded targets.
>
> Alternatively I could only enable that when we build the crt with clang
> and not gcc.
> This would then mean that we can't use compiler-rt with mingw-w64 crt
> built with gcc and that we can't use libgcc with a clang built mingw-w64
> crt.
> I can probably live with that.
>
> The correct fix would be to upstream a patch into libgcc to assume it is
> external from now on.
> Might be hard to get that merged because of legacy support though.
>
> I will provide a follow up patch to enable this only when building with
> clang
>
> On Tue, Mar 1, 2016 at 12:25 PM, Mateusz  wrote:
>
>> Hi,
>>
>> I think we should revert commit [ca451a] Handle __CTOR_LIST__ internally
>> within mingw-w64
>>
>> It is not ready yet and makes serious problems for GCC.
>>
>> Mateusz
>>
>>
>>
>> --
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>>
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

2016-03-01 Thread Óscar Fuentes

Ó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 the results of FP operations on
> the main thread. Please note that the example compares the results of
> two consecutive runs on the main thread.

Sorry, I misread the example code. It is comparing the result of the
main thread with the result of the new thread. Anyways, this is still
valid:

> This looks bad indeed.


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

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

2016-03-01 Thread Óscar Fuentes

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. Please note that the example compares the results of
two consecutive runs on the main thread.

This looks bad indeed.


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

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

2016-03-01 Thread Martell Malone

You have my go ahead to apply.

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

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

The correct fix would be to upstream a patch into libgcc to assume it is
external from now on.
Might be hard to get that merged because of legacy support though.

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

On Tue, Mar 1, 2016 at 12:25 PM, Mateusz  wrote:

> Hi,
>
> I think we should revert commit [ca451a] Handle __CTOR_LIST__ internally
> within mingw-w64
>
> It is not ready yet and makes serious problems for GCC.
>
> Mateusz
>
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

2016-03-01 Thread Daniel Franzini

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 :
>
>> 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
>> note sure about that.
>>
>> if (b == c)
>> continue;
>>
>
> That is true in general, but here, it is used to compare the output of
> identical code.
>
> The fact that this produces different outcomes on different threads has to
> do with Windows' floating point settings on thread creation and the way
> MinGW-w64 handles it (C++ threads are handled through pthread):
>
> https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/CAGGsPMz%3D5w-2X_7bGSgWjEzyQFuwtBVCR%2BOm%3Dr-OA_zp8E2KdQ%40mail.gmail.com/#msg3303
> more precisely:
> https://sourceforge.net/p/mingw-w64/mailman/message/33080317/
>
> I don't remember what the wanted behaviour is. I do know this is probably
> the cause for your inconsistency.
>
> Ruben
>
>
>> On Tue, Mar 1, 2016 at 9:04 AM, Benjamin Bihler <
>> benjamin.bih...@compositence.de> wrote:
>>
>>> 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 program:
>>>
>>> -
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>>
>>> std::string getResult()
>>> {
>>> std::cout << "Thread id: " << std::this_thread::get_id() <<
>>> std::endl;
>>> std::string result = "Result:\n";
>>>
>>> double a, b, c;
>>> int i;
>>> for (i = 0, a = 1.0; i < 1000; i++)
>>> {
>>> a *= 1.0001;
>>> b = sqrt(a);
>>> c = pow(a, 0.5);
>>> if (b == c)
>>> continue;
>>> result += std::string("a: ") + std::to_string(a) + " b: "
>>> + std::to_string(b) + " c: " +
>>> std::to_string(c) + "\n";
>>> }
>>>
>>> return result;
>>> }
>>>
>>> int main()
>>> {
>>> std::string string1 = getResult();
>>>
>>> std::future result = std::async(std::launch::async,
>>> getResult);
>>>
>>> std::string string2 = result.get();
>>>
>>> if (string1 != string2)
>>> {
>>> std::cout << "String 1 is: " << std::endl << string1 <<
>>> std::endl
>>> << " and string 2 is: " << std::endl <<
>>> string2 << std::endl;
>>> }
>>> else
>>> {
>>> std::cout << "The results are the same." << std::endl;
>>> }
>>>
>>> return 0;
>>> }
>>> -
>>>
>>> If I compile it with g++ -O0 -std=gnu++11 Main.cpp the output is
>>>
>>> -
>>> Thread id: 1
>>> Thread id: 2
>>> The results are the same.
>>> -
>>>
>>> If I compile it with g++ -O1 -std=gnu++11 Main.cpp the output is
>>> -
>>> Thread id: 1
>>> Thread id: 2
>>> String 1 is: ...
>>> -
>>>
>>> The same happens with "-O2".
>>>
>>> If I change the line
>>> std::future result = std::async(std::launch::async,
>>> getResult);
>>> to
>>> std::future result = std::async(getResult);
>>> then the result is independent from the optimization flag the following:
>>>
>>> -
>>> Thread id: 1
>>> Thread id: 1
>>> The results are the same.
>>> -
>>>
>>> What actually disturbs me, is that the results differ with asynchronous
>>> execution and optimization turned on. I tried parameters like -ffloat-store
>>> -msse2 -mfpmath=sse to have consistent floating-point operation results,
>>> but this won't help.
>>>
>>> Is this a bug? Or are there compiler flags that force the floating-point
>>> operation results to be consistent?
>>>
>>> Any help is greatly appreciated!
>>>
>>> Regards,
>>> Benjamin
>>>
>>>
>>> --
>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>> Monitor

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

2016-03-01 Thread Mateusz


Hi,

I think we should revert commit [ca451a] Handle __CTOR_LIST__ internally 
within mingw-w64


It is not ready yet and makes serious problems for GCC.

Mateusz

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

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

2016-03-01 Thread David Grayson

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 it is built.

Wasn't __USE_MINGW_ANSI_STDIO implemented without making two ABIs?

--David

On Tue, Mar 1, 2016 at 11:31 AM, Adrien Nader  wrote:
> 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 in to the
>> new behavior in their build configuration, and Windowsy projects would
>> keep working as is?  It would be like __USE_MINGW_ANSI_STDIO.
>
> Wouldn't that mean two ABIs? Sounds difficult to balance.
>
> --
> Adrien Nader

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

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

2016-03-01 Thread Eric Blake

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 software in FOSS, which assumes that pid_t 
>>> has
>>> actually the width of a pointer, and so we decided to make pidt_t on Windows
>>> 64-bit.

That feels wrong.  pid_t should be the same width as whatever gets
returned by getpid(), NOT the same as void*.  I'd rather fix broken FOSS
that incorrectly tries to treat pid_t and void* as synonyms than create
a worse situation by making pid_t incompatible with its real use.

>>> Nevertheless assuming that pid_t is an int, is also wrong on Windows.
>>> It is actually a DWORD.  See GetThreadId (or something like that is the API 
>>> of
>>> Win32).

Isn't sizeof(DWORD) == sizeof(int) for both 32- and 64-bit Windows?  If
so, then there's your answer - pid_t should be 32-bit.

>>> So negative values are nothing to be concerned about at all.

Not for a process id, but there are other interfaces which REQUIRE pid_t
to have negative values to operate on an entire process group.  Whether
those interfaces can be mapped to Windows is a different question, but
pid_t itself needs to be correctly typed for what you DO map to Windows.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org

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

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

2016-03-01 Thread Adrien Nader

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 in to the
> new behavior in their build configuration, and Windowsy projects would
> keep working as is?  It would be like __USE_MINGW_ANSI_STDIO.

Wouldn't that mean two ABIs? Sounds difficult to balance.

-- 
Adrien Nader

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

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

2016-03-01 Thread David Grayson

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, and Windowsy projects would
keep working as is?  It would be like __USE_MINGW_ANSI_STDIO.

--David

On Tue, Mar 1, 2016 at 11:08 AM, Eric Blake  wrote:
> 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 resend it). It's a pity
>> that getpid() still has to return an int (because of compatibility
>> with the MS getpid()) instead of the normal pid_t.
>
> NACK.  POSIX requires pid_t to be signed.
>
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html#tag_13_67
>
> blksize_t, pid_t, and ssize_t shall be signed integer types.
>
>
>>
>> A short look at the Mingw-w64 code shows several type casts from
>> pid_t to DWORD. This code will continue to work with my patch,
>> but the type casts are no longer needed.
>>
>> Regards,
>> Stefan
>>
>
> --
> Eric Blake   eblake redhat com+1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

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

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

2016-03-01 Thread Eric Blake

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 resend it). It's a pity
> that getpid() still has to return an int (because of compatibility
> with the MS getpid()) instead of the normal pid_t.

NACK.  POSIX requires pid_t to be signed.

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html#tag_13_67

blksize_t, pid_t, and ssize_t shall be signed integer types.


> 
> A short look at the Mingw-w64 code shows several type casts from
> pid_t to DWORD. This code will continue to work with my patch,
> but the type casts are no longer needed.
> 
> Regards,
> Stefan
> 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



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

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

2016-03-01 Thread Stefan Weil

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
>> actually the width of a pointer, and so we decided to make pidt_t on Windows
>> 64-bit.
>> Nevertheless assuming that pid_t is an int, is also wrong on Windows.
>> It is actually a DWORD.  See GetThreadId (or something like that is the API 
>> of
>> Win32).
>> So negative values are nothing to be concerned about at all.
>> API is GetCurrentThreadId()
>> I am openminded here, but we might need to expect fallout by this change.
>> Not sure if this is worth the change.

IMHO most FOSS programs with assumptions typically fail when
assuming that sizeof(long) == sizeof(void *). I assume that all
programs which assume that sizeof(pid_t) == sizeof(void *)
fall into this category, so pid_t will be their least problem
when they do a port to 64 bit Windows. :-)

Programs which clean their code while porting to Windows
try to use standard interfaces (like QEMU did). Using pid_t
and assuming that standard functions like getpid return
a pid_t value is typically part of that cleaning, but will fail
today for getpid because of the wrong pid_t size.

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 resend it). It's a pity
that getpid() still has to return an int (because of compatibility
with the MS getpid()) instead of the normal pid_t.

A short look at the Mingw-w64 code shows several type casts from
pid_t to DWORD. This code will continue to work with my patch,
but the type casts are no longer needed.

Regards,
Stefan



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

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

2016-03-01 Thread İsmailDönmez

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 
> Date: 2015-03-31 18:57:45.887248277 +0200
> References: https://sourceforge.net/p/mingw-w64/bugs/471/
> When closing the file handle obtained from mkstemp(), the file
> ought _not_ to be deleted.
> 
> 
> Why did you make such assertion ?
> 
> I can not see such statement in POSIX, Linux, FreeBSD or OpenBSD:
> 
> http://pubs.opengroup.org/onlinepubs/009695399/functions/mkstemp.html
> http://man7.org/linux/man-pages/man3/mkstemp.3.html
> https://www.freebsd.org/cgi/man.cgi?query=mkstemp

I just tested the relevant Windows function _mkstemp_s 
(https://msdn.microsoft.com/en-us/library/t8ex5e91.aspx) and it does not 
remove the temp file on close.

Also tested on Linux with glibc 2.22 and it doesn't remove the temporary 
file either.

So mingw-w64's current behaviour is not compatible with any of them. IMHO 
patch should be applied.

Thanks,
Ismail



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

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

2016-03-01 Thread Burkhardt, Glenn B UTAS

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  Notice the number of 
duplicated reports - it's a surprise to a lot of people.

There are ways to set the precision used by the FPU, e.g.,

#include "fpu_control.h"

fpu_control_t cw;
_FPU_GETCW(cw);
cw &= ~_FPU_EXTENDED;
cw |= _FPU_DOUBLE;
_FPU_SETCW(cw);


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

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

2016-03-01 Thread 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
> actually the width of a pointer, and so we decided to make pidt_t on Windows
> 64-bit.
> Nevertheless assuming that pid_t is an int, is also wrong on Windows.
> It is actually a DWORD.  See GetThreadId (or something like that is the API of
> Win32).
> So negative values are nothing to be concerned about at all.
> API is GetCurrentThreadId()
> I am openminded here, but we might need to expect fallout by this change.
> Not sure if this is worth the change.

--
Adrien Nader

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

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

2016-03-01 Thread Ruben Van Boxem

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 overloaded
> and it performs correctly using some pre-defined precision constant. I'm
> note sure about that.
>
> if (b == c)
> continue;
>

That is true in general, but here, it is used to compare the output of
identical code.

The fact that this produces different outcomes on different threads has to
do with Windows' floating point settings on thread creation and the way
MinGW-w64 handles it (C++ threads are handled through pthread):
https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/CAGGsPMz%3D5w-2X_7bGSgWjEzyQFuwtBVCR%2BOm%3Dr-OA_zp8E2KdQ%40mail.gmail.com/#msg3303
more precisely:
https://sourceforge.net/p/mingw-w64/mailman/message/33080317/

I don't remember what the wanted behaviour is. I do know this is probably
the cause for your inconsistency.

Ruben


> On Tue, Mar 1, 2016 at 9:04 AM, Benjamin Bihler <
> benjamin.bih...@compositence.de> wrote:
>
>> 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 program:
>>
>> -
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>>
>> std::string getResult()
>> {
>> std::cout << "Thread id: " << std::this_thread::get_id() <<
>> std::endl;
>> std::string result = "Result:\n";
>>
>> double a, b, c;
>> int i;
>> for (i = 0, a = 1.0; i < 1000; i++)
>> {
>> a *= 1.0001;
>> b = sqrt(a);
>> c = pow(a, 0.5);
>> if (b == c)
>> continue;
>> result += std::string("a: ") + std::to_string(a) + " b: "
>> + std::to_string(b) + " c: " +
>> std::to_string(c) + "\n";
>> }
>>
>> return result;
>> }
>>
>> int main()
>> {
>> std::string string1 = getResult();
>>
>> std::future result = std::async(std::launch::async,
>> getResult);
>>
>> std::string string2 = result.get();
>>
>> if (string1 != string2)
>> {
>> std::cout << "String 1 is: " << std::endl << string1 <<
>> std::endl
>> << " and string 2 is: " << std::endl <<
>> string2 << std::endl;
>> }
>> else
>> {
>> std::cout << "The results are the same." << std::endl;
>> }
>>
>> return 0;
>> }
>> -
>>
>> If I compile it with g++ -O0 -std=gnu++11 Main.cpp the output is
>>
>> -
>> Thread id: 1
>> Thread id: 2
>> The results are the same.
>> -
>>
>> If I compile it with g++ -O1 -std=gnu++11 Main.cpp the output is
>> -
>> Thread id: 1
>> Thread id: 2
>> String 1 is: ...
>> -
>>
>> The same happens with "-O2".
>>
>> If I change the line
>> std::future result = std::async(std::launch::async,
>> getResult);
>> to
>> std::future result = std::async(getResult);
>> then the result is independent from the optimization flag the following:
>>
>> -
>> Thread id: 1
>> Thread id: 1
>> The results are the same.
>> -
>>
>> What actually disturbs me, is that the results differ with asynchronous
>> execution and optimization turned on. I tried parameters like -ffloat-store
>> -msse2 -mfpmath=sse to have consistent floating-point operation results,
>> but this won't help.
>>
>> Is this a bug? Or are there compiler flags that force the floating-point
>> operation results to be consistent?
>>
>> Any help is greatly appreciated!
>>
>> Regards,
>> Benjamin
>>
>>
>> --
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>
>
>
> --
> Daniel
>
> "Let us

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

2016-03-01 Thread Benjamin Bihler

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 2016 16:58
An: mingw-w64-public@lists.sourceforge.net
Betreff: 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 note sure 
about that.

if (b == c)
continue;

On Tue, Mar 1, 2016 at 9:04 AM, Benjamin Bihler 
> wrote:
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 program:

-
#include 
#include 
#include 
#include 
#include 

std::string getResult()
{
std::cout << "Thread id: " << std::this_thread::get_id() << std::endl;
std::string result = "Result:\n";

double a, b, c;
int i;
for (i = 0, a = 1.0; i < 1000; i++)
{
a *= 1.0001;
b = sqrt(a);
c = pow(a, 0.5);
if (b == c)
continue;
result += std::string("a: ") + std::to_string(a) + " b: "
+ std::to_string(b) + " c: " + 
std::to_string(c) + "\n";
}

return result;
}

int main()
{
std::string string1 = getResult();

std::future result = std::async(std::launch::async, 
getResult);

std::string string2 = result.get();

if (string1 != string2)
{
std::cout << "String 1 is: " << std::endl << string1 << 
std::endl
<< " and string 2 is: " << std::endl << string2 
<< std::endl;
}
else
{
std::cout << "The results are the same." << std::endl;
}

return 0;
}
-

If I compile it with g++ -O0 -std=gnu++11 Main.cpp the output is

-
Thread id: 1
Thread id: 2
The results are the same.
-

If I compile it with g++ -O1 -std=gnu++11 Main.cpp the output is
-
Thread id: 1
Thread id: 2
String 1 is: ...
-

The same happens with "-O2".

If I change the line
std::future result = std::async(std::launch::async, 
getResult);
to
std::future result = std::async(getResult);
then the result is independent from the optimization flag the following:

-
Thread id: 1
Thread id: 1
The results are the same.
-

What actually disturbs me, is that the results differ with asynchronous 
execution and optimization turned on. I tried parameters like -ffloat-store 
-msse2 -mfpmath=sse to have consistent floating-point operation results, but 
this won't help.

Is this a bug? Or are there compiler flags that force the floating-point 
operation results to be consistent?

Any help is greatly appreciated!

Regards,
Benjamin

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



--
Daniel

"Let us change our traditional attitude to the construction of programs. 
Instead of imagining that our main task is to instruct a computer what to do, 
let us concentrate rather on explaining to human beings what we want a computer 
to do." (Donald Knuth)

"Yes, technogeeks can be funny, even if only to each other." 
(http://www.boogieonline.com/revolution/science/humor/)"

"Man is driven to create; I know I really love to create things. And while I'm 
not good at painting, drawing, or music, I can write software." (Yukihiro

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

2016-03-01 Thread 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 overloaded
and it performs correctly using some pre-defined precision constant. I'm
note sure about that.

if (b == c)
continue;

On Tue, Mar 1, 2016 at 9:04 AM, Benjamin Bihler <
benjamin.bih...@compositence.de> wrote:

> 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 program:
>
> -
> #include 
> #include 
> #include 
> #include 
> #include 
>
> std::string getResult()
> {
> std::cout << "Thread id: " << std::this_thread::get_id() <<
> std::endl;
> std::string result = "Result:\n";
>
> double a, b, c;
> int i;
> for (i = 0, a = 1.0; i < 1000; i++)
> {
> a *= 1.0001;
> b = sqrt(a);
> c = pow(a, 0.5);
> if (b == c)
> continue;
> result += std::string("a: ") + std::to_string(a) + " b: "
> + std::to_string(b) + " c: " +
> std::to_string(c) + "\n";
> }
>
> return result;
> }
>
> int main()
> {
> std::string string1 = getResult();
>
> std::future result = std::async(std::launch::async,
> getResult);
>
> std::string string2 = result.get();
>
> if (string1 != string2)
> {
> std::cout << "String 1 is: " << std::endl << string1 <<
> std::endl
> << " and string 2 is: " << std::endl <<
> string2 << std::endl;
> }
> else
> {
> std::cout << "The results are the same." << std::endl;
> }
>
> return 0;
> }
> -
>
> If I compile it with g++ -O0 -std=gnu++11 Main.cpp the output is
>
> -
> Thread id: 1
> Thread id: 2
> The results are the same.
> -
>
> If I compile it with g++ -O1 -std=gnu++11 Main.cpp the output is
> -
> Thread id: 1
> Thread id: 2
> String 1 is: ...
> -
>
> The same happens with "-O2".
>
> If I change the line
> std::future result = std::async(std::launch::async,
> getResult);
> to
> std::future result = std::async(getResult);
> then the result is independent from the optimization flag the following:
>
> -
> Thread id: 1
> Thread id: 1
> The results are the same.
> -
>
> What actually disturbs me, is that the results differ with asynchronous
> execution and optimization turned on. I tried parameters like -ffloat-store
> -msse2 -mfpmath=sse to have consistent floating-point operation results,
> but this won't help.
>
> Is this a bug? Or are there compiler flags that force the floating-point
> operation results to be consistent?
>
> Any help is greatly appreciated!
>
> Regards,
> Benjamin
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>



-- 
Daniel

"Let us change our traditional attitude to the construction of programs.
Instead of imagining that our main task is to instruct a computer what to
do, let us concentrate rather on explaining to human beings what we want a
computer to do." (Donald Knuth)

"Yes, technogeeks can be funny, even if only to each other." (
http://www.boogieonline.com/revolution/science/humor/)"

"Man is driven to create; I know I really love to create things. And while
I'm not good at painting, drawing, or music, I can write software."
(Yukihiro Matsumoto, a.k.a. ``Matz'')
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user

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

2016-03-01 Thread Ruben Van Boxem

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 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 closing the file handle obtained from mkstemp(), the file
>> ought _not_ to be deleted.
>>
>
> Why did you make such assertion ?
>
> I can not see such statement in POSIX, Linux, FreeBSD or OpenBSD:
>
> http://pubs.opengroup.org/onlinepubs/009695399/functions/mkstemp.html
> http://man7.org/linux/man-pages/man3/mkstemp.3.html
> https://www.freebsd.org/cgi/man.cgi?query=mkstemp
> http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/mkdtemp.3
>

There is also no a priori reason to delete it. POSIX also gives an as-if
clause in the latest version of the document you linked:
http://pubs.opengroup.org/onlinepubs/9699919799/

open(pathname, O_RDWR|O_CREAT|O_EXCL, S_IRUSR|S_IWUSR)

Which does not include the Windows-specific _O_TEMPORARY as in MinGW-w64.

Why do you think deleting it is an added value? This function can therefore
also used to create a file that will later be moved, see e.g.
http://stackoverflow.com/a/12008368/256138

So, IMHO, the patch is correct.

Ruben


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

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

2016-03-01 Thread 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 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 closing the file handle obtained from mkstemp(), the file
> ought _not_ to be deleted.
>

Why did you make such assertion ?

I can not see such statement in POSIX, Linux, FreeBSD or OpenBSD:

http://pubs.opengroup.org/onlinepubs/009695399/functions/mkstemp.html
http://man7.org/linux/man-pages/man3/mkstemp.3.html
https://www.freebsd.org/cgi/man.cgi?query=mkstemp
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/mkdtemp.3
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Fix mkstemp implementation

2016-03-01 Thread Ismail Donmez

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 closing the file handle obtained from mkstemp(), the file
ought _not_ to be deleted.
---
 misc/mkstemp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: mingw-w64-crt/misc/mkstemp.c
===
--- mingw-w64-crt.orig/misc/mkstemp.c
+++ mingw-w64-crt/misc/mkstemp.c
@@ -48,7 +48,7 @@ int __cdecl mkstemp (char *template_name
 template_name[j] = letters[rand () % 62];
 }
 fd = _sopen(template_name,
-_O_RDWR | _O_CREAT | _O_EXCL | _O_TEMPORARY | _O_BINARY,
+_O_RDWR | _O_CREAT | _O_EXCL | _O_BINARY,
 _SH_DENYRW, _S_IREAD | _S_IWRITE);
 if (fd != -1) return fd;
 if (fd == -1 && errno != EEXIST) return -1;


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

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

2016-03-01 Thread Sandeep Thakkar

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

 I have dowloaded mingw-builds which Toolchains targeting Win32 from below link.
https://sourceforge.net/ projects/mingw-w64/files/ Toolchains%20targetting% 
20Win32/Personal%20Builds/ mingw-builds/4.9.3/threads- win32/dwarf/ and 
building the open source package pgbouncer sources and seeing the following 
linking error:
.objs/pgbouncer/lib/usual/ time.o: In function 
`mkgmtime':C:/mingw32/i686-w64-mingw32/ include/time.h:220: undefined reference 
to `_mkgmtime32'collect2.exe: error: ld returned 1 exit status
I tried with another builds @ https://sourceforge.net/ 
projects/mingw-w64/files/ Toolchains%20targetting% 20Win32/Personal%20Builds/ 
rubenvb/gcc-4.7-release/
and the package built fine. 
The difference between the two builds I observed is that the _mkgmtime32 is 
present in libmsvcrt.a of the builds in the second path. Why is to so? Which is 
the correct path to pick the mingw builds?
-Sandeep



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

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

2016-03-01 Thread Benjamin Bihler

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

-
#include 
#include 
#include 
#include 
#include 

std::string getResult()
{
std::cout << "Thread id: " << std::this_thread::get_id() << std::endl;
std::string result = "Result:\n";

double a, b, c;
int i;
for (i = 0, a = 1.0; i < 1000; i++)
{
a *= 1.0001;
b = sqrt(a);
c = pow(a, 0.5);
if (b == c)
continue;
result += std::string("a: ") + std::to_string(a) + " b: "
+ std::to_string(b) + " c: " + 
std::to_string(c) + "\n";
}

return result;
}

int main()
{
std::string string1 = getResult();

std::future result = std::async(std::launch::async, 
getResult);

std::string string2 = result.get();

if (string1 != string2)
{
std::cout << "String 1 is: " << std::endl << string1 << 
std::endl
<< " and string 2 is: " << std::endl << string2 
<< std::endl;
}
else
{
std::cout << "The results are the same." << std::endl;
}

return 0;
}
-

If I compile it with g++ -O0 -std=gnu++11 Main.cpp the output is

-
Thread id: 1
Thread id: 2
The results are the same.
-

If I compile it with g++ -O1 -std=gnu++11 Main.cpp the output is
-
Thread id: 1
Thread id: 2
String 1 is: ...
-

The same happens with "-O2".

If I change the line
std::future result = std::async(std::launch::async, 
getResult);
to
std::future result = std::async(getResult);
then the result is independent from the optimization flag the following:

-
Thread id: 1
Thread id: 1
The results are the same.
-

What actually disturbs me, is that the results differ with asynchronous 
execution and optimization turned on. I tried parameters like -ffloat-store 
-msse2 -mfpmath=sse to have consistent floating-point operation results, but 
this won't help.

Is this a bug? Or are there compiler flags that force the floating-point 
operation results to be consistent?

Any help is greatly appreciated!

Regards,
Benjamin

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Mingw-w64-public] Fix mkstemp implementation

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

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

24 matches

Site Navigation

Mail list logo

Footer information