From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31233 invoked by alias); 6 Jan 2008 15:13:39 -0000 Received: (qmail 31118 invoked by alias); 6 Jan 2008 15:12:54 -0000 Date: Sun, 06 Jan 2008 16:21:00 -0000 Message-ID: <20080106151254.31117.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented) In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "joseph at codesourcery dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-01/txt/msg00500.txt.bz2 ------- Comment #5 from joseph at codesourcery dot com 2008-01-06 15:12 ------- Subject: Re: Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented) On Sat, 5 Jan 2008, rguenth at gcc dot gnu dot org wrote: > I wouldn't read the language this way. Because that will forcefully disable > all redundancy removing optimizations (which is what happens in this testcase). > What it currently guards is expression rewriting that changes the outcome if > a rounding mode different than round-to-nearest is used. My understanding has always been that -frounding-math should be usable for the code that calls rounding-mode-changing functions, rather than having no way to compile that code safely with GCC, as well as the code that does not call those functions but may execute with non-default rounding modes. The FENV_ACCESS pragma does not distinguish between the two. > The finer-grained control the documentation mentions should not be globbed > to -frounding-math IMHO. The pragma would in effect set -frounding-math for particular regions of code; it isn't more fine-grained regarding whether the code sets the mode or merely runs under a different mode. It is of course possible that -frounding-math should be split into multiple options (more fine-grained than the pragma) as the other related flags have been split over time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678