The former processor name "arm1176j-s" does not exist according to http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.set.arm11/index.html and causes issues when actually being used during compilation (I tried to compile libffi 3.2 with clang for old iOS, which defaults to "armv6k", and it failed because invalid instructions were used).
It looks like r246930 did introduce the use of that name. The comments on the diff (D11590) for the revision suggest that it was known that this CPU name is invalid and suggest they removed it. However, the wrong processor name still ended up in the finally committed patch.
I reverted the processor name back to the former default "arm1176jzf-s" and introduced a new entry for "armv6k" without VFP which uses "arm1176jz-s", which are the first processor to support ARMv6k extensions starting from their first revision as far as I can tell from the docs on arm.com.
This sadly causes some regressions in the Clang unit tests. Clang appareantly assumes when you target CPU "arm1176jzf-s" you automatically target architecture "armv6kz". This looks like a sane thing, but now breaks because CPU "arm1176jzf-s" is used for both architectures. As a result, "armv6k" is targetted now when targetting CPU "arm1176jzf-s". I have some patch for Clang which marks the respective unit tests as FIXME and correctly adepts the tests for default processor for "armv6k". I will put it in a diff in case this one makes it.