From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33129 invoked by alias); 13 Jun 2017 14:38:30 -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 31218 invoked by uid 89); 13 Jun 2017 14:38:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=Hx-languages-length:1581, quality X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 13 Jun 2017 14:38:18 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dKmxV-0001hh-At for gdb-patches@sourceware.org; Tue, 13 Jun 2017 10:38:21 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44489) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dKmxV-0001hb-6y; Tue, 13 Jun 2017 10:38:17 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4477 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dKmxU-0003KP-8m; Tue, 13 Jun 2017 10:38:16 -0400 Date: Tue, 13 Jun 2017 14:38:00 -0000 Message-Id: <83k24g3qcx.fsf@gnu.org> From: Eli Zaretskii To: Simon Marchi CC: qiyaoltc@gmail.com, simon.marchi@polymtl.ca, gdb-patches@sourceware.org In-reply-to: (message from Simon Marchi on Tue, 13 Jun 2017 12:23:27 +0200) Subject: Re: [PATCH 0/5] Remove a few hurdles of compiling with clang Reply-to: Eli Zaretskii References: <1497124689-11842-1-git-send-email-simon.marchi@ericsson.com> <83tw3n5jyk.fsf@gnu.org> <86tw3labb0.fsf@gmail.com> <83a85d5l4n.fsf@gnu.org> <93eb64489ac9d53665a144ddf5a966d5@polymtl.ca> <83wp8h40lo.fsf@gnu.org> <8660g0dzau.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00384.txt.bz2 > From: Simon Marchi > Date: Tue, 13 Jun 2017 12:23:27 +0200 > > If somebody is willing to do the work and that it doesn't degrade the code quality, > we should have no problem accepting it. So if it's a "side-step" that allows both > compilers to be happy, that's ok. As a patch submitter, if you use primarily GCC, > you are not required to test your patches with Clang, but if you use primarily Clang, > you must test your patch with GCC (a version that's easily accessible for you). > > Does that sound like a good rule? Let's not forget that code submitted by someone who is willing to do the work stays in GDB even when that someone is no longer willing to support that compiler. So there are additional factors to consider when making this decision. > /home/emaisin/src/binutils-gdb/gdb/nat/x86-dregs.c:209:7: error: variable 'i' is incremented both in the loop header and in the loop body [-Werror,-Wfor-loop-analysis] > i++; > ^ > /home/emaisin/src/binutils-gdb/gdb/nat/x86-dregs.c:199:32: note: incremented here > ALL_DEBUG_ADDRESS_REGISTERS (i) > ^ Why is incrementing a loop variable in the body an error? It's perfectly valid code. > I think > that eliminating the error like this is better than adding -Wno-for-loop-analysis, because > if I wrote code like this and it was actually a mistake, I would like the compiler to tell > me. Does clang have the equivalent of "#pragma push"? If it does, we could disable this warning only for clang and only for that code snippet.