[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants

["manu at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #13 from manu at gcc dot gnu dot org  2008-08-10 23:13 -------
(In reply to comment #12)
> > 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 thought as much until this point. However the issue remains on how to handle
the two locations. It would require a lot of changes in both the c-parser and
libcpp. The other approach that you mention (encoding the macro expansion in
one single location information somehow) would probably be less intrusive.

> I think there is another PR (maybe more) where this same idea would make sense.


Andrew? Any idea?

> This would need some work to handle the token pasting case.
[nice idea snipped]
> I hope this makes sense and that I'm not missing something :)

Yes. We probably do not need the whole macro expansion history, we just need to
encode in a single location the current location of the token and the
"original" location of the token. 

On the other hand, I am not sure how the macro expansion information could be
used to provide nicer diagnostics. How do you decide to print the unexpanded
macro, or the first expansion, or the second expansion? Furthermore, on which
context: expanded macro in the context of the original macro or show the first
expansion definition or...?

Getting us to use one location right is proving to be difficult, doing ranges
as LLVM would be nice but no one is working on it, so I thought that two
locations final/original was a wild idea. A stack of macro expansions is like
science fiction!! ;-)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263