On 03/07/2011 14:56, Alexander Best wrote:
"native" doesn't get handled by bsd.cpu.mk at all! it gets passed to gcc
directly and gcc choses -m{tune,arch} on it's own.
don't add -march=* directly to CFLAGS. this is bound to go wrong at some
point. use CPUTYPE to set the cpu and CFLAGS for -O*, -p
This change did NOT add SSSE3 or any other new instruction sets to our
base compiler.
The only change of using -march=core2 vs -march=nocona is actually
different instruction costs that may result
in binaries more optimized for your core2 and later CPUs (and less
optimized for nocona and earlier C
This actually does not happen at the bootstrap stage, but when
building 32-bit compat libs under amd64. It looks like the system
compiler is used here instead (should it be this way, isn't it a bug
somewhere around Makefile.inc1?).
Yes, building + installing world without this optimization makes i
> "native" doesn't get handled by bsd.cpu.mk at all! it gets passed to gcc
> directly and gcc choses -m{tune,arch} on it's own.
>
> don't add -march=* directly to CFLAGS. this is bound to go wrong at some
> point. use CPUTYPE to set the cpu and CFLAGS for -O*, -pipe, etc.
>
> also please keep in mi
On Tue Mar 8 11, George Liaskos wrote:
> > either "native" or "nocona" (actually native should evaluate to nocona):
> >
> > touch _native_test.c && gcc -march=native -### _native_test.c
> >
> > should tell which -march and -mtune settings gcc assumes for "native".
> >
> > indeed there are some kno
> either "native" or "nocona" (actually native should evaluate to nocona):
>
> touch _native_test.c && gcc -march=native -### _native_test.c
>
> should tell which -march and -mtune settings gcc assumes for "native".
>
> indeed there are some known problems with "native", but i think those are
> lim
On Mon Mar 7 11, George Liaskos wrote:
> >What process did you follow to get here?
>
> I did a make toolchain followed by make buildworld.
>
> > that's because the latest gcc commits have support for core2 and thus it no
> > longer is being expanded to nocona. please note that having core2 in
>
On Mon, Mar 07, 2011 at 11:19:40PM +0200, George Liaskos wrote:
> >What process did you follow to get here?
>
> I did a make toolchain followed by make buildworld.
>
> > that's because the latest gcc commits have support for core2 and thus it no
> > longer is being expanded to nocona. please note
>What process did you follow to get here?
I did a make toolchain followed by make buildworld.
> that's because the latest gcc commits have support for core2 and thus it no
> longer is being expanded to nocona. please note that having core2 in make.conf
> has always been *wrong*. hence the need to
On Mon Mar 7 11, George Liaskos wrote:
> Hi,
>
> The following error occurs when i try to build r219385.
>
> cc -O2 -pipe -march=core2 -DHAVE_CONFIG_H
> -I/usr/src/kerberos5/tools/make-roken/../../include -std=gnu99 -c
> make-roken.c
> make-roken.c:1: error: bad value (core2) for -march= switc
Hi,
The following error occurs when i try to build r219385.
cc -O2 -pipe -march=core2 -DHAVE_CONFIG_H
-I/usr/src/kerberos5/tools/make-roken/../../include -std=gnu99 -c
make-roken.c
make-roken.c:1: error: bad value (core2) for -march= switch
make-roken.c:1: error: bad value (core2) for -mtune= s
11 matches
Mail list logo
