5 ms·
When we tried using clang for Android compiling C++ code half a year ago it caused problems, which disappeared when we switched to GCC. > If you have problems
by tobias3 11y ago
When we tried using clang for Android compiling C++ code half a year ago it caused problems, which disappeared when we switched to GCC.
> If you have problems with Clang, please file bugs!
Filing compiler bugs is really hard with a closed source project.
- jmtulloss 11y agoI thought this aspect of android was all open source? I may be mistaken. In any event, you can file bugs here: https://code.google.com/p/android/issues/list?q=label:Component-Tools https://code.google.com/p/android/issues/list?q=label:Compon...
- tobias3 11y agoSorry, I meant that the project being compiled was closed source.
- salgernon 11y agoCompiler bugs are usually limited to a single compilation unit and are usually submitted by doing a binary search on a pre processed source file. This is certainly true for closed source as well - just redact the (few) symbol names and create something that will compile to an a.out that demonstrates the problem. God saves a puppy anytime someone filed a compiler bug with a trivial test case that demonstrates the problem.
- onedognight 11y ago> God saves a puppy anytime someone filed a compiler bug with a trivial test case that demonstrates the problem. The current (r10e) shipping version of clang cannot return 128bit floats from a function. #include <iostream> int main(int c, char **v) { std::stringstream("1.5"); double x; s >> x; return x == 1.5 ? 0 : 1; } EDIT: You don't need "long double" in the above. double (or float) will show the problem. The standard library converts all floating point numbers to long double internally.
- eddyb 11y agoShould that be `long double`?
- rdtsc 11y ago128bit floats? Why would those be 128bit bit? I see mention of long double in your edit, but even then wasn't that 80bit on PC architecture. Only Solaris and HP-UX? defined that as 128bit.
- kevinchen 11y agoRan the program with some slight modifications and couldn't reproduce it #include <iostream> #include <sstream> int main(int c, char **v) { std::stringstream s("1.5"); double x; s >> x; return x == 1.5 ? 0 : 1; } Apple LLVM version 7.0.2 (clang-700.1.81) Target: x86_64-apple-darwin15.2.0 Thread model: posix
- jevinskie 11y agoI'd be wary of concluding that "if it works on Apple Clang, it will work on all Clangs". I've seen this to be untrue in multiple cases and the root cause can be found in a multitude of locations. LLVM, Clang, libc (glibc, musl, MSVC, Apple libC,), C++ STL (libstdc++, libc++, MSVC), compiler-rt, platform ABI (Apple ABI's are pretty much SysV, except when they aren't...), and of course the actual version/branch of all of these things. It is certainly a start but unfortunately an over-generalization. :)
- Narishma 11y agoJust tried it with clang 3.6 on Linux and couldn't reproduce it either.
- onedognight 11y agoThe bug is only in x86_64 Clang 3.6 for Android (r10e).
- jevinskie 11y agoWhat is 'long double' on non-X86 (non-PPC?)? On X86, I know it is an 80-bit X87 float. I wonder if the bug you are seeing is a result of the C++ STL and not the compiler itself. Can you try reproing with libc++?
- fixermark 11y agoWhy is that? The linked-to changelog seems to make the process clear. """ We’ve moved our bug tracker to GitHub: https://github.com/android-ndk/ndk/issues https://github.com/android-ndk/ndk/issues """
- chris_wot 11y agoI can't see why that should be the case. If the bug is reproducible, then can't you create a reduced test case that shows the bug?
- GFK_of_xmaspast 11y agoDepends on the bug, it could be that it's only triggered as a result of the compiler getting in a certain state by processing a bunch of code leading up to the problem area.