Re: [Mingw-w64-public] MinGW-w64 (64-bit/POSIX/SEH) Based on GCC 4.8.0 Regression with -O3 flag (Spotted on QtCore 4.8.5)
2013/7/3 Alexey Pavlov alex...@gmail.com This is known problem. See https://bugreports.qt-project.org/browse/QTBUG-29099. It for Qt5 but for Qt4 is the same. You can't now use -O3 with mingw toolchains based on gcc-4.7.3+. That issue seems unrelated. And it might be fixable by linking the 32-bit GCC compiler executables with -Wl,--enable-large-address-aware. Regards, Alexey. 2013/7/3 Haroogan haroo...@gmail.com: Hello, The problem is as follows. Building Qt 4.8.5 with x64-4.8.0-release-posix-seh-rev2 (from the MinGW-builds project) distribution and supplying -O3 optimization flag results in QtCore4.dll crashing very frequently (almost always). Rebuilding QtCore4.dll with -O2 optimization flag immediately solves the issue. Of course the debug variant QtCored4.dll works just fine (as only -g is supplied). Please, look into it. In particular, does the issue show up for the newest 4.8.1 releases? If not, then I guess we shouldn't worry much as it is fixed, otherwise it should definitely be investigated. Currently, I haven't time to try 4.8.1 out myself. Why do I consider it as regression? Obviously because it was not the case with MinGW-w64 based on GCC 4.7.1. The only slightly sensible way to fix this is either hunt down a commit in GCC that caused the issue, or try to compile with -O3 -g3, although the resulting backtrace is most likely very hard to interpret. Ruben Kind regards, Haroogan -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MinGW-w64 (64-bit/POSIX/SEH) Based on GCC 4.8.0 Regression with -O3 flag (Spotted on QtCore 4.8.5)
2013/7/3 Ruben Van Boxem: That issue seems unrelated. And it might be fixable by linking the 32-bit GCC compiler executables with -Wl,--enable-large-address-aware. or binutils executables? -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MinGW-w64 (64-bit/POSIX/SEH) Based on GCC 4.8.0 Regression with -O3 flag (Spotted on QtCore 4.8.5)
2013/7/3 niXman i.nix...@gmail.com: 2013/7/3 Ruben Van Boxem: That issue seems unrelated. And it might be fixable by linking the 32-bit GCC compiler executables with -Wl,--enable-large-address-aware. or binutils executables? Mingw-builds binutils already built with this flags. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MinGW-w64 (64-bit/POSIX/SEH) Based on GCC 4.8.0 Regression with -O3 flag (Spotted on QtCore 4.8.5)
2013/7/3 Alexey Pavlov: Mingw-builds binutils already built with this flags. I know. I wanted to make sure that Ruben confused nothing. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MinGW-w64 (64-bit/POSIX/SEH) Based on GCC 4.8.0 Regression with -O3 flag (Spotted on QtCore 4.8.5)
2013/7/3 niXman: 2013/7/3 Alexey Pavlov: Mingw-builds binutils already built with this flags. I know. I wanted to make sure that Ruben confused nothing. Can anybody say with certainty whether this flag is needed to build GCC? -- Regards, niXman ___ Dual-target(32 64-bit) MinGW compilers for 32 and 64-bit Windows: http://sourceforge.net/projects/mingwbuilds/ ___ Another online IDE: http://liveworkspace.org/ -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MinGW-w64 (64-bit/POSIX/SEH) Based on GCC 4.8.0 Regression with -O3 flag (Spotted on QtCore 4.8.5)
2013/7/3 niXman i.nix...@gmail.com 2013/7/3 Alexey Pavlov: Mingw-builds binutils already built with this flags. I know. I wanted to make sure that Ruben confused nothing. The bug report clearly shows it is not ld.exe that is running out of memory, but cc1plus.exe: cc1plus.exe: out of memory allocating 279536 bytes So linking the GCC compiler executables with that flag might give it enough address space. Nonetheless, there must be some huge inefficiency in GCC leading to this problem in the first place. Ruben -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MinGW-w64 (64-bit/POSIX/SEH) Based on GCC 4.8.0 Regression with -O3 flag (Spotted on QtCore 4.8.5)
2013/7/3 niXman i.nix...@gmail.com 2013/7/3 niXman: 2013/7/3 Alexey Pavlov: Mingw-builds binutils already built with this flags. I know. I wanted to make sure that Ruben confused nothing. Can anybody say with certainty whether this flag is needed to build GCC? It is not needed per se, but it helps with out of memory problems. Note this will increase virtual address space to 3GB on a 32-bit OS if it is started with that boot flag thingie for larger address space is enabled. On 64-bit OSes (which should really be the default on all current PCs, and which can be run on all PCs that are 10 years or younger), it results in 4GB of virtual address space. http://msdn.microsoft.com/en-us/library/windows/desktop/bb613473%28v=vs.85%29.aspx I stand by the fact that this really is GCC's problem (it just uses too much memory), but as this is not likely something that will be fixed, linking it as large address aware works around the limitation, and hopefully that extra GB or two will be enough to link real-world applications for at least some time. Ruben -- Regards, niXman ___ Dual-target(32 64-bit) MinGW compilers for 32 and 64-bit Windows: http://sourceforge.net/projects/mingwbuilds/ ___ Another online IDE: http://liveworkspace.org/ -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MinGW-w64 (64-bit/POSIX/SEH) Based on GCC 4.8.0 Regression with -O3 flag (Spotted on QtCore 4.8.5)
2013/7/3 Ruben Van Boxem: The bug report clearly shows it is not ld.exe that is running out of memory, but cc1plus.exe: cc1plus.exe: out of memory allocating 279536 bytes Yes, you right. So linking the GCC compiler executables with that flag might give it enough address space. Alexey, we will try to add this flag to our build scripts? -- Regards, niXman ___ Dual-target(32 64-bit) MinGW compilers for 32 and 64-bit Windows: http://sourceforge.net/projects/mingwbuilds/ ___ Another online IDE: http://liveworkspace.org/ -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MinGW-w64 (64-bit/POSIX/SEH) Based on GCC 4.8.0 Regression with -O3 flag (Spotted on QtCore 4.8.5)
03.07.2013, в 12:23, niXman i.nix...@gmail.com написал(а): 2013/7/3 Ruben Van Boxem: The bug report clearly shows it is not ld.exe that is running out of memory, but cc1plus.exe: cc1plus.exe: out of memory allocating 279536 bytes Yes, you right. So linking the GCC compiler executables with that flag might give it enough address space. Alexey, we will try to add this flag to our build scripts? Yes. I try it today. I finish my Ada toolchains with dirty hack. Need to create bug report. -- Regards, niXman ___ Dual-target(32 64-bit) MinGW compilers for 32 and 64-bit Windows: http://sourceforge.net/projects/mingwbuilds/ ___ Another online IDE: http://liveworkspace.org/ -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ 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] intrinsics, __faststorefence, _ReadWriteBarrier et al
On 07/03/13 02:29, dw wrote: Thanks to both Kai and Jacek whose suggestions made this patch much better. This patch includes two parts. The first (and more important) deals with how MSVC's intrinsics are used in mingw-w64: winnt.h: - In all cases (x86, x64, cygwin, not cygwin), remove include for intrin.h and always include x86intrin.h. - Always include (new file) intrin-impl.h, along with define to ensure only winnt.h-related inline functions are created. - Move all the implementations for the intrinsics I have been working on from winnt.h to (new file) psdk_inc/intrin-impl.h. - Temporarily (until these get migrated to intrin-impl.h) add prototypes for __readgs* and __writegs* from intrin.h, needed since intrin.h is no longer included. intrin.h: - Add include for intrin-impl.h. - Add comments describing how the MSVC intrinsics work in gcc. - Changed all // to /* */ - Changed various #if !(__ia64__ || __x86_64) to #if !(defined(__ia64__) || defined(__x86_64)) which was causing compiler warnings with certain settings. intrin-impl.h: - New file to hold all inline versions of functions related to MSVC's intrinsics. - Add copious comments to the top of the file describing the logic of how this should work. - Use __MINGW_INTRIN_INLINE instead of __CRT_INLINE for functions Other: - Make the corresponding changes to the files in mingw-w64-crt\intrincs\*.c to use the new approach in intrin-impl.h. The second part relates to __faststorefence, _ReadWriteBarrier et al: - The existing code for __faststorefence doesn't actually generate a fence. Create intrinsic to use sfence which appears to be faster than MS's trick on newer processors. - MS's MemoryBarrier can't use __faststorefence if we aren't using MS's trick. Change this to use mfence. - Add definitions for _ReadWriteBarrier, _ReadBarrier, _WriteBarrier. This is done with #define, since inline may not produce exactly the same results. - Add intrinsic for __int2c using __builtint from intrin-mac.h. - The code for DbgRaiseAssertionFailure won't compile with -masm=intel. Use __builtint from intrin-mac.h. - Add __buildint to intrin-mac.h for DbgRaiseAssertionFailure __int2c. Looks good to me. Thanks, Jacek -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ 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] intrinsics, __faststorefence, _ReadWriteBarrier et al
2013/7/3 Jacek Caban ja...@codeweavers.com: On 07/03/13 02:29, dw wrote: Thanks to both Kai and Jacek whose suggestions made this patch much better. This patch includes two parts. The first (and more important) deals with how MSVC's intrinsics are used in mingw-w64: winnt.h: - In all cases (x86, x64, cygwin, not cygwin), remove include for intrin.h and always include x86intrin.h. - Always include (new file) intrin-impl.h, along with define to ensure only winnt.h-related inline functions are created. - Move all the implementations for the intrinsics I have been working on from winnt.h to (new file) psdk_inc/intrin-impl.h. - Temporarily (until these get migrated to intrin-impl.h) add prototypes for __readgs* and __writegs* from intrin.h, needed since intrin.h is no longer included. intrin.h: - Add include for intrin-impl.h. - Add comments describing how the MSVC intrinsics work in gcc. - Changed all // to /* */ - Changed various #if !(__ia64__ || __x86_64) to #if !(defined(__ia64__) || defined(__x86_64)) which was causing compiler warnings with certain settings. intrin-impl.h: - New file to hold all inline versions of functions related to MSVC's intrinsics. - Add copious comments to the top of the file describing the logic of how this should work. - Use __MINGW_INTRIN_INLINE instead of __CRT_INLINE for functions Other: - Make the corresponding changes to the files in mingw-w64-crt\intrincs\*.c to use the new approach in intrin-impl.h. The second part relates to __faststorefence, _ReadWriteBarrier et al: - The existing code for __faststorefence doesn't actually generate a fence. Create intrinsic to use sfence which appears to be faster than MS's trick on newer processors. - MS's MemoryBarrier can't use __faststorefence if we aren't using MS's trick. Change this to use mfence. - Add definitions for _ReadWriteBarrier, _ReadBarrier, _WriteBarrier. This is done with #define, since inline may not produce exactly the same results. - Add intrinsic for __int2c using __builtint from intrin-mac.h. - The code for DbgRaiseAssertionFailure won't compile with -masm=intel. Use __builtint from intrin-mac.h. - Add __buildint to intrin-mac.h for DbgRaiseAssertionFailure __int2c. Looks good to me. Thanks, Jacek Yes, patch is ok. Jacek feel free to commit. Thanks, Kai -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ 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] intrinsics, __faststorefence, _ReadWriteBarrier et al
On 07/03/13 12:22, Kai Tietz wrote: 2013/7/3 Jacek Caban ja...@codeweavers.com: Looks good to me. Thanks, Jacek Yes, patch is ok. Jacek feel free to commit. Committed as r5924. Thanks, Jacek -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MinGW-w64 (64-bit/POSIX/SEH) Based on GCC 4.8.0 Regression with -O3 flag (Spotted on QtCore 4.8.5)
This is known problem. See https://bugreports.qt-project.org/browse/QTBUG-29099. It for Qt5 but for Qt4 is the same. You can't now use -O3 with mingw toolchains based on gcc-4.7.3+. I think you got me wrong there. I have no problems building the whole Qt (including QtCore) with -O3 flag. It builds just fine, and cc1plus.exe is not crashing. I'm saying that rather applications based on the resulting QtCore.dll are crashing, and the trace shows that this is because of QtCore.dll itself. Once again, rebuilding QtCore.dll with -O2 solves the issue: it stops crashing. Regards, Haroogan -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MinGW-w64 (64-bit/POSIX/SEH) Based on GCC 4.8.0 Regression with -O3 flag (Spotted on QtCore 4.8.5)
Please do as much as you can to aid the debugging process. Can you provide these traces? Also, can you try to bisect down to the first GCC that breaks this for you? There have been a lot of GCCs between 4.7.1 and 4.8.0 (can you try with 4.8.1 now?) On Wed, Jul 3, 2013 at 1:33 PM, Haroogan haroo...@gmail.com wrote: This is known problem. See https://bugreports.qt-project.org/browse/QTBUG-29099. It for Qt5 but for Qt4 is the same. You can't now use -O3 with mingw toolchains based on gcc-4.7.3+. I think you got me wrong there. I have no problems building the whole Qt (including QtCore) with -O3 flag. It builds just fine, and cc1plus.exe is not crashing. I'm saying that rather applications based on the resulting QtCore.dll are crashing, and the trace shows that this is because of QtCore.dll itself. Once again, rebuilding QtCore.dll with -O2 solves the issue: it stops crashing. Regards, Haroogan -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] OpenGL headers
2013/7/3 LRN lrn1...@gmail.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03.07.2013 00:43, Christer Solskogen wrote: On 01.07.2013 16:02, LRN wrote: mingw-w64 should supply GL headers from [1]. Specifically - GL/glext.h Pardon my french, but why should mingw-w64 supply them? Good question. A) Because MinGW.org supplies them B) Because MinGW-W64 supplies other GL headers already. Those are not sufficient for all uses, however. C) Because MinGW-W64 supplies a DirectX SDK. Why not OpenGL then? - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJR01toAAoJEOs4Jb6SI2Cw5lgIAIBeRjFts6dAo4ZP6JJ6H7rZ ATzyYnZ6eoEmfcd8PMx/OOaHuUqhqNnXpawMdbrOc/q8XXRIiPS7Pl5mnoCm1iuD j2RFEeTJczo326Oy3FC49WfBCHwdcWMy3Sh1fxD+6ngx5mjkU0BRrBnyVohwzGnw aX9Lw+fU/9WGOOcQa40jRPJQ3XIA3VQ9AQlK/4ZShZ9r9aIW0g5Jj/UzVqCF4txu dh1+l0t/dnfyprOlpPwOU2VO16WF/UGoyJ9V/wUHduQ1ZKwqlX6u2r/lUVxDSVFm jMoRgGr5V1ELnGQefIk/5uH8jHr5oLWJMt55BzbvPSjwacco1xAq74PEArnQPd0= =4Isv -END PGP SIGNATURE- Committed to repository at rev. 5925 Thanks, Kai -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] OpenGL headers
On Wed, Jul 3, 2013 at 5:22 PM, Kai Tietz ktiet...@googlemail.com wrote: 2013/7/3 LRN lrn1...@gmail.com: On 03.07.2013 00:43, Christer Solskogen wrote: On 01.07.2013 16:02, LRN wrote: mingw-w64 should supply GL headers from [1]. Specifically - GL/glext.h Pardon my french, but why should mingw-w64 supply them? Good question. A) Because MinGW.org supplies them B) Because MinGW-W64 supplies other GL headers already. Those are not sufficient for all uses, however. C) Because MinGW-W64 supplies a DirectX SDK. Why not OpenGL then? Committed to repository at rev. 5925 Thanks, Kai Notice that you now need to maintain them because those headers are constantly updated by Khronos. This was discussed a very long time ago and it was decided that we need not or should not provide them because, for starters, M$ itself does not. I used to provide them headers only as part of my personal builds, but we never did that officially. -- O.S. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] OpenGL headers
2013/7/3 Ozkan Sezer seze...@gmail.com: On Wed, Jul 3, 2013 at 5:22 PM, Kai Tietz ktiet...@googlemail.com wrote: 2013/7/3 LRN lrn1...@gmail.com: On 03.07.2013 00:43, Christer Solskogen wrote: On 01.07.2013 16:02, LRN wrote: mingw-w64 should supply GL headers from [1]. Specifically - GL/glext.h Pardon my french, but why should mingw-w64 supply them? Good question. A) Because MinGW.org supplies them B) Because MinGW-W64 supplies other GL headers already. Those are not sufficient for all uses, however. C) Because MinGW-W64 supplies a DirectX SDK. Why not OpenGL then? Committed to repository at rev. 5925 Thanks, Kai Notice that you now need to maintain them because those headers are constantly updated by Khronos. Yes, I am aware of that. This is the down-side of adding it. This was discussed a very long time ago and it was decided that we need not or should not provide them because, for starters, M$ itself does not. I used to provide them headers only as part of my personal builds, but we never did that officially. I remember about that discussion. Now you don't need to add it anymore manual ;) -- O.S. Kai -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] OpenGL headers
On Wed, Jul 3, 2013 at 10:36 AM, Ozkan Sezer seze...@gmail.com wrote: On Wed, Jul 3, 2013 at 5:22 PM, Kai Tietz ktiet...@googlemail.com wrote: 2013/7/3 LRN lrn1...@gmail.com: On 03.07.2013 00:43, Christer Solskogen wrote: On 01.07.2013 16:02, LRN wrote: mingw-w64 should supply GL headers from [1]. Specifically - GL/glext.h Pardon my french, but why should mingw-w64 supply them? Good question. A) Because MinGW.org supplies them B) Because MinGW-W64 supplies other GL headers already. Those are not sufficient for all uses, however. C) Because MinGW-W64 supplies a DirectX SDK. Why not OpenGL then? Committed to repository at rev. 5925 Thanks, Kai Notice that you now need to maintain them because those headers are constantly updated by Khronos. We have the same problem elsewhere (wine/dx), but in that case, we have people (Jacek) who regularly keeps us in sync. LRN, given Ozkan's very valid point, would you be able to keep us in sync with Khronos on some set schedule? This was discussed a very long time ago and it was decided that we need not or should not provide them because, for starters, M$ itself does not. I used to provide them headers only as part of my personal builds, but we never did that officially. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] OpenGL headers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03.07.2013 19:10, NightStrike wrote: On Wed, Jul 3, 2013 at 10:36 AM, Ozkan Sezer seze...@gmail.com wrote: On Wed, Jul 3, 2013 at 5:22 PM, Kai Tietz ktiet...@googlemail.com wrote: 2013/7/3 LRN lrn1...@gmail.com: On 03.07.2013 00:43, Christer Solskogen wrote: On 01.07.2013 16:02, LRN wrote: mingw-w64 should supply GL headers from [1]. Specifically - GL/glext.h Pardon my french, but why should mingw-w64 supply them? Good question. A) Because MinGW.org supplies them B) Because MinGW-W64 supplies other GL headers already. Those are not sufficient for all uses, however. C) Because MinGW-W64 supplies a DirectX SDK. Why not OpenGL then? Committed to repository at rev. 5925 Thanks, Kai Notice that you now need to maintain them because those headers are constantly updated by Khronos. We have the same problem elsewhere (wine/dx), but in that case, we have people (Jacek) who regularly keeps us in sync. LRN, given Ozkan's very valid point, would you be able to keep us in sync with Khronos on some set schedule? I'll try. - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJR1D+qAAoJEOs4Jb6SI2Cwwl4H/2S8QX9jS0Q9P986Xv0kDhU1 /omOyZnJmF9sbw92m4GZuCDNndsMoBWz+9T+4/WzEZRU0xVFlu+7pcG8Z9iGEiUA DL7Nqr9tR4B86ohTWBisyDnPDFWLPf4th8z+U4BZpMNqfo7AlS5HQtp0BRpaKO8R AS46/ZM5GOVXgLBMnOVOCuOi6jQyoJmGvZa0Lnhg45MPUidMiMQaW7I6dyL7LSXv XCMzHHTlHFqd5Yf/vvEmCaLvUqOh1S15uTQUjP2Z1fvuTooT+nSIe1OF7p7SjWLi mCn30pT5WrPVUnFdv8tMpA0VxBR6T3gQ2mcucccpST8n1TUaTlBRW5elmyqGWbs= =NeQW -END PGP SIGNATURE- -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] strange gcc 4.8 32bit windows target DLL behaviour
Hi,
If source files use __attribute__ ((dllexport)) to export symbols, the
result DLL looks fine.
But if not use __attribute__ ((dllexport)), the result DLL will export
an extra symbol
'InterlockedCompareExchange@12'. I had checked the compiled and link
files, do not know why.
--- use __attribute__ ((dllexport)) ---
$ cat EOF t-dll.c
__attribute__ ((dllexport))
int get_int()
{
return 1;
}
EOF
$ i686-w64-mingw32-gcc -c -o t-dll.o t-dll.c
$ i686-w64-mingw32-objdump -s t-dll.o | grep -A 5 Contents of section
.drectve
Contents of section .drectve:
202d6578 706f7274 3a226765 745f696e -export:get_in
0010 7422 t..
$ i686-w64-mingw32-gcc -shared -o t-dll.dll t-dll.o
$ i686-w64-mingw32-objdump -x t-dll.dll | grep -A 20 The Export Tables
The Export Tables (interpreted .edata section contents)
Export Flags 0
Time/Date stamp 51d43aff
Major/Minor 0/0
Name a032 t-dll.dll
Ordinal Base 1
Number in:
Export Address Table 0001
[Name Pointer/Ordinal] Table 0001
Table Addresses
Export Address Table a028
Name Pointer Table a02c
Ordinal Table a030
Export Address Table -- Ordinal Base 1
[ 0] +base[ 1] 14d0 Export RVA
[Ordinal/Name Pointer] Table
[ 0] get_int
Looks good !
--- without __attribute__ ((dllexport)) ---
$ cat EOF t-dll2.c
int get_int()
{
return 1;
}
EOF
$ i686-w64-mingw32-gcc -c -o t-dll2.o t-dll2.c
$ i686-w64-mingw32-objdump -s t-dll2.o | grep -A 5 Contents of section
Contents of section .text:
5589e5b8 0100 5dc39090 U...]...
Contents of section .rdata$zzz:
4743433a 2028474e 55292034 2e382e32 GCC: (GNU) 4.8.2
0010 20323031 33303730 33202870 72657265 20130703 (prere
0020 6c656173 6529 lease)..
no section .drectve
$ i686-w64-mingw32-gcc -shared -o t-dll2.dll t-dll2.o
$ i686-w64-mingw32-objdump -x t-dll2.dll | grep -A 22 The Export Tables
The Export Tables (interpreted .edata section contents)
Export Flags 0
Time/Date stamp 51d4440b
Major/Minor 0/0
Name a03c t-dll2.dll
Ordinal Base 1
Number in:
Export Address Table 0002
[Name Pointer/Ordinal] Table 0002
Table Addresses
Export Address Table a028
Name Pointer Table a030
Ordinal Table a038
Export Address Table -- Ordinal Base 1
[ 0] +base[ 1] 6f50 Export RVA
[ 1] +base[ 2] 14d0 Export RVA
[Ordinal/Name Pointer] Table
[ 0] InterlockedCompareExchange@12
[ 1] get_int
What happened ? Why we have an extra export
InterlockedCompareExchange@12 ?
Let's check the link details:
cauchy@CRM-SYSLOG:/tmp$ i686-w64-mingw32-gcc -v -shared -o t-dll2.dll
t-dll2.o
Using built-in specs.
COLLECT_GCC=i686-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/home/cauchy/cross/i686-windows-gcc48/libexec/gcc/i686-w64-mingw32/4.8.2/lto-wrapper
Target: i686-w64-mingw32
Configured with:
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/configure
--prefix=/home/cauchy/cross/i686-windows-gcc48
--with-sysroot=/home/cauchy/cross/i686-windows-gcc48
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=i686-w64-mingw32 --disable-multilib --disable-nls
--enable-checking=release --enable-languages=c,c++,fortran
--with-arch=i686 --with-tune=generic
Thread model: win32
gcc version 4.8.2 20130703 (prerelease) (GCC)
COMPILER_PATH=/home/cauchy/cross/i686-windows-gcc48/libexec/gcc/i686-w64-mingw32/4.8.2/:/home/cauchy/cross/i686-windows-gcc48/libexec/gcc/i686-w64-mingw32/4.8.2/:/home/cauchy/cross/i686-windows-gcc48/libexec/gcc/i686-w64-mingw32/:/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2/:/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/:/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/bin/
LIBRARY_PATH=/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2/:/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib/../lib/:/home/cauchy/cross/i686-windows-gcc48/mingw/lib/../lib/:/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib/:/home/cauchy/cross/i686-windows-gcc48/mingw/lib/
COLLECT_GCC_OPTIONS='-v' '-shared' '-o' 't-dll2.dll' '-mtune=generic'
'-march=i686'
/home/cauchy/cross/i686-windows-gcc48/libexec/gcc/i686-w64-mingw32/4.8.2/collect2
--sysroot=/home/cauchy/cross/i686-windows-gcc48 -m i386pe --shared
-Bdynamic -e _DllMainCRTStartup@12 --enable-auto-image-base -o
t-dll2.dll
/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib/../lib/dllcrt2.o
/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2/crtbegin.o
-L/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2
-L/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib/../lib
-L/home/cauchy/cross/i686-windows-gcc48/mingw/lib/../lib
-L/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib
-L/home/cauchy/cross/i686-windows-gcc48
Re: [Mingw-w64-public] OpenGL headers
On Wed, Jul 3, 2013 at 11:13 AM, LRN lrn1...@gmail.com wrote: On 03.07.2013 19:10, NightStrike wrote: On Wed, Jul 3, 2013 at 10:36 AM, Ozkan Sezer seze...@gmail.com wrote: On Wed, Jul 3, 2013 at 5:22 PM, Kai Tietz ktiet...@googlemail.com wrote: 2013/7/3 LRN lrn1...@gmail.com: On 03.07.2013 00:43, Christer Solskogen wrote: On 01.07.2013 16:02, LRN wrote: mingw-w64 should supply GL headers from [1]. Specifically - GL/glext.h Pardon my french, but why should mingw-w64 supply them? Good question. A) Because MinGW.org supplies them B) Because MinGW-W64 supplies other GL headers already. Those are not sufficient for all uses, however. C) Because MinGW-W64 supplies a DirectX SDK. Why not OpenGL then? Committed to repository at rev. 5925 Thanks, Kai Notice that you now need to maintain them because those headers are constantly updated by Khronos. We have the same problem elsewhere (wine/dx), but in that case, we have people (Jacek) who regularly keeps us in sync. LRN, given Ozkan's very valid point, would you be able to keep us in sync with Khronos on some set schedule? I'll try. Thanks! -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] strange gcc 4.8 32bit windows target DLL behaviour
That is a known issue of ld for pe-coff. If at least one symbol is
exported by dllexport, only those symbols are. If there is none, then
all symbols getting exported.
You can report that to binutils, but I don't see right now a good way
to solve that issue.
Regards,
Kai
2013/7/3 Dongsheng Song dongsheng.s...@gmail.com:
Hi,
If source files use __attribute__ ((dllexport)) to export symbols, the
result DLL looks fine.
But if not use __attribute__ ((dllexport)), the result DLL will export
an extra symbol
'InterlockedCompareExchange@12'. I had checked the compiled and link
files, do not know why.
--- use __attribute__ ((dllexport)) ---
$ cat EOF t-dll.c
__attribute__ ((dllexport))
int get_int()
{
return 1;
}
EOF
$ i686-w64-mingw32-gcc -c -o t-dll.o t-dll.c
$ i686-w64-mingw32-objdump -s t-dll.o | grep -A 5 Contents of section
.drectve
Contents of section .drectve:
202d6578 706f7274 3a226765 745f696e -export:get_in
0010 7422 t..
$ i686-w64-mingw32-gcc -shared -o t-dll.dll t-dll.o
$ i686-w64-mingw32-objdump -x t-dll.dll | grep -A 20 The Export Tables
The Export Tables (interpreted .edata section contents)
Export Flags 0
Time/Date stamp 51d43aff
Major/Minor 0/0
Name a032 t-dll.dll
Ordinal Base 1
Number in:
Export Address Table 0001
[Name Pointer/Ordinal] Table 0001
Table Addresses
Export Address Table a028
Name Pointer Table a02c
Ordinal Table a030
Export Address Table -- Ordinal Base 1
[ 0] +base[ 1] 14d0 Export RVA
[Ordinal/Name Pointer] Table
[ 0] get_int
Looks good !
--- without __attribute__ ((dllexport)) ---
$ cat EOF t-dll2.c
int get_int()
{
return 1;
}
EOF
$ i686-w64-mingw32-gcc -c -o t-dll2.o t-dll2.c
$ i686-w64-mingw32-objdump -s t-dll2.o | grep -A 5 Contents of section
Contents of section .text:
5589e5b8 0100 5dc39090 U...]...
Contents of section .rdata$zzz:
4743433a 2028474e 55292034 2e382e32 GCC: (GNU) 4.8.2
0010 20323031 33303730 33202870 72657265 20130703 (prere
0020 6c656173 6529 lease)..
no section .drectve
$ i686-w64-mingw32-gcc -shared -o t-dll2.dll t-dll2.o
$ i686-w64-mingw32-objdump -x t-dll2.dll | grep -A 22 The Export Tables
The Export Tables (interpreted .edata section contents)
Export Flags 0
Time/Date stamp 51d4440b
Major/Minor 0/0
Name a03c t-dll2.dll
Ordinal Base 1
Number in:
Export Address Table 0002
[Name Pointer/Ordinal] Table 0002
Table Addresses
Export Address Table a028
Name Pointer Table a030
Ordinal Table a038
Export Address Table -- Ordinal Base 1
[ 0] +base[ 1] 6f50 Export RVA
[ 1] +base[ 2] 14d0 Export RVA
[Ordinal/Name Pointer] Table
[ 0] InterlockedCompareExchange@12
[ 1] get_int
What happened ? Why we have an extra export
InterlockedCompareExchange@12 ?
Let's check the link details:
cauchy@CRM-SYSLOG:/tmp$ i686-w64-mingw32-gcc -v -shared -o t-dll2.dll
t-dll2.o
Using built-in specs.
COLLECT_GCC=i686-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/home/cauchy/cross/i686-windows-gcc48/libexec/gcc/i686-w64-mingw32/4.8.2/lto-wrapper
Target: i686-w64-mingw32
Configured with:
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/configure
--prefix=/home/cauchy/cross/i686-windows-gcc48
--with-sysroot=/home/cauchy/cross/i686-windows-gcc48
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=i686-w64-mingw32 --disable-multilib --disable-nls
--enable-checking=release --enable-languages=c,c++,fortran
--with-arch=i686 --with-tune=generic
Thread model: win32
gcc version 4.8.2 20130703 (prerelease) (GCC)
COMPILER_PATH=/home/cauchy/cross/i686-windows-gcc48/libexec/gcc/i686-w64-mingw32/4.8.2/:/home/cauchy/cross/i686-windows-gcc48/libexec/gcc/i686-w64-mingw32/4.8.2/:/home/cauchy/cross/i686-windows-gcc48/libexec/gcc/i686-w64-mingw32/:/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2/:/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/:/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/bin/
LIBRARY_PATH=/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2/:/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib/../lib/:/home/cauchy/cross/i686-windows-gcc48/mingw/lib/../lib/:/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib/:/home/cauchy/cross/i686-windows-gcc48/mingw/lib/
COLLECT_GCC_OPTIONS='-v' '-shared' '-o' 't-dll2.dll' '-mtune=generic'
'-march=i686'
/home/cauchy/cross/i686-windows-gcc48/libexec/gcc/i686-w64-mingw32/4.8.2/collect2
--sysroot=/home/cauchy/cross/i686-windows-gcc48 -m i386pe --shared
-Bdynamic -e _DllMainCRTStartup@12 --enable-auto-image-base -o
t-dll2.dll
/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib/../lib/dllcrt2.o
/home/cauchy/cross/i686
Re: [Mingw-w64-public] strange gcc 4.8 32bit windows target DLL behaviour
On Thu, Jul 4, 2013 at 12:09 AM, Kai Tietz ktiet...@googlemail.com wrote: That is a known issue of ld for pe-coff. If at least one symbol is exported by dllexport, only those symbols are. If there is none, then all symbols getting exported. Just for curious, why 64 bit Windows target not affected ? Why gcc 4.7 32 bit Windows target not affected ? You can report that to binutils, but I don't see right now a good way to solve that issue. Regards, Kai Regards, Dongsheng -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] strftime doesn't parse %T
Hello List!
strftime does not seem to parse the %T format specifier.
First of all, I don't actually know what is supposed to happen. However,
this reference:
http://www.cplusplus.com/reference/ctime/strftime/
states that %T is supposed to be a synonym for %H:%M:%S:
%T ISO 8601 time format (HH:MM:SS), equivalent to %H:%M:%S 14:55:02
Anyway, when I use %T in my format string, strftime returns 0 as the
number of characters copied to the output buffer.
This is nothing urgent for me -- I can simply use %H:%M:%S. I only
bring this up because g++ seems not to agree with some random bit of
documentation I found on the internet.
Here's the output from a sample program:
C:\strftime_test.exe
cnt1 = 17, buf1 = 20130702-13:14:15
cnt2 = 0, buf2 =
the compile line:
C:\g++ -o strftime_test strftime_test.cpp
the compiler version:
C:\g++ --version
g++ (rubenvb-4.8-stdthread) 4.8.1 20130324 (prerelease)
and the test program:
=== strftime_test.cpp ===
#include ctime
#include iostream
int main (int argc, char *argv[]) {
tm mytm = { 15, 14, 13, 2, 6, 113 }; // not portable
char buf1[129];
int cnt1 = strftime (buf1, 128, %Y%m%d-%H:%M:%S, mytm);
std::cout cnt1 = cnt1 , buf1 = buf1 std::endl;
char buf2[129];
int cnt2 = strftime (buf2, 128, %Y%m%d-%T, mytm);
std::cout cnt2 = cnt2 , buf2 = buf2 std::endl;
}
=== ===
Thanks for any feedback.
K. Frank
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] strftime doesn't parse %T
On Wed, Jul 3, 2013 at 9:08 PM, K. Frank kfrank2...@gmail.com wrote:
Hello List!
strftime does not seem to parse the %T format specifier.
First of all, I don't actually know what is supposed to happen. However,
this reference:
http://www.cplusplus.com/reference/ctime/strftime/
states that %T is supposed to be a synonym for %H:%M:%S:
%T ISO 8601 time format (HH:MM:SS), equivalent to %H:%M:%S 14:55:02
Anyway, when I use %T in my format string, strftime returns 0 as the
number of characters copied to the output buffer.
This is nothing urgent for me -- I can simply use %H:%M:%S. I only
bring this up because g++ seems not to agree with some random bit of
documentation I found on the internet.
Here's the output from a sample program:
C:\strftime_test.exe
cnt1 = 17, buf1 = 20130702-13:14:15
cnt2 = 0, buf2 =
the compile line:
C:\g++ -o strftime_test strftime_test.cpp
the compiler version:
C:\g++ --version
g++ (rubenvb-4.8-stdthread) 4.8.1 20130324 (prerelease)
and the test program:
=== strftime_test.cpp ===
#include ctime
#include iostream
int main (int argc, char *argv[]) {
tm mytm = { 15, 14, 13, 2, 6, 113 }; // not portable
char buf1[129];
int cnt1 = strftime (buf1, 128, %Y%m%d-%H:%M:%S, mytm);
std::cout cnt1 = cnt1 , buf1 = buf1 std::endl;
char buf2[129];
int cnt2 = strftime (buf2, 128, %Y%m%d-%T, mytm);
std::cout cnt2 = cnt2 , buf2 = buf2 std::endl;
}
=== ===
Thanks for any feedback.
K. Frank
strftime() is imported from msvcrt.dll, therefore it behaves the way MS
authored it.
--
O.S.
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] strftime doesn't parse %T
Hi Ozkan! Thank you for your explanation. On Wed, Jul 3, 2013 at 2:26 PM, Ozkan Sezer wrote: On Wed, Jul 3, 2013 at 9:08 PM, K. Frank wrote: Hello List! strftime does not seem to parse the %T format specifier. ... Thanks for any feedback. K. Frank strftime() is imported from msvcrt.dll, therefore it behaves the way MS authored it. Thanks. That makes good sense. Just as a follow-up, when I look at msdn's documentation for strftime, e.g.: http://msdn.microsoft.com/en-us/library/fe06s4ak(v=vs.80).aspx I see no mention of the %T format specifier. So I guess, at least in the msvcrt.dll world, %T is invalid, explaining my result. O.S. Best. K. Frank -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] strange gcc 4.8 32bit windows target DLL behaviour
On Wed, Jul 3, 2013 at 12:28 PM, Dongsheng Song wrote: On Thu, Jul 4, 2013 at 12:09 AM, Kai Tietz ktiet...@googlemail.com wrote: That is a known issue of ld for pe-coff. If at least one symbol is exported by dllexport, only those symbols are. If there is none, then all symbols getting exported. Just for curious, why 64 bit Windows target not affected ? Why gcc 4.7 32 bit Windows target not affected ? This behavior was added to binutils years ago by Danny Smith. I'm guessing your affect is a bit over stated. You can use --exclude-all-symbols to stop the automatic export or --export-all-symbols to always export all symbols. You'll also be interested in --warn-duplicate-exports. -- Earnie -- https://sites.google.com/site/earnieboyd -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [Patch] __stos* must use output params
While input parameters to asm blocks are expressions (not lvalues), they
cannot (safely) be modified within the asm code unless they are also
listed as outputs. While this may appear to work, code that comes
*after* the asm block may fail.
dw
Index: mingw-w64-headers/include/psdk_inc/intrin-mac.h
===
--- mingw-w64-headers/include/psdk_inc/intrin-mac.h (revision 5928)
+++ mingw-w64-headers/include/psdk_inc/intrin-mac.h (working copy)
@@ -15,11 +15,13 @@
FunctionName: Any valid function name
DataType: BYTE, WORD, DWORD or DWORD64 */
+/* While we don't need the output values for Dest or Count, we
+ must still inform the compiler the asm changes them. */
#define __buildstos(x, y) void x(y *Dest, y Data, size_t Count) \
{ \
__asm__ __volatile__ (rep stos%z[Data] \
- : /* no outputs */ \
- : D (Dest), c (Count), [Data] a (Data) \
+ : +D (Dest), +c (Count) \
+ : [Data] a (Data) \
: memory); \
}
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
