Don't treat warnings as errors when compiling with GCC 4.6

When compiling with GCC 4.6, don't treat warnings as
errors.

No bots are currently testing 4.6, so it's fairly easy
to regress, and it adds more overhead for new developers
on platforms shipping with GCC 4.6 as default. This is
a temporary solution until GCC 4.6 becomes fully supported.

BUG=80071
TEST=none

[Ryan Sleevi, 2011-06-05 14:13:43]

evan: PTAL. I closed out http://codereview.chromium.org/7056063/ because the
base URL was screwy and would prevent commit-bot from landing.

This warning is triggered quite a bit by ICU (though it's not just ICU at
fault). It's still not fixed in ICU ToT, so I don't think a roll anytime soon
will fix. I wasn't sure whether or not to file an individual bug and/or add
comments to the .gypi.

FWIW, the error (more or less)

third_party/icu/public/common/unicode/unistr.h: In member function
‘icu_46::UnicodeString& icu_46::UnicodeString::replace(int32_t, int32_t,
UChar32)’:
third_party/icu/public/common/unicode/unistr.h:3986:9: error: variable ‘isError’
set but not used [-Werror=unused-but-set-variable]
third_party/icu/public/common/unicode/unistr.h: In member function
‘icu_46::UnicodeString& icu_46::UnicodeString::append(UChar32)’:
third_party/icu/public/common/unicode/unistr.h:4264:9: error: variable ‘isError’
set but not used [-Werror=unused-but-set-variable]
cc1plus: all warnings being treated as errors

[Ryan Sleevi, 2011-06-05 20:00:02]

(follow up from comment on http://codereview.chromium.org/7056063)

Unfortunately, this can't be moved into the icu gyp, as the error is actually in
the ICU public header that gets included by a number of pieces throughout src/,
not just src/third_party.

[Evan Martin, 2011-06-05 20:01:01]

I think you can use direct_dependent_settings for exactly this sort of thing.

On Sun, Jun 5, 2011 at 1:00 PM,  <rsleevi@chromium.org> wrote:
> (follow up from comment on http://codereview.chromium.org/7056063)
>
> Unfortunately, this can't be moved into the icu gyp, as the error is
> actually in
> the ICU public header that gets included by a number of pieces throughout
> src/,
> not just src/third_party.
>
>
> http://codereview.chromium.org/7111026/
>

[Ryan Sleevi, 2011-06-05 21:09:20]

On 2011/06/05 20:01:01, Evan Martin wrote:
> I think you can use direct_dependent_settings for exactly this sort of thing.
> 

Thanks Evan. However, as I mentioned in the original description, while ICU is
the first to trip it, it's not strictly ICU.

Further, it's particularly tickled out by this pattern;

int SomeFunction() {
  int some_var = 0;
  int result = SomeOtherFunction(&some_var);
  ...
#if defined(OS_WIN)
  if (result == kFoo && some_var == kBar) {
    // Do something
  }
#endif
  return result;
}

Note how some_var is set in the Linux code, but only used in the Win32 code. We
could annotate this UNUSED in GCC for such situations.

A more concrete example can be found in:
media/base/yuv_convert.cc: In function ‘void media::ScaleYUVToRGB32(const
uint8*, const uint8*, const uint8*, uint8*, int, int, int, int, int, int, int,
media::YUVType, media::Rotate, media::ScaleFilter)’:
media/base/yuv_convert.cc:224:7: error: variable ‘source_dx_uv’ set but not used
[-Werror=unused-but-set-variable]


An alternative to suppressing this singular warning would be to instruct users
not to run with -Werror on GCC 4.6 (via ~/.gyp/include.gypi ) and fix each
instance separately. WDYT?

[Evan Martin, 2011-06-06 14:53:07]

On Sun, Jun 5, 2011 at 2:09 PM,  <rsleevi@chromium.org> wrote:
> An alternative to suppressing this singular warning would be to instruct
> users
> not to run with -Werror on GCC 4.6 (via ~/.gyp/include.gypi ) and fix each
> instance separately. WDYT?

Yeah, that's what we did for gcc 4.4 initially I think.
http://codesearch.google.com/codesearch?hl=en&vert=chromium&lr=&q=gcc_version...

[Ryan Sleevi, 2011-06-21 04:07:32]

Evan, would you mind taking another look?

After updating my FC15 VM, we've actually regressed/increased the number of
places there are errors. It's also not just ICU.

Given that this particular problem keeps coming up on IRC (I guess people aren't
searching crbug.com ?), I wanted to provide this as a temporary solution.

At some point (very low priority), I plan to go back and begin compiling the
individual list of errors and filing blocker bugs, using 80071 as a meta-bug to
track things down. Without a bot though, I expect this to regress fairly easily,
hence the proposed behaviour to fail-open, until such a time it becomes a
priority (and something tested).

[Evan Martin, 2011-06-24 00:03:32]

I think we don't work under gcc 4.5 either.  Our build instructions tell people
to manually disable werror if they want to use an unsupported compiler:

http://code.google.com/p/chromium/wiki/LinuxBuildInstructions

[Ryan Sleevi, 2011-06-24 00:04:45]

Thanks. I completely missed that. I'm closing out this review then; the current
behaviour/documentation is sufficient enough for me.

[Evan Martin, 2011-06-24 19:08:50]

On 2011/06/24 00:04:45, Ryan Sleevi wrote:
> Thanks. I completely missed that. I'm closing out this review then; the
current
> behaviour/documentation is sufficient enough for me.

It'd be nice if we could detect a non-supported gcc and warn the user, or to
automatically disable -werror or something, but that's a different patch for a
different day.