From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3392 invoked by alias); 10 Aug 2008 22:18:43 -0000 Received: (qmail 3054 invoked by uid 48); 10 Aug 2008 22:17:23 -0000 Date: Sun, 10 Aug 2008 22:18:00 -0000 Message-ID: <20080810221723.3053.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "tromey at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-08/txt/msg00724.txt.bz2 ------- Comment #12 from tromey at gcc dot gnu dot org 2008-08-10 22:17 ------- > I am not sure how that will work. How do you specify a different value of > system_header for a single location? My understanding is that sysp is for a > whole line_map, so you cannot just change its value for a single location. My understanding is that the problem is that we have a define in a system header, like this from comment #8: #define _Complex_I 1.0iF But then we use this macro in user code, and get a warning, because we lose track of the system-header-ness. Right now c_lex_with_flags calls cpp_get_token_with_location. This function returns two locations for tokens coming from a macro expansion: the original location of the token, and also the location of the start of the expansion. Current we throw away the former and just use the latter. But, we could be smarter about using the former location as well. I think there is another PR (maybe more) where this same idea would make sense. This would need some work to handle the token pasting case. > We could handle this for each error but that is not ideal either. This would be > trivial if tokens expanded from macros carried two locations around but I guess > that is too expensive, isn't it? I think it would be interesting to encode the macro expansion and token pasting history into a location, the same way we encode the include history. I don't know how expensive this would be. If it is not too bad it would let us emit much nicer error messages in otherwise confusing macro-expansion cases. (In fact this would be my preferred implementation approach ... but it is much harder than just looking at the already-known second location.) I hope this makes sense and that I'm not missing something :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263