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

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

[tromey at gcc dot gnu dot org]

------- Comment #10 from tromey at gcc dot gnu dot org  2008-04-22 15:24 -------
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.


-- 

tromey at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at gcc dot gnu dot
                   |                            |org


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

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

[manu at gcc dot gnu dot org]

------- Comment #11 from manu at gcc dot gnu dot org  2008-08-10 19:25 -------
(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?


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu dot org


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

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

[tromey at gcc dot gnu dot org]

------- 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

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

[manu at gcc dot gnu dot 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

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

[tromey at gcc dot gnu dot org]

------- Comment #14 from tromey at gcc dot gnu dot org  2008-08-11 02:18 -------
Just FYI -- I was thinking of PR 36478.
I'll respond to the rest later.


-- 


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

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

[manu at gcc dot gnu dot org]

------- Comment #15 from manu at gcc dot gnu dot org  2008-08-18 11:31 -------
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


-- 


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

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

[manu at gcc dot gnu dot org]

------- Comment #16 from manu at gcc dot gnu dot org  2008-08-18 13:55 -------
__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).


-- 


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

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

[tromey at gcc dot gnu dot org]

------- Comment #17 from tromey at gcc dot gnu dot org  2008-08-19 19:28 -------
Maybe libcpp could have a mode where it also recognizes the __extension__
token?


-- 


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

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

[manu at gcc dot gnu dot org]

------- Comment #18 from manu at gcc dot gnu dot org  2008-08-19 19:50 -------
(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?


-- 


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

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

[tromey at gcc dot gnu dot org]

------- Comment #19 from tromey at gcc dot gnu dot org  2010-03-22 18:21 -------
Created an attachment (id=20163)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20163&action=view)
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.


-- 


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

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

[manu at gcc dot gnu dot org]

------- Comment #20 from manu at gcc dot gnu dot org  2010-03-23 13:05 -------
(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)


-- 


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

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

[tromey at gcc dot gnu dot org]

------- Comment #21 from tromey at gcc dot gnu dot org  2010-03-23 15:19 -------
> 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.


-- 


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

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

[dodji at gcc dot gnu dot org]

------- Comment #22 from dodji at gcc dot gnu dot org  2010-03-30 14:06 -------
I'll be looking into this.


-- 

dodji at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |dodji at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2005-12-28 06:30:47         |2010-03-30 14:06:11
               date|                            |


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

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

[dodji at gcc dot gnu dot org]

------- Comment #23 from dodji at gcc dot gnu dot org  2010-05-28 15:34 -------
Created an attachment (id=20769)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20769&action=view)
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.


-- 

dodji at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #20163|0                           |1
        is obsolete|                            |


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

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

[dodji at gcc dot gnu dot org]

------- Comment #24 from dodji at gcc dot gnu dot org  2010-05-28 15:42 -------
Created an attachment (id=20770)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20770&action=view)
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.


-- 


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

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

[dodji at gcc dot gnu dot org]

------- Comment #25 from dodji at gcc dot gnu dot org  2010-06-04 19:36 -------
Created an attachment (id=20846)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20846&action=view)
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')


-- 


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

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

[manu at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]



------- Comment #26 from manu at gcc dot gnu dot org  2010-06-04 20:22 -------
(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.


-- 


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

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

[dodji at redhat dot com]

------- Comment #27 from dodji at gcc dot gnu dot org  2010-06-09 14:23 -------
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.


-- 


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

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

[Dodji Seketeli]

"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.

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

[Dodji Seketeli]

"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.

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

[dodji at redhat dot com]

------- Comment #28 from dodji at gcc dot gnu dot org  2010-06-09 14:32 -------
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.


-- 


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

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

[dodji at gcc dot gnu dot org]

------- Comment #29 from dodji at gcc dot gnu dot org  2010-06-09 17:09 -------
Created an attachment (id=20878)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20878&action=view)
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.


-- 

dodji at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #20769|0                           |1
        is obsolete|                            |
  Attachment #20770|0                           |1
        is obsolete|                            |
  Attachment #20846|0                           |1
        is obsolete|                            |


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

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

[manu at gcc dot gnu dot org]

------- Comment #30 from manu at gcc dot gnu dot org  2010-06-09 17:57 -------
(In reply to comment #29)
> Created an attachment (id=20878)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20878&action=view) [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 ;-)


-- 


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

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

[dodji at redhat dot com]

------- Comment #31 from dodji at gcc dot gnu dot org  2010-06-14 14:13 -------
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 :-)


-- 


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

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

[dodji at gcc dot gnu dot org]

------- Comment #32 from dodji at gcc dot gnu dot org  2010-06-14 14:20 -------
Created an attachment (id=20907)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20907&action=view)
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.


-- 

dodji at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #20878|0                           |1
        is obsolete|                            |


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

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

[dodji at gcc dot gnu dot org]

------- Comment #33 from dodji at gcc dot gnu dot org  2010-07-02 19:00 -------
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.


-- 


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

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.8.0

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

[dodji at gcc dot gnu.org]

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

Dodji Seketeli <dodji at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #43 from Dodji Seketeli <dodji at gcc dot gnu.org> 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.

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

[dodji at gcc dot gnu.org]

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

--- Comment #42 from Dodji Seketeli <dodji at gcc dot gnu.org> 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

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

[dodji at gcc dot gnu.org]

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

--- Comment #41 from Dodji Seketeli <dodji at gcc dot gnu.org> 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.

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

[dodji at gcc dot gnu.org]

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

--- Comment #40 from Dodji Seketeli <dodji at gcc dot gnu.org> 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

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

[dodji at gcc dot gnu.org]

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

--- Comment #39 from Dodji Seketeli <dodji at gcc dot gnu.org> 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

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

[dodji at gcc dot gnu.org]

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

--- Comment #38 from Dodji Seketeli <dodji at gcc dot gnu.org> 2010-11-26 20:58:09 UTC ---
Created attachment 22542
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22542
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.

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

[dodji at gcc dot gnu.org]

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

--- Comment #37 from Dodji Seketeli <dodji at gcc dot gnu.org> 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.

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

[manu at gcc dot gnu.org]

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

--- Comment #36 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 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.

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

[dodji at gcc dot gnu.org]

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

--- Comment #35 from Dodji Seketeli <dodji at gcc dot gnu.org> 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

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

[dodji at gcc dot gnu.org]

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

--- Comment #34 from Dodji Seketeli <dodji at gcc dot gnu.org> 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

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

[jsm28 at gcc dot gnu dot org]

------- Additional Comments From jsm28 at gcc dot gnu dot org  2005-04-06 11:15 -------
*** Bug 20784 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aaronavay62 at aaronwl dot
                   |                            |com


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

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

[joseph at codesourcery dot com]

------- Additional Comments From joseph at codesourcery dot com  2005-02-08 19:07 -------
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.)



-- 


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

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

[neroden at gcc dot gnu dot org]

------- Additional Comments From neroden at gcc dot gnu dot org  2005-02-08 17:26 -------
Shouldn't the warning killer for system header errors apply to this sort of 
thing?  Apparently it doesn't. 

-- 


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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-07 12:16 -------
*** Bug 17877 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |algrant at acm dot org


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

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

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|nobody at gcc dot gnu dot   |unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


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