Re: [Mingw-w64-public] Mass rebuild report for July 15 2013
On 07/15/13 23:50, Erik van Pienbroek wrote: mingw-wine-gecko-2.21-1 Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130715/mingw-wine-gecko-2.21-1 Also winpthreads related. Bug has already been reported upstream and a patch is pending approval: https://bugzilla.mozilla.org/show_bug.cgi?id=893444 The patch is in mozilla-central repo, so this will be included in all future wine-gecko releases. I committed a backport to wine-gecko-2.21 branch. It's commit d605ea88b1ea3bdae996a3c81679cf678415528f. SourceForge is currently broken for Wine Gecko Web git interface, so I can't give you a link directly to the patch, but you'll see it if you clone the repo: https://sourceforge.net/p/wine/wine-gecko/ci/master/tree/ (it's the same as I sent you previously). Thanks, Jacek -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Interlocked* patches follow-up
On 07/17/13 01:12, dw wrote: Please review the new patch Well, we got your good news and your bad news. On the plus side, this patch fixes the problem I was seeing with -Os. On the downside, my release build script also uses -fwhole-program. This is giving me a link error: /undefined reference to `_imp__InterlockedExchange@8.constprop.0'/ I'm using 4.8.1. The minimal set of compile switches to see this problems seems to be: -Os -fwhole-program Examining the object files with a hex editor, I see that -O1 (which works) has symbols for both _InterlockedExchange@8 and __imp__InterlockedExchange@8. -Os has _InterlockedExchange@8.constprop.0 and __imp__InterlockedExchange@8.constprop.0. Something is getting tangled here, but I'm not quite sure what. I can't reproduce it here. It looks like a GCC bug, but I'm not familiar with those constprop symbols. Maybe Kai will have some idea. Jacek -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Interlocked* patches follow-up
Kai, can you offer some compiler insight here? Something is getting tangled here, but I'm not quite sure what. I can't reproduce it here. It looks like a GCC bug, but I'm not familiar with those constprop symbols. Maybe Kai will have some idea. I've had someone else try, and they see the same error. Here's the code I'm using http://privatepaste.com/a27ce89f72. Compile for x86 with -Os -fwhole-program. Remove the -fwhole-program and it works. Even when this works, the inline code for InterlockedExchange is included in the exe AND there is a dependency on kernel32.dll. This fact makes me really uncomfortable. We're actually defining 2 implementations for the same function. And the compiler isn't just picking one, it's somehow trying to use both. I worry that even if we discover a work-around for this specific issue, it seems like we're trying to trick the compiler into doing something it normally forbids. That seldom ends well. I'd like to see this work. But I'm starting to lean back towards just using the imports for x86. dw -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ 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] _bittest, _bittestandset, etc
Ping. These have nothing to do with the boost/Interlocked* issues. dw On 7/15/2013 2:37 PM, dw wrote: 1) Move these functions to intrin-impl.h: _bittest, _bittest64 _bittestandset, _bittestandreset, _bittestandcomplement _bittestandset64, _bittestandreset64, _bittestandcomplement64 2) Update inline asm code: *a) Remove memory clobber*. *b) Remove volatile keyword.* c) Several changes to inputs, outputs, and constraints. d) add cc clobber. e) Use symbolic names. f) Support both att and intel asm formats. dw -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Interlocked* patches follow-up
Hi this issue seems t be related to a bug fixed for gcc' trunk and for the 4.8 branch. Could you test more recent version to see if issue remains? Kai Am 17.07.2013 14:14 schrieb dw limegreenso...@yahoo.com: Kai, can you offer some compiler insight here? Something is getting tangled here, but I'm not quite sure what. I can't reproduce it here. It looks like a GCC bug, but I'm not familiar with those constprop symbols. Maybe Kai will have some idea. I've had someone else try, and they see the same error. Here's the code I'm using http://privatepaste.com/a27ce89f72. Compile for x86 with -Os -fwhole-program. Remove the -fwhole-program and it works. Even when this works, the inline code for InterlockedExchange is included in the exe AND there is a dependency on kernel32.dll. This fact makes me really uncomfortable. We're actually defining 2 implementations for the same function. And the compiler isn't just picking one, it's somehow trying to use both. I worry that even if we discover a work-around for this specific issue, it seems like we're trying to trick the compiler into doing something it normally forbids. That seldom ends well. I'd like to see this work. But I'm starting to lean back towards just using the imports for x86. dw -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
