Bug 7263 - __extension__ keyword doesn't suppress warning on LL or ULL constants
Summary: __extension__ keyword doesn't suppress warning on LL or ULL constants
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: preprocessor (show other bugs)
Version: 3.2
: P3 normal
Target Milestone: ---
Assignee: Dodji Seketeli
URL:
Keywords: diagnostic
: 17877 20784 (view as bug list)
Depends on:
Blocks: 33255
  Show dependency treegraph
 
Reported: 2002-07-10 08:26 UTC by andrew
Modified: 2012-05-16 12:47 UTC (History)
10 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2010-03-30 14:06:11


Attachments
undebugged patch to track macro expansion locations (11.54 KB, patch)
2010-03-22 18:21 UTC, Tom Tromey
Details | Diff
Tom's Initial patch ported to 4.6 (12.59 KB, patch)
2010-05-28 15:34 UTC, Dodji Seketeli
Details | Diff
First version of an updated patch (10.25 KB, patch)
2010-05-28 15:42 UTC, Dodji Seketeli
Details | Diff
Fixes all regressions of C FE's testsuite (23.54 KB, patch)
2010-06-04 19:36 UTC, Dodji Seketeli
Details | Diff
Refreshed version. Fully Bootstraps the C FE and passes regression tests. (23.83 KB, patch)
2010-06-09 17:09 UTC, Dodji Seketeli
Details | Diff
Refreshed version. (24.39 KB, patch)
2010-06-14 14:20 UTC, Dodji Seketeli
Details | Diff
A possible patch to kill pedantic warnings of macros defined in system headers (7.56 KB, patch)
2010-11-26 20:58 UTC, Dodji Seketeli
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description andrew 2002-07-10 08:26:00 UTC
The following code fragment generates a warning in gcc-3.2-20020710, where previous versions (gcc-3.1, gcc-3.0) didn't.

a.c:
--------------------------------------------------------
__extension__ unsigned long long
foo()
{
    return (__extension__ 0x1b27da572ef3cd86ULL);
}
--------------------------------------------------------

% gcc -W -Wall -Werror -ansi -pedantic -c a.c
a.c:4:27: use of C99 long long integer constant

Even though the constant is wrapped using __extension__

__extension__ still removes the warning on the use of
the unsigned long long type.

-Wno-long-long is a workaround for me at the moment.

Release:
gcc-3.2-20020710

Environment:
System: Linux garfield.andypo.net 2.4.18-5smp #1 SMP Mon Jun 10 15:19:40 EDT 2002 i686 unknown
Architecture: i686
Binutils 2.12.90.0.14 20020627
Redhat 7.3 dual processor P3 system
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: /usr/local/src/cvs/gcc/configure --prefix=/usr/local/gcc-3.2-20020710-i686-pc-linux-gnu --with-gnu-as --with-gnu-ld --enable-version-specific-runtime-libs --enable-threads=posix --with-dwarf2 --disable-shared --enable-languages=c++
Comment 1 Christian Ehrhardt 2002-12-09 15:10:17 UTC
State-Changed-From-To: open->analyzed
State-Changed-Why: I can confirm this on recent 3.3. The warning is from the preprocessor
    where we don't know about __extension__. Maybe the fix is to just
    document this. Anyway: Category changed to preprocessor and priority
    raised to medium because this is technically a regression.
Comment 2 Joseph S. Myers 2002-12-09 23:24:53 UTC
From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: <ehrhardt@mathematik.uni-ulm.de>,  <andrew@andypo.net>, 
     <gcc-bugs@gcc.gnu.org>,  <gcc-gnats@gcc.gnu.org>
Cc:  
Subject: Re: preprocessor/7263: __extension__ keyword doesn't suppress warning
 on LL or ULL constants
Date: Mon, 9 Dec 2002 23:24:53 +0000 (GMT)

 On 9 Dec 2002 ehrhardt@mathematik.uni-ulm.de wrote:
 
 > Synopsis: __extension__ keyword doesn't suppress warning on LL or ULL constants
 > 
 > State-Changed-From-To: open->analyzed
 > State-Changed-By: cae
 > State-Changed-When: Mon Dec  9 15:10:17 2002
 > State-Changed-Why:
 >     I can confirm this on recent 3.3. The warning is from the preprocessor
 >     where we don't know about __extension__. Maybe the fix is to just
 >     document this. Anyway: Category changed to preprocessor and priority
 >     raised to medium because this is technically a regression.
 
 Note the same issue applies with the warning for complex floats; since
 __extension__ is there used by glibc's <complex.h> to define _Complex_I,
 some fix involving not warning for such constants arising from macros
 defined in system headers may be necessary.
 
 -- 
 Joseph S. Myers
 jsm28@cam.ac.uk
 

Comment 3 Neil Booth 2002-12-10 00:22:56 UTC
From: Neil Booth <neil@daikokuya.co.uk>
To: ehrhardt@mathematik.uni-ulm.de, andrew@andypo.net, gcc-bugs@gcc.gnu.org,
	gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: preprocessor/7263: __extension__ keyword doesn't suppress warning on LL or ULL constants
Date: Tue, 10 Dec 2002 00:22:56 +0000

 ehrhardt@mathematik.uni-ulm.de wrote:-
 
 >     I can confirm this on recent 3.3. The warning is from the preprocessor
 >     where we don't know about __extension__. Maybe the fix is to just
 >     document this. Anyway: Category changed to preprocessor and priority
 >     raised to medium because this is technically a regression.
 
 I think we just document __extension__ as only applying to non-CPP issues;
 we can't reasonably expect CPP to interact with a parser in all situations
 and under all future code changes.  I imagine we could enhance existing
 code so that we don't have this problem in cases where it is the C front
 end requesting the number interpretation, since it could easily pass a
 "don't warn about foo" flag to cpplib.  However expecting cpplib to get
 it right for #if is not reasonable, seeing as #if can occur between any
 two tokens.
 
 Neil.

Comment 4 Christian Ehrhardt 2002-12-10 11:36:37 UTC
From: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>
To: Neil Booth <neil@daikokuya.co.uk>
Cc: andrew@andypo.net, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
  nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: preprocessor/7263: __extension__ keyword doesn't suppress warning on LL or ULL constants
Date: Tue, 10 Dec 2002 11:36:37 +0100

 On Tue, Dec 10, 2002 at 12:22:56AM +0000, Neil Booth wrote:
 > ehrhardt@mathematik.uni-ulm.de wrote:-
 > 
 > >     I can confirm this on recent 3.3. The warning is from the preprocessor
 > >     where we don't know about __extension__. Maybe the fix is to just
 > >     document this. Anyway: Category changed to preprocessor and priority
 > >     raised to medium because this is technically a regression.
 > 
 > I think we just document __extension__ as only applying to non-CPP issues;
 > we can't reasonably expect CPP to interact with a parser in all situations
 > and under all future code changes.  I imagine we could enhance existing
 > code so that we don't have this problem in cases where it is the C front
 > end requesting the number interpretation, since it could easily pass a
 > "don't warn about foo" flag to cpplib.  However expecting cpplib to get
 > it right for #if is not reasonable, seeing as #if can occur between any
 > two tokens.
 
 The real problem seems to be that cpplib has its own copy of warning options
 in pfile->cpp_opts. The C parser disables the global pedantic flag while
 __extension__ is in effect. However, this change is not propagated into
 cpp_opts. If this was done we could just add the pedantic check in
 cppexp.c. However, neither do I see a clean way to propagate the global
 pedantic flag into cpp_opts nor to check the global flag from cpplib.
 
      regards   Christian
 
 -- 
 THAT'S ALL FOLKS!
Comment 5 Neil Booth 2002-12-11 13:16:54 UTC
Responsible-Changed-From-To: unassigned->neil
Responsible-Changed-Why: Mine.  I'll come up with something.
Comment 6 Andrew Pinski 2004-10-07 12:16:35 UTC
*** Bug 17877 has been marked as a duplicate of this bug. ***
Comment 7 Nathanael C. Nerode 2005-02-08 17:26:19 UTC
Shouldn't the warning killer for system header errors apply to this sort of 
thing?  Apparently it doesn't. 
Comment 8 joseph@codesourcery.com 2005-02-08 19:07:52 UTC
Subject: Re:  __extension__ keyword doesn't suppress
 warning on LL or ULL constants

On Tue, 8 Feb 2005, neroden at gcc dot gnu dot org wrote:

> Shouldn't the warning killer for system header errors apply to this sort of 
> thing?  Apparently it doesn't. 

The problem is that macros are defined in system headers and expanded 
outside them.  Getting the system header treatment to apply to macros 
defined in system headers so that

#define _Complex_I 1.0iF

or

#define INTMAX_C(c) c ## LL

can be defined in system headers, and then expanded in user source files 
without -pedantic diagnostics, would suffice.  (Both cases are relevant, 
the former for <complex.h>, the latter for <stdint.h> if used in C90 
mode.)

Comment 9 Joseph S. Myers 2005-04-06 11:15:56 UTC
*** Bug 20784 has been marked as a duplicate of this bug. ***
Comment 10 Tom Tromey 2008-04-22 15:24:44 UTC
I think this should be fixable now that mapped locations have gone in.
The key is to have c_lex_with_flags return a value for in_system_header
which comes from the token's "original" location, not the macro expansion
location.  I am not sure if this will do the right thing with token pasting.
And, it probably will not work for something like:

/* system */
#define F(x) x
/* user */
F(somethingToCauseAWarning)

It isn't clear to me whether we would want the warning here or not.
Comment 11 Manuel López-Ibáñez 2008-08-10 19:25:20 UTC
(In reply to comment #10)
> I think this should be fixable now that mapped locations have gone in.
> The key is to have c_lex_with_flags return a value for in_system_header
> which comes from the token's "original" location, not the macro expansion
> location.  I am not sure if this will do the right thing with token pasting.

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.

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?
Comment 12 Tom Tromey 2008-08-10 22:17:22 UTC
> 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 :)
Comment 13 Manuel López-Ibáñez 2008-08-10 23:13:50 UTC
(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!! ;-)
Comment 14 Tom Tromey 2008-08-11 02:18:55 UTC
Just FYI -- I was thinking of PR 36478.
I'll respond to the rest later.
Comment 15 Manuel López-Ibáñez 2008-08-18 11:31:56 UTC
Subject: Bug 7263

Author: manu
Date: Mon Aug 18 11:30:32 2008
New Revision: 139194

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139194
Log:
2008-08-18  Manuel Lopez-Ibanez  <manu@gcc.gnu.org>

	PR cpp/7263
	* c-opts.c (cpp_opts): Remove static.
	* c-parser.c (cpp_opts): Declare it extern.
	(disable_extension_diagnostics): Handle cpp options.
	(enable_extension_diagnostics): Likewise.
testsuite/
	* gcc.dg/cpp/pr7263-2.c: New.
	* gcc.dg/cpp/pr7263-2.h: New.
	* gcc.dg/cpp/pr7263-3.c: New.
	* gcc.dg/cpp/pr7263-3.h: New.

Added:
    trunk/gcc/testsuite/gcc.dg/cpp/pr7263-2.c
    trunk/gcc/testsuite/gcc.dg/cpp/pr7263-2.h
    trunk/gcc/testsuite/gcc.dg/cpp/pr7263-3.c
    trunk/gcc/testsuite/gcc.dg/cpp/pr7263-3.h
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/c-opts.c
    trunk/gcc/c-parser.c
    trunk/gcc/testsuite/ChangeLog

Comment 16 Manuel López-Ibáñez 2008-08-18 13:55:42 UTC
__extension__ now works for CPP warnings in the C front-end.

The issue with system headers is more difficult since it depends on having two locations.

C++ lexes everything up front before parsing anything, so the warnings from CPP are all emitted before any C++ warning and __extension__ are handled. I don't see any easy fix to this (apart from moving pedantic CPP warnings to c-common.c but that won't be trivial).
Comment 17 Tom Tromey 2008-08-19 19:28:24 UTC
Maybe libcpp could have a mode where it also recognizes the __extension__ token?
Comment 18 Manuel López-Ibáñez 2008-08-19 19:50:19 UTC
(In reply to comment #17)
> Maybe libcpp could have a mode where it also recognizes the __extension__
> token?

It would definitely need to recognize __extension__. But it doesn't seem easy to implement this. If we make it apply just to the next token, we would need to reset it just after lexing the token after the next.

For example, the C front-end asks CPP for next token. It is __extension__ so CPP disables pedantic and returns it to the front-end. C front-end asks for another token. It is 0x1b27da572ef3cd86ULL. We cannot reset pedantic here because after getting the token, the C front-end may call CPP for further analysis (e.g., cpp_classify_number). We would have to wait for the front-end to ask for yet another token and then reset pedantic.

Should the diagnostics in cpp_classify_number really be given by CPP? If so, why cpp_classify_number is not called by CPP itself?
Comment 19 Tom Tromey 2010-03-22 18:21:08 UTC
Created attachment 20163 [details]
undebugged patch to track macro expansion locations

I wanted to record my unfinished patch to track macro expansion locations,
and this bug seemed like an appropriate place.
Comment 20 Manuel López-Ibáñez 2010-03-23 13:05:57 UTC
(In reply to comment #19)
> 
> I wanted to record my unfinished patch to track macro expansion locations,
> and this bug seemed like an appropriate place.

What is missing from this patch? Is it only the macro location tracked or the parameter expanded within the macro? 

Does this enable us to track macro expansions like Clang?

http://clang.llvm.org/diagnostics.html (search Macro Expansion)

Comment 21 Tom Tromey 2010-03-23 15:19:18 UTC
> What is missing from this patch? Is it only the macro location tracked or the parameter expanded within the macro? 

The biggest problem with the patch is that I didn't finish debugging it.
It causes regressions of various kinds -- it is pretty buggy.
There are a few FIXME comments marking known bad spots.

It tracks the "full" location of each token.  So, if a given token resulted from a macro expansion, you can determine the token's location from before the macro expansion (which might come from another macro expansion, or a macro
definition, or be an argument to a macro invocation).

It doesn't currently handle the original location of tokens arising from
stringizing or pasting.

> Does this enable us to track macro expansions like Clang?

Yes.
Comment 22 Dodji Seketeli 2010-03-30 14:06:11 UTC
I'll be looking into this.
Comment 23 Dodji Seketeli 2010-05-28 15:34:39 UTC
Created attachment 20769 [details]
Tom's Initial patch ported to 4.6

This is just the initial patch I ported to 4.6. It should apply cleanly to recent trunk.
Comment 24 Dodji Seketeli 2010-05-28 15:42:02 UTC
Created attachment 20770 [details]
First version of an updated patch

So I thought I'd post the current state of the patch I am working on.

This patch fixes some issues I noticed about the initial patch, namely:

- The crashes I have noticed while trying to bootstrap c and c++
- Some little issues here and there. Enough to pass bootstrap for C and C++. I haven't tried bootstrapping the other FEs yet.

There are still some caveats:

* I have added an -fdebug-cpp option that (very) verbosely clutters the output of -E. This is useful for me, for debugging purposes. I think the final patch should have this option removed.

* There are still some regression tests that are failing because they need updating.

* I still need to add an option to disable the macro token location tracking.

* The patch still does not handle token pasting

It's true that is still work in progress, but I'd appreciate comments especially if you notice that I am doing something wrong.
Comment 25 Dodji Seketeli 2010-06-04 19:36:50 UTC
Created attachment 20846 [details]
Fixes all regressions of C FE's testsuite

This update fixes all the regressions I have noticed in the test suite of the C FE. I have done the testing and debugging with bootstrap disabled.

This patch merges Tom's initial patch and my additions and should apply to recent trunk.

Next step is to bootstrap the C FE and see/fix the remaining bugs that I encounter there.

Here is what the patch does at the moment:

$ cat test.c
     1  #define OPERATE(OPRD1, OPRT, OPRD2) \
     2   OPRD1 OPRT OPRD2;
     3
     4  #define SHIFTL(A,B) \
     5    OPERATE (A,<<,B)
     6
     7  #define MULT2(A) \
     8    SHIFTL (A,1)
     9
    10  void
    11  g ()
    12  {
    13    MULT2 (1.0);/* 1.0 << 1;*/
    14  }

$ ./cc1 -quiet test.c
While expanding macro OPERATE at test.c:2:8
While expanding macro SHIFTL at test.c:5:14
While expanding macro MULT2 at test.c:8:3
test.c: In function 'g':
test.c:13:3: error: invalid operands to binary << (have 'double' and 'int')
Comment 26 Manuel López-Ibáñez 2010-06-04 20:22:16 UTC
(In reply to comment #25)
> 
> $ ./cc1 -quiet test.c
> While expanding macro OPERATE at test.c:2:8
> While expanding macro SHIFTL at test.c:5:14
> While expanding macro MULT2 at test.c:8:3
> test.c: In function 'g':
> test.c:13:3: error: invalid operands to binary << (have 'double' and 'int')

I find this output a bit confusing. I find clang's output clearer
http://clang.llvm.org/diagnostics.html.

In fact, clang's output actually follows more closely what GCC already does with templates/inline functions. This is from GCC:

test.C:7:3:   instantiated from ‘void SHIFTL(T1, T2) [with T1 = double, T2 = int]’
test.C:10:3:   instantiated from ‘void MULT2(T) [with T = double]’
test.C:15:20:   instantiated from here
test.C:3:3: error: invalid operands of types ‘double’ and ‘int’ to binary ‘operator<<

Also, what are the column numbers pointing to? They don't make sense to me.

In any case, this is a huge step forward! Thanks for working on this. It would be an important marketing point if you manage to complete it for GCC 4.6.
Comment 27 Dodji Seketeli 2010-06-09 14:23:14 UTC
Subject: Re:  __extension__ keyword doesn't suppress warning on LL or ULL constants

"manu at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

> I find this output a bit confusing. I find clang's output clearer
> http://clang.llvm.org/diagnostics.html.

I guess you are talking about the "automatic macro expansion" section of
that link?

>
> In fact, clang's output actually follows more closely what GCC already does
> with templates/inline functions.

Well, this is obviously a first step in that direction. I'd be more
interested in knowing what I can do at *this* step :-)

But yes, once I can bootstrap all the FEs with the macro location
tracking infrastructure in place with no regression, I guess I'll focus
more on the user visible output.
Comment 28 Dodji Seketeli 2010-06-09 14:32:09 UTC
Subject: Re:  __extension__ keyword doesn't suppress warning on LL or ULL constants

"manu at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

>> 
>> $ ./cc1 -quiet test.c
>> While expanding macro OPERATE at test.c:2:8
>> While expanding macro SHIFTL at test.c:5:14
>> While expanding macro MULT2 at test.c:8:3
>> test.c: In function 'g':
>> test.c:13:3: error: invalid operands to binary << (have 'double' and 'int')


> Also, what are the column numbers pointing to? They don't make sense
> to me.

About this line:
>> While expanding macro OPERATE at test.c:2:8

which is about:
#define OPERATE(OPRD1, OPRT, OPRD2) \
 OPRD1 OPRT OPRD2;

Column 8 is the starting column of the OPRT token.

About this line:
>> While expanding macro SHIFTL at test.c:5:14

which is about:
#define SHIFTL(A,B) \
  OPERATE (A,<<,B)

Column 14 is the starting column of the '<<' token.

About this line:
>> While expanding macro MULT2 at test.c:8:3

which is about:
#define MULT2(A) \
  SHIFTL (A,1)

Column 3 is the starting column of the 'SHIFT' token.

> In any case, this is a huge step forward! Thanks for working on this. It would
> be an important marketing point if you manage to complete it for GCC
> 4.6.

No problem ;) Not sure it'll get into 4.6, but I'll try.

Comment 29 Dodji Seketeli 2010-06-09 17:09:13 UTC
Created attachment 20878 [details]
Refreshed version. Fully Bootstraps the C FE and passes regression tests.

This fixes a annoying bug that were making the compiler emit wrong debug info, leading to binaries that were not really debug-able.

Next stop is to disable this feature by default, and enable it with a -ftrack-macro-expansion flag, and update the regressions tests of the C FE.
Comment 30 Manuel López-Ibáñez 2010-06-09 17:57:21 UTC
(In reply to comment #29)
> Created an attachment (id=20878) [edit]
> Refreshed version. Fully Bootstraps the C FE and passes regression tests.
> 
> This fixes a annoying bug that were making the compiler emit wrong debug info,
> leading to binaries that were not really debug-able.
> 
> Next stop is to disable this feature by default, and enable it with a
> -ftrack-macro-expansion flag, and update the regressions tests of the C FE.

Great but... you should just prune the output in the general case (extending prune.exp) and only bother to handle the extra output in cases where it makes sense to specifically test it. This is what we do for the "inlined from" messages and it makes sense to do the same for this kind of message.

I see now the sense in the column numbers, I think it is the order that confused me (and not seeing the code clearly). I would prefer a different output like:

test.c:13:3: in expansion of macro MULT2
test.c:5:14: in expansion of macro SHIFTL
test.c:8:3: in expansion of macro OPERATE
test.c:2:8: error: invalid operands to binary << (have 'double' and 'int')

But this is bike-shedding at this stage and it is more important to get the internals working.

BTW, do we also keep the information about the macro arguments? If so, after your patch goes in we could even go as far as to print macro arguments:

test.c:13:3: in expansion of macro MULT2 [with A=1.0]
test.c:5:14: in expansion of macro SHIFTL [with A=1.0, B=1]
test.c:8:3: in expansion of macro OPERATE [with OPRD1=1.0, OPTR=<<, OPTRD2=1]
test.c:2:8: error: invalid operands to binary << (have 'double' and 'int')

Ok, ok. let's get back to reality ;-)
Comment 31 Dodji Seketeli 2010-06-14 14:13:17 UTC
Subject: Re:  __extension__ keyword doesn't suppress warning on LL or ULL constants

"manu at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

>> Next stop is to disable this feature by default, and enable it with a
>> -ftrack-macro-expansion flag, and update the regressions tests of the C FE.
>
> Great but... you should just prune the output in the general case (extending
> prune.exp) and only bother to handle the extra output in cases where it makes
> sense to specifically test it. This is what we do for the "inlined from"
> messages and it makes sense to do the same for this kind of message.

Indeed. Thanks for the reference to prune.exp. Though, one of the
reasons why I want to be able to disable the feature and fall back to
the previous behaviour is the memory consumption and speed penalty that
*could* arise from the patch. This bug report
http://llvm.org/bugs/show_bug.cgi?id=5610 gives an idea of what I am
talking about.  I agree that I need to make the C++ FE work with the
patch before really worrying about this, but I felt I could do the work
right now and be done with it.

As for prune.exp, I think I will eventually prune at least some parts of
the output when time comes.

>
> I see now the sense in the column numbers, I think it is the order that
> confused me (and not seeing the code clearly). I would prefer a different
> output like:
>
> test.c:13:3: in expansion of macro MULT2
> test.c:5:14: in expansion of macro SHIFTL
> test.c:8:3: in expansion of macro OPERATE
> test.c:2:8: error: invalid operands to binary << (have 'double' and
> 'int')

Ah, okay. Thanks for the comment I'll consider doing this when polishing
the error messages.

>
> But this is bike-shedding at this stage and it is more important to get the
> internals working.
>

Nah. Quite the contrary. I think this is a valuable comment.

> BTW, do we also keep the information about the macro arguments? If so, after
> your patch goes in we could even go as far as to print macro arguments:
>
> test.c:13:3: in expansion of macro MULT2 [with A=1.0]
> test.c:5:14: in expansion of macro SHIFTL [with A=1.0, B=1]
> test.c:8:3: in expansion of macro OPERATE [with OPRD1=1.0, OPTR=<<, OPTRD2=1]
> test.c:2:8: error: invalid operands to binary << (have 'double' and 'int')
>

Not yet. We only keep track of the location of the token accross macro
expansion. We don't keep track of the the kind of information you are
talking about. But I guess this is something we could do. My TODO list
is growing :-)
Comment 32 Dodji Seketeli 2010-06-14 14:20:52 UTC
Created attachment 20907 [details]
Refreshed version.

- Disables the feature by default
- Adds a -ftrack-macro-expansion flag to enable the feature
  Fix a couple of bugs I noticed while trying to make the feature optional
  Updated the relevant regression tests of the macro expansion patch
- Rebased the patch on recent trunk and adapt it to the new directory layout

Next stop is the fix the two remaining FIXMEs and make the C++ FE work.
Comment 33 Dodji Seketeli 2010-07-02 19:00:29 UTC
I have put up a git tree for this. The branch containing my changes is http://seketeli.net/cgit/~dodji/gcc.git/log/?h=PR7263-dodji

The current state as of commit 1d2b6207 addresses the remaining FIXMEs in the code. It thus should properly deallocate the memory used for the macro expansion tokens and still passes regression test for the C FE. Next stop is to make the C++ FE work with this.
Comment 34 Dodji Seketeli 2010-11-25 23:38:09 UTC
I have worked on decreasing the memory consumption of this patchset and I could decrease it quite a bit, even though there is still room for improvement.  On a testcase of mine, I started with a patchset for which the -ftrack-macro-expansion option was consuming 6 times more memory for preprocessing than the initial preprocessor.  Now the patchset consumes 1.6 times more memory with -ftrack-macro-expansion than the initial (non-patched) preprocessor.  On a full compilation of the test I have, -ftrack-macro-expansion increases memory consumption of ~ 13%.  In my quest to further decrease memory consumption I made -ftrack-macro-expansion take parameters 0, 1, or 2.  * 0 means -ftrack-macro-expansion is de-activated.  * 1 means the macro location tracking feature runs in a   "degraded" mode that saves even more memory by making all    argument tokens of a function-like macro have the same location; e.g:            #define IDENT(X) X            IDENT(1+2) would then be expanded to tokens 1+2, tokens '1', '2' and    '3' all have the same location, just like if their locations were    folded into the location of the '1'. This can save a lot of memory.  * 2 means the full feature where all locations of all tokens are   tracked.  A part from that the patchset bootstraps and passes regression tests of C and C++ FEs without -ftrack-macro-expansion.  So now I am back to working on the user facing aspects of the patch again.  Belows is a quick status of what the patch does. It's slightly different from the status I gave earlier.  [dodji@adjoa gcc]$ cat -n test.c      1	#define OPERATE(OPRD1, OPRT, OPRD2) \      2	  OPRD1 OPRT OPRD2;      3	      4	#define SHIFTL(A,B) \      5	  OPERATE (A,<<,B)      6	      7	#define MULT2(A) \      8	  SHIFTL (A,1)      9	     10	void     11	g ()     12	{     13	  MULT2 (1.0);/* 1.0 << 1;*/     14	}  So let's see what an un-patched compiler tells us:  [dodji@adjoa gcc]$ ./cc1 -quiet test.c test.c: In function ‘g’: test.c:13:3: error: invalid operands to binary << (have ‘double’ and ‘int’)  Note how the location given is the locus of the expansion point of the macro. There is no information about where the '<<' token mentionned in the message comes from. In other words, the spelling location of the '<<' is lost.  Now let's see what a patched compiler tells us:  [dodji@adjoa gcc]$ ./cc1 -ftrack-macro-expansion=2 -quiet test.c While expanding macro OPERATE at test.c:2:9 While expanding macro SHIFTL at test.c:5:14 While expanding macro MULT2 at test.c:13:13 test.c: In function 'g': test.c:5:14: error: invalid operands to binary << (have 'double' and 'int')  The location mentionned in the error message (test.c:5:14) is now the spelling location of the token '<<' mentionned in the error message.  The context of the error message (the lines starting with "While expanding macro") unwinds the stack of nested macro expansions that led to "instantiating" the token mentionned in the error message.  The topmost element of the stack of macro expansion is the macro that most directly contains the token mentionned in the error message.  The lowest element of the stack is the macro first macro that actually got expanded and in turn led to the nested macro expansion stack we have.  Note how the location mentioned for this lowest stack element is the location of the /expansion point/ of the macro, whereas locations mentioned for the higher elements are the instantiation locations of the relevant tokens. In other words, the location of the point where SHIFT is expanded inside MULT2 is not interesting. So we don't mention it. But the location of the point where MULT2 is expanded inside the function g is interesting. So it is mentioned.  Hopefuly this can be a starting point for further discussion.  The patchset can be browsed from: http://seketeli.net/git/~dodji/gcc.git/log/?h=PR7263-dodji  You can grab the code by doing:  git clone git://seketeli.net/~dodji/gcc.git gcc.git cd gcc.git git checkout -b PR7263-dodji
Comment 35 Dodji Seketeli 2010-11-25 23:43:02 UTC
OK, my browser screwed up my last comment.

Here is another attempt of the same. Sorry.

I have worked on decreasing the memory consumption of this
patchset and I could decrease it quite a bit, even though there
is still room for improvement.

On a testcase of mine, I started with a patchset for which the
-ftrack-macro-expansion option was consuming 6 times more memory
for preprocessing than the initial preprocessor.

Now the patchset consumes 1.6 times more memory with
-ftrack-macro-expansion than the initial (non-patched)
preprocessor.

On a full compilation of the test I have, -ftrack-macro-expansion
increases memory consumption of ~ 13%.

In my quest to further decrease memory consumption I made
-ftrack-macro-expansion take parameters 0, 1, or 2.

* 0 means -ftrack-macro-expansion is de-activated.

* 1 means the macro location tracking feature runs in a
  "degraded" mode that saves even more memory by making all
   argument tokens of a function-like macro have the same location; e.g:

          #define IDENT(X) X

          IDENT(1+2) would then be expanded to tokens 1+2, tokens '1', '2' and
   '3' all have the same location, just like if their locations were
   folded into the location of the '1'. This can save a lot of memory.

* 2 means the full feature where all locations of all tokens are
  tracked.

A part from that the patchset bootstraps and passes regression
tests of C and C++ FEs without -ftrack-macro-expansion.

So now I am back to working on the user facing aspects of the patch
again.

Belows is a quick status of what the patch does. It's slightly
different from the status I gave earlier.

[dodji@adjoa gcc]$ cat -n test.c
     1	#define OPERATE(OPRD1, OPRT, OPRD2) \
     2	  OPRD1 OPRT OPRD2;
     3	
     4	#define SHIFTL(A,B) \
     5	  OPERATE (A,<<,B)
     6	
     7	#define MULT2(A) \
     8	  SHIFTL (A,1)
     9	
    10	void
    11	g ()
    12	{
    13	  MULT2 (1.0);/* 1.0 << 1;*/
    14	}

So let's see what an un-patched compiler tells us:

[dodji@adjoa gcc]$ ./cc1 -quiet test.c
test.c: In function ‘g’:
test.c:13:3: error: invalid operands to binary << (have ‘double’ and ‘int’)

Note how the location given is the locus of the expansion point of the
macro. There is no information about where the '<<' token mentionned
in the message comes from. In other words, the spelling location of
the '<<' is lost.

Now let's see what a patched compiler tells us:

[dodji@adjoa gcc]$ ./cc1 -ftrack-macro-expansion=2 -quiet test.c
While expanding macro OPERATE at test.c:2:9
While expanding macro SHIFTL at test.c:5:14
While expanding macro MULT2 at test.c:13:13
test.c: In function 'g':
test.c:5:14: error: invalid operands to binary << (have 'double' and 'int')

The location mentionned in the error message (test.c:5:14) is now the
spelling location of the token '<<' mentionned in the error message.

The context of the error message (the lines starting with "While
expanding macro") unwinds the stack of nested macro expansions
that led to "instantiating" the token mentionned in the error
message.

The topmost element of the stack of macro expansion is the macro
that most directly contains the token mentionned in the error
message.

The lowest element of the stack is the macro first macro that
actually got expanded and in turn led to the nested macro
expansion stack we have.

Note how the location mentioned for this lowest stack element is
the location of the /expansion point/ of the macro, whereas
locations mentioned for the higher elements are the instantiation
locations of the relevant tokens. In other words, the location of
the point where SHIFT is expanded inside MULT2 is not
interesting. So we don't mention it. But the location of the
point where MULT2 is expanded inside the function g is
interesting. So it is mentioned.

Hopefuly this can be a starting point for further discussion.

The patchset can be browsed from:
http://seketeli.net/git/~dodji/gcc.git/log/?h=PR7263-dodji

You can grab the code by doing:

git clone git://seketeli.net/~dodji/gcc.git gcc.git
cd gcc.git
git checkout -b PR7263-dodji
Comment 36 Manuel López-Ibáñez 2010-11-26 00:15:05 UTC
Awesome!

I still think that the output would be better if it was more consistent with the current way of printing template instantiations, that is, using "note: while expanding macro..." after the error/warning. If you look to the code for printing the instantiations of templates, you'll see that it also handles long nested templates and recursive templates. Perhaps the same code/algorithm could be used for printing this to avoid such problems.

In any case, you should seek comments from the decision-makers at gcc-patches@, not me, because whatever they want is what is going to be implemented.
Comment 37 Dodji Seketeli 2010-11-26 15:08:34 UTC
"manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> writes:
> Awesome!

:-) thank you for caring.

> I still think that the output would be better if it was more consistent with
> the current way of printing template instantiations, that is, using "note:
> while expanding macro..." after the error/warning. If you look to the code for
> printing the instantiations of templates, you'll see that it also handles long
> nested templates and recursive templates. Perhaps the same code/algorithm could
> be used for printing this to avoid such problems.

Yes, I think so too. I will try to do that.

> In any case, you should seek comments from the decision-makers at gcc-patches@,
> not me, because whatever they want is what is going to be implemented.

Sure, I will do that eventually.

By the way, I started working on fixing the bug mentioned in
comments 2, 8, 10, 11, 12, 13. Now we seem to have the infrastructure to
do so. I will come up with a patch to fix this specifically, on top of
the patcheset of this PR.

Maybe I need a separate PR, I don't know.
Comment 38 Dodji Seketeli 2010-11-26 20:58:09 UTC
Created attachment 22542 [details]
A possible patch to kill pedantic warnings of macros defined in system headers

This patch builds on the infrastructure of the patchset we were talking about earlier. It fixes the problem described in comment 2, 8 et al.

It is hopefully commented enough to explain what it does and how it does it.
Comment 39 Dodji Seketeli 2011-07-27 18:12:44 UTC
Just so that I don't forget the link, a second version of the patch set for this was submitted for review to http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01316.html
Comment 40 Dodji Seketeli 2011-10-17 09:59:02 UTC
Author: dodji
Date: Mon Oct 17 09:58:56 2011
New Revision: 180081

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180081
Log:
Linemap infrastructure for virtual locations

This is the first instalment of a set which goal is to track locations
of tokens across macro expansions.  Tom Tromey did the original work
and attached the patch to PR preprocessor/7263.  This opus is a
derivative of that original work.

This patch modifies the linemap module of libcpp to add virtual
locations support.

A virtual location is a mapped location that can resolve to several
different physical locations.  It can always resolve to the spelling
location of a token.  For tokens resulting from macro expansion it can
resolve to:
  - either the location of the expansion point of the macro.
  - or the location of the token in the definition of the
  macro
  - or, if the token is an argument of a function-like macro,
  the location of the use of the matching macro parameter in
  the definition of the macro

The patch creates a new type of line map called a macro map.  For every
single macro expansion, there is a macro map that generates a virtual
location for every single resulting token of the expansion.

The good old type of line map we all know is now called an ordinary
map.  That one still encodes spelling locations as it has always had.

As a result linemap_lookup as been extended to return a macro map when
given a virtual location resulting from a macro expansion.  The layout
of structs line_map has changed to support this new type of map.  So
did the layout of struct line_maps.  Accessor macros have been
introduced to avoid messing with the implementation details of these
datastructures directly.  This helped already as we have been testing
different ways of arranging these datastructure.  Having to constantly
adjust client code that is too tied with the internals of line_map and
line_maps would have been even more painful.

Of course, many new public functions have been added to the linemap
module to handle the resolution of virtual locations.

This patch introduces the infrastructure but no part of the compiler
uses virtual locations yet.

However the client code of the linemap data structures has been
adjusted as per the changes.  E.g, it's not anymore reliable for a
client code to manipulate struct line_map directly if it just wants to
deal with spelling locations, because struct line_map can now
represent a macro map as well.  In that case, it's better to use the
convenient API to resolve the initial (possibly virtual) location to a
spelling location (or to an ordinary map) and use that.

This is the reason why the patch adjusts the Java, Ada and Fortran
front ends.

Also, note that virtual locations are not supposed to be ordered for
relations '<' and '>' anymore.  To test if a virtual location appears
"before" another one, one has to use a new operator exposed by the
line map interface.  The patch updates the only spot (in the
diagnostics module) I have found that was making the assumption that
locations were ordered for these relations.  This is the only change
that introduces a use of the new line map API in this patch, so I am
adding a regression test for it only.

Added:
    trunk/gcc/testsuite/gcc.dg/cpp/pragma-diagnostic-1.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ada/ChangeLog
    trunk/gcc/ada/gcc-interface/trans.c
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c-lex.c
    trunk/gcc/c-family/c-ppoutput.c
    trunk/gcc/diagnostic.c
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/cpp.c
    trunk/gcc/input.c
    trunk/gcc/input.h
    trunk/gcc/java/ChangeLog
    trunk/gcc/java/jcf-parse.c
    trunk/gcc/testsuite/ChangeLog
    trunk/libcpp/ChangeLog
    trunk/libcpp/directives.c
    trunk/libcpp/files.c
    trunk/libcpp/include/line-map.h
    trunk/libcpp/init.c
    trunk/libcpp/internal.h
    trunk/libcpp/line-map.c
    trunk/libcpp/macro.c
Comment 41 Dodji Seketeli 2011-10-17 10:26:42 UTC
Most of the work done in the patches in attachment was finally checked in to support tracking locations across macro expansions.  The summary of the submission is at http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01461.html.

This bug is still not fixed yet, though.  To properly fix it, I need to change the FEs so that declspecs have their own location.  With that, I'll modify the patch that I sent to http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01043.html.

For the record here is the end of the email thread that gives insight into this: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00264.html.
Comment 42 Dodji Seketeli 2012-05-16 10:51:20 UTC
Author: dodji
Date: Wed May 16 10:51:15 2012
New Revision: 187587

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187587
Log:
PR preprocessor/7263 - Avoid pedantic warnings on system headers macro tokens

Now that we track token locations accross macro expansions, it would
be cool to be able to fix PR preprocessor/7263 for real.  That is,
consider this example where we have a system header named header.h
like this:

	#define _Complex __complex__ #define _Complex_I 1.0iF

and then a normal C file like this:

    #include "header.h"

    static _Complex float c = _Complex_I;

If we compile the file with -pedantic, the usages of _Complex or
_Complex_I should not trigger any warning, even though __complex__ and
the complex literal are extensions to the standard C.

They shouldn't trigger any warning because _Complex and _Complex_I are
defined in a system header (and expanded in normal user code).

To be able to handle this, we must address two separate concerns.

First, warnings about non-standard usage of numerical literals are emitted
directly from within libcpp.  So we must teach libcpp's parser for numerical
literals to use virtual locations, instead of the spelling
location it uses today.  Once we have that, as the diagnostics machinery
already knows how to avoid emitting errors happening on tokens that come from
system headers, we win.

Second, there is the issue of tracking locations for declaration
specifiers, like the "_Complex" in the declaration:

	static _Complex float c;

For that, we need to arrange for each possible declaration specifier
to have its own location, because otherwise, we'd warn on e.g, on:

    _Complex float c;

but not on:

    static _Complex float c;

So this patch addresses the two concerns above.  It's actually a
follow-up on an earlier patch[1] I wrote as part of my initial work on
virtual locations.  We then agreed[2] that the second concern was
important to address before the patch could get a chance to go in.

[1]: http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00957.html
[2]: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00264.html

Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.

libcpp/

	PR preprocessor/7263
	* include/cpplib.h (cpp_classify_number): Take a location
	parameter.
	* expr.c (SYNTAX_ERROR_AT, SYNTAX_ERROR2_AT): New diagnostic
	macros that take a location parameter.
	(cpp_classify_number): Take a (virtual) location parameter.  Use
	it for diagnostics.  Adjust comments.
	(eval_token): Take a location parameter.  Pass it to
	cpp_classify_number and to diagnostic routines.
	(_cpp_parse_expr): Use virtual locations of tokens when parsing
	expressions.  Pass a virtual location to eval_token and to
	diagnostic routines.

gcc/c-family/

	PR preprocessor/7263
	* c-lex.c (c_lex_with_flags):  Pass a virtual location to the call
	to cpp_classify_number.  For diagnostics, use the precise location
	instead of the global input_location.

gcc/
	PR preprocessor/7263
	* c-tree.h (enum c_declspec_word): Declare new enum.
	(struct c_declspecs::locations): New member.
	(declspecs_add_qual, declspecs_add_scspec)
	(declspecs_add_addrspace, declspecs_add_alignas): Take a new
	location parameter.
	* c-decl.c (build_null_declspecs): Initialize the new struct
	c_declspecs::locations member.
	(declspecs_add_addrspace): Take a location parameter for the
	address space.  Store it onto declaration specifiers.
	(declspecs_add_qual): Likewise, take a location parameter for the
	qualifier.
	(declspecs_add_type): Likewise, take a location parameter for the
	type specifier.
	(declspecs_add_scspec): Likewise, take a location parameter for
	the storage class specifier.
	(declspecs_add_attrs): Likewise, take a location parameter for the
	first attribute.
	(declspecs_add_alignas): Likewise, take a location parameter for
	the alignas token.
	(finish_declspecs): For diagnostics, use the location of the
	relevant declspec, instead of the global input_location.
	* c-parser.c (c_parser_parameter_declaration): Pass the precise
	virtual location of the declspec to the declspecs-setters.
	(c_parser_declspecs): Likewise.  Avoid calling c_parser_peek_token
	repeatedly.

gcc/cp/

	PR preprocessor/7263
	* cp-tree.h (enum cp_decl_spec): Add new enumerators to cover all
	the possible declarator specifiers so far.
	(struct cp_decl_specifier_seq::locations): Declare new member.
	(cp_decl_specifier_seq::{specs, type_location}): Remove.
	(decl_spec_seq_has_spec_p): Declare new function.
	* parser.c (cp_parser_check_decl_spec): Remove.
	(set_and_check_decl_spec_loc): Define new static function.
	(decl_spec_seq_has_spec_p): Define new public function.
	(cp_parser_decl_specifier_seq, cp_parser_function_specifier_opt)
	(cp_parser_type_specifier, cp_parser_simple_type_specifier)
	(cp_parser_set_storage_class, cp_parser_set_decl_spec_type)
	(cp_parser_alias_declaration): Set the locations for each
	declspec, using set_and_check_decl_spec_loc.
	(cp_parser_explicit_instantiation, cp_parser_init_declarator)
	(cp_parser_member_declaration, cp_parser_init_declarator): Use the
	new declspec location for specifiers.  Use the new
	decl_spec_seq_has_spec_p.
	(cp_parser_type_specifier_seq): Use the new
	set_and_check_decl_spec_loc.  Stop using
	cp_parser_check_decl_spec.  Use the new decl_spec_seq_has_spec_p.
	(, cp_parser_init_declarator): Use the new
	set_and_check_decl_spec_loc.
	(cp_parser_single_declaration, cp_parser_friend_p)
	(cp_parser_objc_class_ivars, cp_parser_objc_struct_declaration):
	Use the new decl_spec_seq_has_spec_p.
	* decl.c (check_tag_decl): Use new decl_spec_seq_has_spec_p.  Use
	the more precise ds_redefined_builtin_type_spec location for
	diagnostics about re-declaring C++ built-in types.
	(start_decl, grokvardecl, grokdeclarator): Use the new
	decl_spec_seq_has_spec_p.

gcc/testsuite/

	PR preprocessor/7263
	* gcc.dg/binary-constants-2.c: Run without tracking locations
	accross macro expansion.
	* gcc.dg/binary-constants-3.c: Likewise.
	* gcc.dg/cpp/sysmac2.c: Likewise.
	* testsuite/gcc.dg/nofixed-point-2.c: Adjust for more precise
	location.
	* gcc.dg/cpp/syshdr3.c: New test.
	* gcc.dg/cpp/syshdr3.h: New header for the new test above.
	* gcc.dg/system-binary-constants-1.c: New test.
	* gcc.dg/system-binary-constants-1.h: New header for the new test
	above.
	* g++.dg/cpp/syshdr3.C: New test.
	* g++.dg/cpp/syshdr3.h: New header the new test above.
	* g++.dg/system-binary-constants-1.C: New test.
	* g++.dg/system-binary-constants-1.h: New header the new test
	above.

Added:
    trunk/gcc/testsuite/g++.dg/cpp/syshdr3.C
    trunk/gcc/testsuite/g++.dg/cpp/syshdr3.h
    trunk/gcc/testsuite/g++.dg/system-binary-constants-1.C
    trunk/gcc/testsuite/g++.dg/system-binary-constants-1.h
    trunk/gcc/testsuite/gcc.dg/cpp/syshdr3.c
    trunk/gcc/testsuite/gcc.dg/cpp/syshdr3.h
    trunk/gcc/testsuite/gcc.dg/system-binary-constants-1.c
    trunk/gcc/testsuite/gcc.dg/system-binary-constants-1.h
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/c-decl.c
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c-lex.c
    trunk/gcc/c-parser.c
    trunk/gcc/c-tree.h
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/cp-tree.h
    trunk/gcc/cp/decl.c
    trunk/gcc/cp/decl2.c
    trunk/gcc/cp/parser.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/binary-constants-2.c
    trunk/gcc/testsuite/gcc.dg/binary-constants-3.c
    trunk/gcc/testsuite/gcc.dg/cpp/pr7263-3.c
    trunk/gcc/testsuite/gcc.dg/cpp/sysmac1.c
    trunk/gcc/testsuite/gcc.dg/cpp/sysmac2.c
    trunk/gcc/testsuite/gcc.dg/nofixed-point-2.c
    trunk/libcpp/ChangeLog
    trunk/libcpp/expr.c
    trunk/libcpp/include/cpplib.h
Comment 43 Dodji Seketeli 2012-05-16 12:47:31 UTC
I looks like we can finally close this bug now, as it's fixed in trunk (4.8).

Thanks to everybody who contributed.  This was a team effort.