From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Samuel Bronson Newsgroups: gmane.emacs.devel Subject: Re: gl_MANYWARN_ALL_GCC() leads to many spurious warnings Date: Sat, 7 Jul 2012 20:41:17 -0400 Message-ID: <66583BA3-F963-45E2-A543-18F242B3DD64@gmail.com> References: <4FF75B71.3040607@cs.ucla.edu> <707B3485-91B3-4420-888A-A02416D2D1C7@gmail.com> <4FF893CD.2050403@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1341708095 4684 80.91.229.3 (8 Jul 2012 00:41:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 8 Jul 2012 00:41:35 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 08 02:41:34 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SnfZ5-0001Nu-3t for ged-emacs-devel@m.gmane.org; Sun, 08 Jul 2012 02:41:31 +0200 Original-Received: from localhost ([::1]:39489 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SnfZ4-0001V1-73 for ged-emacs-devel@m.gmane.org; Sat, 07 Jul 2012 20:41:30 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37338) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SnfZ1-0001Uv-2t for emacs-devel@gnu.org; Sat, 07 Jul 2012 20:41:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SnfYy-0005hk-QY for emacs-devel@gnu.org; Sat, 07 Jul 2012 20:41:26 -0400 Original-Received: from mail-qc0-f169.google.com ([209.85.216.169]:52194) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SnfYy-0005he-Il for emacs-devel@gnu.org; Sat, 07 Jul 2012 20:41:24 -0400 Original-Received: by qcsd16 with SMTP id d16so6713277qcs.0 for ; Sat, 07 Jul 2012 17:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; bh=Cvc7jNY3UsRDI+pZ4dcHGFUmJxcrhhKJxALdRcumtrs=; b=FwK3k0vI22AVb0uSIFL5rVBrsZXgbhDc4reGDJ66nsf+bxPuVitLaOwZtF2w0+Yrhe S5OZYX3/K0w5CnYNGtyXFyh5UTpRrhEXn0pdksay2lbYLAzZLbch7btP2vmtEjaH+smM pTBjKgj/zB8JzosfymatX31+Sfs+OL7YlG6Q88DKxwcURgfGcVWyCP3EmwCeyMMOaUQh lNNJFnbSqeGDhunap7LFJRJzbDgU1HqroGt6u4Xsi+KnGoRN2HXyUj4sEHcJH6fsAhZD PJnOppM+dT6nvFQ4jT486fieFZDnG8ustFV+3HkhZFepeg/ScZCH1lwkdJo4pOzB81ad 4XCA== Original-Received: by 10.224.117.13 with SMTP id o13mr63048738qaq.73.1341708082011; Sat, 07 Jul 2012 17:41:22 -0700 (PDT) Original-Received: from [192.168.0.18] (207-172-123-137.c3-0.upd-ubr1.trpr-upd.pa.cable.rcn.com. [207.172.123.137]) by mx.google.com with ESMTPS id cg7sm56099036qab.19.2012.07.07.17.41.19 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 07 Jul 2012 17:41:20 -0700 (PDT) In-Reply-To: <4FF893CD.2050403@cs.ucla.edu> X-Mailer: Apple Mail (2.936) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.216.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:151485 Archived-At: On Jul 7, 2012, at 3:53 PM, Paul Eggert wrote: > 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. Yeah, I've actually started trying to get rid of a lot of warnings in my own tree already; I've been waiting on my copyright assignment papers before actually submitting. At this point I don't think the warnings will turn up much in the way of actual bugs; it is turning up a fair amount of seemingly redundant code, though. I did find one in GCC 4.7.1, though; it gives warnings like this: /Users/user/hacking/emacs/src/nsterm.m: In function '-[EmacsView markedRange]': /Users/user/hacking/emacs/src/nsterm.m:5041:5: warning: format not a string literal and no format arguments [-Wformat-security] for calls that most assuredly do use string literals: - (NSRange)markedRange { NSRange rng = workingText != nil ? NSMakeRange (0, [workingText length]) : NSMakeRange (NSNotFound, 0); if (NS_KEYLOG) NSLog (@"markedRange request"); return rng; } given this declaration (from NSObjCRuntime.h): FOUNDATION_EXPORT void NSLog(NSString *format, ...) __attribute__((format(__NSString__, 1, 2))); > 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. Fair enough, I guess. >> 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? Well, okay, it doesn't seem *quite* buggy in GCC 4.7.1 -- it just seems to solve the wrong problem, based on what it does with regex.c when building in lib-src: /sw/bin/ccache /sw/bin/gcc-fsf-4.7 -std=gnu99 -c -Wall -W -Wformat- y2k -Wformat-security -Winit-self -Wmissing-include-dirs -Wunused - Wunknown-pragmas -Wstrict-aliasing -Wdeclaration-after-statement - Wunsafe-loop-optimizations -Wpointer-arith -Wbad-function-cast -Wcast- align -Wwrite-strings -Wstrict-prototypes -Wold-style-definition - Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn - Wmissing-format-attribute -Wpacked -Wunreachable-code -Winvalid-pch - Wvolatile-register-var -Wdisabled-optimization -Wbuiltin-macro- redefined -Wmudflap -Wpacked-bitfield-compat -Wsync-nand -Wattributes - Wcoverage-mismatch -Wunused-macros -Wabi -Wcpp -Wdeprecated - Wdeprecated-declarations -Wdiv-by-zero -Wdouble-promotion -Wendif- labels -Wextra -Wformat-contains-nul -Wformat-extra-args -Wformat-zero- length -Wformat=2 -Wmultichar -Wnormalized=nfc -Woverflow -Wpointer-to- int-cast -Wpragmas -Wsuggest-attribute=noreturn -Wtrampolines -Wno- missing-field-initializers -Wno-sign-compare -Wno-type-limits -Wno- switch -Wno-unused-parameter -Wno-format-nonliteral -Wno-logical-op - fdiagnostics-show-option -funit-at-a-time -I. -I../src -I../lib -I/ Users/user/hacking/emacs/lib-src -I/Users/user/hacking/emacs/lib- src/../src -I/Users/user/hacking/emacs/lib-src/../lib -DXASSERTS=1 -g -O2 -DCONFIG_BROKETS -DINHIBIT_STRING_HEADER \ /Users/user/hacking/emacs/lib-src/../src/regex.c /Users/user/hacking/emacs/lib-src/../src/regex.c:805:0: warning: macro "CHARSET_RANGE_TABLE_BITS" is not used [-Wunused-macros] /Users/user/hacking/emacs/lib-src/../src/regex.c:268:0: warning: macro "CHAR_HEAD_P" is not used [-Wunused-macros] /Users/user/hacking/emacs/lib-src/../src/regex.c:269:0: warning: macro "SINGLE_BYTE_CHAR_P" is not used [-Wunused-macros] /Users/user/hacking/emacs/lib-src/../src/regex.c:1880:0: warning: macro "EXTEND_RANGE_TABLE" is not used [-Wunused-macros] /Users/user/hacking/emacs/lib-src/../src/regex.c:1890:0: warning: macro "SET_RANGE_TABLE_WORK_AREA_BIT" is not used [-Wunused-macros] /Users/user/hacking/emacs/lib-src/../src/regex.c:270:0: warning: macro "SAME_CHARSET_P" is not used [-Wunused-macros] /Users/user/hacking/emacs/lib-src/../src/regex.c:285:0: warning: macro "BYTE8_TO_CHAR" is not used [-Wunused-macros] /Users/user/hacking/emacs/lib-src/../src/regex.c:284:0: warning: macro "MAKE_CHAR" is not used [-Wunused-macros] /Users/user/hacking/emacs/lib-src/../src/regex.c:263:0: warning: macro "CHARSET_LEADING_CODE_BASE" is not used [-Wunused-macros] /Users/user/hacking/emacs/lib-src/../src/regex.c:262:0: warning: macro "CHAR_CHARSET" is not used [-Wunused-macros] /Users/user/hacking/emacs/lib-src/../src/regex.c:1903:0: warning: macro "SET_RANGE_TABLE_WORK_AREA" is not used [-Wunused-macros] (It seems that these macros are only used #ifdef emacs)