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