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

[Alexander Leidinger]

On Wed, 17 Mar 2004 16:22:08 -0800
"David O'Brien" <obrien at freebsd.org> wrote:

> On Mon, Mar 15, 2004 at 06:03:24PM +0100, Alexander Leidinger wrote:
> > > >   Problems with icc v8:
> > > >    - panic: npx0 cannot be emulated on an SMP system
> > > >    - UP: first start of /bin/sh results in a FP exception
> > > 
> > > You forgot the other problems with icc v8 -- Intel's preditorial
> > > behavior.  Note that some parts of the Intel compilers support libs do a
> > > CPUID call and if it notes an AMD CPU either segfaults or dumbs down the
> > > capabilities of the CPU to that of the original i386.
> > 
> > AFAIK: 
> >  - only if the compiled binary contains the main function
> >    (the kernel doesn't)
> >  - only if you use a specific compiler option, which I don't use here
> 
> It happens in several circumstances, not just when using one particular
> compiler option.

It seems I'm talking about a different part of the behavior than you do.

> > BTW.: AFAIK it doesn't segfault, it exit()s.
> 
> BTW, icc v8 produced binaries will sometimes segfault on AMD processors.
> Trust me, AMD has tested this issue more than you have.

Then the check I mentioned is buggy in the sense of "it does not protect
all cases from segfaulting".

It seems Intel identified some issues regarding icc when used on AMD
processors. 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.

It would be nice, if icc would produce code which also runs without
flaws on AMD processors, but I can't influence such decisions, as I
don't have any relationship with Intel (I just got the commercial
license of icc for FreeBSD because I asked for it).

If you are able to provide access to a similar good compiler for (a
subset of) the ia32 architecture, I'm willing to give it a try too. ATM
I'm working with Tom Rhodes and Bruce Evans to change the compiler tests
to feature tests. Support for another compiler should be very easy to
add then.

> > Any manufacturer is free to limit the use of his programs as he wants. I
> > agree, this behavior isn't nice, but life isn't nice either (sometimes).
> 
> Then I'd like to take the stance of reanble the blind use of EFER.NXE in
> the FreeBSD/amd64 loader -- Intel ia32e can just add that feature.

It seems you're aware that this causes problems on Intel processors.
Enabling the use of it is questionable then. 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.

Bye,
Alexander.

-- 
           I will be available to get hired in April 2004.

http://www.Leidinger.net                       Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7