Re: gl_MANYWARN_ALL_GCC() leads to many spurious warnings

[Paul Eggert]

On 07/06/2012 03:38 PM, Samuel Bronson wrote:

> why does it use flags like -Wunreachable-code (which was so buggy
> that it eventually got yanked -- it's now silently ignored)

The big picture is that --enable-gcc-warnings hasn't been
ironed out --with-ns.  This can be fixed, and I expect it
will find a few real bugs along with many things that are
just nit cleanups, but it'll take some work.  Is this
something you'd like to help out with?  It could be combined
with the idea of maintaining another configure-time option
useful for finding bugs on Apple.

I started on this task, checking in the results in trunk bzr
108941, but there's lots more where that came from and to be
honest I don't understand the --with-ns code that well.  I
did see some unused-macro warnings but they seemed correct
to me -- perhaps I am missing something?  Anyway, you can
look at the diffs in 108941 to see how to go about this,
and/or to let me know what I did wrong.

Anyway, to get back to your question, I suspect
-Wunreachable-code was there because it is harmless with the
latest GCC, so nobody bothered to remove it.  Since this
flag doesn't ever help I removed it in trunk bzr 108941.

> and -Wsync-nand (which is totally irrelevant, and warns that this
> warning isn't allowed for Objective C code)

Same thing -- this flag never bothered anybody in the
--without-ns world.  Since it never helps either, I removed
it too.

> and -Wunused-macros (which seems rather buggy in GCC 4.7.1 -- it
> doesn't seem to count appearing in an #ifdef as a use?).

I don't observe a bug here.  The following program compiles
just fine with GCC 4.7.1, with -Wunused-macros.  (This is on
Fedora 15 x86-64.)

  #define FOO bar
  #ifdef FOO
  int main (void) { return 0; }
  #endif

What bug do you see?