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.
[do...@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:
[do...@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:
[do...@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
