Problems with --enable-gcc-warnings

Problems with --enable-gcc-warnings

[Eli Zaretskii]

I tried that option in several systems and saw a few problems I
thought I should mention here.

First, it seems like older compilers have trouble with some of the
warning options.  On one system, which has GCC 3.4, I see this:

  cc1.exe: warning: command line option "-Wabi" is valid for C++/ObjC++ but not for C
  cc1.exe: warning: command line option "-Wdeprecated" is valid for C++/Java/ObjC++ but not for C

On another system, which has GCC 4.4 (fencepost.gnu.org), I see this:

  cc1: warning: command line option "-Wenum-compare" is valid for C++/ObjC++ but not for C

If these options are not universally supported, why doesn't configure
make some real test, and avoid using those if they are not supported
for C programs?  Alternatively, if these warnings are not supposed to
be turned on unless GCC is of some relatively new version, why isn't
that being tested?

Then I had a warning in lib/file-has-acl.c, because under some
conditions the acl_access_nontrivial doesn't return a value (look near
its end).

Lastly, the INT_BUFSIZE_BOUND macro seems to be unable to support
'void *' as its argument without emitting warnings, I need to use
intptr_t instead to pacify the compiler.

Thanks.

Re: Problems with --enable-gcc-warnings

[Paul Eggert]

On 12/17/2013 09:57 AM, Eli Zaretskii wrote:
> it seems like older compilers have trouble with some of the
> warning options.

Yes, --enable-gcc-warnings is currently not supported for older GCC
releases.  We've found it's enough of a pain keeping it working for
relatively-recent releases.  Currently I suspect it really needs 4.6
or later; maybe even 4.7.  Since it's a build-time option, we have
been suggesting to simply not use it if your compiler's old.

If you'd like to add support for older GCC releases, please feel free
to hack on gnulib and submit a patch; the relevant files are
m4/manywarnings.m4 and m4/warnings.m4.

> Then I had a warning in lib/file-has-acl.c, because under some
> conditions the acl_access_nontrivial doesn't return a value (look near
> its end).

I tried to fix that in trunk bzr 115573.

> Lastly, the INT_BUFSIZE_BOUND macro seems to be unable to support
> 'void *' as its argument without emitting warnings, I need to use
> intptr_t instead to pacify the compiler.

That's expected; the argument of INT_BUFSIZE_BOUND must be an integer
type or expression.  This info is in the prefatory comment.

It might be nice to have a bound for void * too, for printf %p formats.
It'd have to be a different macro though, I expect.

Re: Problems with --enable-gcc-warnings

[Eli Zaretskii]

> Date: Tue, 17 Dec 2013 12:49:03 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> On 12/17/2013 09:57 AM, Eli Zaretskii wrote:
> > it seems like older compilers have trouble with some of the
> > warning options.
> 
> Yes, --enable-gcc-warnings is currently not supported for older GCC
> releases.  We've found it's enough of a pain keeping it working for
> relatively-recent releases.  Currently I suspect it really needs 4.6
> or later; maybe even 4.7.  Since it's a build-time option, we have
> been suggesting to simply not use it if your compiler's old.

How about some warning for older GCCs, or maybe even refusing to turn
on the compiler warnings in that case?

> > Then I had a warning in lib/file-has-acl.c, because under some
> > conditions the acl_access_nontrivial doesn't return a value (look near
> > its end).
> 
> I tried to fix that in trunk bzr 115573.

Thanks.

> > Lastly, the INT_BUFSIZE_BOUND macro seems to be unable to support
> > 'void *' as its argument without emitting warnings, I need to use
> > intptr_t instead to pacify the compiler.
> 
> That's expected; the argument of INT_BUFSIZE_BOUND must be an integer
> type or expression.  This info is in the prefatory comment.

OK, thanks.

Re: Problems with --enable-gcc-warnings

[Paul Eggert]

Eli Zaretskii wrote:
> How about some warning for older GCCs, or maybe even refusing to turn
> on the compiler warnings in that case?

The 'configure'-time code already does the latter, or tries to --
the code is evidently not working for the older releases
that you mentioned.

Re: Problems with --enable-gcc-warnings

[Eli Zaretskii]

> Date: Tue, 17 Dec 2013 14:20:45 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> > How about some warning for older GCCs, or maybe even refusing to turn
> > on the compiler warnings in that case?
> 
> The 'configure'-time code already does the latter, or tries to --

Can you point to that code, please?

Re: Problems with --enable-gcc-warnings

[Paul Eggert]

Eli Zaretskii wrote:
>> The 'configure'-time code already does the latter, or tries to --
> Can you point to that code, please?

The source is in m4/warnings.m4 and m4/manywarnings.m4.

Re: Problems with --enable-gcc-warnings

[Eli Zaretskii]

> Date: Tue, 17 Dec 2013 20:13:59 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> >> The 'configure'-time code already does the latter, or tries to --
> > Can you point to that code, please?
> 
> The source is in m4/warnings.m4 and m4/manywarnings.m4.

Sorry, I thought there was something else.

The reason these tests don't really do the job is clear from
config.log:

  configure:8072: checking whether C compiler handles -Wenum-compare
  configure:8091: gcc -std=gnu99 -o conftest -O0 -g3  -Wenum-compare -DGLYPH_DEBUG=1  conftest.c  >&5
  cc1: warning: command line option "-Wenum-compare" is valid for C++/ObjC++ but not for C
  configure:8091: $? = 0
  configure:8102: result: yes

IOW, the test expects the compiler to fail, but warnings don't fail
until you add -Werror to the game.

So perhaps the test should use -Werror as well, to ensure such
warnings fail the compilation of test programs.