Re: [Mingw-w64-public] End of rubenvb builds

2013-07-13 Thread Adrien Nader
Hi, On Fri, Jul 12, 2013, Jon wrote: On Fri, 12 Jul 2013 19:43:04 +0200 Kai Tietz ktiet...@googlemail.com wrote: a) yes, b) yes (we need people in charge for that and doing this reliable), c) yes, we are actual in discussion with mingw-builds venture to go together (and/or co-operate more

Re: [Mingw-w64-public] End of rubenvb builds

2013-07-13 Thread Ray Donnelly
- package gnustep which will help test the objc toolchain Have you seen http://www.cocotron.org/ too? On Sat, Jul 13, 2013 at 12:22 PM, Adrien Nader adr...@notk.org wrote: Hi, On Fri, Jul 12, 2013, Jon wrote: On Fri, 12 Jul 2013 19:43:04 +0200 Kai Tietz ktiet...@googlemail.com wrote: a)

Re: [Mingw-w64-public] End of rubenvb builds

2013-07-13 Thread Adrien Nader
On Sat, Jul 13, 2013, Ray Donnelly wrote: - package gnustep which will help test the objc toolchain Have you seen http://www.cocotron.org/ too? I hadn't. It's interesting but at the same time, I'm a bit worried because they mention patching ld and gcc. =/ In any case, I'll have a look at

Re: [Mingw-w64-public] Regression in trunk regarding InterlockedCompareExchange

2013-07-13 Thread Erik van Pienbroek
Erik van Pienbroek schreef op do 23-05-2013 om 23:29 [+0200]: Hi, During review of one of our Fedora packages we noticed an unexpected change in behavior in recent mingw-w64 trunk snapshots. We noticed that several libraries which were built against recent mingw-w64 trunk snapshots suddenly

Re: [Mingw-w64-public] End of rubenvb builds

2013-07-13 Thread Baruch Burstein
On Wed, Jul 10, 2013 at 5:30 PM, Jon jon.for...@gmail.com wrote: ...SNIP... But interpreting or implying or inferring is not useful. Explicit clarification from Kai and JonY as mingw-w64 leaders is needed. I suspect one reason why this hasn't happened is that both already have too much

[Mingw-w64-public] [Patch] __readfsbyte, __writefsbyte, __readgsbyte, __writegsbyte, etc

2013-07-13 Thread dw
1) Move these functions to intrin-impl.h: __readfsbyte, __readfsword, __readfsdword __writefsbyte, __writefsword, __writefsdword __readgsbyte, __readgsword, __readgsdword, __readgsqword __writegsbyte, __writegsword, __writegsdword, __writegsqword 2) Update inline asm code: *a) Change __write*

Re: [Mingw-w64-public] End of rubenvb builds

2013-07-13 Thread Adrien Nader
On Sat, Jul 13, 2013, Baruch Burstein wrote: On Wed, Jul 10, 2013 at 5:30 PM, Jon jon.for...@gmail.com wrote: But interpreting or implying or inferring is not useful. Explicit clarification from Kai and JonY as mingw-w64 leaders is needed. I suspect one reason why this hasn't happened

Re: [Mingw-w64-public] [Patch] __readfsbyte, __writefsbyte, __readgsbyte, __writegsbyte, etc

2013-07-13 Thread Kai Tietz
Hi patch looks ok to me. Beside one nit. Point 3 should not force none-inline version. Please expain why you think that is required. Kai Am 13.07.2013 15:11 schrieb dw limegreenso...@yahoo.com: 1) Move these functions to intrin-impl.h: __readfsbyte, __readfsword, __readfsdword

Re: [Mingw-w64-public] strange gcc 4.8 32bit windows target DLL behaviour

2013-07-13 Thread Dongsheng Song
On Thu, Jul 4, 2013 at 8:40 PM, Dongsheng Song dongsheng.s...@gmail.com wrote: 于 2013/7/4 17:18, Kai Tietz 写道: 2013/7/4 Dongsheng Song dongsheng.s...@gmail.com: On 2013/7/4 4:49, Earnie Boyd wrote: On Wed, Jul 3, 2013 at 12:28 PM, Dongsheng Song wrote: On Thu, Jul 4, 2013 at 12:09 AM, Kai

Re: [Mingw-w64-public] [Patch] __readfsbyte, __writefsbyte, __readgsbyte, __writegsbyte, etc

2013-07-13 Thread dw
Point 3 should not force none-inline version. Please expain why you think that is required. While I removed the inline asm from these 3 routines, the routines themselves are still __CRT_INLINE. And the routines they call are either __CRT_INLINE or __MINGW_INTRIN_INLINE. If you examine the

Re: [Mingw-w64-public] [Patch] __readfsbyte, __writefsbyte, __readgsbyte, __writegsbyte, etc

2013-07-13 Thread Kai Tietz
Thank you for your explaination. Patch is ok. Thanks Kai Am 13.07.2013 20:03 schrieb dw limegreenso...@yahoo.com: Point 3 should not force none-inline version. Please expain why you think that is required. While I removed the inline asm from these 3 routines, the routines themselves are

[Mingw-w64-public] [Patch] Jon's lib32_libmoldname patch

2013-07-13 Thread dw
Here is the patch jon_y asked for. It contains 1 change: - Add _libm_dummy.c to lib32_libmoldname_a_SOURCES and lib64_libmoldname_a_SOURCES so the archive isn't empty. This is necessary to support tools that can't process empty archives (eg flexlink on cygwin). I'm unable to produce the