Although 'register' is deprecated, we need to use v1, and there's
no way to do that through register constraints on the assembler
fragment itself.
Change-Id: Ib5b12c4c3652513d10cc61d4a4b11314ece25663
In c++11, register has been deprecated, and
libc is now built as gnu++11
From the documentation:
A register specifier is a hint to the implementation
that the variable so declared will be heavily used.
[ Note: The hint can be ignored and in most implementations
it will be ignored if the address of the variable is taken.
This use is deprecated (see D.2)
Change-Id: I459dc3f5f9de63fc09eeda3bc6700f31bdf20f6f
From the release notes:
Changes affecting current and near-future time stamps
Morocco now observes DST from the last Sunday in March to the last
Sunday in October, not April to September respectively. (Thanks
to Steffen Thorsen.)
Change-Id: I9a657a1b819ce17bb424474d4bcdae093f4c4dca
This is basically the other half of I5de76f6c46ac87779f207d568a86bb453e2414de
from Pavel Chupin <pavel.v.chupin@intel.com>, but taking the exact upstream
_types.h instead of the modified version. (I was confused when I suggested
otherwise.)
I've also cleaned up the internal_types.h situation; we weren't gaining
anything from these empty files, and there is no upstream internal_types.h
for x86_64.
Change-Id: I802a9a6a8df1c979e820659212c75a47c2ef392e
This is basically half of I5de76f6c46ac87779f207d568a86bb453e2414de from
Pavel Chupin <pavel.v.chupin@intel.com>, but with the stock upstream
setjump/sigsetjmp and H.J. Lu's suggested changes to __rt_sigreturn.
Change-Id: I8167ec228faeb2065391e5bec0413cca662f3d33
FORTIFY_SOURCE prevents buffer overflows from occurring.
However, the error message often implies that we only
detect it, not prevent it.
Bring more clarity to the error messages by emphasizing
prevention over detection.
Change-Id: I5f3e1478673bdfc589e6cc4199fce8e52e197a24
Got it all wrong on first patch. Somehow that didn't affect system
build, neither arm nor x86... something to think about.
Change-Id: I45416d843aad44af62841c6f6ab607ccf3f012ea
Signed-off-by: Pavel Chupin <pavel.v.chupin@intel.com>
The NDK ABI requires that you support SSE2, and the build system won't let you
build with ARCH_X86_HAVE_SSE2 set to false. So let's stop pretending this
constant is actually a variable, and let's remove the corresponding dead code.
Also, the USE_SSE2 and USE_SSE3 macros are unused, so let's not bother
setting them.
Change-Id: I40b501d998530d22518ce1c4d14575513a8125bb
Make sure the buffer we're dealing with has enough room.
Might as well check for memory issues while we're here,
even though I don't imagine they'll happen in practice.
Change-Id: I0ae1f0f06aca9ceb91e58c70183bb14e275b92b5
memcpy.a15.S/strcmp.a15.S files were submitted by ARM for use as the basis
for the memcpy/strcmp implementations in cortex-a15.
memset.S was moved in to the generic directory.
NOTE: memcpy.a9.S was submitted by Linaro to be the basis for the memcpy
for cortex-a9/cortex-a15 but has not been incorporated yet.
Bug: 10971279
Merge from internal master.
(cherry-picked from 48fc3e8b9f)
Change-Id: I8f9297578990d517f004e4e8840e2b2cbd5a47d8
The check for __ARM_FEATURE_DSP being defined is pointless since it
is always defined.
Bug: 10971279
Merge from internal master.
(cherry-picked from d2642fa70c)
Change-Id: If23ab3271f4da0c38cd531ffdc9a7e5eed6ec5dc
malloc and family were not declared with __attribute__((alloc_size)).
This was (sometimes) preventing FORTIFY_SOURCE related functions
from knowing the size of the buffer it's dealing with, inhibiting
FORTIFY_SOURCE protections.
Add __attribute__((alloc_size))
Information about the alloc_size attribute can be found
at http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
Change-Id: Ia2f0a445f0170a7325f69259b5e7fb35a9f14921
Clang and gcc default to different standards, so we should be explicit
about the versions we want to compile for.
Change-Id: I65495a2392dd29f36373b94c616c2506173e6033
I've no idea what _BITSIZE was supposed to be, glibc doesn't have it,
the BSDs don't have it, and no code is currently using it. But having
it set unconditionally to 32 sounds like a bad idea.
Change-Id: I900235c1489afba891fff0bc3b43e9d593249a4f
