On Sat, Apr 26, 2014 at 11:49 PM, Dongsheng Song <[email protected]> wrote: > On Sat, Apr 26, 2014 at 10:25 PM, Adrien Nader <[email protected]> wrote: >> On Sat, Apr 26, 2014, Dongsheng Song wrote: >>> On Sat, Apr 26, 2014 at 3:22 PM, Adrien Nader <[email protected]> wrote: >>> > On Sat, Apr 26, 2014, Dongsheng Song wrote: >>> >> On Sat, Apr 26, 2014 at 12:31 AM, Adrien Nader <[email protected]> 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 [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
