Use __typeof__() instead of typeof()

typeof() is a gcc builtin and is not always available (such as clang when
-std=c*). Both gcc and clang always expose __typeof__(), so just use that.

Change-Id: I75e2a990acc35f6f39b2c353f6548100ec03c67f
Workaround the GCC "(long)fn -> lfn" optimization bug.

Pass "-fno-builtin-rint -fno-builtin-rintl -fno-builtin-rintf" to avoid
generating self recursions in lrint, lrintl, and lrintf.

BUG: 14225968
Change-Id: Iffc4d8f0692580d636a529f4c8aa9a7a10d7acd8

Conflicts:
	libm/Android.mk
Use __inline__ for fortify.

libunwind has #define inline /* empty */ which breaks our fortified headers.
glibc uses __inline but our BSD-derived headers often override that. __inline__
is the third alternative understood by GCC that -- as far as I know -- neither
the C library itself nor third-party code tries to mess with.

Bug: 12871594
Change-Id: I6677e70ea531bb7d4c46021b43af760d4ad8ecf7
Clean up the pthread-only atomic stuff a little.

It looks like we can probably just use the generic GCC stuff instead;
the generated code looks pretty similar. We should come back to that.

These routines are only used by the pthread implementation, and
__bionic_atomic_inc isn't used, so we can remove it.

Change-Id: I8b5b8cb30a1b159f0e85c3675aee06ddef39b429
Remove harmful attempts to be helpful in pthread_mutex functions.

Most callers won't check for EINVAL, so it's best to fail early.
GCC takes the nonnull attribute as a guarantee that an argument
won't be NULL, so these hacks were already ineffective, which is
how we found that at least one commercial game was using NULL
as if it's a mutex, but actually getting no-op behavior.

Bug: 11971278
Change-Id: I89646e043d931778805a8b692e07a34d076ee6bf
Move bionic over to GCC's 'warning' attribute.

This is a better solution than the old __warn_references because it's
a compile-time rather than link-time warning, it doesn't rely on something
that doesn't appear to be supported by gold (which is why you only used
to see these warnings on mips builds), and the errors refer to the exact
call site(s) rather than just telling you which object file contains a
reference to the bad function.

This is primarily so we can build bionic for aarch64; building libc.so
caused these warnings to fire (because link time is the wrong time) and
warnings are errors.

Change-Id: I5df9281b2a9d98b164a9b11807ea9472c6faa9e3
Add "__noreturn" to assert and assert2

These functions should print assertion violation messages and then
call abort(). They do really not return control flow afterwards.
Consider the declaration of the similar __assert_fail from glibc:

extern void __assert_fail (const char *__assertion,
                           const char *__file,
			   unsigned int __line,
                           const char *__function)
     __THROW __attribute__ ((__noreturn__));

Bionic has __noreturn defined in sys/cdefs.h to be that GNU
noreturn attribute.

This patch has a practical value. Consider the following function:

void check(void* ptr) {
  assert(ptr != NULL);
}

Without this patch applied, gcc (and presumably clang) shows even in
debug mode:

warning: unused parameter 'ptr' [-Wunused-parameter]

In release mode, NDEBUG is defined and assert() becomes a no-op, as
one should expect. Thus, the warning is shown correctly then.

Another code sample:

float array[2];
int i = 3;
...
assert(i < 2);
array[i] = 0;

gcc says,

warning: array subscript is below array bounds [-Warray-bounds]

In other words, without noreturn attribute, assertions do not
allow a compiler's static analyzer to properly understand
the preconditions.

Change-Id: I3be92e99787c528899cf243ed448c4730c00c45b
Signed-off-by: Vadim Markovtsev <gmarkhor@gmail.com>