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 compatible for every CPU, it
_works_. It's a kind of bet but so far it has worked well enough that
noone seems to have complained.

The whole matter is of providing sane defaults. Even when trying to use
another -march, there are build systems which do not handle
user-specified CFLAGS.

Default arch set to core2 _will_ cause issues and is inappropriate in a
generic toolchain.

-- 
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

Reply via email to