Change Android toolchain to GCC 4.9.

Change Android toolchain to GCC 4.9.

Tune global Android ARM cflags for performance.
Update cflags in gn to keep up with gyp.

BUG=407545
CQ_TRYBOTS=tryserver.chromium.linux:android_aosp,android_clang_dbg,android_dbg

Committed: https://crrev.com/6b767135e631b94cd096c78f6622be28a4af277e
Cr-Commit-Position: refs/heads/master@{#293913}

[Fabrice (no longer in Chrome), 2014-07-28 12:05:51]

This still needs to wait for a DEPS roll for webrtc so the MIPS build doesn't
break, but all other builds work.

[pasko, 2014-07-28 13:14:31]

thanks!!

lgtm with a few tweaks in comments

https://codereview.chromium.org/375483003/diff/120001/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/375483003/diff/120001/build/common.gypi#newco...
build/common.gypi:3718: # TODO(fdegans) Reevaluate when we upgrade GCC.
nit:

I think there is no need to have a TODO for reevaluating anymore. Of course, we
will be re-evaluating, but the current state of things is not causing any
obvious difficulties any more.

If you still want to remain the TODO, please put a colon after the closing
paren.

https://codereview.chromium.org/375483003/diff/120001/build/config/compiler/B...
File build/config/compiler/BUILD.gn (right):

https://codereview.chromium.org/375483003/diff/120001/build/config/compiler/B...
build/config/compiler/BUILD.gn:160: # TODO(fdegans) Reevaluate when we upgrade
GCC.
Repeating yourself is boring. Let's have only one instance of these comments in
the most relevant place. It's relatively easy to find the reasons in the
codebase with git grep, and comments will be there.

https://codereview.chromium.org/375483003/diff/120001/build/config/gcc/gcc_ve...
File build/config/gcc/gcc_version.gni (left):

https://codereview.chromium.org/375483003/diff/120001/build/config/gcc/gcc_ve...
build/config/gcc/gcc_version.gni:6: gcc_version = 48
does it mean this is currently wrong for aarch64? does this have the same effect
as gcc_version% in common.gypi?

[Fabrice (no longer in Chrome), 2014-07-28 13:40:44]

Thanks for the fast review!
Replies in comments.

https://codereview.chromium.org/375483003/diff/120001/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/375483003/diff/120001/build/common.gypi#newco...
build/common.gypi:3718: # TODO(fdegans) Reevaluate when we upgrade GCC.
On 2014/07/28 13:14:30, pasko wrote:
> nit:
> 
> I think there is no need to have a TODO for reevaluating anymore. Of course,
we
> will be re-evaluating, but the current state of things is not causing any
> obvious difficulties any more.
> 
> If you still want to remain the TODO, please put a colon after the closing
> paren.

Done.

https://codereview.chromium.org/375483003/diff/120001/build/config/compiler/B...
File build/config/compiler/BUILD.gn (right):

https://codereview.chromium.org/375483003/diff/120001/build/config/compiler/B...
build/config/compiler/BUILD.gn:160: # TODO(fdegans) Reevaluate when we upgrade
GCC.
On 2014/07/28 13:14:30, pasko wrote:
> Repeating yourself is boring. Let's have only one instance of these comments
in
> the most relevant place. It's relatively easy to find the reasons in the
> codebase with git grep, and comments will be there.
I removed the TODO (as per previous comment).
AFAIK, the long-term plan is to switch to gn and remove gyp. And some people do
not check the gn equivalent when doing toolchain changes(they should, but that's
another debate). So the comments will need to appear in both places for the time
being.

https://codereview.chromium.org/375483003/diff/120001/build/config/gcc/gcc_ve...
File build/config/gcc/gcc_version.gni (left):

https://codereview.chromium.org/375483003/diff/120001/build/config/gcc/gcc_ve...
build/config/gcc/gcc_version.gni:6: gcc_version = 48
On 2014/07/28 13:14:30, pasko wrote:
> does it mean this is currently wrong for aarch64? does this have the same
effect
> as gcc_version% in common.gypi?
Currently, it's wrong in gyp too. Though I haven't encountered a breaking change
with GCC 4.9 so it's not that bad.

[brettw, 2014-07-28 17:56:14]

GN LGTM

https://codereview.chromium.org/375483003/diff/120001/build/config/compiler/B...
File build/config/compiler/BUILD.gn (right):

https://codereview.chromium.org/375483003/diff/120001/build/config/compiler/B...
build/config/compiler/BUILD.gn:160: # TODO(fdegans) Reevaluate when we upgrade
GCC.
Yes, please duplicate the comment.

[pasko, 2014-07-28 18:22:27]

https://codereview.chromium.org/375483003/diff/120001/build/config/compiler/B...
File build/config/compiler/BUILD.gn (right):

https://codereview.chromium.org/375483003/diff/120001/build/config/compiler/B...
build/config/compiler/BUILD.gn:160: # TODO(fdegans) Reevaluate when we upgrade
GCC.
On 2014/07/28 13:40:43, Fabrice de Gans wrote:
> On 2014/07/28 13:14:30, pasko wrote:
> > Repeating yourself is boring. Let's have only one instance of these comments
> in
> > the most relevant place. It's relatively easy to find the reasons in the
> > codebase with git grep, and comments will be there.
> I removed the TODO (as per previous comment).
> AFAIK, the long-term plan is to switch to gn and remove gyp. And some people
do
> not check the gn equivalent when doing toolchain changes(they should, but
that's
> another debate). So the comments will need to appear in both places for the
time
> being.

I was wrong: I thought this section is only about clang, and GCC is elsewhere.
You are right, we should have the same comments in GN.

[brettw, 2014-07-28 20:58:43]

lgtm

[Fabrice (no longer in Chrome), 2014-08-01 12:38:20]

The CQ bit was checked by fdegans@chromium.org

[commit-bot: I haz the power, 2014-08-01 12:39:26]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/fdegans@chromium.org/375483003/140001

[commit-bot: I haz the power, 2014-08-01 18:03:53]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  android_dbg_triggered_tests on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_dbg_tri...)
  win_chromium_rel on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel/...)

[commit-bot: I haz the power, 2014-08-01 19:28:34]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-08-01 19:28:35]

Try jobs failed on following builders:
  android_dbg_triggered_tests on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_dbg_tri...)

[Torne, 2014-08-29 11:21:18]

torne@chromium.org changed reviewers:
+ torne@chromium.org

[Torne, 2014-08-29 11:21:18]

Not LGTM.

You need to move the gcc_version into the android_webview_build conditional.
Android WebView is still using GCC 4.8.

[Fabrice (no longer in Chrome), 2014-08-29 12:11:03]

On 2014/08/29 11:21:18, Torne wrote:
> Not LGTM.
> 
> You need to move the gcc_version into the android_webview_build conditional.
> Android WebView is still using GCC 4.8.

Done, looks like the gcc_version was never set properly for webview in the first
place.
I reorganized the whole section so it's easier to read.

[Torne, 2014-08-29 12:13:10]

On 2014/08/29 12:11:03, Fabrice de Gans wrote:
> On 2014/08/29 11:21:18, Torne wrote:
> > Not LGTM.
> > 
> > You need to move the gcc_version into the android_webview_build conditional.
> > Android WebView is still using GCC 4.8.
> 
> Done, looks like the gcc_version was never set properly for webview in the
first
> place.

No, it was set correctly, the conditionals are just confusing.

> I reorganized the whole section so it's easier to read.

Thank you, it's much better now :) LGTM.

[Fabrice (no longer in Chrome), 2014-09-09 08:41:42]

The CQ bit was checked by fdegans@chromium.org

[commit-bot: I haz the power, 2014-09-09 08:42:15]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/fdegans@chromium.org/375483003/240001

[commit-bot: I haz the power, 2014-09-09 10:10:32]

Committed patchset #13 (id:240001) as 4eec08199cd9f4a3dc6aeee48843c5bbd126a554

[Torne, 2014-09-09 11:58:14]

https://codereview.chromium.org/375483003/diff/240001/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/375483003/diff/240001/build/common.gypi#newco...
build/common.gypi:3835: # size and performance in gcc 4.9.
Removing all these -fno-* flags appears to have broken building the WebView
downstream - it hits an internal compiler assert when compiling opus and
crashes.

Also, if the reason those flags were there was to improve binary size in gcc
4.8, then removing them completely when the webview is still using gcc 4.8 seems
like a bad plan.

I suspect these flags should be still here, but guarded a by gcc_version test?

[Torne, 2014-09-09 14:27:26]

On 2014/09/09 11:58:14, Torne wrote:
> https://codereview.chromium.org/375483003/diff/240001/build/common.gypi
> File build/common.gypi (right):
> 
>
https://codereview.chromium.org/375483003/diff/240001/build/common.gypi#newco...
> build/common.gypi:3835: # size and performance in gcc 4.9.
> Removing all these -fno-* flags appears to have broken building the WebView
> downstream - it hits an internal compiler assert when compiling opus and
> crashes.
> 
> Also, if the reason those flags were there was to improve binary size in gcc
> 4.8, then removing them completely when the webview is still using gcc 4.8
seems
> like a bad plan.
> 
> I suspect these flags should be still here, but guarded a by gcc_version test?

The specific thing that breaks WebView is removing -fno-tree-loop-optimize.
Without that flag, the compiler dies on third_party/opus/src/celt/rate.c with:

external/chromium_org/third_party/opus/src/celt/rate.c: In function
'compute_allocation':
external/chromium_org/third_party/opus/src/celt/rate.c:637:1: error:
unrecognizable insn:
 }
 ^
(insn 1384 1383 1385 157 (set (reg:V4SI 1023)
        (unspec:V4SI [
                (const_vector:V4SI [
                        (const_int 0 [0])
                        (const_int 0 [0])
                        (const_int 0 [0])
                        (const_int 0 [0])
                    ])
                (reg:V4SI 1019 [ vect_var_.79 ])
                (const_int 1 [0x1])
            ] UNSPEC_VCGE))
external/chromium_org/third_party/opus/src/celt/rate.c:520 -1
     (nil))
external/chromium_org/third_party/opus/src/celt/rate.c:637:1: internal compiler
error: in extract_insn, at recog.c:2150
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://source.android.com/source/report-bugs.html> for instructions.

I'll file an internal bug against the android toolchain team.

[commit-bot: I haz the power, 2014-09-10 03:52:33]

Patchset 13 (id:??) landed as
https://crrev.com/6b767135e631b94cd096c78f6622be28a4af277e
Cr-Commit-Position: refs/heads/master@{#293913}