At some point, we're going to have to support a newer version of GCC, no? It seems like tackling these errors as they creep up is more manageable than trying to sometime later switch to supporting a more recent release of GCC and then realizing that we've got 50,000 errors to work through... my $0.02
On Thu, Feb 19, 2009 at 9:14 AM, Darin Fisher <[email protected]> wrote: > It is sometimes worth it to reduce the supported toolchain to help reduce > distractions. If these warnings are beneficial, then a bot is probably a > good idea. However, a red bot is bad... so we'd probably have to commit > ourselves to fixing any bustage. I'm not sure what's better... how > beneficial are the warnings? > -Darin > > > On Thu, Feb 19, 2009 at 8:42 AM, Evan Martin <[email protected]> wrote: > >> >> We have a steady trickle of reports from people who run into problems >> building on gcc 4.3. [1] >> The problem is that our buildbots use gcc 4.2 and the compilers have >> slightly different warning sensitivities. [2] >> See, for example, http://code.google.com/p/chromium/issues/detail?id=7742. >> >> Options: >> 1) Provide some sort of way for people to turn off -Werror (which >> makes warnings into errors). Maybe make it dependent on your compiler >> version. I don't like this much, but it's an option. >> 2) Just fix these problems as people report them. >> 3) A gcc 4.3 buildbot. >> >> I'd say the last is best, but it means that people will occasionally >> break that buildbot and need to look at its error output and make >> educated guesses to fix it. On the other hand, it will occassionally >> pick up real problems with our code. What do y'all think? >> >> >> [1] For reference, here are some log entries that mention gcc 4.3: >> $ git log --grep="4\.3" | grep "4\.3" >> Fix gcc 4.3 build break. >> Fix compiler warning with GCC 4.3. Patch by Craig Schlenter (see >> http://codereview.chromium.org/20075 ), r=me. >> Fix warning which breaks compile with gcc 4.3.x >> g++ 4.3.x doesn't seem to like forward declarations >> This fixes a compile error with gcc4.3 (hash_fun.h was moved from ext/ >> I tested locally with gcc 4.3, but gcc 4.2 behaves differently and >> fails. >> Fix Linux build failure caused by GCC 4.3/4.2 differences. >> Linux: GCC 4.3 warning fixes >> The lastest Skia drop included some code which triggers warnings >> with GCC 4.3 >> and fixed a useful gcc-4.3 warning re operator precedence. >> GCC 4.3 fixes >> Add suggested parentheses to fix build with GCC 4.3 >> Fixed build issues on gcc-4.3.1. >> GCC 4.3 build fixes. >> >> [2] For reference, here are three recent problems gcc 4.3 picked up: >> 1) int width, height; SomeFunction(&width, &height); >> warning was: variables may be used uninitialized >> fix: initialize width, height to zero >> 2) SomeFunction(foo, bar, mystring); >> warning was: format string expected >> fix (conceptually, at least): SomeFunction(foo, bar, "%s", mystring); >> 3) src/webkit/tools/npapi_layout_test_plugin/PluginObject.cpp:560: >> error: ignoring >> return value of 'size_t fwrite(const void*, size_t, size_t, FILE*)', >> declared with >> attribute warn_unused_result >> fix: we should look at the result of fwrite to make sure it succeeds. >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
