[Bug c++/23139] [3.4/4.0/4.1 Regression] -pedantic -ffast-math breaks working code

2005-07-30 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-30 
15:26 ---
3.4 produces a warning and not an error, maybe the warning became a pedwarn in 
4.0.0 but this 
should not produce a warning or an error at all.

For some reason the C front-end does not produce a warning or an error.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||diagnostic
  Known to fail||3.4.0 4.0.0 4.1.0
  Known to work||3.3.3
   Last reconfirmed|-00-00 00:00:00 |2005-07-30 15:26:19
   date||
Summary|-pedantic -ffast-math breaks|[3.4/4.0/4.1 Regression] -
   |working code|pedantic -ffast-math breaks
   ||working code
   Target Milestone|--- |4.0.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23139


[Bug c++/23139] [3.4/4.0/4.1 Regression] -pedantic -ffast-math breaks working code

2005-09-06 Thread mmitchel at gcc dot gnu dot org

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-09-06 
15:29 ---
The problem behind both diagnostics fact that the C++ front-end pre-lexes the
entire source file.  As a result, the lexing routines, which depends on the
setting of pedantic to determine whether or not to issue errors, are called when
pedantic is set, even though we are within an __extension__ block.  Because the
parsing of __extension__ blocks is complex, we need to either (a) eliminate the
up-front lexing, or (b) defer issuing diagnostics until we are actually in
position to know the correct value of pedantic.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23139


[Bug c++/23139] [3.4/4.0/4.1 Regression] -pedantic -ffast-math breaks working code

2005-09-06 Thread joseph at codesourcery dot com

--- Additional Comments From joseph at codesourcery dot com  2005-09-06 
15:42 ---
Subject: Re:  [3.4/4.0/4.1 Regression] -pedantic -ffast-math
 breaks working code

On Tue, 6 Sep 2005, mmitchel at gcc dot gnu dot org wrote:

> The problem behind both diagnostics fact that the C++ front-end pre-lexes the
> entire source file.  As a result, the lexing routines, which depends on the
> setting of pedantic to determine whether or not to issue errors, are called 
> when
> pedantic is set, even though we are within an __extension__ block.  Because 
> the
> parsing of __extension__ blocks is complex, we need to either (a) eliminate 
> the
> up-front lexing, or (b) defer issuing diagnostics until we are actually in
> position to know the correct value of pedantic.

The lexing diagnostics depend on the preprocessor's setting of pedantic 
(which doesn't take account of parser context in any case), not the 
compiler's.  This looks just like 7263/11931 for which I still prefer (c) 
handle specially expansions of macros defined in system headers.  A 
fixinclude for definitions of HUGE_VAL as a hex float constant is a 
possible workaround.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23139


[Bug c++/23139] [3.4/4.0/4.1 Regression] -pedantic -ffast-math breaks working code

2005-09-06 Thread gdr at integrable-solutions dot net

--- Additional Comments From gdr at integrable-solutions dot net  
2005-09-06 16:12 ---
Subject: Re:  [3.4/4.0/4.1 Regression] -pedantic -ffast-math breaks working code

"mmitchel at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:

| The problem behind both diagnostics fact that the C++ front-end pre-lexes the
| entire source file.  As a result, the lexing routines, which depends on the
| setting of pedantic to determine whether or not to issue errors, are
| called when pedantic is set, even though we are within an
| __extension__ block.  Because the parsing of __extension__ blocks is
| complex, we need to either (a) eliminate the up-front lexing, or (b)
| defer issuing diagnostics until we are actually in 
| position to know the correct value of pedantic.

In long term, I believe (b) is a better alternative.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23139


[Bug c++/23139] [3.4/4.0/4.1 Regression] -pedantic -ffast-math breaks working code

2005-09-06 Thread mmitchel 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


[Bug c++/23139] [3.4/4.0/4.1 Regression] -pedantic -ffast-math breaks working code

2005-09-15 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-09-15 
19:10 ---
Subject: Bug 23139

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-09-15 19:09:28

Modified files:
fixincludes: ChangeLog inclhack.def fixincl.x 
gcc/testsuite  : ChangeLog 
Added files:
fixincludes/tests/base/bits: huge_val.h 
gcc/testsuite/g++.dg/warn: huge-val1.C 

Log message:
fixincludes:
PR c++/23139
* inclhack.def (huge_val_hex, huge_valf_hex, huge_vall_hex): New
fixes.
* fixincl.x: Regenerate.
* tests/base/bits/huge_val.h: New file.

gcc/testsuite:
* g++.dg/warn/huge-val1.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/ChangeLog.diff?cvsroot=gcc&r1=1.47&r2=1.48
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/inclhack.def.diff?cvsroot=gcc&r1=1.23&r2=1.24
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/fixincl.x.diff?cvsroot=gcc&r1=1.24&r2=1.25
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/tests/base/bits/huge_val.h.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6067&r2=1.6068
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/warn/huge-val1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23139


[Bug c++/23139] [3.4/4.0/4.1 Regression] -pedantic -ffast-math breaks working code

2005-09-15 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-09-15 
19:12 ---
Subject: Bug 23139

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-09-15 19:12:00

Modified files:
fixincludes: ChangeLog inclhack.def fixincl.x 
gcc/testsuite  : ChangeLog 
Added files:
fixincludes/tests/base/bits: huge_val.h 
gcc/testsuite/g++.dg/warn: huge-val1.C 

Log message:
fixincludes:
PR c++/23139
* inclhack.def (huge_val_hex, huge_valf_hex, huge_vall_hex): New
fixes.
* fixincl.x: Regenerate.
* tests/base/bits/huge_val.h: New file.

gcc/testsuite:
* g++.dg/warn/huge-val1.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.32.2.8&r2=1.32.2.9
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/inclhack.def.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.16.14.5&r2=1.16.14.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/fixincl.x.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.16.14.5&r2=1.16.14.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/tests/base/bits/huge_val.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.405&r2=1.5084.2.406
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/warn/huge-val1.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23139


[Bug c++/23139] [3.4/4.0/4.1 Regression] -pedantic -ffast-math breaks working code

2005-09-27 Thread mmitchel at gcc dot gnu dot org


-- 
   What|Removed |Added

   Target Milestone|4.0.2   |4.0.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23139


Re: [Bug c++/23139] [3.4/4.0/4.1 Regression] -pedantic -ffast-math breaks working code

2005-09-06 Thread Gabriel Dos Reis
"mmitchel at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:

| The problem behind both diagnostics fact that the C++ front-end pre-lexes the
| entire source file.  As a result, the lexing routines, which depends on the
| setting of pedantic to determine whether or not to issue errors, are
| called when pedantic is set, even though we are within an
| __extension__ block.  Because the parsing of __extension__ blocks is
| complex, we need to either (a) eliminate the up-front lexing, or (b)
| defer issuing diagnostics until we are actually in 
| position to know the correct value of pedantic.

In long term, I believe (b) is a better alternative.

-- Gaby