Re: another manywarnings failure
Eric Blake wrote: I compiled on FreeBSD 8.2 (gcc 4.2.1), and when I updated to the latest gnulib, I started to see the following in config.log when running ./configure CFLAGS=-g: configure:53920: checking whether C compiler handles -Wuninitialized configure:53939: gcc -std=gnu99 -c -g -Wuninitialized -D_THREAD_SAFE -D_THREAD_SAFE conftest.c 5 cc1: warning: -Wuninitialized is not supported without -O configure:53939: $? = 0 configure:53949: result: yes But when later coupled with -Werror, this makes compilation fail noisily. I think this may have been inadvertently introduced by commit dd44da55 when we updated the list of all warnings (at least, that was the only commit in my recent gnulib update that seems to have touched manywarnings). Any quick ideas how to avoid this warning in the cases where it will have no effect other than to cause a warning that trips up -Werror? When checking for warnings, should we also check that each warning pairs with -Werror with no further problem? IME, this is nothing new. I've had to do this for over a year with coreutils. It's an artifact of configuring with one set of CFLAGS and later compiling with another. When you configure with one set of warning options and later build with another, as with your make CFLAGS=-g, you're short-circuiting the build tests. When I do that, I simply turn off -Werror and ignore the warnings: make CFLAGS=-g WERROR_CFLAGS= Of course, you could simply rerun configure with CFLAGS=-g, and it would test each -W option individually... Then you'd get a warning-free run with -Werror *and* -g. It's just that that takes longer than most of us are willing to wait for a simple recompilation.
Re: another manywarnings failure
On 09/06/2012 12:07 AM, Jim Meyering wrote: Eric Blake wrote: I compiled on FreeBSD 8.2 (gcc 4.2.1), and when I updated to the latest gnulib, I started to see the following in config.log when running ./configure CFLAGS=-g: When you configure with one set of warning options and later build with another, as with your make CFLAGS=-g, you're short-circuiting the build tests. When I do that, I simply turn off -Werror and ignore the warnings: make CFLAGS=-g WERROR_CFLAGS= But note that I did: ./configure CFLAGS=-g at the outset. Yes, I'm aware that _if_ you override CFLAGS at make time, you may have to also disable warnings at that time as well. But here, I'm talking about the case where I configured optimization to be off without needing to override CFLAGS at make time; that is, in a situation where we CAN run a configure test to see whether the warning will even be effective. Of course, you could simply rerun configure with CFLAGS=-g, Which is what I did... and it would test each -W option individually... except that each -W option individually succeeds. -Wuninitialized only warns, not errors out, on this particular gcc 4.2.1 build. You _have_ to test the combination of '-Wuninitialized -Werror' but no -O, in order to hit the failure. But I'm not sure how best to modify manywarnings.m4 to do that testing. Then again, we've already special-cased -Wno-missing-field-initializer to work around gcc infelicities, so I guess I could enhance the module by adding another test along those lines. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: another manywarnings failure
Eric Blake wrote: On 09/06/2012 12:07 AM, Jim Meyering wrote: Eric Blake wrote: I compiled on FreeBSD 8.2 (gcc 4.2.1), and when I updated to the latest gnulib, I started to see the following in config.log when running ./configure CFLAGS=-g: When you configure with one set of warning options and later build with another, as with your make CFLAGS=-g, you're short-circuiting the build tests. When I do that, I simply turn off -Werror and ignore the warnings: make CFLAGS=-g WERROR_CFLAGS= But note that I did: ./configure CFLAGS=-g Ah... I didn't read carefully enough. at the outset. Yes, I'm aware that _if_ you override CFLAGS at make time, you may have to also disable warnings at that time as well. But here, I'm talking about the case where I configured optimization to be off without needing to override CFLAGS at make time; that is, in a situation where we CAN run a configure test to see whether the warning will even be effective. Of course, you could simply rerun configure with CFLAGS=-g, Which is what I did... and it would test each -W option individually... except that each -W option individually succeeds. -Wuninitialized only warns, not errors out, on this particular gcc 4.2.1 build. You _have_ to test the combination of '-Wuninitialized -Werror' but no -O, in order to hit the failure. But I'm not sure how best to modify manywarnings.m4 to do that testing. Then again, we've already special-cased -Wno-missing-field-initializer to work around gcc infelicities, so I guess I could enhance the module by adding another test along those lines. Yes, it looks like if we're using both of those, we'll have to add code to reject -Wuninitialized (maybe with a warning?) when configuring without -O. Actually, with GNU make, this is something that we could probably adjust at make-time. And since we're typically enabling warnings only when we have reasonable development tools, that might be even better (simpler). E.g., [here's simple PoC, i.e., it doesn't know about -O0, but you get the idea ] W = -Wuninitialized -Werror CFLAGS = -O ifneq (,$(findstring -Wuninitialized,$(W))) ifneq (,$(findstring -Werror,$(W))) ifneq (,$(findstring -O,$(CFLAGS))) W := $(subst -Wuninitialized,,$(W)) endif endif endif all: @echo $(W)
Re: another manywarnings failure
On 09/06/2012 06:48 AM, Jim Meyering wrote: Actually, with GNU make, this is something that we could probably adjust at make-time. Only if you use Automake-NG, and can assume GNU make. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: another manywarnings failure
Jim Meyering wrote: ... Yes, it looks like if we're using both of those, we'll have to add code to reject -Wuninitialized (maybe with a warning?) when configuring without -O. ... [here's simple PoC, i.e., it doesn't know about -O0, but you get the idea ] W = -Wuninitialized -Werror CFLAGS = -O ifneq (,$(findstring -Wuninitialized,$(W))) ifneq (,$(findstring -Werror,$(W))) ifneq (,$(findstring -O,$(CFLAGS))) W := $(subst -Wuninitialized,,$(W)) endif endif endif all: @echo $(W) Not quite. The innermost test was reversed: s/ifneq/ifeq/: # With -O in $(CFLAGS) and both -Wuninitialized and -Werror in $(W), # remove -Wuninitialized from $(W). ifneq (,$(findstring -Wuninitialized,$(W))) ifneq (,$(findstring -Werror,$(W))) ifeq (,$(findstring -O,$(CFLAGS))) W := $(subst -Wuninitialized,,$(W)) endif endif endif Also, cfg.mk is project-specific. This is general enough that a shared file like maint.mk would be a better home for it. On the other hand, if you want to change the .m4 file, that would probably be even better, from a locality standpoint. Oh... and then there's the issue of the multiple WARN_CFLAGS variables. coreutils has these three: GNULIB_TEST_WARN_CFLAGS GNULIB_WARN_CFLAGS WARN_CFLAGS Hmm... with that realization, and knowing that those variable names are not standardized, the makefile-based approach looks even less interesting.
