Re: [Mingw-w64-public] [Project News | New Builds]
On Sat, Apr 26, 2014, Dongsheng Song wrote: On Sat, Apr 26, 2014 at 12:31 AM, Adrien Nader adr...@notk.org wrote: I believe --with-arch=core2 is a big issue for generic toolchains. It will create troubles which will be very annoying to pinpoint. Any x86_64/amd64/EM64T (I love how Intel always makes up awful names) already has SSE2 and there is little value in restricting this except in very specific situation which are better dealt on a case-by-case basis. Regards, Adrien Nader Do you really meet this issue ? I can not image someone still running 64 bit Windows on such old CPU. Intel core2 release in July 2006, shutdown in January 2010. http://en.wikipedia.org/wiki/Intel_Core_2 I have troubles believing people still run XP but many do. :P The issue is rather when you look at the AMD CPUs. First models with SSE3 are from the end of 2007 (meaning you would still easily see machines with them at the end of 2008, even beginning of 2009). The real issue is with SSSE3 (one more 'S') since the first mobile CPUs with it have been released beginning of 2011 and the first desktop CPUs with it have been released end of 2011 are are still easily found. I have a machine without SSE3 in my living room (albeit it needs a new PSU), along with a machine without SSSE3 which is definitely running strong (in particular since the rate of CPU speed improvement has dramatically slowed down in the last few years). I don't think there is a point in making core2 the default; I don't think it will bring any improvements except when building multimedia stuff and even then it's not unlikely they don't provide hand-tuned assembly but even then, -mtune should do be able to bring the performance benefits on the newer CPUs while still running on the older ones. -- Adrien Nader -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News | New Builds]
On 4/26/2014 13:44, Dongsheng Song wrote: On Sat, Apr 26, 2014 at 10:24 AM, niXman i.nix...@autistici.org wrote: Dongsheng Song 2014-04-26 06:17: Not help, still no 'Add File' or 'Add Folder'. I also can't see this buttons(bug?), but I use ShellService: https://sourceforge.net/p/forge/documentation/Shell%20Service/ Thanks for your information. When I use ssh login, then 'sf-help --frs' said I did't have FRS on mingw-w64. When I use sftp, 'docbook' and 'osb' is OK, mingw-w64 faild: $ sftp dongsheng,docb...@web.sourceforge.net Connected to web.sourceforge.net. sftp exit $ sftp dongsheng,o...@web.sourceforge.net Connected to web.sourceforge.net. sftp exit $ sftp dongsheng,mingw-...@web.sourceforge.net Password: Try frs.sourceforge.net. signature.asc Description: OpenPGP digital signature -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News | New Builds]
On Sat, Apr 26, 2014 at 3:24 PM, JonY jo...@users.sourceforge.net wrote: On 4/26/2014 13:44, Dongsheng Song wrote: On Sat, Apr 26, 2014 at 10:24 AM, niXman i.nix...@autistici.org wrote: Dongsheng Song 2014-04-26 06:17: Not help, still no 'Add File' or 'Add Folder'. I also can't see this buttons(bug?), but I use ShellService: https://sourceforge.net/p/forge/documentation/Shell%20Service/ Thanks for your information. When I use ssh login, then 'sf-help --frs' said I did't have FRS on mingw-w64. When I use sftp, 'docbook' and 'osb' is OK, mingw-w64 faild: $ sftp dongsheng,docb...@web.sourceforge.net Connected to web.sourceforge.net. sftp exit $ sftp dongsheng,o...@web.sourceforge.net Connected to web.sourceforge.net. sftp exit $ sftp dongsheng,mingw-...@web.sourceforge.net Password: Try frs.sourceforge.net. Still no luck. $ sftp dongsheng,mingw-...@frs.sourceforge.net Password: Password: Password: $ sftp dongsheng,docb...@frs.sourceforge.net Connected to frs.sourceforge.net. sftp exit -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News | New Builds]
On 4/26/2014 10:27, Matthew Brett wrote: I've had problems with sourceforge before. It looks like, to allow people to upload, you have add the person as Developer or Admin, and then (this for the project 'numpy'): Go the 'tools' sidebar: https://sourceforge.net/p/numpy/admin/tools Under Files, select Release Technicians: https://sourceforge.net/p/numpy/admin/downloads/releasers/ Click the box next to the developer's name. That seemed to work for other projects at least. Release manager can't release... Anyway, try again Dongsheng. signature.asc Description: OpenPGP digital signature -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News | New Builds]
On Sat, Apr 26, 2014 at 3:22 PM, Adrien Nader adr...@notk.org wrote: On Sat, Apr 26, 2014, Dongsheng Song wrote: On Sat, Apr 26, 2014 at 12:31 AM, Adrien Nader adr...@notk.org wrote: I believe --with-arch=core2 is a big issue for generic toolchains. It will create troubles which will be very annoying to pinpoint. Any x86_64/amd64/EM64T (I love how Intel always makes up awful names) already has SSE2 and there is little value in restricting this except in very specific situation which are better dealt on a case-by-case basis. Regards, Adrien Nader Do you really meet this issue ? I can not image someone still running 64 bit Windows on such old CPU. Intel core2 release in July 2006, shutdown in January 2010. http://en.wikipedia.org/wiki/Intel_Core_2 I have troubles believing people still run XP but many do. :P The issue is rather when you look at the AMD CPUs. First models with SSE3 are from the end of 2007 (meaning you would still easily see machines with them at the end of 2008, even beginning of 2009). The real issue is with SSSE3 (one more 'S') since the first mobile CPUs with it have been released beginning of 2011 and the first desktop CPUs with it have been released end of 2011 are are still easily found. I have a machine without SSE3 in my living room (albeit it needs a new PSU), along with a machine without SSSE3 which is definitely running strong (in particular since the rate of CPU speed improvement has dramatically slowed down in the last few years). I don't think there is a point in making core2 the default; I don't think it will bring any improvements except when building multimedia stuff and even then it's not unlikely they don't provide hand-tuned assembly but even then, -mtune should do be able to bring the performance benefits on the newer CPUs while still running on the older ones. I agree with you the performance view. But from gcc view, Intel 64 cpu is: nocona, core2 or later. In my memory, I never hear someone can run 64 bit windows on nocona without problem. I know it's unfair for AMD CPUs, but both without -march and with -march=amd cpu type give 3DNow defined, it's not acceptable for Intel CPUs. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News | New Builds]
On Sat, Apr 26, 2014 at 4:47 PM, JonY jo...@users.sourceforge.net wrote: On 4/26/2014 10:27, Matthew Brett wrote: I've had problems with sourceforge before. It looks like, to allow people to upload, you have add the person as Developer or Admin, and then (this for the project 'numpy'): Go the 'tools' sidebar: https://sourceforge.net/p/numpy/admin/tools Under Files, select Release Technicians: https://sourceforge.net/p/numpy/admin/downloads/releasers/ Click the box next to the developer's name. That seemed to work for other projects at least. Release manager can't release... Anyway, try again Dongsheng. Thanks, both web and sftp are OK now. How do you fix this issue ? -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News | New Builds]
Dongsheng Song 2014-04-26 12:22: $ sftp dongsheng,mingw-...@frs.sourceforge.net try: $ ssh dongsheng,mingw-...@frs.sourceforge.net -- Regards, niXman ___ Dual-target(32 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows: http://sourceforge.net/projects/mingw-w64/ ___ Another online IDE: http://liveworkspace.org/ -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News | New Builds]
niXman 2014-04-26 13:53: try: $ ssh dongsheng,mingw-...@frs.sourceforge.net ssh -t dongsheng,mingw-...@shell.sourceforge.net create -- Regards, niXman ___ Dual-target(32 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows: http://sourceforge.net/projects/mingw-w64/ ___ Another online IDE: http://liveworkspace.org/ -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News | New Builds]
On 4/26/2014 16:58, Dongsheng Song wrote: On Sat, Apr 26, 2014 at 4:47 PM, JonY jo...@users.sourceforge.net wrote: On 4/26/2014 10:27, Matthew Brett wrote: I've had problems with sourceforge before. It looks like, to allow people to upload, you have add the person as Developer or Admin, and then (this for the project 'numpy'): Go the 'tools' sidebar: https://sourceforge.net/p/numpy/admin/tools Under Files, select Release Technicians: https://sourceforge.net/p/numpy/admin/downloads/releasers/ Click the box next to the developer's name. That seemed to work for other projects at least. Release manager can't release... Anyway, try again Dongsheng. Thanks, both web and sftp are OK now. How do you fix this issue ? I followed Matthew's instructions, looks like it is working. signature.asc Description: OpenPGP digital signature -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Do I need -flto when building a static lib?
Hello there, do I need -flto when building a static lib? Here is an example: E:\Desktopgcc foo.c -c -flto E:\Desktopar rcs libfoo.a foo.o E:\Desktopgcc main.c -L. -lfoo -flto C:\Users\LH_Mouse\AppData\Local\Temp\ccc30oDd.ltrans0.ltrans.o:ccc30oDd.ltrans0.o:(.text+0x1e): undefined reference to `foo' collect2.exe: error: ld returned 1 exit status Without those -flto options these commands worked just well. Looking forward to you reply. -- Best regards, lh_mouse 2014-04-26 main.c Description: Binary data foo.c Description: Binary data -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Do I need -flto when building a static lib?
Are you using GCC 4.9.0? Since GCC 4.9.0, LTO-enabled object file doesn't contain normal object code but GIMPLE bytecode by default. If you want to link to a static library, you have to pass -fuse-linker-plugin to let it extract LTO segments, and AFAIK it's enabled by default when -flto is passed. But I don't know why, the linker plugin of MinGW seems not working, it always tell me some symbols are undefined. So instead, you may pass -ffat-lto-objects to make it generate object files with normal object code, but you won't benefit from LTO. 2014-04-26 18:39 GMT+08:00 lh_mouse lh_mo...@126.com: Hello there, do I need -flto when building a static lib? Here is an example: E:\Desktopgcc foo.c -c -flto E:\Desktopar rcs libfoo.a foo.o E:\Desktopgcc main.c -L. -lfoo -flto C:\Users\LH_Mouse\AppData\Local\Temp\ccc30oDd.ltrans0.ltrans.o:ccc30oDd.ltrans0.o:(.text+0x1e): undefined reference to `foo' collect2.exe: error: ld returned 1 exit status Without those -flto options these commands worked just well. Looking forward to you reply. -- Best regards, lh_mouse 2014-04-26 -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Do I need -flto when building a static lib?
2014-04-26 Best regards, lh_mouse 发件人：TOCK Chiu stanley82...@gmail.com 发送时间：2014-04-26 21:20 主题：Re: [Mingw-w64-public] Do I need -flto when building a static lib? 收件人：mingw-w64-publicmingw-w64-public@lists.sourceforge.net 抄送： Are you using GCC 4.9.0? Since GCC 4.9.0, LTO-enabled object file doesn't contain normal object code but GIMPLE bytecode by default. If you want to link to a static library, you have to pass -fuse-linker-plugin to let it extract LTO segments, and AFAIK it's enabled by default when -flto is passed. But I don't know why, the linker plugin of MinGW seems not working, it always tell me some symbols are undefined. So instead, you may pass -ffat-lto-objects to make it generate object files with normal object code, but you won't benefit from LTO. 2014-04-26 18:39 GMT+08:00 lh_mouse lh_mo...@126.com: Hello there, do I need -flto when building a static lib? Here is an example: E:\Desktopgcc foo.c -c -flto E:\Desktopar rcs libfoo.a foo.o E:\Desktopgcc main.c -L. -lfoo -flto C:\Users\LH_Mouse\AppData\Local\Temp\ccc30oDd.ltrans0.ltrans.o:ccc30oDd.ltrans0.o:(.text+0x1e): undefined reference to `foo' collect2.exe: error: ld returned 1 exit status Without those -flto options these commands worked just well. Looking forward to you reply. -- Best regards, lh_mouse 2014-04-26-- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Do I need -flto when building a static lib?
Yes gcc 4.9.0. Thread model: win32 gcc version 4.9.0 (i686-win32-sjlj-rev0, Built by MinGW-W64 project) 2014-04-26 Best regards, lh_mouse 发件人：TOCK Chiu stanley82...@gmail.com 发送时间：2014-04-26 21:20 主题：Re: [Mingw-w64-public] Do I need -flto when building a static lib? 收件人：mingw-w64-publicmingw-w64-public@lists.sourceforge.net 抄送： Are you using GCC 4.9.0? Since GCC 4.9.0, LTO-enabled object file doesn't contain normal object code but GIMPLE bytecode by default. If you want to link to a static library, you have to pass -fuse-linker-plugin to let it extract LTO segments, and AFAIK it's enabled by default when -flto is passed. But I don't know why, the linker plugin of MinGW seems not working, it always tell me some symbols are undefined. So instead, you may pass -ffat-lto-objects to make it generate object files with normal object code, but you won't benefit from LTO. 2014-04-26 18:39 GMT+08:00 lh_mouse lh_mo...@126.com: Hello there, do I need -flto when building a static lib? Here is an example: E:\Desktopgcc foo.c -c -flto E:\Desktopar rcs libfoo.a foo.o E:\Desktopgcc main.c -L. -lfoo -flto C:\Users\LH_Mouse\AppData\Local\Temp\ccc30oDd.ltrans0.ltrans.o:ccc30oDd.ltrans0.o:(.text+0x1e): undefined reference to `foo' collect2.exe: error: ld returned 1 exit status Without those -flto options these commands worked just well. Looking forward to you reply. -- Best regards, lh_mouse 2014-04-26-- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Do I need -flto when building a static lib?
Then you must experience the same thing as I did. 2014-04-26 21:24 GMT+08:00 lh_mouse lh_mo...@126.com: Yes gcc 4.9.0. Thread model: win32 gcc version 4.9.0 (i686-win32-sjlj-rev0, Built by MinGW-W64 project) 2014-04-26 -- Best regards, lh_mouse -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News | New Builds]
On Sat, Apr 26, 2014, Dongsheng Song wrote: On Sat, Apr 26, 2014 at 3:22 PM, Adrien Nader adr...@notk.org wrote: On Sat, Apr 26, 2014, Dongsheng Song wrote: On Sat, Apr 26, 2014 at 12:31 AM, Adrien Nader adr...@notk.org wrote: I believe --with-arch=core2 is a big issue for generic toolchains. It will create troubles which will be very annoying to pinpoint. Any x86_64/amd64/EM64T (I love how Intel always makes up awful names) already has SSE2 and there is little value in restricting this except in very specific situation which are better dealt on a case-by-case basis. Regards, Adrien Nader Do you really meet this issue ? I can not image someone still running 64 bit Windows on such old CPU. Intel core2 release in July 2006, shutdown in January 2010. http://en.wikipedia.org/wiki/Intel_Core_2 I have troubles believing people still run XP but many do. :P The issue is rather when you look at the AMD CPUs. First models with SSE3 are from the end of 2007 (meaning you would still easily see machines with them at the end of 2008, even beginning of 2009). The real issue is with SSSE3 (one more 'S') since the first mobile CPUs with it have been released beginning of 2011 and the first desktop CPUs with it have been released end of 2011 are are still easily found. I have a machine without SSE3 in my living room (albeit it needs a new PSU), along with a machine without SSSE3 which is definitely running strong (in particular since the rate of CPU speed improvement has dramatically slowed down in the last few years). I don't think there is a point in making core2 the default; I don't think it will bring any improvements except when building multimedia stuff and even then it's not unlikely they don't provide hand-tuned assembly but even then, -mtune should do be able to bring the performance benefits on the newer CPUs while still running on the older ones. I agree with you the performance view. But from gcc view, Intel 64 cpu is: nocona, core2 or later. In my memory, I never hear someone can run 64 bit windows on nocona without problem. I know it's unfair for AMD CPUs, but both without -march and with -march=amd cpu type give 3DNow defined, it's not acceptable for Intel CPUs. Intel 64 is a name that doesn't exist. It's either AMD64 (AMD parlance), EM64T (Intel parlance), x64 (Microsoft parlance) or x86_64 (parlance of anyone not interested in marketing and propaganda). The first CPUs handling x86_64 date from 2003 and were server-class CPUs. Using --with-arch=core2 means that there many CPUs sold during pretty much *10* years will not be able to run the programs compiled with these toolchains and will crash at surprising times in surprising ways. Right now I have a Windows 8 x86_64 VM running on a CPU from 2009 or 2010 without SSSE3. Actually it maybe doesn't have SSE3 either. I've never had issues with x86_64 stuff on it. I've also grabbed my XP 64 box and there's a cute logo of a Pentium 4. While everyone will agree XP 64 was far from perfect, I think it's a good indication that it worked at least for some people. As for not specifying any arch, I wasn't able to quickly find a reference or documentation on the matter. However, Linux distributions are a good example however: they run on all x86_64 CPUs and don't set anything specific and that's what a generic toolchain should do too. In any case, if not setting --with-arch makes code that cannot run on the triplet specified during the build of GCC (which I do not believe) then this is an issue in GCC and should be dealt in GCC and not worked-around (but again, I believe it is not the case). -- Adrien Nader -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News | New Builds]
On Sat, Apr 26, 2014 at 10:25 PM, Adrien Nader adr...@notk.org wrote: On Sat, Apr 26, 2014, Dongsheng Song wrote: On Sat, Apr 26, 2014 at 3:22 PM, Adrien Nader adr...@notk.org wrote: On Sat, Apr 26, 2014, Dongsheng Song wrote: On Sat, Apr 26, 2014 at 12:31 AM, Adrien Nader adr...@notk.org wrote: I believe --with-arch=core2 is a big issue for generic toolchains. It will create troubles which will be very annoying to pinpoint. Any x86_64/amd64/EM64T (I love how Intel always makes up awful names) already has SSE2 and there is little value in restricting this except in very specific situation which are better dealt on a case-by-case basis. Regards, Adrien Nader Do you really meet this issue ? I can not image someone still running 64 bit Windows on such old CPU. Intel core2 release in July 2006, shutdown in January 2010. http://en.wikipedia.org/wiki/Intel_Core_2 I have troubles believing people still run XP but many do. :P The issue is rather when you look at the AMD CPUs. First models with SSE3 are from the end of 2007 (meaning you would still easily see machines with them at the end of 2008, even beginning of 2009). The real issue is with SSSE3 (one more 'S') since the first mobile CPUs with it have been released beginning of 2011 and the first desktop CPUs with it have been released end of 2011 are are still easily found. I have a machine without SSE3 in my living room (albeit it needs a new PSU), along with a machine without SSSE3 which is definitely running strong (in particular since the rate of CPU speed improvement has dramatically slowed down in the last few years). I don't think there is a point in making core2 the default; I don't think it will bring any improvements except when building multimedia stuff and even then it's not unlikely they don't provide hand-tuned assembly but even then, -mtune should do be able to bring the performance benefits on the newer CPUs while still running on the older ones. I agree with you the performance view. But from gcc view, Intel 64 cpu is: nocona, core2 or later. In my memory, I never hear someone can run 64 bit windows on nocona without problem. I know it's unfair for AMD CPUs, but both without -march and with -march=amd cpu type give 3DNow defined, it's not acceptable for Intel CPUs. Intel 64 is a name that doesn't exist. It's either AMD64 (AMD parlance), EM64T (Intel parlance), x64 (Microsoft parlance) or x86_64 (parlance of anyone not interested in marketing and propaganda). The first CPUs handling x86_64 date from 2003 and were server-class CPUs. Using --with-arch=core2 means that there many CPUs sold during pretty much *10* years will not be able to run the programs compiled with these toolchains and will crash at surprising times in surprising ways. Right now I have a Windows 8 x86_64 VM running on a CPU from 2009 or 2010 without SSSE3. Actually it maybe doesn't have SSE3 either. I've never had issues with x86_64 stuff on it. I've also grabbed my XP 64 box and there's a cute logo of a Pentium 4. While everyone will agree XP 64 was far from perfect, I think it's a good indication that it worked at least for some people. As for not specifying any arch, I wasn't able to quickly find a reference or documentation on the matter. However, Linux distributions are a good example however: they run on all x86_64 CPUs and don't set anything specific and that's what a generic toolchain should do too. In any case, if not setting --with-arch makes code that cannot run on the triplet specified during the build of GCC (which I do not believe) then this is an issue in GCC and should be dealt in GCC and not worked-around (but again, I believe it is not the case). -- Adrien Nader Just pick Linux 64 bit gcc: gcc -dM -E - /dev/null | grep -i k8 #define __k8 1 #define __k8__ 1 From http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86-64-Options.html , k8 is: Processors based on the AMD K8 core with x86-64 instruction set support, including the AMD Opteron, Athlon 64, and Athlon 64 FX processors. (This supersets MMX, SSE, SSE2, 3DNow!, enhanced 3DNow! and 64-bit instruction set extensions.) -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News | New Builds]
On Sat, Apr 26, 2014 at 11:49 PM, Dongsheng Song dongsheng.s...@gmail.com wrote: On Sat, Apr 26, 2014 at 10:25 PM, Adrien Nader adr...@notk.org wrote: On Sat, Apr 26, 2014, Dongsheng Song wrote: On Sat, Apr 26, 2014 at 3:22 PM, Adrien Nader adr...@notk.org wrote: On Sat, Apr 26, 2014, Dongsheng Song wrote: On Sat, Apr 26, 2014 at 12:31 AM, Adrien Nader adr...@notk.org wrote: I believe --with-arch=core2 is a big issue for generic toolchains. It will create troubles which will be very annoying to pinpoint. Any x86_64/amd64/EM64T (I love how Intel always makes up awful names) already has SSE2 and there is little value in restricting this except in very specific situation which are better dealt on a case-by-case basis. Regards, Adrien Nader Do you really meet this issue ? I can not image someone still running 64 bit Windows on such old CPU. Intel core2 release in July 2006, shutdown in January 2010. http://en.wikipedia.org/wiki/Intel_Core_2 I have troubles believing people still run XP but many do. :P The issue is rather when you look at the AMD CPUs. First models with SSE3 are from the end of 2007 (meaning you would still easily see machines with them at the end of 2008, even beginning of 2009). The real issue is with SSSE3 (one more 'S') since the first mobile CPUs with it have been released beginning of 2011 and the first desktop CPUs with it have been released end of 2011 are are still easily found. I have a machine without SSE3 in my living room (albeit it needs a new PSU), along with a machine without SSSE3 which is definitely running strong (in particular since the rate of CPU speed improvement has dramatically slowed down in the last few years). I don't think there is a point in making core2 the default; I don't think it will bring any improvements except when building multimedia stuff and even then it's not unlikely they don't provide hand-tuned assembly but even then, -mtune should do be able to bring the performance benefits on the newer CPUs while still running on the older ones. I agree with you the performance view. But from gcc view, Intel 64 cpu is: nocona, core2 or later. In my memory, I never hear someone can run 64 bit windows on nocona without problem. I know it's unfair for AMD CPUs, but both without -march and with -march=amd cpu type give 3DNow defined, it's not acceptable for Intel CPUs. Intel 64 is a name that doesn't exist. It's either AMD64 (AMD parlance), EM64T (Intel parlance), x64 (Microsoft parlance) or x86_64 (parlance of anyone not interested in marketing and propaganda). The first CPUs handling x86_64 date from 2003 and were server-class CPUs. Using --with-arch=core2 means that there many CPUs sold during pretty much *10* years will not be able to run the programs compiled with these toolchains and will crash at surprising times in surprising ways. Right now I have a Windows 8 x86_64 VM running on a CPU from 2009 or 2010 without SSSE3. Actually it maybe doesn't have SSE3 either. I've never had issues with x86_64 stuff on it. I've also grabbed my XP 64 box and there's a cute logo of a Pentium 4. While everyone will agree XP 64 was far from perfect, I think it's a good indication that it worked at least for some people. As for not specifying any arch, I wasn't able to quickly find a reference or documentation on the matter. However, Linux distributions are a good example however: they run on all x86_64 CPUs and don't set anything specific and that's what a generic toolchain should do too. In any case, if not setting --with-arch makes code that cannot run on the triplet specified during the build of GCC (which I do not believe) then this is an issue in GCC and should be dealt in GCC and not worked-around (but again, I believe it is not the case). -- Adrien Nader Just pick Linux 64 bit gcc: gcc -dM -E - /dev/null | grep -i k8 #define __k8 1 #define __k8__ 1 From http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86-64-Options.html , k8 is: Processors based on the AMD K8 core with x86-64 instruction set support, including the AMD Opteron, Athlon 64, and Athlon 64 FX processors. (This supersets MMX, SSE, SSE2, 3DNow!, enhanced 3DNow! and 64-bit instruction set extensions.) By the way, You can use your prefer -march when compile programs. It's best practices, many people use -march to support newer or older CPUs, no one default setting suits us all. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net
Re: [Mingw-w64-public] [Project News | New Builds]
On Sun, Apr 27, 2014, Dongsheng Song wrote: On Sat, Apr 26, 2014 at 11:49 PM, Dongsheng Song dongsheng.s...@gmail.com wrote: On Sat, Apr 26, 2014 at 10:25 PM, Adrien Nader adr...@notk.org wrote: On Sat, Apr 26, 2014, Dongsheng Song wrote: On Sat, Apr 26, 2014 at 3:22 PM, Adrien Nader adr...@notk.org wrote: On Sat, Apr 26, 2014, Dongsheng Song wrote: On Sat, Apr 26, 2014 at 12:31 AM, Adrien Nader adr...@notk.org wrote: I believe --with-arch=core2 is a big issue for generic toolchains. It will create troubles which will be very annoying to pinpoint. Any x86_64/amd64/EM64T (I love how Intel always makes up awful names) already has SSE2 and there is little value in restricting this except in very specific situation which are better dealt on a case-by-case basis. Regards, Adrien Nader Do you really meet this issue ? I can not image someone still running 64 bit Windows on such old CPU. Intel core2 release in July 2006, shutdown in January 2010. http://en.wikipedia.org/wiki/Intel_Core_2 I have troubles believing people still run XP but many do. :P The issue is rather when you look at the AMD CPUs. First models with SSE3 are from the end of 2007 (meaning you would still easily see machines with them at the end of 2008, even beginning of 2009). The real issue is with SSSE3 (one more 'S') since the first mobile CPUs with it have been released beginning of 2011 and the first desktop CPUs with it have been released end of 2011 are are still easily found. I have a machine without SSE3 in my living room (albeit it needs a new PSU), along with a machine without SSSE3 which is definitely running strong (in particular since the rate of CPU speed improvement has dramatically slowed down in the last few years). I don't think there is a point in making core2 the default; I don't think it will bring any improvements except when building multimedia stuff and even then it's not unlikely they don't provide hand-tuned assembly but even then, -mtune should do be able to bring the performance benefits on the newer CPUs while still running on the older ones. I agree with you the performance view. But from gcc view, Intel 64 cpu is: nocona, core2 or later. In my memory, I never hear someone can run 64 bit windows on nocona without problem. I know it's unfair for AMD CPUs, but both without -march and with -march=amd cpu type give 3DNow defined, it's not acceptable for Intel CPUs. Intel 64 is a name that doesn't exist. It's either AMD64 (AMD parlance), EM64T (Intel parlance), x64 (Microsoft parlance) or x86_64 (parlance of anyone not interested in marketing and propaganda). The first CPUs handling x86_64 date from 2003 and were server-class CPUs. Using --with-arch=core2 means that there many CPUs sold during pretty much *10* years will not be able to run the programs compiled with these toolchains and will crash at surprising times in surprising ways. Right now I have a Windows 8 x86_64 VM running on a CPU from 2009 or 2010 without SSSE3. Actually it maybe doesn't have SSE3 either. I've never had issues with x86_64 stuff on it. I've also grabbed my XP 64 box and there's a cute logo of a Pentium 4. While everyone will agree XP 64 was far from perfect, I think it's a good indication that it worked at least for some people. As for not specifying any arch, I wasn't able to quickly find a reference or documentation on the matter. However, Linux distributions are a good example however: they run on all x86_64 CPUs and don't set anything specific and that's what a generic toolchain should do too. In any case, if not setting --with-arch makes code that cannot run on the triplet specified during the build of GCC (which I do not believe) then this is an issue in GCC and should be dealt in GCC and not worked-around (but again, I believe it is not the case). -- Adrien Nader Just pick Linux 64 bit gcc: gcc -dM -E - /dev/null | grep -i k8 #define __k8 1 #define __k8__ 1 From http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86-64-Options.html , k8 is: Processors based on the AMD K8 core with x86-64 instruction set support, including the AMD Opteron, Athlon 64, and Athlon 64 FX processors. (This supersets MMX, SSE, SSE2, 3DNow!, enhanced 3DNow! and 64-bit instruction set extensions.) By the way, You can use your prefer -march when compile programs. It's best practices, many people use -march to support newer or older CPUs, no one default setting suits us all. Indeed, it defines k8. And on debian x86_64, Slackware Linux x86_64 and even on Mac OS X even though that OS has never officially been compatible with AMD CPUs! The difference is most probably that 3DNow has almost no use (if not completely none) compared to SSE2. While it is admittedly quite ugly not to have an option for something completely
