From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19743 invoked by alias); 22 Aug 2008 16:53:16 -0000 Received: (qmail 19734 invoked by uid 22791); 22 Aug 2008 16:53:16 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 22 Aug 2008 16:52:29 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id m7MGpbCm016339; Fri, 22 Aug 2008 12:51:57 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m7MGpQOE016842; Fri, 22 Aug 2008 12:51:26 -0400 Received: from opsy.redhat.com (vpn-10-112.bos.redhat.com [10.16.10.112]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id m7MGpKEZ032475; Fri, 22 Aug 2008 12:51:20 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id A026937828E; Fri, 22 Aug 2008 10:51:28 -0600 (MDT) To: Simon Baldwin Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH][RFC] -Wno-... option to suppress builtin macro redefined warnings References: <20080730140920.0F9CF3FE1B9@localhost> <489C728B.4040505@google.com> <48A5B2C6.1090600@google.com> <48AEE7A7.9000509@google.com> From: Tom Tromey Reply-To: Tom Tromey X-Attribution: Tom Date: Fri, 22 Aug 2008 17:17:00 -0000 In-Reply-To: <48AEE7A7.9000509@google.com> (Simon Baldwin's message of "Fri\, 22 Aug 2008 17\:21\:59 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2008-08/txt/msg01688.txt.bz2 >>>>> "Simon" == Simon Baldwin writes: Simon> Tom, any further thoughts on this? Simon> It's certainly not hard to split built-in macros into two tiers, Simon> those where redefinition warning can be suppressed by providing Simon> -Wno-builtin-macro-redefined, and those where it can't. However, Simon> since it's all just about suppressing a warning, it may be that one Simon> policy to cover all of them will suffice, and be simpler to manage Simon> and maintain. Simon> No response from Tom to date. Sorry, I had a bit of a mail problem and missed a few things. I think that, as a rule of thumb, we should only relax existing pedantic checks for a good reason. My thinking here is that, in the past, we've had bad experiences with relaxing these rules, and so it is best to defer it as long as we possibly can. In this case, I can understand wanting to override date or time macros. However, I couldn't think of a scenario where it would make sense to modify __LINE__. So, I still think it would be better to separate the cases. I don't think the maintenance burden is a major problem. Perhaps some other GCC maintainer would care to weigh in. Tom