- Copy stable/10 (r259064) to releng/10.0 as part of the
10.0-RELEASE cycle.
- Update __FreeBSD_version [1]
- Set branch name to -RC1

[1] 10.0-CURRENT __FreeBSD_version value ended at '55', so
start releng/10.0 at '100' so the branch is started with
a value ending in zero.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Add a new CPUTYPE supported by Clang 3.3 for AMD Jaguar processors (btver2).

Nuke ARM_WANT_TP_ADDRESS, it's not used anymore.
Don't force -march=armv6 for Cortex A, as we want at least armv6k. The
compiler default is good enough.

Fix typos in the previous commit.

Tidy up bsd.cpu.mk for X86 CPUs:

- Do not limit recent processors to "prescott" class for i386 target. There
is no reason for this hack because clang is default now. On top of that, it
will only grow indefinitely over time.
- Add more CPUTYPEs, i.e., "athlon-fx", "core-avx2", "atom", "penryn", and
"yonah". Note "penryn" and "yonah" are intentionally undocumented because
they are not supported by gcc and marked deprecated by clang.
- Add more CPUTYPE aliases, i.e., "barcelona" (-> amdfam10), "westmere" and
"nehalem" (-> corei7). Note these are intentionally undocumented because
they are not supported by (base) gcc and/or clang. However, LLVM (backend)
seems to "know" the differences. Most likely, they were deprecated with
other vendor code names and clang did not bother implementing them at all.
- Add i686 to MACHINE_CPU for "c3-2" (VIA Nehemiah). Both gcc & clang treat
it like an i686-class processor.
- Add IDT "winchip2" and "winchip-c6" for completeness (undocumented).
- Order processors per make.conf example, i.e., CPU vendors and models.
- Tidy up make.conf example, i.e., remove "by gcc" (because we have aliases)
and remove "prescott" from AMD64 architecture (because it is not correct).

Remove fictitious support for 80386-class CPUs from bsd.cpu.mk and make(1).
It was removed from head more than 8 years ago (see r137784 and r137785).

Reviewed by: imp, delphij, dim

Add x86 CPUs supported by clang on head.

Reviewed by: arch (silence)
X-MFC: r242624

Merging of projects/armv6, part 3

r238211:
Support TARGET_ARCH=armv6 and TARGET_ARCH=armv6eb

This adds a new TARGET_ARCH for building on ARM
processors that support the ARMv6K multiprocessor
extensions. In particular, these processors have
better support for TLS and mutex operations.

This mostly touches a lot of Makefiles to extend
existing patterns for inferring CPUARCH from ARCH.
It also configures:
* GCC to default to arm1176jz-s
* GCC to predefine __FreeBSD_ARCH_armv6__
* gas to default to ARM_ARCH_V6K
* uname -p to return 'armv6'
* make so that MACHINE_ARCH defaults to 'armv6'
It also changes a number of headers to use
the compiler __ARM_ARCH_XXX__ macros to configure
processor-specific support routines.

Submitted by: Tim Kientzle <kientzle@freebsd.org>

Remove support for the Intel C Compiler from the build infrastructure.
This support has not worked for several years, and is not likely to work
again, unless Intel decides to release a native FreeBSD version of their
compiler. ;)

Add ssse3 capability for CPUTYPE=core2 to MACHINE_CPU in bsd.cpu.mk

MFC after: 2 weeks

Add AMD Geode CPU type to bsd.cpu.mk and examples/etc/make.conf
For CPUTYPE=core2 use -march=core2

PR: gnu/155308
MFC after: 2 weeks

Add opteron-sse3, athlon64-sse3 and k8-sse3 cpu types to bsd.cpu.mk.
- add "sse3" to MACHINE_CPU for the new cpu types
- for i386, default to CPUTYPE=prescott for the new cpu types

PR: gnu/154906
Discussed with: kib, kan, dim
MFC after: 2 weeks

- Add CPUTYPE support for sparc64. The net result is that it's now possible
to let the compiler optimize for the famility of UltraSPARC-III CPUs as the
default already was to optimize for UltraSPARC-I/II and generating generic
64-bit V9 is mainly for reference purposes. At least for SPARC64-V CPUs
code optimized for UltraSPARC-I/II still is the most performant one.
Thanks go to Michael Moll for testing SPARC64-V.
- Move a booke MACHINE_CPU bit into the right section.

This case is actually powerpc specific, and doesn't apply to powerpc64.

Submitted by: nathanw@

Complete the integration of tbemd branch into head.

TARGET_BIG_ENDIAN is now completely dead, except where it was
originally supposed to be used (internally in the toolchain building).

TARGET_ARCH has changed in three cases:
(1) Little endian mips has changed to mipsel.
(2) Big endian mips has changed to mipseb.
(3) Big endian arm has changed to armeb.

Some additional changes are needed to make 'make universe' work on arm
and mips after this change, so those are commented out for now.

UPDATING information will be forthcoming. Any remaining rough edges
will be hammered out in -current.

Prefer MACHINE_CPUARCH to MACHINE_ARCH unless there's a good reason...

Now that we default to the proper endian, we don't need these for mips

Minor modifications to know what to do with powerpc64.

When CPUTYPE is defined to any value, on amd64 platform "mmx" is
available through MACHINE_CPU, indicating the CPU supports that
feature, as done by revision 138685.

This changeset adds "mmx" into the default amd64 MACHINE_CPU list
when no CPUTYPE is specified to provide consistent behavior.

PR: amd64/145593
Submitted by: mm
MFC after: 2 weeks

-mabi-calls and -msoft-float aren't needed either

Submitted by: jmallet@

-mno-dsp hasn't been required for a while now.

Kernel module support for mips.

Reviewed by: gonzo

Tested by: Alexandr Rybalko (ray@dlink.ua)

Add support for 64-bit PowerPC CPUs operating in the 64-bit bridge mode
provided, for example, on the PowerPC 970 (G5), as well as on related CPUs
like the POWER3 and POWER4.

This also adds support for various built-in hardware found on Apple G5
hardware (e.g. the IBM CPC925 northbridge).

Reviewed by: grehan

Explicitly disable generation of Altivec instructions in the kernel on PowerPC,
and add support to allow users to set their CPUTYPE in make.conf.

Fix links to online gcc docs.

Reported by: Andre Guibert de Bruet <andy@siliconlandmark.com>
MFC after: 1 day

Add support for MACHINE_ARCH == mips, plus a few generic CPU types that
will be supported in the forth coming FreeBSD/mips port.

Connect MPC85XX to the PowerPC build.

The kernel config file is KERNCONF=MPC85XX, so the usual procedure applies:

1. make buildworld TARGET_ARCH=powerpc
2. make buildkernel TARGET_ARCH=powerpc TARGET_CPUTYPE=e500 KERNCONF=MPC85XX

This default config uses kernel-level FPU emulation. For the soft-float world
approach:

1. make buildworld TARGET_ARCH=powerpc TARGET_CPUTYPE=e500
2. disable FPU_EMU option in sys/powerpc/conf/MPC85XX
3. make buildkernel TARGET_ARCH=powerpc TARGET_CPUTYPE=e500 KERNCONF=MPC85XX

Approved by: cognet (mentor)
MFp4: e500

Add a 'c7' CPUTYPE for VIA C7 CPUs that is 'c3-2' with the addition of
i686, sse2, and sse3.

MFC after: 1 week

Backout rev 1.62, and revert to use -march=armv5te -D__XSCALE__ instead
of -mcpu=xscale for XScale.
gcc still has issues with -mcpu=xscale, and now crashes while building
systat.

Reported by: sam
MFC After: 3 days

GCC doesn't segfault anymore while building world with -mcpu=xscale, so use it.

"If I only had a brain..."

MFC after: 3 weeks

Correct errors in previous commit. I didn't realize that ${CPUTYPE} is
passed unmodified to gcc. Therefore, "prescott" should be used for Prescott,
Nocona, Core and Core 2 CPUs when building 32-bit code, and "nocona" should
be used for Prescott, Nocona and Core 2 CPUs when building 64-bit code.

MFC after: 3 weeks

On i386, make "prescott" an alias for "nocona" (instead of the other way
around), and introduce "core", along with the alias "core2". All of these
enable SSE3.

On amd64, add "core2" (enables SSE3).

MFC after: 3 weeks

Use TARGET_BIG_ENDIAN instead of ARM_BIG_ENDIAN

Remove alpha left-overs.

Revert previous commit. Pre-Nehemiah C3 CPUs do have 3DNow!; it doesn't
show up in dmesg because identcpu.c only looks for it on Intel and AMD
processors.

I don't know where I got the idea that the VIA C3 has 3DNow!; it doesn't.
It does have MMX (though MMX support is reputed to be incomplete in early
generations), and later generations have SSE.

MFC after: 2 weeks

Grr we also need to set -mbig-endian to LDFLAGS. Now I can build a
big-endian arm world.

Remove ALPHA optimization pointer for gcc flags.
Add ARM optimization pointer for gcc flags.

Oops LDFLAGS can be used to invoke gcc, so directly add -EB to {LD}.

Honor ARM_BIG_ENDIAN by adding -mbig-endian to CFLAGS and -EB to LDFLAGS if
it is defined.

Add CPUTYPE support for Via C3 and C3-2 processors.

MFC after: 2 weeks

Add a MACHINE_CPU entry for "ev67".

Use -march=armv5te for Xscale.

Rev 1.44 was a little over-zealous for FreeBSD/AMD64, trim.

No need to add I386_CPU to CFLAGS here for 80386 systems as they are no
longer supported.

Define "I386_CPU" if CPUTYPE is 'i386'. Userland bits can check for "I386_CPU"
to determine if they should select code paths suitable for the 80386 CPU.

Suggested by: ru

Embellish the AMD64 sections a little. Including supporting 'nocona'.

+ Simplify by treating the standard x86 CPU names as the CPUTYPE vs.
treating them as an alias. Treat the shorthand versions as aliases.
+ Separate the x86 GCC CPU CFLAGS from the ICC CFLAGS. This greatly
simplifies the GCC section. It also makes it more clear which CPU's
have the same ICC CPU CFLAGS.
+ Remove redundancy in the alpha section.
+ Add forgotten ICC CPU CFLAGS for the mobile Intel CPU's added in rev. 1.42.

Add support for Pentium M, Pentium 3M and Pentium 4M.

PR: i386/72340
Submitted by: Rong-En Fan <rafan@infor.org>
MFC after: 2 weeks

Add CPUCFLAGS for the strongarm and xscale CPUs.

Add more aliases for common CPUTYPE spellings

Consistently list _CPUCFLAGS.

Define MACHINE_CPU for arm.

Add ${CPUTYPE} support for crusoe processors (cribbed from Linux kernel
settings). Pretend that a crusoe is an i686 which doesn't like alignment
padding.

Add a reference to the ia64 options to gcc. While here, sort the list.

Fix some style bugs in previous commit.
Fix 'broken' ifdefs.
icc does not support profiling yet so remove unfinished code which was
supposed to help.

Submitted by: netchild (original version)
Reviewed by: ru

This are the build infrastructure changes to allow to use the
Intel C/C++ compiler (lang/icc) to build the kernel.

The icc CPUTYPE CFLAGS use icc v7 syntax, icc v8 moans about them, but
doesn't abort. They also produce CPU specific code (new instructions
of the CPU, not only CPU specific scheduling), so if you get coredumps
with signal 4 (SIGILL, illegal instruction) you've used the wrong
CPUTYPE.

Incarnations of this patch survive gcc compiles and my make universe.
I use it on my desktop.

To use it update share/mk, add
/usr/local/intel/compiler70/ia32/bin (icc v7, works)
or
/usr/local/intel_cc_80/bin (icc v8, doesn't work)
to your PATH, make sure you have a new kernel compile directory
(e.g. MYKERNEL_icc) and run
CFLAGS="-O2 -ip" CC=icc make depend
CFLAGS="-O2 -ip" CC=icc make
in it.

Don't compile with -ipo, the build infrastructure uses ld directly to
link the kernel and the modules, but -ipo needs the link step to be
performed with Intel's linker.

Problems with icc v8:
- panic: npx0 cannot be emulated on an SMP system
- UP: first start of /bin/sh results in a FP exception

Parts of this commit contains suggestions or submissions from
Marius Strobl <marius@alchemy.franken.de>.

Reviewed by: silence on -arch
Submitted by: netchild

Fixed indentation of conditionals.

Submitted by: Rostislav Krasny <rosti_bsd@yahoo.com>

Fixed some style bugs (long lines).

Drop -mcpu=pentiumpro from the default CPU flags for i386 as it doesn't
perform better than the default setting for most i386 CPUs.

Requested by: bde

Keep up with sys/conf/ changes.

Since -march=pentium4 is supposed to be fixed with GCC 3.3, and
since people have been reporting success with it, re-enable the
pentium4 optimization.

Change -march=pentium4 to -march=pentium3 when CPUTYPE==p4, because gcc 3.2 is
known to produce broken code with -march=pentium4. Add a note explaining this.
This should be removed when we update to gcc 3.3 or the bug is otherwise fixed.

Approved by: re

s/x86[-_]64/amd64/ for MACHINE_ARCH and MACHINE_CPU .ifdefs.

Noticed by: ru
Approved by: re (amd64-specific low risk stuff)

Add CPUTYPE support for "athlon-tbird", as GCC makes the distinction.

PR: 50801
Submitted by: Glenn Johnson <glennpj@charter.net>

Default the userland to 486 capabilities.

Globally use -mieee in /usr/src for Alpha.

Reduce "code duplication" for AMD CPU's.

Whitespace-only indention fixups for revision 1.20. This lets the 1.20
diff actually be readable.

Oops, fix userland _CPUCFLAGS. Move adding of _CPUCFLAGS to bottom of
file after end of empty CPUTYPE else clause.

For the default case of CPUTYPE not being set, don't define CPUTYPE to the
lowest value in order to get the right MACHINE_CPU values since setting
CPUTYPE can result in problems later in the buildkernel case. Instead,
set MACHINE_CPU directly and leave CPUTYPE alone.

Tested by: mbr

Add support for the AMD x86-64 Hammer platform.

Add support for ev67 and ev45 CPUTYPEs (new in gcc3)

Update to use all the new CPU optimizations of GCC3.

Reviewed by: kris

TARGET_CPUTYPE should exist solely in Makefile.inc1, similar to
TARGET_ARCH and TARGET. This is problematic when one has the =
(unconditional) type of assigment for CPUTYPE in /etc/make.conf.
(This would override what was set on the command line to "make
buildworld".)

Add a (horrible) kludge to Makefile.inc1 to check the type of
assignment for CPUTYPE (only for those who attempts to set it to
a different value). Fix an example make.conf. Fix the kernel's
build-tools target (aicasm only at the moment) to catch up with
bsd.cpu.mk,v 1.15 (BOOTSTRAPPING replaced with NO_CPU_CFLAGS in
Makefile.inc1's BMAKE).

Reviewed by: jhb

- Define NO_CPU_CFLAGS during BMAKE and TMAKE (and thus XMAKE) so that
bsd.cpu.mk doesn't have to worry about compilers other than the current
version.
- Allow TARGET_CPUTYPE to override CPUTYPE in bsd.cpu.mk.
- Treat an empty CPUTYPE the same as an undefined CPUTYPE.
- For buildworld, buildkernel, etc., define TARGET_CPUTYPE to CPUTYPE for
native builds and define it to be empty for cross-builds.
TARGET_CPUTYPE is only defined if it is not already defined via the
commandline or environment.

- Fixup whitespace after previous commit.
- To minimize whitespace changes, remove a test that didn't define
_CPUCFLAGS if both NO_CPU_CFLAGS and NO_CPU_COPTFLAGS were defined
since it is redundant (we don't use _CPUCFLAGS if those are defined).

If there is not a CPUTYPE defined by default, then allow for _CPUCFLAGS
to tune for more advanced processors while still supporting the minimum
processor in an architecture. We can do this with the '-mtune=' option
to gcc for alpha, sparc64, and powerpc and with the mis-named '-mcpu='
option for i386.

This defaults to tuning i386 builds for i686 machines though not using
any instructions that aren't found on an 80386. For alpha it defaults
to tuning for an EV5.

Approved by: peter
Peril sensitive sunglasses borrowed from: peter

In gcc 3.1 Pentium/MMX now has its own -march=XXX option.

Bootstrapping aid for those with Athlon upgrading from gcc 2.95.x.

Prodded by: gordon

Default Alpha compiles to ev5.
EV5 binaries will run on EV4[5], but the timing assumptions do pessimize
running on EV4[5].

Tested by: ticso

Add pointers to GCC's allowable values for -march, and restore structure
of rev 1.7 until someone can sit down and think thru all the GCC 3.1
related changes.

With GCC 3.1, we can now treat AMD Athlon and an Athlon.

Submitted by: Steven G. Kargl <kargl@troutmask.apl.washington.edu>

Add the beginnings of Sparc64 support.

Optimize for i486 better (-m486 is just another deprecated
synonym for -mcpu=i486).

PR: i386/37212
Submitted by: Matthias Andree <matthias.andree@web.de>
MFC after: 3 days

Pentium II's do not support SSE, that came in with the PIII

Submitted by: sf

Use CPUTYPE to add appropriate compiler flags to COPTFLAGS for kernel
builds. This may be disabled using the NO_CPU_COPTFLAGS variable.

Reviewed by: arch

AMD K6/K6-2/Duron/Athlon CPUs support MMX too.

Missed by: kris

Add definitions and support for the AMD k6-2, Pentium MMX (i586/MMX),
and Pentium II, III and IV processors (p2, p3, p4), as well as 'mmx' and
'3dnow' MACHINE_CPU tags as appropriate. In the near future this will
be used to control various ports which have MMX/3dNow optimizations,
instead of the ad-hoc methods currently used.

Reviewed by: peter

Overhaul the MACHINE_CPU behaviour:

* Rip out MACHINE_CPU stuff from sys.mk and include a new <bsd.cpu.mk>
after we pull in /etc/make.conf. We need to do it afterwards so we can
react to the user setting of the:

* CPUTYPE variable, which contains the CPU type which the user wants to
optimize for. For example, if you want your binaries to only run on an
i686-class machine (or higher), set this to i686. If you want to support
running binaries on a variety of CPU generations, set this to the lowest
common denominator. Supported values are listed in make.conf.

* bsd.cpu.mk does the expansion of CPUTYPE into MACHINE_CPU using the
(hopefully) correct unordered list of CPU types which should be used on
that CPU. For example, an AMD k6 CPU wants any of the following:
k6 k5 i586 i486 i386
This is still an unordered list so the client makefile logic is simple -
client makefiles need to test for the various elements of the set in
decreasing order of priority using ${MACHINE_CPU:M<foo>}, as before.
The various MACHINE_CPU lists are believed to be correct, but should be
checked.

* If NO_CPU_CFLAGS is not defined, add relevant gcc compiler optimization
settings by default (e.g. -karch=k6 for CPUTYPE=k6, etc). Release
builders and developers of third-party software need to make sure not to
enable CPU-specific optimization when generating code intended to be
portable. We probably need to move to an /etc/world.conf to allow the
optimization stuff to be applied separately to world/kernel and external
compilations, but it's not any worse a problem than it was before.

* Add coverage for the ia64/itanium MACHINE_ARCH/CPUTYPE.

* Add CPUTYPE support for all of the CPU types supported by FreeBSD and gcc
(only i386, alpha and ia64 first, since those are the minimally-working
ports. Other architecture porters, please feel free to add the relevant
gunk for your platform).

Reviewed by: jhb, obrien