This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/23139] [3.4/4.0/4.1 Regression] -pedantic -ffast-math breaks working code
- From: "mmitchel at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 6 Sep 2005 22:03:28 -0000
- Subject: [Bug c++/23139] [3.4/4.0/4.1 Regression] -pedantic -ffast-math breaks working code
- References: <20050729205340.23139.thor@math.tu-berlin.de>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-06 22:03 -------
The "floating constant exceeds range" message comes from interpret_float in
c-lex.c, which does test just "pedantic", rather than CPP_PEDANTIC(pfile). So,
while the preprocessor warning about use of a hexadecimal floating constant does
seem to be like the other PRs, the actual pedwarn/error is coming from the fact
the C++ front end is pre-lexing tokens.
I agree that disabling warnings in expansions of macros from system headers is a
good idea, independently of whether or not any other changes might be
appropriate to deal with other uses of __extension__. There are certain to be
system headers not using __extension__ in macro definitions, on some systems. I
guess we could have the preprocessor insert a special token to mark the
start/stop of a macro expansion, with an indicator of the location of the macro
definition, including its system-headerness. Then, the front end could
clear/reset pedantic when seeing these tokens. This would also allow us to
issue diagnostics based on the location of the macro, rather than its user, if
we wanted. A more brutal approach would be to have the preprocessor simulate
#include'ing the file from which the macro came when doing the expansion. That
would not require updating the front-ends, but would be more confusing to users.
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |mark at codesourcery dot
| |com, joseph at codesourcery
| |dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23139