From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26717 invoked by alias); 6 Sep 2005 15:43:05 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 26697 invoked by alias); 6 Sep 2005 15:43:01 -0000 Date: Tue, 06 Sep 2005 15:43:00 -0000 Message-ID: <20050906154301.26695.qmail@sourceware.org> From: "joseph at codesourcery dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050729205340.23139.thor@math.tu-berlin.de> References: <20050729205340.23139.thor@math.tu-berlin.de> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c++/23139] [3.4/4.0/4.1 Regression] -pedantic -ffast-math breaks working code X-Bugzilla-Reason: CC X-SW-Source: 2005-09/txt/msg00692.txt.bz2 List-Id: ------- 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