Description of problem: A new (from gcc3 to gcc4) warning suggesting spaces after a while() is not produced consistently from within macros. This causes confusion when using ccache as ccache's preprocessing sometimes 'exposes' warnings that were hidden using raw gcc. Version-Release number of selected component (if applicable): gcc-4.3.0-8.x86_64 How reproducible: The GCC weirdness is easily reproduced. I have not been able to reproduce how these warnings (which turn into errors in our builds) end up in ccache. Steps to Reproduce: 1. compile example program: > cat warn2.cc int main(int, char**) { #define XXX while(0); XXX ; while (0); } > g++ -W -Werror -c warn2.cc Actual results: cc1plus: warnings being treated as errors warn2.cc: In function ‘int main(int, char**)’: warn2.cc:6: error: suggest a space before ‘;’ or explicit braces around empty body in ‘while’ statement Expected results: warn2.cc: In function ‘int main(int, char**)’: warn2.cc:5: warning: suggest a space before ‘;’ or explicit braces around empty body in ‘while’ statement warn2.cc:6: warning: suggest a space before ‘;’ or explicit braces around empty body in ‘while’ statement Additional info: If you gcc -E into a .ii file, then compile that you'll get the 2 errors as expected (this is what ccache does in some cases). The arguments to g++ seem to play a part in the warning. If you do use -c and don't use -Werror you DO get both errors. If you don't use -c you only get one. I can't explain how ccache is interacting with this, we end up with the error version of the compile in ccache sometimes (probably since it runs with -E then compiles afterwards) but then when I try to reproduce that I end up with the non-error version in cache (strace shows ccache calling gcc several times so its likely just that I don't know how and how many times ccache calls gcc).
This bug is caused by mapped locations. With mapped locations, all the tokens from a macro expansion are given the location of the start of the expansion. This is a hack -- using the actual locations of the tokens yields confusing error messages, and the line map data structure does not properly track macro expansions (i.e., with the current code we cannot do better). gcc/cp/parser.c:check_empty_body() does this: if (close_loc.line == semi_loc.line && close_loc.column+1 == semi_loc.column) warning (OPT_Wempty_body, "suggest a space before %<;%> or explicit braces around empty " "body in %<%s%> statement", type); ... but since both tokens have the same location, this does not trigger. This also explains the ccache behavior -- the tokenizer does not know which tokens from a .ii originated in a macro expansion, so they get proper locations (inaccurate if you think about it, but not terribly so), and so the error is emitted as expected. (You can probably see the incorrectness with the .ii using -fshow-column.) In the short term I don't know of a good way to fix this. The "real" location of tokens is discarded by the time this part of the parser is invoked. In the long term I would like to change the line map to track macros the same way includes are tracked. I suspect this is not trivial :(
Would it be worth me opening a bug against ccache to ask them to work around this? If they only ever used the .ii for for checksumming then called the compiler the original way when they had to actually compile for real the results from cache would always match the results from the compiler. This would mean running the preprocessing phase twice on every file that missed in cache, but it would at least produce consistent results.
It isn't really a ccache bug. Instead I would recommend using -fdirectives-only with ccache and distcc. This is a new option in GCC 4.3. Not only is it faster for these uses, it will make distcc and ccache compiles emit the same error messages in this situation. I'm not expert with these tools so I'm not exactly sure how you would get them to pass this to gcc :) Meanwhile, I'm going to push this upstream to gcc. It is really a bug there.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.