aboutsummaryrefslogtreecommitdiff
path: root/iconvdata
diff options
context:
space:
mode:
authorJoseph Myers <joseph@codesourcery.com>2017-01-19 00:05:34 +0000
committerJoseph Myers <joseph@codesourcery.com>2017-01-19 00:05:34 +0000
commit3a66b2b0637e439fb0e7a14c6c3d4c58190eec61 (patch)
tree04a7b7a3c6680075e33ebb1e503d6d511ff20ffb /iconvdata
parentcd880aa2ccabecd1a258b39b987160f0e86fd52d (diff)
downloadglibc-3a66b2b0637e439fb0e7a14c6c3d4c58190eec61.zip
glibc-3a66b2b0637e439fb0e7a14c6c3d4c58190eec61.tar.gz
glibc-3a66b2b0637e439fb0e7a14c6c3d4c58190eec61.tar.bz2
Fix ARM fpu_control.h for assemblers requiring VFP insn names (bug 21047).
Bug 21047 reports that the clang assembler disallows the ARM implementations of _FPU_GETCW and _FPU_SETCW. These are deliberately written the way they are, using generic coprocessor instructions (from the days when VFP was just one possible coprocessor for ARM) that have the right encodings, to handle the case of the instructions being used runtime-conditionally inside glibc, where use of these macros is not meant to result in either the assembler requiring VFP to be enabled at assembly time or in it marking the object as using VFP. However, more recent ARM ARM versions have restricted the definitions of the coprocessor instructions and reportedly the clang assembler follows that in disallowing those names for VFP instructions. In the non-__SOFTFP__ case - which in fact is the only case where these macro definitions can be used outside the build of glibc itself - using VFP instruction names is of course fine, since we know that VFP is enabled for that compilation. Thus, this patch uses the current VFP names for these instructions in that case to improve compatibility for this header file. Tested for hard-float and soft-float builds of glibc, including that installed stripped shared libraries are unchanged by the patch. [BZ #21047] * sysdeps/arm/fpu_control.h [!__SOFTFP__] (_FPU_GETCW): Use VFP name for instruction. [!__SOFTFP__] (_FPU_SETCW): Likewise.
Diffstat (limited to 'iconvdata')
0 files changed, 0 insertions, 0 deletions