Pass -Wno-unused-funciton, -Wno-sign-compare in non-clang gn builds.

Pass -Wno-unused-funciton, -Wno-sign-compare in non-clang gn builds.

This undoes a behavior change from https://codereview.chromium.org/1301483002
that the webrtc bots apparently rely on.  This makes the .gn file different
from the gyp file.

BUG=none
R=johannkoenig@google.com

Committed: https://chromium.googlesource.com/chromium/deps/libvpx/+/91fac05a4051b2883883b567102cb044df2bd9be

[Nico, 2015-08-25 19:48:18]

thakis@chromium.org changed reviewers:
+ johannkoenig@google.com

[Johann, 2015-08-25 20:02:19]

johannkoenig@google.com changed reviewers:
+ marpan@chromium.org

[Johann, 2015-08-25 20:02:19]

LGTM but wait for Marco

The WebRTC failure is strange because that function is *not* unused. The file
that references it is not even in the file list being built. Maybe it's in a
different component. But it's still a strange failure and I don't know what's
up.

Marco: can you make an infrastructure bug to investigate the issue so there can
be a bug # / todo to go in the file?

[Nico, 2015-08-25 20:06:57]

On 2015/08/25 20:02:19, Johann wrote:
> LGTM but wait for Marco
> 
> The WebRTC failure is strange because that function is *not* unused. The file
> that references it is not even in the file list being built. Maybe it's in a
> different component. But it's still a strange failure and I don't know what's
> up.
> 
> Marco: can you make an infrastructure bug to investigate the issue so there
can
> be a bug # / todo to go in the file?

It's a static function in a .h file, and it's probably not used in every
translation unit including that header. (That's one of the reasons why functions
defined in header files should be marked inline, not static: Else every
translation unit using the function gets its own copy of the function. Sadly,
MSVC only supports inline in c++ files. So if you have a C library instead of a
C++ library, you need to defined INLINE to inline with gcc and to __inline with
MSVC – that works in .c files too – and then mark your functions INLINE. So it's
a tiny bit more work than using static, which is why I guess vpx is using
static, not inline. But the Right Fix is to mark your inline functions as
inline, and then you don't need this flag any more.)

[Nico, 2015-08-25 20:12:43]

Committed patchset #1 (id:1) manually as
91fac05a4051b2883883b567102cb044df2bd9be (presubmit successful).

[Johann, 2015-08-25 20:41:48]

On 2015/08/25 20:06:57, Nico wrote:
> On 2015/08/25 20:02:19, Johann wrote:
> > LGTM but wait for Marco
> > 
> > The WebRTC failure is strange because that function is *not* unused. The
file
> > that references it is not even in the file list being built. Maybe it's in a
> > different component. But it's still a strange failure and I don't know
what's
> > up.
> > 
> > Marco: can you make an infrastructure bug to investigate the issue so there
> can
> > be a bug # / todo to go in the file?
> 
> It's a static function in a .h file, and it's probably not used in every
> translation unit including that header. (That's one of the reasons why
functions
> defined in header files should be marked inline, not static: Else every
> translation unit using the function gets its own copy of the function. Sadly,
> MSVC only supports inline in c++ files. So if you have a C library instead of
a
> C++ library, you need to defined INLINE to inline with gcc and to __inline
with
> MSVC – that works in .c files too – and then mark your functions
INLINE. So it's
> a tiny bit more work than using static, which is why I guess vpx is using
> static, not inline. But the Right Fix is to mark your inline functions as
> inline, and then you don't need this flag any more.)

Ahh, thanks for the explanation. This should be a fairly straightforward fix
then. We already have the INLINE macro because we do plenty of that. I'm still
curious why it only turned up for the WebRTC builds, but not that curious.

[Nico, 2015-08-25 20:43:48]

On 2015/08/25 20:41:48, Johann wrote:
> On 2015/08/25 20:06:57, Nico wrote:
> > On 2015/08/25 20:02:19, Johann wrote:
> > > LGTM but wait for Marco
> > > 
> > > The WebRTC failure is strange because that function is *not* unused. The
> file
> > > that references it is not even in the file list being built. Maybe it's in
a
> > > different component. But it's still a strange failure and I don't know
> what's
> > > up.
> > > 
> > > Marco: can you make an infrastructure bug to investigate the issue so
there
> > can
> > > be a bug # / todo to go in the file?
> > 
> > It's a static function in a .h file, and it's probably not used in every
> > translation unit including that header. (That's one of the reasons why
> functions
> > defined in header files should be marked inline, not static: Else every
> > translation unit using the function gets its own copy of the function.
Sadly,
> > MSVC only supports inline in c++ files. So if you have a C library instead
of
> a
> > C++ library, you need to defined INLINE to inline with gcc and to __inline
> with
> > MSVC – that works in .c files too – and then mark your functions
> INLINE. So it's
> > a tiny bit more work than using static, which is why I guess vpx is using
> > static, not inline. But the Right Fix is to mark your inline functions as
> > inline, and then you don't need this flag any more.)
> 
> Ahh, thanks for the explanation. This should be a fairly straightforward fix
> then. We already have the INLINE macro because we do plenty of that. I'm still
> curious why it only turned up for the WebRTC builds, but not that curious.

I think it's because in Chromium, we don't build webrtc on android, and
everywhere else we use clang. And for clang, the flag that disabled this warning
already got passed.