Copy stable/10@r272459 to releng/10.1 as part of
the 10.1-RELEASE process.

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

MFC r260311, r260831:

gcc: Add support for Apple's Block extension

Block objects [1] are a C-level syntactic and runtime feature. They
are similar to standard C functions, but in addition to executable
code they may also contain variable bindings to automatic (stack)
or managed (heap) memory. A block can therefore maintain a set of
state (data) that it can use to impact behavior when executed.

This port is based on Apple's GCC 5646 with some bugfixes from
Apple GCC 5666.3. It has some small differences with the support
in clang, which remains the recommended compiler.

Perhaps the most notable difference is that in GCC __block is not
actually a keyword, but a macro. There may be workaround for this
issue in the future. Other issues can be consulted in the clang
documentation [2]

For better compatiblity with Apple's GCC and llvm-gcc, some related
fixes and features from Apple have been included. Support for the
non-standard nested functions in GCC is now off by default.

No effort was made to update the ObjC support since FreeBSD doesn't
carry ObjC in the base system but some of the code crept in and
was more difficult to remove than to adjust.

References:
[1]
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Blocks/Articles/00_Introduction.html
[2]
http://clang.llvm.org/compatibility.html#block-variable-initialization

Obtained from: Apple GCC 4.2

MFC r260014, r260099:

gcc: Add support for label attributes and "unavailable" attribute.

Apple GCC has extensions to support for both label attributes and
an "unavailable" attribute. These are critical for objc but are
also useful in regular C/C++.

Obtained from: Apple GCC 4.2 - 5531

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

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

Make gcc use C99 inline semantics in c99 and gnu99 mode. This was the
original intent, but the functionality wasn't implemented until after
gcc 4.2 was released. However, if you compiled a program that would
behave differently before and after this change, gcc 4.2 would have
warned you; hence, everything currently in the base system is
unaffected by this change. This patch also adds additional warnings
about certain inline function-related bogosity, e.g., using a
static non-const local variable in an inline function.

These changes were merged from a snapshot of gcc mainline from March
2007, prior to the GPLv3 switch. I then ran the regression test suite
from a more recent gcc snapshot and fixed the important bugs it found.
I also squelched the following warning unless -pedantic is specified:

foo is static but used in inline function bar which is not static

This is consistent with LLVM's behavior, but not consistent with gcc 4.3.

Reviewed by: arch@

FreeBSD uses unchanged versions of this files.

Use stock GCC versions on these files.

FreeBSD uses stock versions of these GCC files.

Use pure stock files.

Use the stock 3.2.1-prerelease file.

Approved by: obrien

Use the stock 3.1 prerelease file.

Go back to stock [3.1-snap] file -- our previous mods are OBE.

Go back to stock file -- our mods are OBE.

Fix conflicts. This brings the "printf0" addition into EGCS 1.1.2.

Add support for a new archetype "printf0" for the "format" function
attribute. It is like the existing "printf" archetype, except that
it doesn't complain if the format string is a null pointer. See
the node "Function Attributes" in the GCC info pages if you don't
know what this is all about.

This change will allow us to add format string checking for the
err(3) family of functions.

This commit was generated by cvs2svn to compensate for changes in r18334,
which included commits to RCS files with non-trunk default branches.

Import of unmodified (but trimmed) gcc-2.7.2. The bigger parts of the
non-i386, non-unix, and generatable files have been trimmed, but can easily
be added in later if needed.

gcc-2.7.2.1 will follow shortly, it's a very small delta to this and it's
handy to have both available for reference for such little cost.

The freebsd-specific changes will then be committed, and once the dust has
settled, the bmakefiles will be committed to use this code.