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
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to