New cross target: i686-linux-android

[overminder]

• All the libstd tests are passing in the optimized build against
  a Zenfone2 and the x86 Android emulator.

I haven't tested the other libraries though.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[hanna-kruppe]

If I read this correctly, this target won't use SSE and SSE2 instructions, instead restricting itself to x87. Correct?

That would be inconsistent with all other i686 targets (in tree, at least), leave performance on the table, and cause many floating point operations to occasionally be slightly inaccurate (i.e., have more rounding error than necessary), from basic arithmetic to the parsing of decimal strings. Assuming x86 Android phones don't use ancient hardware like Pentium < 4 or Athlon XP, there is no harm in using a baseline microarchitecture that has SSE and SSE2, such as Pentium 4. See the other i686 targets in librustc_back/target.

[overminder]

Thanks for the pointers! I didn't know that :P
I will set its CPU to 'pentium4' and test libstd again.

[alexcrichton]

@bors: r+ 6887d8c

Thanks!

[bors]

⌛ Testing commit 6887d8c with merge 19aadd5...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt

[overminder]

Thanks.

By the way, one of the most time-consuming work during the porting was to ensure that the FFI types defined in Rust (e.g., libc::stat) are exactly the same as defined in the target's C headers. I eventually just made a build script to generate C functions to return the sizeofs and offsets of some of the fields and structs, and compare them with the Rust ones. Do we have a more automatic way to do that?

Another thing that I didn't quite understand was that there were two stat definitions in Rust, one in liblibc and the other in libstd (std::os::unix::raw). That also caused me some troubles.. Could someone explain why it's the case?