cvs commit: src/share/mk bsd.cpu.mk bsd.dep.mk bsd.lib.mk bsd.sys.mk src/sys/conf files kern.mk kern.pre.mk kmod.mk src/sys/dev/aic7xxx/aicasm Makefile

[David O'Brien]

On Thu, Mar 18, 2004 at 04:23:58PM +0100, Alexander Leidinger wrote:
> It seems Intel identified some issues regarding icc when used on AMD
> processors.

Yah, the issue of loosing sales to a better technology.  The issues
aren't technical at all.

> I don't know if there is malicious intend to use some
> specific instructions or not. I don't know if there exist instructions
> which perform the same action with the same efficiency (I don't define
> what "efficient" means in this case) without resulting in a segfault on
> AMD processors.

AMD CPU's are bug-for-bug compatible with Intel's -- they *have* to be.
AMD has multiple huge software compatibility and verification labs to
ensure COTS products depending on weird Intel bugs will work on AMD
processors.

> Intel at least seems to be
> aware of some issues and protects the user from misbehavior. The test
> may be not strict enough in some cases, and maybe too strict in other
> cases, but as long as you can't proof they do this with malicious
> intend, you should try to calm down.

Why do they do a CPUID check and look for "GenuineIntel" vs. looking at
the feature bits "SSE,SSE2"??  Intel's compilers only started acting this
way after AMD announced the Opteron and it was clear that large
enterprise ISV's (who are the users of the Intel compilers) would start
certifying an AMD platform.


Just to be clear -- I'm not against supporting a 2nd compiler in /usr/src
at all.  Just don't think Intel is the most gracious compiler vendor.
I'll also strongly push back on ever using 'icc' as part of the release
build.

-- 
-- David  (obrien at FreeBSD.org)