Re: Uhm... if you have problems with porting from x86 to ARM...
Porting isn't as easy as it sounds, have you ever done it? I guess not...
There are many subtle differences between ARM and x86, for example memory ordering, alignment, floating point accuracy, intrinsics etc etc. While ARM supports unaligned accesses, it doesn't on every load/store (eg. not on load/store multiple), so you can still encounter issues with badly written software which casts a char* to int* or double*. Incompetent programmers who do that should be taken out and shot but on x86 they get away with it. And this is not a C/C++ issue either, I see exactly the same thing in C# and other "high-level" languages despite all the bogus claims of being "type-safe".
Also if you rely on the results of the x87 FPU (which is not anywhere near IEEE compliant) you get different results when you run the code on an actual IEEE compliant FPU. If you use SSE and remember to configure all FP settings (like denormal flushing) identically you will still get different results for math functions.
Then there are source code bugs which happen to compile silently on one compiler but fail when you recompile for a different target. Many years ago I added a check to ensure all stack variables are always accessed within bounds. Reasonable, right? Guess what, it triggered too often when building Windows for ARM so I had to remove the check! And there are target-specific bugs you may have to work around... The list is endless, these are just a few of the issues I've encountered.
So yes, believe whatever you want, but porting millions of lines of code is a huge task, irrespectively of the language. Especially when originally written on x86.