You seem to have opted to use the C files instead of the arm-specific assemblies, probably because of clang instruction errors.
To deal with those, try this: remove the "ARG*_in" arguments to macros in the h files, and then change instruction names for clang to understand them:
str[lt|gt|..]h -> strh[lt|gt|..]
ldr[lt|gt|ne|..]sh -> ldrsh[lt|gt|ne|..]
ldr[lt|gt|ne|..]h -> ldrh[lt|gt|ne|..]
as you can see, gcc likes the conditionals right after the instruction, while clang likes its conditionals at the end.
With this done (sed easily does all of this), the codec compiles nicely without any problems.
Let know if you succeed, can fork with fixed code if needed.
I don't think I understand what you mean. Both ARM specific assemblies and generic C files are present, because that's how the original source code is distributed. The ARM assemblies are chosen over the generic C implementation depending on preprocessor flags.
As you can see in 92b5758, I have already made changes to make the assembly files compile under Clang. The only exception is SKP_Silk_CLZ16, which I don't understand how to fix, so I used the C version.
Which assemblies are you referring to? I would love to be able to optimize the code further, its CPU usage is still, even with the lowest complexity setting, a bit high.
I'm using Apple clang version 3.1 (tags/Apple/clang-318.0.61) (based on LLVM 3.1svn)
This is the Clang version that is bundled with Xcode 4.3.3 (I think the compiler is bundled with Xcode, and not the iOS SDK).
Perhaps something has changed with version 4.0. If you want to, you could fork, fix it so it works for you and make a pull request. Then I will see if it works for me too and merge the fixes.
I just upgraded to Xcode 4.4, and experienced the issue you described. Your suggested changes are implemented as of 367e31c.
Thanks for helping out with this, it would have taken me ages to figure this out!