Re: [Mingw-w64-public] What belongs in winnt.h?
On 07/11/13 00:41, dw wrote: Sorry for the delay Since you always have something interesting to say, you are forgiven. Remove non-underscored (aka. __stdcall) variants from mingwex. It's exported by kernel32.dll, so we may use it if needed (or is there some compatibility reason not to?) Sounds good to me. I wasn't aware mingw-w64 handled all the exports for 32bit kernel32, but I see that it does. - For 32-bit version, I'd say that we should have inline versions, probably in winbase.h, redirecting to intrins versions. We can do this, however it is insistent with what MS does. MS maps the non-underscore x86 functions to kernel32.dll. I'm not saying that what MS does is smart, just that this would be different. If we want to force these all to use intrinsics, someone's going to have to specifically tell me to break this compatibility. We talked on IRC and I'd be in favour of that. If someone wants a reference to those functions, those will be still available via kernel32.dll. I personally don't see danger in being incompatible with MS in this case, while that may provide real perf win. Also, we already have inline, non-underscored variants in winnt.h, so if that would be problematic, we'd already know that. Kai, according to IRC talk, we're waiting for your opinion. 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] What belongs in winnt.h?
I am fine by it, as long as patches getting well tested. Kai Am 11.07.2013 04:08 schrieb Jacek Caban ja...@codeweavers.com: On 07/11/13 00:41, dw wrote: Sorry for the delay Since you always have something interesting to say, you are forgiven. Remove non-underscored (aka. __stdcall) variants from mingwex. It's exported by kernel32.dll, so we may use it if needed (or is there some compatibility reason not to?) Sounds good to me. I wasn't aware mingw-w64 handled all the exports for 32bit kernel32, but I see that it does. - For 32-bit version, I'd say that we should have inline versions, probably in winbase.h, redirecting to intrins versions. We can do this, however it is insistent with what MS does. MS maps the non-underscore x86 functions to kernel32.dll. I'm not saying that what MS does is smart, just that this would be different. If we want to force these all to use intrinsics, someone's going to have to specifically tell me to break this compatibility. We talked on IRC and I'd be in favour of that. If someone wants a reference to those functions, those will be still available via kernel32.dll. I personally don't see danger in being incompatible with MS in this case, while that may provide real perf win. Also, we already have inline, non-underscored variants in winnt.h, so if that would be problematic, we'd already know that. Kai, according to IRC talk, we're waiting for your opinion. 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 -- 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] winbase: define out Virtual* functions for Windows Store apps
Le 11/07/2013 19:01, Kai Tietz a écrit : 2013/7/10 Rafaël Carré fun...@videolan.org: --- mingw-w64-headers/include/winbase.h | 2 ++ 1 file changed, 2 insertions(+) Patch is ok. Please apply. Committed as r5947, thanks -- 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] What belongs in winnt.h?
I am fine by it, as long as patches getting well tested. I have made the change and run my test programs. Since the change was so easy and quick, I'm going to let it sit for a couple hours while I think about what I might have missed. On the plus side, I undid the changes I made to the crt. Since these are now all mapped to intrinsics in the header file, there's no need to change the startup code. If nothing else occurs to me, I'll send the final patch here in a couple hours. I saw on the IRC that a new release is pending. I have several other items I'm planning on doing related to intrinsics. Here's my list: 1) Finish InterlockedIncrement/Decrement stuff. 2) Fix broken __writegsbyte stuff. 3) Performance issues with BitTestAnd* stuff. 4) Performance issues with BitScan* stuff. 5) Update winbase.h, widl\winbase.h, widl\winnt.h and ddk\wdm.h to use intrin-impl.h. 6) Update intrinsics\*.c files that weren't fixed by other work. Since #2 is giving the wrong answer, I'd like to get at least that one included. Ideally I'd like to finish it all, but that depends on when you plan to cutoff checkins for this version. 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
[Mingw-w64-public] Problem with ld...
Hello everyone, I was previously using an old Ozkan build, from 2011-11-01. I compiled a project and when that got to the stage to use ld.exe, I got the following error: ld.exe: unrecognized option '--large-address-aware' I thought this may have been due to me using an old tool chain, so I just updated using mingw-builds-install.exe. I downloaded the GCC 4.8.1 x64 posix sjlj rev 2 package. I was able to successfully compile GMP 5.1.2, so this all seems to be working fine. I then tried to compile the original project again, and I still get the error: c:/mingw64-20130711/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld.exe: unrecognized option '--large-address-aware' When I type: ld --help I see in the output: --large-address-aware Executable supports virtual addresses greater than 2 gigabytes Also to show which ld is being used: $ which ld /c/mingw64-20130711/mingw64/bin/ld.exe The full command plus error is: gcc -O3 -fomit-frame-pointer -march=core2 -D_FILE_OFFSET_BITS=64 -DNDEBUG -D_LARGEFILE64_SOURCE -Wall -W -DMSIEVE_SVN_VERSION=\914\ -I. -Iinclude -Ignfs -Ignfs/poly -Ignfs/poly/stage1 -DNO_ZLIB demo.c -o msieve -Wl,--large-address-aware \ libmsieve.a -lgmp -lm -lpthread c:/mingw64-20130711/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld.exe: unrecognized option '--large-address-aware' c:/mingw64-20130711/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld.exe: use the --help option for usage information collect2.exe: error: ld returned 1 exit status make: *** [all] Error 1 So, I was wondering, if I'm compiling on a WinXP x64 system (inside of MSYS) and I'll be using the binary on WinXP x64 and Win7 x64, do I even need the --large-address-aware option to the MingW64 ld.exe? If so, how can I correct the above error? If not, then I can just remove the option and the compile will succeed. Thanks for any help you can provide. -David C. -- 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] Problem with ld...
于 2013/7/12 星期五 11:48, David Cleaver 写道: Hello everyone, I was previously using an old Ozkan build, from 2011-11-01. I compiled a project and when that got to the stage to use ld.exe, I got the following error: ld.exe: unrecognized option '--large-address-aware' I thought this may have been due to me using an old tool chain, so I just updated using mingw-builds-install.exe. I downloaded the GCC 4.8.1 x64 posix sjlj rev 2 package. I was able to successfully compile GMP 5.1.2, so this all seems to be working fine. I then tried to compile the original project again, and I still get the error: c:/mingw64-20130711/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld.exe: unrecognized option '--large-address-aware' When I type: ld --help I see in the output: --large-address-aware Executable supports virtual addresses greater than 2 gigabytes Also to show which ld is being used: $ which ld /c/mingw64-20130711/mingw64/bin/ld.exe The full command plus error is: gcc -O3 -fomit-frame-pointer -march=core2 -D_FILE_OFFSET_BITS=64 -DNDEBUG -D_LARGEFILE64_SOURCE -Wall -W -DMSIEVE_SVN_VERSION=\914\ -I. -Iinclude -Ignfs -Ignfs/poly -Ignfs/poly/stage1 -DNO_ZLIB demo.c -o msieve -Wl,--large-address-aware \ libmsieve.a -lgmp -lm -lpthread c:/mingw64-20130711/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld.exe: unrecognized option '--large-address-aware' c:/mingw64-20130711/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld.exe: use the --help option for usage information collect2.exe: error: ld returned 1 exit status make: *** [all] Error 1 So, I was wondering, if I'm compiling on a WinXP x64 system (inside of MSYS) and I'll be using the binary on WinXP x64 and Win7 x64, do I even need the --large-address-aware option to the MingW64 ld.exe? If so, how can I correct the above error? If not, then I can just remove the option and the compile will succeed. Thanks for any help you can provide. -David C. -Wl,--large-address-aware is only for x86 target -- Best Regards, xunxun -- 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
