From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26675 invoked by alias); 28 Sep 2016 21:51:04 -0000 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 Received: (qmail 26660 invoked by uid 89); 28 Sep 2016 21:51:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=qiyaoltc@gmail.com, qiyaoltcgmailcom, Hx-languages-length:1926, H*RU:cmgw2 X-HELO: gproxy9-pub.mail.unifiedlayer.com Received: from gproxy9-pub.mail.unifiedlayer.com (HELO gproxy9-pub.mail.unifiedlayer.com) (69.89.20.122) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with SMTP; Wed, 28 Sep 2016 21:50:54 +0000 Received: (qmail 13493 invoked by uid 0); 28 Sep 2016 21:50:52 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy9.mail.unifiedlayer.com with SMTP; 28 Sep 2016 21:50:52 -0000 Received: from box522.bluehost.com ([74.220.219.122]) by cmgw2 with id p9qn1t00T2f2jeq019qqkw; Wed, 28 Sep 2016 15:50:50 -0600 X-Authority-Analysis: v=2.1 cv=SZxkKJhu c=1 sm=1 tr=0 a=GsOEXm/OWkKvwdLVJsfwcA==:117 a=GsOEXm/OWkKvwdLVJsfwcA==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=GW1xBdLrtEIA:10 a=pGLkceISAAAA:8 a=HSs9IbzQg2kD829IOTEA:9 a=ZsaK_ktmqzmEw9qm:21 a=TXyGkB-XNq-4fHg8:21 a=6kGIvZw6iX1k4Y-7sg4_:22 Received: from 71-218-192-86.hlrn.qwest.net ([71.218.192.86]:57872 helo=bapiya) by box522.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_1) (envelope-from ) id 1bpLD5-0007yE-Nf; Wed, 28 Sep 2016 14:12:07 -0600 From: Tom Tromey To: Yao Qi Cc: Tom Tromey , "gdb-patches\@sourceware.org" Subject: Re: [RFA 1/3] Fix "fall through" comments References: <1475000192-8789-1-git-send-email-tom@tromey.com> <1475000192-8789-2-git-send-email-tom@tromey.com> <8760phcamm.fsf@tromey.com> Date: Wed, 28 Sep 2016 21:58:00 -0000 In-Reply-To: (Yao Qi's message of "Wed, 28 Sep 2016 19:42:21 +0100") Message-ID: <8760pfhjhl.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BWhitelist: no X-Exim-ID: 1bpLD5-0007yE-Nf X-Source-Sender: 71-218-192-86.hlrn.qwest.net (bapiya) [71.218.192.86]:57872 X-Source-Auth: tom+tromey.com X-Email-Count: 0 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTIyLmJsdWVob3N0LmNvbQ== X-SW-Source: 2016-09/txt/msg00404.txt.bz2 >>>>> "Yao" == Yao Qi writes: Tom> On my machine, clang won't build gdb. From memory there was at Tom> least some issue compiling .c files in c++ mode, but I think there Tom> were other problems as well. Yao> We can use option '-x c++' to suppress the warnings, but you are Yao> right, there are some other problems, like some warning options are Yao> unknown to clang. Yeah. I tried it again and there are two issues. First, clang++ doesn't like the .c extension: clang-3.8: error: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated I was able to fix this with: make CC=clang CXX='clang++ -x c++' CC_LD=clang++ After that I got: error: unknown warning option '-Wunused-but-set-parameter'; did you mean '-Wunused-parameter'? [-Werror,-Wunknown-warning-option] error: unknown warning option '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'? [-Werror,-Wunknown-warning-option] This is probably an oversight in warning.m4, as in config.log I see: configure:14316: clang++ -c -g -O2 -Wunused-but-set-parameter conftest.cpp >&5 warning: unknown warning option '-Wunused-but-set-parameter'; did you mean '-Wunused-parameter'? [-Wunknown-warning-option] 1 warning generated. configure:14316: $? = 0 Adding 'WERROR_CFLAGS=' solves this... but at this point it's fine to keep fall-through comments, because warnings are disabled anyway. It's worth noting that I see tons of "unused function" warnings from vec.h. when building this way. There's definitely some work to be done here if anybody wants to use clang. In sum my view is that it's fine to go ahead with the comment approach. If someone wants to fix up the clang build I can help convert the comments to an attribute. (The issue with doing it up-front is discovering the spots that would need a change -- gcc won't tell us what they are.) thanks, Tom