Do we have a CPUTYPE=native and/or generic stability problem?

Alexander Leidinger Alexander at Leidinger.net
Sun Nov 4 21:55:32 UTC 2012


On Sun, 04 Nov 2012 00:46:15 +0100 Dimitry Andric <dim at FreeBSD.org>
wrote:

> On 2012-11-03 23:24, Alexander Leidinger wrote:
> > while trying to update from r239708 to r242511 (amd64 arch) I tried
> > to compile the world with "make -j8". After a short while I got an
> > internal error in the clang compile (this is a gcc-compiled system,
> > I don't use clang). The CFLAGS/COPTFLAGS are -O2 -pipe.
> >
> > Without the -j8 it compiles just fine.
> > Without the CPUTYPE?=native it compiles even with -j8.
> 
> Hm, at first I thought you might be running out of RAM, but apparently
> that is not the case then. :)

The machine has 12 MB RAM (no swap configured), after nearly a day
uptime it looks like this:

---snip---
Mem: 348M Active, 599M Inact, 9281M Wired, 264K Cache, 1548M Free
ARC: 7117M Total, 1607M MRU, 3996M MFU, 934K Anon, 208M Header, 1307M Other
---snip---

I would not expect an internal compiler error when I run out of RAM.

> > The CPU is an Intel(R) Xeon(R) CPU (L5630) with ECC ram.
> 
> What does gcc detect for this CPU with -march=native?  You can do:
> 
>    gcc -march=native -v -c -x c /dev/null 2>&1 | grep -- -march
> 
> to see what it passes to the second stage.

---snip---
 # gcc -march=native -v -c -x c /dev/null 2>&1 | grep -- -march
 /usr/libexec/cc1 -quiet -v -D_LONGLONG /dev/null -march=core2
 -mtune=generic -quiet -dumpbase null -auxbase null -version
 -o /tmp//cc7kc0JI.s
---snip---

Bye,
Alexander.

-- 
http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137


More information about the freebsd-current mailing list