From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48431 invoked by alias); 30 Nov 2016 16:23:34 -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 48414 invoked by uid 89); 30 Nov 2016 16:23:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=HX-Greylist:succeeded, HX-Greylist:SMTP, HX-Greylist:AUTH, wednesday X-HELO: mail.baldwin.cx Received: from bigwig.baldwin.cx (HELO mail.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 30 Nov 2016 16:23:23 +0000 Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id EE7FF10A843; Wed, 30 Nov 2016 11:23:21 -0500 (EST) From: John Baldwin To: Pedro Alves Cc: Simon Marchi , gdb-patches@sourceware.org Subject: Re: [PATCH 1/3] Fix mismatched struct vs class tags. Date: Wed, 30 Nov 2016 16:23:00 -0000 Message-ID: <1853167.ixQKmG4D0P@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-PRERELEASE; KDE/4.14.10; amd64; ; ) In-Reply-To: <31fa3dbd-e1d1-1fd2-7774-8bc82fd8b37d@redhat.com> References: <20161123200652.89209-1-jhb@FreeBSD.org> <1573845.CKxfuZpZBq@ralph.baldwin.cx> <31fa3dbd-e1d1-1fd2-7774-8bc82fd8b37d@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg00997.txt.bz2 On Wednesday, November 30, 2016 11:38:47 AM Pedro Alves wrote: > On 11/24/2016 07:15 PM, John Baldwin wrote: > > On Thursday, November 24, 2016 06:50:30 PM Pedro Alves wrote: > >> On 11/24/2016 05:45 PM, John Baldwin wrote: > >> > >>> Ok. At the moment we don't have a clang-specific warning set, but if we > >>> add one we can add this to that. > >> > >> We likely don't need one. Our infrustruture checks whether a > >> warning works before enabling it. See gdb/warning.m4. > > > > Hmmm. The only odd case I can think of is -Wunused-function. Right now > > clang triggers warnings when VEC() is used, so ideally -Wunused-function > > Yeah, I still believe that's a clang bug, and clang developers > seem to agree: > > https://llvm.org/bugs/show_bug.cgi?id=22712 Oh certainly. My only point is that to get a -Werror clang build working I'd need a way to exclude -Wunused-function from WARNFLAGS for clang. That's the part I wasn't sure how to handle. I still need to see about adding -Wno-foo for some other clang-only warnings to trim other bits of noise from clang's build. One other clangism is that clang warns about compiling a .c file in C++. It wants an explicit '-x c++' to force the language mode. However, simply adding this to CXX_FLAGS doesn't work as it is included in both compiling and linking (and for the link it causes clang to try to parse all the object files as C++ source leading to bizarre errors). I assume a massive .c -> .cc (or .cxx, etc.) rename is not in the roadmap (it would presumably be very disruptive to pending patchsets)? -- John Baldwin