public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "dodji at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants Date: Fri, 26 Nov 2010 00:15:00 -0000 [thread overview] Message-ID: <bug-7263-4-IxgZMH8G8u@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-7263-4@http.gcc.gnu.org/bugzilla/> 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
next parent reply other threads:[~2010-11-25 23:39 UTC|newest] Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-7263-4@http.gcc.gnu.org/bugzilla/> 2010-11-26 0:15 ` dodji at gcc dot gnu.org [this message] 2010-11-26 0:30 ` dodji at gcc dot gnu.org 2010-11-26 0:52 ` manu at gcc dot gnu.org 2010-11-26 15:20 ` dodji at gcc dot gnu.org 2010-11-26 21:19 ` dodji at gcc dot gnu.org 2011-07-27 18:13 ` dodji at gcc dot gnu.org 2011-10-17 10:03 ` dodji at gcc dot gnu.org 2011-10-17 10:27 ` dodji at gcc dot gnu.org 2012-05-16 11:06 ` dodji at gcc dot gnu.org 2012-05-16 13:08 ` dodji at gcc dot gnu.org 2023-01-24 19:55 ` pinskia at gcc dot gnu.org [not found] <bug-7263-1664@http.gcc.gnu.org/bugzilla/> 2008-04-22 15:27 ` tromey at gcc dot gnu dot org 2008-08-10 19:26 ` manu at gcc dot gnu dot org 2008-08-10 22:18 ` tromey at gcc dot gnu dot org 2008-08-10 23:15 ` manu at gcc dot gnu dot org 2008-08-11 2:20 ` tromey at gcc dot gnu dot org 2008-08-18 11:33 ` manu at gcc dot gnu dot org 2008-08-18 13:57 ` manu at gcc dot gnu dot org 2008-08-19 19:29 ` tromey at gcc dot gnu dot org 2008-08-19 19:51 ` manu at gcc dot gnu dot org 2010-03-22 18:21 ` tromey at gcc dot gnu dot org 2010-03-23 13:06 ` manu at gcc dot gnu dot org 2010-03-23 15:19 ` tromey at gcc dot gnu dot org 2010-03-30 14:06 ` dodji at gcc dot gnu dot org 2010-05-28 15:34 ` dodji at gcc dot gnu dot org 2010-05-28 15:42 ` dodji at gcc dot gnu dot org 2010-06-04 19:37 ` dodji at gcc dot gnu dot org 2010-06-04 20:22 ` manu at gcc dot gnu dot org 2010-06-09 14:23 ` Dodji Seketeli 2010-06-09 14:32 ` Dodji Seketeli 2010-06-09 14:23 ` dodji at redhat dot com 2010-06-09 14:32 ` dodji at redhat dot com 2010-06-09 17:09 ` dodji at gcc dot gnu dot org 2010-06-09 17:57 ` manu at gcc dot gnu dot org 2010-06-14 14:13 ` dodji at redhat dot com 2010-06-14 14:21 ` dodji at gcc dot gnu dot org 2010-07-02 19:00 ` dodji at gcc dot gnu dot org [not found] <20020710082600.7263.andrew@andypo.net> 2004-07-19 1:38 ` pinskia at gcc dot gnu dot org 2004-10-07 12:16 ` pinskia at gcc dot gnu dot org 2005-02-09 2:51 ` neroden at gcc dot gnu dot org 2005-02-09 6:15 ` joseph at codesourcery dot com 2005-04-06 11:16 ` jsm28 at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-7263-4-IxgZMH8G8u@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).