From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11344 invoked by alias); 29 Dec 2006 20:44:50 -0000 Received: (qmail 11336 invoked by uid 22791); 29 Dec 2006 20:44:49 -0000 X-Spam-Check-By: sourceware.org Received: from heller.inter.net.il (HELO heller.inter.net.il) (192.114.186.73) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 29 Dec 2006 20:44:46 +0000 Received: from HOME-C4E4A596F7 (IGLD-83-130-240-52.inter.net.il [83.130.240.52]) by heller.inter.net.il (MOS 3.7.3a-GA) with ESMTP id BJY22548 (AUTH halo1); Fri, 29 Dec 2006 22:44:25 +0200 (IST) Date: Fri, 29 Dec 2006 20:44:00 -0000 Message-Id: From: Eli Zaretskii To: Daniel Jacobowitz CC: gdb-patches@sourceware.org In-reply-to: <20061229135814.GA9741@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 29 Dec 2006 08:58:15 -0500) Subject: Re: RFC: Use -Wall -Wextra Reply-to: Eli Zaretskii References: <20061228195533.GA18492@nevyn.them.org> <20061229135814.GA9741@nevyn.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00350.txt.bz2 > Date: Fri, 29 Dec 2006 08:58:15 -0500 > From: Daniel Jacobowitz > Cc: gdb-patches@sourceware.org > > > > I would agree only if we never try to use -Werror, because with such > > aggressive warnings GDB will never build if we add -Werror. > > > > My other fear is that, with GCC becoming more and more picky about > > perfectly valid C code, these options will cause the compilation to > > become very noisy, but I guess we will hear complaints if that > > happens. > > I don't understand. I built GDB with these warnings and -Werror, so > that can't be literally true. Well, it is on this machine: Linux fencepost 2.6.16.29-xen #1 SMP Wed Dec 6 07:32:36 EST 2006 x86_64 GNU/Linux See below for the error message. > I definitely don't want to back away from -Werror: I think it's done > us a lot of good. I'm not against -Werror, I just don't trust GCC to not flag some innocent code as questionable under -Wall -Wextra. These flags are for those who intentionally want a noisy compiler; adding -Werror to them is asking for too much trouble. > I enabled -Wextra mostly because I wanted -Walways-true IMO -Walways-true is one of the greatest nuisances with the latest GCC versions. Some code, especially sophisticated macros that need to work portably with different data sizes, simply cannot be made to work around this warning, especially if you want to handle 32-bit and 64-bit machines. There already are such problems in GNU Make and in Emacs, and developers are unwilling to fix them because it's too much trouble, if at all possible. > Can you give me some concrete examples of warnings you're concerned about? Those issued by -Walways-true and the ones that wine about mismatch between pointers to signed and unsigned char are the two that come to mind. > (Remember, we ship releases without -Werror.) Thank God for small favors! > > I'd advise against -Wunused: the problems it finds are harmless, > > whereas fixing them is not trivial at all, and quite ugly in some > > cases. > > I'm afraid I don't understand this either. The problems -Wunused finds > are usually very easy to fix. You mean with "i = i;"? Here's the problem that prevented the latest snapshot from building after I patched it with your patches: gcc -c -g -O2 -I. -I. -I./config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../readline/.. -I../bfd -I./../bfd -I./../include -DMI_OUT=1 -DTUI=1 -Wall -Wextra -Wpointer-arith -Wformat-nonliteral -Wno-pointer-sign -Wno-unused-parameter -Wno-unused -Wno-sign-compare -Wno-switch -Wno-missing-field-initializers -Werror infrun.c cc1: warnings being treated as errors infrun.c: In function 'handle_inferior_event': infrun.c:1458: warning: statement with no effect make[2]: *** [infrun.o] Error 1