Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why did you deprecate GCC? #26

Closed
bog-dan-ro opened this issue Mar 17, 2016 · 26 comments
Closed

Why did you deprecate GCC? #26

bog-dan-ro opened this issue Mar 17, 2016 · 26 comments

Comments

@bog-dan-ro
Copy link

@bog-dan-ro bog-dan-ro commented Mar 17, 2016

Is it something wrong with GCC 5.x or upcoming 6 on Android that made you to take this decision?
I think is not a good idea to ditch gcc as long as clang still have some issues e.g. #9, #21.
IMHO having both will not hurt anyone.

@DoDoENT
Copy link

@DoDoENT DoDoENT commented Mar 17, 2016

I can give you my opinions: Clang is faster while compiling source code; has better support for c++14/c++17 and since it is designed primarily as library, it can be used from IDEs like Android Studio to perform static code analysis, refactoring and code completion.

Besides that, Clang is under more permissive open source licence, unlike GCC, which is under GPL. Thus, it is easier to make commercial clang clones which give better support for certain CPU architectures. Also, clang works better with libc++ than GCC, and many native code developers tend to use libc++ because, when compared to GNU stdc++, it has better support for c++14/c++17 STL features and is under permissive BSD-like licence - this makes it possible to use c++14/c++17 features in commercial android apps, like games. GNU stdc++ is under LGPLv3, which makes it impossible to use in commercial apps (yes, stdc++ has special exception for LGPL which allows usage in commercial apps, provided that you do not modify it - but this makes commercial app development very uncomfortable).

I believe that issues like #21 and #9 will be solved soon.

@bog-dan-ro
Copy link
Author

@bog-dan-ro bog-dan-ro commented Mar 17, 2016

You mean that latest clang has better support than gcc 4.9, right? Because AFAIK gcc 5.x has full C++14 support.

Regarding the licenses IMHO you get it wrong. Personally I prefer GPL because it doesn't allow closed source clones, IMHO is fair to give something when you take so much.
GNU libstdc++ is GPL (NOT LGPL) but the special exception that you've mentioned allows everyone to freely use it and also to CHANGE IT as long as the changes made to libstdc++ are made public under GPL. IMHO it is quite stupid to keep these changes for yourself and not to upstream them, because you'll need to maintain them which is not for free.

Least but not last, let's not forget that Google switched to OpenJDK, which is GPL, therefore IMHO the licensing issue doesn't stand.

So, GCC was good to build Android for 10 years and now, suddenly is not, and google must ditch it.

@DoDoENT
Copy link

@DoDoENT DoDoENT commented Mar 17, 2016

I just gave my opinions - let the NDK guys give theirs. I think the tooling support in clang is probably the main reason for switching to it.

@DanAlbert
Copy link
Member

@DanAlbert DanAlbert commented Mar 17, 2016

Licensing actually did not play a significant part in the decision. The other reasons that @DoDoENT mentioned are correct though (yes, GCC 5.x supports C++14, but new features definitely do happen more quickly in clang). The biggest reasons for why we made this decision actually haven't been mentioned though:

So, GCC was good to build Android for 10 years and now, suddenly is not, and google must ditch it.

Things change. GCC isn't good for Android any more because GCC doesn't provide the same security features that Clang does (and when it does, it provides them much later).

An incomplete list of why the platform switched to clang:

  • We make extensive use of integer overflow sanitizers in shipping code to prevent issues like stagefright from recurring
  • Address sanitizer and libfuzzer are used widely in testing
  • Clang's better diagnostics catch a ton of bugs that GCC does not
  • Control flow integrity and safe stacks are being deployed (are deployed?) for even more exploit mitigation.

The fact is that we have significant reason to invest in clang, and splitting effort across maintaining two compilers makes both of them worse.

As it stands now, both compilers are fairly comparable in terms of performance and code size. #21 points at code size increases for armeabi-v7a. That is not always the case, and for every other architecture we actually see smaller code. From some analysis I did when we made this decision for the platform:

It seems our 32-bit ARM devices are typically 1MB larger (out of 600MB-900MB total), whereas volantis is slightly smaller, and fugu is 15MB smaller. Strangely, sprout_b is also slightly smaller.

I think the ARM32 numbers are small enough to not bother anyone, especially given that it looks like it will be a win for the new devices since they're aarch64.

All the comparisons we did showed that Clang and GCC were pretty much equivalent quality when it came to the code they produced. Yes, sometimes we find cases where GCC is faster, but we also find cases where Clang is faster. As an example, we saw a 20% performance improvement in the ART interpreter when we switched to clang.

@DanAlbert DanAlbert closed this Mar 17, 2016
@DanAlbert
Copy link
Member

@DanAlbert DanAlbert commented Mar 17, 2016

@stephenhines might want to add more to this, but I think I covered most of the bases.

@jcelerier
Copy link

@jcelerier jcelerier commented Dec 15, 2016

Regarding

new features definitely do happen more quickly in clang

As of today, that is not true : GCC has better C++17 compiler support than clang...

http://en.cppreference.com/w/cpp/compiler_support

@DoDoENT
Copy link

@DoDoENT DoDoENT commented Dec 15, 2016

Even more, GCC 6.2 has now faster compile times than clang, while still producing more optimised binary. Here are benchmarks from Phoronix (see page 3).

@stephenhines
Copy link
Collaborator

@stephenhines stephenhines commented Dec 15, 2016

Thanks for the updates on GCC. We still have no plans to continue maintaining it, but I am glad that others in the community are still working on it.

@DanAlbert
Copy link
Member

@DanAlbert DanAlbert commented Dec 15, 2016

As of today, that is not true : GCC has better C++17 compiler support than clang...

http://en.cppreference.com/w/cpp/compiler_support

The majority of those features are not in any released version of GCC. Clang hasn't finished it's release cycle either. You have more C++17 with our current Clang than you would with a current GCC, and odds are Clang will close the current gap before 4.0 is done.

Keep in mind my comment above. We have many other reasons to choose Clang, and do not have the resources to pursue both.

@bog-dan-ro
Copy link
Author

@bog-dan-ro bog-dan-ro commented Jan 6, 2017

@DanAlbert @stephenhines : I understand that you don't have resources to maintain it (which sounds like a joke to me ... who could imagine that google can't afford to pay a gcc hacker to maintain it), but why don't you accept community contributions?

@jcelerier @DoDoENT My feeling is that the whole story is not about which compiler is better for google customers, instead is about control and what is better for Google. Google is one of the most GPL haters out there (or at least this is how it looks like), and an BDS like license is more "suitable" for them... Why? Well because the BSD licence allows the Google to choose what (or if) they share back with the community. Again, this is my personal feeling...

@guruz
Copy link

@guruz guruz commented Nov 15, 2017

BTW, it's in Qt the Qt-for-Android Known Issues :-(
https://wiki.qt.io/Qt_for_Android_known_issues

There is a bug in GCC in the latest Android NDK, making it impossible to use it for building Qt. The bug has not been fixed yet, and it's recommended to use Android NDK r10e. NDK r15 produces applications that fail with the error message 'This application failed to start because it could not find or load the Qt platform plugin "android"'. See also the bug report.

@DanAlbert
Copy link
Member

@DanAlbert DanAlbert commented Nov 15, 2017

The bug referred to (#67) is a GCC bug. Use Clang and you won't have a problem.

@ehem
Copy link

@ehem ehem commented Dec 28, 2017

Until standard Linux kernels can be built without extra patches, keeping a working GCC around is pretty valuable. Looks like Google is aggressively pushing Qualcomm off of 3.18, but until every device is off 3.18 it needs to stay.

Really awful reason, but it is an issue.

@stephenhines
Copy link
Collaborator

@stephenhines stephenhines commented Dec 28, 2017

It's not an issue if none of our devices are using GCC for their kernels. Again, feel free to use whichever compiler you like, but we are no longer actively supporting GCC (just like I mentioned last year). https://youtu.be/6l4DtR5exwo if you want to see our talk about getting the kernel and the rest of Android over to Clang.

@jcelerier
Copy link

@jcelerier jcelerier commented Dec 28, 2017

@stephenhines : we aren't free to use "whatever compiler we like" : the choice is between an old GCC and a new Clang. If at least there was a procedure somewhere to build a more recent GCC that works with the android ndk it would be fine.

Besides, as of today, up-to-date GCC still mostly runs circles around Clang in terms of produced code performance: https://www.phoronix.com/scan.php?page=article&item=gcc-clang-eoy2017&num=4

This has a direct effect on the battery consumption of the software.

@DanAlbert
Copy link
Member

@DanAlbert DanAlbert commented Jan 2, 2018

Until standard Linux kernels can be built without extra patches, keeping a working GCC around is pretty valuable.

The NDK compilers are not guaranteed to work for the kernel at all. The kernel compilers come from the prebuilts/gcc/... or prebuilts/clang/... project of the given kernel manifest project.

@DanAlbert
Copy link
Member

@DanAlbert DanAlbert commented Jan 2, 2018

If at least there was a procedure somewhere to build a more recent GCC that works with the android ndk it would be fine.

https://android.googlesource.com/toolchain/gcc/+/master/README.md

@android android deleted a comment from Raulvo Feb 3, 2018
@ghost
Copy link

@ghost ghost commented Mar 26, 2018

The answer to #26 is use Clang. Not GCC.
In case anyone was wondering.
And using Clang on Windows 10 has zero tutorials.
There is one on the official website for Clang, its like a PCI-e 1.0 port for a PCI-e 4.0 device.

@DanAlbert
Copy link
Member

@DanAlbert DanAlbert commented Mar 26, 2018

Using Clang on Windows is the same as using Clang on Linux or Darwin when it comes to the NDK. The NDK compilers are not intended to compile for Windows.

@vczh
Copy link

@vczh vczh commented May 1, 2018

@DanAlbert It should, big companies are using it this way.

@ytrezq
Copy link

@ytrezq ytrezq commented Apr 5, 2020

Thanks for the updates on GCC. We still have no plans to continue maintaining it, but I am glad that others in the community are still working on it.

This is problematic as the Android’s kernel still requires gcc.

@jmgao
Copy link
Contributor

@jmgao jmgao commented Apr 5, 2020

This is problematic as the Android’s kernel still requires gcc.

Pixels have been shipping with clang-built kernels for ~3 years now.

@ytrezq
Copy link

@ytrezq ytrezq commented Apr 5, 2020

@jmgao but Samsung kernels and other manufacturers still require gcc 4.9 and in fact their official binaries use gcc 4.9.

Pixels have been shipping with clang-built kernels for ~3 years now.

(also as someone who tend to favor performance, I’m not kind to run the kernel code as bytecode under a small jit compiler). And gcc doesn’t care about preserving the overall form of the original code (debugging vs performance of course).

But does the android kernel even requires an android compiler?

@DanAlbert
Copy link
Member

@DanAlbert DanAlbert commented Apr 5, 2020

That's not how LLVM works. The bytecode is just an IR. It compiles down to machine code just like GCC does. Sometimes it performs better, sometimes it performs worse.

@stephenhines
Copy link
Collaborator

@stephenhines stephenhines commented Apr 5, 2020

It's actually part of the Android CDD that new devices ship with Clang-built kernels to ensure all relevant security features (CFI and more going forward) are enabled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
11 participants
You can’t perform that action at this time.