From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15653 invoked by alias); 10 Aug 2007 10:04:03 -0000 Received: (qmail 15528 invoked by uid 22791); 10 Aug 2007 10:04:02 -0000 X-Spam-Check-By: sourceware.org Received: from rv-out-0910.google.com (HELO rv-out-0910.google.com) (209.85.198.184) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 10 Aug 2007 10:03:58 +0000 Received: by rv-out-0910.google.com with SMTP id f5so567942rvb for ; Fri, 10 Aug 2007 03:03:56 -0700 (PDT) Received: by 10.141.142.15 with SMTP id u15mr1347234rvn.1186740235923; Fri, 10 Aug 2007 03:03:55 -0700 (PDT) Received: by 10.141.1.13 with HTTP; Fri, 10 Aug 2007 03:03:55 -0700 (PDT) Message-ID: <6c33472e0708100303u18003efer69d4b45d7dc1ed58@mail.gmail.com> Date: Fri, 10 Aug 2007 10:04:00 -0000 From: "=?ISO-8859-1?Q?Manuel_L=F3pez-Ib=E1=F1ez?=" To: "DJ Delorie" Subject: Re: Add a __nowarn__ keyword Cc: gdr@cs.tamu.edu, mark@codesourcery.com, ghazi@caip.rutgers.edu, gcc-patches@gcc.gnu.org In-Reply-To: <200708100327.l7A3RUbm005253@greed.delorie.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46B9F0B5.1080302@gnu.org> <20070809143028.GA14681@caradoc.them.org> <6c33472e0708090805t210191f6r63832af3afdd0816@mail.gmail.com> <200708091531.l79FVI4w032104@greed.delorie.com> <46BB93CD.7070300@codesourcery.com> <87hcn8885y.fsf@soliton.cs.tamu.edu> <200708100200.l7A20oe8001939@greed.delorie.com> <200708100327.l7A3RUbm005253@greed.delorie.com> X-IsSubscribed: yes 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: 2007-08/txt/msg00658.txt.bz2 On 10/08/07, DJ Delorie wrote: > > > | I'm working on it now. > > > > awesome! > > How's this look? The classification state change tree is in the > diagnostic context, but the actual structure is opaque. The push/pop > stack is separate, stored in c-pragma.c. This way, the save/restore > can be used for scope-level diagnostic state once we figure out how to > define that, via a (save A, restore B, restore A) for now. At some > point, I suppose we could pass the state pointer itself to the > diagnostic reporting functions. > Do we have the scope-level information available when we emit diagnostics from the middle-end? How do you search for the current state given a scope? Also, it is not clear to me how the scope of a pragma is defined by its location. You may have several contradicting pragmas at file-scope (set to ignore, then restore), how you lookup the status in that case? As Gabriel, I am a bit confused by what you want to achieve with the proposed push/pop. As the way I see it, some user cases could be: 1. Kaveh wants to disable -Wcast-qual for just one macro. #define WHATEVER \ _Pragma("GCC diagnostics disable -Wcast-qual"); \ my_beautiful_hack \ _Pragma("GCC diagnostics restore -Wcast-qual"); 2. DJ wants a header with stricter diagnostics that preserves the initial state and restores it at the end of the header #pragma GCC diagnostics error "-Whatever" #pragma GCC diagnostics error "-Whatever2" typical things within a header #pragma GCC diagnostics restore "-Whatever" #pragma GCC diagnostics restore "-Whatever2" 3. Manuel wants to enable the new -Wconversion that comes with GCC 4.3 but does not want to get weird warnings for older compilers. #if GCC_VERSION > 40300 #pragma GCC diagnostics enable "-Wconversion" #else #pragma GCC diagnostics disable "-Wconversion" #endif Yes, a simple #pragma GCC diagnostics restore may be shorter for case 2 when you have hundreds of pragmas. It will mean "undo all changes up to the previous pop/save operation or the initial state". But I think it will be a bit expensive operation when the user can simply do copy + paste + s/error/restore/ Maybe (probably) I am misunderstanding your implementation. If you have some examples as you see it, it will help me to understand how you envision the feature. Cheers, Manuel.