Bug 449191 - Gcc warnings not being emitted when code is in a macro
Gcc warnings not being emitted when code is in a macro
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
  Show dependency treegraph
Reported: 2008-05-30 20:47 EDT by Eric Varsanyi
Modified: 2009-07-14 11:26 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-14 11:26:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 36478 None None None Never

  None (edit)
Description Eric Varsanyi 2008-05-30 20:47:56 EDT
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):

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
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).
Comment 1 Tom Tromey 2008-06-07 16:45:24 EDT
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",

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

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 :(
Comment 2 Eric Varsanyi 2008-06-09 10:48:36 EDT
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.
Comment 3 Tom Tromey 2008-06-09 11:48:49 EDT
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.
Comment 4 Bug Zapper 2009-06-09 21:18:25 EDT
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: 
Comment 5 Bug Zapper 2009-07-14 11:26:30 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.